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

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.