Assim como sou capaz de aplaudir o triunfo de um time rival ou um show bem feito de uma banda que eu não gosto nem desgosto, acho justo falar de Steve Jobs.

Não acompanhei sua carreira, nem sei muita coisa sobre ele e seus meios, mas tenho certeza de uma coisa.

Senhor Jobs soube valorizar o que há de mais importante em seus produtos: o consumidor final. Isso é um trunfo inestimável.

Hoje em dia não há nenhum produto da apple que não seja de impecável qualidade, seja em acabamento ou experiência do usuário. Sempre disse isso aos mais chegados: não existe, simplesmente não existe concorrência para a Apple no quesito qualidade. Não importa se são caros ou se alguém diz que seus produtos realizam lavagem cerebral em seus usuários. São ótimos produtos e ouso dizer que valem seu preço. Sou usuário e fã do android e digo que o mesmo está milênios atrás do iOS em experiência do usuário.

Ainda existem muitos paradigmas de mercado a serem quebrados para que existam mais produtos com qualidade tão boa quanto as dos produtos da empresa de Jobs. Não conheço outra empresa que preze tanto pela qualidade quanto a Apple.

Ele se foi. Pra onde, vai da crença de cada um. Pra mim, o que importa é seu legado. Jobs deixou sua marca na vida de milhões de pessoas, seus produtos conquistaram o mundo por mérito. Se ele pudesse ler minhas palavras, eu deixaria a minha mensagem:

Steve Jobs,

O pior já passou. Ponha um sorriso no rosto para cada sorriso de satisfação que você causou com seus gadgets, filmes ou outras obras e terá sorrisos para toda a eternidade. Você fez diferença neste mundo.

Esta é minha humilde homenagem.

Aí veio a pergunta de Mô:

Ué, mas quando eu mando apagar alguma coisa do computador, ele não apaga?

Sim, e não!

Expliquei pra ela o por quê e achei que essa deveria ser uma dúvida frequente pra usuários e resolvi escrever esse post.

Vou tentar explicar a grosso modo como funciona a deleção de arquivos.

A Resposta

Sim, logicamente e não, fisicamente.

A Memória

Primeiro precisamos entender um pouco sobre os tipos de memória que um computador usa.

São dois: a principal (RAM) e o Disco Rígido (HD):

A Memória Principal

Um Pente de Memória

A memória principal é chamada de Random Access Memory, ou memória de acesso aleatório e é composta completamente de componentes eletrônicos, por isso é extremamente rápida, porém tem uma capacidade reduzida. É um tipo de memória volátil, ou seja, quando o computador desliga, ela perde todos os dados guardados nela. Sem ela, o computador não funciona.

O HD

Os discos magnéticos são extremamente rígidos, por isso o nome do drive.

O HD é composto basicamente de discos magnéticos que giram e um braço mecânico com uma cabeça de leitura que se desloca sobre o disco magnético.

Por ter esse componente mecânico o HD é bastante lento, comparado à memória principal (cerca de um milhão de vezes mais lento). Apesar da velocidade relativamente baixa, HDs permitem o armazenamento muito maior do que a memória principal e por isso são o principal meio de armazenamento massivo hoje em dia. O Disco Rígido é uma memória não-volátil, ou seja, quando o computador é desligado, os dados persistem.

Trilhas (A) e Setores (C)

Os discos magnéticos são divididos em Trilhas, que por sua vez são divididas em setores, de tamanho configurável. Dentro e através dos setores ficam os dados referentes aos nossos vídeos, fotos, textos, etc.

Estes dados são gravados em bytes e para ler esses dados, o Sistema Operacional precisa informar a trilha, o setor, o byte de início e o quantos bytes serão lidos, o que se traduz, por exemplo, nisso:

A03FBB410012F144, que chamamos de endereço físico e é muito mais feio que C:\Meus documentos\xxx\videoSecreto.avi, que chamamos de endereço lógico.

O Sistema operacional conversa com o disco através de uma interface que sabe traduzir o endereço lógico para o endereço físico e além disso gerencia a escrita e a leitura através de um sistema de arquivos, que define um formato para os dados no Disco Rígido (daí o termo formatar). Este formato é puramente lógico, ou seja, não muda nada na estrutura física do disco. A grosso modo, é apenas a forma como o Sistema Operacional “enxerga” os dados no disco.

Além de outras funções, o sistema de arquivos é responsável por dizer onde se pode escrever no disco.

Apagando arquivos

Adeus!

Quando apagamos um arquivo através de um comando do Sistema Operacional, o que ocorre na verdade é a deleção lógica do arquivo, ou seja, todas as referências feitas para este arquivo pelo Sistema Operacional são apagadas e o espaço ocupado por este arquivo é marcado como livre pelo sistema de arquivos.

Aí é onde reside o problema: fisicamente os dados do arquivo ainda estarão no HD até que sejam reescritos.

Se um programa qualquer acessa o disco diretamente (sem passar pelo sistema de arquivos) e usa o endereço físico do arquivo, vai conseguir ler o arquivo que você apagou (se nada foi escrito em seu lugar, obviamente).

Deleção segura

É seguro concluir, então que uma maneira segura de deletar arquivos é além de apagá-los, escrever qualquer coisa no lugar deles. Assim, se algum programa tentar procurar algo no endereço físico de um arquivo que você deletou, encontrará uma sequência aleatória de bytes. Esta técnica é chamada de data shredding.

Existem muitas ferramentas capazes de fazer isso, você pode ver algumas aqui: http://en.softonic.com/windows/safe-delete.

Apesar de bem eficiente, os dados apagados com essa técnica podem ser recuperados, usando métodos de laboratório. A não ser que esse vídeo secreto seja algo digno de wikileaks, você não precisa se preocupar com isso .

Outra maneira de evitar transtornos com ferramentas de recuperação de dados é usar criptografia no disco, pois mesmo recuperando os dados, eles estarão criptografados e se você tomou cuidado com sua chave privada, ninguém vai conseguir olhar seus segredos.

Esse não queria mesmo que assistissem o videoSecreto.avi :p

Obviamente, a maneira mais segura de apagar algum dado é destruí-lo. Se você realmente quer que ninguém veja seus dados, destrua-os. Destrua mesmo!

Pegue seu HD, dê 3 tiros, jogue ácido sulfúrico, bote no forno pré-aqucido, asse por uma hora, fatie-o em pedaços e depois jogue no fundo do oceano .

A grosso modo, informação é o resultado de processamento, manipulação e organização de dados.

No mundo corporativo, dados são coletados por Sistemas de Informação, que ajudam na execução geral e organização do negócio. A extração, transformação e análise desses dados gera informações que oferecem suporte a gestão de negócios, em especial a tomada de decisões. A empresa que tem acesso mais rápido à informação de qualidade toma decisões mais rapidamente, o que geralmente cria vantagem sobre suas concorrentes.

O processo de coleta, transformação, organização, análise e monitoramento de dados para a geração de informação útil para a gestão de negócios é chamada de Business Intelligence (BI).

Para a realização do BI, faz-se necessário uma conexão entre as áreas de Gestão Empresarial (Conhecimento do domínio do negócio) e de TI (Conhecimento técnico para criação da informação) que, em geral, são departamentos muito distintos onde o analista de negócio não possui conhecimentos técnicos para com a Tecnologia de Informação e o Profissional de TI não possui conhecimento do domínio de negócios.

Surge então a necessidade de um novo tipo de perfil de trabalho: o profissional de BI.

Já fazia tempo que eu queria voltar a escrever aqui. Mas queria escrever algo bom e boas ideias não vêm tão facilmente. Durante um papo com o @carlosfelippe, ele me fez a seguinte indagação:

Por que um profissional de BI é tão bem pago hoje em dia? Ele faz algo que já não era feita antes via queries? Ou é por estar apoiando a alta gerência e dando gráficos bonitinhos que ele passa a ser mais valorizado?

BI hoje em dia é muito valorizado. Mas por quê? A forma de apresentar dados em relatórios bonitos cheios de gráficos coloridos, do jeito que os homens de terno gostam é tão diferente de entregar uma tabela?

É.

Gráficos são mais interessantes e intuitivos por que uma das coisas que menos se presta atenção são os números. Não me importa se eu vendi 55.364 produtos no mês 3. Me importa o quão maior é a minha barrinha do mês 4 comparada à do mês 3.

Sendo menos grosseiro: o que importa para os analistas de negócio são indicadores. Eles querem ver índices de crescimento, onde estão indo bem, onde estão indo mal, onde não progridem e nada melhor que uma representação gráfica de valores para comparação visual.

Veja você mesmo: Onde é mais fácil perceber que empresa teve o maior crescimento no espaço de 12 meses?

Nesta tabela:

Ou neste Gráfico?

Viva o Google Charts API!

BI não serve apenas para responder perguntas triviais como a apresentada no gráfico, mas técnicas avançadas permitem olhar os dados de várias “ângulos” diferentes e responder questões mais complicadas, como por exemplo, por quê a Nossa empresa conseguiu se manter na frente crise entre os meses 2 e 6, mas o crescimento foi inferior ao da Empresa rival? Por quê o nossa taxa de crescimento continuou a mesma entre os meses 6 e 11 e a da Empresa rival cresceu muito mais?

Tudo bem, mas por quê o cara que faz BI ganha mais?

Um profissional de BI é a ligação entre a gerência de negócio e o departamento de TI. Precisa ser alguém que conheça muito bem o domínio da empresa e seja técnico o suficiente para gerar consultas e relatórios, geralmente complexos.

Pense no “cara de BI” como o geek de terno e gravata. E sim, ele vale mais.

Afinal, os gerentes contrataram a equipe de TI para facilitar o trabalho deles. Se o pessoal de TI não entende bem do negócio da empresa, ocorre o oposto do planejado: o trabalho é dificultado. Pra suprir esse “gap” de conhecimento entre TI e Gerência, surgem os homens do BI, que muitas vezes conhecem mais do domínio da empresa do que a própria gerência, justamente por lidar diretamente com os dados da mesma.

Em 2010/1, junto com os amigos @flavio_frow, @martins_di e o @erickzotte, fiz um texto que tem bastante conteúdo técnico e teórico sobre BI. Ficamos orgulhosos desse trabalho e vale a pena ler. Pra quem se interessou sobre essa área o artigo é uma bela introdução. Você pode baixá-lo aqui: Business Intelligence.

Tenho que agradecer ao @carlosfelippe pelo tema do post. Muito Obrigado, CFC! :p

Aguardo feedback!

Conheça seus limites

Quando você não souber o que está fazendo, não faça. Principalmente se isso envolve sérios riscos, como por exemplo mexer em ambientes de produção ativos. Pare, analise a situação, planeje e pergunte. Pergunte pra alguém mais experiente se o modo que você planejou fazer aquilo é razoável. Peça dicas sobre como realizar os passos, sugestões no planejamento, que cueca usar, whatever. Se puder fazê-lo supervisionado, nem pense duas vezes, faça.

A primeira vez que eu fui mexer em um ambiente de produção, foi justamente para configurá-lo e o expor ao mundo. Se eu fizesse alguma besteira, nenhum sistema iria cair, nem o mundo iria acabar, mas os primeiros momentos não foram bons.

A tarefa era relativamente simples, mas a ideia de que aquilo iria pro cliente e que se falhasse a responsabilidade era minha me deixou estressado. Fiquei umas duas ou três horas fazendo as tarefas iniciais. Um probleminha ali outro aqui, nada demais, porém eu já sentia um pouco de torcicolo e sentia umas dores no ombro. Parei.

O prazo não era longo, nem curto. Eu podia parar por ali pra continuar no dia seguinte. Foi a melhor coisa que eu fiz. Tomei uma coca e fui pra casa ouvindo música. Tive tempo de, no caminho, perceber que meu nervosismo era bobo. Eu sabia o que fazer e como fazer. Era a primeira vez que eu fazia aquilo. Foi um choque inicial, mas quem liga? Se alguém me incumbiu com aquela tarefa, era por que confiava em mim e em minhas habilidades para fazer aquele trabalho importante.

Na manhã seguinte, como esta era minha única tarefa, nem fui pro local de trabalho. Loguei via ssh nas máquinas e terminei relativamente rápido a tarefa.

Cansaço mental

Tem horas que simplesmente não dá pra continuar. Seja estudando ou trabalhando, quando você enfrenta um problema daqueles cabeludos, que envolve toda a filosofia da ferramenta que você usa ou que simplesmente requerem muita queimação de neurônios, você começa a ficar viciado em algumas tentativas de solução. Pelo menos eu fico. Tento uma, outra. Volto pra uma, tento a outra novamente e este processo cansa. Cansa muito.

Já houveram vezes em que eu me sentia cansado como se tivesse feito alguma atividade física pesada, apesar de ter ficado o dia inteiro na frente do computador e assistindo aula. O cansaço mental é muito pior, pois não causa aquela sensação boa que a prática de um esporte trás. Ao invés disso, deixa angústia, baixa a auto-estima e me deixa triste.

O que fazer então, quando você está há três horas encarando aquela stacktrace supimpa e suas idéias acabaram? É hora de dar uma descarga em todo o lixo que está na cabeça. Eu leio feeds de humor, vou tomar um café, comer alguma coisa… Chamo o pessoal pra ir junto e bater um papo. Esqueça aquele problema. Fale do que você fez no fim de semana passado, daquele jogo novo que saiu, etc.

Sabe aquele insights que o House tem quando está infernizando a Cuddy e resolvem o caso num piscar de olhos? Isso realmente acontece às vezes. E quando acontece, não há sensação melhor de realização. Veja bem: não disse que isso vai resolver seu problema, mas esfriar a cabeça é o primeiro passo para resolvê-lo, com certeza. Quando o negócio está feio mesmo, eu apelo pra uma noite de sono. Faz milagres. Essa é mais infalível do que a “descarga mental”. Já cansei de ir pra casa estressado com algum problema, dormir, sentar no dia seguinte e pimba! Achei a solução! De primeira mesmo e sem usar game shark !

Nada é simples

Ambiente descontraído

Não há nada melhor que trabalhar com os amigos. Fazer aquela piada sobre a dondoca horrorosa que alguém pegou no fim de semana, zoar o notebook lerdo do amigo do lado, registrar no quadro uma frase comprometedora que escapou… Enfim, rir e fazer alguém rir integra as pessoas e torna o ambiente mais agradável.

intantsfun.es aberto na aba ao lado é sempre uma promessa de boas risadas .

Trabalhar em par

Onde eu trabalho usamos eXtreme Programming. Um dos valores do XP é a programação em par. Por experiência própria, eu digo que não existe modo mais produtivo de programar. A quantidade de erros bobos diminui absurdamente e a troca de experiências é fantástica. Não existe modo melhor de aprender e ensinar a programar como programando em par.

Acompanhar Listas de desenvolvimento/usuários/commits

Eu tinha muito medo de olhar o código de ferramentas que eu uso. Medo bobo, de achar que não estou num nível bom para entender como os frameworks funcionam. Foi a coisa mais ingênua da minha vida. Certo dia, eu estava com dificuldades na integração do Seam com o Drools 5 e queria saber a quantas andava a integração no desenvolvimento. Assinei a lista de desenvolvimento do Seam e perguntei se havia algum pra integração ficar pronta, dando alguns exemplos de funcionalidades que me seriam úteis. Calhou de que algumas funcionalidades que eu falei nem terem sido pensadas por eles e as idéias acabaram sendo adotadas, dizendo que as implementariam.

Assinei então a lista de commits do Seam, pra acompanhar o desenvolvimento das features que sugeri. E comecei a ler os códigos que recebia por email dos commits e pra minha surpresa, eram claros como água de nascente. Comecei a ter mais “coragem” pra olhar os códigos e acabei tendo um aprendizado enorme sobre a ferramenta através do seu código.

Acho esse medo até natural para alguém que começou a programar agora, mas quanto mais cedo esse medo for superado, melhor será para seu aprendizado.

Listas de desenvolvimento/usuários também são uma ótima maneira de se informar sobre bugs, features novas e mudanças quaisquer no projeto que você participa/usa.

É isso. Existem outros tópicos, certamente, mas estes ficam pra um próximo post .

O problema é que muita gente nem se dá ao trabalho de ler o que está escrito alí. Vê aquele monte de caracteres intimidadores no terminal e acha que é algo sério demais para sua cabeça processar. Se você se encontrar numa situação dessas, não se desespere e corra pro fórum/lista mais próximo. Respire fundo. Pense que poderia ser pior: Seu programa sai do nada, sem dizer nada, do mesmo jeito de quando sua namorada fica calada, com aquela cara de bolada e você pergunta “O que foi, amor” e recebe um convincente “Nada!”. Não ia dar nem pra correr pra algum lugar. Imagine um post numa lista:

Subject: U R G E N T E!!!! AJUDA POR FAVOR!!!
Gente, tava usando meu programa maneiro aqui aí quando eu cliquei no botão XPTO ele saiu! Alguem sabe o que é?

Meio dificil de responder, convenhamos. Mas o Java não te deixa na mão. Seu programa falha, mas a stack trace está lá, pra te apontar exatamente onde ocorreu o erro fatal. Isso facilita a vida do desenvolvedor e do noob, que vai correr atrás de alguém pra ajudar.

Agora vamos lá! Noob que é noob não quer mais ser noob. Faca nos dentes e vamos tentar aprender a ler Stack Traces.

Considere a seguinte classe:

package br.stacktraces.exemplo;

public class Exemplo {
 public static void main(String[] args) {
   Exemplo ex = new Exemplo();

   ex.foo();
 }

 public void foo() {
   bar();
 }

 public void bar() {
   throw new RuntimeException("OMG! StackTraces!");
 }
}

Se rodarmos o main, teremos o seguinte output:

Exception in thread "main" java.lang.RuntimeException: OMG! StackTraces!
 at br.stacktraces.exemplo.Exemplo.bar(Exemplo.java:15)
 at br.stacktraces.exemplo.Exemplo.foo(Exemplo.java:11)
 at br.stacktraces.exemplo.Exemplo.main(Exemplo.java:7)

Agora vamos lá, como nosso velho amigo Jack: por partes.

Exception in thread "main" java.lang.RuntimeException: OMG! StackTraces!

A sintaxe é: Exception in thread “<Nome da thread>” <Nome da exceção>: <Mensagem da exceção>

• Nome da thread: se você usa multithreading no seu programa, isso te ajuda a descobrir em qual thread ocorreu a exceção.
• Tipo da Exceção: a classe que representa a exceção. Geralmente é um nome curto que especifica o tipo do problema, como NumberFormatException e FileNotFoundException.
• Mensagem da Exceção: geralmente uma explicação mais específica do problema.

at br.stacktraces.exemplo.Exemplo.bar(Exemplo.java:15)
at br.stacktraces.exemplo.Exemplo.foo(Exemplo.java:11)
at br.stacktraces.exemplo.Exemplo.main(Exemplo.java:7)

A sintaxe é: at <Nome completo do método>(<Arquivo fonte>:<linha>)

• Nome completo do método: nome completo é a concatenação dos nomes do pacote, da classe e do método.
• Arquivo fonte: o arquivo no qual se encontra o código do método em questão.
• Linha: a linha na qual o ocorreu o erro.

Agora vamos aprender a ler esse bagulho. O nome Stack não é a toa. Se você notar, o texto que contém os “at” forma uma pilha de chamadas, ou seja, é todo o caminho das chamadas de métodos que seu programa fez até a exceção ser lançada.

No topo, temos a linha onde a exceção foi lançada:

throw new RuntimeException("OMG! StackTraces!");

Logo abaixo, a linha em que chamamos o método que lançou a exceção:

bar();

E assim vai até o método main, que é onde ocorre a chamada que desencadeia a exceção:

ex.foo();

Ler esta Stack Trace é fácil. Ela só indica métodos que nós mesmos escrevemos. E quando ela faz referências a métodos que não escrevemos e nem sabíamos que existiam?

Considere o próximo exemplo:

public class Exemplo {
 public static void main(String[] args) {
   Exemplo ex = new Exemplo();

   ex.getNumeroUm();
 }

 public Number getNumeroUm() {
   return new Integer("um");
 }

}

Com o output:

Exception in thread "main" java.lang.NumberFormatException: For input string: "um"
 at java.lang.NumberFormatException.forInputString(Unknown Source)
 at java.lang.Integer.parseInt(Unknown Source)
 at java.lang.Integer.<init>(Unknown Source)
 at br.stacktraces.exemplo.Exemplo.getNumeroUm(Exemplo.java:19)
 at br.stacktraces.exemplo.Exemplo.main(Exemplo.java:7)

Vejamos o que mudou na Stack Trace do exemplo anterior:

Exception in thread "main" java.lang.NumberFormatException: For input string: "um"

• Tipo da Exceção: java.lang.NumberFormatException. Opa! Agora já sabemos que é uma exceção de formato de número.
• Mensagem da Exceção: For input string: “um”. Parece que o Java não sabe criar números a partir de Strings por extenso.

Agora já temos noção de sobre o que se trata o erro. Vamos descobrir onde ele está e consertá-lo:

at java.lang.NumberFormatException.forInputString(Unknown Source)

O método que lançou a exceção se chama forInputString. Não fomos nós que escrevemos e não temos o código fonte dele, mas sabemos que é um método java.lang, então o problema não deve ser alí. O que fazer agora? Vamos para a linha seguinte:

at java.lang.Integer.parseInt(Unknown Source)

Não fomos felizes desta vez. Próxima linha:

at java.lang.Integer.<init>(Unknown Source)

Outro java.lang… Próxima:

at br.stacktraces.exemplo.Exemplo.getNumeroUm(Exemplo.java:19)

Opa! Esse é meu! Vamos olhar:

return new Integer("um");

É, acho que o java não cria números com Strings por extenso…

Pronto! Achamos nosso problema e agora podemos consertá-lo. Graças à quem? À mensageira demoníaca, dona Stack Trace.

Agora falta mostrar apenas mais um componente da famigerada StackTrace: o caused by.

Este é bem simples, como os outros. Quando uma exceção é lançada por causa de outra exceção, o caused by aparece. Aproveitando o último exemplo, considere a seguinte modificação ao método getNumeroUm():

public Number getNumeroUm() {
 try {
   return new Integer("um");
 } catch (NumberFormatException nfe) {
   throw new RuntimeException("Deu ruim!", nfe);
 }
}

Que nos gera o output:

Exception in thread "main" java.lang.RuntimeException: Deu ruim!
 at br.stacktraces.exemplo.Exemplo.getNumeroUm(Exemplo.java:22)
 at br.stacktraces.exemplo.Exemplo.main(Exemplo.java:7)
Caused by: java.lang.NumberFormatException: For input string: "um"
 at java.lang.NumberFormatException.forInputString(Unknown Source)
 at java.lang.Integer.parseInt(Unknown Source)
 at java.lang.Integer.<init>(Unknown Source)
 at br.stacktraces.exemplo.Exemplo.getNumeroUm(Exemplo.java:20)

Agora repare que nossa RuntimeException não apenas diz que “Deu ruim!”, mas também nos indica que “Deu ruim!” por causa de uma outra exceção: a NumberFormatException.

Caused by’s são comuns em exceções lançadas por frameworks, ou métodos que encapsulam outras tarefas. Imagine que o nosso getNumeroUm() fizesse parte de um framework de uma determinada aplicação e dado o erro de formato de número, precisássemos também lançar uma exceção proprietária, para notificar a aplicação que houve um erro interno. O caused by seria uma informação mais “underground” sobre o problema ocorrido e facilitaria a vida do estagiário que tentaria resolver o problema.

Espero que agora a nossa amiga Stack Trace deixe de ser uma mensageira de satã e passe a ser sua companheira na hora de corrigir erros no seu código. Tenha em mente as seguintes dicas:

• É muito, mas muito provável mesmo que alguém já teve o mesmo problema que você e tenha buscado ajuda. Google é seu amigo. Pesquise bastante antes de procurar ajuda. A informação que você procura pode ser dificil, mas lendo casos semelhantes, mesmo que não resolvam especificamente o seu problema, agregam conhecimento.

• Quando a Stack Trace for muito cabeluda, do tipo de dezenas ou centenas de linhas, treine seu olho para procurar nomes de pacotes que você criou, como o dos exemplos: br.stacktraces. Assim você pode passar o olho rápido perto dos “at” até encontrar um nome familiar e começar a investigar dali.

• Stack Traces genéricas. Essas são um pesadelo. São aquelas que são tão úteis quanto “java.lang.RuntimeException: Deu ruim!”. Na dificuldade de debugar alguma dessas, considere utilizar uma ferramenta de debug. O eclipse tem uma ótima e é muito facil de usar.

• Uma possibilidade pouco provável, mas vale nota. Se você usa algum framework em desenvolvimento, já tentou de tudo pra consertar seu código e o erro persiste, considere baixar o código do framework (se disponível) e dê uma olhada. Ja presenciei casos de horas e horas perdidas por bug no framework.

• Quando ao desenvolver uma aplicação houver necessidade de lançar uma exceção, procure bastante uma exceção que especifique a classe do problema, se não achar ou tiver preguiça, crie uma e seja absolutamente claro no texto da mensagem.

Lembre-se: StackTraces estão aí pra ajudar. Ficar assustado no início é perfeitamente normal, mas coragem e esforço pra lê-las pagam. Depois de um curto tempo você não será mais o cara que pergunta, mas o cara que responde .

Quarta-feira de cinzas com cara de domingo. Tomei banho e, sem fome, fui olhar meus emails. Um email de propaganda, outro que me motivou a escrever este texto. Começou assim:

Ontem teve jogo do Milan contra o Manchester United, pelas oitavas de final da Champions League. Não sou fã de futebol há muito tempo, mas é suficiente pra acompanhar o campeonato italiano, pois torço pelo Milan. Meu time italiano anda mal das pernas, por motivos técnicos, julgo eu. Então, satisfeito com o jogo e insatisfeito com o resultado, resolvi escrever sobre o jogo e postar no google buzz. Pensei que ninguém ia ler, pois o texto ficou grande. Mas tive uma boa surpresa: haviam lido! E melhor 2 pessoas deixaram sua marca. Uma delas foi de um colega da faculdade/trabalho, que marcou que gostou do texto. A outra foi um comentário do meu primo: “Está na hora de vc criar um blog. =D”.

E criei .

Já fazia tempo que eu queria mesmo. Gosto de escrever, apesar de não fazê-lo frequentemente e também não me considerar muito bom no português. Sou melhor escrevendo Java ou C :p. Não tinha feito um blog antes, pois tinha medo de abandoná-lo depois de 3 textos, mas depois de ver os blogs de uns colegas, principalmente o 2papos, que tem 2 textos com espaço de um ano, perdi o medo.

Agora eu fico pensando num tema. Sobre o quê que eu vou escrever? Sei lá. Java, desenvolvimento de aplicações web usando algum framework opensource da vida, configurando servidor de aplicações, modelagens de alguns projetos que eu comecei, pra ver se alguem se interessa e continua, Linux, jogos, futebol, que manjo pouco, enfim… Só esta lista já valia um post completo.

Uma coisa engraçada é que eu li o comentário do meu primo e abri logo a página do wordpress pra criar um blog, mas exitei. Comecei a procurar sobre Home Office e acabei perdendo o foco, até que a empregada pediu pra varrer o quarto e eu saí. Pensei em almoçar logo, mas estava sem fome. Aí decidi tomar foco e escrever o primeiro post.

Um benefício por criar o blog, eu já encontrei: me ajudar a focar em alguma coisa, pois eu sou mestre de começar algo maneiro e largar no meio do caminho por distrações, o que só me faz ser pouco produtivo em casa. Farei um post sobre uns projetos que comecei e larguei.

Outro benefício que enxergo é, de fato, aumentar minha produtividade: Escrever é aprender. Pra não dar bobeira é preciso pesquisar sobre tudo que se escreve, logo, aumentando meu conhecimento sobre algo, pode me tornar mais eficiente ao fazê-lo. Posts técnicos vão requerer testes e exercícios, outros teóricos, pesquisa. Pra mim é só alegria :p.

Agora, se me dão licença, vou almoçar .