Desenvolvendo aplicações web para iPhone

Tive pouco mais de duas semanas de experiência antes desta apresentação, mas deu para aprender bastante coisa.

Esta é uma atividade que estamos fazendo na GoNow para compartilhar o conhecimento com a equipe e treinar apresentações.

Espero que o vídeo possa agregar algum valor para você que vai assistir, fique a vontade para comentar.

Não estar gripado e com o nariz escorrendo já ajudaria um pouco, isto eu percebi

Aplicações web para iPhone from Renato Nitta on Vimeo.

]]> http://www.renatocn.com/blog/desenvolvendo-aplicacoes-web-para-iphone/feed/ 0 http://www.renatocn.com/blog/a-familia-aumentou-o-trabalho-mudou-e-o-brasil-nao-ganhou/ http://www.renatocn.com/blog/a-familia-aumentou-o-trabalho-mudou-e-o-brasil-nao-ganhou/#comments Thu, 22 Jul 2010 03:02:38 +0000 renato http://www.renatocn.com/blog/?p=409 Pois é, em pouco tempo muita coisa aconteceu, agora somos em 5 na família, a Thaís, minha filha mais nova nasceu tem um mês, saudável, pesada (3,650kg) e linda, como o resto da família, cof… cof.. claro.
Estamos todos muito felizes com chegada dela, a cada filho o mundo parece que dá uma volta, sendo assim, se contar a ida para o Japão, já devo ter dado umas 4 voltas ao mundo

Também mudei de local de trabalho, depois de algum tempo fuçando, lendo, indo em eventos e me interessando pela tecnologia, enfim estou trabalhando com Ruby e Ruby on Rails, ainda sei pouco, faço a interface das aplicações na equipe porque é o que tenho domínio, mas pretendo aprender cada vez mais e participar mais do desenvolvimento em ruby. Estou bastante otimista com a empresa (GoNow) e com a equipe, que foi muito receptiva, descontraída e super aplicada, em pouco tempo já pude aprender bastante sobre git, github, vim, ubuntu, scrum, testes, integração contínua e muito mais.
Já tinha lido sobre tudo o que tenho feito no último mês, mas na prática, como qualquer outra coisa, é bem diferente, bem melhor. Vamos ver o que nos espera daqui pra frente…

Ah! E o Brasil? Pois é todo mundo já sabe que não ganhamos a copa, mas precisava de algo para rimar.

Na Hous fiz muitos amigos, posso dizer que foi o melhor lugar onde já trabalhei, pelo menos até agora.
Minha vontade por lá, sempre foi de tentar inovar, de aplicar metodologias e tecnologias novas, estávamos seguindo um bom caminho, as perspectivas são muito boas, porém não vou poder acompanhar de perto o resto do processo, mas tenho certeza que meus colegas Housers vão dar continuidade em tudo o que tínhamos e o que ainda não tínhamos planejado, desejo um futuro muito próspero para todos vocês.

Não queria citar nomes para não ser injusto, mas tenho que mencionar pelo menos dois: o Rodrigo, que além de me conhecer desde o colegial, foi quem abriu as primeiras portas e me ajudou a voltar ao mercado brasileiro depois de eu ter passado tanto tempo fora do país e a Angela, que foi o superior mais humano, porém conseguindo manter o profissionalismo com quem já trabalhei, muito obrigado aos dois!
Um obrigado também a todos que de alguma forma faziam o meu dia de trabalho mais prazeroso, seja mostrando determinação na hora de resolver as “pipas” mais cabeludas nas madrugadas ou mesmo nas brincadeiras na hora do café.

Aprendi muito com todos vocês e espero que tenham aprendido algo comigo também, um grande abraço e até a próxima!

Recentemente, escutei minha esposa e pessoas mais próximas dizendo que tenho trabalhado demais. De fato estou trabalhando muito ultimamente, se contar as horas na agência e em casa, uma média de 14 a 16 horas por dia, contando com o final de semana, chego perto de 100 horas por semana, é muita coisa.

Mas isto me fez lembrar de um conto que ouvi no Rails Summit Latin America, agora não lembro se foi em 2008 ou 2009, foi na palestra do Rafael Lima, que começou contado três contos, um deles ficou na minha cabeça, era mais ou menos assim:

Todos os dias na savana africana, o antílope sabe que terá que correr muito para não ser comido pelo leão.
O leão por sua vez, sabe que se não correr muito para pegar sua presa, ele e seus filhotes poderão morrer de fome.

Moral da história?
Não importa se você é o antílope ou o leão meu amigo, quando o dia nascer, é bom você correr muito, correr tudo o que pode se quiser sobreviver.

É isto que tenho feito, estou correndo!
E olha que ainda não estou correndo tudo que posso, tenho metas e objetivos para atingir a curto prazo, e a médio/longo prazo, tenho um sonho para construir.
Isto sem contar que hoje já tenho dois, a partir do mês que vem, terei três filhos para criar.

Então com licença, mas preciso correr mais um pouquinho.

Este é um artigo que li em inglês e achei que seria bacana traduzir, hoje trabalho com uma equipe focada em .net e queria compartilhar os relatos do autor com o pessoal lá.
Espero que sirva de inspiração ou pelo menos para atiçar a curiosidade no assunto.

imagem por todorov40

Você é um programador .NET pleno.

Você já desenvolveu muitas aplicações com ASP.NET.

Você já gastou muito tempo, muitas noites sem dormir tentando descobrir detalhes avançados, como fazer a modelo orientado a eventos do ASP.NET trabalhar do jeito que você gosta.

Você já é experiente em padrões como “Presentation Model” ou “Model View Presenter” para adequar sua aplicação e deixá-la mais fácil de se testar fazer manutenções.

Você acha que Ruby on Rails é apenas mais uma dessas tecnologias de modinha e você não deve gastar seu tempo com isto, pelo menos até que o mercado comece a respeitá-la ou exigi-la quem sabe.

Bem vindo ao meu mundo.

Se você continua lendo este artigo até aqui já merece o meu respeito, porque você deve estar curioso o suficiente para saber como eu, após um mês desenvolvendo em Ruby on Rails, mesmo sendo um programdor experinte em .NET, posso dizer que muitas aplicações que fiz anteriormente, poderiam ter sido feitas em bem menos tempo e código, caso eu tivesse conhecido o Ruby on Rails antes.

Para ser justo, continuo gostando muito do .NET, afinal ele me ofereceu um ambiente no qual eu sempre pude entregar valor de negócio aos meus clientes. No entanto, eu sempre gosto de me lembrar que há várias maneiras e tecnologias para se resolver um mesmo problema, alguns melhores que outros. Sendo fiel a apenas uma tecnologia, eu acabo sendo obrigado, mesmo que inconscientemente a tomar decisões tendenciosas, fator que acaba prejudicando minha capacidade de agregar valor ao negócio.
Por exemplo, conhecendo uma linguagem de script dinâmica como o Ruby me faz pensar que eu posso escrever automações simples de batch/shell em bem menos tempo, se comparado com uma linguagem compilada.

Então, por quê não?
Descrevo abaixo algumas coisas que descobri e me trouxeram um novo paradigma como um programador .NET aprendendo Ruby, espero que se goste.

Não compile
Em Ruby, não existe o conceito de compilação, tudo roda em tempo de execução. Alguns podem dizer que a compilação é uma segurança para seu código, mas você deveria dar uma olhada em como o desenvolvimento orientado a testes, integração contínua, testes unitários (testes que não tocam em banco de dados ou web services) e injeção de dependência podem lhe ajudar a produzir código de qualidade e permitem boa flexibilidade para alterá-lo com confiança.

De repente compilar o seu código podem não ser tão útil assim.

Melhore o comportamento das suas classes dinamicamente – sem um Decorator
Usar o padrão de projetos Decorator é uma maneira de se fazer isto em linguagem tipada (outra maneira pode ser o Método de Template). Porém em Ruby, há muitas outras maneiras de melhorar uma classe dinamicamente e com facilidade, apenas pelo fato de que a linguagem suporta isto, sem ter que complicar a estrutura de seus projetos. Considere “module mixins”, “class_eval”, instance_eval, etc. É possível definir programáticamente métodos em uma classe em tempo de execução. Geração de código em uma linguagem tipada pode ser em caminho para conseguir isto, mas só de saber que existem outras opções já o tornam um solucionador de problemas melhor.

Diminua suas linhas de código em 10˜20% apenas por retirar todas as declarações de tipo e de interface
Ruby é uma linguagem dinamicamente tipada. Você não precisa declarar o tipo de uma variável antes de usá-la ou fazer seus parâmetros de método propriamente tipados. Isto significa que o seu código fica mais enxuto em detrimento a maior dificuldade de debugar e procurar por erros, certo? Nem tanto, se você acreditar em testes unitários e bons conceitos de orientação a objeto. Se as suas classes forem curtas e coesas, e seus métodos por sua vez forem curtos, bem intencionados e cobertos por testes, então debugar e encontrar erros será “mamão com açucar”.

Ajax sem dor
Ruby on Rails tem suporte embutido ao script.aculo.us, uma biblioteca Ajax com toneladas de efeitos para fazer sua aplicação mais “user-friendly” (você também pode usar jQuery). Em muitos casos, ter requisições web em Ajax no server side em Rails é equivalente a colocar uma tag de controle em suas páginas e escrever um método no code-behind, simples assim.

Com Rails, você não precisa de um O/R Mapper
Aplicando algumas conversões de nomes enquanto cria seu banco de dados, tabelas, colunas e objetos do modelo, você pode esquecer o castigo que é implementar um O/R Mapper, Ruby on Rails faz isto por você. Nos casos mais simples, tudo o que você precisa fazer é adicionar um campo em sua view, insistir para colocar um campo de texto no seu html e adicionar a coluna onde você quer que o valor seja guardado na tabela, depois é só assistir o texto inserido usuário popular a recém criada coluna no banco. De verdade, isto é tudo.

Usar scripts em Ruby para desenvolver/implantar/publicar é melhor que usar NAnt
A ferramenta padrão para isto em Ruby on Rails é o Rake. O Rake usa Ruby, isto significa que você usa Ruby em seus scripts para várias necessidades de desenvolvimento e implantação. Como linguagem, o Ruby é muito melhor quando se trata de manipulação de strings, criação de arquivos e diretórios, incluindo o suporte superior a expressões regulares. Pense em quantas vezes, em seus scripts de batch ou NAnt, você fez coisas como: para cada arquivo com a extensão .sql no diretório “a”, copie do servidor A para o servidor B e então execute um por um. Se você odeia as limitações de scripts batch ou não gosta das coisas no formato xml do NAnt, há grandes chances de você gostar do Rake.

Sem dor, sem ganho
Sim, existem alguns obstáculos que tive de atravessar para aprender Ruby.
Primeiro, eu tive que lidar com as emoções para aceitar o fato de que incialmente iria levar mais tempo encontrar uma nova solução em Ruby do que eu levaria com uma tecnologia com a qual eu já estava acostumado. Esta é uma experiência muito dolorosa, mas depois de um tempo, você começa a perceber que consegue desenvolver diversas maneiras de resolver diferentes problemas, é aí que começa a ficar divertido.
Segundo, apenas ler sobre Ruby e Rails apenas me dispersa. Usar o que você aprende na prática, ajuda a fixar o que foi aprendido. Lembre-se use o que você aprende ou estará perdendo tempo investido em ler sobre isto.

Sobre o autor original
Stephen Chu é desenvolvedor de software, consultor da ThoughtWorks. Ele é um experiente desenvolvedor .NET e recentemente foi capturado pelo Ruby on Rails. Você pode ler mais em seu blog: http://www.stephenchu.com.

Considerações:
O artigo original pode ser encontrado aqui: http://www.infoq.com/articles/Netter-on-Rails.
Esta é uma tradução livre, pode conter erros que com o tempo vou revisando, se você encontrar alguma inconsistência entre os textos, por favor me avise.

Clean Install - com direito a formatação do HD

O backup

Talvez a parte mais importante e trabalhosa na instalação limpa de qualquer sistema operacional seja o backup, eu acho uma das partes mais chatas, mas também é a parte onde se encontram arquivos esquecidos, sumidos e uma boa hora para rever a importância de cada aplicativo ou arquivo presente na sua máquina.

Por sorte, o Mac OS X é um sistema bem amigável quando se diz respeito ao backup, provavelmente, a maneira menos custosa de se fazer é via Time Machine, mas como não uso o Time Machine, fiz do jeito “tabajara” mesmo.

Basicamente, há dois diretórios para se copiar, o Applications onde deveriam estar todos os seus aplicativos e o seu diretório de usuário, que é onde estão todos os outros arquivos que você provavelmente precisará, insto inclui seu Desktop, Documents, Downloads, Library, Movies, Music, Pictures e tudo mais que você tiver colocado lá.

A cópia do diretório Applications é opcional, uma vez que você deve ter todos os softwares para instalar depois, você pode querer apenas uma lista dos softwares que posui para poder instalar posteriormente, se for este o caso, use o seguinte comando no terminal:

ls /Applications/ >> meusapps.txt

Este comando irá criar um arquivo .txt com uma lista (resultado do ls) de tudo que estiver dentro de /Applications/, ou seja, todos os seus softwares.

Eu particularmente prefiro copiar logo o diretório Applications inteiro, assim, depois de instalar o novo OS é só jogar os softwares faltantes pra dentro do novo diretório Applications e ser feliz.

Já o diretório de usuário é só copiar tudo, depois você pode separar o que será ou não usado. Lembre de copiar o diretório todo, incluindo Desktop, Documents, Downloads, Library, Movies, Music, Pictures e o que mais tiver.

Se você é desenvolvedor, pode ser que tenha algo importante em outros locais como /usr/local/ por exemplo, se for este o caso, procure os dados que precisam ser preservados antes de limpar seu HD.

Com isto o backup deve estar completo, um HD externo deve ser uma boa pedida, pois o backup pode passar dos 100Gb dependendo do que você tem.

A instalação

O Snow Leopard, é uma atualização do Leopard e não tem a opção “erase and install” como nos sistemas anteriores, sendo assim, eu fiz o seguinte no MacBook, instalei o Tiger pelos discos de instalação escolhendo a opção “erase and install” para apagar tudo o que tinha no HD, fiz o upgrade para Leopard e depois mais um upgrade para Snow Leopard, achei que assim iria preservar tudo que veio nos discos de instalação e seguiria uma ordem sem perder nada. Mas notei o seguinte, a primeira instalação (Tiger) consumiu 17Gb de espaço, já o Leopard pulou para 25Gb e por último, o Snow Leopard caiu para 19Gb, isto contando todos os extras que vieram nos discos de instalação.

Fiquei achando que o Snow Leopard apaga muita coisa inútil e se pudesse instalar ele direto seria bem mais fácil, a unica coisa é que não teria iLife e nada que veio nos discos de instalação, mas isto é o de menos.

Sendo assim, no iMac resolvi fazer uma instalação limpa só do Snow Leopard.

Para fazer uma instalação limpa, direto pelo DVD do Snow Leopard, faça o seguinte:

1) Insira o DVD do Snow Leopard;

2) Reinicie o computador, quando ouvir o barulho clássico da inicialização, aperte e segure a tecla C, isto irá forçar o boot pelo disco. Assim que aparecer o logo da maça você já pode soltar a tecla C;

3) Assim que o Mac bootar pelo disco você verá a tela de inicio de instalação e também um menu superior, vá em Utilities > Disk Utility > Selecione o HD correto > Clique na aba Erase > Escolha o formato Mac OS X Extended (Journaled) nomeie o disco se quiser > clique em erase…;
Caso tenha partições no disco, cuidado para não apagar a partição errada.

4) Feche o Disk Utility e volte para a tela de instalação;

5) Clique continue, escolha o disco em que quer instalar o sistema e clique em install.

Depois de uns 30 e poucos minutos o Snow Leopard estará instalado.

Se quiser instalar por exemplo o seu iLife ou qualquer outro software que veio instalado no seu Mac, pegue os discos de instalação e instale apenas os aplicativos, opção: “bundled applications only”.

Feito isto, é só repor os arquivos do backup nos seus respectivos lugares e pronto, sistema novinho em um HD zerado.

Configurações iniciais e aplicativos úteis

Cada usuário acaba criando hábitos no uso de qualquer sistema operacional, vou listar algumas coisas que gosto de fazer antes de começar a trabalhar com o novo OS.

1) Velocidade de “tracking” do mouse
É impossível trabalhar com aquele ponteiro do mouse lerdo, parece que alguma coisa está com defeito, dependendo do mouse eu deixo no máximo “fast”. Já aproveito para habilitar o botão direito do mouse, pode parecer besteira, mas tem muito usuário de Mac que fica sem o botão direito sem saber.

2)  Quicksilver
Normalmente este é o primeiro software que instalo nas minhas máquinas, ele é uma ótima maneira de agilizar tarefas corriqueiras, como abrir um aplicativo, abrir ou mover um arquivo e muitas outras que você vai descobrir brincando com ele.
Site do Quicksilver.

3) Layout do teclado
Até o Leopard, não existia layout de teclado onde se pudesse usar o teclado americano e o português como idioma de entrada, assim tínhamos de instalar um layout adicional, há um layout US International desenvolvido por Rainer Brockerhoff, que pode ser encontrado aqui.
Mas para minha surpresa, o layout do Rainer foi incorporado no Snow Leopard.
Para configurar os layouts de teclado, basta ir em System Preferences > Language & Text > Input Sources

4) Enchergando todos os arquivos
Gosto de poder ver pelo Finder, todos os arquivos do meu sistema, há algumas maneiras de se fazer isto, a maneira mais “roots” que é pelo terminal, para isto pode-se rodar os seguintes comandos:

defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder

Ou da maneira mais fácil que é usando algum aplicativo, para isto, uma ótima opção é o OnyX, este aplicativo é uma ferramenta de manutenção, muito bom para verificação de discos e reparar permissões, mas dentre suas funções, há a opção de habilitar a visualização de arquivos ocultos.
Para isto, abra o OnyX, vá em Parameters > Finder > Show hidden files and folders

5) Personalizando a barra de ferramentas do Finder
Outra coisa que sinto falta no Finder em uma nova instalação, são mais opções na barra de ferramentas, basta ir em View > Customize Toolbar e montar sau barra de ferramentas.

6) iStat Menus
Outro aplicativo bem bacana é o iStat Menus, com ele consigo monitorar toda a saúde das minhas máquinas, vale a pena dar uma olhada.

Com isto eu acredito que o setup inicial está feito, agora é só instalar os softwares de uso, configurar contas de e-mail, ambiente de desenvolvimento para desenvolvedores e por aí vai.

Mas grande parte das anotações que estou fazendo vão servir para atualizações futuras do sistema operacional.

Tenho o Mac OS X desde o Jaguar, quando comprei meu primeiro Mac em 2003, um eMac G4 que tenho até hoje, mas fiz a “formatação” da máquina, ou seja, a “clean install” uma ou duas vezes, fui apenas fazendo os upgrades e nunca tive problemas. Desta vez, resolvi que ia fazer uma limpeza geral nas duas máquinas que uso hoje, um iMac e um MacBook, mas o trabalho foi tanto que resolvi registrar alguns passos por aqui.

Antes de começar, queria comentar sobre algo que me chamou atenção no Snow Leopard, onde foi parar a caixa?
Com exceção do Leopard, que não veio nem embalagem porque ganhei da Apple (tinha comprado as duas últimas máquinas pouco antes do lançamento), todos os outros OS que comprei vieram em caixas bacanas, material de qualidade, manual e as firulas da Apple.
Mas quando vi o cara trazer o Snow, fiquei pensando… caramba, já paguei e ainda vou ter que pegar esse “cartãozinho” que o cara jogou na sacola e trocar em algum lugar quer ver? Engano meu, era o próprio que já estava na sacola, uma caixinha “safada” que já veio meio amassada e abrindo nos cantos.

Está certo que não faço nada com as caixas, talvez tenha até alguma relação com o impacto ambiental (que eu acho difícil), mas para quem já pegou produtos estilosos com toda aquela experiência que começa já na abertura do produto, foi meio broxante.

Alguém por acaso comprou um dos primeiros iPods? Eu comprei um, lembra como eram as embalagens? Já comparou com as de agora?

Enfim, vamos logo para o que interessa, Snow Leopard!

Eu estava escrevendo uma série sobre os meus estudos de programação na linguagem Ruby, mas meus artigos eram escritos a partir de anotações que fiz no caderno em meados de 2008 e depois para completar, fiquei  quase 6 meses sem conseguir postar nada aqui.
De lá pra cá, mudou tanta coisa que não vejo mais motivo para dar continuidade na série, se um dia a vontade voltar eu penso novamente.

Por enquanto vou tentar escrever mais posts sobre assuntos presentes, vamos ver no que vai dar…

puts ‘Hello World!’

Isto é um exemplo clássico de todas linguagens e já usamos o puts. Ok, usamos o puts, mas se ele é um método, onde está o objeto?
Este é um caso a parte, onde o objeto oculto é ele mesmo, “self”, então quando escrevemos:
puts ‘Hello World’
é o mesmo que:
self.puts ‘Hello World’

Métodos puts e gets:

puts ou “put string” – tenta converter o que vier na sua frente em string e retorna o resultado na tela

gets ou “get string” – pega todas as ações executadas no teclado até que se aperte ENTER

O gets também pega a quebra de linha quando apertamos ENTER, para evitar isto usamos o método .chomp para mastigar a string e nos entregar sem a quebra de linha.

Segue abaixo mais métodos em uma pequena lista:

Métodos de String:
.reverse – Reverte a ordem dos carácteres de uma string.
.length – Calcula a quantidade de carácteres de uma string.
.upcase – Converte os caracteres de uma string em maiúsculas.
.downcase – Converte os caracteres de uma string em minúsculas.
.swapcase – Iverte todos os caracteres, maiúsculas para minúsculas e minúsculas para maiúsculas.
.capitalize – Deixa o primeiro caracter maiúsculo.
.center – Cetraliza o conteúdo de uma string.
.rjut – Alinhar a direita.
.ljust – Alinhar a esquerda

Métodos de comparação:
> – Maior que
< – Menor que
>= – Maior ou igual a
<= – Menor ou igual a
== – Igual a? (importante notar que isto é uma pergunta, não uma afirmação como =)

Obs.: Uma observação sobre método de string .reverse é que quando testei uma string acentuada, a mesma retornou com os caracteres quebrados.

Retorno:

Os caracteres quebrados só aparecem na string onde usei o método .reverse, o que me leva a crer que é algum problema no método, mas não descobri ainda se é ou qual é o problema.

Se você sabe o que acontece com o método .reverse, peço que me explique, a versão do Ruby que estou usando é a 1.8.6.

Ainda há vários outros métodos para vermos, inclusive os que eu ainda não conheço, mas aos poucos eles vão aparecendo.

Se objetos (como strings, inteiros e floats) são os substantivos na linguagem Ruby, os métodos são como os verbos. E, ao contrário do Português (em que há sujeitos indefinidos e outras construções esotéricas), você não pode ter um verbo sem um substantivo para executar o verbo. Mas mesmo o Português trata a ausência de um substantivo como exceção: por exemplo, contar o tempo não é algo que simplesmente acontece; um relógio (ou cronômetro, ou algo parecido) deve fazê-lo. Em Português diríamos: “O relógio conta o tempo”. Em Ruby dizemos relogio.tiquetaque (presumindo que relogio é um objeto Ruby, claro). Programadores podem dizer que estamos “chamando o método tiquetaque do relogio,” ou que “chamamos tiquetaque no relogio.”
tirado da tradução do “learn to program”

Ou seja, métodos são coisas que fazem coisas, mas fazem coisas em objetos. Um método por si só não faz nada, afinal ele é um “método” de fazer algo, este algo no Ruby é um objeto.

A relação de método e objeto é como uma simbiose, andam juntos e ambos se beneficiam.

Já vimos que para usar determinados métodos usa-se um ponto (.) entre o objeto a ser manipulado e o método que vai manipulá-lo, então sempre temos objeto.método.

Ex.: Em 171.to_s para converter um inteiro em string, 171 é nosso objeto e .to_s é nosso método.

O que não sabemos de início, é que alguns métodos estão implícitos, como nos métodos aritméticos:

O resultado é o mesmo:

Para não precisarmos digitar o ponto toda vez que usamos um método, alguns já estão implicitos, isto facilita a escrita do código e também a leitura do mesmo, que fica mais limpo.