Sam Merrell Tinkerer. Parent. ADHD. Developer.


Using qDslrDashboard with the Sony a6000

Most of my posts are going to be something technology related but I do happen to have other interests. For a while now, I’ve had a Sony a6000 that I’ve been very happy with. I’m very much an amateur at photography but I find it fun and I like the images I get of my family more than the ones I can get from my iPhone. So I’ve been slowly trying to level up my photography skills. I’m definitely not over 9000 yet, but maybe one day I’ll get there.

This Christmas, I finally got a tripod and it has gotten me interested in trying to do some time lapse photography. Sony has a time lapse app but I wanted to see what other options were out there. After a bit of Googling, I came across DslrDashboard. Confusingly, the apps have been renamed to qDslrDashboard, but there is an app for just about every platform.

Since I own two iDevices, I went ahead and threw down the $10 it cost for the iOS app. At first, I was hoping to find a free option to do time lapse, but I definitely feel better giving a developer my ten dollars instead of just throwing it at Sony. Since I didn’t have my iPad right on hand, I started trying things out with my iPhone. It took me a while to figure out how to get the app to work with my phone, and honestly, I’m still not 100% sure how to get the thing to work consistently every time. Here’s what it took me to get my camera and my iPhone running the qDslrDashboard app running.

  • Go to
  • Create an account (PlayStation Network account, ugh.)
  • Go to Menu -> Applications

    Application list on the a6000

  • Select PlayMemories Camera Apps

    Application select PlayMemories Camera Apps on the a6000

  • Find Smart Remote Control app
  • Install it

I still feel pretty gross about having to create a PlayStation Network account, but there you go, all the steps to get the Smart Remote Control updated.

Getting qDslrDashboard and the a6000 working together

To get the a6000 to be controlled remotely, you have to open the Smart Remote Control application. This is as simple as going from Meny -> Applications -> Application List -> Smart Remote Control. Once you open the Smart Remote Control app, the a6000 will create a WiFi network. Simply connect your device to that network using the SSID and Password from the screen and the camera will start in remote control mode.

This is where it gets a little odd with the qDslrDashboard app.

Tap the button until it works

The first tap of the Sony Wireless button has not worked for me, I often have to press multiple times until it works. A little weird, but it does eventually work!

Once you’ve tapped the Sony wireless connection button enough times, you’ll be greeted with this screen of buttons. I don’t know for sure if qDslrDashboard defaults to using a live view, but if it does you’ll see what the camera is seeing as well. Otherwise you can tap the little Lv button in the top left corner.

To get to the time lapse portion, you need to tap the time lapse button on the right.

The time lapse button

The time lapse screen has a whole bunch of options to choose from. In the image below, I captured a sample, it then displays a bunch of information about the image you took to help you figure out what settings you’ll need to make the time lapse. I don’t know what much of that means, but one day I will!

The time lapse screen

At the most basic level, you really just need to scroll down and click the stopwatch icon. The stopwatch icon will let you configure the interval timer which is the heart of doing the time lapse.

The time lapse interval timer screen

Setting the interval timer is pretty simple, but you do have to think a little bit about it. When I first set it up, I wasn’t really reading what the screen was trying to tell me. I set a frame count and then set the interval to 20 minutes. In my mind it was going to take pictures until the 20 minutes ran out. When nothing happened for a minute or two, I realized my mistake.

The time lapse interval timer setup

If you want to have a time lapse go for a specific amount of time, you need to factor in two things. The interval, which is how long to wait between shots, and the frame count. The frame count is exactly what it sounds like, the number of frames to capture. So, if I wanted to shoot for an hour and I was taking a frame every second, I need to work backwards to get the number of frames.

If I have an interval of 5 seconds, it is going to look something like this:

(60 seconds / a frame every 5 seconds) * 60 minutes = 720 frames

So to capture an hour of time at 1 frame every 5 seconds, I need 720 frames total. This will capture an hours worth of time, I do wish qDslrDashboard had a way to say how long to capture as well, but it isn’t too difficult to figure out on my own.

After that you simply press start and the camera will start taking pictures at the interval. Easy! So how about after you’ve taken the pictures? Well, after some Googling and playing around I’ve found two different ways to use the time lapse. One is by making a gif and the other making a movie.

Resizing the images

Since the a6000 takes 24 megapixel (roughly 6000x4000), I resize the images first. This is where ImageMagick comes in handy. The script below will find all the images and use ImageMagick’s mogrify command to resize the images in place.

for file in *.jpg do;
  mogrify -resize 3840x2160^ -gravity center -crop 3840x2160+0+0 +repage $file

I got this from this great post.

Note: This script resizes images in place, I do this because I export the pictures from Apple Photos. If you don’t want to resize the actual image, you can add -write resized/$file before the last $file. This will write out all the images to a resized folder.

Depending on how you want the images cropped, you might want to play with the -gravity setting. This script will crop all the images directly in the center of the image. The 3840x2160^ resizes the image to a 4k resolution but will preserve the smaller of the width or height.

I’ve played around with resizing images with ImageMagick before, but the credit for this script goes to Dan Loewenherz’s great blog post Making a time-lapse on the command line using FFmpeg and ImageMagick. There are many great tips from his post, so you should go read it.

Turning the images into a gif

If your time lapse is pretty short, you can convert to an animated gif quite easily using ImageMagick. The command looks something like:

convert *.jpg -set delay 1 my-time-lapse.gif

This is the most basic way to create an animated gif from a series of images. This only works if the Jpeg files are ordered. You can play around with the -delay time and see how it turns out. ImageMagick also has a million other things you can do so take a look at the docs.

Turning the images into a movie

Once you have the images resized how you want them, converting to a movie using ffmpeg is pretty simple.

ffmpeg -framerate <some number> -start_number 1 -i image%04d.jpg -c:v libx264 -pix_fmt yuv420p <filename>.mp4

This command will take the series of images and put them together into an MP4 video file. The -c:v libx264 command tells ffmpeg to encode the video using the libx264 codec. This will encode it as an h264 video. The -pix_fmt option sets the pixel format of the video. This is the color format of the video, video players will use it to know how to display the video properly.

And with that, you will have the final product! Ffmpeg has a ton of option and is a very powerful tool, I’m certain I will have more to write about using ffmpeg to convert or create videos.

End Result

Edit: Feburary 6, 2016:

Here is a sample video I made of a sunset.

Learning Rust as a C# Developer

Choosing a new programming language to learn is difficult. What do I want to focus on? Do I want to learn something low level like C? Do I want to go all out functional and learn Haskell? What about Go? Everyone seems to be glowing about that language. Elixir? I hear Rubyists are really digging on that language, and it is built on top of Erlang! So many choices!

As you’ve probably guessed from the title, I ended up picking the Rust programming language as the language I’d like to focus on and learn about. So lets take a little bit of time to talk about why I made that choice.

A way to delve into “systems programming”

“Systems programming” feels like this mythical place of expert developers writing bare metal code to do things I can barely even understad. It is so different from my day-to-day job that it feels almost unattainable. I’ve never written anything in assembly, I can’t really read hex, and I’ve only barely tried to write anything in C. It really feels like such a daunting task to get into what seems like such a complicated topic.

Fortunatly, Rust really feels like an accessible language that could get me learning about systems programming. I can learn how to manage my own memory, how to write performant code, how to work safely with pointers and many other “low level” bits of code. For whatever reason, Rust just feels like I can jump in and actually do something. I haven’t felt that way with C or C++.

A C replacement

I swear, one day I actually am going to get around to learning C. When I do I’m going to do it the hard way. But until I do, one of the reasons I picked Rust is that it is explicitly aimed at replacing C and C++ as the programming language of choice for prople writing performance critical or low level code. I’ve started and quickly stopped learning C and I haven’t found the motivation yet to stick with it and really learn the language. I’m sure I will eventually, but I think the barrier to entry has still been too high for me.

With Rust, I have been able to get going pretty quickly in the language and start to learn bits and pieces about Rust while doing interesting things. I’m sure I could also do this with C, but so far I just haven’t had the willpower to stick with it. Rust, on the other hand, has kept me very interested and very motivated to learn the language.


Another specific reason I chose Rust was that I wanted to try out a language that does no garbage collection for me. Throughout my career as a developer I’ve worked in a garbage collected language, and honestly it is pretty awesome most of the time. But, since it is the only thing I’ve used before and I want to learn lower level programming skills, I have to learn how to walk away from garbage collection and learn how to manage memory myself.

Modern language features

As a final deciding factor, the language features that Rust provides are very compelling to me. Generics are available and I am familiar with how to use them in C#, Traits (i.e. Interfaces for C# people), pattern matching, etc. are all language features that feel very compelling and interesting to use.

So there you have it, a few of the reasons that I’ve decided to spend time really trying to dig in and learn the Rust programming language. I have much to learn and will likely be sporadically sharing what I’ve come across so far here on this blog.

Agile is Hard

Agile. Such a broad topic with so much to discuss and so much already discussed. It really is one of those topics you can go on about forever. So how am I going to put my spin on things? Well, I’m not I’m just going to talk about what I’ve learned so far in over a year of really trying to do agile the right way and hopefully I’ll have learned something as well as you, the reader.

Scrum Time

A little over a year ago we decided at work that the way we were doing things could really use some improvement. We were using Agile Zen and its online Kanban board but instead of embracing Kanban and continuous flow we basically were working in a waterfall manner.

Fortunately for me, I got pulled onto a new team that was working on a new product to support our call center’s onboarding of agents. Since we were on a new team we also were tasked with really digging in and giving scrum a go. We gathered our new team of joint QA and Dev, read a couple books, got a scrum consultant, set up our white board and we were off estimating our stories and slapping them up on the board.

Two weeks

It really was great starting out. It was the first time for me to really get more interaction with the business and learn a ton about the domain. We also had decided to give one week iterations a try and deliver what we could within that time frame. I was really onboard with the one week iteration idea since about a year before that I had read Kent Beck’s Extreme Programming Explained and really felt it would help keep us on track.

Unfortunately for us one week iterations just felt like too much so that lasted only a couple weeks until we decided to change our sprints to two weeks and have more breathing room. We also had the typical growing pains of trying to figure out how to actually estimate stories and become better with our estimations. We also worked on keeping our discipline of writing tests first and really being TDD focused.

Over the last year we feel like we’ve gotten pretty good at most of these things, but over time I’ve noticed a few bad habits creep in and as a whole I’ve noticed some questioning of the methods we’ve been using.

Things don’t seem quite right

I began to notice that things with our development process didn’t seem quite right. We had begun to fall into a trend of consistently going over our two week iterations by a few days. We were beginning to leave QA behind and move forward when we were “dev complete”. As I started to feel like we were doing it wrong Jeremy Miller wrote a post about (not the book, mind you) “Code Complete is polite fiction”.

Since Jeremy’s post better explains how I was feeling, please read that. Basically we had fallen into the quagmire of “trailer-hitched QA” as Uncle Bob Martin called it. Instead of staying focused and being done-done-done we were slipping into the bad habit of saying we were done earlier in the sprint that we really were.

Round two

So recently we have decided to try and give Kanban a real try after learning so much with our time using Scrum. One nice thing about Kanban is that it isn’t really prescriptive. I’ve always found scrum a bit grating that way just because you start out with a rigid set of rules you’re supposed to follow until you are comfortable. From there, you can decide what is or isn’t working, the hardest part there though, is uprooting all your processes to implement Scrum.

Moving forward I think the next couple steps we’ll be taking is to really reduce the work in progress to a manageable level. One of the worst symptoms I see of trailer-hitched QA is that you have a dozen or more features or bug fixes all being worked on at a time. It gets very confusing to keep track of everything in flight and make sure it gets out the door in good shape.

From just reducing our work in progress I imagine we’ll begin to see more clearly where our processes are causing bottlenecks and work towards fixing them. Instead of uprooting everything and starting over, we continually improve to make the processes we have now better and more effective. Most importantly the long term effect is we developers are happier, QA is happier, and our business is happier with the work we’re doing. And for me, that is an all around win.

Make Testing Easy

Testing. We all know that we should do it, and yet often times we find ourselves struggling to stay consistent in testing our code. I know that I personally find it difficult sometimes to really stick to and test my code, and guess what happens when you don’t test your code. It comes back to haunt you.

I was discussing this with my coworker Ryan about this very problem, and it got me thinking I should write it down. (It also helps he suggested it would be a possible blog post topic, so thanks Ryan).

When I Test

At Extend Health, I’ve been working on a specific project for quite some time now. I got the privilege to start out with a new greenfield project and have watched it transform over the last year. When we first started out, we had to keep our business process running by pretty much glue and duct tape to make it through the Annual Enrollment Period. Those were rough times filled with taking an existing Microsoft Access project and getting it to talk to SQL server on the backend so the data was at least in one place.

It was rough, but interestingly we were determined to keep things tested. Since basically all logic had to go into the DB at the time, we looked at SQL testing frameworks. We stumbled on tsqlt and found it helped us quite a bit. But even with a testing framework we found it very difficult to write tests.

On the next revision of our project, we got to start completely fresh and built our system using CQRS and Event Sourcing. With a clean code base and pretty good discipline, we were able to consistently keep our code tested and often we wrote test first. Not always, but a good portion of the time anyway.

Then Things Get Hard

After working on my last project, I got some time to add to a large project we have based around WPF and Caliburn. This is when I noticed I started to throw my testing habits out the window and just cowboy code everything. But why would I knowingly throw testing out the window?

Then I sat down and thought about it. What was the main thing that I was using to justify my lack of tests, even though I know I should be doing them? It really came down to one thing for me, testing the code base was hard. Boo hoo, right? But it really comes down to friction making tests surpassing my will to write the test.

Well What Do We Do About This?

So what exactly do we do about this so we actually test our code? I’m going to throw my favorite programmer answer at that one: it depends. I know, I know, that is the lame answer but it really is true from what I can tell. Really it just depends on if you’re working with existing code or starting out fresh. Since it isn’t too common to just get a new, fresh codebase to start with lets look at the existing code problem.

The way I see it, there really is only one way to go with an existing solution. You can start by beefing up your test helpers to make setup as painless as possible, and while you’re doing that you get a bonus. It helps you identify areas in your code that are very painful to test. Once you’ve got your test helpers automating the suck away as much as possible, you can start to identify the most problematic code to test.

Perhaps you have un-mockable or difficult to mock classes? God objects being used everywhere? Either way, once you identify the problem areas you can pick them apart one by one and write the new code using tests, of course. Obviously it sucks to have to do this slowly but I don’t really see another way to take it besides griding down the painful pieces as you can.

So The Moral Of The Story Is

You’ve got to make your code easy to test or you are going to find ways to convince yourself you don’t need to write them. Simple I know, but it helps to stay disciplined when the code lends itself to testing. If you have a codebase that is really difficult to test, then it is worth the investment to make it as easy as possible. This means you can make helpers for the tests while you chip away at the really hard parts of the code. In the end, you’ll thank yourself for doing it.