Programador Guimarães Rosa

A proposta deste texto não é discutir os padrões de codificação. Na verdade é fazer uma chacota sobre a criatividade ao dar nomes aos bois na hora de codificar.

Por que programador Guimarães Rosa? Chamo assim aquele que tem uma tremenda capacidade de criar vocábulos para os objetos, classes, propriedades e etc em um sistema.

Aquele exemplo clássico para controle transacional: transferência de valores entre contas bancárias… impraticável sem um método que permita desfazer as operações se em algum passo houver um erro, e um outro método que confirme ao final das operações que tudo está nos conformes e pode ser persistido no banco de dados a transação. Daí que alguns desenvolvedores resolvem fazer um pseudo encapsulamento de API’s e eita, que desce Guimarães Rosa, para renomear métodos passando para o tal “RollbackarTransacao()” (sim! eu já vi isso) e o “CommitarTransacao()”. Mas tudo bem…

O fato é que toda empresa tem que ter seu sistema de controle de versões do código das aplicações. ImprescindÌvel essa ferramenta por motivos que todos nós sabemos muito bem e seria redundante ficar enumerando-os. Mas é importante se ater às operações diárias com ele: “checautar” ou “checar” (“oh cara, vc checou a pasta inteira?”) a aplicação correta; sempre “updeitar” antes de “commitar” e se conflitar, o jeito é “mergear“; triste é se o cara “lockou” o arquivo… loucura!

Codificando, tem momentos que precisamos “castear” (ai!) tipos de estruturas de dados; noutros, reparar se está “sheidando” direito o objeto na tela. Mas nunca, nunca se esqueça: depois de qualquer alteração, validar e depois “comitar“. Fechado!?.

Já que em alguns momentos se confunde o sentido do Globalization dando nomes a métodos como “GetUltimoUsuario()” vejo que seria melhor algo assim: “GetBenutzerPorSeuNombre(string utilisateur)”. Usaríamos este lindo método para retornar usuários passando um nome como parâmetro. O mais bizonho é que possivelmente muitos alemães, programadores de língua inglesa, programadores de língua portuguesa, de francesa e espanhola não entenderiam o que realmente este método retornaria por uma olhada de imediato.

Apesar de tudo sabemos, nós, os caras da informática, nossa incfluência na sociedade moderna. Impondo maneiras de se trabalhar, agilizando processos e até criando novos vocábulos. Afinal de contas até os imortais da academia brasileira de letras deletam hoje em dia sem o menor pudor.

Quem sabe um dia as crianças jogando bolinha de gude não dirão: “não deixo ‘rollbackar‘” querendo dizer “não dou disvóltis”.

É tudo uma questão de popularização e facilidade na comunicação. Quantas “tuitadas” os brasileiros não dão todos os dias?

Creio que seja uma questão de facilidade na comunicação aportuguesar, justapor, e etc, muitos termos. Mas para codificar, a idéia não é bem essa.

Porém, como disse que não é meu propósito discutir padrões de codificação, fica a deixa: “gente, saladear nos nomes, não performa de jeito nenhum!” 😉

É isso aeee

ps: poxa, fazia tempo que eu não postava aqui no blog 😀 hehe jaja tsc tsc

Project Haiku

Para despertar a curiosidade:

Após 8 anos em desenvolvimento, é lançado o Release Candidate 1 do sistema operacional Haiku. Haiku é um projeto open-source que visa um sistema operacional compatível com o BeOS, da falida Be. Inc.

O primeiro pensamento que vêm a cabeça é: Por que raios precisamos de mais um sistema operacional ?

Haiku não é um clone de Unix. Por volta de 1991, muitas inovações tecnológicas estavam sendo introduzidas: sistemas multiprocessados ganhavam espaço em datacenters e processadores de 64-bit passavam a ser comercialmente viáveis, apesar de ter demorado mais 10 anos para que eles viessem ao nosso desktop. Para aproveitar essas tecnologias, a Be Inc. decidiu abandonar a velha filosofia Unix e partir para um sistema com multithreading pervasivo (o que significa que a API praticamente forçava seu programa a ser multithread)  e um aAPI C++ totalmente orientada a objeto. Uma dos grandes trunfos do BeOs era sua rápida resposta e baixíssima latência, o que trazia uma experiência completamente sem “lag” para o usuário final, não importando quantos processos estavam rodando. (Um exemplo que vi de um usuário: Em um Pentium II 400mhz, o sistema ainda era responsivo enquanto ele rodava 10 mídia players simultaneamente.)

No site do Projeto Haiku, existe  uma .iso e imagens para máquinas virtuais.  Experimentem e apoiem!

Links:

haiku-os.org/

http://www.birdhouse.org/beos/byte/29-10000ft/

5 coisas que aprendi com programação

Com o final da minha faculdade resolvi criar uma série de textos relativos a educação e TI. Trabalho com informática a 10 anos, e como fiz a faculdade tardiamente acho que consegui ver a graduação com outros olhos, e não só ela, áreas de TI que eram totalmente uma incognita para mim ganharam novos ares, novas abordagens, uma delas programação.
Não é que passei a gostar de programar, só respeito mais e percebi que me engrandeceu profissionalmente, consigo ver a aplicação da minha área de maneira mais ampla, dimensionando melhor e ajudando mais no processo no geral.

Assim listo os 5 pontos mais relevantes:

1 – Esse sistema precisa de tudo isso de infraestrutura?
Muitas vezes pela dificuldade de saber o que o cliente precisa o programador enche seu código de coisas que não usará. Quando um sistema é standalone o problema fica menos perceptivel, mas como tudo é feito pra rede isso acarreta em tráfego desnecessário. Sabendo um pouco de programação (e banco de dados) algumas bizarrices podem ser evitadas. Economia de banda, afinal provavelmente não será a única a utilizar a infra.

2 – Não deixar programadores colocarem problemas no seu colo:
Com as coisas teoricamente funcionando não é rara as vezes que problemas são associados a infra, não que não existam problemas de infra, mas a grande maioria dos problemas quando existe uma infra enxuta, no padrão, são dos sistemas. Sabendo o básico se tem mais argumentos e pode-se ajudar os programadores a acharem os problemas.

3 – Integração entre sistemas e equipamentos
Muitas vezes é necessário ter aplicações para gerenciar equipamentos, digo servidores radius, appliances, wireless switchs, etc. e sabendo programar pode-se saber pedir esse tipo de sistema e assim ter algo mais eficaz.

4 – Automatizar pequenas coisas
Rotinas de backup simples, coleta de informações em roteadores, as possibilidades são muitas. Aí linguagens script como perl e bash se mostram eficazes e nem precisam de um conhecimento aprofundado de programação.

5 – Projetar sistemas:
Não necessáriamente programar, mas desenhar a arquitetura, casos de uso, a infra, com uma visão mais abrangente.