Graphical tips for the average coder

I am not a front-end guy and surely not a web designer, but I promised myself not to avoid amateurial graphical work on occasion. While doing photomontages and altering images such as photos and movie posters, I learned some basic techniques and I now take great advantage of the editor's tools. I want to share these insights with the average programmer, who like me has seldom used a graphics editor and is scared by design work.

Selection is underrated in the minds of us programmers. Rectangular, circular, magic wand selections and similar tools are very sophisticate and composable: addition, subtraction and inversion of selections are the norm in a graphic's workflow. Selecting the right part of an image is fundamental for rendering the effects you want to apply, such as brush strokes, gaussian blur or even a bucket fill, to the correct zone instead of spreading them all over the image.

Working at an high zoom level - from 200% to 300% - gives you the opportunity for fine surgery. I guess this is why graphic designers have giant monitors, besides for fitting all the toolbars from Photoshop or GIMP on a single virtual desktop. Even when having an enlarged main view, you can always open another small view at a realistic scale to always have a glance at the overall picture.

Layers are the bread and butter of image editing, and every decent editor lets you modify, show and merge them independently, and combining layers of different sizes and positions in a unique image. If you are a web developer, I'm sure you have worked with CSS and the box model, so the concept of layering won't be a novelty. I store graphical works in the XCF format, which is the GIMP native format akin of the widely known PSD: both allow layers to be kept separately instead of being rasterized together in a JPEG or PNG. The separation of XCF from JPEG or PNG can be think of as the equivalent of source code and binaries: when you start playing with the source code you are transforming from an user to a programmer.

Transparency, often in the form of an alpha channel, is the glue that allows the composition of rectangular layers. Technically speaking, the alpha channel occupies 8 of the 32 bit of the color space, so that every pixel can specify its red, green and blue content with a total of 24 bits, but also its transparency (or by converse its opacity) to the point of being completely invisible.

Finally, another tool I find very useful in my pixel-obsessed, mathematical weltanschauung of image editing is the guide and the automatic snap of selections and layers to them or to the image borders. I simply cannot produce a decent work without setting up guides to attach layers to. I have not a perfectly steady hand while moving a mouse, which is not a precision device, but the combination of zoom and snaps lets me work like I was playing with Lego bricks or with my good old classes and objects.

How I learned to stop worrying and love new words

Because of the subject of my Bachelor's degree thesis, I am currently busy learning more and more about Java technologies, in particular the OSGi specification and the frameworks that implement it.
In the past, I saw articles about OSGi passing in DZone's feeds, and never cared much about it. It's possible and desiderable to avoid contact with many technologies we are not considering for right now: somehow we have to limit the amount of new information in our self-improvement process to the actually useful fields.
However, the thesis subject (audio and video search) is interesting but it involves a large amount of Java technology, in particular a framework built on top of the OSGi model. Here comes the pain: I did not know what OSGi was at all. Instead of continue worrying about it, I decided to dive into OSGi and I'd like to recall my steps here so that you can decide to take a similar journey on an argument that you are required to know.

Step 1: Wikipedia
Wikipedia is the starting point of most of my researches, even if it is not 100% reliable as every community-crafted content is. Wikipedia took me from an empty word (OSGi) to a definition:

The OSGi framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments.

Moreover, well-written Wikipedia articles have many internal links to related material, both in the page body and in the See also section. Every new term you encounter usually points to its own definition, a scenery that can lead to a tab explosion but also to deep knowledge.

Step 2: define concepts in your own terms
I quickly discovered that OSGi applications are composed of bundles. The bundle term is part of the Ubiquitous Language of OSGi, but I did not know an exact definition. When you are doing a panoramic of a technology, it's useful to start with a good approximation which uses already grasped concepts:

OSGi bundles are particula JARs which includes some metadata files along with the hyerarchically organized .class files that contain the bytecode. Bundles export or import Java packages they respectively provide or require.

This is an approximation, since JARs and bundles do not strictly overlap. But it is a good one and let me abstract away most of the bundle internal organization for a while.

Step 3: resources to learn more

• Google is often the best friend of a developer (as the GIYF acronym correctly says.) You can look for tutorials, but also for particular frequently asked questions.
• Books on the subject, particularly if they contain good code samples, are the best road to a deep understanding of the technology. However they may not be the right material if you're only looking for a crash course.
• YouTube videos are instead highly distilled knowledge, and the equivalent of a crash course. A 1-hour long talk can teach you very much about the assumptions and the usage of a framework like OSGi without effort: you just need to listen to the speaker.
• also a search on Wikimedia Commons will bring you a lot of diagrams about your preferred technology (example), used throughout all the Wikimedia Foundation wikis.

Step 4: practice
My first practising step was producing an OSGi bundle and deploying it in an OSGi framework. I've done it even before step 3 because I like to get a walking skeleton as soon as possible, but I've gone reviewing my code once I had learned a larger part of the theory. Getting a running example is always a confidence booster however, even if you are copying much of the code without knowing its meaning.

The same learning process is going on for me for other material I'm using in the thesis, such as BPEL and the SMILA framework. While there may be aliens with genetic memories, you shouldn't be afraid of new concepts: everything you know was learnt at some point in your life.

Programming Cone of Experience

The Cone of Experience is a model formulated by the educationist Edgar Dale in which he summarized the various learning media and their effectiveness. Like every model, it has limits and should be adapted to your personal vision, but since learning is something a good developer does every day to improve himself, having a methodology for acquiring new knowledge is fairly essential.

The Cone shows different activities in crescent order of memory retention. People are generally able to remember more things if they are learning trough the lower and larger layers and less if they are working in one of the top and thin ones. We will show an example of a developer learning Test-Driven Development and good software design, comparing different layers of the cone. There are many examples of phrases like "People remember 10% of what they read, 20% of what they see, ... 90% of what they do", but these numbers are totally made up and there are no quantifications in Dale's original work.
However, this is the Cone:

Let's analyze the different way a developer can learn a new technology or practice, such as TDD. We will start from the less powerful experiences and descend towards the end of the cone where the experiences have a great effect on the human memory and we are less prone to forget and confuse informations.
I want to learn TDD, so what I can do?

• I read a book. However, reading one, two or ten books does not make me an expert on TDD or software design, and if I don't refresh my knowledge often I will probably forget everything but Red-Green-Refactor.
  
• If the book has nice figures, they will improve my understanding and I will be able to remember at a glance different concepts that fit together in a single picture.
• I listen to a podcast or see a video of Misko Hevery doing a talk at Google. This is more impressive for the brain and typically will have a longer-lasting effect on me than reading a book.
• If I see him writing code in real time, the experience is even best.
• The next step is simulating a real world situation by writing code for a toy project. This is also probably the last step we can make.
  
• The final step is real experience: TDD some classes for my preferred application and analyze the results, then start again. The real experience is often not available for learning, or it presents some restrictions, fortunately: think of surgeon that practices on human beings. He must gather real world experience, but he is under the strict control of senior colleagues for years.

So suppose you want to learn TDD or the new technology. What you should do? Skim a book of course, to know the theory. But don't stop here: write code snippets, compile real code, work on a small project you can afford to throw away. If you have the time and the money to invest, go to a conference where in one hour the speaker will give you a general knowledge of the subject.
If is it available, a live coding session is the best thing to start with a new technology or language. That's why in university's exercise sessions and laboratories we learn much more what we would do while staring at a professor. Taking notes is a step further down in the Cone of Experience, but if you are missing pieces because you are too busy writing down everything to bother listening to the professor, it is not an improvement.

The hello world applications presented by many frameworks are not meant for being simply read. They are made for being compiled and hacked. The usefulness of a hello world program resides in helping you setting up the environment and the tools to build the simplest application - the one that does nothing. By experiencing the steps needed to build such a small binary, you start to grasp how to work with the new technology.
First-hand experience is the most powerful learning tool for the majority of people in the world and we should give it the right priority.

The value of knowledge and what we should learn

In one of my last posts, I suggested to learn math topics as they will be propedeutic and complementary to programming challenges. I think we can gain useful knowledge and overkill knowledge while learning. I will present a story to fix ideas. I am sure you already heard this story, and now we will analyze it from several different points of view.
This famous anecdote goes more or less like this:

The printing machine of a famous newspaper had started to malfunction. Several technicians were called to find where the failure was, but even after a while no one was able to identify what component needed a fix.
So, the newspaper owner called the printer who had worked for many years at the now-broken press, who was at the time retired.
After he had arrived, he looked at the press and at its control panel for some minutes, then picked up a screwdriver to slighty turn a screw. He said "Now the press will do its job."
Incredibly, the press started to work again, and the worker was thanked and asked for a bill for his services.
The day after, the bill arrived and it was for 10000 dollars! The owner cannot believe the worker had had the gut to ask all that money for one minute of work, and sent back the invoice asking for a more detailed report.
A new bill came the next day:
- $ 1.00 for turning a screw
- $ 9999.00 for knowing which screw to turn

This (totally made up I guess) story shows us the value of knowledge. If you substitute screw with line of code and turn with tweak, you will obtain a perfect programming story. This is because there is really nothing about printing in this anecdote, but only a marketing lesson:

• If you spend time to learn valuable [programming] knowledge, you can be paid a large amount of money. Obvious, but the problem is finding the disciplines which are not at risk of obsolescence: a doctor for example spends many years in education which very rarely becomes obsolete, and he is very well-paid troughout his career. The worker has previously spent many years on the press, gaining an enormous insight of how it worked and how to fix every kind of fault. Knowing how to fix a little, replaceable machine or other sacrificeable tools is not so useful knowledge in this context, just like knowing how to repair a motherboard with a soldering iron.
• You have to market yourself: the newspaper owner knows that calling the retired printer could be the way to fix his machine. If no one knows about your special capabilities, it is difficult that someone will be willing to pay you much. Fortunately, the World Wide Web is now the best showcase you could desire: under the right conditions, billions of people can find you easily, in a matter of seconds.
• If your knowledge is useful but not so diffused, the supply and demand laws permits you to charge more: the worker was probably the only one in the city that could fix the press. For example, if the market is saturated with Java basic developers, you may have an hard time finding projects which fall in your skills range. The more specific your capabilities are, the more sought-after you are, provided that there is enough demand for you to make a living: becoming an expert in Sothern Australia butterflies is not what I would suggest.

What have I learned this year? New languages, frameworks, practices? Is my previous knowledge becoming obsolete in the meantime? What valuable things do I know?
These are questions that I ask to myself before starting a new craft, such as learning Erlang. I mean, it is an interesting language and it is fun to play with, but how much am I likely to utilize it in web applications, given that I currently focus on php? I would rather deepen my Zend Framework know-how to be able to tackle more large and rewarding php projects. To be complete, I should also sharpen complementary skills as web design even if I am usually the backend guy. Disciplines which reside next to my main one give me a greater understanding of the overall picture: knowing what a designer works with helps me to communicate with him and to refine my job to perfectly match his.

Learning new things is important to keep an active mind and to feed it with new patterns and experiences. It is a self-improvement task, and in no way I am saying you should focus on work-related topics only. Just make a selection to keep out obsolete ones and to ensecure you are not forgetting the important disciplines before writing Erlang code. And if you have fun with Erlang, just practice with it! Maybe you will find a use for it in the future. The trick is not to think you are updating yourself on new technologies which lie in your field if they don't, as the time for learning is stretched between many topics today. The ROI for learning Erlang is not high for me and I want to invest in the best assets.
That said, knowing which screw to turn on a printing machine is incredibly valuable - but only if your job comprehends fixing printing machines: if you want to design Space Shuttle's computers for a living, you had better study software and hardware engineering. And even if printing machines could be more interesting than physics, the latter is a more pertaining topic since your computers will interface with a real situation outside the Space Shuttle.
As I previously said, if you want to design the Space Shuttle's computers. Don't be fooled in learning high paying disciplines that you don't care about at all. Work fills a big chunk of your life, especially for [software] engineers, and making sure you enjoy it, it's the best favor you can do to yourself. Even if you are less marketable and less rich, but not broke and still happy.