Ideas: Remotely hosted personal site with home data store that syncs as client

This idea is based on my Local + Proxy Remote Hosting for Personal Site idea, but attempts to mitigate some of its problems further.

In this setup, the website (most appropriate for personal indieweb type sites) will still have a remotely hosted and a home hosted component. The home server will be the single source of truth for data, but will not be remotely accessible. The remote server will have the full code and data to run the website and will handle all visitor request directly, using copies of the data from the home server. CUD changes can be done on the remote server, but they will be marked as ‘unverified’ or some-such. The home server can have a cron task or manually run script to make a request to the remote server, which will transfer changes between the two. The change request may also be run after each change is done on the home server, or after a certain interval following an update to batch send them. Some sort of key based system would be used to authenticate both ends.
Continue reading Ideas: Remotely hosted personal site with home data store that syncs as client

Blogs moved and merged

This weekend, I moved my wordpress.com “professional” (web development) blog and my “personal” blog both to my main website and merged them together. I had been planning on moving my blog from wordpress.com for a while, but recent problems with writing posts with code blocks pushed me to finally take the plunge. I’ve also been feeling like maintaining a separate personal and professional site might be more trouble than it’s worth. I do worry that the different sort of audiences that would go to the one wouldn’t want to see the content from the other and vice versa. I might be less inclined to write some personal stuff on my professional blog. But I think I will be able to find ways to mitigate those issues and make it work well.

Both sites are now redirecting to my main site. I had to pay wordpress.com ($13 a year) for the privilege, but I think it is worth it considering the “link juice” I have with that blog. I will probably continue paying for at least several years. With the use I’ve gotten out of WordPress so far, they’ve probably earned it.

There are still some things to fix:

  • The content imported from my professional blog didn’t bring over the markdown formatting, and thus all of the code blocks are messed up. I am going to have to manually copy them over one by one from the wordpress.com admin as far as I can tell. A pain.
  • I accidentally deleted all of the media files imported from the wordpress.com due to the way I deploy my site. I’m going to have to reimport on a local install and upload, then make sure my deploy ignores that directory. Hopefully the redirect I set up doesn’t cause problems for this.
  • There is plenty of non-blog content on my personal site that I will need to move to my main site. I don’t have any real “link juice” with that site, so I can move things wherever I see fit or not copy it at all if it doesn’t seem worth keeping.
  • The theme is just a slightly modified ‘twenty fifteen’. I’m going to have to decide what I want to do with it to better integrate it into the rest of my site.

My eventual plans are to move my blog out of WordPress and into the same system I’m using for the rest of my site. I may lose some things in the process, including possibly my connection to the WordPress project, but I will gain control.

I had a number of problems during my move, but am way too tired to write about them currently. Hopefully they’ll make for a few posts this upcoming week.

Command-line weather with wttr.in

Cool, lightweight, and simple ASCII weather forecast site that can be curled: wttr.in. It does user-agent sniffing to show plain, colored text for curl, wget, and the like so that it looks nice on the command line, while browsers get HTML with a similar appearance. The “home page” does IP lookup to guess your location. Results of curl wttr.in/cleveland:

nicely formatted ASCII weather forecast

Websites in Multiple File Formats

Since I saw Symfony’s _format routing parameter, which is used to effectively set the file type of the response, I’ve thought it would be cool to have every page on a website support more than just ‘html’ response types by adding a .{_format} to the end of the URL and make a template version for each. Users would be able to consume the same information in different formats depending on their needs. ‘txt’, for example, would basically have just the content that would go in the “ element, in pure text format, providing a fallback or simplified view that can be read even by curl users. ‘json’ or ‘xml’ formats might provide the content and meta data about it in a machine consumable format. You could even go all out with an ‘mp3’ format where you read the page content.

Yesterday, I took my first step toward this idea on my site by implementing my homepage in the ‘txt’ format. This was very simple since my content is already being composed in markdown, a visually pleasing structure for text content.

Obviously, adding more pages and formats will add development time. This probably wouldn’t be useful enough to be worth it for a normal site, but for my own site, I get to play with whatever cool ideas I want.

My new resumé site

Well, I finally did it. After several years of effort, I finally released a new version of my CV / resumé site. How did I accomplish such a difficult task? Let me tell you, it was not easy. There was the desire to accomplish perfection that I did not have enough time for in my day job, to make everything organized and set up in the best possible way, that I might be able to draw from for other sites. There was the want to learn new things that I don’t use at work that might be useful or at least give me ideas and be important to know for my career in general. And, of course, there was the fatigue from doing very similar work for long periods of time at my actual job, and working on some of the more general use projects I work on on github.

I spent countless hours reading about different best practices and methods. I researched and tried several different frameworks / CMSs. I built and rebuilt my site numerous times in different ways. I played with different design, development, and content ideas, and was not entirely satisfied that any was the best.
Continue reading My new resumé site