Archive for June, 2007

Linux No Desktop

Thursday, June 14th, 2007

Já que começamos o tema vamos prosseguir para o GNU/Linux no desktop. Minha opinião? Linux no desktop é para quem tem pelo menos tempo (e interesse) de saber minimamente como um computador funciona. É simples: se você é um programador (ou se diz um) e não saber utilizar um GNU/Linux como desktop você está no caminho errado da carreira. Vamos lá, o GNU/Linux não tem nada de novo em termos de sistema operacional. Se você estudou SO em algum lugar (faculdade, livro, cadeia, etc.) você consegue saber como um UNIX funciona, se você acha que “perdeu tempo” estudando S.O. saia desta carreira e deixe os profissionais assumirem.

Mas… minha mãe não. Minha mãe trabalha com projetos, ela não tem tempo nem interesse em aprender como um computador funciona. Durante alguns anos ela usou GNU/Linux alegremente, quando eu morava com ela e dividíamos o computador. Ela já usou diversas distribuições e nunca reclamou. Por que? Porque eu configurava todo o computador, saia no tapa com winmodems e parâmetros bizarros e quando ela usava a máquina ela estava funcionando. Isso explica porque GNU/Linux para desktops corporativos funciona bem: quem toma conta não é o usuário. Agora minha mãe mora sozinha, eu deixaria um GNU/Linux instalado lá? Se eu não tenho tempo de a administrar (ainda que remotamente) não.

E não, não é mérito do Windows, é vergonha do GNU/Linux. Exemplo? Pegue um usuário leigo, deixe ele usando Mac OS X e depois pelo mesmo tempo seu sabor favorito de Linux. Sabe qual ele vai preferir? Eu já fiz essa experiência e te digo: o Mac. As interfaces GNU/Linux, por mais que KDE e Gnome sejam ótimos, não estão prontas para o usuário comum. Neste instante alguém diz: ah, é porque a documentação é para Windows.

Vamos lá, minha mãe não lê o manual do DVD player dela para saber o que o botão XYZ do controle remoto faz, você acha que ela procura na Internet como resolver um problema? A coisa tem que ser intuitiva e como eu disse acima um sistema UNIX é extremamente intuitivo para quem tem a mínima noção de como funciona um SO, mas não o contrário. Minha mãe não consegue diferenciar a rede local da Internet, como ela conseguiria conectar um modem ADSL para dois computadores? E estamos falando de uma pessoa que lida diariamente com computadores diversos há uns bons quinze anos, tanto no trabalho quanto em casa, e já passou por todos os sabores de Windows e antes dele o DOS e OS/2.

Eu não entendo como alguém pode aceitar as limitações de um sistema Windows enquanto desenvolve software (tanto que mesmo quando programo em .Net uso o Mono), mas realmente não consigo conceber um usuário doméstico, sem administrador, usando GNU/Linux.

Kickin’

Saturday, June 9th, 2007

Tem alguns meses que eu voltei apra o paraíso que é trabalhar apenas em GNU/Linux. No trabalho e em casa tenho um Kubuntu e para as aplicações que preciso de Windows (alguém disse MS Project?) eu rodo uma VM no qemu.

Ontem eu fiz a atualização periódica do meu sistema. É muito difícil, você precisa abrir um terminar e digitar:


$apt-get update
$apt-get upgrade

Sim, isso tudo.

Depois eu descobri que o Firefox não estava se entendendo com o kicker (a “barra do botão iniciar” do KDE). O kicker simplesmente travava. Pelo log do processo tinha algo errado na minha configuração do X misturada com a do Beryl. Depois de ler alguns históricos e fóruns eu descobri a solução adicionando uma linha nova na configuração para suportar um módulo novo qualquer, pronto. Tempo total: 45 minutos.

O que?!! 45 minutos para consertar um bug do sistema?! Sim. Mas pense bem: se isso acontece num sistema onde você não tem controle (nem digo um sistema de código fechado, esse não é o problema, o problema é não ter controle) você só ia ter uma opção: reinstalar o sistema. E sim, eu poderia reinstalar o sistema e ia demorar muito menos, já que eu talvez só precisasse reinstalar o KDE e não todo o SO como acontece com o Windows (acrescente duas linhas na sequência acima e pronto).

Aqui em casa temos um espaço com dois desktops, o da minha esposa e o meu. Ela roda Windows (mas está querendo migrar para Mac, não aguenta mais) e dia desses eu passei várias horas fazendo algumas manutenções no PC dela após uma sequência que começou com spyware e terminou com um computador sem som e que não reproduzia DVDs. Após a luta para salvar as fotos dela, arquivos, etc. eu formatei a máquina toda, depois tive que baixar aqueles programas que reconhecem o hardware para baixar de 3 sites diferentes os drivers de todos os periféricos, além da grana em anti-vírus.

Este não é um post do tipo “mude para Linux” porque eu já passei desta fase, mas é só uma demonstração de como os problemas que existem em ambas as plataformas são tratados.

3 Letrinhas

Thursday, June 7th, 2007

Você sabe o que é um ataque de força bruta? É quando você tem um problema para resolver (uma senha para quebrar, por exemplo) e para chegar a solução você tenta todas as formas possíveis. É um desperdício de recursos tremendo quando há outra alternativa, além de ser ineficaz contra alguns problemas (principalmente problemas cuja resposta muda conforme se tenta chegar a solução).

Este é o espírito de boa parte das pessoas que contratam as famosas empresas de 3 letrinhas. O termo surgiu em uma das intermináveis conversas entre Marcos Eliziário e eu e serve para designar empresas que você conhece muito bem. São aquelas consultorias que contratam pessoas após 10 minutos de entrevista e cobram 90% a mais pela hora destas pessoas do que o que pagam para ele (que normalmente são contratados como PJ, cooperativa ou outro meio escuso).

Estas empresas se aproveitam do fato de que qualquer macaco consegue criar um programa de computador e que todo mundo precisa de programas de computador, ou pelo menos pensa que precisa. O modelo de negócios é bem simples: entupimos o cliente com técnicos de nível júnior ou menor e cobramos preço de senior ou mais. Como o cliente não vai saber quem são nossos funcionários nem vai testá-los precisamos de selinhos de qualidade (SCJP, MCP, whatever) nos curriculuns dele. Como o cliente não sabe o que é um processo de software ou como ele funciona precisamos de um selinho de qualidade (CMMi, MPS.br) no nosso.

Essas empresas se valem do “fator Sheakespeare” e de como ele funciona bem em TI. Bem para quem fornece, claro, para quem compra e quem trabalha em ambos os lados é uma bela dor-de-cabeça. A forma como tratam seus recursos humanos é o que mais mostra suas 3-letrices. Imagine um porto. Existem pessoas que trabalham abrindo containers e descarregando o conteúdo em algum lugar. Estas pessoas não têm a menor chance de subir na sua carreira, se elas querem ter um futuro elas devem parar de fazer o que fazem e assumir outra profissão. Sim, somos estivadores, commodity, para estas empresas. Para crescer ou ganhar algum dinheiro você tem que largar tudo aquilo que estudou e “evoluir” para uma posição de gerência de pessoas ou processos.

Além do simples fato de que nem todos são bons com pessoas e processos (vide os gerentes ruins e medíocres que temos aos quilos por aí), estas empresas renegam o fato máximo de que gerência de pessoas, de processos, de custos ou de qualquer coisa é uma disciplina complexa e cheia de variantes por si só. Não é a toa que temos tanta discrepância por aí.

Quem lê este blog sabe que eu sou um grande defensor dos conceitos de engenharia de software. Não é porque você usa uma plataforma OO, por exemplo, que está usando objetos, pode estar fazendo a besteira de usar BOs e VOs, sem ter sequer noção do que está fazendo. Esta ignorância sobre os princípios básicos que regem as coisas é a mesma que faz com que uma empresa dessa pegue um framework completamente iterativo como RUP e transforme em waterfall, por exemplo.

Quer fazer um teste rápido? Sua empresa tem “fase de análise”? Vocês tratam as fases do RUP como análise/especificação/implementação/implantação, nesta ordem? Se sim sinto muito, meu amigo, mas você não usa RUP., usa o que te contaram que era RUP. Que tal ler um bom livro sobre o assunto e não confiar em 3 letristas?

Seu gerente de projetos faz questão de agendar todos os possíveis eventos em cronogramas e Gantt Charts enormes que abrangem todo o projeto? Ele está atrasado pelo menos 5 anos.

E quanto tempo isso dura? Por quanto tempo esse modelo de negócios é viável? Alguns sinais começaram a ser vistos como ameaças de demissão em massa e corte de custos. Mas ainda há muito dinheiro e por um bom tempo o cliente ainda está disposto a gastar o valor de uma produção de Hollywood quando na verdade o que ele queria era ler (não necessariamente ter ou fazer um) um pocketbook de Rei Liar (cujo texto está disponível gratuitamente).

DDD e DTO

Thursday, June 7th, 2007

Pergunta na lista UML-BR:

Boa tarde a todos,

Estava estudando o DDD (Domain Drive Design)…

Percebi que a camada de negócios deve ser um reflexo da realidade, para que
o sistema possa evoluir de maneira mais fácil (flexibilidade) conforme a
regra de negócios do cliente tb muda…
Por isso temos as entidades.. Por exemplo Funcionario, Departamento, etc…

A duvida que eu tenho é a seguinte:
Vamos supor que eu tenha que exibir todos os funcionários em um JSP… eu
deveria criar um DTO do Funcionario e “mandar” para a camada de visão? ou
posso mandar o proprio objeto de negócio (o que na minha opinião é mais
pratico, já que eu não preciso duplicar código no DTO)?
Pois eu li o Artigo do Phillip Calçado e do Martin Fowler
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
http://www.martinfowler.com/bliki/AnemicDomainModel.html
onde eles dizem que não é bom criar DTO´s… e por isso estou confuso….

O que vcs acham… para exibir as entidades em tela a camada de visão pode
ter contato com as entidades… ou vou ter que duplicar o código criando um
DTO para cada entidade?

[...]

Então eu tb penso assim….

Mas pensando no lado negativo disso, imagine se eu tiver 50 JSP´s mostrando
os dados desse Funcionario…. Ai eu vou e faço uma refatoração no codigo
(talvez mudando metodos de uma classe pra outra, etc)…. vou ter que
verificar nos 50 JSP´s pra ver se não deu nenhum problema, ou até mesmo para
ajusta-los a nova mudança!!!!!
Talvez se eu criasse DTO´s para isso eu não teria esse problema pois os
DTO´s não mudariam…..
O que vcs acham disso…. faz sentido????

valeu pessoal…..

Felipe Regalgo

Você poderia ter objetos de transferência apenas para a interface - DDD
não fala explicitamente sobre isso- mas existem algumas questões
práticas neste sentido:

- Hierarquia duplicada desnecessariamente: Ao manter um DTO (VO é um
nome que já foi usado para DTOs mas não é mais) para isso você está
duplicando toda a sua hierarquia de classes, o que indica código
duplicado, tendo em dois ou mais lugares no seu sistema o mesmo
conceito implementado.

- Mudanças: Da mesma maneira que se eu alterar minha classe de
negócios vou ter que alterar a interface sem DTOs, com DTOs a cada
mudança no meu modelo de negócios *eu tenho que alterar o DTO
correspondente em si*, logo você só transfere o problema de lugar mas
continua com ele -e com código duplicado que é *muito* ruim.

- Se você pensar neste isolamento então precisa de DTOs para qualquer
coisa que não seja camada de negócios, logo vai precisar também para
persistência, por exemplo, caindo nos mesmos problemas acima para
outra camada.

- Encapsulamento: OO exige que suas abstrações sejam encapsuladas, e
isso quer dizer que dificilmente a mudança na implementação de uma
classe vai afetar outras em tão grande escala. Quando isso acontece é
porque houve um grande refactoring ou uma grande mudança de conceito de
negócios, e isso -além de raro- vai afetar seu sistema com ou sem
DTOs. A diferença, como citando no primeiro item, é que sem DTOs você
não precisa se preocupar em mudar vários lugares, apenas a classe de
negócios.

- Conceito de Negócios: DDD pressupõe que seu sistema modela ao mais
próximo da realidade possível. Se uma classe muda no modelo de
negócios é porque seu entendimento sobre o negócio mudou e
provavelmente alguma coisa na interface vai refletir isso.

Em DDD temos os ContextMappers que mapeiam domínios diferentes que
precisam se comunicar. Esta é a abordagem normal para os casos onde se
percebe a necessidade de algo como um ‘DTO interno’.

‘DTOs internos’ (”VOs”) são uma péssima prática, completamente não OO
e difundidas tristemente pela Sun para lidar com as falhas da
arquitetura de EJBs pré 3.0.

[]s

DAO e Repository

Tuesday, June 5th, 2007

Tópico quente no GUJ. Muita gente está atrás de Domain-Driven Design hoje em dia e não tem a menor noção do que é um repositório.

Re-colando o trecho para a lista de DDD:

On 5/19/07, Phillip Calçado wrote:
> The main thing to keep in mind while working with Repositories is that
> they’re a domain concept, while a DAO or any other Mapper between
> objects and tables aren’t. The domain classes knows that repositories
> are where business objects instances remain. As a business concept it
> can and will be handled, received as a parameter, etc. by those
> business domain classes like services and entities.
>
> A DAO doesn’t fit in a Repositories place directly, this would break
> layered archtiecture of a application, but generally a Repository is
> just something that when invoked will call a DAO.
>
> To avoide the tortures of creating a brinless delegator as a
> Repository you can use the Dependency Inversion principle, by Uncle
> Bob, and make Repository an interface implemented by the DAO class.
> This way your domain classes won’t end up dependent on infrastructures
> classes (like DAOs) while you avoid creating Repository classes that
> acts just like delegators.
>
> I’ve used this approach more than once. In a recent project I’ve used
> this Dao<>Repository strategy and suddenly was requested
> that before checking the database I’d have to first check a enterprise
> search engine (something like google appliances or a dedicated Lucene
> server). I used to have:
>
> Domain Object –<>–> Repository <--<>– DAO
>
> And changed to:
>
> Domain Object –<>–> Repository
>
> Repository <--<>– RepositoryImpl –<>–> DatabaseDao
>
> –<>–>SearchEngineDao
>
> The RepositoryImpl was the class responsible for looking for the
> instance persisted in one of the two deta repositories. The domain
> classes that just relied on the Repository concept, not its
> implementation, weren’t affected.
>
> cheers
>
>
> On 4/25/07, Nick wrote:
> > I’ve just completed my third project using DDD principles and I think
> > I’m ready to move away from the repository pattern (though still
> > giving it some thought). In theory, I think it’s great. However, it
> > just causes so much code explosion, I find it’s just not practical.
> > For example, for the customer aggregate root I have:
> >
> > Domain.ICustomerRepository
>
>
>
> –
> Phillip Calçado
> http://www.fragmental.com.br

O DQO também colaborou.

BugBashing

Monday, June 4th, 2007

BugBash

“Quando o Eclipse fizer isso alguém me avisa ?”

Monday, June 4th, 2007

É impressionante como as pessoas se atêm a brigas inúteis. Este tipo de flamewar é decepcionante:

Quando o Eclipse fizer isso alguém me avisa ???
Data: Mon, 4 Jun 2007 18:00:11 -0300
http://weblogs.java.net/blog/caroljmcdonald/archive/2007/06/sample_store_ca_1.html#comments

A resposta tá na ponta da língua: vai serno mesmo dia em que alguém que criou algo realmente importante como Hibernate, Spring, JBoss, qualquer um dos projetos do CodeHaus, JUnit, etc. e não apenas CRUDzinhos utilizar o NetBeans. Talvez no dia em que ele tenha um editor de código de verdade.

Mas que tal ao invés de continuar com esta infantilidade barulhenta (atrasada, como sempre) os brasileiros produzissem algum código que presta?

Microsoft: RIP?

Monday, June 4th, 2007

Paul Graham e Martin Fowler decretaram o fim da MSFT. Não é a primeira vez que isso acontece mas desta vez são grandes nomes, um sempre escandaloso e um geralmente bem imparcial, na ordem. Como falamos aqui nos últimos meses, Redmond tem surpreendido a comunidade de desenvolvimento (como nota Fowler) com novidades realmente interessantes mas… Microso$oft é MSFT, não tem jeito. Após tantos anos jogando com as peças erradas vão ser necessários muitos milhões de dólares e neurônios para virar a mesa, e por mais que dólares não faltem neurônios ainda são muito caros para Redmond, já que seu preço varia com o freguês.

Enquanto Graham se atêm às perdas de mercado na computação de desktops Fowler fala sobre a perda de mercado da plataforma .Net. Vai ser necessária muita inovação, tanto em SO quanto em plataforma de desenvolvimento, para reverter o jogo. Em Plataforma temos visto aqui que realmente eles estão tentando, e muitas vezes conseguindo. A parte de SO é a antítese: cópias de recursos com mais de dez anos de existência.

Dado que a MSFT prende sua plataforma ao seu SO, o sucesso ou fracasso de um influencia o outro. Este risco sempre esteve presente para o programador .Net mas antes ele era tão irreal que era simplesmente desconsiderado. Agora ele está aí nas mãos dos milhares de MacBooks nas mãos de quem mora em países civilizados (do tipo que não faz um MacBook custar R$6.500,00) e dos sabores de GNU/Linux que alimentam os datacenters. Na lista do Graham sobre como salvar a MSFT eu incluiria abrir sua plataforma para externos. Por mais que o Windows continue caindo pelo menos uma parte da empresa estará a salvo.