Concrete Logo
Hamburger button

Os 10 links do mês – Fevereiro

  • Blog
  • 27 de Fevereiro de 2017
Share

E aqui estamos nós no mês dos confetes e serpentinas. Você já sabe que uma das coisas que a gente mais gosta de fazer (além de produtos digitais incríveis) é compartilhar conhecimento. Certo? Então, nós temos um fórum interno de e-mail que não para de aparecer novidades, o tempo todo. Ajuda bastante a ficar bem informado! Então, para que essas informações não fiquem só com a gente, reuni os 10 links mais comentados este mês em um ranking. Quer ver?

10. JavaScript Start-up Performance

O post do Addy Osmani (também conhecido como Addy Osmito por alguns) foi dica do Filipe Mondaini. Nele, o autor basicamente ensina como otimizar a etapa Parse/Compile de projetos em JavaScript. Vale a leitura! O post ainda cita esta talk sobre o mesmo assunto como referência, o Matheus Lima destacou e indica também.

9. Como criar um componente reusável com RxSwift, View Code e Realm

Está ficando cada vez mais comum um jabá no ranking dos dez links, né? Pois é, eu juro que nossos critérios são apenas numéricos, só os mais comentados entram! E o nono lugar nesse mês foi uma talk da galera de capítulo de iOS aqui da Concrete. Nela, o Thiago Lioy explicou como criar um componente reusável com RxSwift, View Code e Realm, a galera curtiu bastante! Dá uma olhada.

8. Meet.jit.si

A dica é do Roberto Brasileiro, uma alternativa ao Hangouts e janelas virtuais. Com ele, segundo Roberto, você cria um link permanente e não precisa de usuário e senha. É só entrar no link e já está na conferência. Ele já usou muito e nunca teve problemas. O Rodrigo Batini lembrou do Appear.in, que ele usou há algum tempo, e o Frederico Moreira aprova. Victor Nascimento até já desinstalou o Hangouts.

7. I’ll never bring my phone on an international flight again. Neither should you.

Foi o Tales Pinheiro quem mandou o post Quincy Larson, que fala sobre a exigência de informações (como até sua senha) em aeroportos. O Tales comentou que, para ele, não vale a pena levar o computador nem formatado, porque vai que eles pedem para cadastrar as contas nos apps? A Andressa Chiara disse que eles podem trazer um computador deles e dizer “loga aí”. O Tales destacou dois pontos do texto:

“You can’t hand over a device that you don’t have”.

“They may choose to detain you anyway, and force you to give them passwords to various accounts manually. But there’s no easy way for them to know which services you use and which services you don’t use, or whether you have multiple accounts”.

O Tales comentou: “Eles não vão ter acesso a praticamente TODAS as senhas em plain text, histórico de navegação, conteúdo de todas as redes sociais, dados de GPS, fotos, e-mails, etc, extraídas pelas ferramentas que só precisam que você destrave seu device com biometria ou senha. “Só” terão nos serviços que pedirem pra vc autenticar”. E acrescentou que já ouviu relatos de viagem parecidos no Canadá e na Inglaterra.

Pra terminar, Leonardo Pabon destacou:

“The border is technically outside of US jurisdiction, in a sort of legal no-man’s-land. You have very few rights there.” Tenso.

6. How great leaders inspire action

O TED com o Simon Sinek foi dica da Samanta Cicília. A maioria dos comentários mostra que todo mundo acha o cara muito bom. =) Assistindo à talk, o Otto Gori lembrou de uma leitura antiga sobre a ideia de um “approach” com o cliente em que você demonstra o quanto uma metodologia/framework/tecnologia pode aumentar o valor da empresa. Veja aqui.

5. Sprint Initializr

Boas opiniões sobre a ferramenta! Quem pediu dicas sobre ela foi o Gustavo Oliveira, que nunca tinha usado. O Anderson Silva foi o primeiro a comentar, ressaltando que o IntelliJ 2016.X (IDE) tem a opção de inicializar um projeto spring com start.spring. O Alexandre Jacques disse que não é nenhuma bala de prata, mas agiliza a digitação do pom.xml, e ressaltou de novo a integração com o IntelliJ.

1

O Bruno Rocha opinou que é uma mão na roda para criar projetos do spring, inclusive dá para utilizar no terminal com o CURL. No site tem as sintaxes para criar o projeto com as dependências por linha de comando:

image

O Josué Freitas disse que com o STS você também consegue, se criar um Sprint Starter Project; e pra finalizar o Juliano Sato pegou carona no uso via terminal e deixou um exemplo:

$ curl start.spring.io/starter.zip -o demo.zip –data @options

(aqui “options” é um arquivo chamado “options” que contém:

dependencies=web,actuator&

applicationName=BrunoRocha&

artifactId=bruno-rocha&

description=bruno-rocha&

groupId=bruno.rocha&

packageName=bruno.rocha.javeiro

O @ ali é para indicar que vamos passar um arquivo pelo curl.

4. Em 2020 não haverá mais aplicativos

Tava demorando para aparecer a polêmica por aqui, né? Pois é, o Wesley Silva foi quem começou a discussão mostrando que os analistas do Gartner acreditam que assistentes pessoais munidos de machine learning vão substituir os apps em breve. Ele acredita que não vai ser em apenas três anos, mas faz sentido pensar em uma arquitetura com uma interface feita por uma agente inteligente plugado em back-ends de serviço.

O Victor Nascimento se perguntou se essa previsão se compara à do fim do teclado e mouse. Ele acha que haverá uma força de Google, Samsung, Amazon e cia para esse lado, principalmente porque a guerra para ver quem tem mais informação continua. Para ele, o modelo de app store é bem sucedido, mas como essas empresas precisam obrigatoriamente crescer todos os anos, não ele não sabe se continuarão investindo até 2020.

Victor ainda lembra que historicamente temos mais a tendência de absorver novas formas de interação do que de substituir. Exemplo disso é CD e vinil, que existem até hoje (inclusive fala-se da volta do vinil). Ele não acredita que será o fim dos apps, mas talvez o fim de sua hegemonia.  O Rafael Bielawski acha que as app stores vão estagnar, mas não tão rápido. E o Leandro Neumann também acha que é inevítável, mas em um prazo mais longo. Ele também deixou o link desta iniciativa, que ele conheceu neste sentido.

O Rodrigo Bio terminou o debate destacando o seguinte trecho:

“Os assistentes virtuais irão criar novos assistentes e robôs irão criar novos robôs. Por isso, Sondergaard considera crucial criar algoritmos da forma certa.”

A pergunta dele é: quem garante que essas máquinas vão decidir que a melhor solução é fazer “o que nós fizemos”?

E falando do fim dos apps em si, Bio ressalta que os assistentes são mais direcionados a serviços como os apps de banco, agenda, mapa, etc. Neste caso, como fica o entretenimento? A impressão dele é que essa é uma frente que vai se adaptando às novas formas de interação que forem surgindo (assim como a indústria de jogos para celular se adaptou do teclado para o touch e assim por diante). Nessa linha, a próxima adaptação de toda essa área de “serviços” talvez seja essa mesmo dos assistentes.

3. (More than) one million requests per second in Node.js

Mas aí, quando começa, a polêmica não para. Agustín Albertengo mandou logo uma sequência de links. Esse aí do título, que fala dos requests por segundo no Node.js e esse aqui, com a importância do Scope Control de JavaScript. Ele acrescentou ainda que já foi implementado no engine.io (Socket.io).

O Caio Rosa não sabe se é implicância dele, mas acha esse tipo de benchmark uma “bullshit completa”. Ele não acha possível que alguém tenha coragem de retirar todo tratamento de dados em um ambiente produtivo. Para testar e demonstrar que existe uma capacidade maior, que a implementação atual está ruim ou é um bloatzão ele acha OK, mas é pilantragem porque não fica na cara que não é viável no mundo real

Ele acrescenta ainda que existem várias limitações no teste em si, aceitar conexão http e responder um OK é muito inútil, por exemplo. E deixa o trecho abaixo:

“Since every single http server built with Node.js makes use of the Node.js core http module indirectly or directly (via ExpressJS or not), it makes sense to try and make a replacement module that has a similar enough interface to allow seamless transition from slow to fast and from bloated to lightweight in terms of memory usage per connection.”

O Victor Neves concorda, diz que os cenários devem ser mais reais, e acrescenta que já existem alguns cenários legais na comunidade .NET, como ASP.NET Core – Exceeds 1.15 Million request/s, 12.6 Gbps e este comparativo, que mostrou .NET CORE 300% mais rápido que NodeJs. Para Victor, não só comprovam qual é mais performático, mas lembram que temos uma ótima opção competitiva disponível além do Node, que é a plataforma NET CORE.

image (1)

O Caio Rosa voltou para dizer que o segundo teste do ppt já interessa mais, mas ainda assim é limitado: “retorna uma lista no formato json a partir de um arquivo de texto em disco”. Ainda assim ele é a favor de testes com limitação a 10% de CPU e depois extrapolar o resultado. Segundo caio, Node.js a 100% de CPU com I/O vira um idoso atravessando a rua, é muita concorrência.

Caio ainda indica a leitura do artigo sobre benchmarks do Eran Hammer:

“What makes things worse when doing this sort of benchmarking is that the load is almost exclusively blocking because there is no business logic to go and create that downtime. Most of the internal framework facilities, such as parsing headers, cookies, and payload processing are blocking activities that require better downtime management than an application with empty business logic provides.”

O Marcos Bérgamo disse que esse tipo de benchmark é muito tendencioso e visa apenas provar que uma linguagem é mais rápida que a outra, não levando em conta cenários do mundo real, no qual diversas integrações são usadas, como banco de dados, serviços de terceiro e etc. O primeiro a indicar a polêmica, Agustín Albertengo, também a fechou dizendo que concorda que o benchmark não contempla a lógica por trás da request, mas a lib foca em otimizar a performance no tratamento de requests http. Se a comparação fosse entre frameworks tipo Express vs Koa, realmente ele acha que precisaria de um benchmark de mais alto nível, mas para demonstrar uma melhora na performance da lib que vai processar a request ele acha este satisfatório. O fato do Socket.io(opcional)  e o Deepstream incluírem como dependência, para ele, diz que a lib deve fazer alguma diferença.

E você, o que acha? Deixe sua opinião nos comentários =)

2. Replacing The User Story With The Job Story

Mais uma polêmica para a coleção de Fevereiro!  Dessa vez foi o André Coelho que jogou na roda o post do Alan Klement e só deixou lá, nem deu opinião sobre. O Rodrigo Batini ficou em dúvida se simplesmente trocaria um pelo outro, talvez possamos escrever épicos como  User Stories para criar empatia e dar norte para o time e quando for algo mais concreto utilizar o Job Story. Para ele, Job Story lembrou um Test Case mais genérico, e não necessariamente dá senso de necessidade.

“In the context of signal-noise and data analysis, building personas would be adding noise to your data”

Batini ainda acrescenta que persona é importante para criar empatia, mas ela precisa ser concebida e melhorada de forma iterativa também. É muito comum definir personas no começo do processo e não revisitar nem aprender nada com elas. Aí o ruído tende a levar o produto para um lugar não tão ideal.

A Andressa Chiara não gostou. Ela acha que vai na contramão de tudo que o uso da user story traz de benefício, e ela não se prende 100% no modelo de user story quando está criando os itens de backlog, mas está sempre se esforçando para criar user story para os itens de visibilidade funcional. Isso porque em última análise ela permite (caso ela tenha escrito direito) identificar a necessidade do usuário que precisamos atender. Sem a user story, o time frequentemente se prende a atender uma lista de requisitos, e não à necessidade do usuário. Isso na experiência da Andressa, claro.

Apesar da dificuldade em escrever user stories nos modelos “tradicionais”, a Adriana Ramos disse que também busca deixar evidente qual a necessidade que está tentando atender ao finalizar cada tarefa que compõe a story. Ela teve problemas semelhantes em seguir algo mais focado na solução e isso virar uma dependência do time: quando não dizia o resultado esperado e mais a forma de atingi-lo, poucas ou nenhuma solução eram apresentadas. Por fim, recaía em um modelo perigoso que consistia em dizer “consigam X resultado com a forma/solução Y”, o que tirava completamente a consciência do por quê o time estava trabalhando naquela story.

Ela não acha o modelo ruim, mas acredita que o formato tradicional atende mais facilmente um time trabalhando com framework Ágil. Talvez seja uma opção para times mais seniors com mindset Ágil.

Pra terminar, Leonardo Pabon citou Jeff Patton em um curso que ele fez recentemente. Ele acha que o formato supostamente padrão é só uma sugestão, não uma obrigação. Você pode usar qualquer formato que funcione para o seu cenário. Quando o Kent Beck propôs User Stories em vez de requisitos funcionais elaborados, a ideia não era criar um novo tipo de documento. User Story serve para facilitar uma conversa entre o PO e o time de desenvolvimento, e é essa conversa (na qual pode-se tirar todas as dúvidas e alinhar o significado) que é o genial da coisa. Durante o desenvolvimento o time olha a Story, se lembra da conversa e tem mais chance de acertar frequentemente. Para Pabon, o formato padrão é algo que melhora a chance da conversa entre PO e time de desenvolvimento ser produtiva.

1. As cinco maiores tendências de pagamentos para 2017, segundo a Adyen

Você que acompanha o Blog já deve ter percebido que pagamentos e serviços financeiros são assuntos recorrentes por aqui. Isso porque temos bastante clientes nessas áreas, e como nos importamos muito com o que criamos, estamos sempre de olho nas novidades. O primeiro lugar de fevereiro nos mostra isso! Foi a Tamires Viana quem mandou o link e pra facilitar até já destacou quais são as tendências:

– Carteiras digitais;
– Uso de dados contra fraude;
– Assinaturas / Recorrência;
– Foco no consumidor;
– Consolidação de dados.

O Juliano Sato, um dos nossos homens da segurança, destacou o seguinte trecho:

“Por isso, é importante manter sistemas robustos antifraude integrados à plataforma de pagamentos, a fim de unificar dados para combater os fraudadores da melhor forma, com inteligência analítica e menor intervenção manual.”

unnamed

Ele disse que Santander e Itaú, por exemplo, ainda estão tateando nessa direção, não faz nem um ano, e deu como referências este e este link. Ele ainda acrescenta que a justificativa é bem essa: “sistemas robustos antifraude integrados à plataforma de pagamentos”.

Em resposta, a Tamires acha que blockchain merece e precisa ser tratado como um tema bem maior, que extrapola o âmbito de pagamentos. Ela tem lido bastante sobre a substituição dos cartórios no modelo atual por blockchain, pelo uso nas eleições e uma infinidade de utilizações que a mente humana conseguiu bolar. Olha só este link.

E é isso! Gostou das dicas deste mês? Se você tem alguma dúvida ou quer deixar alguma opinião, aproveite os campos abaixo. Em março a gente volta. Até lá!

Se você também gosta de compartilhar conhecimento e quer fazer parte do nosso time, acesse aqui. Mas se você precisa de ajuda para sua estratégia e quer saber mais sobre nossos times e produtos, entre em contato.