Salvador Dali, 1931 - The Persistence of Memory

Já conversei com pessoas que batem o martelo facilmente dizendo:

- É por tempo.  Eu programo em brainfuck há seis anos, logo sou sênior.

Será mesmo ?

Em tempos modernos, fica ainda mais complexo fazer uma avaliação deste tipo para programadores, arquitetos ou engenheiros de software, pois, não é somente uma linguagem de programação que está em análise. É todo um contexto que abrange desde a escolha do ambiente de desenvolvimento até relacionamento com stakeholders e domínio em metodologias e paradigmas de desenvolvimento.

Se temos a análise temporal como inválida, então o que espera-se de um dito sênior ?

Para tal, conversei com três pessoas que estão diretamente envolvidas com estes aspectos.

Creio que sim. Existem os profissionais seniores, porém muitas pessoas, e empresas, acabam confundindo o nível do profissional com o seu tempo de experiência.

Em minha visão, o tempo de experiência é importante, porém, não determinante para rotular um profissional, ou seja, é perfeitamente possível existirem seniores com 3 anos de experiência e juniores com 15 anos.

O profissional Júnior, é aquele que já desempenha as tarefas com certa autonômia, porém, necessita de um maior tempo de pesquisa e em alguns casos de orientação.

Por sua vez, o pleno já demora um tempo menor para realizar as mesmas tarefas além de não necessitar de orientações referente aquela tarefa. O que difere o pleno de um sênior é a visão holistica, ou seja, para ser um profissional sênior é preciso possuir habilidades complementares as necessárias para o desenvolvimento daquela tarefa, isso ajuda acima de tudo no desenho de uma melhor solução além de maior facilidade no tratamento de problemas.

Outro ponto que vale ser observado, é que muitas vezes o sênior é destacado para tarefas simples, que não exige um conhecimento avançado, como seguir um procedimento de criação de usuário. Esse fato, além de desmotivar o profissional, gasta recursos de forma imprudente, já que são os seniores que deveriam criar os procedimentos a serem seguidos, além de desenhar soluções para problemas e corrigir falhas críticas ou em serviços críticos.

Vinícius Bufoni, coordenador de engenharia web na Vex

Este é um assunto interessante. Na maioria dos lugares as pessoas usam “anos de experiência” como medida para classificar. Esta é, na minha experiência, uma das piores maneiras de se fazer este tipo de classificação. Uma pessoa que desenvolve em, digamos, JSP e Servlets Java por 10 anos não necessariamente tem 10 anos de experiência desenvolvendo software, ele tem experiência desenvolvendo JSP e Servlets! E mesmo assim, tempo gasto em uma tecnologia não está diretamente relacionado com proficiência nesta. Enfim, utilizar tempo para medir experiência é, normalmente, uma besteira.

A forma com que eu tenho lidado com esta relação entre níveis de desenvolvedores, atualmente, é usando algo chamado modelo Dreyfus de aquisição de conhecimento: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition .

Normalmente eu tenho as áreas em que eu considero que meu time deve ser competente (este post: http://fragmental.tw/2009/11/24/i-wish-i-knew-that-before-getting-this-job-–-slides-and-long-notes da uma idéia sobre quais seriam estas áreas) e uso o Dreyfus para tentar entender onde cada um está nestas competências. Tem funcionado relativamente bem para mim mas ainda é, como sempre será, problemático e, por muitas vezes, injusto.

Phillip Calçado, consultor na ThoughtWorks

Do meu ponto de vista um profissional sênior é acima de tudo auto suficiente, é o tipo de profissional em que você não precisa passar o que deve ser feito, ele geralmente entende seu papel em uma equipe e como pode contribuir.

Um profissional Sênior consegue tomar decisões e assumir responsabilidades, ele não depende de alocações e precisa de muito pouca supervisão gerencial e técnica.

Geralmente um profissional Sênior também, está sempre atualizado e esta sempre ligado em tendências do mercado e em como adaptar estas novidades a sua realidade nos projetos em que esta envolvido.

“Tempo” de experiência na verdade não é tão importante, mas a diversidade e intensidade da experiência da pessoa é extremamente importante, se ele esteve envolvido uma grande diversidade de projetos e atuou em papeis dos mais diversos, um profissional sênior geralmente consegue se adaptar pois já trabalhou em diversos papéis e com diversos times.

No caso de grandes empresas de Internet, como o Yahoo!, é vital que o profissional sênior entenda de e tenha tido vivência com projetos de grande escala, e que entenda de Sistemas, arquiteturas e plataformas que funcionem com grandes volumes de acesso e demandam muita performance.

Não gosto muito destes rótulos, mas um profissional Pleno depende de um nível de supervisão/apoio maior. Um Pleno também tende a ser mais inseguro na tomada de decisões e definições mais complexas.

Mas a principal diferença é a experiência, bagagem de conhecimento. Em entrevistas sempre pergunto qual foi o maior desastre da carreira da pessoa, espero que ele me diga quais foram os erros e o que ele aprendeu com isso. Isso mostra maturidade em relação a tentativa/erro, onde não se deve temer cometer erros e que sempre devemos aprender com eles e continuar tentando. Isso é chave para ser inovador.

Antônio Carlos Silveira, diretor de Produto e Engenharia, Yahoo! América Latina

Cada um tem seus métodos de análise, mas ficou evidente que contar os dias no calendário já não é mais tão convincente como parecia

Random Hack of Kindness São Paulo 2010 por danicuki

Eventos como Yahoo! Open Hack day; Google Developer Day; o recente Random Hack of Kindness; Coding Dojo (o de Sampa no IME da USP está meio inativo ao que consta); e vários outros movimentos iniciados até por empresas, como a própria Caelum que já abriu as portas para criar um ambiente onde programdores pudessem se juntar e desenvolver suas coisas, ou mesmo que fechado ao grupo de programadores da mesma como já ouvi relatos de programadores.

O que leva esse bando de programador malhucos das cavernas a participarem com empolgação destes eventos – muitas das vezes apenas com free lunch e Internet 0800 ? São desocupados ? Loucos ?

Yahoo! Open Hack Day Brazil 2010 por Antônio Carlos

Simples: adoram o que fazem ! São essas pessoas que geralmente criam tendências, aplicam ideias e tomam iniciativas nas corporações em que trabalham; São os mesmos developers que passam horas a fio programando com vários livros de nomes nonsense à tira-colo; ou que criam projetos pessoais para suprir uma necessidade própria e acabam chamando a atenção de muita gente – vide tantas startups bem sucessidas criadas e mantidas por programadores.

Geralmente esses mesmos programadores conhecem pelo menos duas linguagens. O motivo ? Curiosidade ! Pouco importa se Ruby on Rails fará sucesso no mercado coorporativo ou se Python não agrada o chefe. É legal para eles, então, investem tempo nisto.

Sempre em busca de novos conhecimentos, fanáticos pela arte em programar e fazer coisas novas; de novas formas e com novas ferramentas. Criam coisas, compartilham o feito e ainda passam a diante o novo conhecimento com artigos, blogs ou seminários. São programadores sempre motivados que buscam fazer uma análise crítica sobre suas próprias formas de programação buscando a evolução das ideias.

Vida social ? Muito bem, obrigado ! Nestas idas e vindas acabam conhecendo pessoas, lugares e oportunidades diferentes. Trocam ideias, conversam, trocam contactos das redes sociais; juntam-se em botecos ou equivalentes tornando o simples ato de programar em grupo em praticamente uma festa completa !

1.”The early years”.

O meu primeiro computador veio tarde, foi um 386, mas foi o suficiente para me introduzir no mundo dos computadores e me deixar completamente fascinado. Quando comprei meu primeiro modem foi que a coisa começou a tomar força, acessava as BBSs e quando finalmente a internet apareceu, tive certeza o que queria fazer da minha vida.

Desde cedo comecei nos esportes, durante vários anos fui atleta profissional, nadava duas vezes ao dia, de segunda a sábado. Começava de madrugada, das 5 às 6:30, a tarde, das 4 às 5 tinha preparação física, e das 5 às 7:30 era o treinamento principal na água. Eu nadava em média média 12 a 14km por dia.

Meu primeiro livro foi a história do Kevin Mitnick, não deu outra, ele foi minha maior referencia e inspiração na infância/adolescência, comei a estudar programação, Linux, BSD, montei um grupo hacker, comecei a andar com os melhores hackers do Brasil e além da natação, computador era uma das coisas que eu mais gostava no mundo.

Nunca fui bom aluno, sempre achei um saco a escola e a forma como ensinavam as coisas. Tomava broncas homéricas quando meu boletim chegava. Um dia, para deixar meu pai feliz, larguei a coisa mais importante da minha vida, para mostrar o quanto eu estava empenhado em estudar. Saí da natação e resultado, nada mudou. Só que mais tarde eu entendi que tudo aquilo foi importante para eu ingressar no mundo profissional. Deixei de ser hacker e comecei a entender como o mundo dos negócios funcionava. Mergulhei no software livre, que acabou me abrindo todas as primeiras portas.

2. Totalmente direto quando o assunto é Java. Por quê tamanho desdém por uma das linguagens mais utilizadas no meio corporativo ?

De jeito nenhum, deixei de ser radical ainda novo, acho o Java uma excelente linguagem e plataforma de desenvolvimento, foi responsável por uma expansão brutal do nosso mercado, mas infelizmente em todos os problemas que eu encontro na vida, existe uma solução mais interessante que o java. Você que trabalha comigo aqui na Vex, sabe que temos uma área web, outra de redes, outra de sistemas embarcados e agora teremos aplicativos desktop e mobile e mesmo assim o Java não entra como minha primeira opção em nenhuma delas.

3. Como um bom programador você deve possuir uma linguagem que tenha mais afinidade e como consequência, habilidade. Qual seria e por quê ?

Depois de tantos anos programando, percebo que não existe uma linguagem que te acompanha para o resto da vida como sua melhor linguagem, em cada momento ou fase da minha vida eu tive uma linguagem de programação mais presente, a que até hoje nunca foi superada na minha opinião, o C, mas tem suas aplicações limitadas, obviamente eu não usaria e não uso C para uma serie de aplicações, mas considero uma linguagem pura e eficiente, elegante quando bem utilizada. Em linguagens de script para servidor, gosto muito do Python. Para desenvolvimento web, confesso que o Rails tem roubado os meus holofotes. Programei muito em muitas outras linguagens, de Assembly a Visual Basic ou Delphi, acredite, programei nessas linguagens. Mas teve fase da minha vida que fui apaixonado por Lisp. Também fui apaixonado por C++ e PHP e também programei bastante no quase falecido Pascal.

4. De developer à manager. Você tinha como objetivo este “desvio” na carreira ou chegou como uma boa oportunidade ?

Nunca tive a pretensão de ser chefe, mais importante ainda, nunca tive interesse em ser chefe. Sempre fui extremamente técnico, minhas leituras sempre foram regadas a tópicos bem profundos da tecnologia. Por este motivo eu admirava empresas gringas que valorizavam bons engenheiros, eu imaginava que poderia continuar como engenheiro e ainda assim ter um nível salarial comparado a um gerente ou diretor. Mas ei, eu estava no Brasil, a cena de tecnologia era praticamente nula, eu tive que mudar minha mentalidade e subir a escadinha dos cargos, hoje eu sei que as coisas são bem diferentes e hoje já é possível ser um eterno engenheiro com um bom salário, ainda não é fácil, pois são raras as empresas que dão boas condições no Brasil. Mas desde então passei a estudar e aprender este outro mundo, marketing, finanças, vendas, gestão de pessoas, política, etc. Ainda bem que eu tive essa vontade de ser eterno engenheiro e não consegui, assim como várias outras vontades na minha vida que eu não realizei, hoje todas elas são minhas metas de vida, para tornar isso realidade para alguém. Pratico hoje o que eu busco amanhã, meu funcionário ideal é aquele que tem amor incondicional pelo que faz, assim como eu tive e tenho pela tecnologia.

5. Seguindo a nomeclatura do mercado, temos cargos baseados em níveis por, em teoria, conhecimento: Júnior, Pleno e Sênior. Assumindo que você está em busca de um profissional dito sênior, qual seria sua forma ou metodologia para tachar Foolano ou Ciclano adequado ao título ?

Vale lembrar que eu sou totalmente contra as formas tradicionais de organização de recursos humanos, muitas empresas acabam errando ao fazer isso. Falando especificamente de engenharia de sistemas, o conhecimento técnico é sempre um pré-requisito para um sênior, um candidato que se propõe a trabalhar com um determinado assunto e não domina completamente o assunto é eliminado imediatamente. Além disso, o cargo Senior pressupõe que o engenheiro tem muita experiência prática, escreveu centenas de milhares de códigos, passou por dificuldades em diversos tipos de sistemas diferentes. Mas eu ainda assim penso que cada pessoa é única, não pode ser tratada genericamente, já tive gênios na minha equipe que eram completamente loucos e anti-sociais, impossíveis de trabalhar em equipe, uma maçã podre que todos nós sabemos qual destino tem. A história de vida de cada um tem importância, outras aptidões, estilo de vida, equilíbrio e controle emocional também formam um profissional Sênior.

6. Mantendo a linha sob o foco de níveis em cargos, quais seriam as diferenças fundamentais entre um programador pleno e sênior ?

Este é tema para um artigo, mas resumidamente, eu gosto de definir as características para cada um dos cargos, aplicar uma pontuação a cada uma delas e definir os interva-los para os cargos propostos, como você mencionou poderia ser Junior, Pleno e Sênior.

Por exemplo:

1. Formação acadêmica (x pontos)
2. Linhas de código escrita (y pontos)
3. Tempo de experiência (z pontos)
4. … (n pontos)

• Junior – 10 pontos
• Pleno – 20 pontos
• Sênior – 30 pontos

Essa metodologia funciona muito bem se muito bem testada e validada, mas como mencionei acima, muitas empresas utilizam algo similar de forma completamente errada. Quantas empresas que conhecemos que definem para um engenheiro de sistema que a formação acadêmica é um pré-requisito? Um detalhe besta que faz com que perca-se pessoas brilhantes. Vale lembrar o que eu já mencionei várias vezes, os melhores programadores que eu conheci na vida não tinham formação acadêmica.

7. Com o “boom” das metodologias ágeis, começaram a preocupar-se mais com processos de desenvolvimento de software. O que temos atualmente, porém, são muitas empresas sem processos e metodologias mesmo que primárias para gerenciar a produção (de software). Como gestor, qual sua visão sobre esta falta de processos e qual a solução que você indicaria para uma possível adoção ?

Quando eu comecei a trabalhar não falava-se muito neste assunto, anos mais tarde eu me vi em meio a implantação de ISO 9001 e CMMI. O CMMI é uma das coisas mais radicais que eu vi na vida, impraticável, não se da um peido sem levantar os requisitos, prazo, riscos, conseqüências e pedir permissão e após autorizado registrar em log, relatórios, lições aprendidas, etc. Sou totalmente contra alguém fazer algo do tipo, pelo jeito muitas pessoas são, não foi a toa que surgiu as metodologias ágeis, que se preocupa somente com o que realmente funciona. Meu conselho para este de prática é, aprenda as melhores, utilize somente o que fizer sentido. Não seja radical, pois as vezes a melhor metodologia é não ter metodologia.

8. É comum ler pela rede a seguinte expressão: “Desenvolva para mudanças”. Para tal, é fundamental o foco na qualidade do software produzido/mantido. Apesar de óbvio, não é isto que realmente acontece. A qualidade, no mundo real, é sim um fator “negociável” e por isso falhas, insatisfação do cliente e o retrabalho aumentam drasticamente. Em seu ponto de vista, qual o problema em fazer da qualidade uma constante ao projetar software ?

O dia em que o chefe absoluto da sua empresa for um engenheiro que passou por tudo isso que você esta passando, pode ser que isso não mais aconteça.

8++. Como você tem mantido organizadas atividades profissionais na Vex e projetos pessoais ? Utiliza-se de ferramentas ou técnicas de organização pessoal ou tem mantido tudo nos renomados checklists (i.e. Remember The Milk) ? E como tem feito uso de tais ferramentas ? (dica de @chanelym)

Já inventei muito para me organizar, hoje eu posso dizer que eu alcancei uma forma prática e funcional de me organizar bem. Eu pratico muitos conceitos do GTD e tenho duas principais ferramentas, um gerenciador de tarefas, utilizo o Things (http://culturedcode.com/things/), que me acompanha em meus computadores, iPhone e futuramente no iPad, e um bom calendário (iCal), paralelamente utilizo muito o AddressBook, tudo sincronizado com Push.

Chegou a hora delas, as palavras finais…

Novamente, obrigado por aceitar o convite
Parabéns pela iniciativa do blog, continue sempre escrevendo, foi um prazer responder a sua entrevista. Boa sorte e continue firme e forte, pois enxergo em você um potencial muito grande.

Meu blog empoeira às vezes, mas para quem quiser visitá-lo: http://blog.marcelotoledo.org.

Bacharel em Ciência da Computação, trabalha como Java Developer/IT Specialist em um projeto internacional na IBM – Hortolândia-SP.

1. Cientista da computação e trabalhando com Java. Como foi seu primeiro contato com essa área e qual foi o motivo – se é que houve motivos especiais – que a motivou a seguir em frente ?

No começo sempre quis seguir a carreira de direito, mas não gostava de decorar história pra passar no vestibular. Resolvi mudar para a área de exatas, pois sempre gostei muito de física e matemática, e entre as carreiras possíveis escolhi ciência da computação pois sempre gostei de explorar o computador desde que ganhei o meu primeiro, aos 10 anos de idade (e o coitado vivia no conserto por causa disso! rs).

Entrei na faculdade sem nem sequer saber que raios era a tal da programação. Tive um pouco de dificuldade no início, para aprender lógica de programação, mas decidi que iria aprender aquilo de qualquer jeito e comecei a estudar bastante. Chegava a estudar lógica por umas 5 horas/dia no primeiro período da faculdade. Até que no final do período já tinha gosto por programar em portugol e não sentia mais dificuldade, aprendi a “manha”.

Minha primeira linguagem de programação foi Pascal, mas tinha muitas limitações. Depois ouvi sobre o tal de Java (na época java estava super na moda). Uma professora sugeriu começar um grupo de estudos fora do horário da faculdade para aprendermos a linguagem. E aí fiquei apaixonada e até hoje mantenho esse “casamento”.

2. Ao que consta, o primeiro programador foi na realidade uma programadorA – http://en.wikipedia.org/wiki/Programmer -, porém, mesmo assim o espaço das programadoras é bem pequeno. Acha que há algum tipo de impedimento ou preconceito que esteja dificultando mais programadoras ?

Essa é uma questão que há anos intriga os pesquisadores da área. A escassez da participação de mulheres não ocorre apenas na computação, mas em qualquer carreira científica. A taxa de mulheres na graduação de exatas sempre foi baixa, mas depois de 2000 esse número descresceu ainda mais.

A ACM e a SBC estão bem empenhadas para divulgar e tentar trazer mais mulheres para a área.

Na minha opinião, o que ajudaria muito seria introduzir o estudo da programação básica ainda no ensino médio, pois é nessa época que começamos a pensar em qual profissão iremos seguir carreira. Assim, mais garotas (e também garotos) ficariam atraídos pela área, e muitos decobririam aptidão e vocação que às vezes nem sabem que têm.

3. Eu já pude ver algumas pessoas um pouco decepcionadas com as provas de certificação da Sun para a linguagem Java – o que não inclui a SCEA, claro – Você inclusive foi uma delas Essa forma facilitada está fazendo a certificação perder seu valor “no mercado” tornando-se um belo quadro ou elas ainda tem seu valor para o profissional ?

A certificação nunca tem o objetivo de desvalorizar o profissional, muito pelo contrário. O que acontece com a certificação da SUN é que atualmente, ficou muito fácil de passar. Bastam 2 meses de estudos e decoreba que você passa, ou seja, “qualquer um” consegue uma certificação SCJP, até mesmo quem nunca programou em Java.

Vamos ver se com a reformulação da Oracle isso vai mudar agora. O que eu acho que a maioria dos profissionais java esperam, é que seja cobrado na certificação problemas e cenários presentes no dia-a-dia de um profissional java, valorizando a experiência, e não apenas decorar para daqui a um mês esquecer tudo.

O que quero deixar bem claro é: se tiver vontade de tirar a certificação por você mesmo, ou seja, para aprender mais sobre Java, vai fundo, porque você vai ser valorizado por isso. Mas se quiser tirar a certificação só pra colocar no currículo (decorar pra passar), não é o fato de ter a certificação que vai ajudar a conseguir um emprego, até porque fora do Brasil, certificação da SUN não é muito valorizada, aliás, os caras lá fora nem vão ler o seu currículo, só irão te entrevistar pra ver se você realmente sabe o conteúdo.

Essa é minha opinião pessoal. Esse assunto é um pouco complicado de abordar, já gerou várias brigas em listas de discussão, é igual política, cada um defende um lado! rs

4. Há várias aplicações, inclusive Bancos, que utilizam o Java no backend e fazem integração para rodar PHP como frontend dessa aplicação Java. Como você enxerga este fato ? Pelo que sei, esta parte é uma das mais “XML based” dos padrões JEE. Há implementações JEE que trabalham seguindo a linha “Convenção sobre Configuração (CoC)”, trazendo uma boa melhoria eliminando tanto XML. Mesmo assim, o modelo Controller (Servlets) e View (JSP, JSTL) do JEE é visto como um problema para a comunidade ou acredita que haja outros motivos para essa adoção hibrida ?

Acredito que essa mixagem de linguagens se dá por alguns fatores:

O contra do PHP nesses casos é a fraca implementação OO, o que leva a pouco reaproveitamento de código e dificulta a manutenção por isso. Porém, a curva de aprendizado do PHP é pouco íngreme. Por outro lado, temos o Java, com implementação OO bem forte, mas a curva de aprendizagem é longa e íngreme. Sem contar o fato que ás vezes, muitas empresas não migram totalmente seus sistemas para Java justamente por esse fato, o que resultaria em alto custo de treinamento dos funcionários.

Hoje há uma certa flexibilidade entre linguagens e diferentes sistemas, então é legal explorar esse lado e usar o que cada linguagem tem de melhor para oferecer.

5. Trabalha especificamente com Web. Qual o motivo da escolha pelo Java ?

Comecei com Java no meu estágio e depois nunca parei. Meu trabalho foi sempre voltado para web, que acredito ser a maior demanda hoje, independente de linguagem. Me colocaram para trabalhar com web e aqui estou – só trabalhei em um projeto desktop até hoje. Gosto bastante da área, bem eclética, há centenas de recursos que pode-se usar, às vezes fica até difícil escolher o que usar.

Java oferece vários recursos nativos da própria linguagem, além de vários frameworks no mercado, como Spring, JSF, Struts, Vraptor (um brazuca que é ótimo). Sem contar com a mixagem de frameworks que se pode fazer, tanto no lado servidor, quanto no lado do cliente (browser).

6. No seu blog é fácil perceber que há vários artigos sobre o lado frontend de uma aplicação. É sua preferência ? Por quê ?

No último ano troquei de empresa e tive oportunidade de aprender novos frameworks. Sempre trabalhei muito com código do lado servidor. Nessa nova experiência, tive oportunidade de trabalhar com código do lado cliente (browser) e aprendi mais javascript. Comecei a aprender ExtJS (framework javascript) e JQuery, que são maravilhosos e poupam muito o tempo do desenvolvedor.

Hoje divido meu tempo entre frontend e backend. É legal porque nos torna um profissional mais completo. Profissional java web, além de saber Java e frameworks, também tem que saber javascript, HTML e CSS, senão fica um profissional incompleto. Temos que desenvolver a aplicação pensando no usuário (que pensa que é mágica que acontece por trás da tela!), por isso também gosto do frontend.

No meu blog faço um log de algumas coisas que estou aprendendo, estudando. Às vezes é fácil encontrar na internet aquele exemplo bem básico, mas quando precisa fazer alguma integração com outra tecnologia é mais complicado de encontrar. Faço meus testes e publico no blog, assim, quando precisar novamente daquilo já tenho um passo a passo pronto, além de poder ajudar outras pessoas que podem ter as mesmas dificuldades.

7. A Oracle já colocou sua “cara” nos sites que pertenciam a Sun. Essa aquisição trouxe temores à comunidade Java ? O que esperam do futuro da linguagem ?

Há muita coisa sobre a Oracle que a gente ainda não sabe. Acho que só esperando pra ver. A Oracle já comprou várias empresas e muita coisa mudou para elas, mas acho que nenhuma compra foi tão importante e deu tanto o que falar quanto a compra da SUN.

Uma coisa já sabemos: a Oracle vai continuar com o suporte aos JUGs – grupos de usuários java. Enviaram uma carta aos JUG leaders. A nossa preocupação agora é se esse suporte vai ser tão bom quanto a SUN nos dava. Pelo menos foram bem receptivos com a gente.

Recentemente anunciaram algumas mudanças na certificação. Isso pode trazer tanto pró como pode ser contra. A Oracle tem a fama de precisar fazer curso para tirar certificação, o que seria ruim. Por outro lado, talvez mudem um pouco o processo da certificação e a melhore, trazendo de volta o status que uma certificação Java tinha antigamente.

8. Já estive presente em seminários “Javeiros” e foi comum ouvir horrores sobre o PHP. Mesmo sendo ele tachado como “ridículo” pelos Javeiros, a adoção dele por empresas de gente grande é elevada – Yahoo!, Flickr (agora Yahoo!), Last.fm, Digg, Facebook, … – além das recentes “amizades” com Microsoft e Adobe. O que você pensa sobre esse #flamewar que o pessoal do Java faz contra o PHP. #off : (olha lá, sou developer PHP, hein !? =P ) /off

Flamewar não faz bem para ninguém. Há muitos desenvolvedores que são apaixonados pela linguagem, como os profissionais Java. Mas ser radical é ridículo. As pessoas precisam aprender que a linguagem é apenas uma ferramenta de trabalho. Java pode ser melhor para certos tipos de sistemas, PHP para outros, C/C++, C#, Ruby, Cobol, e assim por diante.

Uma linguagem não é melhor do que a outra, temos que saber usar e saber o que aplicar para cada tipo de situação.

Não adianta eu falar que PHP/Java/C# é a melhor linguagem do mundo sendo que preciso desenvolver um sistema para mainframe. Nesse caso, não há linguagem melhor do que cobol. E aí?

Hoje as empresas não buscam mais aquele cara que só sabe uma linguagem. Para se destacar hoje no mercado, é preciso ser um profissional “multi-línguas”. Aquela pessoa que for muito xiita, não vai se sair muito bem…

8++. Entre os developers Java, parece que há uma certa afinidade com o Ruby (e o Rails) que carrega a bandeira ágil, o qual possui um manifesto criado por dezessete developers muitos deles developers Java. Qual é a explicação para essa afinidade em seu ponto de vista ?

Ruby é a linguagem do momento, da moda, que as pessoas dizem ser a linguagem do futuro. Ruby tem vários recursos incríveis, além de ser rápida para codificar. Como já citei na resposta anterior, hoje o profissional procurado é aquele que não tem problema de se adaptar para usar uma outra linguagem, ou várias ao mesmo tempo. O “in” é usar o que tem de melhor de cada linguagem para construir um sistema mais robusto, mais potente. E com certeza Java e Ruby é uma ótima combinação!

"Java printout por Ngọc Hà @ flickr"

Naquela época era claro para mim que programação era algo relacionado à área de exatas, pois criar uma aplicação é algo lógico tendo envolvimento direto com matemática e tudo mais.
Em coisa de um mês e pouco já conseguia fazer até uns “SQLs” e montava sites no estilo macarrônico de desenvolver. Aquilo para mim era fantástico! Tinha como objetivo aprender bem a linguagem para assim conseguir minha certificação da Zend, tornando-me assim um programador profissional.

Aconteceu porém, algo inesperado: comecei a “seguir” – não era no Twitter, até porque ele ainda era um protótipo de projeto na época – pessoas realmente profissionais em desenvolvimento de software e eu percebi assim que o buraco era mais embaixo e que eu ser excelente em uma linguagem era apenas um dos passos para tornar-me um programador profissional.

Abrindo um parênteses, eu li através do @sergioprado, não lembro onde agora, uma frase interessante e que tem como tradução algo como:

"O caminho para tornar-se mestre: siga o mestre; ande com o mestre;
torne-se o mestre."

Após começar eu a seguir os mestres, pude perceber que programação vai muito além da leitura de um requisito funcional de software e fazer daquilo algo sistêmico. Hoje, arrisco-me a dizer que programação não é algo somente relacionado à exatas. Possuí também, questões éticas – humanas – e artísticas.

A programação é relacionada a área de exatas

Isso é bem claro aos envolvidos em desenvolvimento de software. Você lê um problema descritivo, vulgo especificação funcional, ou visual (UML, rabisco na Moleskine, whatever) e faz daquilo algo sistêmico e que agregue valor ao negócio de seu cliente.

Como premissa você precisa aprender uma linguagem. Conhecer uma linguagem bem não é nada fácil. Você precisa empenhar-se para conhecer as intrínsecas e peculiaridades para aproveitar o melhor dela, tornando-se um especialista na linguagem. Eu valorizo mais um programador excelente em uma linguagem a um que já “trabalhou” com várias. Não é impossível uma pessoa ser excelente em mais de uma linguagem, mas isto, porém, demandaria muito tempo de dedicação para atingir tal nível.

A programação é relacionada a ética

Toda área tem suas condutas éticas e humanas, óbvio. Em programação, porém, vejo muitos ditos programadores ignorando isto. Quando você troca qualidade por falso ganho de tempo, você está sendo antiético. Quando não analisa corretamente as decisões que irá tomar em cima de algum problema, falta-lhe ética. Quando deixa de atentar seu cliente, o que inclui seu chefe, sobre a ausência de segurança, qualidade ou algum problema em cascata que venha a aparecer em decorrência de uma atitude, você está sendo antiético.

E isso acontece em demasia em nossa área! Seja por falta de interesse por parte do dito programador ou mesmo por medo de perder o emprego/projeto por “afronto” ao seu chefe ou cliente.

Para conhecer as técnicas, metodologias e artimanhas no desenvolvimento de software é necessário antes, ter uma boa noção de análise e projeto de software; arquitetura de aplicações; padrões e melhores práticas, para, após criticar uma atitude antiética de seu chefe/cliente, você ter total embasamento para propor a solução sem comprometer o projeto nem a aplicação. Isto será necessário também, para você ter um vocabulário comum para quando estiver numa roda de conversa entre os “mestres” da área.

Importante ressalvar que seu cliente ou chefe pode estar tomando uma atitude antiética, no ponto de vista de programação, inconscientemente. Afinal ele é especialista no negócio, o programador profissional é você!

A programação é também relacionada a artes

Há uma enorme diferença entre criar algo que funcione e criar algo que além de funcionar, transparece o domínio (regra de negócio).

Eu posso saber ler e escrever em português, mas há uma diferença gritante entre um poeta português e eu. Ele, diferentemente de mim, sabe utilizar muito bem as palavras e com elas, faz transparecer sentimentos, idéias e pensamentos sobre determinado tema, trazendo um enredo ao assunto abordado, envolvendo-nos em sua história.

Posso saber desenhar, mas isso não me torna um artista que emociona as pessoas com minhas obras.

Como programadores profissionais é fundamental conseguirmos fazer o mesmo ! É de nossa responsabilidade criar um código simples, legível e que conte toda a história da aplicação através de seus pacotes, classes, métodos, parâmetros, atributos e variáveis. Qualquer coisa diferente disso, não pode ser aceito como código profissional.

Pouco importa se a linguagem X é tachada como mais poluída que a Y. Você como profissional, tem que quebrar essa barreira e torná-la tão legível quanto qualquer outra, afinal, você é especialista na linguagem, lembra ?

Além de criar, é nossa responsabilidade cuidar para que o código continue sempre otimizado por tantas quantas forem as mudanças que nele ocorrer. Criar algo legível recai diretamente sobre isto, pois, no futuro outro profissional em programação poderá continuar seu trabalho sem danificar ou abandonar as premissas cruciais para um bom código. Andrew Hunt aborda o título: “Don’t live with broken windows”, onde resumidamente ele alerta para não descuidarmos da qualidade, pois, basta uma janela quebrada em uma casa para que ela transpareça o estado de abandono, fazendo assim, com que outras pessoas destruam mais janelas.

E como toda arte, não há uma receita para criar bons softwares. É necessário muito empenho, ler muitos códigos, revisar muitos paradigmas ao longo do tempo e claro, programar bastante. Não é possível tornar-se um programador profissional sem conhecimento teórico, tão pouco, sem vivência com erros e acertos.

Ao desenvolver a aplicação, não aceite nada menos do que seu melhor naquilo e atente-se para não cair na armadilha de criar softwares de forma sistematizada. Tenha autocrítica para fazer avaliações em seus próprios códigos e evitar assim, programar por coincidência.

Lembre-se de que será seu nome no @author.

Vex - Setores TI e Operações - Maio 2009

A “ideia” de trabalhar fora veio repentinamente, basicamente com um pseudoconvite de meu amigo de longa data @Otata, que já estava trabalhando por lá e disse-me não por uma, nem duas, mas algumas vezes, de que a Vex estava contratando mais developers para fechar o time e que era para eu enviar meu “currículo”.

Após enviar meu currículo para o pessoal, houve os tramites default de conversa por telefone, entrevista pessoal, a renomada provinha tira-teima e no final do dia após enviar meu currículo estava ingressando no time.

Algo que achei peculiar foi a rápida contratação – comigo pelo menos. Tudo bem que houve ele, o QI, mas fiquei surpreso com a confiança que recebi dos coordenadores, afinal eu era até aquele momento um freela de cabelo comprido e que morava há alguns quilômetros de distância da empresa.

Ambiente

Vex - Galere Web - Maio 2009

Obviamente, totalmente diferente do até então escritório-casa que eu trabalhava enquanto freelancer. A adaptação não foi um problema, pois na Vex eu também utilizo notebook para desenvolver plugado à um monitor externo quase nos mesmos moldes que tenho em meu home office.

Por não recebermos visitas de clientes no prédio, podemos ir com roupas menos formais. Isso não quer dizer que eu possa ir de bermudas ou chinelos igual já tentaram fazer por lá

No andar do desenvolvimento, há também o pessoal de sistemas embarcados e redes. O relacionamento com todos sempre foi bem tranquilo, mesmo quando saía uns flamewars do tipo: Python vs PHP; Zimbra não é Yahoo!; e todo mundo contra o @Otata.

Vex - Junho 2009

Durante esse período uma coisa ficou clara: a empresa movimenta-se bastante. Houve pessoas entrando; pessoas mudando de área, pessoas deixando a Vex e até, pessoas que saíram e estão retornando novamente. As saídas, do ponto de vista pessoal, são ruins, pois todos no andar tem um contato diário, uma amizade e que depois de sua saída o contato praticamente se extingue.

Os PHP’ers

Vex - Galere Webdev (@bufoni)

Vex - Galere Web (@Sugamele)

Se os developers geralmente não batem muito bem das ideias, essa turma bate menos ainda ! (haha, vão me matar com esse comentário). O pessoal na Vex é bem tranquilo e são bem espontâneos. O que surpreende nessa turma são as diferenças: cada um possui seu temperamento, opiniões – muitas das vezes bem diferentes – e suas especialidades. Mesmo com tantas diferenças, nós, que trabalhamos geralmente aos pares ou trios e raramente individualmente, temos um envolvimento excelente nos projetos.

Ao que estive olhando nos logs do controle de versão, passaram aproximadamente 12 pessoas (achismo mode on) pelo time Web durante um período de 4 anos.

Inclusive, o @esampaio, aqui conhecido como meu chefe, publicou um vídeo com o histórico do SVN de um de nossos projetos internos.

Vex - Webdev. @Sugamele e eu - Agosto, 2009

Pela quantidade de pessoas que ao longo desse período trabalharam em cima desse projeto em específico é um pouco previsível o que pode-se encontrar nele. Há coisas realmente muito boas – tanto código quanto solução para um problema – a própria engine de i18n é uma delas, porém, há também coisas desenvolvidas no estilo WOP. (Workaround-oriented programming).

O que me chamou a atenção nessa área é a real vontade do pessoal em evoluir e melhorar os pontos que hoje não estão bons. Quality of Code está literalmente em alta e o princípio “Don’t live with broken windows” (para mais leia o livro: The Pragmatic Programmer) tem feito sucesso.

Quando é necessário atualizar alguma coisa ou sempre que possível – mesmo não estando na lista de prioridades, os códigos obscuros do passado são atualizados, melhorando não só a leitura e documentação (leia-se PHPdoc), mas também o relacionamento daquele módulo com todo o resto. Anima muito ver uma equipe – o que inclui os coordenadores da área – interessados em adotar metodologias e princípios que visam melhorar o código e entendem que isto no final, traz benefícios não só para os developers, mas também para os usuários da ferramenta.

Vex - (@lfamorim e @sergioprado ao fundo) @Otata e @acidcode - Maio, 2009

Vex - @bufoni @esampaio e @sergioprado - Fevereiro, 2010

Vex Webdev - @bufoni e @Sugamele - Setembro, 2009

Trabalho em grupo

Por ter o costume de trabalhar sozinho na época dos freelas – claro, havia o designer @jorgeveteran – eu, achei no começo que seria algo complicado. E sim, é complicado ! Não guardar as ideias ou soluções contigo é uma das coisas mais complicadas. Deixar o pessoal que está contigo no projeto atualizado das ações, estabelecer uma linha e manter as coisas alinhadas durante todo o projeto é algo que eu precisei reeducar quando comecei na Vex. Mas até hoje não houve nenhum tipo de problema com o pessoal que já trabalhei em conjunto.

Um dos maiores problemas foi encontrar paciência para explicar as coisas técnicas para o pessoal. Não sou o melhor exemplo de paciência quando a tarefa é explicar coisas – que eu julgo claras e simples de entender – aos outros. Consigo explicar tudo numa boa, porém, dúvidas e erros que eu julgo primários me deixa meio: “Não acredito que você fez/perguntou isso !?”.

Outra particularidade é que dependendo da pergunta – na realidade, quase todas – eu não forneço a resposta pronta. Forneço links, materiais e até títulos de livros para que a pessoa leia, estude e tire suas próprias conclusões a respeito. Antes eu debater com ela aquele assunto à eu “formar robozinhos” que repetem tudo que eu julgo ser verdade até aquele momento. Se eles não entendiam o motivo pelo qual faço isso, agora eles ficaram sabendo !

Vex Webdev - Playground - Fevereiro, 2010

Esse período que é um pouco mais de um ano realmente está valendo muito. Ao que percebo de comentários – críticas, na realidade – dos developers nas empresas em que trabalham, é possível ter uma clara noção de que a Vex é uma exceção. Uma equipe jovem, de jovens líderes e com ideias muito boas. O setor de tecnologia está de parabéns !

Retratos que coleciono desde quando iniciei na Vex podem serem vistos aqui, ó !

Reparando bem, cada modelo tem suas particularidades, porém com mesma base. O Pecl2 e Zend Framework PHP >= 5.3, aqui chamado de Java/Sun/Oracle Coding Standard, tem o mesmo objetivo: atualizar o não-padrão para trabalharem com suporte a Namespaces. O que explico mais adiante.

Antes do namaspace, ou seja, antes do PHP 5.3 a Zend recomendava um padrão que eu sempre achei ridículo, mas pensando bem, não tinha muito como fugir disso:

Arquivo: /application/module/Object.php
Nome da Classe: Module_Object

Arquivo: /application/module/client/view/Json.php
Nome da Classe: Module_Client_View_Json

Funcional ? Sim, sem dúvidas. Elegante ? Bem…

Bonito fica quando encontramos coisas como:

Arquivo: /application/module/AObject.php
Classe: Module_AObject <<abstrata>>

A adoção do prefixo “A” para abstrações e do prefixo “I” para interfaces. Além de nada elegante, só atrapalha o uso de Domain-Driven Design onde, resumidamente falando, tem como foco: transparecer no código o que você ouve de seu cliente/stakeholder.

Salvo engano meu, vi isso em um destes padrões sugeridos para o PHP. Mas infelizmente não encontrei o link :/

E aí veio o PHP 5.3

Com a chegada oficial do PHP 5.3, os padrões ao invés de unificarem-se e sugerir algo em comum, resolveram o que ? Criar mais padrões (o que chega a ser irônico) para brindar a chegada do tão sonhado Namespace (ou pacotes, para os Javeiros).

A Zend sugere o seguinte agora:

Arquivo: /application/module/client/view/Json.php
Namespace: \module\client\view
Classe: Json

Sim, óbvio ! Temos assim o padrão Zend Framework v2 ou simplesmente, Java Coding Standards. E eu não estou brincando não. No próprio artigo proposto por Matthew Ratzloff, ele cita como referência o link para o site do Java. O foco de Matthew é acabar com um problema grave criado pela Zend Framework: abreviação de nomes devido a quantidade de caracteres.

O pessoal do Pecl, sugeriu algo bem parecido. Manteve as particularidades e adicionou o suporte à namespaces ao seu Coding Standard.

Porém, há os frameworks

Obviamente em meio a sopa de pseudo-padrões, cada framework tem o seu próprio como era de se esperar. symfony, Cake PHP, Zend Framework, Kohana, etc. Cada um com o seu próprio mesclando vários e criando um terceiro.

Em minha sincera opinião, acho o Coding Standard do symfony de longe o mais bizarro: tab com dois espaços e nome de classe iniciado por minúsculo e sufixado com .class.php de longe lidera a aberração.

Para piorar o autoload dele autoriza coisas como:

Arquivo: /apps/module/lib/myObject.class.php
Classe: myObjectClass

Isso não funcionará com namespaces. Fato.

Teremos um padrão ?

Gostaria eu que sim. Seria fundamental estabelecer, agora com o reaparecimento de namespaces no PHP – sim, existiu num passado sombrio – um padrão default e que fosse largamente adotado. Complicado é convencer muito ego por aí a fora a abandonar seus pseudo-standards – que de padrão não tem nada – e utilizar um único facilitando a colaboração entre projetos e utilizando o tempo no que realmente importa: criar bons e bem documentados softwares.

Resumidamente é um projeto criado pelo Fabien Potencier - para quem não o conhece é o criador do symfony framework – e salvo engano há rumores de que ele pretende integrar o Twig à versão 2.x do symfony removendo o PHP super verboso que rola nos templates do symfony desde seu lançamento. * carece fontes concretas

Recursos bacanas e uma sintaxe à lá Django nos templates me chamou muita atenção para não só mais olhar, mas sim, testar para ver melhor a ferramenta.

Não demorou para eu testar como ele se portaria diante de objetos no template e para minha tristeza, para ele ler um atributo, depende nada mais, nada menos do que __get() e __isset(). É possível também, assim como na JSTL ler um atributo iniciado por get. No template você deveria chamá-lo sem esse get. i.e: getFoo() no template seria apenas foo.

Imediatamente, o que vem a mente de quem trabalha com OO ? Quebra brutal de encapsulamento. Sim, __get() por mais fácil que possa parecer, quebra totalmente a segurança de uma variável membro, uma vez que os atributos da mesma tornam-se públicos.

Tentei entrar em contato com o Fabien para ver o motivo que o levou a implementar assim. Ele, bem receptivo - ironia mode on - disse-me: se tiver um patch mande-o, do contrário, peço que seja paciente.

Fiz o patch, revi algumas coisas e mantive compatibilidade com o __get() __isset() que o Twig originalmente aceita e criei um Fork do projeto no GitHub.

Features default

• Suporte a plugins
• Variáveis
• Leitura de arrays por índices int ou string
• Arrays multidimensionais
• Objetos (via __get() __isset() apenas)
• Objetos alinhados (Nested Objects) com __get() __isset() também
• Blocos de controle, loops, etc.

Mudanças

Métodos públicos começados por:

• get
• is
• has
• match
• contain

Podem ser chamados no template sem qualquer problema sem a necessidade dos métodos mágicos.
Abaixo exemplos funcionais:

//...
/**
 * SomeVar
 * @var string
 */
 private $baz;
 /**
 * Bar Object
 * @var Bar
 */
 private $bar;
 /**
 * Magic String with __get
 * @var string
 */
 public $magic;

 public function __construct() {
    $this->baz = "Value of Foobar::\$baz";
    $this->bar = new Bar();
    $this->magic = 'Magic methods still working !';
 }

 /**
 * @return string
 */
 public function getBaz() {
     return $this->baz;
 }

 /**
 * @return boolean
 */
 public function hasBaz() {
     return (!empty($this->baz)) ? true : false;
 }

 private function hasIamNull() {
     return false;
 }

 public function fakehasFoo() {
     return 'I will not be displayed !';
 }

 public function matchesWith($otherString) {
     return ('foo' === $otherString);
 }

 public function getBar() {
     return $this->bar;
 } // ....

No template teriamos:

<body>
 <h1>Meu título</h1>
 <p>Bar foo</p>

 {% if foo.hasBaz %}
 <p>{{ foo.getBaz }}</p>
 {% endif %}

 {% if foo.hasIamNull %}
 <p>{{ foo.getBaz }}</p>
 {% endif %}

 <p>{{ foo.getAbstractBaz }}</p>

 <p>{{ foo.getIamPublic }}</p>

 <p>{{ foo.fakehasFoo }}</p>

 <p>{{ foo.getBar.getHlegius }}</p>

 <p>{{ foo.getBar.getBarFoo.getTwig }}</p>
 <p>{{ foo.getBar.getBarFoo.tryToCallMe }}</p> <!-- private function, fails. -->

 <p>{{ foo.methodThatIsnotExists }}</p> <!-- without error -->

 {% if foo.matchesWith('foo') %}
 <p>Yeah, it's matches !</p> <!-- will matches -->
 {% endif %}

 {% if foo.matchesWith('baz') %}
 <p>Yeah, it's matches again :S !</p> <!-- will NOT matches -->
 {% endif %}

Métodos não permitidos, índices não existentes e outros tipos de erros são omitidos por default.

Ainda penso em melhorar e implementar mais coisas ao projeto. Minha ideia inicial é ir sempre atualizando do projeto oficial para não distanciar-se muito. O patch eu também encaminhei ao próprio Fabien, mas ainda ele sequer respondeu ao meu e-mail.

Quem já utiliza o Twig e quiser testar essa nova versão mais “Object-oriented friendly” farei questão de dar total suporte e apoio para mantê-la up to date
Há ainda, exemplos de uso e do que você pode fazer com o Twig que eu modifiquei. Detalhes você encontra no diretório examples do projeto.

Vejamos um exemplo nada científico que fiz:

Criei os seguintes exemplos:

<?php
class Estatico {

    public static function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
           echo Estatico::outraCoisa();
           $i++;
        }
    }

    public static function outraCoisa() {
        return "Conteúdo";
    }
}

Estatico::fazAlgumaCoisa();

<?php
class Instancia {

    public function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
            echo $this->outraCoisa();
            $i++;
        }
    }

    public function outraCoisa() {
        return "Conteúdo";
    }
}
$objInstancia = new Instancia();
$objInstancia->fazAlgumaCoisa();

Os resultados após rodar quatro vezes cada foram:

Ou seja: 91.09 ms para o estático contra 90.07 para a versão non-static. Obviamente foi apenas um teste sem qualquer relevância, pois rodei em minha máquina pessoal com várias outras aplicações rodando em background. É perceptível porém, que a diferença não é absurda que compense o uso de estático por este motivo.

Deixando a questão de “performance” de lado, partimos para questões arquitetônicas:

• Identidade
• SoC – Separation of Concerns (Principio de Separação das Responsabilidades)
• Encapsulamento
• Estado
• DRY – Don’t Repeat Yourself
• Associações – sejam elas composições ou agregações

Ao perder Identidade e Estado as possibilidades daquele método – ou da classe inteira, caso use estático em tudo – tem o leque de utilidade reduzido para:

• Service
• Facade
• Factory
• Helpers – no âmbito de serem apenas funções que realizam determinada tarefa na aplicação sem qualquer valor ao Domínio

Com isso, perdemos também o Princípio de Separação das Responsabilidades, ou seja, a classe perde o controle sobre a integridade dos dados que ela deveria controlar e proteger contra acesso ou alteração indevidos.

Listei o DRY também por um motivo simples: com métodos estáticos, perdemos a grande chance de usar as variáveis de instância da classe à favor da mesma. Exemplo:

class UsuarioEstatico {

    public static function login($usuario, $senha) {
        // valida o usuário e zaz
        $autenticador = new Autenticador();
        $autenticador->autentica($usuario, $senha);
    }

    public static function logout($usuario) {
        // verifica se a sessao está aberta
        $autenticador = new Autenticador();
        $autenticador->fechaSessaoPara($usuario);
    }
}

class Usuario implements Autenticavel {
    private $autenticador;

    public function __construct($usuario, $senha) {
        // manipula os dados de entrada
        $this->autenticador = new Autenticador($this);
    }

    public function login() {
        return $this->autenticador->autentica();
    }

    public function logout() {
        return $this->autenticador->fechaSessao();
    }
}

Repare no modelo estático: foi necessário instanciar o antenticador por duas vezes em pontos diferentes. Opa, repetiu ! Mesmo que o autenticador fosse estático, teriamos duplicação, pois teriamos que certificar que o usuário existe e tudo mais. Isso porque não comentei como ficaria o lado cliente dessa implementação estática. O cliente – seja Controller, WebService ou qualquer classe em outra camada no domínio – teria que conhecer muita coisa sobre implementação dessa classe para poder manipulá-la.

Como bônus, repare que perdemos neste caso também o Polimorfismo, uma vez que eu poderia ter esse Autenticador() como base de autenticação para qualquer tipo (Usuário, Funcionário, Gerência, Administradores…)

O uso de métodos ou funções – sim, há diferença – estáticas pode ser bem-vindo nos itens já enumerados. Alguns developers porém, ainda que nestes casos são contra o uso por achar a ideia estática demasiadamente anti-oo.

Trata-se de uma ferramenta para disseminar Memes com imagens, vídeos e até aúdio acrescidos de um texto de no máximo 2000 caracteres por meme postado. Tudo bem que está sendo usado mais como um Twitter tunado só que ao meu ver o objetivo é disseminar memes e isto não inclui o que você está fazendo ou o que está acontecendo agora.

Alguns conceitos foram por eles sugados como o Repost (Retwitt), seguidores e a palavra “baleiando” quando algo dá errado por lá. Interface default do Yahoo!, integração com sua credencial Y! e agora estão aprimorando para torná-lo mais amigável com APIs que conectam-se ao Facebook, Twitter e mais algumas outras.

Havia uma promoção que ajudou a disseminar o Meme do Yahoo! na rede, porém, a mesma encerra-se hoje às 23:59hs.

Mais informações de como funciona e o que está rolando por lá, basta acessar o site do Meme do Yahoo! Se interessar ver meus memes, segue por aqui, ó !