When asking any photographer what he or she thinks about tripods, you’ll get different answers, as most people will have different needs for their tripods. There is one common denominator; the tripod should provide a platform stable enough to take sharp pictures. Though some require a tripod for one to two second exposures, and some for timelapses that run for hours where the camera needs to stay in the exact same position, and others for blending multiple exposures of the same scene over the course of hours. This difference in usage results in different tripods and heads to suit their specific needs.

“The thing about the smaller ones is that if you need a 30 second exposure and there’s any wind, you’ve got next to no chance of making a sharp image. That’s why I don’t think of these as “travel” tripods. Because it’s not the traveling that I need it for. It’s the making sharp photographs. And if the tripod doesn’t do that, what good is it?” David DuChemin

Personally, I’m using a tripod currently for longer exposures, nighttime photography and exposure bracketing. My idea is also to experiment with video, astrophotography and time-blending photos, inspired by the Elia Locardi & F-Stoppers landscape photography tutorial and cityscape photography tutorial. A few years ago I got a cheap alloy 4-section tripod that has accompanied me literally around the world, from New Zealand to Iceland to support a Canon DSLR. This has taken its toll on the tripod, and it is now a wobbly bit of metal that only is sturdy when two sections of the four are extended and when there is no wind. It thus calls for a replacement, yet what to look for?

Thom Hogan wrote a clear article about the requirements for a tripod, and that you can either spend a whole lot of money investing in multiple tripods over the course of a few years, or spend less when buying the right tripod and head from the start. The most important part in his article for me personally are the requirements for a new tripod, on which I based my own requirements:

  1. Stable and solid platform for a 35mm camera + 70-200mm f/2.8 telephoto zoom lens, will not move to a medium format
  2. One time investment; it should be built to last and future proof, not having to buy another tripod again in a few years.
  3. Small and light enough that I want to carry it with me, yet tall and heavy enough to raise camera securely to about eye level (about 180 cm) on even ground when mounted on ball head in adverse weather conditions:
    1. Flight carry-on compliance is bonus points, but should always fit inside my The North Face duffel
    2. Maximum of four leg sections.
    3. Platform height of 125cm is acceptable.
  4. Easy to clean and maintain in the field.
  5. No center column, as I’d like it to get low to the ground.

At first my thoughts went in the direction to purchase one tripod and head that met all my criteria, even the flight carry-on compliance. Though, I’ve been swayed into the direction of purchasing two separate tripods and heads to accommodate my needs better. A tall, heavy duty tripod and ball head combination, that should weigh no more than about 2 kg, for travels and personal assignments that focus on photography, and a lighter tripod that is travel-friendly (i.e. carry-on compliant). Coming years I’ll probably travel and fly a lot more than in past years, sometimes with only a carry-on sized backpack, and at times with check-in luggage.

Matt K of onOne software makes a good argument in the same fashion as my thoughts go; you do need a strong tripod, but you can’t always bring the largest one you have, and then having a small tripod with you can still be beneficial as long as you are aware of the drawbacks. It is all a trade-off. Similar situation with cameras; I don’t carry my Sony A7II or Fuji X100 everywhere I go, but I practically always have my iPhone with me. The best camera is the one that’s with you.

Based on a lot of reviews and blogs (Luminous Landscape, Tools & Toys, Pentax Forums), I have decided on the following two tripods and ball heads: – Full size: Really Right Stuff TVC-24L tripod + BH-40 lever-release ball head – Travel friendly: Sirui T-025X tripod + C-10X ball head

Mind you, these setups are not cheap, but I intend that particularly the RRS will last me a life-time, and I’m saving my pennies for it. I have been swayed to select the TVC-33 by Really Right Stuff as my full size tripod paired with a BH-55 ball head, yet that is overkill with the gear that I currently have and expect to own, and that combination weighs too much in my opinion. Lighter camera systems also allow for somewhat lighter support gear; the TVC-24L is rated to support a whopping 18 kg, and the BH-40 for a load capacity of 8 kg, way more than the gear I plan to put on top of it (Thom Hogan wrote that a good tripod should “hold its position no matter what the angle of the camera”).

Review of the Sirui T-025X tripod + C-10X ball head

Sirui T-025X (left, one leg section extended) and Redged RTT-423 (right)

Sirui T-025X (left, one leg section extended) and Redged RTT-423 (right)

Recently I’ve purchased the Sirui T-025X as my travel friendly tripod, and I’m quite delighted with the quality and stability of it. It feels more stable than my metal alloy Redged RTT-423 tripod, yet isn’t quite as tall. I really have to sit on one knee to work with the Sirui, and that is a compromise I’m willing to make for the portability. I can strap the tripod to my F-Stop Loka UL backpack, or even inside it, so that I can carry it on an airplane.

The specifications that matter to me: – Load capacity: 6 kg – Collapsed size (without center column, and not folded over itself): 40cm – Weight (without center column): 0.8 kg – Number of leg sections: 5

The Sony A7II + Canon 70-200mm f/4 is quite stable on the Sirui

The Sony A7II + Canon 70-200mm f/4 is quite stable on the Sirui

The stability of the T-025X is quite alright; when I’ve got my Sony A7II + Canon 70-200mm f/4 mounted without using a lens collar and the tripod legs in their smallest spread, I do see some movement in the image at longer focal lengths (> 135mm) when handling the camera or lens (for instance slowly focusing). Yet when I’ve got the Sony 24-70mm f/4 mounted on the body I can’t see any movement. I think that mounting the 70-200mm with a tripod collar on this tripod will improve the stability, as the weight of the combination will be more centered.

Leg locks; twisting locks of the Sirui on the left, the Redged clip locks on the right

Leg locks; twisting locks of the Sirui on the left, the Redged clip locks on the right

What I really like about the Sirui are the twisting leg locks, these are way easier to use than the clip leg locks on the Redged, wouldn’t want anything else anymore on a tripod. When the tripod is collapsed it is for me easy to grip all locks and twist them open in one go, pull the leg sections out, and then with a short twist close the leg locks separately. It feels faster, and a lot more elegant, than the leg clips to setup the tripod. Same goes for collapsing the tripod, though in reverse order.

The Sirui C-10X ball head

The Sirui C-10X ball head

The ball head is OK; compact, lightweight and compatible with Arca Swiss/Really Right Stuff camera plates. With the Sony A7II and 70-200mm f/4 combination (without lens collar) I don’t notice any drop of the ball head when left locked and untouched for half an hour. The thing I don’t like about the ball head is the clamp; the screw clamp is cumbersome to open and close, I do prefer lever release clamps for their speed and simplicity.

Overall the Sirui does its job as the travel friendly tripod; short collapsed size, stable and a low weight. A good companion for a city trip when traveling with only one bag, or when traveling really light.

When I have purchased the Really Right Stuff TVC-24L I’ll write a more extensive review of that tripod.

Tagged with:

Recently I had a chat with a product manager inside our organisation, discussing about the future roadmap and the wishes of a development team for that roadmap. In that discussion it was mentioned by the product manager that improving code quality and solving technical debt doesn’t do anything towards customer value, only use precious time that is better suited to develop new functionality. Personally, and as a proud developer, I do not agree to this, and in order to get my facts straight, I decided to write this letter.

Dear product manager,

In a recent discussion we came across the topic of solving technical debt and improving code quality, and we differed on the opinion whether these actions contribute to customer value and/or market value. With this letter I’d like to present you with some arguments as to why I think that solving technical debt and improving code quality will have a positive effect on customer value.

One of the test managers at Spotify, Kristian Karl, mentioned at the 2015 Continuous Delivery conference that “Defect prevention is better than defect detection”. When focusing on improving the code quality it will be easier to spot potential defects in the code, and thus signal these defect earlier. It may be argued that bugs can be found during manual regression testing, but that is again time spent that could have gone to delivering new functionality. Of course this is also dependent on the discipline of the developers, where they should take pride in delivering craftsmanship code.

“Defect prevention is better than defect detection”

Improving the code quality will also have a positive effect on the maintainability of the code, and will contribute to the time it takes for new team members to comprehend the concepts in the code. When new team members are getting up to speed faster, they can contribute at an increased pace, which in term provides a faster time to market for new functionality (i.e. customer value).

The solving of technical debt may not contribute directly to an increase in customer value, but it will allow for a faster time to market in the future of new features and functionality, where the obstacles of technical debt are no longer in place.

I will be the first person to also mention that we shouldn’t only focus on improving code quality and solving technical debt, that will get boring pretty soon -from a developers perspective- and that we also should focus on innovation. But saying that solving technical debt and improving code quality have no customer value, is in my opinion not correct. I hope that with this letter I have provided a few arguments that will put your thoughts in a different perspective.

With kind regards,
A concerned developer/scrum master

Tagged with:

The world today is filled with people being connected all the time, sharing tweets, instagram photos and Facebook posts. I myself am also guilty of doing those things, and my iPhone practically doesn’t leave my side during the day. Being connected all the time has its advantages, but also the drawbacks.

What would happen when I simply stopped being connected to the whole world some time? A whole year offline might be a bit too much for me, like Paul Miller did, but intentionally putting my iPhone, iPad and laptop away for some time every day would not hurt, right? Do you have to be reachable all the time?

The first draft of this article was written on my iPhone, where my Baron Fig Confidant was also within arms reach .. what does that say about me? Guess that it was a bit easier to get this article started on my iPhone and to continue with it on another device, without having to copy my scribbles. But yeah, I sometimes think that I’m also quite attached to my phone, and that I should put it away much more often than I do now, but then I start reading ebooks on my iPad, and end up browsing the internet.

Using the iPad over a separate ereader + tablet was a conscious decision, maximizing the usability of one device. The way it is being used is the responsibility of the user, not the limitations of the device. Using the device with intent should be the mantra, and focus on what you planned to do. Writing on an iPad can be distraction free, due to the single screen and pre-iOS9 inability for splitscreen on the newer iPads, and so is reading also.

A few quick hints to help:
* Disable app notifications
* Enable do not disturb; on iOS this will allow for people to reach you in case of emergencies, though won’t distract you otherwise

Multitasking isn’t something we humans are good at, although there are exceptions of course. When having a dinner or a conversation with someone, shouldn’t you give that other person your full attention, instead of letting the bleeps on your phone take over priority?

Tagged with:

Being a software developer and scrum master at the same time is bound to have conflicting interests at times, even worse when a product owner is also a manager, but that’s for another time. At one moment you’re happily coding on a complex issue, requiring all your focus, and then a team member requires the help of the scrum master to solve something as he/she cannot continue with the task they’re working on.

Of course, you’re a scrum master first, so the team takes precedence over your own work. However, this does not mean that you alone need to work on solving the impediment, it is also your responsibility to educate and/or coach the team member in being able to solve things on their own.

Diverting your attention away from your own work, try to let the other person explain their problem and let them elaborate on what they’ve tried to solve it, and/or where the cause could be. In about half of the cases a solution has now presented itself in the persons mind, where for you as scrum master only required a bit of attention and patience. The other half of the cases are more complex, usually requiring actions of people outside your team.

Continuing in the path of the former half; this approach can be learned and taught to your team members, and even works when trying to explain your problem to a dummy. Exploring problems from different angles contributes to the way people approach them, letting them grow in their own right. Don’t expect this to be the silver bullet, it isn’t! This just helps your team members, and isn’t that the role of a scrum master?

Tagged with:

As our local development team has become a geographically distributed scrum development team, we were facing some challenges with regard to keep open communication channels between all members. Our idea to use a persistent chat channel soon emerged, and we were looking for tools.

If we lived now in the early 90s we would have chosen IRC as our tool of choice, though we are now in 2015, so we would have to find something else. My employer has employed Microsoft Lync as chat application, though the version we have doesn’t support persistent chat channels, therefore we as a team decided to move forward with Slack. Personally, I just liked the nice introduction video, thus had to give it a try :).

A few months later, we have a few developers in Spain and a few developers in the Netherlands, and we’re using Slack for both work related chats and non-work related nonsense ;). Adding new developers to our team meant also that we would have to update the email notifications in TFS for our continuous builds, and after a bit of brainstorming we decided we could improve.


Thus, a #build channel was soon created in Slack, together with an incoming webhook called ‘Bob’. It then took a bit of coding and testing to figure out how the incoming webhook worked, and eventually we created the code below. This notifies all developers about whether the last build passed all unit tests and integration tests, both the continuous builds as well as the nightly ones. We are planning to increase the scope of our nightly builds to also include full security scans, but for now the difference between continuous and nightly is the creation of a code coverage report. The latter is a real performance hog, therefore we decided it would be good enough to generate that once every 24 hours.

For the nitty-gritty integration to TFS; we’re calling a web service from the build definition in TFS to run the tests of our PHP code.

PHP code snippet used to show the Slack notification:

private function _notifySlackChannel($success)
$attachment = new stdClass();
$attachment->fallback = "Build tests ". ($success == true? "passed" : "failed") . " for last '" . $this->_testType . "' build";
$attachment->title    = "Last '" . $this->_testType . "' build " . ($success == true? "OK" : "failed" );
$attachment->text     = "Check <http://tfs_url/tfs/DefaultCollection/RoosterWeb/_build|build log> for more details";
$attachment->color    = $success == true? "good" : "danger" ;
$params = array(
    'payload' => json_encode(array('attachments' => array($attachment)))

$ch = curl_init("https://hooks.slack.com/services/something" );
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $params);

Tagged with: