coder . cl

There are several parallel models. One of the most used parallel programming models is the threading model, where you create threads or lightweight processes which are sharing memory and resources, like open files. A thread is an independent execution space that shares memory with its creator inside the its parent process. So, imagine that you need to process 5 files containing call time duration and you need to sum and join that data. Processing that set of files sequentially probably is slower than doing a parallel program to process all files at once. Here is an example written in Python that can help you to understand a threaded solution for this problem.

I always wanted to be a programmer. As programmer my main motivations are three main items: challenging problems, good inputs — computers, printers, and related stuff — and well done stuff. Not necessary in that order. Including more than money. Challenging problems are those problems that can make you think a lot on how to solve them, where you need to take your books about algorithms and make some research on how to solve them, mainly related to algorithm design. Good inputs allow you to make a better work, more efficient working hours and comfortable job. Well done stuff, is all your job made well, with the proper milestones, without pressure and doing a great work with algorithms implemented with beautiful code.

If you have pretty clear programming concepts, learning new programming languages is not so hard as it seems. But those concepts are hard to understand. I will use my most recent learnt programming language, where probably you already know about what is it. Haskell is a programming language fulfilled with concepts, mostly based on mathematical abstractions inherited from Lambda Calculus, Combinatory Logic and Category Theory, among other topics that are covering its well known constructs, like Monads — which is inherited from Category Theory. You can understand how to work with Monads, like the IO Monad, StateMonad, and similar ones, but you need to understand the Monad basis from the perspective of the Category Theory to build your own Monads as abstractions. I am pretty sure that you can find theoretical basis on most programming abstractions, once you understand those theoretical basis, you are able to build well structured abstractions by yourself. Even if your knowledge on each topic is not so deep an abstraction variant, you can understand those concepts behind each construct and implement not so formal variants of each abstraction.

Where I work we are using code reviews, so each developer as peer is reviewing the code of another developer, using a review cycle where each review session is made to any different member of the team. All reviews are done in the team as peers, making the team responsible about the code that is sent to the QA stage. This help us to detect errors that cannot be seen by the programmer that owns a task, because is hard to see our own programming mistakes, and the team knowledge is balanced incrementally on each review. We are using Atlassian FishEye for code reviews, and we comment each commit when it is required, with internet links to well known bugs, documentation and papers, documenting each comment. Each team member knows about their peer programming tasks and how those tasks will affect his own tasks, and due to the system complexity we must avoid as much programming errors as we can — usually we do not send code with bugs to QA and we are constantly passing all tests.

There are some myths about programming and development methodologies. Among several of those myths, the one that makes laugh a lot is that one that claims that “you do not need skilled programmers to build successful software”. I really cannot imagine a team of non skilled programmers doing a successful application. Most myths are claiming that “the used methodology and management is more important than having good programmers”. Then CMMI, Agile, and several points of view about developing applications and systems are applied daily in software development. But more than the methodology itself, the fact that communications and skilled programmers are making great teams, cannot be denied.

Defining state machines is not so hard as it appears. Initially you can build constructs that can help on building automata processing much friendly than using plain code. Starting from the idea that you can place your state machine inside data structures allowing friendly editing without modifying the processing code. Any stateful processing can be migrated to state machines. As any automata can be represented in a state diagram and then it can be migrated to plain data structures. Even if you are using a purely functional programming language, you can place a stateful processing data structure to be processed as automata.

I was reading this blog post about productivity porn. Probably I can agree that there are many tips about how to be productive in our work, but we can use many of those tips, I think that many of those tips are good enough to make our day very productive. But memory is weak. I recognize that I cannot remember everything that I can do on a day. Mainly once you have many real work projects, side projects or personal projects. So, to make a day productive — mainly if you are a freelancer and nobody is pressuring your work and you must be responsive by your own initiative — you need some tool to track or make you remember your tasks. A calendar like GMail is useful, but as Emacs user, I prefer to use org-mode.