The fellow who designed it, is working far away;
The spec’s not been updated for many a live-long day.
The guy who implemented it, is promoted up the line;
And some of the enhancements didn’t match to the design.
They haven’t kept the flowcharts, the manual is a mess;
And most of what you need to know, you’ll simply have to guess.

by David Diamond

Update: This is dated June 1976, by the way.

Uma leitura interessante, o último artigo do Paul Graham (como muitos dos artigos dele o são), no qual reflecte sobre os efeitos de trabalhar numa empresa grande, ou numa empresa pequena.

Muitas destas ideias vão muito ao entro à minha opinião sobre estes assuntos, e têm tudo a ver com agilidade.

The restrictiveness of big company jobs is particularly hard on programmers, because the essence of programming is to build new things. Sales people make much the same pitches every day; support people answer much the same questions; but once you’ve written a piece of code you don’t need to write it again. So a programmer working as programmers are meant to is always making new things. And when you’re part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you’re going to face resistance when you do something new.

There is one thing companies can do short of structuring themselves as sponges: they can stay small. If I’m right, then it really pays to keep a company as small as it can be at every stage. Particularly a technology company. Which means it’s doubly important to hire the best people. Mediocre hires hurt you twice: they get less done, but they also make you big, because you need more of them to solve a given problem.

Vou brevemente arrancar com um pequeno projecto em que um dos requisitos será utilzar uma linguagem funcional. Existindo a necessidade de trabalhar com comunicações e com alguma concorrência, tenho andado a olhar para Erlang. A minha experiência com linguagens funcionais tem sido reduzida, aliás, nula, se pensarmos que XSLT e Python têm influências de linguagens funcionais, mas não são linguagens funcionais em si mesmas, por isso estou com alguma curiosidade em ver no que isto dá.

A ideia passa por ter uma aplicação em C# (Mono + MonoDevelop) a falar com um servidor em Erlang, coisa que ainda não estou certo que seja fácil, apesar de haver alguns indicadores de que deverá ser possível.

Para já estou em busca do IDE certo para o módulo em Erlang. Em princípio, devo-me ficar pelo Erlide (um plugin para o eclipse), já que o Erlybird funciona em cima do NetBeans (em relação ao qual não tenho nada contra, mas entre este e o Erlide, prefiro rentabilizar a experiência que tendo com o eclipse) e o Distel não é um verdadeiro IDE (eu até gosto do emacs como editor, mas por muita boa vontade que tenha, aquilo, de facto, não é um IDE).

Após indagar no respectivo forum há alguns dias, apercebo-me hoje que existem já versões beta 1 do SharpDevelop 3 (apesar das referências, na ligação anterior, de que se trata de uma versão Alpha).

Ainda não experimentei convenientemente, mas estou com bastantes expectativas nestas novas versões. O roadmap é promissor.

Ao ler sobre sobre o padrão de análise Accountability, do Martin Fowler, dei com esta pérola de descrição:

If you are dealing with an organization with a single hierarchy, or even a couple, then Organization Hierarchy is the simplest way to deal with things. However larger organizations grow beyond this. You often find a host of different relationships between parties, all of which carry their own meaning. If your hierarchies start breeding like viagra infused rabbits, it’s time to look to Accountability.

Ontem ou anteontem saiu o Visual Studio 2008; hoje reparo (via Pedro Santos) na publicação dos resultados de um inquérito sobre as funcionalidades mais pedidas do MonoDevelop.

Em relação ao Visual Studio, segundo a PC World, há a dizer que está aí a um preço engraçado (no sentido que me dá vontade de rir) — 800 USD. Os upgrades sempre são mais baratos, mas ainda assim, a preços muito pouco convidativos — 550 USD. Por outro lado, existe a versão express, gratuita, mas ainda não a explorei muito mais, após perceber que teria que sobreviver sem a integração com o NUnit. Ainda assim, ainda hei-de olhar melhor para ela, já que nenhuma das restantes alternativas é perfeita também.

Em relação ao MonoDevelop, parece que as minhas necessidades andam perto das da população em geral: debugger integrado, designers, e ferramentas de refactoring. Parecem-me ir na direcção certa pelo menos, mas ainda não estão bem lá.

Ultimamente tenho passado algum tempo no SharpDevelop, que vai servindo os propósitos, mas em relação ao qual começo a conhecer cada vez melhor as limitações (sendo a mais gritante a falta de uma janela de watch!). Entretanto vou fazendo figas para que saia proximamente uma versão estável do SharpDevelop 3, ou do MonoDevelop > 1.0 (o 1.0 parece estar já muito próximo, mas o debugger ainda não vem nesta versão).

Não pude deixar de sorrir ao ler este artigo, onde se afirma que o iPhone tem a jogar a seu favor o facto de trazer como browser o Safari, o qual se baseia no WebKit, já que desta forma existirá bastante software já desenvolvido para Symbian que poderá ser facilmente portado (tendo em conta que as últimas versões do S60 trazem o Nokia Browser, também baseado em WebKit). O inverso também deve ser verdade, as aplicações Web que sejam desenvolvidas para o iPhone também devem facilmente funcionar em Symbian.

Curiosamente, ao contrário do iPhone, há vários SDKs em Symbian, sendo o browser apenas mais uma hipótese. O software que entra nesta última categoria é uma gota no oceano de todo o software que existe para Symbian, por isso, ao apontar o Safari como *o* SDK do iPhone, acho, tristemente, que só conseguirão com que o software existente para iPhone seja sempre um sub-grupo reduzido do que existe para Symbian.

Vai brevemente ter lugar na FEUP um curso de Desenvolvimento Ágil de Software (28 horas lectivas). Do que conheço dos formadores e do tema, recomendo em absoluto!

Surpreendemente, a Apple lançou o Safari para Windows.

Interrogo-me se também funcionará em Linux, via Wine :)

Sempre é mais um com que passo a testar os sítios Web que me saiam das mãos.

Ao ler um artigo do Duarte Grilo fui dar à descrição na wikipedia do que se entende por flow, no contexto da psicologia. Achei piada à relação que estabelecem com a espiritualidade.

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing, characterized by a feeling of energized focus, full involvement, and success in the process of the activity.
[...]
For millennia, practitioners of Eastern religions such as Buddhism and Taoism have honed the discipline of overcoming the duality of self and object as a central feature of spiritual development. Eastern spiritual practitioners have developed a very thorough and holistic set of theories around overcoming duality of self and object, tested and refined through spiritual practice instead of the systematic rigor and controls of modern science.
[...]
In education, there is the concept of overlearning which seems to be an important factor in this technique, in that Csikszentmihalyi states in his book Flow: The Psychology of Optimal Experience that overlearning enables the mind to concentrate on visualizing the desired performance as a singular, integrated action instead of a set of actions.
[...]
The concept of “being in the zone” during an athletic performance fits within Csikszentmihalyi’s description of the Flow experience, and theories and applications of “being in the zone” and its relationship with athletic competitive advantage are topics studied in the field of sport psychology.

Os únicos momentos em que me senti neste estado foi ao programar, mas nunca tinha pensado na possibilidade de se passar pelo mesmo com outro tipo de actividade (o que aliás, faz todo o sentido).