Back to computing

Muito longo; não li (ml; nl ou tl;dr tupiniquim): post pessoal sobre meu trajeto na computação e aprovação no programa Outreachy.


Já sigo um tempo sem postar por aqui nem no dicas e toda semana fico pensando “putz, precisava voltar com o blog, preciso mandar email pro dicas”… mas sento no computador, enrolo, entro em mil vortexes pela internet e quando percebo já está tarde e não tenho mais tempo.

Soa familiar? Infelizmente esse é um problema muito comum e não existe segredo – pelo menos não descobri ainda, se souber deixa nos comentários, por favor… É muito difícil achar motivação e foco, principalmente quando a gente já trabalha tanto e quer ficar fazendo nada nas horas vagas. Já li muitos conselhos, posts, livros sobre o assunto e sempre chego à conclusão que a solução mesmo é parar de pensar sobre fazer ou não ou quando começar e sentar a bunda na cadeira e começar o que você quer/tem que fazer. A gente costuma gastar muito tempo se dando desculpas do porquê não começar ao invés de gastar esse tempo fazendo o que tem que ser feito.

Hoje voltei por ter uma novidade muito especial! Pra quem me acompanha desde o início do blog e para os meus amigos próximos, sabem que eu não sou desenvolvedora, embora trabalhe com desenvolvimento de sites desde 2008. Sempre fui mais designer, porém há uns 2~3 anos minha vontade de voltar a estudar computação (fiz curso técnico) tem aumentado. Do ano passado pra cá tive que me virar muito com a plataforma que usamos na Mupi, startup da qual sou co-fundadora, e  por isso considero que subi alguns níveis na área. De todo modo, continuo com muitas lacunas teóricas e ainda não consigo me definir como desenvolvedora. Ok, tem um pouco de síndrome de impostora nisso, mas eu chego lá.

Em março deste ano, decidi aplicar novamente para o programa Outreachy que tem o intuito de inserir mulheres na comunidade de software livre – eu já havia aplicado uma vez em 2013 e não tinha conseguido. Fiquei sabendo que as inscrições estavam abertas faltando 1 semana para encerrar (obrigada Mônica por ter me avisado <3) e corri pra me inscrever, já que o processo consiste em preencher a ficha de inscrição e contribuir com um patch pro projeto que eu queria entrar, ou seja, toma um certo tempo. Passada a correria, stress e tempo livre trabalhando nisso, quem entrou num projeto da Mozilla? Yo! Olha o meu nominho ali.

Ser aprovada no Outreachy tem sido muito importante para eu perceber minha capacidade e comprovar que toda conquista é precedida de muito esforço e dedicação, mas é possível! E essa tem sido minha motivação para desprocrastinar.

Para as meninas que queiram prestar nas próximas turmas, o processo que segui foi:

  • Fuçar no site do Outreachy projetos que fossem do meu interesse (eu me interessei por uns 4, mas é bom focar em 1 porque não há tempo para tentar todos).
  • Entrar no canal IRC do projeto escolhido.
  • Conversar com os mentores sobre possíveis bugs e patches para enviar e por onde começar.
  • Configurar o ambiente de desenvolvimento local para trabalhar nos bugs -> eu tentei trabalhar em dois projetos e essa é a parte mais difícil e demorada, pois requer muito tempo para entender como o projeto funciona, instalar todos os requisitos do projeto e fazê-lo rodar como deveria na sua máquina.
  • Subir o patch do bug resolvido. -> aqui é importante ter um pouco de familiaridade com git, se você não tem, sugiro começar agora, dá uma olhada nesse curso gratuito do Willian Justen. Recomendo super!

Para vocês veram o tipo de patch que é pedido, eu enviei 2 pull requests  (esse e esse) e mandei um pequeno fix para um outro projeto da Mozilla.

Todas as pessoas com quem conversei da Mozilla foram super receptivas e atenciosas, então não tenha medo de fazer perguntas, nenhuma pergunta é idiota. Mas claro, recomendo você sempre tentar resolver as coisas antes e fazer as perguntas à medida em que ficar bloqueada e não o contrário, perguntar antes de tentar.

Bem, próximos passos: dia 23/05 começa o programa e aí que meu trabalho começa de fato. Pretendo continuar compartilhando meu processo e aprendizado por aqui, quem sabe não ajuda mais pessoas a se movimentarem e a deixarem de procrastinar um pouco? Além de incentivar mais meninas a virarem desenvolvedoras e se aventurarem no mundo do software livre.

Como gravar sua tela em gifs animados no Linux

Todo mundo que me conhece sabe que sou fã incondicional de gifs animados (a louca dos gifs). Ultimamente fui surpreendida pela popularização da utilização de gifs em tutoriais e documentações técnicas, algo que eu ainda não havia pensado sobre mas que achei genial pela simplicidade e eficiência dessa prática. Além de tornar documentações e tutoriais muito mais envolvente. Veja um exemplo que estamos usando na Escola Mupi (aqui tem uns legais também):

Exemplo de gif animado em guias de usabilidade

Existem várias formas de se fazer isso. Você pode, por exemplo, gravar sua tela em video e depois editar exportando para gif (o Adobe Premiere faz isso, Camtasia também, e existem alguns programas só para este fim). Mas como uso Linux, precisei aprender como fazer isso sem esses programas que só rodam no Windows ou Mac OS, e encontrei o Byzanz, que você pode ver seu código aqui.
O Byzanz permite gravar a tela diretamente em um gif animado. Como não encontrei muitas informações sobre ele (parece que seu site está fora do ar), resolvi criar esse tutorial para ensinar como utilizá-lo, já que o achei super simples e soluciona muito bem essa necessidade.
Spoiler: é tudo pela linha de comando então se você, assim como eu, tem muito apego visual, recomendo um pouquinho de paciência que no fim das contas é simples de usar e é possível que você vicie e queira gravar tudo! 🙂

1 – Instalar o Byzanz Abra o seu terminal e execute os passos abaixo para instalar o Byzanz.
Se você usa Fedora e Gnome, o byzanz já está no repositório do Fedora então basta instalar:
$ sudo yum install byzanz

No Ubuntu 13.10, Ubuntu 13.04, Ubuntu 12.04, Ubuntu 12.10:
$ sudo add-apt-repository ppa:fossfreedom/byzanz
$ sudo apt-get update
$ sudo apt-get install byzanz

2 – [Opcional] Instalar o Wmctrl
Esse passo é mais uma dica, ele não é necessário. Mas através do Wmctrl (um comando que permite você gerenciar suas janelas) a gente consegue experimentar tamanhos e posicionamentos de janelas para definir a área a ser gravada antes de usar o Byzanz.
Para instalar é igual ao passo 1:
– Para Fedora:
$ sudo yum install wmctrl

– Para Ubuntu:
$ sudo apt-get installwmctrl

Se não achar o Wmctrl, leia este tutorial.

3 – Definindo o tamanho da janela que você quer gravar.
Com o Wmctrl fica bem mais fácil essa etapa, por isso o passo dois. A linha abaixo está dizendo para posicionar a janela atual (no caso sua janela do terminal) se posicionar 500 pixels à direita (eixo x), 100 pixels abaixo (eixo y), com a largura (width) de 800 pixels e altura de 600 (altura) pixels. A opção -e significa que ele vai redimensionar a janela com os parâmetros definidos.
$ wmctrl -r :ACTIVE: -e 0,500,100,800,600
E é só isso que precisamos do Wmctrl, se quiser ver mais opções é só ver o help do Wmctrl com o comando $ wmctrl --help. Agora você pode ficar experimentando os valores até achar o que quer:
terminal

4 – Gravando a tela com o byzanz
Com os valores de tela definido, você posiciona a janela que vai ser gravada, seu navegador por exemplo, no local que ficou sua janela do terminal do passo três.
O uso do byzanz usa os seguintes parâmetros: byzanz-record [opções] nomedoarquivo.gif. No caso do meu exemplo usei o comando abaixo, onde -d 10 se refere à duração da gravação e -c que vai gravar o cursor:
$ byzanz-record -d 10 -c --x=500 --y=100 --width=800 --height=600 terminal.gif
Para conferir o resultado é só ir na pasta onde você salvou e abrir o gif no seu navegador 🙂
Para mais opções do byzanz basta acessar seu manual: byzanz-record --help

E seu gif está pronto :] Simples, não? Eu particularmente achei muito melhor do que depender de editores de videos pesados que demoram pra renderizar e são difíceis de mexer.
Agora é experimentar, boas gravações!
Ah, e se for gravar pra web só cuidado com o tamanho final dos gifs, afinal cada frame é uma imagem que podem custar caro pra sua performance.

Wireframe, protótipo e mockup – Qual a diferença?

Uma das etapas mais fundamentais durante o processo de desenvolvimento de um produto, no nosso caso, web sites ou aplicativos, é a geração de ideias e protótipos. Após compreender o problema que temos que resolver, independente de sua complexidade, é necessário gerar ideias de como será sua solução para então poder implementá-la. Existem várias formas de representar uma ideia e projetar sua solução. O artigo abaixo explica a diferença entre mockups, wireframes e protótipos e é uma tradução livre que fiz do post feito por Marcin Treder no Design Modo. O original pode ser lido aqui.

“Alguns anos atrás me dei conta de que muitos amigos meus de TI, não-designers, usam nomenclaturas de design deliberadamente como se fossem sinônimos. Eles assumem que wireframes, protótipos e mockups são exatamente a mesma coisa – um rascunho meio cinza, com várias formas retangulares que representam uma ideia engenhosa.

O problema com essa visão simplificada é que eles nunca sabem o que esperar do trabalho de um designer de User Experience e muitas vezes ficam confusos. “Por que raios isso não é clicável?”, “Bem, eu não sabia que eu deveria clicar aqui…” – esses são comentários típicos em projetos de UX.

Confundir wireframes com protótipos é como assumir que uma planta de uma casa e aquelas casas modelo decoradas para amostra são a mesma coisa.

Embora você provavelmente queira morar numa casa modelo (você sabe, ela é bonita e supostamente mostra o quão legais são as casas na região), você não pode contar com uma estadia confortável numa planta de imóvel – é apenas uma folha de papel.

Uma casa de showroom e uma planta são diferentes formas de comunicação na área de arquitetura:

– uma planta serve como um plano de construção e deveria especificar como o prédio/casa deveriam ser construídos

– uma casa modelo funciona como um test drive para futuros moradores

A mesma distinção pode ser feita com wireframes, protótipos e mockups. Eles aparentam diferente, comunicam algo diferente e servem para propósitos diferentes.

Porém, uma casa modelo e uma planta tem uma coisa em comum: as duas são representações do produto final – uma casa real. E novamente, o mesmo tratamento pode ser aplicado aos wireframes, protótipos e mockups: todos eles são formas de representação do produto final.

Acredite ou não, a diferença entre um protótipo, um wireframe e um mockup é sempre uma das primeiras coisas que tento ensinar aos membros do meu time de design de UX.
Sim, esse assunto é realmente importante.

Vamos discutir wireframes, protótipos e mockups em detalhe, assim você poderá entender em quais situações utilizar cada um.

Wireframe

1. O que é um wireframe?

Um wireframe é uma representação de baixa fidelidade de um design. Ele deve mostrar claramente:

– os principais grupos de conteúdo (o quê?)

– a estrutura da informação (onde?)

– uma descrição e visualização básica da interface e interação do usuário (como?)

Wireframes não são apenas caixas meio sem sentido desenhadas em p&b, embora pareçam exatamente isso. Considere-os como o esqueleto do seu design e lembre-se que os wireframes devem conter a representação de todas as partes importantes do produto final.

UXPin_DM1

“Representação” é um termo crucial aqui, que te ajuda a encontrar a fidelidade certa – e equilíbrio de velocidade de desenvolvimento. Você não pode mergulhar em muitos detalhes, mas, por outro lado, você precisa criar uma representação sólida do produto final que não sentirá falta de nenhuma parte importante. Você está definindo um caminho para todo o projeto e para as pessoas com quem você trabalha (desenvolvedores, designers gráficos, redatores, gestores de projetos – todos eles precisam de wireframes bem-feitos). Na verdade você está criando o mapa de uma cidade. Cada rua é representada no mapa, porém de uma forma bastante simplificada. Você consegue sentir a arquitetura da cidade ao olhar um mapa, mas não pode ver sua beleza.

Wireframes devem ser criados num espaço de tempo curto: a maior parte do tempo deve ser gasta na comunicação com seus colegas e… pensando. A simples atividade de criar o wireframe deve ser realmente muito rápida.

A visualização de um wireframe se dá esteticamente, mas de uma forma bastante simplificada. Preto e branco são as cores típicas que você irá usar (você pode adicionar o azul para especificar os links).

Se algumas escolhas tomarem bastante tempo (por exemplo a escolha de ícones, subir imagens), você deve representá-las de uma forma primária (ex. utilizando espaços reservados para certos elementos – retângulos vazios com um “X” no meio para imagens acompanhados de uma descrição). Nós costumamos chamar wireframes de “entregáveis de baixa fidelidade” (lo-fi).

Lembre-se: um wireframe bem-feito deve comunicar o design de uma maneira cristalina e definir o caminho a ser seguido por todo o time.

2. Quando utilizar wireframes.

Wireframes normalmente são utilizados como parte da documentação de um projeto. Como eles são estáticos e congelam a interação em um ponto específico no tempo, eles devem ser acompanhados de descrições por escrito (de pequenas anotações explicando as interações até documentações técnicas mais complexas, quando necessário).

No entanto, eles também podem ser utilizados em situações mais informais. Já que são simples e rápidos de serem feitos, servem também como rascunhos claros para serem usados na comunicação interna do time. Se os desenvolvedores perguntarem como algo deve ser feito, a resposta pode ser dada com a criação rápida de um wireframe.

Considere isso: a UXPin é uma start-up com ciclos de desenvolvimentos realmente rápidos (releases a cada dois dias). Nós utilizamos wireframes para a visualização rápida de tarefas (até as pequenas!). Isso elimina desentendimentos e é realmente barato.

Wireframes são dificilmente utilizados como material de teste, ainda que possam ajudar a coletar feedback inicial, estilo guerrilha; ou como uma pesquisa na qual você não se importe muito sobre metodologia, mas sim em conseguir rápidos insights.

Wireframes inseridos no contexto do processo completo do design podem ser surpreendentemente eficazes e, ainda que nos últimos anos tenham ganhado má reputação, continuam indispensáveis na fase inicial de projetos complexos.

Protótipo

1. O que é um protótipo?

Um protótipo, muitas vezes confundido com um wireframe, é uma representação de média a alta fidelidade do produto final e que simula a interface de interação do usuário. Ele deve possibilitar ao usuário:

– experimentar o conteúdo e as interações da interface

– testar as principais interações de forma similar ao produto final

Um protótipo é uma simulação da interação final entre o usuário e a interface. Pode não parecer exatamente com o produto final, mas deve ser bastante similar (definitivamente não é um coisa cinzenta e com cara de rascunho, como são os wireframes). As interações devem ser moldadas com cuidado e apresentar uma semelhança significante com a experiência que o usuário terá no produto final. A interdependência entre a interface e o funcionamento do backend é frequentemente omitida para reduzir custos e acelerar os ciclos de desenvolvimento.
2. Quando utilizar um protótipo.

UXPin_DM2

Protótipos são utilizados em seu máximo potencial nos testes de usuário. A simulação das interações finais geram um ótimo material para testar a usabilidade da interface antes do desenvolvimento iniciar de fato.

Os protótipos normalmente não são a melhor forma de documentação, já que exigem do “leitor” um certo esforço para entender a interface. Por outro lado, um protótipo é a forma mais engajante de documentação do design, uma vez que a interface é palpável e direta.

Lembre-se que criar protótipos pode ser caro e consumir bastante tempo. Uma sugestão é criar protótipos que possam ser utilizados no desenvolvimento (sim, isso significa que você deve saber programar um pouco de HTML e CSS). Isso é especificamente eficaz em projetos relativamente simples.

Feita de forma correta e combinada com testes de usuário, a criação de protótipos consegue pagar seu custo.

Mockup (mock-up)

1. O que é um mockup?

Um mockup é uma representação estática de média a alta fidelidade de um design. Muitas vezes um mockup é um rascunho bem próximo do design final do produto, ou até o próprio design visual do produto final. Um mockup bem feito:

– representa a estrutura da informação, visualiza o conteúdo e demonstra as principais funcionalidades de uma forma estática

– estimula as pessoas a realmente revisarem a parte visual do projeto

Mockups são muitas vezes confundidos com wireframes, por causa dos nomes de certas empresas de software.
2. Quando utilizar um mockup.

UXPin_DM3

Os mockups são particularmente úteis quando você quer vender a ideia do produto antes dele estar pronto para seu público estratégico (stakeholders). Graças a sua natureza visual, mockups não possuem a resistência dos entregáveis de baixa fidelidade (wireframes) e são bem mais rápidos de criar do que protótipos. Eles são ótimos coletores de feedback e, se inseridos no contexto geral do processo de criação do design, podem criar um bom capítulo da documentação.

Resumo

 Representação Fidelidade Custo Uso  Características
Wireframe baixa $ Documentação, comunicação rápida Rascunho, representação preta e branca da interface
Protótipo média a alta $$$ Teste de usabilidade, esqueleto reutilizável para o desenvolvimento da interface Interativo
Mockup média a alta $$ Coletar feedback e conseguir vender a ideia do produto Visualização estática

Por onde começar?

Antes de escolher um meio de comunicação do processo de design você precisa:

– especificar o problema que você está tentando resolver

– entender o seu público-alvo

– dar uma olhada no que os concorrentes tem feito na área

– definir os requisitos gerais do produtos

Isso é o mínimo. Agora pense qual entregável será mais apropriado para você. Considere seu produto e seu time. O que funcionará melhor para vocês? Uma documentação formal ou rascunhos mais informais e discussões presenciais? Você tem tempo e dinheiro para uma pesquisa mais consistente de usabilidade ou vai apenas a um café local desenhar alguns rascunhos a mão para os seus futuros clientes?

Quais habilidades você possui? Você sabe programar?

Olhar para si mesmo(a), seu time e seu projeto deve lhe guiar pelo processo de escolher o melhor entregável.

Você pode, é claro, criar todos e… na maioria dos casos você vai! Não tenha receio de dar esse passo. Os três fazem sentido e, se forem bem executados, podem te levar a um ótimo produto final.”

Artigo original: http://designmodo.com/wireframing-prototyping-mockuping/

Preciso modificar um commit passado, como faz?

Nas últimas duas semanas tenho tido um intensivão de aprendizado de git por causa da reformulação do site da Escola Mupi. O projeto usa como base uma plataforma que se chama Timtec, mas que ainda está sendo desenvolvida, logo muitos bugs, features faltando e muitos merge conflicts… Eu que ainda estou descobrindo as magias do git, tenho uma relacionamento de amor e ódio, pois já fiz muita besteira e perdi muitas horas de trabalho por não saber como ele funciona direito, assim como ele já me salvou muitas vezes <3

Esses dias, precisei adicionar alguns arquivos num commit antigo para manter minha árvore organizada e coerente. Para isso, @padovan me ensinou a resolver esse problema usando fixup + rebase interactive [que eu particularmente achei incrível]. Vamos lá:

Antes de iniciar, você precisa copiar um pedaço inicial do hash do commit que você deseja modificar. O hash é o código de identificação do commit, exemplo: 636bf2643e67bf34f67691333b916e292571a469. No caso os 6 primeiros caracteres já são suficientes. Você pode achar o hash com o comando git log.

Tendo isso copiado, deve-se fazer um “fake” commit. Ou seja, criamos um commit que servirá apenas como um repositório temporário das novas modificações que serão acrescentadas ao commit desejado. Para isso usamos o seguinte comando:

$ git commit --fixup=636bf26

Isso cria um commit com a mensagem “fixup! + msg do commit selecionado”. Isso ajuda a identificar que esse não é um commit convencional, mas que precisa ser “fixed up”. Feito isso, agora vem a magia: git rebase --interactive ou git rebase -i. O rebase interactive dá muito mais flexibilidade para modificar os commits. Para usá-lo precisamos indicar a quantidade de últimos commits a serem mostrados a partir do HEAD. No meu caso, os 4 últimos commits foram suficientes:

$ git rebase -i HEAD~4

que nos dá no editor padrão do terminal a quantidade indicada de commits em ordem do mais antigo ao mais novo, assim como todas as opções do rebase interactive. Nesse exemplo só vamos utilizar fixup (note que existem outras opções pra rebase interativo que podem ser muito úteis em outras situações):

Para a magia acontecer, é preciso escrever f no lugar de pick na frente do commit de fixup e modificar a ordem dos commits, colocando-o logo abaixo do commit desejado:

Agora é só salvar e voi lá! o “fake” commit é fundido no commit de cima =) é só dar um checada se deu tudo certo com git log.

UPDATE: Como pode se ver na primeira imagem, existem outras opções bem interessantes para se usar no rebase interativo, como o reword, que permite modificar apenas a mensagem de algum commit, e o squash que permite juntar dois ou mais commits em um só. Para quem lê em inglês, sugiro este artigo do github a respeito e dou um quote de alerta (tradução livre minha): “É considerada uma má prática dar rebase em commits que já foram submetidos ao repositório remoto. Ao fazer isso, você poderá invocar a ira dos deuses do git”.

obs.: Para modificar o último commit feito, git commit --amend é a melhor opção, já que “reabre” o último commit para edição.

Learn how to code Javascript by playing a game!

CodeCombat is a web based game that teaches you how to code with Javascript by playing it and so far, the more I get to know it the more I like it! 

The game has a 2D RPG skin with cute characters and runs directly in the browser. At the beginning it is a bit hard to get used to its UX and for those who are anxious, sorry to tell, but you will have to read the instructions. But when you start to get how it works it gets more fun and without noticing you are learning how to code and hacking the code they give you in order to pass the levels faster.

The better part of Codecombat I just found out yesterday: the team who built it has open-sourced everything! I have even talked with the team and they are super accessible, they have provided a few aways of doing that.

There are a bunch of ways to get involved with the game and helping spread code education out there. So, if you are looking for a free and open-source software to contribute, you should consider this one.

What I’ve learnt at #learnfest

Yesterday I’ve attended to Learnfest Conference & Festival @Campus Party, an event to gather great and important people that are working hard for a better education. It intends to be more than a conference: a movement that motivates people to use their energy in order to focus their effort to make create ideas and solutions for social problems involving education.

I am already working with education and technology for a couple of years now and one of the most frustrating parts about being an entrepreneur at this field is to deal all the time with the dilemma social vs. money. So I could say that events like this are always important to remind me of why I’m doing this and why I’m giving up of a lot of things to use my knowledge and potential for dealing with real & big problems that I believe that are important to be solved.

Although somethings can sound obvious, and actually they can be obvious, it is always good to punctuate them:

The problem we are trying to solve can be bigger than we think, so we need to consider the process and the time

When we are trying to do a massive thing, and I’m not saying that we shouldn’t think big, but we should consider the whole context and that somethings are out of our hands or else we will get really frustrated, mainly in the educational field that everything is very tied and outdated. It doesn’t matter how good was our planning and strategy, we need to consider that somethings just cannot be solved from one day to another, it takes a while and a lot of effort and timing.

Innovation for a big company is not the same for a start-up

As a start-up, we need the help from big companies in order to grow up and conquer market, but we have to know how to understand them and that our concepts of innovation are different. We have also to remember that they need us too. Their operation process prevent them from doing and testing things fast and cheap as well as creating new solutions.

Money != quality

Yes, we (Brazil and LATM) are investing a lot of money in education but we still have a countless number of problems in this area. As Brian Pick, the Chief of teaching and learning at Washington D.C., mentioned at the event, we need to focus on three major things: 1) train and gather the very best teachers; 2) acquire and create the very best content; and 3) engage the students and families. These are our major efforts in order to build Mupi, an online school of creative technology in Portuguese.

 

One thing that I’ve noticed in common among all of the speakers and participants was that we have a lot of challenges ahead but we are also getting strong and the ones that are successful are the ones that didn’t changed their goals despite of all the problems faced and really want to invest their efforts in something bigger. This inspired me to go on and keep up the good job. Who knows I’m not sharing my values and successful (and not so successful) cases in a near future to help other adventurers? 😉