Quando eu comecei usando computadores, foi numa época que a maioria de vocês jamais ouviram falar: A Reserva de Mercado. Na prática, significava pagar dez vezes por algo que já chegava obsoleto. De lá pra cá, muita coisa mudou: Apenas pagamos o iPod mais caro do mundo (não precisam comentar, prezados macfags). Mas o fato é que, a exceção dos produtos macfaguísticos, hoje o custo para manter um computador é mais barato que há alguns anos.

O acesso à informação mais barato criou algumas variáveis interessantes. Há 8 anos, eu hospedar um repositório particular de código-fonte distribuído na internet virtualmente me exigiria a configuração de um servidor virtual, um VPS (exigiu – eis porque eu hospedo isso na linode).

Extrapolando mais: Há quinze anos, eu provavelmente necessitaria fazer colocation em um data center.

Hoje eu pago cinco dólares – apenas para manter restrito, pois gratuitamente eu possuo mais oferta.

Isto é algo que está alinhando para outros aspectos – Nuvens, como EC2 e o AppEngine, efetivamente barateiam. Quanto custa – monetariamente falando –, criar um domínio e hospedá-lo é uma fração do quanto custava há alguns anos.

O que não irá baratear? Mão de obra. Cada vez mais cara, cada vez mais especializada, cada vez mais difícil de formar. Logo, há risco em toda contratação em TI – é uma aposta, afinal de contas. E uma laranja podre pode cagar um projeto. Logo, você, que quer entrar no mercado, deve reduzir e eliminar os riscos na sua contratação.

Porque falo isso? Porque quando comecei em TI, era mais complicado manter um portfolio e currículo, e a minha etapa de ‘profissionalização’ demorou alguns anos e foi meio tortuosa. Embora hoje eu não necessite tanto, os meus próprios repositórios de fonte acima mencionados já me ajudaram em várias situações, tanto no trabalho quanto na faculdade e, principalmente, para arranjar trabalho.

É sério: A maneira mais fácil que você tem de dar um curto-circuito em uma entrevista de emprego é mostrar código-fonte seu e comentá-lo. Mais do que isso, você mostra ser orientado a problemas e auto-disciplinado, quando você devota seu tempo a projetos pessoais.

O código sequer precisa ser bom – isto, na verdade, é gancho para que outras pessoas possam participar e conhecer. É, de certa forma, um ótimo caminho para estabelecer networking.

Uma única observação: Certifique-se que sua propriedade intelectual não infringe a dos outros – e, principalmente, entenda sobre licenças e saiba defender a sua e identificar outras licenças open-source adequadas para outros projetos – como o dos seus empregadores, por exemplo.

Então, prezado amigo, eis um segredo dourado, que eu não costumo citar: Crie um projeto. Qualquer projeto. O importante é você ter um horizonte atingível e, acima de tudo, dedicação para mantê-lo. Use um google code ou github, agregue colegaboladores, e – porque não? – publique o mesmo fonte online, bem como coloque o site no ar.

Por mais simples que seja, você tem um projeto – e um bom assunto para a sua próxima entrevista de emprego. Ou, quem sabe, o seu próximo empreendimento.

Moral da história? Eu *queria* poder ter feito tudo isso há 15 anos. Sim, é uma inveja branca da geração atual.

Adoro o Jing, e até me dou bem com o Wave. Porque não botar os dois?

Infelizmente, não há widgets que permita fazer tal atividade diretamente. Felizmente, existe um recurso alternativo (leia-se: Gambi): Você pode embutir um Gadget de texto artibrário HTML colocando o código de embedding do screencast.com.

Segue o passo a passo:

• Suba o seu vídeo no Jing. Obtenha o código de embedding e guarde em algum lugar;
• Na wave em questão, insira um gadget por URL, utilizando o URL deste widget (no caso, é este URL)
• Edite o Gadget e cole o código de embedding
• ???
• Lucro!

Só pra ser ainda mais redundante, eis o link para o vídeo demonstrando como foi feito (não estou embutindo aqui em nome da formatação e a coluna. Tenho respeito aos meus 6 leitores).

Caso você tenha notado algo diferente na hora de colar: Bem, eu sou um fã incondicional do ditto, que mantém um histórico da minha área de transferência.

Um mea culpa público: O Ellipsis, como meus últimos PCs, realmente merecia um descritivo neste blog. Bem, este post é um work-in-progress – como praticamente tudo aqui, é uma tentativa de compensar.

Mas antes, o motivo: Ellipsis estava morrendo, o storage e a performance estava ruim, e eu tava com o cartão de crédito no stand center. Pra complicar, meu desktop principal (x64, lembra?) morreu, cortesia São Pedro. Mesmo com o mac, e com virtualização e emulação, eu ainda precisava de um Windows.

Então agora temos o Alpha One, que é um Acer Aspire One de 12 polegadas. Compare contra o meu caderno e o Ellipsis (que era de 7 polegadas):

Isto foi meio impromptu e gradualmente irei documentá-lo. Por hora, ele é repleto de pontos fortes:

• As Especificações são generosas:

• 250 GB de Disco
• Intel Atom Z520 @ 1.33 (embora nominal seja 1.6 GHz)
• 2GiB de RAM

• É uma segunda geração de netbooks, já com o Atom e um chipset novo pensado na plataforma;
• A Acer colocou seu expertise:

• SignalUp, que realmente otimiza o sinal com uma antena wireless
• O teclado tem uma disposição excelente com teclas maiores
• O monitor é 1366×768, LED, 12 polegadas – IMENSO para um Netbook

Os principais problemas que julguei foram:

• A opção pelo Vista Home Basic
• O Chipset de vídeo (GMA 500) ainda não está maduro – dói que só rodar no Vista e, surpreendentemente, no Jaunty fica ainda pior. Felizmente, no Windows 7, ele funciona excelente
• A parte externa do case brilha demais. Pode parecer mimimi, mas eu moro numa cidade quente e é fácil estragar a vista com gordura :)

Qual o veredito atual? Bem, se quiser comprar, o preço para um novo esta ótimo e acho que muito nego que não sabe configurar um PC irá oferecê-lo em segunda-mão. Logo, compre um até Janeiro/Fevereiro, que acho que é quando irão melhorar os drivers e o suporte do Ubuntu Linux.

Grato. Faxineiro-mor deste weblog.

Hoje, porém, parte do meu dia (eletrizante, até) envolveu uma atividade boba, revelou um insight genial:

No Linux, eu precisava desenhar um diagrama de blocos. Tentei com InkScape, e funcionava, com um detalhe: Sendo um editor de SVG, eu precisava criar 2 objetos (Retângulo e Texto), selecionar ambos, alinhar os centros e agrupá-los. Resumindo: Contraproducente.

Depois do InkScape, tentei Kivio – Que ao contrário do original, não possui um único stensil de retângulo. Game Over, K.

Tentei outro no Ubuntu: Karbon (antigamente, KIllustrator). Mesmo sintoma do Inkscape.

Procurando várias alternativas, li em algum lugar que o OpenOffice permitia.

E fez bem e consegui concluir os diagramas.

Mais tarde, refletindo com um colega de trabalho, permitimos um padrão:

• O Java surgiu como basicamente um GIF Animado;
• O NetBeans é ótimo quando o assunto se limita apenas a Swing
• JavaFX é uma segunda tentativa da Sun reaver a posição de melhor animador de GIF depois do Flash
• OpenOffice Draw me permitiu desenhar como eu queria

Em suma: A Sun faz software sério, até (Java, JXTA, OpenSolaris), mas ela queria mesmo era achar-se a Adobe. Só pode.

A pervasive elitism hovers in the background of collaborative software development: everyone secretly wants to be seen as a genius. In this talk, we discuss how to avoid this trap and gracefully exchange personal ego for personal growth and super-charged collaboration. We’ll also examine how software tools affect social behaviors, and how to successfully manage the growth of new ideas.

Moral da História: Embrace Failure. Haver-se-à retrabalhado, e evitar é impor-se um obstáculo.

Nunca havia pensado, mas é bastante recorrente no meio. E admito que parte da minha eterna capacidade de procrastinar deriva disso.

A História da Web: Relembrar é Entender

Acompanhar a Web envolve um pouco da própria natureza da tecnologia: Novas demandas, novos desafios, e a constante necessidade de manter tudo alinhado com o que já existia, oferecendo recursos que originalmente sequer foram imaginados. Basicamente, as principais tecnologias que compõem a Web, entre 1990 a 2000, surgiram da necessidade de resolver os seguintes problemas:

Agora repare esta tabela com um olhar crítico: Dentro da visão original da Web, ela buscava apenas ser um repositório online de documentos, o que basicamente envolve HTTP e HTML. Ou seja, apenas o primeiro item da lista.

Todas estas necessidades transformaram a mesma em um ambiente dinâmico de troca de informações. Os documentos não eram mais arquivos em uma pasta: Tornaram-se registros complexos em grandes bancos de dados, constantemente acessados e modificados.

A solução Java, àquiela época, eram os Servlets, que buscavam apenas a geração de conteúdo dinâmico. Ela se situa no tempo um pouco depois do conteúdo rico na linha do tempo. Era uma solução adequada? Bem, não muito, mas o Java Server Pages, em 1998, ajudou a aliviar e torná-la mais agradável.

Mas acompanhando esta corrida, perceba que surgiram requisitos implícitos: Bancos de Dados, Logs, Gerência de Concorrência, Pooling de Recursos. Performance e Elegância.

Complexidade

Esta complexidade minou inicialmente o poder do Java. As soluções saiam, mas jamais dentro de padrões aceitáveis de performance. A Lei de Moore ajudou e hoje Java está entre as plataformas mais adequadas em termos de performance, e relação custo-benefício adequadas a maioria das corporações.

Perceba a ressalva acima: Corporações. Ela ainda estava – e ainda está – inacessível a maioria dos desenvolvedores. Desenvolver em casa e publicar na web uma aplicação Java envolve um pouco de esforço em achar soluções de hospedagem, devido a natureza do negócio de hospedagem.

Em paralelo, ambientes como Perl e PHP trouxeram uma outra visão: Ambientes Interpretados, leves, com valores diferentes do que o público-alvo do java buscava. Isto gerou uma impedância entre os ambientes que até hoje persiste: A maioria dos ambientes de hospedagem é capaz de rodar Perl e PHP, mas não Java. Isto criou uma cultura e uma divisão: Programadores PHP acham Java Complexo demais, e Programadores Java consideram PHP inadequado para fazer aplicações dentro das necessidades da sua empresa.

AOP, IOC, DI e ORM: Abordando os Problemas sob outro Ponto de Vista

Estamos em 2004. Nesta época, as soluções Java já estavam sendo questionadas quanto a sua capacidade de manterem-se adequadas aos requisitos modernos. O AOP criou um novo paradigma de programação, mas o conceito de Injeção de Dependências e Inversão de Controle, popularizados pelo Spring, e o de Mapeamento Objeto-Relational (Hibernate) mostraram que desenvolver em Java era possível – apenas não estavam sendo feito de uma forma efetiva.

Em paralelo, o Struts tornava-se norma, enquanto buscava-se ao JSF a agilidade e leveza que o ASP.NET trazia.

Ruby on Rails – Uma Nova Abordagem (e Valores)

O Ruby on Rails é um divisor de águas: Com um novo jogo de valores (YAGNI, DRI), ele buscou a simplicidade e jogou outro requisito na roda: Interatividade. Muitos (bons) programadores Java, Perl, Python e PHP foram para o Ruby on Rails.

Web 2.0

Em paralelo, cunhou-se o termo “Web 2.0”. Redes, Ajax, Mashups. Novos requisitos na roda.

Recomeçando

Neste ponto, haviam 3 grandes problemas:

• Haviam basicamente 2 tribos de desenvolvedores Web: Os programadores de Scripting (PHP/Perl/Python), com ambientes interpretados, dinâmicos e leves, e os programadores Java, compilados e exigindo mais memória;
• As soluções interpretadas forneciam aplicações com grande demanda (CMS), enquanto as Java eram orientadas ao ambiente enterprise. Porém, isso não impedia que soluções de CMS open source fossem viáveis para corporações, mas o temor natural de integrar uma aplicação PHP com uma base de dados manipulada por uma aplicação Java inibia a sua adoção, resultando em vários CMS Java de uso interno – causando diariamente a reinvenção da roda nas empresas;
• Haviam outras maneiras de se fazer as coisas, e mais atrativas que em Java;

No ambiente Java, criou-se um claro conflito de valores: Como produzir mais e ao mesmo tempo, integrar com o que eu tenho?

Esta proposta foi a premissa para a IBM inaugurar o Project Zero.

O Conceito:

O Project Zero busca trazer leveza, reuso, simplicidade e agilidade para o desenvolvimento web. As seguintes premissas foram adotadas:

• O Java permite o uso de linguagens Interpretadas;
• O Ambiente Servlet/JSP é complexo, e isto causa problemas;
• O conceito dos Archives J2EE – EAR, WAR, RAR não provê a reusabilidade necessária para as aplicações, trazendo retrabalho;
• O ambiente deve ser flexível, permitindo que vários meios sejam usados para desenvolver um website;
• O Open Source é uma realidade, e não pode ser ignorado;

Desta forma, a proposta do Zero procura englobar estes fatores em uma solução onde:

• O open source seja uma realidade, e que a equipe interaja com a comunidade buscando uma solução não apenas com massa crítica, mas focada em um objetivo comum;
• Linguagens como Groovy e PHP possam integrar-se com o Java;
• O reuso de aplicações Web seja uma coisa possível
• O desenvolvimento pode ser feito a partir de um runtime pequeno (2MB), podendo ser feito pela linha de comando, IDE (Eclipse), ou até pelo Browser (AppBuilder);
• As abstrações de acesso a dados (arquivos locais e remotos, e-mail, e Web) sejam vistos como recursos REST, abstraindo a complexidade de uma forma homogênea

O Zero possui um website, com blog, forum, issue tracking, área de desenvolvimento, downloads e documentação. Tudo rodando no runtime do Zero, e mantido pela equipe do Zero.

Aplicações:

O meu tcc foi feito no Zero. Ambora me arrependa de ter tido uma abordagem mais monolítica (evitando o PHP e Groovy), comparar a sua performance (Spring + Hibernate) contra um servidor J2EE equivalente demonstrou uma performance superior. Lembra quando falei de um runtime leve? Pois então.

Outro ponto forte é integração: Vamos supor que você possui na intranet um portal MediaWiki, e gostaria de integrar a sua autenticação com algum sistema proprietário da empresa. Ou o seu blog (em WordPress) necessita de alguma integração com o seu CMS Java? Pois – mesmo sendo PHP, o Zero integra com eles de uma forma genial.

E o sMash?

Ah sim, o sMash é a versão comercial do Zero, e é disponível pela IBM. Mas a mesma é baseada no Zero e na sua comunidade.

Concluindo

Então fica o convite: Veja os links acima e julgue se a Web não precisa de um curto-circuito. :)

“-Quando Tralha é Coisa Séria!”

Nesta virada do ano, arrumobservando o meu quarto, percebi que o espaço classificava-se da seguinte maneira (classificado por importância):

• Livros e Revistas;
• CDs e DVDs;
• Cabos Antigos e Aparelhos Eletrônicos Sem Uso;
• Computadores;
• O mega-traste que vos fala;

Como destes, o último item, embora pouco importante, era apenas a razão do quarto existir, e dada a velocidade com que o espaço começava a ser tomado, decidi fazer uma organização. CDs e DVDs estão sendo ripados, e pro 2o semestre fecho um Home Server/Media Center e alguns livros serão doados (caso você tenha algum leve interesse, confira isso e aquilo).

Moral da História: O traste fica, apesar dos protestos da vizinhança.

Mas a questão das revistas bateu em alguns aspectos sentimentais:

• Quadrinhos de Valor Sentimental: Vertigo Brasileira e os Episódios da Morte e Ressureição do Super-Homem;
• Coleções
• Periódicos (que irão pro saco! Eu juro);
• Outras, aonde um artigo ou outro se salva, serão scaneadas e mantidas – prometo escrever sobre isso quando fechar a solução, mas já dei início a este processo;
• Outras revistas tem mais de 30 anos… err…

Abre Parêntese – Eu ainda não cheguei aos 30, mas ver revistas de 1978 ensinando a fazer tele-jogo me colocaram em um dilema imenso: Eu não sabia eletrônica, mas durante anos, sempre assinei e comprei revistas e livros sobre eletrônica. Como lidar com isso? Fecha Parêntese.

Em paralelo, outras constatações: Estava me formando, queria dar menos atenção a programação – Calma, é apenas uma licença sabática! – , e queria ter novas perspectivas sobre a vida. Novos passatempos, mas ainda mantendo a natureza doméstica que rege a minha vida.

A partir daí, surgiu o plano.

O Plano

O Plano era simples: Montar um Laboratório de Eletrônica e efetivamente aprender Eletrônica Básica, Digital e Microcontroladores. Estabelecer um hobby, ganhar o domínio e a prática para ler os artigos, compreender, e enfim, dar cabo na minha coleção das Revistas da Editora Saber. Um processo para tomar os próximos 2 anos, divertir-me e ganhar o conhecimento.

Existe uma infinidade de fatores que impediram isso de iniciar-se antes. Fatorei tudo e resolvi utilizar uma abordagem semi-autodidata para conduzir o meu próprio aprendizado. Motivar-me, de acordo com as minhas próprias premissas. E, principalmente, montar uma caixa de ferramentas de deixar os outros com inveja. :)

Power!!!!

E como você costuma ler neste blog, ter um projeto bem definido e exemplar :)

Semi-Autodidata?

É. Deixa eu explicar: Ser autodidata é muito valorizado pelas pessoas. Porém tem um grandissíssimo problema: Diante de fatos incompreendidos, você define que uma maneira é a única que funciona, muitas vezes sem sequer de fato compreender os aspectos que envolvem a sua percepção.

Falta. Método.

Isto te torna hábil, mas também te torna burro. Muito burro. E foi por este motivo – não prender-me a miopia do auto-aprendizado –, que me graduei em computação mesmo já possuindo experiência no mercado de trabalho. Resolvi aplicar esta visão a um hobby.

Logo, é necessário método: Experimentar sim, porém diante do obstáculo, discutir e compreender a questão, de forma iterativa.

Parte do Plano envolveu eleger “Tutores” – Pessoas com Experiência Vasta nos Assuntos, para orientar-me e ouvir meus relatos. Até agora, tem rendido muito bem.

Porque mencionei o Aprendizado de Programação? Bem, o Aprendizado de Programação, sem método, cria um rendimento baixo – é necessário você ter persistência e, principalmente, compreender abstração. Mas de qualquer forma, não obter o resultado desejado envolve um pouco da preguiça mental de não compreender o obstáculo diante de você. É o clássico “Maldito compilador! Agora este erro!” – Muitas vezes sem ler e buscar compreendê-la.

E o que você fez?

Estabelecendo Premissas:

• Safety First – Comecei comprando equipamentos e lendo orientações de segurança. Isto rendeu-me uma ida ao IT Center;
• Ferramentas são para o que o homem não domina com as mãos: Sempre que encontrava alguma dificuldade, recorria ao google para descobrir como os outros resolviam. Isto gerou algumas descobertas sobre ferramentas úteis, como as “Terceira Mão”, muito úteis para soldagem de placa, ou descascadores de fio (tentei aqueles da Western – São bons, mas tendem a quebrar fácil. A coisa terminou no da Sparkfun – É Campeão!). E pinças e alicates;
• Dicas, Dicas, Dicas: Utilizei o Instructables como uma referência. Ótimas idéias, e uma comunidade ativa na área de eletrônica. Fazer não basta. É preciso saber fazer uma forma melhor de fazer;

A partir daí, a coisa centrou-se ao redor de coletar, informar, e registrar:

• Plataformas: Na verdade, há cinco anos eu já possuia uma uma placa de desenvolvimento PIC. Decidi mantê-los, mas com menos enfoque, e direcionar-me para Arduino, dada a comunidade;
• Componentes: Tem a Tip, no Reduto. É boa, mas me deslocar pro comercio em horário comercial é uma tormenta. Fico em casa: Tentei algumas lojas online. A minha favorita absoluta chama-se Soldafria. O atendimento é ótimo, a navegabilidade é boa, e a variedade e preços são excelentes. Para outros casos extremos, recorri a Sparkfun e ao MercadoLivre;
• Circuitos: Ainda não achei projetos que me inspirassem. Por hora, estou rascunhando alguns e aprendendo sobre as partes envolvidas;
• Sites: Sim, algum. Ainda não tomei coragem para postar em algum fódum – Prometo repensar sobre isso. De qualquer forma, meu caderno de notas continua a mil;

Aonde ficamos?

Basicamente já montei alguns circuitos básicos com Arduino. O foco agora é em montar circuitos, e não em programá-los. Logo, minha experiência com o Eagle, Arduino IDE, WinAVR, Processing e MPLAB fica para outro momento. Por hora, é soldagem e construção de placas parece ser o próximo estágio. Porém, compreenda que o enfoque – macro – é aprender todas as áreas e buscar-me nelas.

Preciso fazer um curso intensivo de solda. Ainda não decidi, mas o curso do Francisco, do Kit8051, me parece bom. E tem o CuriousInventor.com tem um site útil sobre o assunto.

Lembra dos aparelhos eletrônicos acima? Estou desmontando e me livrando do que não me interessa de componentes. O resto vai pra caixa de componentes, serelepemente. :)

Agora eu consigo olhar para um esquema envolvendo microcontroladores e compreender o significado – Reconhecer o padrão. Aplicá-lo ainda está um pouco tortuoso, mas eu provavelmente irei trabalhar isso em breve.

Bem, o futuro parece claro: Montar mais circuitos, ganhar esta confiança, entender os principais circuitos envolvidos, e começar a envolver-me em outros projetos. Ah, sim: Desmontar mais circuitos, hehe.

Caso você esteja curioso, confira a minha galeria de fotos do lab no Gallery2. Caso deseje discutir e até oferecer-se como tutor em alguns projetos, fale com o nosso Serviço de Atendimento ao Cu-rioso.

Grato.

Ok, now that zero.firephp is here, its time to dissect ProjectZero itself. It was not pleasant to deal with the ivy files, so lets get started before I remember how painful it was to deal with a cheap M2 rip-off.

Java Logging 101: The History

(Skip to the next section if you already know about this)

In the end, there was System.out. And this was good.

People then started to wonder that if would be helpful to separate logging statement from application output. Thus, Unix programmers quickly rushed to System.err, already in the knowledge it was a safe harbor. So now people could enable and disable logging. And that was good as well.

However, people started to notice that when logging was on, performance was down while copious amounts of logging data were written as well. So, Java people borrowed the concept of Logging Levels and started put simple statements to test before logging.

Then, people wanted to have the ability to save output into a file. Perhaps for daemons, or perhaps just to keep a copy handy to look and compare with other. Thus, the logging flags to file output were born.

Then, Ceki Gülcü (aka “The God of Logging ”) came and thought it was a good idea to mix the hierarchy java uses in the package system, mix levels, analyze and came up with Log4J. That was excellent, and several other frameworks were made after his one.

Soon, a company with the Stock Symbol “JAVA” on NASDAQ thought it would be good to bless. What a mess (it rhymed!)… The java.util.logging package was born, and this was not good, culminating in flame wars (vi-versus-emacs-style) in Apachia, a small micronation on the internets.

The overlords at commonia, a small county within Apachia , in an attempt to restore peace and ensure Apachia’s economical growth, devised commons-logging, an ill-fated that while good in nature (trying to automagically bridge logging requests between log4j and java.util.logging), in truth created another layer of abstraction which is still useful today, but creating a third logging API which also brought some nasty classloading issues.

Ceki Gülcü left apache, and log4j 1.3 was soon left deprecated. 2.0 is said to be still in the works. Meanwhile, Ceki came back and revised the concepts between commons-logging and log4j, creating slf4j and logback, respectively, trying to narrow the gap and bring his vision back to the world. It also includes libraries to bridge java.util.logging and plug-in replacements for log4j as well as commons-logging.

In the end, we have 5 apis, all of them completely different.

Oh god… I miss System.out.

Zero

Zero uses java.util.logging. Being a good citizen of the Java World, seems fine. But if you want to use logback, its possible. In particular, download this file, unpack and keep going, as I will outline the steps required to enable logback and, as a bonus, see zero logging under Lilith, a handy logging viewer for logback.

Step #1: Declare the Dependencies

Take the enclosed ivy.xml. Merge the section outlined below into your ivy.xml:

You’re inserting the APIs required slf4j  (transitively, from jul-to-slf4j), as well as logback-classic (which also includes core). However, you’re excluding some dependencies which are not needed for logback. Change them if you need (specially janino).

Step #2: Declare the java.util.logging Bridge

Simply copy the contents from logging.properties into your project.

Step #3: Modify zero.config as you need

In particular, the /config/logging/levels setting. The one declared is set as the root appender. But the syntax is “logger” : “level”, where you put the desired logging levels.

The one declared in the file is pretty verbose, which may be undesirable. I use those settings:

/config/logging/levels += {
  "*" : "ALL",
  "zero.network" : "OFF",
  "zero.core.context.zones.UserZoneHandler" : "INFO"
}

Step #4: Logback

Declare a logback.xml file. The enclosed one should work with lilith. You can also use logback’s Eclipse Plug-In instead.

Step #5: Lilith

Open, Unpack, Run.

Step #6: The result

Here is the result, in all of its glory!

Beyond logback and java.util.logging: commons-logging and log4j

You can also declare the compatible counterparts for integrating commons-logging and log4j into the slf4j/logback combo as well. Check the slf4j web site for more information.

De certa forma, talvez isto explique o motivo do meu argumento de que eu ‘fui criado pra ser nerd’:

Família,

     Ontem o modem metido a roteador começou a despirocar de vez. Ia comprar um novo. Bem, cheguei a comprá-lo, mas descobri que o mesmo não era modem e apenas roteador. Então, surgiu o monolito albino na biblioteca. Não batam nele: não, ele não brotou do nada e a culpa é toda minha.

     Quando fiz o modem funcionar apenas como modem e deixar as funções de roteador, o mesmo ganhou mais facilidade de gerência. Embora vocês não liguem, isso vai facilitar demais o meu trabalho – embora, em casos extremos (acho que o seu é um, Anna), será necessário reconfigurar a placa de rede para endereços automáticos. Nisso o Roteador não me deu chance.

     A outra coisa legal foi que agora tem uma rede sem fio, chamada ‘Leal’. Com o nível de segurança mais f*deroso disponível. Para ingressar nesta rede, é necessário uma senha. Anotem-la:

    [senhasenhasenha removida]

    Ok. Quanto ao alcance: Criamos um “Bem” Virtual, e simulamos locais aonde o bem usaria a rede sem fio: Os seguintes locais passaram:

    * Mesa da Cozinha, sentado de frente para o Microondas e de Costas pra Geladeira;
    * Cama, do lado do poleiro do cachorro marrom cor-de-cocô
    * Sala, sentado de forma que o aparelho petralha musical (o violão) fique à sua esquerda
    * Quarto do extremo oposto, de dona desconhecida, refúgio do gato preto modelo macumba – encima da cama com 2 metros de pé direito. (Sinal Excelente, inclusive).

    Espero que fiquem felizes com isso. Dúvidas e esclarecimentos, marquem hora porque eu já tô fazendo hora extra e não tenho centro de custo pra “bilar” (do verbo ‘to bill’) vocês.

    Atenciosamente,

–
–
– Aldrin Leal, <aldrin@leal.eng.br> / http://www.leal.eng.br/mnemetica/

O que falar dele?

Bem, eu sou suspeito pra falar: O meu primeiro Series 60 foi um Nokia 7650. Sim, o primeirão. Sim, o monstro. Em geral, eu opto pelos grandes por um único fator: Eles sempre terminam no bolso da calça e até o momento, não me levaram nenhum. Aleluia.

eSeries ou nSeries?

Os eSeries são business e os nSeries são entretenimento. Este é o principal diferenciador deles.

E porque?

Porque eu gosto tanto dos Series 60 e agora, particularmente, dos eSeries? Alguns motivos:

Sugestão? Nokia eSeries. E61 ou E62 (mais barato).

• Edição Nativa de DOC, PPT e XLS;
• Leitura de Arquivos PDF e Flash;
• Zilhões de Aplicações, Java ou Nativas;
• Não tem GPS, mas pode utilizar um via Bluetooth;
• A tela é imensa (QVGA). Isso faz uma diferença enorme na hora de navegar pela Web;
• Teclado QWERTY (Ok, se você não faz questão: Todos os series 60 – exceto o primeiro, o 7650 – suportam teclados bluetooth);
• Conectividade em Exagero: Eu costumava no 6600 e no 7650 bater fotos e imediatamente fazer upload delas, usando o gallery2. SyncML é suportado, além de outros formatos de arquivos;
• Falando nisso, o browser dos Series 60 é baseado no WebKit. Além dele, Opera e Opera Mini são outras boas pedidas;
• Modo Offline: Vai pegar um avião? Desligue o chip e mande ver no telefone;
• Compatiblidade: Consegui, usando apenas um chip (no 6600), migrar. O E62 fez upload de um programa e o telefone antigo subiu todos os contatos;
• O E61i (o dobro do preço, atualmente) tem também cliente SIP, WiFi e Câmera. Compensa? Sim, compensa;

Conclusão:

Este vai ficar pelo menos mais 4 anos comigo, mas agora, eu vou poder passar mais tempo jogando e lendo livros durante os momentos de tédio.

I’ve written some notes on making JXME work, as well as making it work under Java SE as well.

Bearing in mind I’m not your best JXTA/CLDC/JSE source, feel free to take a look. Thank you. :)

Piorou quando diz que para programar não é preciso inspiração. Isso é verdade se você for um macaco que escreve código, mas para quem vai um pouco além disso, programar é muito de inspiração (além de concentração). E convenhamos que inspiração olhando apenas para IDE não é exatamente fácil de alcançar, por isso eu defendo que dispersar os pensamentos as vezes é benéfico para quem está programando.

O que eu penso? Bem, penso que superestimamos a criatividade. Semestre passado, me dediquei a repensar a maneira com a qual eu lidava com os meus processos criativos. Particularmente, produzir trabalhos pra faculdade e entregar código. Não preciso descrever toda a minha produção semestre passado, mas posso sumarizar: Foi imensa.

Mas e afinal, o que ela teve de tão milagroso ou ímpar para justificar este meu post? Método. A Criatividade em si, é paradoxal: Nada realmente é original atualmente, e tudo vem de idéias herdadas anteriormente, apenas com pequenas digressões em cima da anterior. Logo, o chave neste processo criativo, na minha opinião, está em compreender todas as variáveis envolvidas, decidir quais realmente importam, e aonde mexer, à partir de um modelo original.

Soa familiar? É exatamente este a origem dos Design Patterns. Mas não se limita a isso: Parte chave de um processo criativo envolve em constantemente aumentar o seu vocabulário de idiomas. E quanto a isto, ler códigos-fonte e aprender novas abstrações e implementações é, sem dúvida, o segredo de um código rápido, elegante, curto, e de sucesso.

Horários Ajudam: Na minha experiência, estabelecer um horário e criar disciplina ajudou, na medida que eu condicionava o cérebro a trabalhar apenas naquele momento. Eu desplugava, e era o inconsciente que me dava dicas, orientando quanto ao que seria necessário fazer. Lembre-se: Você não precisa saber o caminho aonde chegar lá (mapa / bussóla), quando você pode ter um conjunto de pontos a serem atingidos. Eis porque sempre chegamos tendo apenas a relação de pontos a serem atingidos. Cognição é a chave.

Em tempo: No meu caso do semestre passado, mapas mentais e notas (organizadas ao mesmo tempo usando o OneNote, OnFolio, WikidPad, Trac, e dokuwiki, de acordo com o contexto) foram ferramentas de um valor incalculável. Mas não esqueça: A ferramenta não é nada sem o domínio do processo. E, portanto, a disciplina. 

Eu não nego que sou fã incondicional do Eclipse em Java. A facilidade de navegar e depurar programas é, de longe, a feature que eu mais sou fanático nele. Então, seguem três screencasts, para que você possa aprender como navegar pela interface, pelo código, e como depurar:

Obs: Eu parto da premissa que você instalou o Eclipse e o JDK. :)

Parte 1: Navegando pela Interface

Parte 2: Navegando pelo Fonte

Parte 3: Debugging

Major bridges collapse every 30 years and engineers learn from these mistakes and make better and more reliable designs. When we complain that Software Development doesn’t have the same sound practices as engineering, we shouldn’t accuse just immaturity of our profession. It is one of the most intellectually complex human activities dealing with very complex systems. I just hope we will experience less and less collapsing bridges both in physical and software worlds.

A Engenharia de Software ainda tem algum caminho tortuoso a percorrer, mas nas últimas duas décadas, a risco diminuiu, sem dúvida. Mais do que isso, eis que temos um ciclo se repetindo…

Ok, hora de explicar: A Engenharia é uma profissão nova. Quando ela surgiu? Surgiu a partir do momento que percebeu-se que era importante haver responsabilidade social pelo projeto e pela implementação de… pontes. Isto data do século 19.

É uma tendência: Quanto maior for o risco em projetos de software, maior será a pressão da sociedade para ter-se responsabilidade e, principalmente, título para poder exercer isto.

Moral da História? Não basta saber e ter talento: Precisa do canudo!