Re: [androidbrasil-dev] Comunicação Cliente - Servidor

Só para deixar claro, nunca disse que entregaria um produto de baixa
qualidade, mas sim, um produto viável...e, pra mim, acima de tudo a
viabilidade do produto é o que faz ele se sustentar a fim de poder
entregar mais e mais melhorias.

Não estou aqui fomentando a entrega de um produto esdruxulo e esquecer
que o cliente existe.

[]'s

Ernani

2013/2/5 Ítalo Gustavo Araújo <italogustavoaraujo@gmail.com>:
> Ótima discussão que começou quando disse tudo menos PHP. Eu também sou leigo
> em muita coisa por aqui vendo essa discussão consigo aprimorar mais meus
> conhecimentos. Uma coisa que todos nos desenvolvedores temos que fazer e
> valorizar nossa profissão é não fazer dela uma prostituição entregando para
> os clientes projetos mau feitos visando apenas o lucro, vamos nos
> conscientizar e dar mais valor ao nosso trabalho.
>
>
> Em 5 de fevereiro de 2013 09:50, Ernani Joppert Pontes Martins
> <joppert@gmail.com> escreveu:
>
>> Bacana pessoal!
>>
>> Também acredito que, há casos e casos, e, é claro, estou tentando
>> simplificar ao extremo aqui o tipo de
>> produto desenvolvido, também levo em consideração um produto maduro
>> que o cliente está disposto a pagar
>> e o produto está em constante desenvolvimento, e, independentemente de
>> bugs, ele funciona sem causar
>> detrimento ao cliente.
>>
>> O foco na minha frase não foi o sistema conter ou nào bugs, todos eles
>> tem,
>> quem nunca criou bugs que atire a primeira pedra...kkk
>>
>> Há casos e casos de produtos que podem ou não ter bugs, aplicativos de
>> missão crítica,
>> exigem um desenvolvimento mais estruturado, e também, com processos de
>> correção ou
>> identificação de bugs, seguindo aquela linha de Functional
>> Verification Testing, Internet
>> Verification Testing, Performance Testing, Security Standards check,
>> Architecture Review Board, etc.
>> Mas estes projetos ficam na mão de empresas gigantescas, e, portanto
>> não era o escopo do meu reply naquele e-mail.
>>
>> Conto com o bom senso de todos, e, espero que tenham entendido o ponto
>> que quero chegar, e,
>> nada do que disse é uma cartilha a ser seguida à risca.
>>
>> Valorizo muito a fase de levantamento de requisitos e, acredito que há
>> produtos a serem
>> criados dos quais nem mesmo os clientes sabem.
>>
>> Dêem uma olhada neste vídeo, é uma Lean Startup dentro de uma empresa
>> gigantesca, a Nordström,
>> eles criaram um lab de inovações, para, poder realizar novos produtos
>> em tempos recorde, este processo facilita a criatividade e a
>> interatividade com o cliente, ou o processo lean chamado de Genchi
>> Gembutsu, ou seja, vá e veja você mesmo o que o seu cliente precisa,
>> ou do que o seu produto precisa para atrair mais clientes...
>>
>> Eles criam um aplicativo de iPad em 1 semana, indo direto ao cliente e
>> levantando os requisitos
>> e seguindo um passo de ciclos de implementação bastante interessante...
>>
>> http://www.youtube.com/watch?v=szr0ezLyQHY
>>
>> Como o foco da lista é desenvolvimento de aplicativos para
>> dispositivos móveis, acredito que com um time enxuto e
>> com muita criatividade consigam também ir pesquisar melhor seu cliente
>> e tentar ao máximo entender do que ele
>> precisa pois muitas vezes nem o cliente sabe mesmo o que ele quer!
>>
>> []'s
>>
>> Ernani
>>
>> 2013/2/5 Renato Lima <renattolima@gmail.com>:
>> > Opa, a discussão tá boa, então só pra botar mais lenha na fogueira:
>> >
>> > Concordo com suas colocações Fernando, mas como bem colocado pela
>> > citação do
>> > meu chará logo acima: as coisas devem ser equilibradas.
>> >
>> > Quando você disse ao Ernani para "pensar fora da caixa", imagino que
>> > você
>> > deva fazê-lo antes, pois ao meu ver você está pautado num modelo
>> > tradicional
>> > que, de fato, faz todo o sentido no contexto por você colocado. Contudo
>> > não
>> > podemos tirar o mérito daqueles que fazem uma ideia acontecer
>> > independente
>> > de seguir padrões ou boas práticas de programação e nesse mundo
>> > altamente
>> > concorrente de startups isso faz uma diferença enorme. Falo com a
>> > experiência de quem já esteve dos dois lados da moeda (startups e uma
>> > empresa tradicional com um sistema consolidado e uma grande carteira de
>> > clientes).
>> >
>> > Já cansei de ver de perto os benefícios de boas práticas, assim como
>> > também
>> > aprendi a aceitar que elas podem (e às vezes até devem) ser colocadas de
>> > lado afim de tirar uma ideia do papel quando você sente que o tempo dela
>> > pode passar se você não agir rápido. Quando você já tem uma equipe
>> > concisa
>> > acostumada com padrões tudo flui, mas tente fazer isso com pessoas que
>> > não
>> > estão acostumadas a eles, pode ser desastroso.
>> >
>> > Eu tinha o pensamento como o seu Fernando, mas foi trabalhando com uma
>> > startup que eu aprendi a "pensar fora da caixa". Por isso acredito
>> > totalmente na proposta do Ernani que um sistema pode sim ser rentável
>> > mesmo
>> > apresentando bugs, aí entra seu poder de administração dos mesmos e
>> > saber o
>> > que realmente é prioritário para o seu cliente.
>> >
>> > Just my 2 cents.
>> >
>> > Abraço,
>> >
>> >
>> > Em 5 de fevereiro de 2013 03:46, Renato Toi <renato.toi@gmail.com>
>> > escreveu:
>> >
>> >> Excelente discussão. Há poucos dias li uma citação mais ou menos assim;
>> >> "quando os americanos colocaram uma estatua em homenagem à liberdade na
>> >> costa leste, deveriam ter colocado uma estatua à responsabilidade na
>> >> costa
>> >> oeste".
>> >>
>> >> Longe de mim querer discutir política, ideologia ou estatuas. Uso a
>> >> citação apenas para ilustrar os seguintes pontos:
>> >> 1- se há apenas uma dimensão sendo avaliada, cuidado, você pode estar
>> >> esquecendo de coisas importantes. O mundo não é uni-dimensional, e
>> >> muitas
>> >> vezes ha diversas dimensões a avaliar. Considerar apenas a métrica
>> >> "quantidade de bugs" pode não ser o melhor.
>> >> 2- "responsabilidade" é um critério essencial para as decisões
>> >> gerenciais.
>> >> A decisão bugs x prazo aparece constantemente em nossa vida. Agir
>> >> responsavelmente é um julgamento para o qual não há formula, que se
>> >> altera
>> >> conforme o cliente, o tipo de produto, a nossa experiência etc.
>> >>
>> >> Abraços a todos
>> >> Renato
>> >>
>> >> Em 05/02/2013, às 03:28, Fernando Costa <fcosta@inmov.net> escreveu:
>> >>
>> >> Ernani
>> >>
>> >>
>> >> Ainda discordo que seja purismo e na sua colocação sobre sistemas sem
>> >> bugs.
>> >>
>> >> Não acredito que a entrega incremental deixe espaço para "liberar mesmo
>> >> com vários bugs"; pelo contrário. Como você sabe, a entrega
>> >> incremental é
>> >> para medir o valor agregado do entregável agora e não no fim do projeto
>> >> como
>> >> promove processos cascateados. Isso muda significamente a projeção do
>> >> ROI e
>> >> Payback, além de diminuir os riscos do processo de desenvolvimento.
>> >>
>> >> Também venho acompanhado nestes 8 últimos anos equipes de 6, 600 e 2000
>> >> desenvolvedores diariamente respondendo requisitos de empresas como
>> >> Shell,
>> >> Petrobrás, NET, McDonalds, Banco do Brasil, entre outros... Assim como
>> >> acompanhado desenvolvimento de softwares que faturam mais de 200
>> >> milhões de
>> >> reais ano e discordo categoricamente.. Os bugs não são notados pois os
>> >> cenários (user stories) não são testado como se devem ou porque a
>> >> cobertura
>> >> do código não é suficiente! nem a cobertura de testes unitários nem as
>> >> de
>> >> integração. Isso é fato!
>> >>
>> >> Em estratégias fremium, adotadas por diversas startups, alguns erros
>> >> matariam o produto no primeiro ano. No primeiro ano. (Lembre-se que
>> >> neste
>> >> período somente 1% transforma-se em clientes que pagam)
>> >>
>> >> Para saber se um sistema é viável ou não há inúmeras abordagens já
>> >> estudadas e praticadas por empresas de diversos portes. Sobre as
>> >> funcionalidades adequedas a serem promovidas a release concordo com
>> >> você e
>> >> com a literatura. Há uma outra excelente literatura para isso: "Where
>> >> good
>> >> ideas come from?".
>> >>
>> >> Obrigado pela conversa. Excelente tópico!
>> >>
>> >> []s FC
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Em 5 de fevereiro de 2013 01:36, Ernani Joppert Pontes Martins
>> >> <joppert@gmail.com> escreveu:
>> >>>
>> >>> Fernando, já imaginava que esta parte do texto fosse ser meio polêmica
>> >>> e, não foi à toa, só não quero causar atritos na lista, com um e-mail
>> >>> gigantesco, e sim trazer
>> >>> ao bom senso o que aprendi vendo exemplos por aí e lendo livros e
>> >>> aplicando na prática...
>> >>>
>> >>> Mas, também para não deixar a coisa de uma maneira tão vaga, e, dando
>> >>> margem à interpretações mil, quando quis dizer isto, levei como pré
>> >>> requisito um sistema funcional e que gera lucros...
>> >>>
>> >>> Depois claro que foquei também na quantidade de bugs...
>> >>>
>> >>> Quando saímos da faculdade, queremos por mais que tudo colocar todos
>> >>> os conceitos aprendidos na universidade e nos livros puristas as
>> >>> práticas ensinadas na teoria, mas, a prática é bem diferente...
>> >>>
>> >>> O foco aqui está no sistema funcional, e lucrativo, se o cliente
>> >>> paga,é porque está satisfeito...
>> >>>
>> >>> Se há bugs ou não, o cliente está pagando, e, se está pagando mesmo
>> >>> com bugs, por pior que seja este aspecto, significa que eles não
>> >>> causam detrimento do seu produto em questão...
>> >>>
>> >>> Agora, também abordando a qualidade de software, tenho acompanhado
>> >>> exaustivamente a maturidade da turma, e, sei que em toda sua maioria o
>> >>> pessoal aqui é bem fluente no que faz...tenho visto trabalhos
>> >>> exemplares...
>> >>>
>> >>> Gostaria que alguns até se manifestassem, mas, acho que é um uníssono,
>> >>> quando falamos que não existe sistema sem bugs...
>> >>>
>> >>> Os bugs as vezes existem e nem sequer notamos, a não ser quando o
>> >>> cliente reporta o quando damos a sorte de captá-lo antes de um
>> >>> release.
>> >>>
>> >>> Muitas abordagens, tais como TDD e afins, evitam esta situação, SCRUM
>> >>> também foca em bugs identificados para serem trabalhados no backlog do
>> >>> próximo release.
>> >>>
>> >>> O problema é que num ambiente enxuto, onde temos o desenvolvedor e
>> >>> mais ninguém ou, num caso de sorte, 2 amigos desenvolvedores, na sua
>> >>> garagem de casa (trazendo um pouco da era .com), isto é praticamente
>> >>> uma utopia.
>> >>>
>> >>> Claro que o sistema livre de bugs é o ideal, mas, se você não soltar
>> >>> seu produto o mínimo funcional possível, com várias coisas para
>> >>> colocar em prática, e, consequentemente vários bugs para corrigir ou
>> >>> várias melhorias para implementar, você nunca vai saber realmente se
>> >>> seu produto é viável e quando mencionei este texto, foi de uma maneira
>> >>> sucinta e um tanto quanto chocante (de propósito) de expor este
>> >>> processo prático de pensar em realmente lançar algo funcional,
>> >>> imperfeito mas, aceitável a fim de que seu cliente pague por ele e
>> >>> mantenha seu time ou você à todo vapor motivado a melhorar o sistema
>> >>> até que se torne algo tão viável que possibilite pensar em estratégias
>> >>> ainda mais ricas para a melhoria do produto em si...
>> >>>
>> >>> É o lance do livro lean startup, onde o cara do livro trabalhava numa
>> >>> empresa que fundaram, chamada de IMVU, e, tinha vários bugs o sistema
>> >>> de chat deles, era um chat tipo second life, com personagens em 3d, e,
>> >>> colocaram uma funcionalidade do personagem de teleportar, em vez de
>> >>> animar o personagem de um ponto A a um ponto B, e, depois de uma
>> >>> pesquisa de comportamento dos clientes, a fim de conseguirem mais
>> >>> usuários pagos, descobriram que este trade off era na verdade uma das
>> >>> funcionalidades mais interessantes para os clientes pagos, e, pararam
>> >>> de focar no que achavam legal e economizaram um tempo absurdo que
>> >>> teriam gasto se tivessem segurado o release do produto a fim de
>> >>> implementar esta tal funcionalidade que julgavam ser primordial.
>> >>>
>> >>> []'s
>> >>>
>> >>> Ernani
>> >>>
>> >>> 2013/2/5 Fernando Costa <fcosta@inmov.net>:
>> >>> > Prezado Ernani
>> >>> >
>> >>> > Quase enriquecedor seu email, mas vi que você fudeo quando escreveu
>> >>> > a
>> >>> > pérola "Eu sou partidário de que o melhor sistema ou tecnologia é
>> >>> > aquele que
>> >>> > funciona e dá lucro, independentemente da quantidade de bugs,
>> >>> > problemas
>> >>> > ou
>> >>> > sequer arquitetura, ..".
>> >>> >
>> >>> > Prezado, como uma pessoa com sua experiência me solta essa pérola?
>> >>> > Como
>> >>> > um
>> >>> > sistema pode funcionar independente da quantidade de bugs? Como
>> >>> > podemos
>> >>> > defender um arquitetura middle-out assim?
>> >>> >
>> >>> > Nós como fornecedores de solução podemos manter uma mentalidade
>> >>> > assim?
>> >>> >
>> >>> > Vamos pensar fora da caixa.
>> >>> >
>> >>> > Abs,
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > Em 4 de fevereiro de 2013 19:12, Ernani Joppert Pontes Martins
>> >>> > <joppert@gmail.com> escreveu:
>> >>> >
>> >>> >> Acredito que tanto upgrades verticais quanto horizontais fariam
>> >>> >> diferenças significativas num ambiente apache + php dependendo do
>> >>> >> tipo
>> >>> >> de setup feito no apache.
>> >>> >>
>> >>> >> O apache 2 é multithreaded e, o php, se instalado com a libphp, que
>> >>> >> é
>> >>> >> um módulo do apache, suportaria threading também, o que, se, no
>> >>> >> caso
>> >>> >> de um upgrade de processador com mais cores, beneficiaria o setup.
>> >>> >>
>> >>> >> Memória, tudo depende do tipo de aplicação em questão, como os
>> >>> >> scripts
>> >>> >> em PHP são short lived, ou seja, executam e morrem, raramente
>> >>> >> precisam
>> >>> >> de muita RAM, o que pode ser feito é uma otimização no apache a fim
>> >>> >> de
>> >>> >> limitar ou aumentar a quantidade de threads e requests por thread e
>> >>> >> a
>> >>> >> quantidade de processos filhos que ele sobe inicialmente e qual o
>> >>> >> máximo de quantidade de threads ele aguentaria, o que, sinceramente
>> >>> >> consegue-se uma performance absurda.
>> >>> >>
>> >>> >> Tudo isto poderia beneficiar-se de um upgrade de RAM, dependendo da
>> >>> >> quantidade de memória definida por processo do PHP.
>> >>> >>
>> >>> >> Confesso que após vários projetos em Java. onde para a aplicação
>> >>> >> funcionar, precisava-se de um app server, e, consigo uma série de
>> >>> >> setups, tunning e ajustes de segurança, o Java e a JVM em si comem
>> >>> >> muita RAM, já o PHP é mais flexível nesta parte, e, por isto, o
>> >>> >> custo
>> >>> >> de hospedagem é mais em conta.
>> >>> >>
>> >>> >> Acredito que não exista bom ou ruim, nem melhor ou pior, o que
>> >>> >> define
>> >>> >> muito o ecossistema de uma empresa, e sua infra de TI é a vontade
>> >>> >> de
>> >>> >> adotar-se um padrão de desenvolvimento e por isto optam
>> >>> >> homogenização
>> >>> >> da tecnologia e com isso o Java sai em vantagem por estar presente
>> >>> >> em
>> >>> >> várias plataformas, inclusive embarcados.
>> >>> >>
>> >>> >> O PHP também está, mas, como é mais voltado para a Web, e, não
>> >>> >> tanto
>> >>> >> para comunicações remotas, tais como CORBA, RMI, IIOP e afins, ele
>> >>> >> acaba perdendo interesse das grandes empresas.
>> >>> >>
>> >>> >> Temos muitos casos de uso, mas, falando mais do PHP, o Facebook,
>> >>> >> por
>> >>> >> seguir uma linha mais voltada à Web, e também para webservices, deu
>> >>> >> um
>> >>> >> jeito interessante de inovar o PHP criando o compilador HIP HOP,
>> >>> >> que
>> >>> >> transforma os scripts em C puro, e também está adotando um
>> >>> >> mecanismo
>> >>> >> de JIT (Just in Time Compiler) justamente para poder tirar o máximo
>> >>> >> do
>> >>> >> proveito da velocidade de execução dos scripts.
>> >>> >>
>> >>> >> Bacana divagar sobre isto por horas, mas, o foco da lista é
>> >>> >> Android,
>> >>> >> peço desculpas pelo OT, mas acho legal que os desenvolvedores da
>> >>> >> lista tenham um entendimento mais macro de um ambiente distribuído
>> >>> >> e
>> >>> >> também não mitifique uma tecnologia X ou Y.
>> >>> >>
>> >>> >> Eu sou partidário de que o melhor sistema ou tecnologia é aquele
>> >>> >> que
>> >>> >> funciona e dá lucro, independentemente da quantidade de bugs,
>> >>> >> problemas ou sequer arquitetura, e, muitas vezes algumas linguagens
>> >>> >> da
>> >>> >> qual o desenvolvedor é mais familiarizado dá à ele a possibilidade
>> >>> >> de
>> >>> >> transofrmar a idéia em algo real e concreto, a fim de depois se
>> >>> >> preocupar com problemas dos quais todos nós gostaríamos de
>> >>> >> enfrentar,
>> >>> >> se, é claro, o negócio realmente for algo viável!
>> >>> >>
>> >>> >> Abraço,
>> >>> >>
>> >>> >> Ernani
>> >>> >>
>> >>> >> 2013/2/4 Ricardo Othuki <othuki@gmail.com>:
>> >>> >> > Escalabilidade vertical seria um Upgrade no servidor, como por
>> >>> >> > exemplo,
>> >>> >> > um
>> >>> >> > processador mais rápido, mais memória, maior numero de "cores",
>> >>> >> > etc.
>> >>> >> > Sem entretanto aumentar o numero de servidores. Com Apache + PHP,
>> >>> >> > este
>> >>> >> > tipo
>> >>> >> > de upgrade fara pouca diferença em casos de alta concorrência.
>> >>> >> >
>> >>> >> > Normalmente tenta-se um upgrade vertical (de menor custo) e ao
>> >>> >> > atingir o
>> >>> >> > limite, parti-se a horizontal, incluindo mais servidores para
>> >>> >> > atender a
>> >>> >> > demanda, com mais servidores tem-se a necessidade de um
>> >>> >> > load-balance
>> >>> >> > ou
>> >>> >> > outras soluções que impactam diretamente nos custos.
>> >>> >> >
>> >>> >> > --
>> >>> >> > You received this message because you are subscribed to the
>> >>> >> > Google
>> >>> >> > Groups
>> >>> >> > "Android Brasil - Dev" group.
>> >>> >> > To unsubscribe from this group and stop receiving emails from it,
>> >>> >> > send
>> >>> >> > an
>> >>> >> > email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> >>> >> > For more options, visit https://groups.google.com/groups/opt_out.
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >> --
>> >>> >> You received this message because you are subscribed to the Google
>> >>> >> Groups
>> >>> >> "Android Brasil - Dev" group.
>> >>> >> To unsubscribe from this group and stop receiving emails from it,
>> >>> >> send
>> >>> >> an
>> >>> >> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> >>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > FERNANDO DA COSTA
>> >>> > Inmov - Inteligência em Movimento
>> >>> > fcosta@inmov.net
>> >>> > +55(11)2175-1174
>> >>> > +55(11)9319-8385
>> >>> > FaceBook Page
>> >>> > Siga-nos no twitter: @inmov
>> >>> >
>> >>> > --
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "Android Brasil - Dev" group.
>> >>> > To unsubscribe from this group and stop receiving emails from it,
>> >>> > send
>> >>> > an
>> >>> > email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> >>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >>> >
>> >>> >
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> >>> Groups
>> >>> "Android Brasil - Dev" group.
>> >>> To unsubscribe from this group and stop receiving emails from it, send
>> >>> an
>> >>> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> >>> For more options, visit https://groups.google.com/groups/opt_out.
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> FERNANDO DA COSTA
>> >> Inmov - Inteligência em Movimento
>> >> fcosta@inmov.net
>> >> +55(11)2175-1174
>> >> +55(11)9319-8385
>> >> FaceBook Page
>> >> Siga-nos no twitter: @inmov
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Android Brasil - Dev" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Android Brasil - Dev" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >
>> >
>> >
>> >
>> > --
>> > Renato Lima
>> > @renattolima
>> > +55.31.8829.3777
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Android Brasil - Dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Android Brasil - Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android Brasil - Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to androidbrasil-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.