Empreendedorismo on Rails no Encontro de TI

Sairam os vídeos da minha apresentação no Encontro de TI. A palestra foi gentilmente cedida pelo Vinícius, originalmente apresentada no Rails Summit 2008.

3 comentários : 16.12.2008 09:10 PM

Palestra Utilizando Ruby com Bluetooth

Na semana passada eu apresentei no Latinoware a palestra “Utilizando Bluetooth com Ruby: A forma mais fácil de programar com Bluetooth”. Foi um sucesso total, a sala estava lotada e o pessoal se amarrou nas demonstrações ao vivo.

Coloquei os downloads na seção de artigos.

1 comentário : 07.11.2008 08:22 PM

Rails Summit dia 16: Obie Fernandez

Tudo que tenho para falar é como trabalhamos com os principios Ágeis. Eu começei em XP em 2000 e trabalhei com isso por muito anos… já são 10 anos de experiência. Nós buscamos a melhor maneira de desenvolver software. Começando sobre princípios e iterações sobre processos e ferramentas. Isso nos diz que a coisa deve estar em busca das pessoas. Como a programação em par impacta na produtividade? Isso parece contra a intuição, mas duas pessoas trabalhando em um computador pode ser mais produtivo que duas pessoas trabalhando em dois computadores. A melhoria do design no desenvolvimento em par é melhorado, além de ser mais gostoso. Pair programming não é uma coisa natural pois não é naturalmente usado em grandes empresas, mas é preciso aprender… e leva um certo tempo.

Eu acho muito importante ter dois teclados e dois mouses pois dessa maneira, uma só pessoa que tenha um perfil dominante não trabalha sozinha. Um dos princípios que melhora a produtividade é a revisão de código automática. Ao trabalhar em par isso é natural. Quando está trabalhando em par se trabalha o dia todo. Pois ao trabalhar sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim de um dia de programação em par você está cansado. Pois você realmente pensou e trabalhou o dia todo, mas você fica contente, pois sabe que teve o trabalho realizado.

É comum entre nós desenvolvedores, muitos de vocês mais inteligentes do que eu trabalham muito bem. Então dizem que demoram uma hora para realizar o trabalho, mas ficam horas escrevendo no blog e no twitter, fazem o trabalho em 5 minutos e depois vão para o almoço. O pair programming elimina isso. Ele te dá muita produtividade. Para as pessoas farerem pares é preciso contratá-las. Quando eu contrato pessoas para a minha empresa eu faço um post no meu blog e espero as respostas. Você diz as suas habilidades e é convidado a trabalhar por uma semana para nós sabermos se você é bom de verdade fazendo pair programming num projeto de verdade. Então nós contratamos as pessoas sem entrevistas, mas com elas trabalhando num projeto real por uma semana. Só por que alguém vai bem numa entrevista não tem relação em como ela é no dia-a-dia do trabalho. Em times pequenos é mais fácil de manter a felicidade de todas as pessoas. Times de 2 a 4 pessoas são boas opções. Além disso vocês podem ter problemas de comunicação.

Mais um principio que se pode utilizar ao ter um time de 2 a 4 pessoas é ter um time auto-organizado. Na nossa empresa a gente não tem chefes. Todos os times são auto-gerenciados. Pois se você tem um time desse tamanho de apenas pessoas boas e você tem um lema “todo mundo junto” as coisas simplesmente funcionam.

Software funcionando em contrário a uma extensiva documentação. Uma maneira de trabalhar desse jeito é usando rspec, nós somos fãs de rspec. É uma ferramenta tão eficiente, ela não somente ajuda você a trabalhar com o software, mas também para gerar uma documentação, que nós entregamos para o nosso cliente. Isso com certeza agrega valor ao nosso trabalho.

Eu me importo em ser real e essa uma razão pelo o qual eu estou envolvido por tanto tempo com Rails. Nós participamos do Rails Ramble de 2007, isso foi antes da formação do Rails Rocket, e isso mostrou pra gente que é possivel com Rails fazer um trabalho muito grande com pouco tempo. Foi muito bom trabalhar com essas restrições, pois na nossa área é comum o tamanho de um projeto expandir para caber no tempo total disponível para o desenvolvimento.

Nós trabalhamos com um conceito chamado 3-2-1. Que significa colocar um software no ar em 3 dias, onde temos 4 desenvolvedores, 2 da nossa equipe e mais 2 que chamamos para uma semana de trabalho.

Colaboração do cliente em frente a negociação de contratos. Isso tudo tem relação com transparência em relação ao cliente. Isso leva confiança ao seu cliente. Nós gostamos dos clientes com o qual trabalhamos.

Uma coisa importante é que você precisa ter um designer dentro da equipe que saiba fazer todo o visual do nosso projeto. Pois sem um projeto visual acabado, nós não temos o que mostrar para o nosso cliente. É bom ver exatamente como vai ficar e eu posso construir isso em 3 dias se você me mostrar como vai ficar.

Por outro lado, quando já temos um design, não temos muito o que divergir da maioria é que nós gostamos de user stories, que para nós significam a aceitação do cliente. Nós trabalhamos com cartões e com projeções para atividades que duram de 0 até 8 pontos de desenvolvimento. Com isso nós medimos o desenvolvimento de nosso equipe e quantos pontos podemos fazer por semanas. Na nossa equipe é comum fazer algo em torno de 25 pontos por semana. Em 0 pontos nós temos coisas que duram apenas alguns minutos e em 4 pontos nós temos coisas que duram uma semana.

Antes nós perdíamos muito tempo com negociação de contrato. Então nós desenvolvemos um documento, que serve como nosso contrato, que não exije que o cliente nos pague caso ele não esteja satisfeito. Esse contrato tem um termo especial que diz que ele não pode te processar por mais dinheiro que ele iria te pagar. O nosso contrato também estabelece que nós podemos contribuir com o mundo opensource com o código desenvolvido para eles, mas só as coisas que não são específicas do cliente, como plugins e gems que você desenvolveu para trabalhar naquele projeto.

E a última parte do manifesto ágil é responder a mudanças em vez de seguir um plano. Nós usamos um serviço chamado pivot tracker e ele é muito bom pois ele nos mostra muitas informaçõe sobre o nosso projeto, incluindo gráficos de burndown entre outros. A stand up meeting é outra coisa essencial para nós sobre como anda o nosso projeto e nos ajuda a dar mais uma previsão sobre quanto tempo esse projeto ainda vai demorar. Todos falam sobre o que fizeram ontem, o que farão hoje e sobre o que está atrapalhando o trabalho. Quando estamos com mais pessoas, como nós que já estamos com 20 pessoas, temos que mudar um pouco a dinamica do standup meeting, mas a essencial é a mesma.

Tenho mais uma coisa para falar, que coloquei no final, que é a parte mais importante do Hashrocker, a nossa empresa, é que nós achamos que a coisa mais importante é se divertir no trabalho. Sem diversão não há produção. Nós fazemos algumas coisas em conjunto para diversão.

E nós bebemos bastante para nos divertir e pulamos na piscina quando todos estão bêbados!

1 comentário : 16.10.2008 09:37 PM

Rails Summit dia 16: Phillippe Hanrigou

Existem diversos problemas com os testes do selenium. São naturalmente lentos, assim como qualquer tipo de teste de integração. Eles rodam no navegador, que são coisas instáveis, bugados. E ainda colocam pessoas poucos experientes para escrever os testes do selenium, o que é um problema. Tem que ser os melhores para fazer essa tarefa! Mas se é tão dificil, por que fazer?

E quanto mais javascript se usa, mais devem haver testes. Se você usa muito javascript a sua chance de ter algo que não funciona em todos os browsers é alta. E se você não suporta todas as plataformas, você estará perdendo dinheiro caso não suporte todas. Sobretudo na comunidade Rails. Então é por isso que temos que automatizar esse tipo de testes. E essas são coisas que tem que ser repetidas diversas vezes… então não são coisas que os humanos tem que fazer. A coisa mais fundamental sobre esses testes e a comunidade de Rails está usando esse tipo de ferramente, mas tem muitas coisas que podemos apredender dos mais antigos. Coisa que podemos aprender de antigos programadores XP, é que testes de aceitação são muito importantes. Pois os testes de aceitação dão poder ao cliente. Você precisa da aceitação para fazer o código correto, do ponto de vista do cliente. Os unit testes server para garantir que os pequenos pedaços funcionam, mas os testes de aceitação server para garantir que tudo funciona junto. O teste de aceitação é tão importante no desenvolvimento que ela não é considerada completa até que ela passe numa suite de aceitação. Uma suite de aceitação te gera confiança.

Depois da era de ouro, vieram os bárbaros! Os bárbaros são os browser, que impediram a realização de muitos testes de aceitação. Por sorte hoje temos o selenium.

Quando um teste falha, temos que investigar para descobrir onde está o problema. Então você tem que rodar isso na sua máquina e com sorte o problema também ocorrerá na sua máquina. A melhor forma de resolver o problema com mais facilidade é capturar a maior quantidade de informações no campos de testes: na máquina que rodou o teste, no browser e etc.

Agora a parte boa para diminuir o tempo de testes do selenium é que desenvolvemos o selenium-grid, que permite que diversos testes do selenium sejam paralelizados, inclusive entra diferentes máquinas de diferentes poderes de processamento. Um dos problemas, assim quando você coloca muitos fios de energia muitos juntos, é que você tem que garantir que um teste não irá interferir nos outros. Garantir por exemplo que as coisas irão rodar em stacks de Rails diferentes.

Uma coisa boa a fazer é deixar de fazer login como um teste no selenium, mas inserir diretamente um cookie no navegador e resetar a base de dados diretamente pelo teste do selenium. Isso é muito mais rápido.

A questão das fixtures. Testar com dados randomicos é complicado, pois há muitos efeitos colaterais. Testar usando fixtures fixas com grandes aplicações pode tornar a manutenção das fixtures muito dificil. Uma das soluções que podemos usar é criar os dados usados nos testes diretamente nos próprios testes, sem o uso de fixtures. Mas isso também é complicado, pois pode dar trabalho preencher objetos complexos. Uma solução plausível são os Object Mother. São como templates de objetos instanciados padrões, onde você passa parametros apenas para sobrescrever os valores do objeto que você quer que sejam diferentes do default. Existem diversas maneiras de fazer isso e há muita documentação na internet sobre o assunto.

Eu queria que vocês saissem daqui sem esquecer: não virem as costas para os testes de aceitação.

0 comentários : 16.10.2008 06:30 PM

Rails Summit dia 16: Carl Youngblood

Um ecossistema é a fauna e a flora e também o meio-ambiente de um certo lugar, não somente as coisas vivas, mas também o clima, por exemplo. Um conceito associado a um ecossistema é o aparecimento gradual. As coisas pequenas que quando atuadas em conjunto formam padrões e coisa mais importantes que as coisas pequenas isoladamente. Uma formiga individual carregando comida para dentro da toca sozinha parece que não faz nenhum trabalho importante. É um trabalho que nunca termina. Mas muitas formigas trabalhando em conjunto sem um chefe e de forma individual faz no conjunto um importante trabalho.

Agora como funciona o surgimento nas pessoas. Fazendo analogias do mundo real, como o crescimento das cidades e a comunicação de neurônios em nosso cérebro ele explicou como a inteligência coletiva é importante. Muitas das pessoas importantes do mundo muitas vezes são insuportáveis.

Agora o ecossistema do Rails. Dhh tem uma arrogância natural e sem ele não exitiria o Rails. Chad Fowler, James Buck, Michael Molina e Zed Shaw, todos eles são excentricos e tem caracteristicas exóticas, boas e ruins. Por último os humoristas do Rails Envy. Todas ajudam a comunidade internacional. Mas e o ecossistema Rails brasileiro?

Sem ser mau ou ser bom, qualquer pessoa não serve para nada. Que papel, você vai exercer?

1 comentário : 16.10.2008 06:29 PM

Rails Summit dia 16: Vinicius Teles

Serviços on Rails podem ser desenvolvimento, consultoria, treinamento, mentoring. Fazer serviços da forma certa deve ser acompanhado de paixão. Esse é a melhor maneira de se obter sucesso. Tendo paixão por um assunto, você tem paciência. Paciência é muito importante. Empreendedores não de fazem da noite para o dia. É preciso estudo, dedicação, ser entusiasta. O empreendedor levanta de rasteiras mais que outras pessoas. Hoje mais do que nunca a melhor estratégia é: give, give e give. Quanto mais você contribui para uma comunidade, mais você é importante para a comunidade e mais alguém estará disposta a pagar para você.

Quais as estratégias? Apresentações, apostilas, livros, traduções. Nosso maior exemplo nacional é o Akita, que se tornou internacionalmente conhecido pela sua colaboração a comunidade. Podcast, video, videocast, entrevistas, divulgação de trabalhos alheios. Todas essas coisas podem até acabar virando negócio, mas acima de tudo levam reconhecimento. O ser humano é caracterizado pela vaidade. É muito dificil querer entrevistar alguém e essa pessoa não querer ser entrevistado. Seja quem for esse pessoa será envaidecida, seja ela um ótimo ou bom desenvolvedor, mas que tem algo bom a ser divulgado. O entrevistado irá divulgar eventualmente mais que o próprio entrevistador e isso é uma grande alavancagem pessoal.

A melhor de todas as contribuições… se você já sabe escrever códigos escreva plugins, escrever gems e participe do movimento opensource. E para isso você não precisa nem sair do seu emprego atual. Hoje ninguém precisa obrigatoriamente ser empregado de uma empresa, o ferramental disponível e muito grande e pode permitir qualquer um ser dono do seu próprio negócio numa estratégia de longo prazo.

No Brasil é mais fácil se destacar que no exterior. Por todos os problemas que o Brasil tem, ele é um mar de oportunidades. E não é necessário largar tudo que você já faz hoje. Como trabalhar part-time em alguns projetos. Trabalhar no exterior e muitas outras coisas. O risco é muito baixo.

Alguns detalhes que precisam ser notados na vida de serviço. Da onde sai o dinheiro? Para alguns seria melhor trabalhar para empresa pequena, para outros uma empresa grande. Desenvolver software customizado para pequenas empresas é algo complicado, pois elas não tem dinheiro para pagar por desenvolvimento de software. Você sempre acha que está ganhando de menos e ele sempre acha que está pagando demais.

Serviços não escalam - assim, como Rails (brincadeira). Para se ganhar mais dinheiro com serviço, significa que você precisa ter mais gente trabalhando para você. Quanto você ganha é proporcinal a quanto de tempo você aloca em um cliente. Se você tem mais alguem trabalhando para você, eventualmente você pode ganhar o dobro. E quando você perceber que tem que contralar um batalhão de gente talvez você perceba de fato que serviços não escalam.

E aí você vai perceber que o trabalho com produtos são mais interessantes. Pois com um produto talvez você consiga resolver o problema de escala. Se você replica aquilo n vezes o valor que você pode ganhar não é proporcional a quantidade de tempo que você dedidou para o projeto. Como por exemplo o Highrise, que custa $24 mês. Se 1000 pessoas resolvessem pagar são $24000. E assim por diante e você pode perceber que isso pode gerar muito dinheiro, ainda mais se você considerar uma equipe pequena.

Se você vai fazer um produto sobre alguma área que não é computação, é bom você procurar alguém que entenda daquele negócio. Nós da computação não sabemos nada! O que é melhor? Um experimento ou um plano de negócios? Em Rails é possível que você consiga ter algo tão funcional que você possa colocar na mão de alguém que entende daquele negócio. Ou seja, fazer um plano de negócios eventualmente leva tanto tempo quanto fazer um experimento. Com a desvantagem de ele não te dar feedback.

Uma implementação é tudo. Não adianta apenas a idéia, se você não tiver uma implementação. Se você começa a ter algumas idéias e começa a fazer alguns experimentos, você pode encontrar um nicho ainda não explorado corretamente. No Brasil não é difícil encontrar um nicho. No Brasil existe o paradoxo do talentoso. Uma pessoa estudiosa, talentosa, ele quer ganhar dinheiro. No Brasil essa pessoa acaba procurando uma grande empresa, pois é lá que a grana está. Mas dentro de uma grande empresa, ela não consegue aproveitar o talento dessa pessoa. As grandes empresas estão sugando os grandes talentos e desperdiçando esses talentos. E quem está atendendo os pequenos negócios? Provavelmente os menos talentosos. Os pequenos negócios estão numa espécie de limbo e precisam de bons profissionais para resolver os seus problemas. E os bons profissionais não estão nem aí para os pequenos negócios, pois eles não tem dinheiro.

Eles não tem dinheiro para pagar alguns milhares de reais por mês para o desenvolvimento de um software. Mas eventualmente eles podem pagar uma mensalidade de 50 ou 100 reais e se você cria um mar onde se consegue navegar sozinho por muito tempo, num produto que atende pequenos negócios… milhares deles, que pagando pouco por mês geram muito dinheiro.

A oportunidade é muito grande!

0 comentários : 16.10.2008 06:23 PM

Rails Summit dia 16: Jay Fields

Existem 6 tipos de conceitos de testes: unit, external, smoke, functional, integration e acceptance. Nunca se deve ter medo de falhar quando se estar testando. Quando se trabalha com testes encontramos erros que passariam despercebidos. Os testes devem ser bem escritos e não serem esquecidos. Um erro comum é testar tudo. Em vez de testar tudo, teste as coisas mais importantes. Testes de aceitação no cliente também são muito complexos. Testes com interdependencia são bem problemáticos. Testes com problema de velocidade são críticos. Eles tem que ser rodados muitas vezes.

100% de cobertura de testes não é a meta. Em ruby podemos optar por toda essa cobertura. Não é necessário escrever testes para cobrir 100%. Os testes são a parte mais importortante do sistema. Se o seu negócio depende de uma funcionalidade que é crítica, ela deve ser muito bem testada. Para ter a confiança ao fazer refactoring é precisa ter alguma cobertura de testes, eles dão confiança. Seu código de testes deve ser limpo, perfeito.

As imaturidades do teste do selenium. Ele é bom, mas falha em algumas situações. Existem diversas maneiras diferentes de utilizar o selenium. É preciso escolher a maneira correta no seu contexto. Se você está programando em ruby, utilize selenium programando em ruby. O selenium tem outro problema grande: ele é muuuuuito lento. Grandes suites de teste do selenium são difíceis de manter. O selenium tem bugs, e roda em cima do navegador e algum bug no internet explorer pode fazer o seu teste quebrar e você irá demorar muito tempo para descobrir onde o problema está. O selenium não informa precisamente onde estão os problemas.

Selenium tem boas vantagens. Ele pode testar o seu site entre navegadores. Ele é o único a testar o fullstack de uma aplicação web. Ele é fácil de usar e por ter muitas maneiras de usar, ele pode se adaptar a praticamente qualquer ambiente. Ele é amigável para testadores. É a melhor solução para smoke testing.

Imaturidade do test/unit. Ele não é tester friendly. Os testes são procedimentos e se perde muito da orientação a objetos, não há herança entre testes. Ele testa apenas pequenas coisas. A sintaxe dele é horrível, não intuitiva, não há um mapeamento muito bom entre o código do software e o de teste. Não há um framework de mock incluído. Mas tem vantagens, ele é muito amigável com o desenvolvedor. Muitos desenvolvedores já utilizaram algum tipo de teste unitário. Apesar da sintaxe feia, os desenvolvedores estão acostumadas a ela. E é fácil de escrever para um desenvolvedor. Roda muito rapidamente.

Imaturidade de rspec. Rspec usa muita mágica para fazer as coisas funcionar. Ele é muito baseado no inglês, mas ao mesmo tempo não tão consistente assim com o inglês. Mas depois da familiarização com o rspec entender as convenções fica fácil. Não é tão simples de extender. Ele é focado em testes de comportamento (behavior), que são mais fáceis de entender. Ele gera documentação automática e possui um framework de mock embutido.

Imaturidade do Synthesis. É um framework de integração. Encoraja classes desacopladas. Dá confiança sem necessidade de fazer testes de integração traducionais.

Imaturidade do Expectations. Framework de expectativas, similar com frameworks de behavior. Ele é somente código, não existem métodos. Então por exemplo se um teste falha ele apenas diz que falhou uma coisa na linha 35, por exemplo. Então ele não tem documentação, pois há ligação entre uma linha de teste e sobre qual teste em si está sendo executado. Ele é bem conciso, então essa é a parte legal, por isso que eu uso ele para certas situações. Ele encoraja a realização de testes bem granulares. Os valores esperados são literais. Encoraja que você faça definição de métodos que sejam expressivos.

Experimente e faça o que funciona melhor para você.

0 comentários : 16.10.2008 01:52 PM

Rails Summit dia 15: Dr Nic

Eu, Dr Nic e Jason

Nosso doctor da comunidade contou como ele começou no Rails, em como foi chato ver pela primeira vez o tutorial de Rails de 15 minutos e como ele largou o Visual Studio e mudou para Rails.

Antes de fazer hacks em código as pessoas faziam hack em carros e o Dr Nic era triste pois os pais dele não deixaram ele hackear o carro, já que eles precisavam usá-lo. Depois apareceram os hacks de hardware, mas eles eram caros. E então apareceu o código, onde você não precisa gastar dinheiro nenhum para começar a hackear. No passado não havia tanto código quanto hoje, então hoje é muito fácil estudar código e olhar código para hackear.

Foram apresentados algumas estatísticas do número de projetos opensorce no sourceforge, rubyforge e github. É notável, pois há cerca de 6500 projetos no rubyforge, enquanto já existem 19000 no github!

Mais uma vez, assim como o Chad Fowler, uma palestra falando sobre reconhecimento pessoal. Dr Nic incentivou a colaboração, fazendo uma analogia com dinheiro. Se você tem $1,000 que você não pode gastar em lugar nenhum, para que serve esse dinheiro? Essa foi a relação que ele fez com os segredos de código.

Defendeu uma mudança no pensamento em relação a grupos e permissões, dando mais incentivo ao individuo. Na opnião dele simplesmente dizer que algo está quebrado é uma coisa muito lenta. Então normalmente ele interfere num projeto enviando um patch, pois este diz tudo que diversos e-mails não resolveriam. É algo como andar na frente. Em suas palavras: “There is no them”.

Falou sobre as diversas atividades que os desenvolvedores podem ter dentro de um projeto opensource e como cada uma dessas atividades individuais são importantes. Existem diversas oportunidades de contribuição em projetos opensource, inclusive os projetos não mais mantidos do Dr Nic. Enfatizou bastante a questão da não necessidade de permissão para fazer as coisas, e sobre como o git facilitou a nossa vida nesse sentido.

Ele citou o exemplo de um cara que trabalha com ele que programa em Cocoa, mas que não entende nada de software opensource, que não contribui com a comunidade. E mais um vez está a importancia dos blogs para divulgar a cultura opensource e mostrar para esse tipo de pessoa sobre como trabalhar colaborativamente pode favorecer a todos.

Os caminhos para se tornar bom na comunidade: aprender controle de versão(svn e git), aprender unit testing, começar um blog, aumente a sua bagagem técnica e na comunidade

Ele focou bastante ao falar do tdd. Ele não mexe em código que não tem teste, no máximo auxilia na documentação. E ainda falou das facilidades já oferecidas pelo Rails.

Sobre o blog ele falou da importancia que o blog teve para torná-lo conhecido e sobre como isso pode ajudar os profissionais para se tornarem também. Enfatizou que não é preciso escrever textos formais no blog, o importante é contribuir com qualquer coisa que você tenha aprendido. Isso ajuda você no futuro e ainda ajuda a comunidade.

Participar de conferências, mostrar o seu código, corrigir o código dos outros, fazer (boas) perguntas em forums, traduzir coisas para o português e para o inglês.

Don’t keep secrets! Compartilhe, compartilhe, compartilhe!

Esse é o caminho para o awesomeness!

0 comentários : 15.10.2008 05:05 PM

Rails Summit dia 15: George Malamidis e Danilo Sato

Foram desenvolvidos de diversos aspestos sobre REST, o principal foi o uso do REST para prover serviços, suas limitações e formas de escalar. Por fim o REST foi comparado com outros protocolos para prover serviços e enviar mensagens, como SMTP e XMPP. Esse tipo de protocolo pode ser mais escalável que prover serviços em REST dependendo do que se deseja.

No fim da palestra apareceu uma pergunta interessante que questionou se o serviço do Flickr era REST ou não. O questionamento foi em relação aos resources do Flickr não utilizarem a formatação clean das URLs como no Rails, mas passando parâmetros na URL da forma convencinal para informar a action desejada. O George defendeu que os serviços do Flickr são REST sim, apenas não utilizam a mesma formatação de URLs Rails. Na opnião dele se são recursos que podem ser acessados e cacheados então ele considera sim como sendo um recurso.

0 comentários : 15.10.2008 03:59 PM

Rails Summit dia 15: Chad Fowler

Palestra Chad Fowler

Chad Fowler falou bastante sobre como se promover no mercado como desenvolvedor. Ele fez analogia comparando o desenvolvedor com produtos, mas não de maneira negativa. Apenas informando que o desenvolvedor deve saber se apresentar para o mercado, fazer barulho para se mostrar, fazer marketing pessoal. É uma coisa que muitos desenvolvedores não gostam de fazer, mas é necessário se você quer crescer como profissional. Um dos exemplos dados por ele foi o de um funcionário que sabe desenvolver 5 vezes mais rápido que qualquer um da equipe de desenvolvimento, mas não fala isso pra ninguém e continua trabalhando com suporte.

Ele falou também sobre produtos que ele classificou como remarkable. Seriam coisas que tem potencial de sucesso, como foi/é o caso do Rails. Também foi o caso do iPod, que entrou para concorrer nos Estados Unidos num mercado onde se compra um MP3 Player por $15 e o iPod algumas centenas de dólares. E o principal, enfatizou que o profissional deve ser remarkable.

Não foi nada que eu já não soubesse, mas é legal ouvir de alguém com renome na comunidade.

Hora do almoço!

0 comentários : 15.10.2008 02:11 PM

Em Julho: Ultra Maratona How To!

logo_maratona

Em 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, entre R$60 e R$90.

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 o Felipe Barreto. 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.

0 comentários : 13.06.2008 11:00 PM

Palestra sobre Rails 2 no FISL!

Pra quem ainda não viu, a página do programa do FISL 9 divulgou nos últimos dias a segunda lista de palestras e entre elas a minha foi aprovada.

O título é: Rails 2: Arrumando a Casa! Baseado nos slides do Peepcode sobre o Rails 2, falarei sobre esses assuntos:

A palestra não está pronta ainda, sugestões são bem vindas. Apareçam por lá!

4 comentários : 17.03.2008 08:21 PM

Falta tempo! Eventos, eventos, eventos!

O mês de novembro foi bem conturbado, gostaria de ter mais tempo para postar aqui, mas está bem difícil. Gosto de escrever com calma, revisar bem, então sempre demoro para escrever posts técnicos, por exemplo. E nesse mês definitivamente tempo foi escasso. Assim que possível vou escrever sobre como foi migrar o blog para o Mephisto e para o Rails edge. Posso adiantar que foi divertido e com emoção.

Participei de dois eventos em sequência. Primeiro Conisli, São Paulo, onde apresentei uma versão nova da palestra Nos Trilhos Com Rails, que já está disponível para download, e também a palestra sobre o BlueZone. Depois direto de São Paulo para Foz do Iguaçu: Latinoware. Sem dúvida um dos melhores eventos de Software Livre que já participei, com uma estrutura fenomenal dentro do Parque Tecnológico de Itaipu. No Latinoware ministrei um workshop de Rails e também a mesma palestra sobre o BlueZone.

Ao chegar de volta ao Rio, uma semana depois de sair, infelizmente não tive disposição para voltar a São Paulo para o RejectConf, mas sem dúvida estarei presente no RioOnRails. Novidades a caminho, quem quiser conversar, apareça!

0 comentários : 25.11.2007 01:15 PM

Inscrições abertas para o V Fórum de Software Livre

Logo V Forum

Atenção pessoal! Estão abertas as inscrições para o V Fórum de Software Livre do Rio de Janeiro. Para se inscrever visite o site e abra o menu correspondente. A inscrição para participação nas palestras e circulação na área do evento é GRATUITA. Os minicursos são cobrados com desconto para estudantes e servidores públicos.

Esse ano mais uma vez contamos com quatro dias de fórum: dois no Clube de Engenharia e mais dois, na Unirio, com foco no público técnico. Na Unirio, além das palestras também teremos minicursos diversos visando introdução ou aprofundamento de assuntos técnicos pertinentes ao mundo do Software Livre.

Avançando um passo de cada vez, esse ano temos a confirmação do nosso primeiro palestrante internacional: Maddog Hall! Foi uma grande conquista para o nosso evento. Esperamos com isso conseguir um pouco mais de visibilidade da comunidade de Software Livre do Rio de Janeiro, que sabemos ser grande, mas infelizmente muito dispersa.

Até lá!

1 comentário : 21.09.2007 06:38 PM

Bluezone em Itajubá

Semana passada tive o prazer de apresentar o BlueZone para o pessoal de Itajubá. Na seção de artigos já está disponível para download os slides da apresentação.

0 comentários : 07.09.2007 11:29 AM

Design by: styleshout | Valid XHTML | CSS        ATOM Feed        Rio de Janeiro        Powered by Mephisto