Estamos desenvolvendo na Myfreecomm um sistema de cobrança que está ficando muito interessante. Ele irá resolver um problema real e trará muita conveniência no dia-a-dia das empresas que realizam cobrança com integração com os bancos.

O sistema está quase pronto e estamos neste momento definindo aqueles detalhes que fazem toda a diferença.

A concepção foi baseada em um fluxo único de uso, de forma que os itens de menu contemplassem as ações que o usuário irá realizar, como se o sistema todos fosse um grande wizard. As páginas acessórias são acessadas apenas por links contextuais. Não temos menu e submenu, nem breadcrumb. E te digo, fazer o sistema assim é um desafio!

A interface ficou bem simples, sem muitas opções e com links no lugar certo e na hora certa. Quando fazemos sistemas deste gênero as palavras e termos utilizados nos itens de menu, nos títulos e nos links são muito importantes. É preciso que o usuário consiga se situar de forma rápida e entenda o que irá acontecer a cada clique.

O Allan é o responsável por fazer com que o sistema seja entendido pelos usuários. Ele está escrevendo o manual, pensando em que lugares existirão links para o manual, quais são os pontos que podem gerar dúvidas, etc. E nesse processo ele está revendo os termos utilizados a todo momento. Inclusive nas interações chegamos a perceber e incluir na histórias novos status para determinada entidade e tudo.

Hoje ele levantou uma bola que gerou uma discussão muito saudável. Uma das ações do usuário no sistema é juntar várias cobranças para que elas sejam enviadas para o sistema do banco. Até hoje, o termos utilizado para esse conjunto de cobranças era Remessa. Tínhamos termos tais como: Preparar Remessa, Enviar Remessa, Remessas Pendentes e Remessas Enviadas.

A questão levantada foi: “Não deveria ser Lote ao invés de Remessa?”

A conclusão imediata depois de um rápido brainstorm foi de que tanto faz, afinal dá no mesmo, lote e remessa são a mesma coisa. Bem, depois de muita conversa e esclarecimento sobre entidades, estados, tempos, etc chegamos a uma opinião diferente.

Buscamos definições de lote e remessa no Google, depois fomos aos dicionários priberam e Aurélio. Mais alguns minutos de discussão e desenho foram neecessários para concluirmos que Remessa é algo que foi enviado, ou seja, que já passou pelo processo de envio. Se existe algo que pode ser remetido, mas ainda não o foi, isso não pode ser chamado de Remessa.

Donde se concluí que  dizer “Enviar Remessa” está errado e o termo “Remessa enviada” é um pleonasmo. Se é Remessa, é por que já foi enviado.

No meio da discussão chegamos a lembrar que muitas vezes não importa o “certo” e “errado” na gramática formal e que o mais importante é o entendimento do usuário. Mas é o que eu digo, se podemos usar o correto de acordo com a gramática sem afetar o entendimento do usuário, melhor. Se, usando o termo gramaticalmente corrento, ainda assim facilitamos o entendimento do usuário, como foi o caso, melhor ainda!

Por fim decidimos usar o termo Lote ao invés de Remessa e mudaremos para “Preparar Lote”, “Enviar Lote”, “Lotes pendentes” , “Lotes enviados” e outros termos presentes na interface. Como escrevemos todo código de programação em inglês, não tivemos maiores problemas.

Essa experiência foi muito interessante, pois foi legal estudar e discutir sobre o significado destas palavras e foi incrível perceber como uma mudança simples pode ao mesmo tempo melhorar o sistema e facilitar nosso trabalho. Ficará mais fácil agora escrever o manual. É aquela velha história: Se está difícil, está errado!

Uma vez eu li um post da 37signals extamente sobre isso. Agora eu entendo perfeitamente o que eles queriam passar com o post, e é o que eu espero deixar de recado também.

A definição de termos corretos e fáceis de serem compreendidos pelo usuário é fundamental para a boa usabilidade do sistema.

Além disso, escolher as palavras certas facilita a compreensão da relação do que elas representam com o sistema como um todo.

São diversos fatores que tornam um sistema bom ou ruim, difícil ou fácil de usar e complexo ou simples. Usar palavras corretas e de simples entendimento é um fator muito importante. Às vezes parece que está tudo bom, e que as palavras estão certas e serão compreendidas, mas nem sempre é verdade.

Pense no sistema que você usa ou está desenvolvendo. Será que mudando alguns termos não ficaria muito mais fácil de usar? Você tem algum caso similar? Deixe sua história nos comentários!

Abraços e até a próxima.

Eu gostei tanto deste artigo que resolvi traduzí-lo e publicá-lo aqui.

Atenção: Este artigo não é de minha autoria. Ele foi traduzido do artigo escrito por Alberto Gutierrez, disponível em: http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-programmers/

***

Existem dois conjuntos de habilidades que um bom desenvolvedor precisa cultivar: habilidades técnicas e não técnicas. Infelizmente, alguns desenvolvedores focam somente na parte técnica. Quando isso acontece eles desenvolvem alguns maus hábitos dos quais os seguintes 5 são os erros não técnicos:

1 .- Falta de disciplina.

“Disciplina é a ponte entre estabelecimento de objetivos e o cumprimento de metas.” Jim Rohn.

Sempre achei que disciplina fosse uma das habilidades mais valiosas, não só por ser um desenvolvedor de software, mas também para ser bem sucedido em qualquer outra área da vida também. E é bem verdade que, geralmente, é muito difícil encontrar pessoas que são tanto brilhantes quanto disciplinados.

Steve Pavlina destaca os 5 pilares da auto-disciplina … “[...] Aceitação (Acceptance), força de vontade (Willpower), trabalho árduo (Hard work), esforço (Industry) e persistência (Persistence). Se você pegar a primeira letra de cada palavra, você terá a sigla “A WHIP” (Um Chicote) – uma maneira conveniente de recordá-las, uma vez que muitas pessoas associam auto-disciplica como uma forma de chicotear-se em forma.[...] Eu altamente recomendo que leia sua série de artigos na auto-disciplina.

Como expliquei no meu artigo anterior: 5 dicas para criar bons códigos todos os dias, a minha abordagem pessoal é seguir estes passos todos os dias.

-Prepare sua própria lista de afazeres do dia.
-Faça uma coisa de cada vez
-Faça-o direito
-Não finalize nada até que tenha completado tudo.
-Antes tarde do que arrependido, PORÉM antes arrependido do que nunca.

2 .- Grandes egos.

Pela minha experiência posso dizer que grandes egos e programadores vão de mão em mão, o principal problema de ter um grande ego é que, na realidade, ele te impede de perceber que você o tem. Alguns indicadores que podem ajudar você a saber se o seu ego é grande são as seguintes:

* Você se considerar o melhor programador.

* Você bloquear conversas.

* Você pedir verificações de códigos não para obter opiniões críticas, mas para mostrar quão bom o seu código é.

Existem artigos muito bons na internet sobre programadores e seus egos, eu recomendo dois deles, este artigo de Mike Bernat: “Programação sem ego algum” e esta dicussão em stackoverflow.com.

3 .- Ser um mau comunicador.

“Se eu for falar por dez minutos, eu preciso de uma semana de preparação; se quinze minutos, três dias; se meia hora, dois dias, se uma hora, estou pronto agora“. Woodrow Wilson

Como a comunicação é nossa principal atividade. Ser um bom comunicador é difícil, porém essencial à nossa profissão, estamos continuamente trocando opiniões sobre designs, códigos, fazendo revisões, escrevendo documentações, tentando convencer os outros que nosso projeto é melhor, escrevendo código…

Bons comunicadores são pessoas que, quando estão explicando alguma coisa, sua explicação é a seguinte:

* Foco. Eles só falam sobre o que é preciso para se compreender.

* Clareza. Fácil de entender.

* Breve. Nada a acrescentar, nada a retirar.

Para ser um melhor comunicador, tenho dois conselhos:

* Se você acha que não é um bom comunicador, prepare o que vai falar até ficar focado, claro e conciso.

* Se entrar numa conversa, primeiro ouça, depois pense e depois fale.

Há mais algumas dicas para melhorar a comunicação quando tiver uma reunião neste artigo que publiquei anteriormente “7 melhores práticas para tomar decisões no desenvolvimento de equipe“.

4 .- Esquecer o cliente.

“Se não cuidarmos do cliente … alguém vai cuidar.”

Você está aí por uma razão apenas, seu cliente. É fácil, as vezes, esquecer isso. Estive em equipes que se concentraram em tecnologias e plataformas, em vez de ter um cliente feliz. Gastaríamos meses criando uma estrutura que não proporcionaria valor algum para o cliente, e pelo tempo que começaríamos a usá-la, iríamos acabar descobrindo que não se encaixa nas nossas necessidades.

5 .- Não priorizar o trabalho corretamente.

Os programadores que estão sempre se atualizando muito, pesquisando novas e mais interessantes tecnologias, mais soluções de engenharia ou simplesmente fazendo tudo o que acham mais legal, são empecilhos para o projeto. Não estou dizendo que não é normal que se engaje em atividades paralelas ao longo do tempo, pois todos nós precisamos de distrações, mas se você se encontra normalmente nas situações ditas antes, você deve reconsiderar a forma como prioriza seu trabalho, mais uma vez vou recomendar que leia as ‘5 dicas para criar bons códigos a cada dia‘.

Estava com um problema sério para colocar o Velox pra funcionar direito via conexão direta no Windows Vista Business na BielSystems. Depois de ler um bocado solucionei rodando a seguinte linha no command prompt como administrador:

netsh interface ipv4 set subinterface “Velox” mtu=1300 store=persistent

É isso!

Todos nós sabemos que um projeto de software que não possui um deploy seguro e automático acaba falhando em algum momento. O deploy é o ato de colocar o que foi desenvolvido em produção.

Os projetos que não possuem um bom sistema de deploy, acabam acumulando muitas tarefas antes de virar para produção. Isso ocorre por não justificar gastar, por exemplo, o dobro de tempo gasto no que foi desenvolvido somente para fazer a entrega.

Ai sabe como é que é, o tudao.tar.gz demora pra ser enviado, problemas de falta de arquivo, ninguém dorme, e aquela história de sempre.

Se você está desenvolvendo para web, utilize o Capistrano. Mas este post não é sobre isso.

Essa introdução é uma justificativa para o sistema de deploy que eu montei para o meu podcast Voltando pra Casa.

Desde que tive a idéia de fazer o podcast, eu sabia que se eu não montasse um esquema automatizado para a publicação, acabaria não mantendo com a freqüência desejada de um podcast por dia.

Comecei a pensar no fluxo necessário e cheguei à seguinte proposta:

1. Gravo no meu Celular Nokia N95 os arquivos
2. Ao ligar o MacBook o script de sincronização (de contatos e agenda) rodaria também a sincronização dos audios gravados. (isso ainda não rolou)
3. Um programa escrito em Ruby e Shoes abriria perguntando quais arquivos eu desejo publicar. (isso não vai rolar, usei a abordagem de workflow por diretório)
4. Ao selecionar os arquivos, eles entram em fila para serem processados.
5. A rotina de processamento, faz um mix colocando um wav padrão no início e no final de cada arquivo.
6. Os arquivos já mixados são convertidos de .wav para .mp3
7. Em seguida, as tags ID3 são aplicadas em cada arquivos convertido
8. Eles são enviados por ftp para o meu servidor de hospedagem
9. Um post é criado no WordPress pelo XML-RPC e salvo como rascunho
10. O firefox é aberto na página do post para eu editá-lo e publicá-lo

Resumindo, minha interação se restringe a escolher quais arquivos gravados no celular serão convertidos em podcast e depois publicar no momento que achar oportuno.

Desta maneira a chance de eu conseguir manter este podcast aumenta bastante!

Vou publicar este script em breve no GitHub em http://github.com/rafaelp/podcast-deployment

Abraços e até a próxima.

Todas vez que eu reinicio o computador, o Firefox pergunta se eu desejo definí-lo como navegador padrão. O mesmo acontece com o Audim.

Eu suspeitei que pudesse ter haver com o FileVault que eu mantenho habilitado. Depois de algumas buscas descobri que eu estava certo. Existe um bug desde a versão 10.4.5

Fica a dica para os googlers perdidos.

Palavras chaves: mac, macos, bug, filevault, preferences, boot, restart, ask, default.