Concrete Logo
Hamburger button

Os 10 links do mês – Junho

  • Blog
  • 30 de Junho de 2015
Share

Ae! Chegamos ao mês das festas juninas, de São João, de fogueiras, bolos de milho, quentão e vinho quente. E assim como em todos os outros meses do ano, o pessoal aqui na Concrete Solutions teve muito o que comentar no nosso fórum interno. Falamos sobre o NuBank, sobre o Mint e até sobre atenção plena. Também, como não poderia deixar de ser, teve Apple e Google. Confira:

1. Taiga.io

O pessoal começou a testar uma ferramenta simples que tem quase tudo o que precisamos para gerenciar projetos ágeis, segundo o Wesley Silva. Ele ainda ressalta que é gratuita, tem Kanban, gerenciamento de histórias, sprints, backlog e mais um monte de coisa. Thiago Holanda destacou: “our site uses cookies, wich our Oompa Loompas munch on to keep our site running” =P enquanto Gabriel Brettas ressaltou “Low poly art \o/”.

Wesley atualizou a dica dizendo que usou a ferramenta de videoconferência que vem por padrão com o Taiga e funcionou muito bem.

2. Add-on para Firefox

Outra dica do Wesley, que preferi transcrever exatamente como foi dada:

Isso aqui:

​Pessoal, boa tarde

================

Tenho uma dica legal de ferramenta…

————————————————-

…para quem **curte Markdown**

elixir

x = {:ok}

msg = "e para quem gosta de enviar código bem formatado"

IO.puts(msg)

return x

– é fácil

– não muda nada na interface do browser

– não deixa lento

– é compatível com qualquer janela que aceite *rich text*

Baixem [aqui](https://addons.mozilla.org/en-US/firefox/addon/markdown-here/)

![joia](https://icons.iconarchive.com/icons/custom-icon-design/mono-business-2/256/thumbs-up-icon.png)

Vira isso aqui:

Pessoal, boa tarde

Tenho uma dica legal de ferramenta…

…para quem curte Markdown

x = {:ok}
msg = “e para quem gosta de enviar código bem formatado”
IO.puts(msg)
return x

  • é fácil
  • não muda nada na interface do browser
  • não deixa lento
  • é compatível com qualquer janela que aceite rich text

Baixem aqui.

image02

 

 

 

 

 

 

 

Alexis Henaut lembrou que também existe uma extensão para o Chrome e que eles usam highlight.js. O pessoal gostou e aprovou.

3. Linux Mint

Matheus Lima comentou que usa o Ubuntu desde o 9.10 mas queria experimentar um novo, e pediu recomendações sobre o Mint. Lucas Cardinali disse que é excelente para quem não gosta da interface do Ubuntu, e que o Mint é mais leve também. Alexis Henaut usou há algum tempo mas voltou para o Ubuntu porque não viu muitas vantagens. Rafael Toledo ressaltou o fato de o Mint não ser atualizável, mas João Felipe destacou que atualizou de boa até a versão 16. Segundo ele, foi necessário alterar os repos dos pacotes, mas nada de mais. Davi Silva e Patrick Porto, por sua vez, recomendam. Davi ainda cita o Elementary OS para quem gosta da interface do Mac, mas ele prefere o Linux Mint ou Ubuntu. Patrick diz que o Mint é bem mais prático e leve que o Ubuntu, uma edição mais lapidada com menos bugs. Ainda segundo ele, a edição mais comum incentiva a instalação limpa ao invés do problemático upgrade que poucos sistemas tratam de forma aceitável. E para aqueles que preferem este tipo de abordagem eles possuem uma edição feita a partir do Debian que tem um bom suporte para atualizações.

4. Work Rules

Foi Dhiana Deva quem ouviu uma entrevista com o VP de People Operations do Google em um podcast no You Are Not So Smart. A entrevista diz como o Google usa uma abordagem data-driven baseada em psicologia comportamental para a cultura, políticas, contratações tudo o mais. Sobre o assunto, Matheus Lima recomendou o “Thinking Fast and Slow”, e a Dhina recomenda o blog (You Are Not So Smart) antes, para não dar seg fault. Rafael Toledo pediu o link do livro na Amazon, e aqui está ele.

5. Brazil’s Nubank Raises $30M Led By Tiger To Build Out Its Mobile-Based Credit Card Business.

A indicação da matéria do TechCrunch sobre o Nubank no Brasil, feita pelo Rogerio Martins, gerou um monte de pedidos e ofertas de convites para o uso do cartão. No meio delas, algumas experiências: Victor Landeira disse que os convites fazem toda a diferença, porque ele entrou na fila há tempos e só conseguiu depois de receber o convite da namorada. Diego Chavão disse que usa há seis meses e as únicas vantagens são a facilidade (imensa) de conseguir aumento de limite e baixa taxa de juros caso tenha problemas de crédito. Rafael Alves indicou essa matéria do Olhar Digital sobre como a tecnologia está revolucionando o setor bancário brasileiro, enquanto Leandro Moraes lembrou que a NuBank usa AWS.

6. (Super) Power Management – Igor Minar

Alexandre Bairos sugeriu o vídeo sobre a experiência de um dos criadores do AngularJS com a Atenção Plena (Mindfulness) e se colocou à disposição para quem quiser conversar sobre o assunto. Matheus Lima pediu lista de livros sobre o assunto, destacando que só leu o Eckhart Tolle. Agustín Albertengo sugeriu essa palestra do Joe Dispenza e Bairos comentou que existem vários vídeos do Bentinho Massaro com os workshops dele, bem como de Jeff Foster e Mooji e Adyashanti, para os quais o tema é central dentro de seus contextos particulares. Bairos ainda sugere ir na origem do conceito, baseado no discurso original do Sidharta Gautama.

Ainda são dicas do Alexandre Bairos esse texto sobre a relação do Budismo com a Ciência e essa matéria do The Guardian. Dhiana Deva contribuiu com uma tirinha:

image05

 

E Bairos ressaltou um dos comentários: “You can meditate at work. Just don’t close your eyes or it gives the game away. Create a space in the middle of a spreadsheet with one cell shaded black. Focus on that one black cell and regulate your breathing: 4 heartbeats breathe in, hold 7, breathe out over 8. To everybody around you, you will be focusing intensely on the spreadsheet – but you will be spiritually evolving over them. You will, literally, be the office Excel Guru”.

7. Kill The Hamburguer Button

Felipe Garcia sugeriu a matéria afirmando que muitas vezes as funções do hamburguer menu são confundidas com as da tab bar. Sobre o assunto, a Luciana Nasr sugeriu este post da exis web. Theo França destacou o trecho abaixo sobre esse último texto ressaltando que é um ponto importante: nem todos têm o mesmo entendimento a respeito de um ícone e até de um label.

“I can’t measure intent with this test. I’m measuring clicks on a webpage. Maybe the user thought menu as a list of food to order. Maybe they wondered what the hamburger icon was and tapped it. Who knows. AB testing cannot tell you this”.

De acordo com Theo, teve uma outra empresa que testou uma alternativa (não apenas de ícone/label – mas de arquitetura), e também chegou à conclusão de que o hamburger não é a melhor solução. Ele também indicou este post, sobre a posição da Apple e o assunto nas design specs do Google: “The content in the left nav is ideally navigation- or identity-based. The content in the right nav should be secondary to the main content on a page” para chegar à conclusão de que o assunto é polêmico.

Luciana acrescentou que em um projeto para um curso que ela está fazendo ela pensou no hamburguer e alguém a orientou a colocar as informações mais relevantes ou de mais acesso como é no Instagram, na parte inferior do app. Victor Lima lembrou que no iOS é padrão, no Android é relativamente encorajado, e pediu mais opiniões sobre o tema.

Theo resumiu a posição dele assim:

  1. Tente achar uma solução de arquitetura melhor para evitar o hamburger.
  2. Se o hamburger ainda for necessário (normalmente qdo o app tem muitas funções):
  3. Pelo menos tire as principais funções do app de dentro do hamburger;
  4. Evite que o hamburger seja o gavetão onde é possível colocar qualquer coisa, projete-o de forma que sua função seja limitada;
  5. Crie regras claras para navegação nos subníveis (quando o hamburguer dá lugar à seta voltar?)

Para ele, o maior problema do hamburger é que ele não quer dizer nada, ou melhor, quer dizer: “aqui tem um monte de coisa, clique para saber mais”. Para alguns apps, isso não é tão crítico, mas para outros, é.

Gabriel Brettas trouxe para a discussão o uso da Apple para o WWDC, que Theo chamou de “menu pão na chapa”:

image00

 

Corintho Assunção ironizou: “Caraca, a Apple inovou com esses dois risquinhos. #revolucionário #inovador #cool #futuro #apple_love #sqn”. E Tales Pinheiro perguntou por que tanto rant contra a Apple ultimamente, indicando este link com a origem do Hamburguer Button.

Corintho explicou que não é rant contra a Apple, é contra o ciclo que se inicia:

“- O Hambúrguer é a salvação da interface mobile;

– Tudo deveria ser assim;

– A Apple já pensa nisso desde sempre (ou então, foi ela quem pensou em “evoluir” o original);

– Aí veio alguém (a Google) e roubou a ideia dela antes de fazer ser sensacional e a coisa mais linda do mundo;

– A Apple lança o raio gourmetizador, faz a próxima “evolução” do hambúrguer (estilo pão na chapa como foi brilhantemente exposto acima);

– Daqui a 6 meses vai ter um monte de artigos e aplicativos usando o pão na chapa, falando que é a grande experiência mobile do futuro…”

8. Bests comments ever

O tópico do Stackoverflow foi indicação da Alicia Zavalis, e logo o Diego Chavão destacou um comentário:

image04

 

André Cardoso relatou que já pegou um:

// Nao eh problema meu

Exatamente na classe que causou incidente.

Matheus Corregiari mandou esse post para incentivar e Alexandre Bairos lembrou do DevOps Reactions, enquanto André Silva lembrou do The Coding Love. Victor Lima comentou que DevOps Reactions é aquele tipo de “parada” que você não consegue não clicar no “next page”, e destacou a publicação “Testing my own code”:

image01

 

 

 

 

 

Matheus Lima destacou dois comentários:

E Tales Pinheiro contou que não lembra de comentários assim, mas já trabalhou em um projeto em C que tinha comentários e alguns nomes de funções em português, inglês, espanhol e francês. E já pegou algo assim também:

9. REST APIs: logout

“Post, retorno 303 e redirect para a página de post log out. Sugestões?” foi a introdução de Alexandre Bairos para o segundo link mais comentado do mês no nosso fórum interno. Thiago Holanda mandou este link apenas para complementar com uma listagem de HTTPs Status Codes.

Victor Nascimento acha que há uma certa confusão. A pergunta está tentando mapear recursos HTML/CSS/JS com REST ao mesmo tempo que está mapeando as ações. Ou seja, ele acha que “buscar a página de logout” é diferente de “fazer” um logout. Se está tudo no mesmo “domínio.com“, trataria os recursos de páginas como “recursos” mesmo e os colocaria todos debaixo da URI /pages por exemplo. Nesse caso um GET /pages/logout faz sentido e um PUT /pages/logout ATUALIZA a página de logout. Para o “fazer” logout usaria POST /user/logout ou /session/logout ou direto /logout. POST porque é uma ação que não deveria ser idempotente, ou seja, tem efeitos colaterais e, portanto, não é uma ação candidata a ser cacheada (apenas um exemplo do que aconteceria com outros casos). O status 300 pode atrapalhar clientes mobile (se seus frameworks HTTP não tiverem bem configurados e seguirem redirects). Se for um SPA usaria 200 mesmo e avaliaria no cliente o que fazer.

Daniel Carli concorda com o Victor. Segundo ele, como o token é persistido, faria sentido modelar como um recurso da API e fazer as requisições nele. Talvez o logout poderia ser um DELETE. Quanto ao cliente, ele acha que faz sentido o 200 mesmo e a aplicação cliente toma a ação mais adequada. Matheus Lima disse que já teve a dúvida entre POST x DELETE e ele preferiu o DELETE porque no caso o parâmetro passado é o X-SESSION-ID no header apenas, e ele é apagado, ou seja, deletado logo após o request.

Na opinião do Mário Chaves o básico seria verificar se o usuário está autenticado, com um método genérico pra isso; fazer um POST excluindo o token associado ao usuário logado e retornar um objeto response 200.

Alexis Henaut opinou que “login” e “register” não são “recursos” REST. Ele explica que um serviço RESTful deve ser stateless, então as sessões registradas no servidor não são RESTful. Para ele, os princípios RESTful devem ser respeitados tanto quanto possível, mas só se fizer sentido para a aplicação. Neste caso, para ele é comum o uso de requests GET para URLs que não representam recursos REST. Alexis ainda recomenda essa resposta do próprio Stackoverflow, além desta, que considera uma sessão como um recurso.

Para Victor Nascimento, embora elas não sejam recursos, um token stateless deveria ser um recurso para que as opções propostas aqui emitam um POST /token e criem um token que expira e ainda assim seja RESTful. Assim como um logout com DELETE /token/{id} faria. Victor acrescenta que as restrições citadas sobre REST não são uma religião (como bem colocado nesta resposta). Salvar um token no banco de dados do servidor não é unRESTful (se fosse, então salvar um usuário no banco de dados também seria unRESTful, assim como todos os seus outros modelos). Seria unRESTful salvar dados para uma sessão HTTP tornar as rotas de navegação dependentes. Pelas restrições dadas no texto do Roy, o cliente não deveria  manter o estado. A abordagem do token estaria, portanto, seguindo seus princípios.

Ainda de acordo com Nascimento, existem muitas pessoas que pensam que ter tokens persistentes não é RESTful. “Até se nós concordamos em discordar, eu acredito que olhando pela perspectiva de segurança ainda é necessário que nós salvemos os tokens. Nós devemos saber quantas sessões são válidas, quando elas foram criadas e etc. E nós não estamos nem falando sobre CSRF tokens… esses deixariam nosso debate ainda mais complicado”.

Victor ainda ressalta que essa é uma longa discussão sobre até que ponto nós deveríamos seguir todos esses princípios: “Se nós formos tão radicais, até logs no servidor seriam considerados ‘side effects’, e isso não é de todo errado. Talvez nós chegaríamos a um ataque de custos que faria o servidor cuspir montes de logs, transformando em um problema de custo. Quem sabe…” Para terminar, Victor diz que em um token baseado em um sistema de autenticação e autorização ele recomenda salvar todos os tokens criados em um “fast read slow write key-value datastore”. Isso provavelmente não seria um gargalo para uma arquitetura infinita e escalável, assim como datastores são distribuídas por natureza (Riak, Redis, etc).

Por sua vez, Alexis comenta que a opinião de Victor é similar à segunda resposta que ele gostou. Para ele, utilizando POST ou DELETE como request em um recurso de “token” ou “session”, voltamos à filosofia RESTful. Alexis diz que concorda totalmente com o ponto da religião. Para ele, alguns conceitos da sua aplicação às vezes não estão de acordo com os requerimentos para ser RESTful, e você deve apenas aceitar que sua aplicação não é necessariamente 100% RESTful.

Alexis ainda afirma que observando o conteúdo do Stackoverflow, talvez a segunda frase dele tenha sido muito “definitiva”. Mas o uso de verbos como “login” e “logout” e a mistura de formas HTML e performing actions faz com que o 100% RESTful seja irrelevante. Para ele, a primeira mensagem era sobre isso. Um site não é uma API e REST é só um estilo de arquitetura que pode ser implementada além do HTTP.

10. Here’s Proof of Apple’s Downward Fall From Innovator to Imitator

E finalmente, o link mais comentado em todo o mês de junho foi uma provocação do André Cardoso que sempre dá pano pra manga aqui na Concrete. Apple! Alexis Henaut usou o vídeo “Has Apple Really Ever Invented Anything?” para iniciar o debate e Corintho Assunção disse que defender que a Apple inova ao copiar é defender que a China otimiza ao copiar (e produzir mais barato).

Erick Santos citou Lavoisier: “Nada se cria, tudo se transforma” e para Thiago Lioy “#hatersGonnaHate e enquanto isso os stats sobem…”. Corintho concorda e acrescenta: “Stats da Apple sobem, e a China vende mais. O problema da China vender mais é que eles poluem mais, já que usam carvão como combustível. Qual o problema dos stats da Apple subirem? Nenhum? Ou algo que a gente ainda não entendeu? (Não que eu ache a Google uma santa, diga-se de passagem…)”, indicando este link.

Para Rafael Alves, em tudo na vida raramente se inventa algo. Ele acredita que toda “invenção” se baseia em padrões anteriores, até artistas não criam tendências do nada. Para ele, a Apple tem apenas se adequado aos padrões da concorrência, uma influência que não se pode ignorar, dando um toque de “originalidade”, como um design diferenciado, uma propaganda mais bonita, o preço mais caro, etc.

Corintho acha que só está errado o toque de “originalidade”. Ele cita o Apple Music como exemplo e questiona o que ele tem de original ou diferente de Spotify ou tantos outros, além do fato de ser feito pela Apple.

Rafael explica que foi por isso que ele usou o termo entre aspas. Justamente porque a Apple não é muito boa em fazer algo comum parecer que é algo diferente. Já influencia a nível do subconsciente.

Rafael Toledo, por sua vez, tem a impressão de que a Apple adotou a posição de não correr muitos riscos. Para ele, nos últimos anos o que temos visto foi só o acompanhamento da tendência. Até 2013 eles ainda utilizavam o visual “glass” no iOS, e depois que todo mundo foi para o flat eles aplicaram no iOS (e só ano passado no OSX). Eles esperaram o Google Wallet ficar alguns anos no mercado, ver o que fizeram de certo e errado, perceber que é uma boa ideia, e lançaram o Apple Pay. Esperaram Spotify, Deezer, Rdio e todo o resto se esbofetarem e fazerem o mercado crescer pra depois lançar o produto deles. Esperaram as telas de celular aumentarem, ver que todo mundo queria celulares maiores, e aumentaram o iPhone. Android Wear chegou, aqueceu o mercado, eles vieram com o Apple Watch. E já que eles têm os seguidores da “religião” que a Apple é, eles não têm muitos motivos pra mudar essa postura. Espera o mercado emergir alguma coisa, fazem o deles e vendem igual água.

image03

 

Rafael Alves concordou com o xará e destacou outros fatores:

– Inovar é perigoso, por causa da facilidade de ser copiado facilmente. A Apple já teve e tem várias ações contra a Samnsung por quebra de patentes… E mesmo que resulte em punição, a Samsung já lucrou bilhões copiando e tirando um pouco da exclusividade que a Apple procura proporcionar;

– Infelizmente, inovar requer ousadia, tempo para prototipar e desenvolver a ideia, e, principalmente SIGILO. A facilidade de ter acesso a rumores – verdadeiros – é alta. E não adianta focar em um projeto inovador buscando exclusividade no futuro se você fica sabendo que seus concorrentes tomarão conhecimento e irão trabalhar na mesma ideia. Exemplo: Apple Watch. Há anos a Apple vem preparando, porém os rumores se tornaram fortes demais e os concorrentes lançaram rapidamente os relógios inteligentes deles, sem todo aquele glamour que a Apple traria… Em parte isso quebrou um pouco do “barato” do Apple Watch e a Apple passou a ser aquela que copiou.

Resumindo: inovar causando impacto como antigamente (nos tempos do lançamento do iPhone), requer muitas condições que atualmente não são possíveis. Principalmente por causa do acesso a informações sigilosas, que se tornam rumores.

Corintho Assunção concorda mais uma vez em quase tudo: que a Apple parou de inovar e passou a utilizar o “raio gourmetizador” para fazer o cachorro quente de R$40. Ele só não concorda com a colocação de Rafael Alves sobre o Apple Watch. Nas palavras dele: “Imaginar que a Apple passou anos e anos e anos bolando e aperfeiçoando o Aple Watch para depois os outros ‘lançarem na frente’ e o dela parecer cópia. Isso me parece o papo de fanboy (sem hashtag, pois não tem a conotação negativa normalmente associada às zoações que fazemos). O primeiro ‘smartwatch’ se não me engano foi lá pra 1998-2001, com Linux e Samsung. Smartwatch considerando algo relativamente tecnológico. A não ser que eles tenham copiado a ideia da Apple, esse discurso não cola. Já tem muita gente, há muito tempo olhando essa mesma ideia…”

Para Corintho, se eles já foram os precursores, hoje estão correndo atrás. Dizem que correr atrás é mais lucrativo e, no entanto, não se cansam de dizer que a Apple ganha rios de dinheiro. Se ela ganha rios de dinheiro, e chegou lá inovando, por que não continuar? Por que agora reverter para o que “os outros” fazem?

Para Thiago Lioy, o pessoal fica tão preocupado com a questão de copiar que perde o foco. Para ele, se copiar fosse proibido nós viveríamos monopólio em todas as indústrias. Só teríamos Ford, Harley Davidson, Macintosh, etc. Ele recorda que a Apple disruptou a indústria criando o iPhone e o iPad e tal movimento motivou o surgimento de inúmeros concorrentes, como o Android. Ainda de acordo com ele, nada mais justo eles se basearem em coisas que agora deram certo em outras plataformas. Não é crime e é proveitoso, só beneficia a competição e o usuário final.

Rafael Alves voltou para o comentário do Corintho dizendo que mesmo que houvesse smartwach em 1998-2001, naquele tempo as coisas não eram pensadas para o público em geral, mas, talvez, para executivos, como já acontecia com o “Palm Top”, por exemplo. Além disso, naquela época, a concepção de um sistema operacional móvel robusto e conectado sem fio ainda estava germinando, e foi depois da explosão do mundo mobile que a pergunta ficou no ar: “quem vai fazer o próximo dispositivo com um nível de conectividade e de popularidade tão bom quanto a de um smartphone?” Apostaram no relógio. Provavelmente o próximo passo seria apostar no carro (Android Auto X Apple Car). Rafael deixa a pergunta: “E aí, quem vai inovar primeiro para os carros inteligentes? Ou, generalizando: a internet das coisas?”

Rafael ainda diz que até hoje Steve Jobs (mesmo dentro do caixão) guarda ressentimentos de quem copiou o design do iPhone e do iOS. Em parte, as pessoas ou empresas inovam pensando na exclusividade, daí vem as patentes. A Samsung não ligou para isso, copiou, lucrou e agora responde na justiça. Para Rafael, admirável e rara foi a atitude da TEsla Motors ao abrir mão da patente sobre motores elétricos para benefício da comunidade e aperfeiçoamento do sistema.

Para finalizar, Corintho diz que para ele tanto faz quem vai fazer o primeiro ou o melhor. O que ele acha perda de foco é dizer “a Apple fez primeiro” ou “a Google fez primeiro e a Apple aprimorou”. Ele acha que sempre vai ter o pessoal que vai olhar no final das contas e ver que quem ganha, em teoria, é o usuário final (veja referências do New York Times e do New Yorker) e sempre vai ter a galera que bate o pé e diz que essa ou aquela empresa é a melhor. Para ele,o segundo grupo sempre vai estar errado, pois essa ou aquela empresa está sempre pensando no dinheiro que elas vão ganhar e fazem patentes apenas para defender esse interesse no longo prazo.

Ufa! Pessoal inspirado e discussões polêmicas esse mês, não? Tem alguma opinião a acrescentar ou acha que faltou algum link? Deixe abaixo sua contribuição! Até o mês que vem.