dvrom.eu

Almost one year after jumping into the mac world, these are my must-have (free) apps for Mac OS X:

Just as easy as resizing images with mogrify…

1. Download and install GIMP

2. Open Image

3. Filters -> Light and Shadow -> Drop Shadow

Couldn’t be easier!

Simply:

1. Install ImageMagick

2. Setup the needed environment variables:

export MAGICK_HOME="/opt/local/var/ImageMagick-6.5.3"
export PATH="/opt/local/var/ImageMagick-6.5.3/bin:$PATH"
export DYLD_LIBRARY_PATH="/opt/local/var/ImageMagick-6.5.3/lib"

3. Resize:

bash-3.2$ /opt/local/bin/mogrify -resize 525x700 image.jpg

(NOTE: Overwrites image (does not create a new image))

If you like good, easy-reading and free knowledge like me, you will surely find taking a look at 97 Things Every Software Architect Should Know worthwhile.

Every software project is different, and has it’s own and unique needs, and as Edward Garson points out in Context is King:

“I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively there are no ideals. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.”

However:

“But alas, ceci n’est pas une pipe.”

I also believe that software engineering projects do share some common issues (or at least I hope for this, any morale booster is welcomed: software engineering is such a challenging discipline that despair is frequent !).

“97 Things” points out some topics and solutions that should probably be applicable for any software engineering endeavor.

There are some big names and many years of experience behind these tidbits of wisdom, and in my short career so far, I have found many of the described issues in “97 Things” in past and present projects.

Because 97 things are too much for my short term memory, these are the top 3 things to know that I strive to remember:

Michael Nygard is a professional programmer and architect with over 15 years experience, and also the author of “Release It! Design and Deploy Production-Ready Software”.

Having encountered this book on many “Top Books a Software Engineer Must Read” lists, I thought i’d give it a try.

This will not be a in-depth review, as there are already many out there, but rather a summary of ideas that will stay with me after this first read.

Michael’s book is all about the problematics related to successfully executing software systems in production, and although it is centered on high availability and large scale distributed systems, many of the discussed topics can be applied to any software system.

The book covers all the possible elements and layers of software engineering I can think of: management, delivery, testing, design, coding…, front-end, back-end, deployment, etc., and rather than trying to answer all the questions, it tries to point out the good direction in which to go.

This is certainly a book that I expect to come back to in the future, as the ideas and scenarios that will stay with me after this first read are only the ones which I can relate to, because I have encountered them in current and past projects.

1. Get a pair of Flickr API keys here

2. Write the code to invoke the REST url through curl, parse the xml, and transform the result into a nice array:

When I first discovered google search some time ago, one of the first queries I issued was “David Valcárcel Romeu”, that is, me.

Regardless of the reasons why one would want to know the degree of one’s internet presence, such as ego or curiosity, the idea has come to be quite a common practice, and several terms have even appeared to identify this trend.

New possibilities of querying the world wide web appear at almost the same frequency in which new ways to share information become available, and with the advance of the Semantic Web, it is incredibly easy to explore the web in different ways.

While thinking about this idea, I wondered if it would be possible to “self flickr” myself.

For example, thanks to the flickr API, it is possible to query the flickr photo base in innovative ways, such as integrating flickr content with a semantic web version of wikipedia.

As the moment of this writing, flickr has over 80 million geotagged photos.

I myself have a collection of photo’s that have been geotagged.

Could it be possible to find myself in someone else’s photo, somewhere in the background, inadvertently becoming part of the picture?

For each one of my photos, I created a link that allows to query flickr for photos that were taken at more or less the same time and at more or less the same place.

Timestamp and geolocation information is extracted from each photo, and used as search criteria for the flickr API call.

For the moment, I have not managed to find myself in somebody else’s photo, although results are surprising: some photos were taken at almost the same time and at almost the same place.

In theory, the possibility of finding myself should increase day by day, as users continue to embrace photo geotagging technologies.

Thinking ahead, it should be possible to include other photo sharing sites that offer querying APIs, and thinking even more ahead at a larger scale, one could even consider running queries continuously, and analyzing results with face detection applications for examples…

The question that remains is if all this is just some sort of egolized form of amusement à la Where’s Wally?, or if this and similar ideas is something to bring up next time you run in to some idea-searching VC’s…

System architecture, object design, build-release-test cycle definitions, tool configuration, coding…etc…

These are just some of the things that bring me back to software engineering in June, in my new company.

I consider myself to be extremely lucky to have worked with some exceptional technical and functional domain experts as a Technical Consultant for one of the world’s private banking software solution leaders, in one of the banking capitals of Europe for the past year and a half.

Being able to harvest knowledge from hardened veterans who have been in the trenches for years has certainly given me a good understanding on how things work in the Private, Retail and Core Banking world.

I must say though, that going from codebase and development junkie to functional and technical product evangelist was quite a revealing experience.

As a developer, I had always seen the consultants with whom I had worked with from a skeptic dilbertesque point of view: the fancy suits, the nice cars and the expensive hotels already created an important distance before even starting to work together.

There are many stories out there about the mystical Consultant that appears in a messiah manner to save the souls of the doomed project: whether it be with magic wordings, sacred vendor-specific knowledge or just pointing out the obvious, their presence is almost always mysterious and ethereal.

The mysterious aura surrounding consultants tends to exaggerate their performance: good consultants will be remembered as wizards with efficient problem solving techniques, while others will be remembered like the strange guy who nobody knew and just wandered around all day.

Having worked on the past as a developer taming one certain beast, I was often frustrated when one of the beast’s consultants could not answer some of my questions.

After being on the other side, I now see that probably the most important virtue of a vendor specific consultant is not what he /she knows, but rather what he / she can find out: the consultant will probably be your best link to the developers behind the product, and the key to the knowledge you are looking for.

So next time your are face to face with one of theses mysterious vendor consultants, remember to throttle frustration if your answers are not given to you on the spot, and instead be patient for the information to be collected by your only link to the products core…

One of the first projects I worked on has finally been replaced and gone to wherever dead code goes…

Looking back now, this extremely simple CMS was one of the most successful projects I have ever worked on so far, in terms of longevity (it was in production for the past 5 years) and user feedback.

It is also probably the simplest solution I ever worked on (no complicated development processes, no clever code, no pattern abuse…) and it reminds me of a quote I remember reading once that was somewhere on the lines of:

I would probably rephrase this statement to:

In the same sense, I would also state:

My quick exposure to the vast world of J2EE, ORM Frameworks, Enterprise Patterns, the Java API, Web Frameworks and other candidates for abuse in the projects that followed this simple CMS, combined with my “bring it on!” rookie prepotency, led to some ugly code and some terrible over-engineering…

Not only wisdom, but also ignorance, can sometimes produce the best results…

Stress testing, Load testing, Performance testing, Capacity testing…they all are based on the same idea:

• Software systems are usually built to be used, and chances are that, at one point or another, you will want to know how your system reacts on heavy loads, and, in case the results are not satisfactory, you will want to improve the systems performance.

A first question arises:

Should it be done at some particular phase or should it be triggered by some specific requirement?