Learning how to Code

How do you learn to be a good coder? Well you can get somebody else's code and hack it. That's how I started learning. You can also dive into someone else's unit tests to figure out what they are doing.

It is best to inspect a small project's code. That way you will not get overwhelmed or lost. Check out code from dudes who are gurus at software. You should also look at the source for any libs you use. Trace down what happens when you make API calls.

Reading other people's code is an easy way to learn what to do when you code yourself. However the very best way to learn coding is to just do it. There are many apps waiting to be written. What are you waiting for?

MultiCore Design

Virtualization let's you scale applications on multiple processors. This allows multiple nodes to run in parallel, giving you a performance gain. You might have 10 times as many instances of your application running. This is easy to set up, but might not be optimal speed wise. It works best if there are a small number of dependencies in your application.

The problem with this technique is that hardware is no longer getting exponential increases in power and capacity. Therefore you would be better off designing your applications for the multicore processors out there. Normally this means using a threading model which might be complicated. You can cheat a little by using a thread pool with a bunch of worker threads.

There is not usually a need to entirely rewrite your applications to make them support multicore. You got to put some synchronization. And you must make sure race conditions and deadlocks do not occur in your code. Model driven development can help with this task. Refactor your apps for multicore usage, and you will see a big gain in performance.

Software Engineering Method and Theory

There are a bunch of industry veteran trying to discern the universal truths of software development. They have formed the Software Engineering Method and Theory group. It is called SEMAT for short. Some industry luminaries like Ivan Jacobson, Bertrand Meyer, and Larry Constantine are involved.

This group wants to investigate the core theories and best practices in the development world. They state that this group is not about any specific product of standard. They are attempting to uncover the universal set of practices that occur in software development.

SEMAT has broken out six working groups. These include terminology, kernel language, universals, core theory, requirements, and assessment. The group reiterates that it is no looking to create a new development methodology. Instead they are defining software development patterns and practices.

There are some who have their doubts about this effort. Universities lag the industry in practice. It make take many years for the work of this group to bear fruit. This is a theoretical exercise. There may not be any impact to real world development. Something like this was tried before with the Agile Manifesto.

Self Repairing Code

Researched at MIT and the University of Washington are working on software code that repairs itself. You heard that right. This technology is called ClearView. It requires no human intervention.

The new technology knows and understands the normal behavior for software. When it detects some problems, it comes up with multiple options for the fix, and chooses the best one.

This is supposed to be a good way to combat hacking. I guess you could think of it as some type of intelligent system. Self healing code makes for a good headline. However I can't imagine this working for anything but the most simplest of bug fixes. There are plenty more categories where you need an old fashioned maintenance programmer.

How Does printf Work?

An author at the Hostile Fork blog decided to answer a question on how the printf function actually gets implemented in C. This came from StackOverflow. It was assumed that it ended up with some inline assembly code. Let's see what he found out.

The truth of the matter is that it depends on the implementation of your compiler. Hostile Fork guy checked out the GNU C compiler. Turns out printf calls vfprintf with stdout as a parameter. vfprintf calls some macros. They do a putc to a buffered output.

In the end, the calls map down to the write function. And lo and beyond, this becomes a syscall. Next homework step is to trace how Microsoft Visual Studio handles printf.