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