Você se diverte codificando?

Eu sim...apesar do meu trabalho hoje em dia envolver pouca codificação, sempre que tenho oportunidade, escrevo uns ifs e whiles pra matar a saudade. Bom...o objetivo deste post não é ser saudosista e sim divulgar uma radio online que passei a ouvir faz bem pouco tempo, mas que tem cativado meu gosto musical ( que não é mais o mesmo de antigamente...conforme você for envelhecendo, seu gosto vai mudar...pode acreditar ) enquanto trabalho. Me lembrou dos velhos tempos, quando botava o meu fone e codificava das 9 as 5, sem parar e lovin'it.

Enfim...segue o link, eu particularmente gosto da Rock 181.

Análise dos Fatos à Luz da Ciência

Um assunto bem offtopic, é verdade, mas a coerência do texto do Stephen Kanitz merece destaque...
___________________________________________________

A expulsão de Geisy Arruda, pela diretoria da Uniban, por usar uma saia super curta me remeteu ao 19º Congresso de Genética Comportamental de 2007, realizado em Williamsburg, Virgínia, quando conversei com a Dra. Meghan Provost, que havia feito um estudo interessante.

Ela filmou mulheres usando um software, clique para ver, http://www.biomotionlab.ca/Demos/BMLwalker.html, ou baixe no Iphone o programa Walker programado por Ivo Wessel, e descobriu o seguinte:

Mulheres, na época da ovulação, mexem o quadril de forma ligeiramente mais acentuda do que no período infértil. Não de próposito, mas provavelmente consequência indireta de algum hormônio que controla a ovulação. Alguns homens talvez nem conseguem perceber, outros aprenderam a sutileza.

Achei o software fascinante, e a pesquisa também, em anexo. http://www.springerlink.com/content/3g8l78060073n873/

De volta a São Paulo, um dia observei na Avenida Paulista três garotas indo para uma festa. Uma usava uma saia curta vermelha, até vulgar, outra tinha uma saia que ia até os joelhos, e a terceira usavam um tubo longo preto.

Qual é a saia mais sexy para se usar numa festa? Uma saia curta, média ou longa? Posso estar tirando as conclusões erradas a partir da pesquisa da Meghan, mas ficou claro para mim naquele instante que é a saia média.

Porque ela acentua o balanço do quadril e amplifica o sinal que uma mulher está ovulando. Sinal para atrair os instintos de todo homem a 200 metros de distância.

Pessoalmente, nunca achei uma saia curta sexy, pelo contrário, usei o termo vulgar. Na realidade, uma saia curta é a que balança menos, por definição. Saia curta não atrai homens como se imagina, e a Uniban deveria ter ensinado genética comportamental às suas alunas desavisadas, e não expulsá-las. A aluna expulsa não é uma devassa, simplesmente usou um mito entre as mulheres de que saia curta lhe faria mais atraente entre os homens que querem ter filhos. Ledo engano.

O longo, é o vestido típico de mulheres casadas, e agora sabemos porquê. Tem um mínimo de balanço sem provocar.

Se você quer ser atraente, use saia levemente abaixo dos joelhos ou acima dos joelhos, rodada e que tenha um balanço harmônico. É, segundo a Genética Comportamental, a mais eficiente para atrair um homem que queira ter filhos.

Dito tudo isto, devo dizer que não encontrei mais referências sobre esta questão, nem a Meghan, parece ter continuado nesta linha, portanto deixo isto como assunto para ser pesquisado e comentado, não como verdade absoluta.

Minha área não é exatamente esta, estou aqui também de curioso.

______________________________________________
Retirado de http://blog.kanitz.com.br

...you’re not here to write code; you’re here to ship products.

Outro post interessante de Joel Spolsky. Confesso que senti um certo alívio ao lê-lo.

Duct Tape Programmer

Boa Leitura...

Administração clássica

Recentemente assisti uma palestra sobre Marketing para Empreendedores em um evento em Florianópolis, onde o palestrante (José Chequer, professor da fundação Don Cabral) comentava sobre a importancia na qualificação das pessoas que trabalham nas empresas. Ele citou o exemplo do MacDonalds, onde a atividade é particionada de forma que cada um possa saber simplesmente uma parte do processo, sem ter noção do todo e sem tomar nenhuma decisão. Essa linha de raciocínio, segundo ele, denota das idéias da administração de Taylor e Fayol, chamado de modelo clássico.

Neste momento, comecei a pensar sobre os modelos tradicionais de desenvolvimento de software (inclusive o adotado na empresa que trabalho ) em contrapartida com o modelo Ágil. No modelo tradicional, são criados inúmeros papéis, com um particionamento claro de responsabilidades. Onde trabalho, por exemplo, temos analista de negócios, analista de sistemas, testador, arquiteto e programador. No modelo ágil, o número de papéis se reduz e a definicao das responsabilidades normalmente é um pouco mais flexível.

Diz-se que metodologias ágeis somente são eficientes quando aplicadas em times de pessoas altamente qualificadas, o que realmente não é a realidade da maioria das empresas. Normalmente se contrata uma pessoa extremamente talentosa para cada 4 menos talentosas e se monta uma espécie de "esquadrão de elite", onde as regras são definidas por esse esquadrão para os incautos. Essa desproporção de talentos na verdade se justifica pelo custo, pois o salário de um desenvolvedor talentoso é normalmente bem mais alto que o dos outros.

Conclui-se que a criação de metodologias burocráticas surge como uma tentativa de reduzir os erros e aumentar a qualidade do software produzido sem gastar mais com contratação, certo?

Daí vem meu questionamento...será que o custo de criação de papéis extras, metodologias burocráticas, aquisição de ferramentas para BPMN, BPEL, UML e Gestão de Requisitos, tempo gasto no cumprimento das regras definidas para formatar o comportamento dos menos talentosos não supera o custo de contratação de uma equipe formada por programadores mais talentosos que pudesse utilizar uma metodologia mais enxuta?

Penso que vale a reflexao...

Obsolescência

Com a compra da Sun pela Oracle, diversas pessoas entre elas alunos da graduação, alunos da pós-graduação e colegas de trabalho me perguntaram o que eu achava que aconteceria com o Java. Honestamente ainda não tenho opinião formada, mas se tivesse que dar um palpite, diria que:

1) a ORACLE nao vai abandonar o Java e continuará a dar suporte (com o mysql eu penso que o futuro é um pouco mais nefasto);
2) se a ORACLE decidir fechar uma versão proprietária, acredito que a comunidade passará a dar continuidade ao que hoje conhecemos como Java;
3) Ultimamente, Java tem perdido bastante terreno em relação ao .net. Na minha opiniao um dos fatores que ocasiona isso é a lentidão na evolução da plataforma por conta da insistência exagerada em backward compatibility (quem não lembra da novela que foi o generics?). Penso que a ORACLE poderá acelerar um pouco a evolução...e acredito que isso seja benéfico;

Independentemente do que acontecerá, é supreendente a dificuldade que as pessoas têm em aceitar a mudança. "E agora...continuamos aprendendo java na faculdade?" "Ainda vale a pena a certificação?"

Inicialmente, pode-se dizer que java é, na minha opiniao, a melhor linguagem para estudar POO sem ficar na visão simplesmente acadêmica. Acho o C# um pouco agressivo e o Smaltalk pouco prático. Lembrando o que um professor me dizia: O importante é o conceito...a tecnologia mudará sempre.

Outro detalhe é a questão da própria atualização profissional...Delphi morreu já há algum tempo e deixou sabe-se lá quantos programadores órfãos. O mesmo acontecerá com Java? Será que essas pessoas pensavam que iriam tirar o SCJP, o SCJD e dai deu? Ou será que elas imaginavam trabalhar com java para sempre?

A obsolescencia é a pior coisa que pode acontecer a um profissional de TI. Sabe qual o principal sintoma? O profissional de TI dificilmente fica muito tempo em uma mesma atividade pois é normalmente movido por desafios. Se a empresa não consegue identificar isso ( lembra de meu post sobre os geeks? ) o profissional muda de emprego. Quando voce não pode mudar de emprego pois tem medo de não conseguir outro caso perca o atual, isso representa um sintoma claro de obsolescencia (ou de ter escolhido o tema errado pra se especializar :) ).

A nossa área é extremamente dinâmica e todo profissional de TI, desde o formatador de HD até o Gerente está sujeito a ter que aprender constantemente, às vezes em um ritmo quase sobre-humano (francamente cansei de tentar acompanhar os frameworks da moda). O importante é estar disposto a enfrentar estas mudanças. Java morreu? Que pena...bom, vamos ao próximo tópico de estudo...Se voce não reconhece esta como uma rotina prazerosa, desculpe mas voce está na área errada.

KISS ( keep it simple s... )

Atualmente estou lendo a segunda versao do Effective Java do Josh Bloch e ao passar por algumas partes, relembro alguns conceitos básicos de Java e OO que acabam passando despercebidos aos que estao começando a estudar a linguagem e mesmo a programadores experientes, seja por distração ou por desconhecimento.

Um exemplo simples são os modificadores de visibilidade e o encapsulamento. Quando se define uma classe que não é nested (interna), os dois únicos modificadores possíveis de serem utilizados são o public e o default, chamado de package private pelo Josh Bloch. O default (sem modificador) define a visibilidade somente no pacote onde a classe está definida. Por que isso é importante? bom...pra inicio de conversa, 90% dos exemplos em java que vemos por ai comecam com public class NomeDaClasse, inclusive os exemplos que passo aos meus alunos de java. O encapsulamento define que somente o que é essencial deve ser exposto ao resto do mundo e, portanto, antes de sair por ai colocando public em tudo que é classe, deve-se ter o bom senso de analisar se essa classe será utilizada fora do pacote.

Se a classe for utilizada, coloque public sem medo, somente tome cuidado com o acesso a membros. Se a classe for utilizada somente no pacote, tire aquele public dai imediatamente.

Por vezes voce acaba criando um FACADE para expor a funcionalidade e nesse caso, fica ainda mais visível a utilização desnecessária do public como modificador na classe.

O puxão de orelha serve para mim também, visto que meus exemplos de aula também, em sua maioria, começam com public class...

Outro aspecto importante é a utilização de Herança. Esta é bem mais simples...sua classe foi criada pensando na herança? Se sim, implemente-a como tal, se nao, simplesmente marque-a como final (ou sealed...). Se ela não foi criada para essa finalidade, impeça-a.

Voce se torna refém de tudo que expoe ao mundo externo e para fins de compatibilidade, acabará tendo que manter esse codigo.

Pra resumir a conversa...
1) cuidado com a utilização correta do encapsulamento;
2) leia o Effective Java, o livro é indispensável aos programadores java;
3) vou alterar meus exemplos de sala de aula;

Entendendo o Usuário.

Cortesia de meu amigo Frank, (atualmente maratonista ) que está indo fazer doutorado em Portugal...