segunda-feira, dezembro 27, 2010

Interfaceando Microcontroladores - Parte 6

Quase dois meses depois, eis a sexta (e última parte) desta série de posts. O assunto aqui são os displays LCD alfanuméricos. A abordagem aqui é bastante sucinta, estes displays certamente merecem uma série própria de posts.



Como referência, seguem abaixo os links para as demais partes da série:

Parte 1 - Resumo das arquiteturas dos microcontroladores usados como exemplo
Parte 2 - Programação dos periféricos em C
Parte 3 - Entrada e Saída Digital
Parte 4 - Entrada e Saída Digital (continuação)
Parte 5 - Entrada e Saída Analógica e interface com LCD organizado em segmentos

domingo, dezembro 26, 2010

Jogo do Mês: Broken Sword - The Director's Cut

Comprei este jogo de aventura no embalo das promoções de final de ano do GOG.com. Embora a versão original seja de 1996, o GOOG.com está vendendo um remake recente (feito em 2009 para o DS e Wii e portado para o PC agora em 2010). Nos comentários no site fala-se que esta versão estaria "simplificada" em relação à original para atrair jogadores mais "casuais". Como não conheço a versão original, avalio aqui apenas a nova versão.


quarta-feira, dezembro 22, 2010

Windows for ARM ?

O burburinho do dia é o possível anúncio de um versão do Windows (desktop) para processadores ARM, a ser feito na CES no início de janeiro. Segundo algumas fontes, o produto propriamente dito só estaria disponível daqui a 2 anos (e portanto seria o Windows 8).

A maioria não lembra disto, mas um dos objetivos do Windows NT era ser um sistema portável, suportando tanto a arquitetura x86 (na época o 386) como arquiteturas RISC. Ele chegou a ser comercializado em versões para processadores MIPS, Alpha e PowerPC.

O Windows CE também foi projetado para ser portável; após suportar arquiteturas diversas como x86 e MIPS, acabou se concentrando na arquitetura ARM.

Para quem enxerga nisto uma ruptura completa da Microsoft com a Intel, é bom lembrar que a Intel fabrica a tempos processadores com arquitetura ARM (embora é claro que ela prefira as suas próprias arquiteturas).

A Microsoft tem, portanto, as ferramentas e a experiência necessária para adaptar o Windows para a arquitetura ARM. A dificuldade do port de aplicativos vai variar bastante caso a caso. E a Microsoft tem os contatos e a força política para colocar no projeto fabricantes de hardware e acessórios, garantindo uma disponibilidade no mínimo razoável de equipamentos e drivers na época do lançamento.

E qual o motivo de tudo isto? Aparentemente os tablets. Embora a Microsoft venha tentando abrir este mercado literalmente há décadas (alguém lembra do Windows for Pen Computing?), quem emplacou um produto foi a Apple. Planos para tablets com o Windows 7 parecem ser escassos. Não existe nem menção em usar o Windows CE neste tipo de equipamento. O recém lançado Windows Phone 7 não é considerado adequado para tablets.

Minha opinião? É um boato muito plausível mas o ponto crítico para um tablet não é o sistema operacional, mas sim a interface com o operador. A interface do Windows (e a API por trás) me parece muito amarrada ao uso de mouse. Sem mexer nisto, será mais um fracasso.

Alguns links de notícias a respeito:

OSNews
The Register
Bloomberg
Wall Street Journal

O Kit MSP430 Launchpad

Na imensa lista de "coisas que eu gostaria de ter tipo tempo para mexer" está o kit MSP430 Launchpad.

Há muito tempo atrás eu mencionei que a Texas tinha lançado um linha de microcontroladores MSP430 de baixo custo. Este ano ela lançou o complemento perfeito: uma plaquinha de baixíssimo custo (US$4,30) para quem quiser conhecer a plataforma.


terça-feira, dezembro 21, 2010

Será Que Tão Poucos Sabem o Que É Programação Orientada a Objeto?

Entre as minhas "desventuras" deste ano estão algumas tentativas de contratação de desenvolvedores e estagiários. Faz parte do processo aplicar uma provinha nos candidatos entrevistados.

Neste ano eu dei preferência por questões mais básicas e de resposta aberta, na expectativa de fazer o candidato escrever um pouco. A primeira questão era justamente "o que você entende por Programação Orientada a Objeto". Me pareceu "barbada", já que todo currículo diz que o candidato estudou e pratica isto. Eu estava aberto tanto para definições decoradas de livro como para visões pessoais e imperfeitas.

O resultado foi péssimo, poucas respostas faziam sentido. Acho que teve até quem deixou em branco! No entanto, todo este pessoal está formado (ou a caminho de) e escreve programas (profissional ou academicamente) em linguagens como Java e C# (que supostamente impõem OOP). Eu me pergunto o que será que é visto nas aulas.

Talvez a culpa esteja nas IDEs cheia de wizards e outras bruxarias. Por exemplo, no Windows Forms cada formulário corresponde a uma classe (que herda a maioria das funcionalidades de uma classe chamada Form), mas o Visual Studio escreve o grosso desta classe para você e até esconde a parte mais mundana (como a definição dos controles como campos da classe). Talvez tenha gente que nunca tenha reparado que uma classe está sendo definida.

Em tempo: minha tentativa de dizer o que é OOP está aqui; é claro que se alguém me pergunta-se de supetão a minha resposta não seria tão articulada.

segunda-feira, dezembro 20, 2010

domingo, dezembro 19, 2010

Lista: 35 Frases Sobre Programação

Lendo uma lista de 50 frases sobre programação, resolvi selecionar algumas e apresentá-las traduzidas; qualquer que seja a linguagem da sua preferência vai sobrar para ela também:
  • "A programação hoje em dia é uma corrida entre engenheiros de software tentando fazer programas maiores e melhores a prova de idiotas e o universo tentando fazer idiotas maiores e melhores. Até agora o universo está ganhando." - Rick Cook
  • "Andar sobre as águas e fazer software a partir de uma especificação é simples se ambas estiverem congeladas."- Edward V Berard
  • "Uma linguagem de programação é de baixo nível quando exige atenção com o irrelevante." - Alan J. Perlis
  • "Um programa em C é como uma dança rápida sobre chão encerado, executada por pessoas segurando navalhas." - Waldi Ravens
  • "Eu sempre desejei que o meu computador fosse tão fácil de usar quanto o meu telefone; meu desejo se tornou realidade pois eu não consigo mais usar o meu telefone." - Bjarne Stroustrup
  • "O estudo da ciência da computação não consegue transformar qualquer um em um excelente programador, da mesma forma que o estudo de tintas e pinceis não transforma qualquer um em um excelente pintor." - Eric S. Raymond
  • "Não se preocupe se não funcionar direito. Se tudo funcionasse, você estaria desempregado." - Lei de Mosher da Engenharia de Software
  • "Certo, Java PODE ser um bom exemplo do que uma linguagem de programação deve ser. Mas as aplicações escritas em java são um bom exemplo de como as aplicações NÃO DEVEM ser." - pixadel
  • "Considerando o triste estado dos programas de computador, o desenvolvimento de software claramente ainda é uma arte obscura que ainda não pode ser chamada de uma disciplina de engenharia." - Bill Clinton
  • "O uso de COBOL deteriora a mente; o seu ensino deve, portanto, ser considerado uma ofensa criminal." - E.W. Dijkstra
  • "A versão orientada a objeto do 'código espaguete' é o 'código lasanha' - camadas em excesso" - Roberto Waltman
  • "FORTRAN não é uma flor, mas sim uma erva daninha - é dura, raramente floresce e aparece em todo computador." - Alan J. Perlis
  • "Por muito tempo eu não entendi como algo tão caro pudesse ser tão inútil. Aí eu percebi que os computadores são máquinas estúpidas capazes de fazer coisas incrivelmente inteligentes; enquanto que os programadores são pessoas inteligentes capazes de fazer coisas incrivelmente estúpidas. Em resumo, nasceram um para o outro." - Bill Bryson
  • "Na minha opinião egoísta, os programas em C da maioria das pessoas deveria ser identado 6 pés para baixo e coberto de terra." - Blair P. Houghton
  • "A evolução das linguagens: FORTRAN é uma linguagem não tipada. C é uma linguagem fracamente tipada. Ada é uma linguagem fortemente tipada. C++ é uma linguagem cuja utilidade é fortemente exagerada." - Ron Sercely
  • "O bom projeto adiciona valor mais rápido do que custo." - Thomas C. Gale
  • "Falar é fácil. Mostre-me o código." - Linus Torvalds
  • "A perfeição é atingida não quando não se tem mais o que colocar, mas sim quando não se tem mais o que tirar." - Antoine de Saint-Exupéry
  • "C é excêntrico, defeituoso e um enorme sucesso." - Dennis M. Ritchie
  • "Na teoria, teoria e prática são iguais. Na prática, não." - Yogi Berra
  • "Você não consegue um grande software sem uma grande equipe, e a maioria das equipes de software se comporta como famílias disfuncionais." - Jim McCarthy
  • "PHP é um mal menor criado e executado por amadores incompetentes, enquanto que Pearl é um grande e perversivo mal executado por profissionais habilidosos mas pervertidos." - Jon Ribbens
  • "Pearl - A única linguagem que parece a mesma antes ou depois de ser criptografada." - Keith Bostic
  • "Eu inventei o termo 'orientado a objeto', e garanto que não tinha em mente o C++." - Alan Kay
  • "Aprender a programar tem a ver com desenvolvimento de software interativo tanto quando aprender a datilografar tem a ver com a escrita de poesia." - Ted Nelson
  • "Fique atento para bugs no código acima; eu apenas provei que ele está correto, eu não o testei." - Donald E. Knuth
  • "Análise de sistemas é como criar uma criança; você pode fazer um estrago imenso mas não pode garantir sucesso." - Tom DeMarco
  • "Não me interessa se roda na sua máquina! Nós não estamos entregando a sua máquina!" - Vidiu Platon
  • "Medir o progresso de um programa por linhas de código é como medir o processo de montagem de um avião pelo peso." - Bill Gates
  • "A complexidade de depurar é o dobro da de escrever o código. Portanto, se você escrever código os mais inteligente possível, por definição você não será esperto o suficiente para depurá-lo." - Brian W. Kernighan
  • "A maioria dos softwares atuais são como as pirâmides do Egito, com milhões de blocos empilhados um em cima dos outros, nenhuma integridade estrutural, feita apenas pela força bruta e milhares de escravos." - Alan Kay
  • "O problema com os programadores é que você nunca consegue saber o que eles estão fazendo antes de ser tarde demais." - Seymour Cray
  • "Em duas ocasiões [os membros do Parlamento] me perguntaram: 'Diga, Sr Babbage, se eu entrar na máquina números errados ela conseguirá sair as respostas corretas?' Eu não sou capaz de entender a confusão mental capaz de gerar este tipo de pergunta." - Charles Babbage
  • "Codifique sempre como se o cara que for dar manutenção seja um psicopata violento que sabe onde você mora." - Martin Golding
  • "Existem duas maneiras de construir um projeto de software. Uma é fazê-lo tão simples que obviamente não há falhas. A outra é fazê-lo tão complicado que não existem falhas óbvias." - C.A.R. Hoare
Cheguei à lista original a partir do OSNews.

quarta-feira, dezembro 15, 2010

Promoção de Natal do GOG.com

O site GOG.com iniciou ontem a sua promoção de Natal. São quase 300 jogos com descontos de 30 a 50%. Para quem não conhece, o GOG.com vende jogos antigos (mas com compatibilidade garantida com Windows XP e Vista), sem DRM e por preços baixos (as faixas normais são US$5.99 e US$9.99).

Com a promoção, tem jogos a partir de US$2.99. Uma pequena amostra:

quarta-feira, dezembro 08, 2010

Google Entra no Mercado de eBooks

Em um lance aguardado há algum tempo, a Google anunciou no início da semana o Google eBooks e a Google eBookstore.

A Google vem digitalizando livros há bastante tempo, um empreendimento envolto em polêmica pelo fato da Google ter digitalizado livros cujos direitos autorais não estão claros (os chamados "orfãos") e estar tentando um acordo que lhe daria acesso praticamente exclusivo a estas obras (algumas notícias a respeito aqui e aqui).

O serviço de venda de livros está sendo descrito pela Google como "aberto", notadamente pelo fato da Google não estar vendendo um leitor de eBook. Os livros podem ser lidos diretamente na internet, no iPad e dispositivos Android (através de aplicativos da Google) e em alguns leitores de eBook (como os da Sony e o Nook). A grande falta na lista de dispositivos suportados é o Kindle (por enquanto?). No momento a loja está restrita aos EUA.

Curiosamente o iPad é hoje quem tem acesso às três lojas mais badaladas: Amazon, iBooks e Google eBooks. O The Register fez um teste rápido das três opções e deu vitória para a Amazon, por ter uma melhor seleção de livros e um aplicativo de leitura mais eficiente. A Apple leva a pior, com menos opções na loja e um aplicativo que não os agradou (a sua experiência pessoal pode ser diferente!).

O que não impediu Steve Jobs de alardear na metade do ano que a Apple já tinha entregue* 5 milhões de livros, sendo responsável por 22% das vendas de eBooks (ver foto aqui) das editoras participantes do iBooks (grifo meu, isto estava na fala de Jobs não na tela).

* Em todas as opções existe uma grande quantidade de textos grátis, como os encontrados no Projeto Gutenberg. Existem também amostras grátis, o que torna as estatísticas de "entregas" (downloads) menos relevantes do que podem parecer em um primeiro momento.

domingo, dezembro 05, 2010

Novo Som para o Carro: Philips CE120

Com o colapso total do Visteon, precisei procurar um novo aparelho de som para o carro. O meu requisito básico foi ser capaz de tocar MP3 a partir de cartões SD. O formato SD me parece ótimo para a aplicação: dá para gravar um quantidade grande de músicas, o preço é razoável e, mais importante, não fica exposto a trancos acidentais (um problema com as entradas USB).

sábado, dezembro 04, 2010

Cinco Anos de Blog

É difícil acreditar mas na quinta passada (2/12/10) o blog completou 5 anos. Do ano passado para cá não teve muitas novidades e a correria neste final de ano impediu uma comemoração muito especial.

De qualquer forma, aqui estão alguns gráficos mais recentes (clique para ampliar):





Os destaques deste último ano foram:
  • Disponibilização (finalmente) do livro PC Assembler em formato de ebook.
  • A série "Som Aposentado" (1 2 3 4 5 6)
  • A série "Interfaceando Microcontroladores", uma primeira experiência com vídeos no YouTube (1 2 3 4 5 ... falta ainda a última parte!)
  • O Google Groups me deixa na mão (1 2). Está na lista de "urgentes" achar um outro lugar para hospedar os arquivos e acertar todos os links.

quarta-feira, dezembro 01, 2010

Projetando a Interface com o Operador

A interface com o operador (que vou chamar aqui simplesmente de UI) é uma parte crítica de um programa, mas muitas vezes acaba sendo feita com pouco esmero.

Um livro muito bom a respeito é "User Interface Design for Programmers" de Joel Spolsky. A edição impressa está esgotada na Amazon, mas você pode ler hoje mesmo se optar pela versão Kindle. Melhor ainda, parte do material está disponível gratuitamente no site do Joel. É material de quase dez anos atrás mas os princípios continuam valendo.

Uma Interface Intuitiva

"Intuitivo" é um termo muito mencionado quando se fala de UI. As pessoas querem sentar na frente do programa e sair usando. Como se consegue isto?

Um termo que Joel usa é affordance, que ao pé da letra é "permitir" mas que podemos traduzir para "facilitar". Em uma boa interface os objetos "facilitam" o seu uso. É tão óbvio o uso destes objetos que eles parecem "implorar" para serem usados. Esta técnica, entretanto, é limitada quando temos que indicar ações ou escolhas que não tem um equivalente na vida normal. E aí que entra a principal técnica para uma boa interface: a consistência.

Consistência

Se não dá para evitar que o usuário tenha que aprender algo, que ele aprenda somente uma vez. Se ele puder usar o mesmo objeto, da mesma forma, para obter o mesmo resultado, não vai demorar muito para que o seu uso fique intuitivo. Melhor ainda se esta consistência não estiver limitada a um aplicativo mas se extenda a vários.

Isto leva ao que considero a regra de ouro do projeto de UI: O projeto de UI não é lugar de ser criativo. Pode parecer um paradoxo, já que o projeto de UI parece ser lugar para um artista. Embora os aspectos estéticos sejam importantes (e já vou falar deles), um bom projeto de UI consiste em dispor adequadamente elementos padronizados.

Esta consistência visual é incentivada pelos próprios sistemas operacionais, que costumam incluir um bom conjunto de elementos gráficos "prontos". É vital que o projetista conheça os elementos disponíveis, seus recursos e variações e, principalmente, quando eles devem ser usados.

Às vezes existem várias opções possíveis. Neste caso deve-se optar pela que seja mais confortável ao operador. Considere a entrada de um número. Algumas opções:
  • Seleção por radio button: prático se as opções forem poucas e a operação for principalmente pelo mouse.
  • Seleção em um drop list: também para o caso de poucas opções. Tem a vantagem de ocupar menos espaço na tela e a desvantagem das opções não estarem claras.
  • Digitação em um text box: pode ser mais trabalhoso para o operador e para o programador (por envolver consistências) mas é mais prático para uma faixa grande de valores e funciona bem em uma tela com bastante digitação.
O Grande Pecado

Vamos considerar dois elementos básicos da interfaces atuais: os checkbox e os radio buttons (minha experiência é com Windows mas imagino que isto se aplique aos principais SOs atuais). Os elementos padrões do SO possuem uma aparência que automaticamente associamos à forma de operação: checkbox são opções independentes e radio buttons são agrupados em conjuntos onde uma opção exclui as demais.

Uma pequena digressão: será que alguém ainda lembra dos rádios com botões mecânicos onde o pressionamento de um fazia saltar o que já estava pressionado ou esta é uma metáfora cuja origem já se perdeu?

Vamos supor que você ache o checkbox feio e resolva inventar uma aparência diferente (e você certamente não vai estar sozinho nisto). O seu usuário vai ter que aprender que este seu elemento funciona como um checkbox (ou pior, entender um funcionamento parecido mas não igual). O que o usuário ganha em troca deste esforço? Um visual que você acha mais bonito (no que ele pode não concordar).

O pior que você pode fazer, entretanto, é mudar a operação de um elemento padrão. Por exemplo, você faz um checkbox funcionar como radio button (já ví isto). Você acaba de confundir o seu usuário. É um passo esta confusão se transformar em frustração e depois raiva.

Estética

Sim, a estética é importante. Principalmente no que se refere à legibilidade da UI. Cores e fontes diferenciados podem auxiliar a organização da tela, mas devem ser usados com muita parcimônia.

No Windows é bastante trabalhosa a mudança de cores e fontes para quem está programando diretamente a API do Windows. A partir do Visual Basic, estas mudanças ficaram triviais e é natural que alguns desenvolvedores tenham se entusiasmado além da conta.

Uma tela cheia de cores e fontes diferentes confunde a visão do operador. Além disso, o seu cérebro vai ficar tentando achar significados por trás destas pistas falsas.

Por último, é bom lembrar que o Windows já possui recursos para o usuário customizar as cores dos elementos gráficos (alguém ainda lembra dos temas?). Forçar uma cor ou um tamanho de letra vai impedir o funcionamento destas configurações.

Ajudando o Operador a Não Errar

Uma característica das UIs é que elas precisam estar preparadas para erros do operador. É inadmissível que informações sejam processadas sem um mínimo de consistência e particularmente vexaminoso quando um erro fatal ocorre mais adiante porque uma informação inválida ou inconsistente foi aceita.

Um mínimo que deve ser feito é fazer uma consistência dos dados e a apresentação de uma mensagem clara sobre qual foi o erro detectado e quais as principais alternativas para corrigí-lo.

Melhor ainda é examinar alternativas que o impeçam de errar. Retomando o exemplo anterior, uma lista de valores válidos impede os erros que podem ser cometidos na digitação em um campo livre.

Pequenos Cuidados

Um olhar atento a detalhes é importante. Reveja bem os textos utilizados, garanta que não escapou um erro de digitação e que os termos são consistentes entre as telas. Não se esqueça de definir atalhos e de verificar a ordem de tabulação.