Menu

Colin Devroe

Reverse Engineer. Blogger.

Thirty days of images

Each morning, at around 9am Eastern, a new image is published to my blog. I schedule these posts each weekend (I even built a WordPress plugin to help me) and they publish automatically without any other interference from me.

I’ve just hit 30 consecutive days of this schedule and I’d like to keep it up in perpetuity.

The image posts are the least popular on my blog. They are not tweeted or shared on Facebook or Instagram. They are silently published with no fanfare. I think of these posts as a slowly building collection of my favorite images. A way to showcase images, not as a library, but as a selection.

Very, very light editing happens from shot to post. I shoot with my iPhone (currently an iPhone SE), a Canon DSLR, or a GoPro camera. Hopefully soon I’ll be adding a new UAV camera to the mix. I do not make reference to the camera used for each shot because I believe that sort of information is irrelevant. The image is what is important, not how it was captured. In general I prefer my images to be slightly bumped in color so I generally crop, straighten, bump a few values, and prepare for publishing.

To prepare for publishing I have two albums in Photos for macOS. “To Publish” is an album I drag images into that I would like to publish some day. I generally drag 7 to 10 new photos into this album each week so that I always have enough to choose from when I’m scheduling these posts. “Published” is an album full of every image I’ve published. This way I have a fairly simple way of remembering whether or not I’ve already published a particular photo or not. Once the image is edited I drag the image to my Desktop, resize to 1000 pixels wide, and toss it into a new post in WordPress, tag it, and schedule it to be published.

It is a simple enough workflow that it allows me to get an entire week’s worth of images scheduled within about an hour or less each week. I hope if you’re subscribed to this blog you enjoy seeing them.

These posts have inspired both Danny Nicolas and Kyle Slattery to begin doing similar posts on their site. I’m extremely happy and humbled to see that and I’m glad to subscribe to their blogs to see what they share. Who knows? Maybe in another 30 days two or three more people will join.

Use what works, play with the new

I had Unmark’d Kyle Slattery’s post on his company site (which I think is rather good looking; here is why) regarding why his company uses Ruby on Rails. It is a good post. Notice this bit:

It’s easy to get caught up in the newest trend, and there are lots of great technologies being developed, but at the end of the day, just because something’s new and shiny doesn’t mean it will move the needle for your business.

Bingo. By the time I finish editing this post seventeen more frameworks, libraries, or pseudo-languages will have been released. And honestly, that is fantastic. Because out of those a few will take off, be well supported, and become great utilities for future projects to benefit from.

However, this doesn’t mean we need to use them in live projects immediately. Or, that we should jump from one framework to the next because you like the way the method names use camelCase.

Kyle goes on:

When it comes down to it, I’m most productive when I’m writing Rails code. Sure, I could build out my next project in Node.js, or Go, or whatever else is out there, but I’m going to be able to crank out the best, most productive code in Rails. I know it best. I’ve been working with it for almost as long as it’s been out, so I know all of its ins and outs.

This piece, as he explains, is a big reason to decide to use one language or framework over another. Not just your own productivity, as he states, but also for those that may touch the code in the future. If the framework is widely known, actively maintained, and many people use it in live projects, chances are you can add more people to the project and not have to teach them much about your project. They can likely dive right in and be productive very early on.

Lastly, this bit:

A mature framework, while it may not be as exciting, has had thousands (maybe tens of thousands) of hours of developer time spent getting it to where it is, which generally results in a more stable and secure platform.

If the project your working on ever hits any type of scale, you will want to know that hundreds if not thousands of other projects that run on the same technology has done so too. Early on, many people pointed to Twitter as a project that helped Ruby on Rails mature. And also to Facebook as one that helped PHP get a lot faster. Do a bit of digging when selecting what to use in your project, if a “big boy” is using and supporting it then you will likely get more sleep.

The very same reasons Kyle uses Ruby on Rails is why I use PHP. I do like the way Ruby looks far better than PHP. (Insert GIF of DHH saying Ruby is gorgeous here) I also think that the Rails framework is well structured for web applications. I do think Go looks succinct and interesting. And Node is likely better for some of the things I’m trying to accomplish. However, I’m faster with PHP, a lot of people know it, it is very fast and stable, and has been used in large-scale projects. So I’m perfectly happy using PHP.

I try my very best to stay completely agnostic when it comes to choices like these. (Kyle and I still get along great even though he’s a Ruby fascist.) In fact, longtime readers of my little blog here have likely seen my opinion of Microsoft technologies change dramatically since 2012 or so. Recently I saw someone’s C# and was all o_0! It looked very, very nice.

I love playing around with new things in order to see what else is out there. I can’t tell you how many times I’ve built a new Ruby on Rails application or built something with React or this or that. You’ve gotta keep the juices flowing and one way is to push your abilities into new territory. I liken it to a guitar player that mainly plays rock music riffing with a classical pianist. Expand your horizons from time-to-time and it will only make you a better guitar player.

None of this is to say that you shouldn’t switch to something new when the time is right. In fact, one very good reason to play with new languages and frameworks from time-to-time is that when something you’re using needs to get the axe you’re likely better prepared than if you had your head in the sand. There may be a time to switch from PHP to something else and when that happens I hope I have an open mind and make a good decision. I’ll likely refer back to Kyle’s post to help me make that decision too.

RSS to Twitter using PHP

Update January 19, 2010: This script is now available on GitHub. Go forth and fork.

Today I noticed that my now ancient PHP script to update Twitter automatically using PHP/cron needed to be updated. It turns out that Twitter stopped recognizing URLs with ? in them as clickable links. Here is an example tweet where you’ll notice this happening.

I could have told Twitter and asked that they update the way they handle URLs but in reality my script was old, slow, too long, and shouldn’t include ? anyway so I figured I’d write a new one from scratch that included my short URL scheme.

So, here is the PHP script to parse an RSS feed and send the posts to Twitter. It includes a caching mechanism so that you won’t have duplicate URLs posted to Twitter. If you want it, take it. However, if you are better than I am at PHP (most 6yr. olds are better than I am at programming) then I ask that you fork the script on Gist and try to improve it.

Update Dec. 6 @ 5:34p: Kyle Slattery, follow Viddler team member, loves him some Ruby on Rails. As such he’s offered up this version of the script rewritten in Ruby.

Next up we have Anthony Sterling, self-proclaimed “PHP addict”, who has rewritten the script to make the configuration a bit easier. He also changed the way the cache is saved. He’s using a hashed version of the title for each post as his key. I do not believe this to be the best way to go, since post titles can easily change after publishing – but I do like that the script is about 20 lines shorter and the code is arguably cleaner.

Thanks to both Kyle and Anthony for their versions. Lets keep this going and see if we can get this script much more succinct, stable, faster, and usable by others?