Thursday, July 19, 2012

Command line script to batch convert images

Ever had a folder full of images that you needed to convert? Well, today I had a couple hundred 20Mb RAW images that I wanted to convert to JPG, and I really didn't want to open them on an image editor.

So I went hunting for a way to convert the images using the command line on the Mac. Here's what I found:

1. Converting an image via command line: There's a tool called "sips" that does this (and much more) on the mac! To convert a file from RAW to JPG, you just need to call something like:

sips -s format jpeg IMAGE.NEF --out IMAGE.jpg

2. Getting the right name: Iterating a list of files via command line is easy, getting just the filename in order to change the extension requires google! Here's how to do it:

for i in *.NEF; do echo "${i%.*}.jpg"; done

(curious on how it works? Check this doc)

3. All together now: To convert all the files in the current directory, do this:

for i in *.NEF; do sips -s format jpeg $i --out "${i%.*}.jpg"; done

Let me know how the script worked out for you!

Sunday, May 20, 2012

Moving from iPhoto to Lightroom

I've been using iPhoto since I bought my mac, but lately it seems to be getting slower and buggier... Takes ages to launch, search doesn't work properly, and my library of about 25,000 photos seems too much for it. So I decided to try Lightroom.

Unfortunately, there's no easy way to get out of iPhoto, be it for Lightroom, Picasa, or whatever... There's no simple way to export all of your events into nice subfolders! So I built my own way out!

I created a python script that reads the data from iPhoto, and uses it to create a tree structure with year/name_of_event and all the photos inside. Here's a screenshot of the script running:


To use the script, download it from here, and execute it via the terminal using:

python iphoto-to-folders.py [AlbumData.xml] [destinationDir]

[AlbumData.xml] is a file inside your iPhoto library, and can usually be located at ~/Pictures/iPhoto\ Library/AlbumData.xml

[destinationDir] is the folder where you want your photos to be copied to.

A couple of notes about the script:

  • It only copies the original versions of the photos. Changes you made in iPhoto are not copied.
  • It copies all the files from your iPhoto library, so it needs quite a bit of disk space.
  • It may take some time to run. To copy my 25.000 photos it took 1.5 hours
  • It's not supposed to mess with your iPhoto library, but do make backups!
  • It has no warranty whatsoever!
  • It's supposed to be tweaked! If you're comfortable with python, adapt the script to your needs.
If you have any questions or spot some problems, please submit them here. And be sure to leave a comment telling me how the script worked for you!

Wednesday, March 21, 2012

Delay your project, protect your future


One of the dangers of Agile is that teams are so busy sprinting and delivering potentially shippable projects, that they forget to invest in becoming more productive in the future.

Let's use some basic economics to illustrate this problem.  Assume your team has a top productivity of X. It doesn't matter the unit you pick - story points per iteration, function points per month -  but let's assume your team cannot produce more than X.


Now, one of the things you can do with productivity is move it around. For instance, google allows employees to invest part of their work week on pet projects. So if we put that on a vertical axis, we get something like this:


This curve is called a Production Possibility Frontier, or PPF, and it represents your team's limit in terms of productivity. This means the only way you'll make your team more productive is by moving the PPF! And the way to achieve this is through investment.

You may argue that google pet projects are an investment, but what I mean is direct investment in improving productivity. For instance, you could invest in improving your QA infrastructure, so that developers don't spend so much time building and fixing tests. Or you could invest in tools to improve your overall capacity to deliver, like the OutSystems' Agile Platform. (disclaimer, I work for OutSystems! ;).

When you do this type of investment, the end result is that you move the PPF to the right, therefore increasing your team's capacity to deliver.


Easy, right? So why isn't everybody doing these investments and increasing their productivity? Why do we meet so many inefficient teams and R&D departments?

Turns out there is a catch. These improvements are not continuous, and work in leaps. This means you need to go all the way to see the results of your investment. If you study a new tool for a couple of weeks and stop the investigation before something actionable comes out of the study, you're just throwing your time and money out the window...

But guess what happens as soon as a the project stars to slip? We choose the short term solution, and increase the productivity of the team at the expense of our investment.

Standing up to your stakeholders and delaying a milestone to protect your future is the hard part in making your team more productive. And I hope this short post gives you a bit of ammunition to go in the right direction! :)

Tuesday, February 21, 2012

Why developers suck at UI design

Yesterday I was listening to this podcast from Boagworld  dedicated to the dangers of "what if" design. The basic idea is that you shouldn't let exceptions hinder the experience of the majority. I.e. if something happens once in a blue moon, you shouldn't compromise your UI design because of it.

At a certain point he alerts for the fact that developers tend to make this mistake because developers are worried about edge cases - "what if the connection to the database is broken", "what if the user isn't logged in". I agree with this, and I believe this is one of the reasons developers tend to make interfaces that are overly complicated for the common use case.

The solution seems easy, right? Developers need to take a step back from their work, look at the user-stories they captured from their users, make the most used features really obvious, and hide the rest of the clutter.

Well, nothing fundamentally wrong with this approach. I believe developers must deliver the best possible interface they can, and that requires effort and training. But I don't believe this is enough.

The problem is, when you dive as deep as a developer does on the project, it's very hard to step back and take a look at the big picture. What developers really need to do is get someone from the outside to spot the obvious errors that are just too evident to be seen by someone buried in the nitty gritty details of a project.

Again, this sounds like a simple enough solution. After all, getting someone to comment on your work isn't really hard, is it? Specially if it's about design! But the problem is that most developers don't know how to listen or how to act on the feedback they receive. It's the "what if" problem again... it's really easy to dismiss feedback based on edge conditions that happen 1% of the time. (This makes a great topic for another blog post, and I urge you to write it!)

In the meantime, no time like the present to become better at UX design. Here's an interesting webinar with "6 steps to engineering awesome user interfaces". Have fun!
(disclaimer: this is a webinar recorded by me for OutSystems, the company I work for)