posts

I think that the workflow I have developed for this blog is pretty interesting, so I decided to write up how I currently approach it.

I decided to dust off ab and see what the performance of the new blog is.

It’s running on a single Heroku Hobby Dyno, with 512m of RAM. It’s running nginx/1.9.7, Puma 3.11.2 and Ruby 2.3.4-p301. All of the files are static, generated by Jekyll.

As a remote worker, and one that travels at that, finding a good coffee shop to work from is a hassle. Sometimes I want a loud place with a lot of bustle, sometimes I want someplace more like a library. I’m often on calls, so when I have a day with out calls, and I can get out and about I really enjoy it.

I really like markdown for writing technical stuff. It makes it super easy to create code blocks, embed commands in a sentence and generally be really cool.

So I went and did it - Moved to Jekyll and Markdown. Hosted on Heroku with a full development pipeline behind it. I love how easy it is to create a branch, work in that, and have my review app up and running for reviews.

I was pressed into service to do a training on Heroku for about 300 developers. It was a fun experience, and I really like to go back and watch myself so that I can critique my performance. Hopefully improve as well.

I’m playing around with Nanoc - a static site generator.  Basically,  nanoc allows you you write your blog posts offline, and then generates your entire site in raw HTML. This allows you to host a site with out needing a database. In other words, it’s dead quick. You can also forgo a web server, and just host your site from S3 if you want.

In the mid 2000’s a bookseller accidentally changed the world. Yes, that bookseller was Amazon, and the change was the introduction of a IaaS. Quite possibly the first Infrastructure as a Service. At least the first commercially viable IaaS.

(cross posted from the HPCloud Blog. With 75% more typos!) One of the most basic problems with systems that need to persist data, is making sure that you can recover those systems in the case of a critical error. I’ve used and written backup systems for more time then I’d like to admit (for example). With the advent of cloud storage systems such as S3, moving your data offsite has become much easier, and much easier to recover data from your offsite storage system.

Just a disclaimer - I am a Buddhist, so I tend to frame my thinking in Buddhist language. However I am not a religious Buddhist. The only reason that I identify as Buddhist is that the philosophies put forward by the Buddha resound with me, as do the ways that they are presented.

One of the trends that I personally have noticed is the removal of the ability to comment from articles on blogs. I’m not sure which camp I’m in,  so I decided to preform an experiment. I turned off comments on the last few articles that I have posted, just to see how that makes me feel.

Over the last few months, I’ve done a few webinars. On was Running Production Apps on Heroku, and the other was Optimizing  Production Apps on Heroku. Below the fold I have the slides and video from the talks.

So, yesterday I read this. It echoed a lot of how I approach my inbox as a task list, and some of the ideas there pushed my inbox-fu to black belt levels. However I work in a different environment then Keith does, with a lot more customer facing email. I’ve merged Keith’s ideas with my workflow, and have come up with a gmail centric inbox-fu which is agile, powerful, and above all easy.

Footprints in the Sand …the Discordian version

I really hate this error. Skype is so unstable for me that I get little slowdowns and lock ups weekly, And about once a month I get this error after I’ve force killed it. I used to have to google it every time, drop to a command line and do a bunch of stuff. Well no more. Now there is a script to clean up after Skype’s mess! Skype - you can barrow this if you want. Just have it run when Skype is launching.