Conhecimento nunca é o bastante

O mais novo lançamento da Google chama-se Doctype. Trata-se de uma enciclopédia aberta (a la Wikipedia) para documentar padrões web abertos como HTML e CSS e outros tópicos sobre desenvolvimento como segurança e caching. De quebra ainda estão disponíveis 8 mil linhas de Javascript que formam a biblioteca Javascript desenvolvida pela Google.

A intenção é criar uma referência completa sobre padrões web, tudo com casos de teste. Uma iniciativa muito interessante, vale a pena conferir.

Essa semana atualizei o Wordpress para a versão 2.5.1. Já havia atualizado outra vezes, então fiz o mesmo procedimento: salvei um backup completo do blog, descompactei a nova versão e copiei para ela as configurações e conteúdo como temas e uplods.

Tudo ocorreu normalmente, sem nenhum problema. Ou quase. Após algumas horas acessei o blog e vi que estava com o tema default do Wordpress. Alterei para o tema que uso - Copyblogger - e verifiquei: tudo certo agora. Passam-se algumas horas e… tema default outra vez.

Resumindo: a cada “virada” de dia (ou seja, por volta da meia noite), o blog volta ao tema default por vontade própria. Entro no módulo administrativo e o tema ativo é o Copyblogger. Tenho que mudar para algum outro e escolher novamente o Copyblogger para que tudo volte ao normal… todos os dias.

Alguém já passou por isso?

Depois de um bom tempo, mais um artigo da série “Developer 101″. Dessa vez decidi falar sobre vários assuntos de uma forma sucinta com o objetivo de instigar a curiosidade do leitor.

Então vamos lá, aí vão mais alguns conceitos que acho importantes na formação de um desenvolvedor:

POSIX
Portable Operating System Interface, POSIX, é o nome dado a um conjunto de padrões especificados pela IEEE que define a API e interfaces de shell e de utilitários para software compatível com o sistema operacional Unix (mas o padrão pode se aplicar a qualquer sistema operacional). O objetivo era estabelecer uma interface padrão entre todos os sistemas operacionais que adotassem o conjunto POSIX e os softwares rodados sobre eles, de forma a torná-los portáveis. O nome POSIX foi uma criação de Richard Stallman.

Entre os sistemas operacionais mais conhecidos, são totalmente compatíveis com o conjunto POSIX: AIX, HP-UX, Mac OS X e Solaris. Entre os não-oficialmente certificados, mas compatíveis em grande parte estão FreeBSD e a maioria das distribuições Linux. É possível conseguir algum nível de compatibilidade no Windows através de pacotes como o Microsoft Windows Services for Unix.

Leia mais aqui.

BSD
Berkeley Software Distribution, BSD, é um sistema operacional derivado de Unix desenvolvido na Universidade da Califórnia, em Berkeley, de 1977 a 1995. Foi um branch do Unix e muito de seu código acabou sendo aproveitado pelo mesmo.

Serviu como base para muitos projetos em desenvolvimento até hoje, como FreeBSD, OpenBSD e para o core do Mac OS X (conhecido como Darwin, que é um sistema operacional por si só, contendo partes do FreeBSD, do Mach e de código desenvolvido pela Apple - XNU), sistemas considerados Unix-like.

Leia mais aqui.

Bash
Bourne-again shell, Bash, é um shell Unix escrito para o projeto GNU. É o padrão na maioria das distribuições GNU/Linux e também no Mac OS X e pode ser utilizado na maioria dos sistemas Unix-like. Foi portado para o Windows pelo projeto Cygwin.

Leia mais aqui.

Reforçando: se você encontrar algo incorreto ou incompleto, por favor, comente.

E olha que passaram-se apenas quatro meses!

No início do ano escrevi aqui meus objetivos para 2008.

Agora os objetivos estão quase todos atingidos, pois este post é para anunciar que, após mudar do PC para o Mac, lançar um plugin pra Rails (outros virão) e ficar noivo, sou o mais novo contratado do Manchester United integrante da equipe da WebCo Internet, do já famoso Manoel Lemos, a startup por trás do BlogBlogs e do ainda-em-beta-fechado Brasigo.

Como diz aquela frase: “Eu vômimbora pra Sumpaulo!”. Nesse momento se misturam empolgação, ansiedade, felicidade, dúvidas como “Onde eu vou morar?” e afirmações como “Socorro! Metade (ou mais) dos bairros dessa cidade tem mais gente que na cidade em que moro hoje!”.

Impossível não se empolgar com a proposta de trabalho, o ambiente da empresa e a equipe, da qual fazem parte nomes bem conhecidos na comunidade Rails, como Ronaldo Ferraz e Nando Vieira, além de outros ainda não tão conhecidos, mas igualmente capacitados (puxa-saco!).

Serão muitas oportunidades para fazer algo de que gosto muito: aprender. Nova cidade, nova equipe, nova metodologia (Scrum e práticas do XP)… tudo novo! Um grande abraço a todos os meus ex-companheiros de trabalho, muito sucesso pra vocês.

WebCo, São Paulo, aí vou eu!

Testing is a very important aspect of Rails programming. The framework makes testing really easy, eliminating some excuses you could have for not testing your applications. Here’s my five tips for testing with Rails:

• Embrace the TDD cycle: this one isn’t Rails related, but is very important. You can write your code first and test it after and you’ll get some benefits, but Test-Driven Development really leverages the power of this automated testing. By writing your tests first you get low coupling and high cohesion through a better interface (API) design. Moreover, by following the red-green-refactor cycle you’ll always know when you’re done and will avoid scope creep.




• Test your helpers: plain and simple. Rais Recipes has a recipe about it and, with Edge Rails, testing helpers got easier.




• Overmocking results in brittle tests:and brittle tests are a bad thing. Many people just mock and stub everything. By doing this you’re coupling your tests to the inner details of the tested code instead of the result of its execution. You can see an example here (and subscribe to that blog’s feed, it’s very good).




• Watch out on your way to BDD: Behavior-Driven Development is in vogue within the Rails community. Be careful. Just like you can write Fortran in any language, you can use something like RSpec and still not do BDD. BDD is about a shift in the way you think about tests, not about tools by themselves. You can use Test::Unit and do BDD. Tools like RSpec and Shoulda (my personal choice) are facilitators, they don’t guarantee anything.




• One assertion per test: this is one of that tips that seems inoffensive but once you’re doing helps a lot. Why? Jay Fields can explain better than me.

And that’s it. Five quick and simple tips that I hope will help you. Feel free to share your own tips in the comments. This article is my entry to the Railscasts’ 100th episode contest. Take some time to visit the site, it’s really good.

Muitas empresas sofrem com o que se chama “fuga de cérebros”: os melhores profissionais da empresa estão sempre saindo para outros empregos. Isso pode ter vários motivos, como problemas de relacionamento pessoal, baixos salários, mudança de foco profissional, insatisfação com a estratégia ou foco da empresa e vários outros. Mas há um fator muito importante que geralmente é ignorado: a falta de confiança na intuição do profissional especialista (expert).

Pausa para explicação.

O modelo Dreyfus de aquisição de habilidades divide os profissionais em cinco níveis de conhecimento para uma dada habilidade (isto é, você pode estar no nível 1 em culinária e no nível 5 em jardinagem, ninguém “é” um nível 5 e pronto). Bem resumidamente, são eles:

1. Novato: o novato precisa de regras claras e independentes de contexto (”receita de bolo”) para guiar seu trabalho, e não sabe lidar com problemas pois não tem experiência para tomar decisões sozinho. Também não toma responsabilidade pelas regras que segue - “Eu estava apenas seguindo ordens!”.
2. Iniciante avançado: começa a tomar decisões mais básicas pois já possui alguma experiência e percebe que pode adaptar algumas regras a certos contextos. Ainda não toma decisões contrárias às regras, não sabe lidar com problemas inesperados e não experimenta a sensação de responsabilidade pessoal. A maioria das pessoas está nesse nível.
3. Competente: questiona as regras de acordo com sua experiência e percebe consequências a longo prazo. Começa a tomar decisões de acordo com o contexto, resolver problemas inesperados e a tomar a responsabilidade sobre seus atos.
4. Proficiente: se utiliza de pouquíssimas regras, começa a valorizar mais sua intuição e sempre analisa o contexto em que está inserido de acordo com o que já experimentou. Sente-se completamente responsável por suas decisões e respectivas consequências.
5. Especialista: o especialista usa a intuição que adquiriu com a experiência e faz tudo parecer muito fácil. Toma decisões e resolve problemas sem esforço, pois reconhece padrões muito rapidamente. É o pior professor para um novato, pois não segue qualquer receita, apenas sabe o que fazer.

Um ponto interessante é que pessoas nos níveis mais baixos costumam se sobreavaliar, enquanto as pessoas nos níveis mais altos são bem mais críticos em relação ao seu trabalho e nível de conhecimento.

Leia o artigo completo

Pro pessoal de Porto Alegre-RS e região, o Jony dos Santos Kostetzer anunciou uma nova turma do curso Formação Desenvolvedor Web com Ruby on Rails, ministrado por ele.

Veja mais informações aqui.

• Ezra Zygmuntowicz anunciou que está fazendo modificações no ActionPack em seu fork do Rails no Github. Basicamente, ele está migrando a funcionalidade de integração com Rack do Merb para o Rails e, com isso, fazendo uma limpeza geral no código, conseguindo mais desempenho e estabilidade e caminhando para uma possível implementação thread-safe.
• Ruby Hero Awards - indique os membros da comunidade que, para você, fazem um trabalho importante. Reconhecimento é uma grande motivação.
• O que é Ruby Enterprise Edition? - Fábio Akita - o Railer que nunca dorme - em mais um excelente artigo.
• Interessado em Git? Então dê uma olhada nesse post para algumas boas referências
• A arte de testar aplicações web - mais uma ótima apresentação de Gregg Pollack
• Posts do Signal vs. Noise: Start a business, not a startup, If you’re working in a big group, you’re fighting human nature, Quit your job!.
• Metaprogramming Ruby Presentation
• Import GMail contacts using Rails
• Lançado Ubuntu 8.04

O melhor do evento, com certeza, foram as pessoas. Tive a oportunidade de conhecer pessoalmente muita gente que só conhecia no “mundo virtual”: Jony dos Santos, Rodrigo Kochenburger, Júlio Monteiro, Carlos Eduardo Franco, Ronaldo Ferraz, Weldys Santos, Everton Carpes e também rever alguns, como Fábio Akita e Vinícius Teles.

Akita, Tiago, Lucas, Vinícius, Carlos Eduardo, Júlio, Jony e Rodrigo - Rails Brasil em peso no FISL

Vi algumas palestras. Algumas boas, algumas péssimas. Não tem jeito, quando alguém muito técnico é posto para falar, o resultado não é muito bom. Por isso é tão importante sair do “cubículo” e dar atenção a aspectos nâo técnicos para desenvolver outras habilidades.

Conversamos também com um pessoal de um grupo de usuários de Java do Uruguai. Eles estão interessados em aprender Rails e foram até o stand do Rails Brasil para uma conversa. Três pessoas falando espanhol e quatro falando português, imaginem a “salada”.

Outro estrangeiro que apareceu por lá foi o Evan Henshaw-Plath, aka “Rabble”, desenvolvedor Rails da Yahoo! e também um dos criadores do Odeo. A conversa com ele foi muito interessante. Eles nos mostrou um novo produto da Yahoo! desenvolvido em Rails (Fire Eagle) e também nos contou que está escrevendo um livro sobre TDD com Ruby para a O’Reilly.

Outros destaques foram as palestras de Randal Schwartz (que era sobre Seaside mas ficou só no básico de Smalltalk) e Jon Maddog Hall.

O que ficou do evento é que nossa comunidade vem crescendo muito bem e conta com desenvolvedores excelentes, sempre buscando melhorar e objetivando qualidade. Valeu galera, até a próxima oportunidade!

Veja mais fotos aqui.

Foi anunciada hoje a terceira edição do principal livro sobre Rails no mercado: Agile Web Development with Rails, que agora cobrirá o Rails 2. Na terceira edição, Sam Ruby participará como escritor-líder, junto com Dave Thomas e David Heinemeier Hansson.