The Developer's Dystopian Future by Ed FinklerEd Finkler (

I think about how I used to fill my time with coding. So much coding. I was willing to dive so deep into a library or framework or technology to learn it.

My tolerance for learning curves grows smaller every day. New technologies, once exciting for the sake of newness, now seem like hassles. I’m less and less tolerant of hokey marketing filled with superlatives. I value stability and clarity.


I’m scared that either the job “web developer” is outpacing me, or my skills are atrophying.

Marco Arment links to developer Ed Finkler who is ageing and finding that keeping up with every flashy shiny new language and development framework is just exhausting and no longer interesting.

I’m almost 48 — Marco and Ed are most likely much younger — and as a former1 web developer I’m already living into my own dystopian future. I haven’t a clue about Ruby on Rails or Scala.  I dislike the formatting cage of Python and I barely know (or used) Objective C and Java.  I absolutely hate C.

But.   I’m going to try to learn the Swift language and the Node.js framework. I’m going to leverage my other language skills in Perl, PHP and JavaScript.

Then I’m going to learn how to break code.

Because the application layer is where the black hackers and criminals have gone.   The future will be filled with (more) data piracy and breaches, and cyber attacks.  So I’m learning how to break the code and start a new future.

I still call myself a web developer but the technologies have rapidly outpaced my motivation. But I have a plan.

Posted via Desktop Publishing Machine

  1. I still code.  I just don’t get paid to do it. 

[exif id="31380"]

Yesterday, Facebook announced Hack, a new language that also runs on HHVM. It’s like a “PHP++” — it adds optional static typing, generics, and a bunch of other enhancements and conveniences to PHP. Unlike HHVM, adopting Hack is a huge risk. HHVM was great because you could switch to it and switch away from it freely, with almost no effort (especially to switch away). You were still writing PHP. But once you convert a file to Hack and use any of its new features, it’s no longer valid PHP, so you must always use Hack and HHVM from that point forward (or undertake an expensive rewrite).Hack Isn’t PHP –

Be careful not to be locked-in.

Last August I started a small project to use my Raspberry Pi to do bracketed image capture for HDR using my ageing Nikon D40. My solution worked but was not complete. My solution required me to compose my scene and then connect and power on the RPi and wait for the script to complete and then shut down the RPi. I wanted something that I could trigger with a switch.

After much trial and error -- and a bit of panic -- I have a fully functional solution written in Perl. This HDR Raspberry Pi project is based on other projects and ideas from several places including the comments section of my original post from last August. In particular, I would like to recognize the following projects.

Zach Dwiel's gphoto2-timelapse project is written in Python but I got the basic concept of what I needed to from his project. Using a startup script and usbreset ideas were borrowed from his project.

After searching around for how to use the GPIO on the Raspberry Pi I found a link to gpio from WiringPi. This is an implementation of most of the Arduino Wiring functions for the Raspberry Pi. The gpio binary plus a very easy to understand diagram and some simple code from the TNET Raspberry Pi site helped complete my project. I also found the RPi low-level peripherals page on the site very useful.

This project allows you to create bracketed images for use in HDR photography using the Raspberry Pi, a supported DSLR camera connected via USB to the Raspberry Pi, and the gphoto2 program. The script is a Perl rewrite of an earlier BASH script. The goals for the Perl rewrite was to make things a little easier.

I've included the code for the main script and usbreset but the rest you'll have to download and install yourself. Download and compile the WiringPi code to create gpio. You will need this to control the GPIO pins on the RPi and a switch to signal the main script to do its work.

You will also need to install usbutils - Linux USB utilities - to get lsusb. lsusb is a utility for displaying information about USB buses in the system and the devices connected to them. I found lsusb more useful for detecting when a camera was attached to the RPi and turned on. I could have used gphoto2 with the autodetect switch but I found lsusb was faster.

You will also need to compile usbreset. This handy piece of code helped reset the USB interface to the Nikon camera between brackets sets. I found that without usbreset that gphoto2 would generate a lot of errors using the Nikon.

You will need to install Perl to run the HDR scripts. This might already be a part of your library.

Once everything is installed, you need to tweak the script a bit to get it to work with different cameras. For example, I used lsusb to specific USB ID for my Nikon D40. I used that in the script. You will also need to find the proper gphotos2 parameters for you camera. Once you have the camera specific parameters and functions in place, you can use the Perl scripts to begin taking images.

perl There is also an rc script which you can use to start the HDR script automatically when the computer (raspberry pi) is turned on. To setup, this feature runs the following commands:

sudo ln ./rc.hdr /etc/init.d/rc.hdr cd /etc/init.d/ sudo update-rc.d rc.hdr defaults

The script is made up one main loop and four functions. One function uses the lsusb utility to get the bus and device information for the Nikon. This information is then used by usbreset to re-initialise the Nikon's USB connection in between bracket captures. I found that this eliminated a lot of the error messages from gphoto2.

Two more functions control the gpio so that I can trigger the capture event. One function takes the five brackets images.

That's it in a nutshell. I did notice that the slowest part of the script is the gphoto2 capture. I can't explain why but I notice that gphoto2 takes about 5 seconds to set up before it will start capturing images.

Moments after completing this project I had some ideas for improvement. I want to reduce the time between pushing the button and capturing the last image. Currently, this is five seconds. I suspect that calling out to gphoto2 from Perl is slowing things down. I think maybe writing Perl binding to the gphoto2 library may help or perhaps writing the entire program in C. I'm not a big fan of C -- I try to avoid strongly typed languages in general -- but if I can find the time and motivation I will try.

You can find all the code on GitHub.