Open Serpro?

Reter é perecer...

Ederson Torresini - Professor Universitário, Comunista e Adm Redes

Notícia do SL.org:
"O Serpro, que processa os principais programas de informática do governo e a arrecadação da Receita Federal, anunciou a adoção de uma nova política de sistemas por meio da qual irá reforçar a adoção de software livre e intensificar o desenvolvimento na plataforma aberta, além de buscar a aproximação da empresa com a comunidade open source, de modo a estreitar a colaboração na produção do conhecimento tecnológico brasileiro."

Fonte: http://www.softwarelivre.org/news/10495

Tem certeza que isso ai é um framework?

Saudações a todos... post melancólico... =)
Acredito que seja talvez nossa ânsia por resolver todos os problemas de uma vez só. Ou ainda nossa pretensão em acreditar que possamos realmente resolver todos os problemas de uma vez só...
Engraçado, mas tenho visto muito disso no mundo de desenvolvimento Java. Basta procurar em sites como Sourceforge ou Javaforge pelas palavras "framework"(1 e 2) e você terá a com extatidão o tamanho do problema.

Deve ser pela interpretação errada que alguns líderes técnicos fazem do tema, mas todos os frameworks que presenciei a implementação causaram sempre mais problemas do que soluções. Sempre fui e sempre serei averso à criação de frameworks, ou um pseudo-genérico-subsistema que "deixe as coisas mais fáceis" sem que seja estritamente necessário... como infelizmente nunca estive na posição de tomar este tipo de decisão, apenas paguei pelo erro dos outros, utilizando implementações que não foram feitas para serem utilizadas, mas apenas para servirem de vitrine: "olha, como nosso framework é maravilhoso! implementamos todos os desigs patterns existentes! não funciona para o seu caso de uso, mas mesmo assim ele é maravilhoso!".

Bom saber que exitem pessoas preocupadas com isso além de mim (vide 37signals com o Getting Real)... a apresentação deste post é do cara que ajudou a implementar a API de coleções do Java, Joshua Bloch... até que ele programa um pouco... conhece um pouco do assunto...

Bem, todos deveriam ver este vídeo... sinceramente...
Principalmente akeles que acreditam que sabem implementar frameworks e APIsp. São apresentados conceitos simples (muito simples), mas que muitas vezes são esquecidos: como tentar SEMPRE implementar um sistema que utilize a API ou framework (sempre é pouco, que tal 3 sistemas até realmente afirmar que o framework está pronto??), ou ainda tentar obter o máximo de feedback e tentar deixar tudo o mais simples possivel? ( do one thing, and do it well!) ou ainda documentar o necessário para que outras pessoas possam utilizar o seu framework/API.... entre muitas outras coisas. Confira por si próprio...

Com vcs, o cara:

ABSTRACT

Every day around the world, software developers spend much of their time working with a ... all » variety of Application Programming Interfaces (APIs). Some are integral to the core platform, some provide access to widely distributed frameworks, and some are written in-house for use by a few developers. Nearly all programmers occasionally function as API designers, whether they know it or not. A well-designed API can be a great asset to the organization that wrote it and to all who use it. Good APIs increase the pleasure and productivity of the developers who use them, the quality of the software they produce, and ultimately, the corporate bottom line. Conversely, poorly written APIs are a constant thorn in the developer's side, and have been known to harm the bottom line to the point of bankruptcy. Given the importance of good API design, surprisingly little has been written on the subject. In this talk, I'll attempt to help you recognize good and bad APIs and I'll offer specific suggestions for writing good ones.

Marcio Marchini at edugraf

Saudações a todos!
Bem, na semana passada, em Florianópolis, houve uma apresentação do Marcio Marchini, consultor da Bedarra, empresa Canadense do Dave Thomas. Bem, o Marcio está no Brasil para auxiliar a Audaces na adoção do desenvolvimento Ágil. Estamos crescendo muito com a participação dele!

Desculpe a divagação.

Na terça passada o Marcio fez uma apresentação (aula aberta) com o título "Desenvolvimento de Software no Silicon Valley North", mostrando sua experiência com Desenvolvimento de software e principalmente com Desenvolvimento Ágil.
A palestra foi bastante produtiva, e alguns pontos são importantes ressaltar:

- Na Rational eles usam Diagramas de classe para o desenvolvimento? Resposta: HAHAHAHAHAHAHAHA
- Na Rational eles fazem testes automatizados? Resposta: HAHAHAHAHAHA
- E na IBM? Resposta: HAHAHAHAHAHA
- A Microsoft utiliza o Project para desenvolvimento de Software? Resposta: HAHAHAHAHAH

"Em casa de ferreiro o espeto é de pau"...

Também foi uma oportunidade para o Marcio divulgar os serviços da Bedarra no Brasil... com o CTIP (Continuous Test and Integration Plattaform), que é uma compilação de vários sistemas para promover a Integração Contínua.

O Edugraf disponibilizou os slides da apresentação, e logo estará disponível o video com a palestra... vale muito a pena conferir!

Veja os slides: Marcio-Bedarra-Agile.pdf

[]s

Triste Realidade

Saudações!
Infelizmente é comum encontrarmos projetos em que não houve a menor preocupação com qualidade... seja qualidade na resolução do problema que um código se propõe, seja na qualidade do código produzido.
Lendo um texto clássico, How to Write Unmaintainable Code, percebe-se o quanto é importante a preocupação com a forma que produzimos software.
"Any fool can write a code that a machine understands. Good programmers can write code that a human can understand"

Pense nisso... em desenvolvimento de software, código legal está entre os principais motivos para atrasos no desenvolvimento.


Continue a leitura do artigo, e caso encontre similaridades na forma com que seu código fonte está organizado repense sua forma de trabalho. Coloquei apenas a introdução do texto, mas vale a pena checar o artigo completo.

Introduction

Never ascribe to malice, that which can be explained by incompetence.

Napoleon

Because of the Slashdot plug, hits peaked at 250 a second on this page, and the hit counters stopped kicking over. I received a slew of email with suggestions for ever more subtle techniques of writing unmaintainable code. It took me quite while for me to incorporate all your suggestions. The essay has been like rock candy, seed the string with sugar, soak in sugar water, soon it grew out of control.

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!
General Principles

Quidquid latine dictum sit, altum viditur.
Whatever is said in Latin sounds profound.

To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.

He views your code through a tube taken from the centre of a roll of toilet paper. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything.

Programmers are lulled into complacency by conventions. By every once in a while subtly violating convention you force him to read every line of your code with a magnifying glass.

You might get the idea that every language feature makes code unmaintainable -- not so, only if properly misused.

Street Fighter IV

Ainda com a nostalgia em alta, lah vai mais um video...
Depois de Rambo, o que poderia ser mais "roots" para nós, nascidos em meados da década de 80? Street Fighter!!!
Bem, o video fala por si só



Fonte: Uol Videos

Rambo 4

Tiros... muitos tiros... e mulher bonita... algumas... e muito sangue... Rambo 4



Fonte: Rambo 4 trailer
... Estou me sentindo nostálgico....

Um pouco de Alan Shalloway

Allan Shalloway, da NetObjectives apresenta seu ponto de vista sobre os benefícios do Scrum:

Fonte: Praise for Scrum

A natureza iterativa do Scrum permite o aprendizado rápido. Sendo Scrum baseado num modelo iterativo, é normalmente necessário construir uma parte do sistema e inclusive entregá-la ao cliente para receber feedback e somente assim continuar. Esta natureza permite aprender rapidamente as necessidades do cliente tão bem quanto aprender de que forma otimizar o próprio processo de entregar valor agregado ao cliente.

A inclusão do cliente, assim mais valor pode ser entregue rapidamente. Focando-se na relação entre o cliente e a equipe, Scrum traz à tona um dos maiores desafios para a equipe: conseguir informações concretas sobre o que construir. Scrum provê uma serie de idéias para lidar com clientes sobre a ótica de produtos. Construindo software em partes com o contato direto com o cliente, as funcionalidades mais importantes podem ser entregues rapidamente.

Diminuição do risco de construir a coisa errada. Apresentando o mais rápido possível as funcionalidades implementadas ao cliente, a equipe pode diminuir significativamente as chances de construir ou interpretar errado requisitos. Isto é extremamente importante, sendo o maior risco para o desenvolvimento de software. Construir funcionalidades que não serão utilizadas é obviamente desperdício de recursos. Entretanto é muito pior do que se imagina. A complexidade extra, e não utilizadas, deste software pode causar ainda maiores custos de manutenção, que serão normalmente maiores que o custo de construir a funcionalidade.

A ênfase em na remoção de impedimentos. Sendo Scrum um ótimo processo para iniciar, seu foco em remover impedimentos leva a equipe à procura de continuamente melhorar seu desempenho. Isto não apenas possibilita à equipe gerar mais valor, é um beneficio para a propria criação do time. E uma ótima equipe produzirá muito mais valor com um processo capenga do que uma equipe mediana. Boas equipes com processos ótimos podem ser realmente maravilhosos.

Dá a oportunidade às pessoas perceberem que estão no controle de seu destino. Remover impedimentos da vida de alguém possue um efeito espiritual. Traz à tona a consciencia de que esta pessoa não é a vitma, mas o capitão de suas proprias decisões.

Facilmente implementado pela equipes. O fato de Scrum ser tão simples é impressionante. Com apenas um dia de treinamento já é possível iniciar a sua utilização. Vitórias rápidas são as melhores!

Are you Agile or Fragile??

Saudações!!
Lah vai mais um video: Scott Ambler, autor de dezenas de livros, faz uma apresentação de improviso extremamente Agile Like!!
Video bastante longo e instrutivo, com intensa participação da platéia.


Fonte: Google Video


Desculpem a demora... estamos no meio de uma visita de um consultor canadense (Bedarra), que está ajudando muito nossos projetos Scrum e auxiliando bastante na implantação de um ambiente de Integração Contínua... novidades por ai!
[]s

Technical Success

By Ken Schwaber:
"There is no such thing as 'Technical Success'. If there is not business success, 'Technical Succes' is just an eufemism for failure"

Ou em bom e velho português:
"Não existe esse negócio de 'Sucesso Técnico'. Se não houver sucesso de negócio (ou comercial), então 'Sucesso Técnico' é apenas um eufemismo para fracasso"

Essa frase vai para o Abu, amigo Agilista, que agora sim está mudando para uma nova fase, que com certeza será mais produtiva e menos frustrante!

Free Beer

As profecias estão cada vez mais claras para mim... sim! Colaboração e Liberdade de Escolha são o caminho!

Fonte: Folha de São Paulo
A Free Beer é a nova ação do coletivo dinamarquês Superflex, composto por Bjornstjerne Reuter Christiansen, Jakob Fenger e Rasmus Nielsen. No ano passado, o grupo trouxe polêmica à 27ª Bienal de São Paulo com o Guaraná Power, censurado pela presidência da instituição, que afirmou que não se tratava de uma obra de arte. Apesar do veto, o Guaraná Power, feito em colaboração com a Cooperativa de Agricultores da Região de Maués, na Amazônia, chegou a ser distribuído em museus e na própria Vermelho, durante a Bienal.

"Agora estamos propondo uma marca aberta e, nesse sentido, sugerimos um novo modelo econômico, que permite a qualquer um produzir e distribuir cerveja, a partir de uma receita que é pública, além de criar consumidores não obedientes, como gosta o mercado", conta Fenger.

"Free software"

A Free Beer surgiu em 2004, numa parceria com estudantes da Universidade de Copenhague. "Buscamos transferir os princípios do software livre para algo físico, e a cerveja se tornou um bom exemplo", conta Nielsen. "Por isso, a Free Beer tem sido comparada ao Linux [sistema operacional gratuito] e à Wikipedia", diz o artista.

Quem quiser produzir e comercializar a Free Beer pode baixar do site www.freebeer.org a logomarca da cerveja, de forma gratuita. "Já há Free Beer sendo produzida na Inglaterra, nos Estados Unidos, na Dinamarca e até na República Tcheca", afirma Fenger.