Este artigo visa explicar a User Interface do Android, voltado principalmente para o design, portanto vamos abordar aqui a documentação do Android que trata desse assunto.

Em pesquisa intensa pela internet percebi que poucos abordam as especificações do Android para fazer a aplicação de uma skin, a discussão está mais voltada a desenvolvedores, otimização, xml etc, quase nada trata de fontes, ou padrões visuais. Então muitos designers se perguntam como fazer uma skin para uma app Android, já que não é somente abrir o Photoshop ou outro software gráfico e começar a desenhar.

Eu vou tratar aqui exatamente desse tema, não só deixando a mão as fontes (TTF) para você, mas como toda pesquisa que for feita sobre o assunto, haverá PSDs para baixar, ícones e muito mais, material para você começar a produzir sem qualquer complicação. Portanto deixe esse link nos seus favoritos pois ele será atualizado semana a semana, conforme eu for criando novos posts eu vou inserir o link dos temas nesse artigo, assim ele será um guia para você encontrar o que deseja.

Estarei postando aqui a UI Guidelines e comentando-a onde for pertinente, e alguns desenvolvedores poderão fazer uso já que estará tudo mastigado e com isso quem quiser se aventurar em criar algumas skins para suas apps não terão tantos problemas, mesmo assim aconselho, contrate um bom designer, pois ele saberá discutir não só como fazer uma skin, mas como criar um visual atraente e funcional, discutindo inclusive seu wireframe.

Vamos começar entendendo o que é a UI Guidelines, ela é separada na plataforma Android por:

.

Icon Design (design dos ícones)
.

.

App Widget Design (componentes da interface da app)

.

• Padrão anatômica de um widget
• Projetando um widget
• Padrão de tamanho de um Widget
• Padrão de frames de um Widget
• Padrão de sombras de um Widget
• Widget – dicas e truques gráficos
• Widget – formato de arquivo gráfico

.

Activity and Task Design (atividades e tarefas, ou seja, os comportamentos)

.

• Entendendo de forma geral as tarefas
• Dicas de design

.

Menu Design (todo o comportamento do menu)

.

• Opções do Menu
• Contexto do Menu e atalhos

.

Talvez você se pergunte porque é necessário saber isso e não apenas pegar um PSD Guideline e começar a criar. A resposta é bem simples, se você quer criar um app que realmente as pessoas vão usar você deve respeitar e entender esses padrões, saber dos recursos que são suportados por essa plataforma e suas limitações.

Afinal por ser um sistema aberto, qualquer um pode subir uma aplicação na AndroidMarket, por mais bugada que seja, porém o que vai definir o sucesso da sua app será os cuidados que tiver em respeitar a Guideline, o seu conceito, e o seu design.

FONTES

Droid Serif

Droid-Sans

Droid-Sans-Mono

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath

Twitter!

Aprendendo Scala

Estou começando uma série de posts sobre Scala para divulgar as minhas experências com a linguagem e suas aplicações. Vou tentar passar o funcionamento da linguagem e seus recursos, assim como também um pouco do paradigma de programação funcional, e tentar chegar em aplicações práticas no ambiente de desenvolvimento.

Existem alguns tutoriais disponíveis na internet bem interessantes mas que as vezes jogam muito conteúdo sem dar tempo para assimilar os conceitos. Nessa série de posts tentarei colocar os conceitos e ferramentas de Scala e linguagens funcionais de uma maneira natural, conforme eu mesmo for evoluindo na linguagem e também dando exemplos e exercícios para que você possa assimilar o que está sendo passado. Vou tentar explicar também conceitos mais teóricos do paradigma funcional, para que a linguagem que estamos falando seja a mesma.

Minha experiência com Scala é algo bem próximo do zero, por isso estou escrevendo esta série de posts com o intuito de me forçar a estudar a linguagem e também ajudar a divulgar uma das possíveis alternativas ao Java, afinal se trata de uma linguagem nova e que ainda não foi muito difundida na comunidade. Tratarei bem do básico nos primeiros posts com exemplos bem trivias apenas para ajudar na compreensão dos conceitos básicos. Também colocarei algumas bibliografias de onde se pode encontrar documentação sobre a linguagem.

Linguagens funcionais e Scala

Não é nova a ideia de se programar em um paradigma funcional. Linguagens funcionais existem a quanse tanto tempo quanto existe linguagens de programação. Com certeza na sua faculdade você viu, ou verá, linguagens como LISP, Scheme, Erlang, Clojure, etc… e atualmente que está ficando bem conhecida: Scala que roda em cima da JVM, a virtual machine do Java. Linguagens funcionais mudam o paradigma para focar em ‘funções’. Assim como em linguagens orientadas a objeto onde a unidade básica é uma intância de um objeto, em linguagens funcionais a unidade básica é uma função. Uma função nada mais é do que uma operação que recebe parâmetros, executa alguma ação e devolve um resultado. O funcionamento é muito parecido com o dos métodos em linguagens orientadas a objeto.

O interessante sobre Scala, é que a linguagem permite uma mescla do paradigma funcional com orientação a objeto. Existem conceitos de ambos implementados na linguagem e que fazem sentido quando aplicados em conjunto. Por exemplo, em scala existe o conceito de classe e de instâncias de classes, que são os objetos. Também existem funções que independem de uma classe para existirem. Se trata de um conceito muito poderoso, pois possibilita toda padronização e controle do design do sistema que as linguagens orientadas a objeto permitem, sem restringir o uso do dinamismo e abstração da linguagem funcional.

Mas claro que Scala e linguagens funcionais tem seus problemas. Por exemplo, não existe uma IDE sólida como o Eclipse ou o NetBeans para Scala. O que dificulta no momento de trabalhar com projetos muito grandes, com uma equipe com vários programadores. O dinamismo da linguagem também impede uma análise de código que por exemplo o PMD, ou o FindBugs disponibilizam no Java. Dessa forma, deveríamos garantir que as boas práticas e o design está sendo seguido com nossos testes unitários.

Chega de filosofar sobre a linguagem, vamos para a parte prática.

Instalando Scala

Para instalar o Scala basta acessar a página oficial de download neste link, e fazer o download de acordo com sua plataforma. Feito isso, descompacte o conteúdo em alguma pasta na sua máquina e adicione a pasta ‘bin‘ ao path do seu sistema operacional. Para se certificar que foi tudo instalado corretamente, abra um console e digite ‘scala‘, o terminal do scala deve abrir e aparecer uma tela como essa:

Agora que o terminal está sendo executado, digite ‘1 + 1‘ e repare na saída:

É uma saída um tanto quanto confusa, mas que faz sentido no contexto do Scala. O que está acontecendo é que a unidade básica em Scala é uma função, portanto a operação + também é uma função, que foi executada no objeto ‘1‘, passando o parâmetro ‘1‘. Para se ter uma idéia melhor desse funcionamento, digite o seguinte no terminal:

e aperte Enter. Repare na saída:

Com exceção do tipo que era int e agora é Double, o funcionamento é exatamente o mesmo. Tal sintaxe já deve estar bem claro na cabeça da maioria dos programadores, mas a primeira sintaxe é só uma maneira difetente de se fazer a mesma chamada.

Conceitos básicos da linguagem

Vamos definir uma função para entender um pouco mais da sintaxe. Digite o seguinte:

Aqui estamos definindo uma função com o nome ‘a‘ que não recebe parâmetros, e devolve o resultado da soma ‘2 + 2‘. A palavra restrita return não é necessária, o compilador consegue inferir que a última expressão da função será o valor devolvido. Repare também que não precisamos definir o tipo que a função devolve, o qual também foi inferido pelo compilador. Portanto ao contrário do que possa parecer, Scala é uma linguagem tipada em tempo de compilação, portanto o seguinte trecho não compila:

Repare que o compilador inferiu que o tipo da variável ‘b‘ é String (note que é o String do java), e que o tipo devolvido por ‘a‘ é Int, logo o código não compila. De certa forma esse comportamento é bom, pois garante uma maior integridade do código, sem que você tenha que programar para “deixar o compilador feliz“, ou seja, não existem tantas regras na escrita do código, porque muitas podem ser deduzidas a partir do contexto.

Um outro conceito de Scala é a diferença entre chamada por valor, e chamada por nome. Na chamada por valor é feita a evaluação da expressão assim que o código é executado, mesmo que não seja necessário usar o resultado da chamada. A vantagem é que evitamos executar outras vezes a expressão para obter o resultado, pois este já foi determinado. Na chamada por nome a evaluação da expressão ocorre apenas quando o resultado da chamada será usado, tendo um comportamento mais lazy. A desvantagem é a execução da expressão várias vezes para se obter o mesmo resultado, mas a vantagem é não fazer a execução quando não for necessário. Vamos ver um exemplo da diferença entre a chamada por valor e por nome. Volte no terminal e defina a seguinte função:

Agora defina uma função que recebe dois inteiros e devolve o primeiro:

Agora execute a chamada passando ‘loop‘ como segundo parâmetro e se prepare porque seu console irá travar na execução =):

Vamos fazer uma pequena modificação na definição de ‘primeiro‘ para tornar possível a execução de tal código:

O que definimos agora foi que o segundo parâmetro de ‘primeiro‘ será uma função que devolve um Int. Assim seu resultado só será obtido quando for feita a chamada direta na expressão. Agora conseguimos fazer a chamada em nossa função:

Nossa função executou e finalizou sem problemas dessa vez, isso porque não foi necessário utilizar o segundo valor para obter o resultado. Essa é chamada por nome, e o primeiro exemplo é a chamada por valor.

Até agora vimos como invocar funções, como definir funções (def) e como definir variáveis (var). Vimos também o básico de inferência de tipo pelo compilador do scala e os primeiros conceitos da linguagem. Mas como eu havia dito, Scala também tem conceitos de orientação a objetos, portanto vamos definir nossa primeira classe em Scala:

Lembre-se que não somos obrigados a definir o tipo devolvido pela função caso esteja explícito e também não precisamos da palavra reservada ‘return‘. O que fizemos foi definir uma classe que se chama ‘AcumulaSoma‘ que tem um atributo, que por padrão do Scala é de acesso privado, que se chama acumulado e que o compilador inferiu o tipo inteiro baseado no valor atribuído. Também definimos para a classe a função ‘acumula‘ que recebe um inteiro, guarda o valor acumulado até então da soma com o parâmetro passado e devolve tal valor. Vamos instanciar um objeto da nossa classe e fazer a chamada ao método:

Algumas diferenças com o Java (supondo que estamos mais acostumados com a sintaxe do Java) já podem ser notadas. Além da inferência do tipo de ‘ac‘ para ‘AcumulaSoma‘, criamos ‘ac‘ com a a palavra reservada ‘val‘, ou seja, estamos dizendo que diferente de ‘var‘ onde criamos uma variável, estamos criando um valor e estamos garantindo em tempo de compilação que este valor não pode ser alterado no código. No Java teríamos que usar a palavra ‘final‘ para obter o mesmo comportamento, em Scala temos que “satisfazer menos o compilador“. Também não foi necessário usar ‘()‘ para invocar o construtor de AcumulaSoma, e assim como no Java toda classe em Scala tem por padrão o construtor que não recebe parâmetros com acesso público. Continuando o exemplo:

Nada de novidade aqui, estamos invocando a função ‘acumula‘ no objeto ‘ac‘. Porém ‘acumula‘ é uma função que recebe um único parâmetro e devolve um valor. Dessa forma podemos executar a chamada da nossa função da outra forma que vimos anteriormente:

No Java conseguimos definir classes estáticas. Em Scala não existe exatamente o conceito de classes, atributos e parâmetros estáticos, porém existe um conceito mais bem definido: ‘object‘. Criamos um ‘object‘ igual criamos uma classe, com a diferença de que não é possível instanciarmos um object, afinal estamos definindo o próprio. Com essa diferença, estamos garantindo em tempo de compilação que o design do código, em que foi tomada a decisão de restringir a existência de apenas uma definição para determinada classe seja seguida. Em Java também é possível garantir tal critério em tempo de compilação, mas demanda a escrita de bem mais código e de uma compreensão um pouco maior do funcionamento e limitações da linguagem. Um exemplo de object:

Existem os tipos primitivos básicos em Scala como Int, Long, Boolean, Float, Double, Short, Byte, Char e String, sendo que String é a String do ‘java.lang‘. Um fato interessante sobre Scala é que como a linguagem roda em cima da JVM, todas as bibliotecas disponíveis para Java também estão disponíveis para Scala.

O tipo que não vimos ainda é o ‘void‘. Em Scala não existe o conceito de void, toda função devolve um valor e quando não há um valor explícito a ser devolvido o compilador se encarrega de devolver um valor do tipo ‘Unit‘. Exemplo:

‘print’ é uma função que imprime um valor no terminal e não devolve valor, logo nossa função ‘imprime‘ também não devolve valor, portanto o tipo devolvido é ‘Unit‘, que também pode ser expressado/escrito como ‘()‘. A diferença básica entre void e Unit, é que Scala permite criar valores e variáveis do tipo Unit, e em Java por exemplo não é possível criar uma variável do tipo void. Também é possível analisar o valor devolvido por qualquer função mesmo que a função não devolva um valor definido e neste caso será um Unit. Um exemplo trivial de como usar este comportamento:

O tipo ‘Any‘ é análogo ao ‘Object‘ do Java, portanto pode ser qualquer valor, função ou objeto.

Nessa função estamos usando um tipo de switch case para obter o mesmo comportamento do ‘instanceof‘ em Java, afinal não existe tal operação em Scala. O que está acontecendo é que a função verificaUnit recebe uma função que não recebe argumentos e devolve um valor qualquer. A função ‘f‘ é então evaluada e o resultado da função é testado nos cases da operação ‘match‘. Caso seja do tipo Unit, imprimimos “Eh Unit!”, e no caso padrão imprimimos “Nao eh Unit!”. Repare que diferente do ‘switch‘, no ‘macth‘ não temos que chamar a operação ‘break‘ para não executar os outros casos. Para testar verificaUnit vamos fazer a chamada usando nossas outras duas funções que foram definidas:

Um exemplo mais prático

Vamos implementar um exemplo um pouco mais prático que calcula a raiz quadrada aproximada de um número. Para isso vamos usar o método de Newton de aproximações sucessivas. A idéia é bem simples, nada mais é do que uma busca binária entre os palpites que se aproximam cada vez mais da raiz quadrada do número passado. Vamos começar definindo uma função que diz se a raiz encontrada é boa o suficiente para ser o resultado:

O bloco if é igual a sintaxe usada no Java, o mesmo vale para o else e o else if. Na segunda função estamos verificando se o número elevado ao quadrado é próximo o bastante do original. Agora vamos definir a função que faz um palpite melhor:

O que fizemos foi pegar um número para palpite que está entre o nosso palpite anterior e x dividido sobre o palpite anterior, onde x é o número que queremos obter a raiz quadrada. O método de Newton garante que para x >= 1 essa aproximação é sempre válida. Vamos agora a função que executa o método de Newton propriamente dito:

Estamos calculando a raiz quadrada de modo recursivo até que o resultado seja bom o suficiente. Agora basta definir uma base para nossa função, para isso iremos pré-definir um valor para o palpite base, guardando a chamada nesse escopo em uma outra função:

Pronto, basta brincar com algumas chamadas para nossa função que calcula a raiz quadrada =).

O resultado obtido não é muito preciso, mas também essa não é a melhor maneira de se calcular a raiz quadrada, inclusive para números muito grandes o algorítmo não funciona por restrições com a precisão do Double.

Algumas Considerações

A grande moda das linguagens funcionais está surgindo porque acreditasse que elas são o futuro para a programação concorrente e paralela, de que se o seu programa foi escrito em uma linguagem funcional você terá ganho o benefício da execução concorrente sem grandes esforços, bem, isso não é verdade. Linguagens funcionais como qualquer outro paradigma necessitam que o programa seja escrito de maneira que seu design seja voltado para execução concorrente ou paralela, a difenrença é que a sintaxe e as ferramentas disponíveis nas linguagens funcionais facilitam tal design.

Existem algumas técnicas de programação que surgiram com linguagens funcionais, como por exemplo Recursão em Cauda, que não entrarei no mérito nesse post mas que vale a pena pesquisar sobre o assunto. Tais técnicas facilitam a vida do compilador no momento em que for possível ser feita algum tipo de otimização.

Uma comparação que logo surge na cabeça dos programadores é: qual linguagem é melhor, Scala ou Java? A resposta é fácil… nenhuma. Cada linguagem tem um escopo e paradigma de atuação diferente, não tem como comparar ambas. O que talvez faça sentido comparar sejam fatores mais fora do domínio da linguagem, como por exemplo o tamanho da comunidade que utiliza efetivamente a linguagem, o tipo de suporte, a documentação disponível, as restrições de uso, mas em geral depende do caso de uso específico para o seu problema, e principalmente do gosto do programador.

Por enquanto é isso, em um próximo post tratarei de alguns outros tipos de funções e falarei um pouco mais sobre currying. Também darei exemplos de tipos diferentes de declarações de classes e objetos.

Referência: Scala By Example, Martin Odersky

Neste post vou compartilhar um pouco dos meus experimentos para tornar o suite de testes do Cifras mais rápido.

No atual estado do serviço eu tenho por volta de 800 testes automatizados usando Rspec 1.3 e Rails 2.3.9.

Estes testes cobrem o sistema praticamente todo e a são única forma ter a confiança necessária para trabalhar em novo recursos, correções de bugs e etc.

Este número de tests tem crescido consideravelmente desde que comecei a utilizar o Steak para testes de aceitação. Testes de aceitação possuem um papel muito importante em certificar que a funcionalidade é aceitável para o cliente em faz os testes em estado mais macro. Desta forma tenho coberto o sistema praticamente todo usando o Steak nas últimas semanas.

No entanto eu me vi em uma situação que já era perceptível mas começou a se tornar insuportável. Meu suite de testes (ainda com 800) estava demorando por volta de 4.5 minutos para ser executado. O mais estranho é que 800 testes é muito pouco para poder demorar tanto.

Arquitetura de um Saas

Cifras é um Saas que envolve pagamentos e múltiplos usuários dentro de um conta. Eu já trabalhei em vários outros Saas’s e todos que envolvem algum tipo de assinatura e vários usuários acabam tendo uma arquitetura muito parecida nos models.

Normalmente você possui os seguintes models: conta, usuário, assinatura, plano de uso, preferências e o uma associação para proprietário da conta. Além destes 5 models também existe um processo que insere alguns dados iniciais como categorias assim que uma conta é criada.

Fica claro que qualquer signup vai disparar uma criação em cadeia de uma conta com uma assinatura que possui um propietário (que é um usuário) e depois preencher as categorias e etc. Este processamento é bem rápido mas multiplicado por 800 (ou mais) acaba sendo um problema.

Eu não quero reduzir o número de models reunindo tudo no model de conta pois acredito que seria uma arquitetura bagunçada além de uma alteração que envolva tanto o banco de dados ser extremamente perigosa.

Eu não queria tocar em nada do código da aplicação apenas para fazer os testes se tornarem mais rápidos. Do contrário acredito que estaria ocorrendo um inversão das responsabilidades, fazendo os testes guiarem o desenvolvimento mais de uma forma errada.

1º passo: Logger

Comecei o trabalho de otimização analisando o log de test. Para ter certeza de onde cada query vinha e o tempo gasto, adicionei um plugin chamado query_trace.

É um plugin bastante antigo mas ainda funciona muito bem. Assim que instalei, fiz algumas anotações de todas as queries que ocorriam com frequência em meus tests e de onde elas vinham.

Mas o mais interessante que ao instalar o plugin a performance dos meus testes caiu drasticamente. A única razão para isto é que o plugin escrevia toneladas de textos no meu log, ou seja, operações que envolvem muito IO.

O que fiz foi anotar as coisas que me interessavam e remover o plugin, no entanto uma otimização que já poderia ser feita é alterar a estratégia de log do ambiente de tests para :info ao invés do padrão.

Apenas esta alteração tornou meu suite de testes quase 50 segundos mais rápido.

No arquivo config/environment/test.rb:

1
    config.log_level = :info

2º passo: Evitando consultas

Analisando o resultado do query_trace não havia nenhuma consulta extremamente lenta que ocorresse com frequência. Como eu já utilizava bibliotecas como SlimScrooge, Oink e NewRelic eu já tinha encontrado estas queries e resolvido a mais tempo.

No entanto, uma coisa que muitas vezes não nos lembramos é que qualquer validação de unicidade e associação do Rails vai disparar um consulta. Sim, uma micro consulta que normalmente gasta 0.3 ms e não incomoda em nada em ambiente de produção. Mas nos tests isso pode significar muito.

Como eu utilizava apenas factories (com FactoryGirl) cada spec acabava precisando de um before ou um let do Rspec que fazia uma chamada a Factory account que consequentemente criava todas outras factories associadas e ainda executava as validações.

As criações associadas não me incomodavam ainda pois eu estava atacando apenas as validações. A melhor alternativa que encontrei para remover os 0.3ms de cada validação foi usar fixtures.

Fixtures são carregadas apenas uma vez e não passam pelas validação, então em todos os momentos que eu precisava dos dados base como conta e usuário para fazer os outros testes eu passei a usar fixtures.

Por exemplo, nos testes de categorias eu precisava criar uma conta antes para associar uma categoria a ela. Este processo rodava em um before o que tornava os testes bem mais lentos, a partir de agora tudo é previamente carregado por fixtures.

No final, terminei com uma fixture para cada model base e criei helpers para o Rspec. Algo assim:

1
2
3
4
5
6
7
8
9
10
11
    def account

      accounts(:apple)

    end



    def subscription

      subscriptions(:apple)

    end



    def user

      users(:sjobs)

    end

E meus specs passaram a ficar assim:

1
2
3
    let :bank_account do

      Factory :bank_account, :account => account

    end

A desvantagem é que novos desenvolvedores terão que entender que o account é um helper já que ele é incluído pelo spec_helper.

Outra coisa que fiz foi incluir as fixtures base como globais para evitar ter que carrega-las manualmente nos specs.

1
2
    Spec::Runner.configure do |config|

      config.global_fixtures = :users, :plans, :accounts, :settings ...

Em vários casos o uso de fixtures para a base do sistema eu tive ganhos de mais de 100% em velocidade. Então a partir disso toda a base do sistema (5 models) utilizam fixtures nos models associados e factories em seus próprios models.

Por exemplo, no model User eu faço os specs usando a Factory user mas a sua conta é trazida de uma fixture e vice versa com os outros models base. No caso de Transações eu carrego usuário, conta, plano, assinatura e preferência através das fixtures enquanto as transações são criadas com factories.

3º passo: Evitando chamadas remótas

Uma coisa irritante da comunidade Rails são as modinhas. Por um lado é bom, pois as coisas se atualizam MUITO rápido por outro lado fixtures se tornaram diabólicas de um dia para o outro, também ocorreu com attachment_fu por exemplo e etc. O mesmo vale para mocks.

Se você vai fazer uma integração com uma API, você DEVE usar um mock para não fazer o request, essa é a regra. Eu simplesmente descordo!

Se sua aplicação depende da API para existir, eu considero totalmente errado fazer um mock disso pois você nunca saberá se por algum motivo a API mudou ou parou de funcionar, ou mudou de endereço.

Apesar de óbvio que uma API deve ter versões e não mudar dessa forma, nem sempre isso ocorre, ainda mais as API’s brasileiras.

Por esta razão os testes do Cifras executavam requests para o sandbox do MOIP, o que fazia eu ter a segurança que o meu código continuava funcionando com a API deles. Eu NÃO iria fazer um mock dessa parte e ponto final.

Isso causava uma demora de mais ou menos 1 min nos testes. Mas era um preço que eu preferia pagar.

Com uma dica do meu amigo Jeffry Degrande conheci uma ferramenta que resolve isso. O ephemeral_response faz o request para a API e armazena um cache com o retorno por um prazo pré-determinado. Defini que este prazo no Cifras seria de um dia.

Com este passo reduzi mais um minuto do meu suite.

4º passo: Trabalho de formiga

O último passo seria de fato passar spec por spec e olhar o que poderia ser otimizado. Em alguns pontos stubs faziam mais sentido, outros apenas um Factory.build ao invés de create tornava o test mais rápido.

Outras duas técnicas muito boas é utilizar Factory.attributes_for :meu_model e Factory.stub :meu_model.

Este passo não reduziu muito o tempo pois eu já utilizava desta forma, mas em alguns pontos eu tinha deixado passar então tive uma pequena melhoria.

Conclusão

O resultado final foi que de 5min eu consegui reduzir para 1.5 min. Ainda existe espaço para otimizações, mas por enquanto isso deixo de ser prioridade e será melhorado usando aos poucos seguindo The Boy Scout Rule.

A minha conclusão é que fixtures são excelente para alguns casos e factories também, então não existe nenhum motivo para este ódio contra fixtures. Você pode usar tanto fixtures quanto factories no mesmo projeto e tirar o melhor dos dois mundos.

Outra dica é quanto ao log e o ephemeral_response e sempre ficar atento para usar Factory.build e Factory.stub quando possível.

Se você tiver alguma outra dica, compartilhe nos comentários.

Hoje fiz um webcast ao vivo no MSDN sobre extensibilidade e otimização de aplicações em Silverlight 4 utilizando MEF. Em alguns dias este webcast estará disponível para download e eu atualizarei este post com o link para download do vídeo.

A demo que fiz durante o webcast foi feita utilizando o Visual Studio 2010 RTM e o Silverlight 4 RTM. No final desse post tem um link para baixar o arquivo com os fontes e o pptx da apresentação.

Abaixo tem também alguns links úteis sobre o assunto. Se tiverem alguma dúvida, basta postar um comentário aqui ou me mandar uma mensagem pelo Twitter, MSN ou email.

• MEF no Codeplex http://mef.codeplex.com
• Post meu explicando como usar MEF com Silverlight 3: http://blog.kelps.net/2010/01/extendendo-silverlight-3-com-mef.html
• Session de Glenn Block (@gblock) no PDC09 sobre MEF: http://microsoftpdc.com/Sessions/FT24
• Session de Glenn Block (@gblock) no MIX10 sobre MEF: http://live.visitmix.com/MIX10/Sessions/CL52
• Fórum Silverlight MSDN Brasil: http://social.msdn.microsoft.com/Forums/pt-BR/silverlightpt/
• Blog: http://kelps.net
• Twitter: http://twitter.com/kelps e http://twitter.com/xamlcast
• Podcast: http://xamlcast.net
• E-mail e MSN Messenger : kelps@cnzk.com.br

Update: Para quem assistiu ao webcast ao vivo, o minha última demo não funcionou corretamente mas o código fonte anexo já está “corrigido”. O problema estava na ordem que as ações estavam sendo executadas. O código ao vivo estava chamando a função DownloadAsync para baixar o xap adicional antes de encluí-lo no catálogo mestre. Acontece que ao fazer isso, o download estava terminado muito rápido, e quando chegou no catálogo mestre ele acabou não recompondo a aplicação. O código corrigido simplesmente inverte a ordem dessas 2 linhas no App.xaml.cs, fazendo com que a recomposição funcione.

No mês passado eu fiz uma apresentação no nosso grupo local de Ruby, o RailsMG, falando sobre otimização de frontend. As dicas da apresentação servem para qualquer linguagem, mas eu mostro como solucionar cada problema usando o Rails.

Como tive alguns problemas na gravação e para editar o que foi filmado no dia acabou não ficando muito legal eu resolvi regrar em formato de screencast. O vídeo tem por volta de 50 minutos e mostra os conceitas da otimização e como aplicar na prática em um projeto Rails.

No mês passado eu fiz uma apresentação no nosso grupo local de Ruby, o RailsMG, falando sobre otimização de frontend. As dicas da apresentação servem para qualquer linguagem, mas eu mostro como solucionar cada problema usando o Rails.

Como tive alguns problemas na gravação e para editar o que foi filmado no dia acabou não ficando muito legal eu resolvi regrar em formato de screencast. O vídeo tem por volta de 50 minutos e mostra os conceitas da otimização e como aplicar na prática em um projeto Rails.

A apresentação é bem parecida com a que apresentei no RailsForKids de 2009 mas com atualizações e novos slides (que você pode baixar separadamente aqui).

O código fonte dos exemplos está disponível no meu GitHub em github.com/danielvlopes/optimizing_rails_frontends e conta com uma versão usando o asset_packager e outra usando o jammit.

Twitter!

Ano passasdo perguntei ao Beck como passar parâmetros para Event Handlers adicionados dinamicamente, porque quando você adiciona Event Listener usando myComp.addEventListener(…), o handler deve esperar apenas o parâmetro do evento. O Beck deu uma solução para isso, mas deixou claro que é apenas uma solução “alternativa”, não a melhor delas.

Alguns dias atrás eu estava trabalhando com requisições simultâneas para o servidor e queria guardar o parâmetro da chamada, mas não queria ter que retornar ele do Java, então pensei em uma outra solução para isso. Considerando que seu Event Handler está esperando uma Function que tem somente um parâmetro Event, eu criei uma outra Function que retorna uma Function esperando um parâmetro Event. Mas o segredo é que o escopo de Function Closure permite que você acesse parâmetros tanto da primeira quanto da segunda Function, então você pode fazer isso:

Mas e agora se você quiser usar esse Event Handler diretamente no MXML? Bem, você não pode fazer isso:

Isso não vai funcionar porque a Function que retorna da primeira Function está esperando um parâmetro Event. Então, você pode fazer assim:

Estranho, não? Talvez mais um patter do FreaktionScript?

A cópia de objetos pode ser feita com apenas uma linha de código (6) e mais algumas anotações.

http://github.com/bfuster/dtomanager
Mirror DSL

Core J2EE Patterns, Transfer Object
Factory method pattern