Abril de 2011

Quem está me acompanhando nos últimos 4 anos nas minhas discussões sobre formas de gerenciamento e de organização de empresas vai se lembrar que eu muitas vezes não só flertei como procurei maneiras de tentar defender um tipo de organização “democrática”. Esse conceito sempre foi incompleto e eu imaginava que mais cedo ou mais tarde a equação iria se fechar. Em vez disso estou retornando ao zero e redefinindo esses conceitos. A primeira coisa que eu preciso corrigir é o uso da palavra “Democracia”. Essa palavra não condiz com o tipo de organização que eu descrevo.

Minha linha de pensamento sempre é baseada em Evolucionismo Darwinista. É a única forma onde Caos consegue tender a uma certa Ordem através de auto-organização. Esse processo envolve diversos mecanismos e é onde já palestrei sobre Redes de Livre Escala, sobre Sistemas Complexos Adaptativos, e como tudo isso leva a processos, metodologias, incluindo o tão discutido Scrum. Essa linha de estudo – que você pode acompanhar nos meus blogs e palestras dos últimos 3 anos – passa superficialmente por temas de biologia, sociologia, psicologia, filosofia, física, matemática. Em última instância me parecia que o caminho mais coerente era em torno do que hoje em dia ficou conhecido como Organizações Democráticas, especialmente por causa de cases famosos como a Semco, de Ricardo Semler e aspectos de democracia na organização que podem ser observadas em empresas como Southwest Airlines, Dreamhost, Groupon, Zappos.

Porém, eu mesmo fui vítima daquilo que sempre critico: um grupo de evidências positivas sobre um modelo, por melhor que pareçam ser, nunca provam o modelo! Concluir baseado apenas em evidências positivas é o mesmo que cargo cult. Portanto, a primeira coisa que devo corrigir é: o tipo de organização que descrevo e defendo não tem a ver com “Democracia”, portanto na minha concepção, o termo “Organizações Democráticas” é um erro.

If you didn’t read my last two article I recommend you do so before going any further because I am using the same pet project, ObjC Rubyfication as an example for this article. The point is: you are writing reusable code that you want in more than one project.

Most of this was based on Cocoanetics article about universal static libraries. So, if you’ve payed attention to my previous article, you saw this screenshot:

As some of you may know, I have this small pet project called ObjC Rubyfication, a personal exercise in writing some Ruby-like syntax within Objective-C. Most of this project uses the fact that we can reopen Objective-C standard classes – very much like Ruby, unlike Java – and insert our own code – through Categories, similar to Ruby’s modules.

The idea of this pet project is to be a Static Library that I can easily add to any other project and have all of its features. In this article I’d like to present how I am organizing its many subprojects within one project (and I am accepting any suggestions and tips to make it better as I am just learning how to organize things within Obj-C projects) and talk about a gotcha that took me hours to figure out and might help someone else.

While experimenting with ways of using Objective-C a little bit closer to how I code Ruby, there were two things that annoyed me a bit. First, Date Formatting and, second, Regular Expressions.

The Cocoa framework has both implemented as NSDateFormatter and NSRegularExpression that also happen to be available for iOS development.

You can format dates like this:

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateStyle:NSDateFormatterMediumStyle];
[dateFormatter setTimeStyle:NSDateFormatterNoStyle];
 
NSDate *date = [NSDate dateWithTimeIntervalSinceReferenceDate:162000];
 
NSString *formattedDateString = [dateFormatter stringFromDate:date];
NSLog(@"formattedDateString: %@", formattedDateString);
// Output for locale en_US: "formattedDateString: Jan 2, 2001"

And you can use Regular Expressions like this:

NSError *error = NULL;
NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"\\b(a|b)(c|d)\\b" 
                                                                       options:NSRegularExpressionCaseInsensitive
                                                                         error:&error];

NSUInteger numberOfMatches = [regex numberOfMatchesInString:string
                                                    options:0
                                                      range:NSMakeRange(0, [string length])];

But I have issues with both of these. The Ruby equivalent for the date formatting example would be:

require 'activesupport'
date = Time.parse("2001-01-01") + 162000.seconds
date.strftime("%b %d, %Y")

And the regular expression example would be like this:

number_of_matches = /\W*[a|b][c|d]\W*/.match(string).size

There are 2 specific things that annoys me:

• that the Obj-C versions feels unnecessarily verbose. Now, I do understand that they are lower level and they will probably allow for more flexibility, but I think they should have higher “porcelain” versions, that are more straightforward.
• that in Obj-C, the Date Formatting uses the Unicode TR-35 formatting standard and that Regular Expressions uses the ICU standard that is inspired by Perl Regular Expression with support for Unicode and loosely based on JDK 1.4 java.util.regex.

So, the ideal solution for me would be:

• to have higher level versions of those features;
• to have C-compatible strftime date formatting and Ruby 1.9’s Oniguruma level regular expressions.

Nos últimos artigos eu descrevi algumas controvérsias que rolaram pelo comunidade recentemente, primeiro a decisão do Twitter de trocar Ruby por Java, depois a decisão do Rails Core Team de adotar SASS e Coffeescript, finalmente a discussão entre Rspec e Test::Unit.

Em todos esses casos existe ainda outras variáveis a considerar. Primeiro, as discussões são de desenvolvedor para outro desenvolvedor. Na maioria dos casos vamos cair em estética, o que é basicamente questão de gosto. Alguns vão dizer que Less é melhor que Sass, quem gosta de Sass vai dizer que é melhor do que Less. Quem gosta de ERB vai dizer que não gosta de HAML, quem já se acostumou com HAML vai dizer que ERB é feio e assim por diante. E agora o ponto crucial: nenhum dos dois está nem certo nem errado.

Sei que essa resposta não ajuda mas quem disse que a vida é fácil? Quero discutir dois argumentos para essas discussões todas, a primeira mais conceitual e filosófica (vocês me conhecem) e a segunda mais comercial e de negócio.

Eu uso o Mail.app, que é o cliente de email padrão do Mac há muitos anos e sempre gostei muito dele. Quando o Lion (OS X 10.7) for lançado este ano o Mail.app receberá uma grande e bem vinda atualização no seu visual. Mas até lá podemos já dar uma ajudinha agora mesmo. Veja uma foto do meu Mail.app:

E para quem não conhecia, eu também escrevo artigos na Rede de Blogs da Info Online. Meu blog lá se chama Gestão 2.0 e trata de assuntos de gestão, mercado, e coisas relacionadas (muito do que eu publico aqui também como Off-Topic). Eu passei algum tempo longe dele por motivos de trabalho (faltou tempo!) mas estou retornando! Então quem ainda não viu, veja meus artigos mais recentes: Processos e Metodologias não vão te Ajudar

Então você quer terceirizar um projeto? Quem é você?
Então você é...

Alguns dias atrás, o bom e velho @dhh começou uma controvérsia na comunidade. Eu diria até que foi uma discussão saudável. Leia a cobertura do acontecido na RubyInside mas em resumo ele fez a seguinte sequência de tweets:

“Pergunta: que framework de teste vocês usam na 37signals? Resposta: Test::Unit com uso ocasional do mocha. (Isso é tudo que você precisa para bons testes.)”

“Eu respeito os caras por trás disso e sou totalmente a favor de experimentação, mas a proliferação de rSpec e Cucumber me deixa triste.”

“RSpec me ofende esteticamente com nenhum benefício discernível pela sua complexidade adicionada sobre Test::Unit.”

“Cucumber não faz sentido a menos que você tenha clientes lendo os testes. Por que você construiria um parser específico de testes para inglês?”

“A coisa importante, é claro, é que consigamos fazer as pessoas testarem, então ferramentas não deveriam importar muito. Mas a complexidade extra ainda me chateia.”

Sendo sincero, eu também compartilho da mesma opinião do @dhh. E não, não é cargo cult, antes que algum engraçadinho faça o comentário: lembro de 1 ou 2 anos atrás onde eu e o Carlos Brando estávamos conversando justamente como voltar pra Test::Unit era até um alívio. Também lembro de discutir o assunto do Cucumber com o Daniel V. Lopes, que pelo menos na época preferia Steak justamente porque nenhum cliente iria ler os testes escritos em inglês e portanto isso era redundante.

Só para adiantar a conclusão: se alguém estava levando a discussão para o nível de qual sintaxe é “melhor”, ou qual é mais “elegante”, ou qual é mais “suscinta”, você está indo na direção errada e vai tirar conclusões sem nenhum fundamento também. Então vamos com calma que, pra variar, a leitura será longa.

Para quem não está acompanhando, esta semana rolou uma pequena controvérsia acerca de uma nova decisão na linha de desenvolvimento para o futuro Rails 3.1 (atualmente estamos na 3.0.6). A partir dessa versão, o framework trará como dependência as bibliotecas CoffeeScript, SASS e Sprockets, além da mudança que já havia sido anunciada antes de trocar a instalação padrão do framework Javascript, Prototype + Scriptaculous, por jQuery.

A maioria dessas mudanças foram bem recebidas e até em alguns casos, aplaudida, no estilo “já não era sem tempo!” (caso do jQuery).

Porém, a escolha de colocar o CoffeeScript como padrão causou um grande furor, diversas trocas de hostilidades, piadas de humor negro, sarcasmo e também muita gente que simplesmente gosta de fazer barulho sem motivo algum (tem tempo sobrando, eu diria).

O pessoal do Rails Core Team acha que é a melhor decisão. Uma parcela barulhenta da comunidade acha que foi uma grande bobagem. E agora, o que isso significa?

Estava esperando ter um tempinho para falar sobre isso. Se você presta atenção já deve ter visto posts de blog, tweets e tudo mais falando sobre um post recente do próprio Twitter explicando sobre a migração dos seus front-ends feitos em Ruby on Rails para uma solução que eles mesmo fizeram, chamada Blender, que é construída com Java. Com isso eles reduziram o tempo de requisição de 800ms para 250ms e conseguiram fazer suas máquinas terem 10 vezes mais capacidade.

Este é o resumo que você vai ler em todas os canais de comunicação que noticiaram o ocorrido. E, claro, os mais atrevidos e sem noção não se inibiram de novamente dizer “Ruby é muito lento, por isso compensa usar Java mesmo”. Como faz algum tempo que não falo sobre o assunto, acho que vale a pena repetir. Sim, todos nós rubistas sabemos que Ruby é uma das linguagens mais lentas que existem em uso hoje. E nenhum de nós faz nenhum esforço para esconder esse fato. Isso não é novidade, nunca foi. E aí eu pergunto: “e daí?” E a resposta continua: “oras, por isso mesmo não compensa usar Ruby e devemos todos continuar com Java, que é muitas vezes mais rápido, afinal se o Twitter disse é porque deve ser verdade.”

Antes de Ruby e diversas outras linguagens, existe Perl. No dia 7 de maio acontecerá a São Paulo Perl Workshop que contará com as presenças de Brad Fitzpatrick e ninguém menos que Larry Wall. Brad, criador do LiveJournal, memcached (que nós rubistas gostamos muito!), mogilefs, gearman e dentre outras importantes contribuições, virá ao Brasil pela primeira vez para divulgar em primeira mão o novo projeto de storage voltado para a web chamado Camlistore. Larry Wall, criador do Perl – não preci...