Dennis Ritchie é um pouco (ha-ha) menos conhecido que o Steve Jobs, mas merece uma página de destaque tão grande quanto Steve.

Ritchie é reconhecido por duas grandes criações, que vivem até hoje e revolucionaram a computação. A linguagem de programação C e o sistema operacional UNIX.

Vencedor do prêmio Turing em 1983 pelo seu trabalho com o UNIX. Sistema esse que continua sendo base para uma parte dos sistemas operacionais utilizados nos dias de hoje ( incluindo o MacOS do outro homenageado do mês ).

Tudo que posso dizer é que ele mudou a computação e agradecer por deixar um legado tão importante!

Valeu Ritchie! Break;

Alguns fatores que definem a qualidade da informação são: Confiabilidade, Confidencialidade, e Disponibilidade. Esse último parece ser muito simples de compreender e ainda mais simples de se confundir.

Disponibilidade é: A qualidade do que se pode fazer uso, segundo o dicionário. Ou ainda podemos enunciar disponibilidade como é utilizada por muitos estudiosos de sistemas: A probabilidade de um sistema estar funcionando corretamente e disponível para desempenhar suas funções, num dado instante de tempo t.

A disponibilidade porém não é estática, e pode variar entre sistemas e até mesmo dentro de um sistema. A queda da rede por exemplo, gera um óbvio problema de disponibilidade da informação e perturba a disponibilidade como um todo. A disponibilidade também é afetada por um outro fator que determina a qualidade da informação: Confidencialidade.

Esse fator reduz a disponibilidade em sistemas que usam amplamente interface com humanos porque afeta o sentimento das pessoas envolvidas.

Metaforizando um pouco aqui vamos analisar a disponibilidade de um sistema que será compreendido imediatamente pela metade masculina dos hipotéticos leitores (a metade feminina, se existente, por favor perdoe o exemplo). Vamos falar sobre o sanitário masculino!

O sanitário masculino possui um número N de acessos para alíviar urgências de natureza líquida, e portanto a disponibilidade teórica de N mictórios. Porém como todos os leitores hipotéticos masculinos sabem, a realidade é bem diferente dessa teoria.

A busca para reduzir os momentos constrangedores, nos leva a utilizar – mesmo que inconscientemente – o International Choice of Urinal Protocol. Os cálculos mostrados no link nos mostram que o grau máximo de disponibilidade de um sanitário com N mictórios – sem constrangimento – é 2N/3 (edit: para o caso de N=1, teremos disponibilidade de 100%, assumam N>1. Grato.).

A perda de disponibilidade do sistema de 33% não é visível no sistema até o momento em que colocamos o mesmo em uso. Somente com a interação do sistema com humanos podemos perceber os problemas na disponibilidade.

O sistema deve considerar a forma como ele será utilizado pelas pessoas, a forma como as pessoas utilizam outros sistemas, os sentimentos da pessoa ao utilizar o seu sistema. É necessário deixar a pessoa a vontade ao acessar o seu sistema, isso faz parte da disponibilidade.

Simplesmente o aumento das formas de acesso a informação, pode não permitir o aumento na disponibilidade (faça os teste com o sanitários com 5, 6 e 7 mictórios). Deve ser prioridade de quem está desenvolvendo o sistema se preocupar com a disponibilidade da informação.

E encerrando o exemplo do sanitário, fica a máxima: sempre se preocupem com a visualização da “informação” pelos seus usuários.

Não conheço um Steve Jobs além do que vi nos keynotes da Apple, e na visão que ele implantou em seus produtos.

Então vou replicar um comentário sobre sua morte de alguém que conviveu com ele e falou tudo que poderia ser dito nesse momento:

Steve Jobs was a great friend as well as a trusted advisor. His legacy will extend far beyond the products he created or the businesses he built. It will be the millions of people he inspired, the lives he changed and the culture he defined. Steve was such an ‘original,’ with a thoroughly creative, imaginative mind that defined an era. Despite all he accomplished, it feels like he was just getting started. With his passing the world has lost a rare original, Disney has lost a member of our family, and I have lost a great friend.

Bob Iger

E uma frase do próprio Jobs que completa esse post:

No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because death is very likely the single best invention of life. It is life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Steve Jobs

–

Ah, e mais uma coisa, um quadrinho sobre a sua visão: http://abstrusegoose.com/402

Adeus Steve, você vai fazer falta!

Uma lousa, com a logo do Google apagada, a equação:

x^n + y^n != z^n, n > 2

E os lendários dizeres (adaptados):

Eu tenho uma demonstração realmente maravilhosa, mas este doodle é muito pequeno para contê-la. [substitua doodle por margem e você tem a versão original.]

Pierre de Fermat faria 410 anos hoje, e seu teorema escrito nas margens de um livro ficou famoso por levar séculos até ser provado como verdadeiro (isso aconteceu em 1993).

Quem provou o último teorema de Fermat? Como foi a saga para provar tal teorema? Tudo isso está no épico

Fermat’s Enigma: The Epic Quest to Solve the World’s Greatest Mathematical Problem enquanto a matemática envolvida na prova do teorema pode ser encontrada aqui.

Quando vi o Doodle me bateu uma saudade de estudar uma matemática tão interessante e resolvi compartilhar um pouco dessa nostalgia com vocês!

Até!

Um dia de alegrias e tristezas para o programa espacial americano, já que a Endeavour vai para a sua última missão.

Para aqueles que não acompanharam o lançamento ao vivo, segue o link do Último voo da Endeavour.

Outro dia, no almoço, eu tive uma pequena epifania. Eu também tinha um garfo de churrasco, mas isso é uma outra história. Em qualquer evento, algo veio a claridade que tinha me incomodado profundamente por algum tempo.

Nos últimos anos, a indústria de software se tornou cada vez mais focada no processo e métricas como uma forma de garatir códigos de “qualidade”. Se você seguisse todas as melhores práticas agora, você faria:

• TDD completo, escrevendo seus testes antes de implementar o código.

• Requerer uma porcentagem arbitrária de código checada antes de fazer um check-in.

• Revisar o código completamente em todos os check-ins.

• Usar ferramentas como o Coverity ou Sonar para gerar números de complexidade de códigos e requerer refatoração por parte dos desenvolvedores quando o código estiver demasiadamente complexo.

Adicionalmente, se sua companhia tem bebido Tang sabor Scrum, vocês também teria que gastar seus dias com:

• Geração de cabeçalhos, histórias e tarefas.

• Limpar as histórias antes de cada sprint.

• Aturar seções de planejamento.

• Controlar seu tempo para gerar gráficos para a gerência.

Resumindo, você estará usando boa parte do seu tempo com o processo, e cada vez menos tempo realmente programando a aplicação. Eu trabalhei em algus projetos onde os casos de testes duravam duas ou três vezes mais que programar o código em si, ou onde a necessidade de marretar os testes de unidades reduziram a legibilidade do código. Eu também vi exemplos de desenvolvedores tendo que enganar as ferramentas para atingir metas de quantidades de linhas e complexidade de códigos. A recursão subsequente faz com que isso seja progressivamente pior para o programador passional que escreve um código ótimo, mas o processo mata a paixão. Programadores desinteressados escrevem códigos ruins, códigos ruins fazem com que a gerência adicione mais processos na tentativa de “fazer” com que programadores escrevam bons códigos. E isso somente piora a moral.

Agora, eu certamente não estou advogando para uma abordagem velho-oeste onde nada é testado, e os desenvolvedores programam o que querem ignorando as agendas, etc. Mas a aplicação cega de processos de melhores práticasatravés de todo o desenvolvimento está tornando o que deveria ser um processo criativo em um relatório financeiro com gráficos com um toque de prisão. Enquanto cada um destes bambolês parece bom isoladamentes (exceto talvez o Scrum…), fazer os desenvolvedores passarem por todos eles vai desmoralizar até o mais apaixonado dos geeks.

Eu não tenho a bala mágica aqui, mas as companhias precisam começar a aceitar que existe uma diferença qualitativa entre os desenvolvedores. Fazer com que todos eles usem arados de mesmo peso para garantir que nenhum deles cometa erros é prejudicial para a moral e eficiencia como um todo. Agora, isso pode soar um pouco arrogante: “Eu sou um desenvolvedor experiente, eu não preciso de nenhum desses recém-criadas práticas para fazer bom código.” Mas, por exemplo, talvez desenvolvedores júniores (ou especializados) devessem escrever testes de unidades, deixando os desenvolvedores mais calejados livres para se concentrar na real implementação da aplicação. Talvez você não precise micro-gerenciar eles com seus updates diários do VersionOne para ter certeza que eles estão comprometidos com o sprint.

Talvez uma olhadinha no código seja preferível a um processo de revisão formal.

E um segredo, se voce está dizendo que voce está praticando desenvolvimento ágil, então pratique um desenvolvimento ágil!!! Um projeto onde você decidiu antes de iniciar o ciclo do produto as características que devem ter no produto, a data em que deve ser entregue, e os recursos necessários é um projeto cascata. Usar termos como “histórias” e “sprints” apenas inserem uma casca ágil quebradiça, e é loucura pensar qualquer coisa além disso. E francamente, isso é o que levou a toda a mentalidade Scrum/Burn Down Charts, porque as equipes de desenvolvimento não tema  flexibilidade para “entregar o que está pronto, quando estiver pronto.”

A não ser que os problemas que eu estou falando sejam atacados, eu temo que o ciclo negativo processo/paixão irá continuar a dragar desenvolvedores engajados em um pântano de reuniões e jogos de métricas.

Traduzido daqui.

Como fazer o touch do seu smartphone funcionar com luvas?Utilizem pasta térmica!! Sim aquela mesma que vocês utilizou para grudar o dissipador no seu processador!

A pasta térmica aparentemente possui as mesmas características touch-friendly que os nossos dedos. Então podemos usá-la para não termos que congelar nossas mãos ao tentar acessar o twitter do seu smartphone.

A ideia parece funcional, agora, eu não testei isso mas aparentemente temos alguns contras:

• A qualidade do contato depende da quantidade que você coloca;
• Aparentemente a tela fica com um pouco de resíduo da pasta térmica, então quem não tem protetor de tela pode ter problemas.

Bom essa era a dica… Esse quick_Bit foi um oferecimento de LifeHacker e MacGyver!

fonte: http://lifehacker.com/#!5793872/make-your-gloves-touchscreen+friendly-with-a-bit-of-cpu-thermal-compound

A 50 anos a primeira pessoa foi enviada com sucesso ao espaço. O primeiro passo para o tão famoso gigante salto foi dado nesse dia.

E hoje o que aprendemos com toda essa corrida espacial que culminou com a visita do homem a lua. Que a Terra é um mísero grão de areia no espaço, e que ela é a nossa (possivelmente única) casa e que definitivamente precisamos cuidar dela.

Ela deveria ser o exemplo a ser seguido por todas as mulheres que pretendem entrar na computação, e da mesma forma que falamos de gênios da computação que motivam os homens a entrar nesse meio, precisamos exaltar mais as mulheres que fizeram história na computação.

Por que ela é importante? Jean Bartik foi, junto com um time que contava com outras mulheres, uma das primeiras programadoras do ENIAC. Trabalhou também com o ENIAC e com o BINAC.

Pessoas da computação! Quais outros gênios estão esquecidos no passado?

Por isso batizei os Quick_bit[n] (nome pode ser alterado se quiserem!)

Os Quick_bit`s são pequenas informações como notícias de jornais, revistas, blogs + a opinião resumida. Estou me permitindo escapar um pouco do assunto “computação” nessa primeira vez pois o tema foi muito relevante, e muito comentado em todos os lugares.

–

Quick_bit[0] (PILOTO):

http://comentarios.folha.com.br/comentarios?comment=163138&site=folhaonline&skin=folhaonline

Os comentários da folha mostram como as pessoas entendem de energia nuclear, e como reagem a tal situação. Atentem para as comparações do tipo: “Podem multiplicar Tchernobyl por 4″. Isso é o povo, essas pessoas não estudaram quase nada sobre energia para saber do que estão comentando, ou o que estão falando, estão apenas reagindo ao medo gerado pela situação.

Mas o que dizer dos cientistas que argumentam contra a energia nuclear, o que dizer sobre seus pontos, seus dados…

http://www.guardian.co.uk/commentisfree/2011/apr/05/anti-nuclear-lobby-misled-world

Li hoje esse artigo no Guardian, que comenta sobre a desinformação, e a falta de veracidade nos dados que circundam as notícias sobre desastres nucleares.

O autor comenta que números de desastres antigos como os de Tchernobyl são alterados e manipulados para se adaptar ao discurso anti-nuclear, e que muito do que se é dito sobre os acidentes e principalmente sobre os efeitos na saúde não é baseado em fatos.

Acho que é responsabilidade de quem for comentar sobre esses acidentes, procurar se informar sobre cada uma das fontes de informações usadas, para garantir que a informação passada seja a mais correta possível. E cabe a nós pessoas que estudaram (apesar de não termos estudado especificamente o assunto) duvidar, e expor abertamente nossas dúvidas quanto a alegações extraordinárias, e demandar provas para todas essas alegações.

E citando Carl Sagan, lembrar sempre que: “Alegações extraordinárias, demandam provas extraordinárias”.