Studio shots

We started out in my apartment, which I had converted into a small studio for the occasion, and tried to mimic some old-style portraits. Here’s an example (click for larger version):

Mimi did all the hair, the makeup and the posing, while I wielded the light and technology. A background kit and two softboxes was all it took, and I think it turned out pretty well

Turning day into night

For the second part, I wanted to try to create some dark and spooky forest pictures, and thought Mimi’s fair skin would be a perfect elvish contrast to a gloomy forest (how’s that for adjectives!). She was on to the idea right away, and managed to find someone who knew a woman, through Facebook, with a wolf-like Siberian Husky that we could “borrow” for the shoot. She also almost rented a stuffed raven, but since none of us were sure if the “wolf” would see the stuffed raven as an irresistible chew-toy, we decided to skip it (this time).

Now the only problem was how to create a dark and gloomy forest from a sunny day. What I ended up doing was

1. Set the cameras white balance to tungsten (about 3200K). This turned the warm daylight into a cool blue
2. Under-exposed the background, with the camera on manual, to get a darker, blue, night-like setting
3. Attached two flashes (strobes/speedlites) to a tripod, and covered them with an orange film (for the strobists: I gelled it with a 1/2 CTO). The flashes were now giving orange light, which looked white to the camera, since it’s white balance was set to tungsten
4. Set the flashes to high-speed sync mode. This was necessary to get them to light the scene properly, with the fast shutter speeds needed by the camera to under-expose the background (a typical shot was taken af f/4 and 1/1000s)

Here’s an example of how this works. First off, a picture as it would have probably have looked if I used the camera on automatic (with a ‘daylight’ white balance). Click the image for a larger version:

Step 1 - daylight white balance

This is what happens when I set the white balance to tungsten, and underexposed the scene:

Step 2 - tungsten white-balance and underexposure

Next step was to add the flashes (with the orange ‘gels’), which now look white to the camera and voila – something that looks a bit more like a moonlit forest:

Step 3+4 - Gelled flashed

And here is the final version, with a bit more tweaking to make it more dramatic:

Final version

For the shoot Karina and a friend showed up with 3 dogs, including Aqui the Siberian Husky we would use for “wolf”. She did a great job at keeping him in place, even though he was distracted by the occasional mouse or lizard rummaging through the forest bed. Here are some more of the shots we got out of it (click for large):

Thanks

Finally I want to Mimi for being so much fun to work with, and for being so patient, despite the not-so-comfortable spots I made her sit. Also a huge thanks to Karina Tollundgaard for letting us use Aqui, and for helping us out by keeping him in front of the camera.

And after an eventful day we strolled off into the sunset.

The local show team also performed at the friday night party. Here’s a video of our performance:

…and here are some pictures from the event:

I continue to be impressed with the low-light performance of both the 7D and the 24L, and although not all of the pics are sharp, many of them would have been impossible without this combo. I’m loving it

I waited a long time to get my hands on the Canon EF 24mm f/1.4L II lens. Back in december 2008, I wrote a small ruby script to help me determine what focal lengths I favored, and concluded that this particular lens would be the perfect match for my EOS 50D, for low-light photography. I still hadn’t managed to turn up the funds for one when The Digital Picture published a glowing review of it a couple of months later, but later that year I gutted my piggy bank, and finally received the lens after waiting in a back-order queue for 5 weeks.

Now, after using the lens for some months, I wanted to share my impressions with you, the internet. I won’t go into nearly as much detail as the DP review, and if you’re interested in this lens I’m sure you’ve already read it (you should), but instead focus on my impressions of using it on a APS-C camera, specifically the EOS 50D, since I haven’t found many reviews covering that aspect.

I don’t own many L-series lenses, and no L-series primes, and before the 24mm II my favourite lens was the fabulous EF-S 17-55mm f/2.8 IS, which I loved for it’s low-light capabilities. Now, my favorite lens on the 50D is the 24mm II, because of it’s outstanding image quality, combined with a 38mm equivalent field of view, and an impressive maximum aperture of f/1.4.

Image quality

I am continually impressed with the image quality of this lens. It’s way better than the 17-55mm f/2.8 IS, which was already good, with wonderfully saturated colors, outstanding sharpness even wide open(!), and negligible chromatic aberration. If you manage to get the focus right, even f/1.4 will be sharp. The photo below is an example of that, though perhaps not a work of art in itself

Landscape photography is not my area of expertise, but one thing I have noticed, is that the lens controls flare very well, as you can see from the image below, and some of the samples, where the sun is in the scene.

Other reviews will have more details and charts for you, as well as more basis for comparison, so let it suffice to say that the image quality of the 24mm II has impressed me, compared to the other I own, notably the 17-55mm f/2.8 IS, 70-200mm f/4 IS and 50mm f/1.4.

38mm equiv. field of view (on an aps-c camera)

It’s not easy to find fast primes that are wide on an APS-C camera, such as the 50D/40D/500D/7D, and the 50mm f/1.4 has always been a bit too narrow for my style of shooting, as I like to get a lot of context in my shots, and often shoot indoors in close-quarters, which makes 80mm equiv. unpractical.

The field of view (FOV) took a bit of getting used to, and the fact that it is a prime means I’ve been getting more exercise running around, but I absolutely love it. I have to get closer to fill the foreground, but the wide angle can create some very dynamic and engaging compositions, where you really are “in” the scene you’re photographing. It allows me to get a lot of context into the shot, while still separating the foreground from the background, further aided by the low depth of field enabled by the large aperture.

Images taken with the 24mm II up-close and wide-open get a distinct “feel”, which I suppose is because it’s unusual to see images with low depth-of-field taken with a wide lens.

Large f/1.4 aperture

One of the major “features” I was looking for in a fast prime, to supplement my already-excellent-for-low-light-shots 17-55 f/2.8 IS, was a large aperture. I was expecting a marginally more “handholdable” lens, for indoor shots, with much better bokeh.

In my experience, the 24mm II is not significantly more “handholdable”, because although it has a two-stop advantage over the 17-55, the latter sports an image stabilizer which promises 3-stop stabilization. I don’t have any hard statistical data, but my “feeling” is that this pretty much levels the playingfield between these two lenses, at least where stationary objects are concerned. For moving targets, the 24mm II should theoretically have the advantage, since the larger aperture enables faster shutter speeds. However, I do a lot of dance photography, and for this purpose, IQ aside, the 24mm II’s f/1.4 aperture doesn’t really help: It has proven to be extraordinarily difficult to accurately focus on anything moving (such as dancers), with the shallow depth of field at f/1.4. In short, image quality may be better, and f/1.4 may enable faster shutter speeds, but good luck focusing on anything that moves.

If I was slightly disappointed with the 24mm as a replacement for my “dance lens”, which isn’t really a fault of the lens, as much as my own expectations, the bokeh rendered by the 24mm II is a thing of beauty. If you can control it, you will get beautifully smooth out-of-focus backgrounds and foregrounds. It’s addictive

All-in-all…

…this is a wonderful lens on a APS-C crop camera, such as the 50D. The field of view is approximately equivalent to a 35mm lens on a full-frame camera, and as one of canon’s newest L-lenses, the image quality is unmatched at this focal length. It’s expensive, but I’m inclined to think this is a case of you-get-what-you-pay-for.

I think this focal length is good as a walk-around lens on a crop-camera, and the bokeh combined with the wide FOV, makes for some really unique shots. I have especially loved it for environmental portraits because of the FOV and shallow depth-of-field, as the sample pictures demonstrate.

I hope you’ve found this useful, and feel free to ask questions if there’s anything you feel I’ve left out. I’ll try my best to answer. Enjoy the samples, or check out my images on Flickr tagged with this lens.

With 60 out of 140 dancers from outside Denmark, there were a lot of very pleasant surprises, and a big thanks goes out to all of you who came, and the people who helped stage this event. Here are some snapshots from the Saturday night Jack’n'Jill competition, and social dancing.

Me at Øredev

I was fortunate to get to go to Øredev 2009 last week, and wanted to share a couple of impressions with you. The picture on the left is me with my Øredev passport, after a very large espresso from one of the Oracle-sponsored baristas.

Øredev is a developer conference held each year in Malmö. This years’ event took place between November 4^th and 6^th. It is not a technology-specific event, but covers a wide range of topics such as .Net, Java, Agile ways, testing, project management, and web/cloud/mobile development. Talks range from concrete hands-on topics such as how to work with a specific technology, to more theoretical subjects on software development and computer science. Speakers are brought in from around the world, and include prominent figures such as Jeff Sutherland (“father” of Scrum), Cameron Purdy (Vice President of Development at Oracle), Dan North (agile thinker and consultant at ThoughtWorks), James Coplien (agile development and consulting guru) and Trygve Reenskaug (OO guru and “father” of the MVC pattern).

Øredev 2009 conference map showing tracks

I think this mix is what makes the conference so interesting – you can discuss the nitty gritty details of your favorite framework with likeminded peers over a cup of coffee  in the morning and discuss paradigms of software development with someone else with your afternoon tea, regardless of what technology they usually work with.

Over the course of 3 days I attended 18 talks and 4 keynotes, which again was only a small part of what the conference offered. The following are some of the things that caught my attention, in words and images, and admittedly not an attempt at “fair” coverage. If your favorite topic is missing, wait for the videos to come online at http://www.oredev.org/, or even better – go see for yourself next year!

Efficiency vs. effectiveness

Maybe the best coffee at any conference?

The theme this year was efficiency, and several of the keynotes and talks pointed out why it’s important to differentiate between efficiency and effectiveness. While efficiency is concerned with how fast or well you can perform any specific task or sub-goal, effectiveness is concerned with how that contributes to reaching an overall goal. They argued that while many of the practices used in agile methods such as Scrum and XP can make us good at “local” efficiency, it doesn’t help if we’re busy building the wrong things, or have a bottleneck somewhere else in the value chain.

It seems part of the current trend among agile thinkers is finding ways to supplement the software development practices from Scrum, XP and other agile methods with core concepts from Lean development, thereby emphasizing not just doing, but also thinking, and not just local efficiency but effectiveness towards the overall goal and value chain. As part of his “Why your agile rollout is failing”, Dan North from ThoughtWorks had a really good phrase summarizing why we need to introduce some systems thinking/theory into software development to create lasting change, instead of focusing narrowly on individual practices: “A bad system will beat a good person every time”, meaning that no matter how much any single person tries, he will always fail if the system around him is bad. So much to learn – so few hours in the day

DCI – the paradigm to replace Object Oriented Programming?

One of the most interesting sessions at the conference, was what may turn out to be the biggest change in the foundations of software development since OOP (object oriented programming) was introduced. It was a series of talks by Trygve Reenskaug and James O. Coplien, discussing a concept they call DCI Architecture (DCI stands for Data-Context-Interaction, but we’ll get back to that in a minute). I will try to explain it as well as I can, but if you’re interested, or just don’t understand what all the fuss is about, I suggest you read a couple of the articles I link to in the end of this section.

Trygve Reenskaug, from the University of Oslo, is a veteran in software development. As visiting scientist at the Xerox Palo Alto Research Laboratory, he was involved in the development of the Smalltalk programming language, and among other things coined the Model-View-Controller (MVC) pattern in 1978. He has spent the last several years trying to change the way we do model and program software.

Trygve Reenskaug and James Coplien argue that what we have come to know as OOP is not actually object oriented programming, but class oriented programming (a distinction you may start hearing around the Internet), and that it is a poor way to model the users’ mental model of the domain.

Classic OOP is all about objects, but what we’re actually writing are classes. Classes are good at describing the structure of data, but this is not the only thing interesting to the users of the software services we develop: We’re also interested in interactions, such as algorithms and business rules.

Most main-stream programming languages offer no special language construct for interactions, that is, collaborations between objects. They don’t capture algorithms that flow over those collaborations. Instead the interactions of a “use case” or algorithm often get spread across a number of classes, so that you cannot find a cohesive representation of them in code. There is no natural place for the algorithms and business rules to “live” – they are not a first-class citizen – and so they easily become fragmented, and hard to communicate, review and verify.

It turns out that the inability to express interactions severely hinders our ability to reason about the quality and effectiveness of the software we develop:

“Back in the 1960s, we could take the behavioral requirements for a program, and the FORTRAN code that implemented them, and give both of them to an office mate—together with a big red pen—to review whether the code matched the requirements. The overall form of the code reflected the form of the requirements. In 1967, software engineering took away my ability to do this: the algorithm had to be distributed across the objects, because to have a large method that represented an entire algorithm was believed to not be a “pure” object-oriented design. […] That works fine when an algorithm lives within a single object, as might be true for changing the color of a circle on the screen, or adding a typed character to a word processor’s text buffer. However, interesting business functionality often cuts across objects. […] Object-orientation pushed us into a world where we had to split up the algorithm and distribute it across several objects, doing the best piecemeal job that we could.” (from http://www.artima.com/articles/dci_vision.html)

So in order to better express and communicate interactions in code, DCI aims to make interactions a first-class citizen, just like classes. Like the MVC pattern separates concerns between components when building applications with user interfaces, the DCI architecture separates concerns between data and business rules. Another way to describe it is that DCI tries to close the gap between the end users mental model and the way the programmer describes it in code, in order to more easily build the software services that the users need, and facilitate communication and reasoning about them.

The key concepts in DCI are:

Data – this is expressed in terms of classes, but these classes should be dumb. They should express structure, but not behavior. Classes capture what objects are.

Context – can be thought of as a use case. It sets up the pieces we need for the interaction, meaning live objects based on our classes, and assigns them the roles (behavior) that we want them to perform. The roles are assigned on a per-use-case basis, so the same object can participate in different roles and use cases during its lifetime.

Interaction – describes end-user algorithms in terms of roles. Roles capture what objects do. At runtime, classes and roles are combined into objects as needed by the context (use cases). This idea takes a little getting used to, because most mainstream programming languages today are not good at expressing roles separately from classes.

The important thing is that the roles objects “play” are expressed separately from the classes defining data. This makes it easier to reason about an algorithm or interaction, because it is expressed as a unit, separate from the classes of participating objects, and separate from other interactions that the objects may take part in. In other words: Interactions are expressed cohesively, not fragmented across a number of classes.

As mentioned, most mainstream programming languages do not make it easy to express roles, and inject them into objects at runtime. In some languages such as Ruby and Scala, however, it is straightforward. Check out the references for examples in C++, Scala and Smalltalk.

The inventors of DCI, Trygve Reenskaug and James Coplien, together with Rickard Öberg working on related concepts in Qi4J in Java

References

Trygve Reenskaug and James Coplien can explain the concepts better than me, so if you think this was interesting, I encourage you to read more. These links should be a good start:

http://www.gertrudandcope.com-a.googlepages.com/thedciarchitecture

http://www.artima.com/articles/dci_vision.html

http://www.infoq.com/news/2009/05/dci-coplien-reenskau

UPDATE: There’s also a google group dedicated to DCI, with discussions and source code examples in various languages, such as Ruby, Javascript and Python:

http://groups.google.com/group/object-composition

ASP.Net 4 and MVC

There were a lot of talks on the .Net track about Microsoft’s newest web-framework “ASP.NET MVC”. ASP.NET MVC is a fully-supported alternative to ASP.NET WebForms (what people typically think of when they say .Net), and have generated a lot of interest in the developer community from people who didn’t like the programming model that WebForms built on top of the basic web application technologies such as HTTP and HTML. The framework is built on the model-view-controller pattern, and Microsoft makes no attempt to hide that it is heavily inspired by Ruby on Rails.

I’ve had the opportunity to work with ASP.NET MVC for the past 4-5 months, and I much prefer it to WebForms for a number of reasons: It is much easier to test, it provides clear separation of concerns (courtesy of the MVC pattern), and instead of abstracting away the details of HTML and HTTP that a developer needs to build modern web apps with AJAX, it provides a set of useful conventions, but with full developer control over page flow and markup.

Microsoft is working hard on the next version of their MVC framework, version 2, and appears to be really committed to it. What’s interesting is also that the next version of ASP.NET, ASP.NET 4, will include a number of changes to WebForms inspired by the feedback they have gotten on MVC. It will now be possible to regain full control over the markup and element id’s generated by WebForms (finally!), and it will be possible to disable ViewState on a page-wide basis. ViewState genocide is now an attainable option… ready….set….GO!

Oh yeah, and they’re now bundling the jQuery javascript library by default, instead of their own proprietary version. Three cheers for OpenSource!

Other notes

Scott Hanselman speaking on effectiveness

Neal Ford, author of The Productive Programmer had a lot of good tips for individual-developer-level-productivity. If you’re interested in that kind of stuff, you can check out his website where there are a lot of slides, tools and links. On a similar note, Scott Hanselman, Principal Program Manager at Microsoft, gave a talk about personal effectiveness, and recommended a couple of tools including Evernote for keeping notes synchronized across multiple platforms and with the ability to search within images files (it works!). He also mentioned a tool for knowledge workers called RescueTime, which automatically monitors what you do on your computer, allowing you to see when you are spending time on distracting activities. You can find more info on Scott’s blog.

Neal Ford also gave a talk comparing JRuby (a Ruby interpreter running on the JVM) and Groovy (a dynamic language similar to Ruby but with stronger ties to Java). His main message was that they were more similar than different, and that the community should try to avoid another unconstructive “Emacs vs. vi”-style war.

Thanks for reading

Well, that’s it. Hope you found it interesting. Sharing is caring

I’ll be exhibiting mostly dance related photographs from 2009, but I’ll also bring a larger flip-through catalog with other material.

If you’re interested, please stop by between 15 and 18 on Sunday, October 11th, and feel free to bring your friends along The café will be open, and there will be a live jam for dancing. Here’s a link to the event on Facebook:

http://www.facebook.com/event.php?eid=147524757519&ref=nf

Should you be taken by any of the photos in particular, and would like to hang them on your wall, I have prints and frames for sale at reasonable prices.

If you have, check out the Canon Camera Museum, where they have a cool little tour of how a EF 500mm f/4L  IS USM lens is manufactured, all the way from mixing the raw materials that makes up the lens elements, to final assembly.

I think it’s pretty cool