Publicado por Vinicius Manhães Teles há aproximadamente 5 horas.
Ontem eu falei que nós estávamos em um novo endereço e várias pessoas pediram fotos. Então, pensei, por que mostrar fotos, quando podemos filmar? Aí está o resultado. Como eu dei mole no vídeo e falei a "nova nova sede da Improve It", ao invés de "nossa nova sede da Improve It", o título também ficou assim. :p
Publicado por Vinicius Manhães Teles há aproximadamente 13 horas.
No próximo sábado (26/07/2008) estarei na The Developer's Conference 2008 fazendo uma apresentação sobre Extreme Programming. No fim do ano passado eu parei de fazer palestras e, desde então, tenho me concentrado em outros assuntos já não mais tão relacionados ao mundo do desenvolvimento ágil. A exceção ficou por conta de algumas apresentações que fiz em Porto Alegre na época do FISL.
A apresentação de sábado surgiu a partir de um convite feito pelo meu amigo Jorge Diz, que tive a oportunidade de conhecer nos XP Brasil 2002 e 2004. Se alguém de São Paulo estiver a fim de me ouvir falar sobre XP, esta certamente será uma rara oportunidade.
No evento também terei a satisfação de re-encontrar meus amigos Juan Bernabó e Manoel Pimentel. O Juan fará uma apresentação de Scrum na sexta-feira e o Manoel apresentará Modelagem Ágil um pouco antes de mim, no sábado. No fim do evento haverá um painel no qual estará presente também o amigo José Papo e a turma da Paggo.
Publicado por Vinicius Manhães Teles há 1 dia.
Estou sumido. É fato. Mas, por que? Porque às vezes é preciso dar um passo para trás, para dar mil a frente.
Há tempos que trabalho em casa, na companhia do Leandro e do Tapajós. Cansado do trânsito infernal do Rio de Janeiro, fui organizando as coisas para não ter mais que sair de casa. Atualmente, só preciso fazer isso uma vez por semana, quando visito o Projeto Lucidus, no Leblon.
Infelizmente nossa infra-estrutura em casa não era tão boa quanto deveria ser. Em abril, logo depois que voltei do FISL, me dei conta de que precisávamos nos mudar. Depois de algumas semanas, conseguimos achar o lugar certo e depois de muita papelada, fechamos toda a parte burocrática no dia anterior a minha ida para os EUA, que já estava programada há mais tempo.
Fui para os EUA, onde estive no Railsconf, na SEED3 e na WWDC. A viagem foi excepcional e, além de várias outras coisas, serviu para revalidar que estamos no caminho certo, sobretudo no que diz respeito à decisão de direcionar a empresa para a criação de produtos. Serão necessários muitos posts para descrever o que aprendi nesta ida aos EUA.
Enquanto estive lá, a mudança ficou parada e só ganhou forças novamente com a minha volta em meados de junho. A partir daí, foi necessário quase um mês até que migrássemos definitivamente para o novo endereço. A quantidade de detalhes que precisavam ser tratados era absurda. Felizmente, deu tudo certo. Demos muita sorte com praticamente todos os profissionais envolvidos. Algumas coisas ainda estão sendo finalizadas. Mas, no geral, já está tudo encaminhado.
Aqui na casa nova a situação é bem diferente. Investimos bastante para criar a melhor infra-estrutura possível. Nosso escritório ficou ótimo. Temos uma bela rede gigabit, dois quadros brancos enormes (quatro metros de largura no total), todos os livros à vista, cadeiras confortáveis, Macs e um puff grandão. :-)
Dediquei praticamente todo o meu tempo a essa mudança nas últimas semanas. Por isso estive sumido. Mas, como vêem, foi por uma boa causa. Este semestre quero poder dedicar todo o meu tempo, ou a maior parte dele, para criarmos os melhores produtos possíveis. Queria ter certeza de que faríamos isso usando a melhor infra-estrutura a nossa disposição. Agora estou tranqüilo, pois atingimos esta meta. Muito obrigado a todos que nos ajudaram nestes últimos dias.
Publicado por Sylvestre Mergulhão há 17 dias.
Nos dias 19 e 20 de julho teremos no Rio de Janeiro a I Ultra Maratona How To de Software Livre! É um evento com 20 tutoriais práticos de 4 horas cada. Terão desde cursos de utilização de BrOffice e Inkscape, passando por segurança de servidores, hardening e desenvolvimento. Para ver a grade completa acesse. Os preços são bem convidativos.
Eu serei tutor de dois. O primeiro, com nome de "XP Game e o Jogo da comunicação", será em conjunto com o Tapajos e a galera do Lucidus. No segundo estarei sozinho e será uma "Introdução ao Ruby on Rails".
Acesse já e faça a sua inscrição, as vagas são limitadas.
Publicado por Leandro Mello há 27 dias.
Na internet, mesmo que você não consiga mostrar uma imagem, ainda consegue dizer as mil palavras.
Hoje descobri um detalhe no meu método de escrever CSS que pretendo adotar como "best practice" pra mim em todo projeto futuro: a única folha de estilo que, num projeto que abranja tela/impressão/mobile, deve levar atributo media="all". Eu a chamo de "typography.css".
Cheguei a esta prática aplicando no webdesign um tanto do modus operandi adotado por publicitários e designers fora da web.
Em design e publicidade, costuma-se lidar separadamente com layout e tipografia. Isso porque o design aplicado ao texto carrega por si só uma personalidade tão forte, que merece atenção à parte. Há aos montes empresas dedicadas exclusivamente à tipografia, que passam dias, semanas, para criar uma única fonte, completa e bela. O visual do texto tem um poder só seu.
Na web, sofremos sérias restrições à tipografia. Não é possível usar fontes realmente únicas em um site porque elas podem não existir no computador do usuário. O uso de imagens com texto bonitão apresenta alguns riscos à acessibilidade, e a prática de incluir as próprias fontes no código tem suas próprias complicações. Em resumo, paciência: o jeito é usar o rozfejão mesmo e saber brincar com ele. O que é bom, já que este texto não trata mesmo de tipografia, mas do que podemos aprender com o hábito de separá-la do layout.
O bom do CSS é que ele garante a consistência das páginas do seu site. Uma mudança num seletorzinho qualquer e pronto, milhares de páginas são atualizadas de uma vez só, que beleza! Isso tem tudo a ver com o que chamamos identidade visual.
Uma empresa que respeita a própria identidade visual faz questão de que, no mínimo, sua tipografia seja consistente em todos os meios de comunicação, tanto em impressos como em eletrônicos, tanto quanto for possível. O layout é muito mais sujeito a pequenos ajustes aqui e ali por causa da variedade de suportes a que pode ser aplicado, mas o modo como o texto é apresentado tem que respeitar uma consistência ainda mais globalizada — o designer um dia pode se ver tendo que fazer uma peça que confie unicamente na tipografia, e as pessoas têm que reconhecer que tal peça pertence a tal empresa. E na web esta situação é bastante recorrente.
Imagine que seu site é poderosão, pode ser impresso, visto em mobiles, transformado numa transparência etc. Agora tire todos os luxos. Imagens, firulas de layout e tudo mais. O que sobra? Texto. Na internet, mesmo que você não consiga mostrar uma imagem, ainda consegue dizer as mil palavras. E de quebra transmiti-las para as outras mídias. Então por que não criar uma folha de estilo que lide só com o que tem a ver com texto?
À medida que os projetos em que eu trabalho cresciam, ficava complicado navegar pelo mar de seletores. Como eu escrevo CSS de modo incrivelmente regular, com todas propriedades aparecendo sempre na mesma ordem (ok, podem me chamar de maníaco) percebi que as propriedades que regiam o texto vinham sempre antes do grupo que controlava o layout. Para diminuir o tamanho de arquivo, resolvi pegar as propriedades de texto e jogar todas num arquivo separado, a que chamei typography.css.
.rss_links a,
.podcast_files h4 a {
font-size: 80%;
text-transform: uppercase;
text-decoration: none;
padding: .3em 1em;
background: #F7F7F7 url(/images/background/gradient_light_to_dark.png) repeat-x bottom left;
border: 1px outset #F7F7F7;
}
.rss_links a,
.podcast_files h4 a {
font-size: 80%;
text-transform: uppercase;
text-decoration: none;
}
.rss_links a,
.podcast_files h4 a {
padding: .3em 1em;
background: #F7F7F7 url(/images/background/gradient_light_to_dark.png) repeat-x bottom left;
border: 1px outset #F7F7F7;
}
E assim por diante, com todos seletores. A cisão foi bem fácil. A decisão de fazer a divisão e o nome que arranjei para a nova folha de estilos foi mais guiada pelo meu velho hábito de designer gráfico — e por uma leve esperança de que isso tornasse menores os arquivos — do que por alguma noção de onde isso ia dar. Mal sabia que ia ter resultados bem interessantes.
Ora, em um ponto chega a hora de fazer um CSS de impressão e um para mobile. Em minha primeira experiência desde que resolvi usar o método typography, resolvi expandir a dobradinha para o print e o handheld, criando assim as folhas de estilo application_print e typography_print, e application_handhled e typography_handheld.
Minha pasta "stylesheets" então ficou assim:
Que beleza! Mas pô... seis folhas de estilo só por um capricho de designer de separar o layout da tipografia? "Tem que ter um jeito de fazer melhor", pensei. E tinha. Com a sacação sutil, já dita lá em cima, de que a tipografia tem que ser global.
Percebi que os seletores dos três arquivos de tipografia eram muito similares. Assim, misturei tudo o que eu tinha no typography, typography_handheld e typography_print em um único arquivo typography.css. Fim da duplicação: ele passou a cuidar de tudo — tamanho da fonte, cor da letra, itálicas, negritos, maiúsculas e tudo mais. No CSS de impressão, como geralmente as pessoas preferem imprimir textos em preto, foi só escrever html * { color: #000; } que tudo foi resetado para preto (sobra meia dúzia de seletores teimosos, é só fazer o mesmo).
Por último, no head do HTML, atribuí ao typography.css media="all". E só a ele. As outras folhas de estilo que se preocupassem com suas mídias específicas. Todas estas outras folhas herdariam as mesmas propriedades de texto e, assim, estaria garantida a consistência não só entre as páginas de um mesmo site, mas entre as várias mídias que uma empresa e seu site disponibilizam. Identidade visual, caro leitor!
Outras vantagens que este método me trouxe:
Enfim, a nova prática tem-me rendido bons resultados. Há ressalvas, claro: num projeto pequeno, que não se pretende imprimir ou ver em mobile, não vale a pena separar typography de application. Por sua vez, um projeto gigantesco, ainda que bom candidato a ganhar um typography.css, tem muito mais chances de ter folhas de estilo auxiliares que provavelmente jogariam por terra minha contagem "n+1" de folhas. Mas no todo, meu trabalho com CSS tem sido bem mais bacana tendo que me preocupar com uma coisa de cada vez. É algo que com certeza vou adotar como best practice nos meus trabalhos... até aparecer uma prática melhor! :)
Este foi meu primeiro post no blog da Improve It. Espero que as informações sejam úteis de alguma forma, e inspirem boas práticas em designers e programadores por aí. Até onde experimentei, foi dos métodos que mais facilitou o trabalho por aqui. Claro que, ou eu não li o suficiente sobre CSS, ou esse assunto de separar tipografia já cansou de ser discutido lá fora, ou as duas coisas. Por isso, convido meus caros compadres designers a participarem da discussão. Quem sabe até onde esta metodologia pode ser aprimorada?
Publicado por Marcos Tapajós há 27 dias.
É com grande satisfação que informo a todos que a partir da próximo mês eu farei parte do time brasileiro da Surgeworks. Pode parecer estranho esse anúncio sair do site da Improve It mas vou explicar já que vocês iriam acabar sabendo mesmo e poderia rolar algum tipo de especulação sobre isso.
Engraçado que pouca gente sabe realmente como é a minha participação na Improve It e já escutei de tudo, desde que eu era sócio até que eu era cunhado do Vinícius. Eu não sou nada disso, sou apenas um funcionário da empresa como todos os outros!
Eu conheci o Vinícius quando eu fui aluno dele lá na UFRJ e logo após o termino do curso eu ingressei na equipe da Improve It e simplesmente adorei. Na época eu escutei de várias pessoas que no início é tudo uma maravilha e tal, só que lamento informar a todas elas que estavam erradas! Dois anos se passaram e eu continuo adorando só que atualmente gosto muito mais do que antes.
A Improve It é uma empresa muito diferente de todas as outras empresas que eu conheço e isso se dá ao fato do Vinícius ser um chefe completamente diferente de todos os outros. Não é à toa que ele deixou de ser meu chefe e se tornou um grande amigo e por isso mesmo eu não encaro a Improve It apenas como um emprego que eu posso deixar a qualquer momento. É difícil não vestir a camisa de uma empresa que te oferece todas as condições necessárias para você sentir prazer em sair de casa e ir para o trabalho!
Ele deposita uma confiança tão grande na equipe e isso me fez agir em nome da empresa diversas vezes sem nem pedir permissão antes e por isso mesmo as pessoas pensam que eu sou sócio dele.
Não dá para explicar tudo isso em um único post e mesmo que eu conseguisse vocês não teriam paciência para ler!
Semana passada eu tive uma conversa com o Vinícius sobre como seria a minha participação na empresa daqui para frente já que eu trabalho part time e como eu estou me formando quero ganhar mais e consequentemente trabalhar mais. Dessa conversa surgiu um acordo onde eu iria continuar part time e iria arrumar outros trabalhos no resto do meu dia e num primeiro momento o que parecia é que eu iria voltar ao mercado de consultorias, sobretudo em XP.
Só que me veio a cabeça a idéia de procurar uma vaga na Surgeworks, já que eu sabia da saída do Akita e adoro trabalhar com Rails. Comentei isso com o Vinícius que me falou que havia conhecido e adorado o Carl Youngblood e que poderia conversar com ele sobre uma ida part time para lá. Dessa conversa saiu a minha ida para a Surgeworks e o que é melhor ainda, a minha permanência na Improve It.
Publicado por Marcos Tapajós há 28 dias.
Agora o Integration Plugin suporta GIT!
Desde o lançamento do Integration Plugin eu tinha a sensação que faltava o suporte ao GIT porém como o plugin foi extraído dos nossos códigos e não usávamos esse SCM ele foi lançado assim mesmo.
Logo depois o Eduardo Fiorezi me enviou um patch adicionando esse suporte e posteriormente o suporte ao git-svn só que eu não aceitei de imediato pois faltava documentar e eu estava completamente sem tempo para isso. Só que hoje recebi um patch do Sylvestre Mergulhão atualizando a documentação.
Obrigado aos dois!
Publicado por Marcos Tapajós há aproximadamente 1 mês.
Como eu falei no meu outro post, nós estamos refatorando o Brazilian Rails e essa é a hora para quem quiser dar grandes sugestões e/ou colaborações. Quem quiser comentar algo ou faça agora ou cale-se para sempre! :-)
Tudo que estamos mexendo está em um branch chamado gems lá no Github. Para baixar o código basta seguir esses passos:
git clone git://github.com/tapajos/brazilian-rails.git
cd brazilian-rails
git checkout --track -b gems origin/gems
Publicado por Marcos Tapajós há aproximadamente 1 mês.
Já faz um bom tempo que o Tino conversou comigo sobre rescrever o Brazilian Rails só que nós fomos adiando e acabou não saindo nada. Freqüentemente nós recebemos várias sugestões e queria dizer que todas estão sendo analisadas e algumas já estão na nossa agenda(no meio digital dois corpos ocupam o mesmo espaço!).
Essa semana o Cássio e o Hallison deram a sugestão de modularizar o plugin para poder instalar apenas o que é realmente útil para um determinado projeto. Foi uma sugestão que não é inédita mas que eu juntei com uma outra que eu recebi faz um bom tempo que é transformar o plugin em uma gem para não precisar instalar em cada projeto.
A idéia é tornar um Brazilian Rails em um conjunto de gems de forma bem semelhante ao Rails mas que poderá ser usado como plugin da mesma forma como é usado hoje. Bem, esse é o futuro!
Pois bem, fiz um branch chamado gems lá no nosso repositório e já estou trabalhando na futura versão do Brazilian Rails. Se alguém quiser olhar e dar sugestões..
Publicado por Marcos Tapajós há aproximadamente 1 mês.
Freqüentemente eu vejo as pessoas com fork do Brazilian Rails deletando e refazendo esse fork a cada alteração no repositório original sem necessidade. Para manter o seu fork atualizado existe uma estratégia bem simples que eu vou descrever em 6 passos.
Fazer um clone do seu repositório e depois entrar no diretório local.
Adicionar o repositório original como um remote com o seguinte comando:
git remote add original url_do_repositório
Depois basta fazer um fetch do repósitório original. Esse nome original é arbitrário, você pode dar o nome que você quiser. Eu particularmente gosto de John!
git fetch original
Fazer o merge do que está no master do repositório remoto com o meu master.
git merge original/master
Resolver possíveis conflitos.
Fazer um push para o seu repositório no Github.
git push
