Página: 4 – Tribo do C.I.

Contribuindo com a Mozilla

Mozilla 2013 Summit — Mozilla Summit – Foto por Marcia Knous, disponível no blog da Mozilla

Quando eu descobri que eu era capaz de contribuir com os projetos da Mozilla isso me fez sentir muito feliz e útil. Não consigo me lembrar dos detalhes, mas eu estava aprendendo sobre HTML5 e Web Mobile usando o MDN como meu recurso principal e percebi que algumas páginas estavam em português e outras não. Descobri então que qualquer um poderia traduzir as páginas, então comecei a traduzir também, pois queria melhorar meu inglês e também fazer estes conteúdos disponíveis às pessoas que não sabem inglês.

Isso foi em 2014, eu aprendi algumas coisas sobre a Web e também melhorei um pouco o meu Inglês traduzindo artigos no MDN. Logo consegui desenvolver WebApps e publicá-los no Marketplace do Firefox, na Chrome Web Store e também aprendi a usar o PhoneGap para tornar os meus aplicativos da web instaláveis em dispositivos Android. Eu ganhei um monte de novas habilidades apenas me envolvendo mais na tradução desses artigos no MDN e assim estudando mais, e eu tenho certeza que muitas pessoas foram capazes de aprender mais a partir de então, com esses artigos também disponíveis em português. Uma mão lava a outra.

Como eu estou acostumado a dar palestras, eu preparei algum conteúdo sobre essas coisas novas que eu aprendi, e ministrei palestras e mini cursos em alguns eventos em minha cidade e outras cidades próximas. No final de todas essas palestras, eu mencionava o MDN e tudo o que aconteceu comigo, encorajando os participantes a contribuir com os artigos também. Mais tarde eu descobri que a comunidade Mozilla era grande aqui no Brasil, e eles fazem muitas atividades. Na verdade, eu aprendi que a Mozilla tem listas de atividades e como executá-las, tornando a vida do contribuinte muito mais fácil.

Sheldon Led no Software Freedom Day BSB 2016 palestrando sobre os principais projetos da Mozilla

No começo eu estava muito ocupado, terminando minha graduação, mudando de posição no trabalho, e esses tipos de coisas que nos amarram à nossa rotina, então eu não envolvi com a comunidade. Mas as coisas mudaram um pouco em 2016, quando encontrei alguns amigos da Mozilla Brasil morando perto de mim, e dispostos a unir forças para realizar as atividades da Mozilla aqui no Centro Oeste do Brasil (Goiás e Brasília). Foi algo incrível, eles me motivaram. Logo nós nos reunimos para fazer um plano de ação e começar a incentivar mais pessoas a contribuir com a Mozilla.

Westerley e Sheldon, no Software Freedom Day BSB 2016

Em setembro de 2016, palestrei em três cidades diferentes (Brasília, Ceres e Uruaçu) falando sobre os projetos da Mozilla em geral, e em uma ou duas dessas conferências falei também sobre a Mozilla e a IoT, tambem conhecido como Connected Devices. As pessoas ficaram maravilhadas porque pensavam que a Mozilla era uma coisa distante, mas agora viram que estamos em toda parte, e também aqui, ao lado deles. Eu não sei se algum dos ouvintes já começou a contribuir com a Mozilla, mas eu sei que eu plantei alguma chama em seus corações.

Eu estou disponibilizando todos os slides das minhas palestras na minha conta do github, então você pode apenas verificar o meu repositório Talks e ver o que que tem de bom por lá. Mas quero destacar os slides usados nas palestras de setembro:

Sheldon Led na Semana de Inovação Uruaçu

Agora estamos planejando uma grande atividade no Fórum Goiano de Software Livre – FGSL. Estaremos falando sobre Realidade Virtual, Compatibilidade com a Web, Privacidade e Segurança, e também sobre como contribuir com o Mozilla. Eu ficaria mais do que feliz se você desse uma olhada na nossa agenda na conferência. Tudo será informado em http://fgsl.net.

Isso é só um começo. Eu sei que estaremos fazendo grandes coisas de agora em diante, e eu quero que você participe também. Veja meu exemplo, você só tem a ganhar, e além disso, também estará ajudando os outros a serem beneficiados também.

Dica rápida: campo de senha

É muito legal e causa muita confusão aos leigos (bem leigos) preencher o campo de senha em um formulário. Eu já fui professor de idosos e eles sempre ficavam intrigados por digitarem e, na verdade, só aparecer bolinhas na tela. Com a popularização dos smartphones essa prática deve ser repensada.

Não significa que o campo de senha tem que ser abolido, pois ele impede que quem quer que esteja ao seu lado saiba sua senha. No smartphone o campo de senha não é prático por dois motivos básicos:

O usuário quase sempre erra o que digita no celular, e não tem como ele checar sua senha.
Não é tão seguro assim para o curioso ao seu lado, pois ao pressionar o teclado, a letra aparece na tela por uma fração de segundo antes de virar uma bolinha.

A solução mais simples e mais usada para isso é deixar o campo de senha como está, e incluir uma opção de mostrar a senha. Assim o usuário pode digitar a senha mais à vontade e depois dar uma conferida se digitou corretamente. Essa prática se tornou tão comum que a microsoft a adotou como padrão em todo campo de senha do Windows 8.

Em 2016 eu iniciei uma idéia maluca de criar o projeto #366DailyCode, que consiste em publicar 1 pedaço de código JavaScript por dia (geralmente um problema ou algoritmo conhecido). Isso é assunto para outro post, o fato é que eu tornei essa opção de mostrar a senha o código do dia 14/01/2016. Você pode checá-la em prática abaixo:

See the Pen #366DailyCode #Day14?—?Input type password by Sheldon Led (@sheldonled) on CodePen.

FULLSTACK API – Ou o que aprendi com o MEAN.

Muito se ouve falar de API’s, e termos como API First, ou Offline API. É um conceito muito bacana, do qual não vou entrar em detalhes aqui pois basta você pesquisar um pouco e achará centenas de artigos falando sobre isso, em Português, em Inglês, ou qualquer outra língua. Não só porque tem muito material já disponível, mas porque esse material disponível já descreve muito bem sobre isso, então eu só quero detalhar um pouco do que eu aprendi, sabendo que talvez não acrescentará em nada, mas pode ajudar quem esteja começando, assim como eu.

Eu sou uma pessoa que estuda pouco, porém sobre muitas coisas, e só entro em mais detalhes quando preciso. Então muita gente me acha inteligente, mas sou apenas curioso, e foi assim que, há um tempo atrás eu precisei/quis aprender NodeJS e AngularJS. Foi quando eu descobri a STACK (conjunto de tecnologias para se desenvolver determinada solução) MEAN (MongoDB, ExpressJS, AngularJS e NodeJS).

Esse termo (MEAN) é muito conhecido, basta você “googlar” e verás. Mas o que está por trás dessa ideia, eu (e creio que todo mundo que estudou o MEAN) descobri rapidinho: trabalhar com API. Mas que diabos é trabalhar com API? Também não vou entrar em detalhes, mas basicamente, nesse contexto que estamos inseridos, ao trabalhar com API, você cria um conjunto de rotinas/funções/métodos padrão, e isso vai ser o núcleo (core) do seu sistema. A partir de então, você desenvolve um elo entre o usuário e o core do seu sistema, esse elo é chamado de Cliente. Se sua API está online (de novo, no contexto desse artigo, presumiremos que sim), então você pode fazer vários tipos de clientes para acessá-la, como, cliente web, para Android, iOS, para Windows, Linux etc.

Esse negócio de se trabalhar com API começou com grandes softwares. Eu vi, pela primeira vez, em redes sociais, como Twitter e Facebook. Isso foi testado e aprovado por programadores, que foram passando essa experiência ao longo dos anos e hoje em dia é uma tendência altíssima trabalhar dessa forma. Sendo assim, vamos somente recapitular, alguns benefícios de se construir o seu software no formato API:

Multiplataforma: também pode ser entendido como generalismo. É muito mais fácil criar uma versão de seu software para uma outra plataforma, pois o core do seu software já está pronto, de forma genérica, basta criar o cliente na plataforma desejada, para conversar com ele.
Consistência: Existe um padrão, único, no seu software, e todos os objetos e a arquitetura do seu software já estão bem definidos.
Modularidade: É muito mais fácil dividir seu software em módulos, ou em níveis de acesso, e distribuir essa divisão entre os clientes, pois você praticamente alterará somente um lugar

Voltando ao MEAN, você acha facilmente artigos para aprender essas tecnologias, eu particularmente gosto desse artigo da Caelum. Mas se você parar para pensar, o que é o MEAN?

Um banco de dados (MongoDB)
Uma biblioteca para obtenção, tratamento, roteamento etc, das requisições dos clientes (ExpressJS)
Uma biblioteca para se construir seu cliente, nesse caso, web (AngularJS)
Um servidor web (NodeJS)

Então porque o MEAN ficou tão famoso? Pelo fato de que, ao se trabalhar com qualquer uma dessas tecnologias, você só precisa ter conhecimento JavaScript, pois tudo o que mencionei é baseado nessa linguagem. Mas para trabalhar com API, não necessariamente você precisa pegar uma STACK pronta, você pode adaptar o que você já está acostumado à ideia de API.

Pensando nisso, eu peguei as tecnologias mais comuns (LAMP – Linux, Apache, MySQL e PHP) e adaptei à ideia de API. Transcrevendo a ideia do MEAN, o Apache preenche o item 4, o PHP preenche o item 2, o MySQL preenche o item 1 e o item 3 pode ser preenchido por qualquer biblioteca cliente que você quiser, inclusive o próprio AngularJS. Então meu MEAN virou um MPAA (MySQL, PHP, AngularJS, Apache).

Nessa ideia, eu criei uma webapp que faz a mesma coisa que o exemplo do artigo da Caelum, e disponibilizei para qualquer um poder estudar e aprimorar a ideia. Segue os links:

Espero que esses links possam ajudá-lo nos seus estudos.