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.

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 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. :)

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/

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. :)

Traduzindo: Eu queria poder ler no Google Reader um feed com a vista consolidada de todas as mensagens nos fóruns aonde postei. Eu já leio em separado um outro feed, contendo apenas os novos tópicos dos fórums que assino. Mas o objetivo era poder acompanhar a discussão nos fóruns aonde eu havia postado.

O que é o Yahoo! Pipes? Bem, ele é um website aonde eu posso, visualmente, agregar feeds e criar manipulações. Os feeds são a entrada e ele gera um feed de saída. Eis o porque do nome, Pipes (“Canos”). Não apenas isso: Eu posso compor pipes e criar outros.

Eu não havia experiência prévia com o Pipes. Logo, o desafio era aprender a utilizá-lo, bem como implementar o objetivo por mim traçado. Não era um projeto de final de semana, e sim um projeto de uma noite. :)

Criando um Pipe

Embora o Pipe seja um ambiente de desenvolvimento um pouco incomum, o ponto-chave foi perceber que ele possuía, indiretamente, princípios de programação funcional. A Documentação não é muito intensiva, porém existem tutoriais de suporte, bem como é possível localizar exemplos para cada parte que eu utilizo.

Como assim, partes? Bem, O Pipe é um ambiente que se baseia na idéia de programação visual, aonde eu desenho um fluxo da informação através das partes, e os ligo através de canos. Antes disso, peço desculpas pelo tom nasal e pela voz distante: Estou gripado. Dito isto, eis um screencast demonstrando a utilização do Yahoo! Pipes para fazer a listagem das minhas últimas mensagens, filtradas por tópico, no site do guj:

A partir daí, eu posso publicar, ou apenas salvar e utilizar o pipe. Publicando, eu posso deixá-lo disponível a outros usuários, e permitir que eles ‘Clonem’ e possam criar outras variantes a partir do conceito original.

Caso você queira ver este screencast isolado (i.e., tirando todo o meu texto :]), clique aqui.

p/S: Nem sei se meus criptogramas são tão interessantes assim. Acho que vou colocá-los de greve durante um mês.

É fácil: Logue e veja a barra de opções a esquerda do seu perfil:

Ao clicar em “Edit Feeds”, adicione os feeds que você publica. Aqui, pus del.icio.us, twitter, last.fm e claro, mnemetica. Mais simples, impossível:

Qual a utilidade disso? Bem… Eu acho que é um grande passo para o Orkut tornar-se uma grande plataforma de colaboração, como hoje é o Facebook nos Estados Unidos.

Ah, você não foi apresentado ao RSS? Porque não dá uma visitada ao RSSficado?

<cobalt60> Not really. The overrall idea is to be based off the Profile being used
<cobalt60> The Real pocketserver will use it, for sure :))
<cobalt60> If you want to see the gory details, jump to pocketserver-bootstrap's pom. You'll be scared :)
<yart> hehe, just trying first to start it and see what it can do
<yart> started mnv install - junit.framework.AssertionFailedError: No tests found in org.modafocas.pocketserver.m2.PocketServerMojoTest
<cobalt60> It won't work, really
<cobalt60> just look at the pom, you'll really be scared :)
<yart> uhuhuhuhuh
<cobalt60> I told you! I told you! I told you!
<cobalt60> (mind if I blog this tiny snippet? :))
<yart> maybe not even think to try :)
<yart> Just aks later the questions about the plexus when I will have :)
<cobalt60> this pom is a rarity :)
<cobalt60> It asks antrun which in turn asks maven tasks for ant (thus embedding maven within maven), but after having another bootstrap script written by a groovy ant task :)

No meu entretenimento atual (breve a ser apresentado ao grande público – stay tuned!), um detalhe me chamou a atenção: O quanto realmente perdemos de espaço, em aplicações java. E o quanto ainda temos que aprender (a despeito de inúmeras soluções de gerência integrada de artefatos e dependências encontradas por aí).

Ok, antes disso, um prólogo: Parte da idéia do meu projeto é demonstrar a viabilidade técnica do que eu chamo de aplicações pervasivas. Sabe aquele programinha útil que você sempre mantém no seu pendrive ou CD? Então, isto é um nicho interessantíssimo.

Na maioria absoluta dos casos, as aplicações que empacotam tem uma característica de executáveis desktop. E porque não aplicações web? Bem, isto envolve a necessidade de pensar sobre as seguintes coisas:

• Aonde persistir os dados? No disco rígido, na mídia móvel, em rede, ou em lugar algum?
• Como integrar os zilhões de dependências de uma pilha Web necessita, de forma portável? Isto é, como consigo empacotar o servidor, seus logs, sua área de comunicação inter-processo, e seus módulos nativos para outras linguagens?
• Além disso, será que cabe neste espaço disponível?

Com relação aos isso, decidi basear a solução nas seguintes premissas

• Uso de um bom container genérico de componentes, permitindo a inclusão e a exclusão de features através de componentes;

Assim, com este container, todos os aspectos ficam gerenciáveis a partir de descritores. Uma nova necessidade, um novo componente. E assim a solução se ajusta.

Que tipos de abstrações são necessárias? As principais são: Serviços de Persistência (RDBMS, FileSystem, Configuração, Propriedades), Serviços de Conectividade (SSH, HTTP, SMTP), e Serviços de Localização e Publicação de Recursos (LiveTribe, Bonjour, Container), Logging, Cache, entre outros. Em suma: Tudo aquilo que, em um ambiente de servidor, é tido como de facto, fica sujeito a questionamentos. Como gosto e questionar, acho que a abordagem é válida.

A partir deste container, permitir que os diversos aspectos (storage, logging, IPC, JNI) sejam abstraídos conforme a disponibilização destes componentes;

• Fatorar a questão do storage

Minhas propriedades podem ficar num lugar (persistido na memória, carregado via HTTP, serializado via SFTP), a base em outro (Embedded, ou via um Tunnel SSH), e a aplicação pode continuar no pendrive. Porque não, portanto, permitir que sejam criadas “Zonas” de Storage, como componentes, e disponíveis para os outros serviços? No caso particular, isto é feito através do commons-vfs.

• Gerência de Dependência (ainda indefinido – mantenha-se alerta!)

Este conceito é relativamente novo, mas popularizado por idéias como o Maven (particularmente, o Maven 2), Transit, e agora, o Ivy. Consiste em gerenciar quais classes devem ser carregadas para atender as necessidades de outra e, além disso, permitir a sua resolução dinâmica através de repositórios). Ainda não cheguei a um consenso sobre a isto.

• Empacotamento de Aplicações Java usando técnicas agressivas de otimização de espaço, ou, empacotamento de forma clássica (arquivo zip);

Já ouviu falar no Pack200? Bem, vamos a alguns números, relativos a um stub de carga/resolução de artefatos mínimo para o pocketserver:

Arquivo .jar, sem a inclusão das dependências:

-rw-r–r– 1 aldrin aldrin    8150 2006-12-15 12:05 pocketserver-bootstrap-0.0.1-SNAPSHOT.jar

Nada mal, ok? Aplicando o Jar Jar Links (não esse, mas esse), eu consigo fazer com que as dependências sejam embutidas como um subpacote do pacote principal. Resultado? Isto:

-rw-r–r– 1 aldrin aldrin 3290958 2006-12-15 12:05 pocketserver-bootstrap-0.0.1-SNAPSHOT-full.jar

3.3 Mib? Não era 8K? Era… Ok, vamos refazer o jar, porém aplicando alguma filtragem, e excluindo pacotes que serão desnecessários:

-rw-r–r– 1 aldrin aldrin 1182446 2006-12-15 12:26 pocketserver-bootstrap-standalone-0.0.1-SNAPSHOT.jar

Melhorou. Agora, pack200 para o tiro de misericórdia. Vou pular os detalhes (exige uma explicação sobre compressão lossy, teoria da informação, e compressão/arquivamento). Mas, se queres uma boa noção, ele é uma compressão lossy (estilo .jpg e .mp3, aonde a descompactação não é necessariamente fiel ao arquivo de origem), alinhado com a lógica de compressão após arquivo (i.e., “-Porque meu .tar.gz é menor que o meu .zip”):

-rw-r–r– 1 aldrin aldrin  184475 2006-12-15 12:26 pocketserver-bootstrap-0.0.1-SNAPSHOT-optimized-full.pack.gz

Mas pera, não é um jar. Sim, com razão. O pack200 foi feito para ser usado basicamente pelo JNLP (i.e., Java WebStart). Porém, com alguns ajustes (em breve – caaaalma!), meu módulo de Pack200 pra Jar para o commons-vfs deve reproduzir o efeito desejado). Sem perda de performance, um ganho de mais de 20x em relação ao primeiro jar completo.

E aí fica a dúvida? Será que estamos preparados para isso?

The standard suggested recipe relies upon group maintenance. I didn’t like for a single reason: POSIX ACL seems to be more suitable for managing file permissions (without the need to manage umask, perhaps having to constantly checking fixing file permissions, and don’t forget newgrp)

In a nutshell, you need to:

• Setup subversion and have mastery in svnadmin, schemas, and fsfs repositories;
• Master ACL enabling
• Having a working svnserve / apache2 / ssh setup;

All you need is to enable your repository for being maintained for the different user ids. Suppose your repository (I’ll refer to it as $REPOS) will be accessed from the following users:

• aldrin
• www-data

This one is a quick ACL-enabled solution I’ve come up with. After some troubleshooting, it looks ok:

for user in “” “aldrin” “www-data” ; do \
  for type in “u” “d” ; do
    find $REPOS -type d | xargs -i_ \
      setfacl -m $type:$user:rwx _
  done
  find $REPOS -type f | xargs -i_ \
    setfacl -m u:$user:rwx _
done

What does it mean?

For Each File, You Set Properties, so:

• Its owner keeps its original property;
• Users “aldrin” and “www-data” are granted full access to each file;
• For each directory, you set defaults, to the above two statements are also true for each new file you create

Well, it works. I’m just publishing this recipe in order to have it as a personal finding/report.

Ok, it worked, but I’d like to remove all this ACL thingie..

Just reset your properties:

find . | xargs -i_ setfacl -b _

Como postar um comentário na nova Internet brasileira do senador Eduardo Azeredo (PSDB-MG).

Breve, num país ditatorial de terceiro mundo mais próximo de você.

Porém, enquanto eu explicava a idéia, buscando enrolar persuadir, objetivos, e tudo o mais, ocorreu um momento engraçado: eu tinha que convencer que disponha de recursos (principalmente tempo e disposição) pra entregá-lo no dia 30. Após a pergunta, ocorre uma falta de luz.

Como é uma burgofaculdade noveau-riche e não um refúgio de alunos do DCE a serem jubilados, ligaram o gerador, e a luz voltou. Enfim, como convenci? Basta ter a frase certa:

“- A luz faltou antes deu dizer, mas o que eu ia dizer é: Eu quero que dê um blecaute aqui se eu, por um acaso, eu estiver mentindo pra mim mesmo e dissesse que eu não tinha condições de concluí-lo.”

Acho que convenci. Até aí, tudo bem. Volto pra casa (a pé, porque a burgofaculdade é pra burga, mas infelizmente, eu não sou. Ok, não vou mentir, o fato é que moro a um quarteirão de distância). A luz havia faltado pra todo o quarteirão, e meus pais me esperavam na varanda (no primeiro andar). Contei a história do térreo, meus pais riram, e eu emendei: “-Agora quer ver só? Que a luz volte quando eu entrar em casa.”

Bem, ela tinha voltado antes: O que caiu foi só a fase da iluminação pública. Duh.

Fiquei sem palavras ao ver a integração do Orkut com o GoogleTalk (que já estava *BEM* integrado ao gmail). O mais sensacional é saber que suas mensagens de away podem surgir no seu perfil. Só descobri ao voltar depois do almoço (ocasião rara, visto que me alimento de luz, mas necessária, visto que ando passando pouco tempo me bronzeando na lâmpada fluorescente), quando eu uso este motivo especial.