Postgresql x Mysql: a diferença que faz uma estratégia correta

Ontem fui no Tech Talk de MySql aqui na Globo.com, que me trouxe algumas idéias interessantes e também fomentou algumas discussões. Não vou falar muito sobre o tech talk especificamente, mas sobre uma discussão paralela.

Algumas pessoas sabem da minha preferência pelo Postgres sobre o MySql. Durante a apresentação ontem o Rafael me perguntou porque tanta gente utiliza o MySql e nem tanta gente usa o Postgres. Ele me perguntou isso porque usa o Postgres em alguns projetos e não viu vantagens em utilizar o MySql em vez do Postgres.

Bom, a resposta pra isso na minha opinião vem da diferença de estratégia. Banco por banco, sou mais o Postgres, embora eu considere que em boa parte dos casos, qualquer banco atende aos requisitos. Mas porque então o MySql ganhou bem mais adoção do que o Postgres?

Na minha opinião, o fator principal que levou a isso é que o MySql já há muito tempo oferece instalador nativo para o Windows. O MySql foi lançado em 1996 e começou com suporte apenas a Linux, mas desde 1998 permite instalação nativa no Windows. O Postgres começou como um projeto acadêmico em 1986, mas em 1996 se tornou um projeto open source com participação da comunidade de software livre. Podemos ver que nesta vertente atual de desenvolvimento, ambos estão disponíveis desde 1996. Enquanto o MySql suporta nativamente o Windows desde 1998, no Postgres isso só foi ocorrer em Janeiro de 2005, com o lançamento da versão 8.0. Anteriormente o Postgres só podia ser instalado no Windows com uso do Cygwin, que está longe de ser algo prático.

Considerando os recursos que ambos os bancos ofereceram ao longo de sua história, não restam dúvidas de que o Postgres é historicamente superior tecnicamente, e na minha opinião continua sendo. Entretanto, com a enorme quantidade de desenvolvedores que só utilizavam Windows (what a shame!), o fato de poder rodar o banco de dados na mesma máquina de desenvolvimento tornou o MySql muito mais conveniente para quem precisava de um banco de dados gratuito para suas aplicações.

Quando o Postgres lançou a versão 8.0 em Janeiro de 2005, muitos desenvolvedores já utilizavam o MySql há anos, e com isso sua adoção já estava bem grande. Neste ponto podemos ver claramente a diferença que fez uma estratégia correta. O fato de ser limitado tecnicamente em comparação com o Postgres não impactou o sucesso do MySql, porque durante muitos anos ele foi simplesmente muito mais conveniente para o desenvolvedor.

Atualmente, só vejo chances do Postgres aumentar seu sucesso se for comprado por alguma grande empresa e colocado em uma pilha de produtos interessante. Eu gosto muito do banco, e nos meus projetos pessoais ele é minha opção default. Entretanto, temo que ele nunca saia da sua abrangência atual, pelos erros na estratégia. É uma pena, devido à qualidade do projeto. Mas é muito difícil qualquer mérito técnico sobreviver a uma estratégia perdedora.

Apenas uma vez

Às vezes vamos no cinema já sabendo bastante sobre um filme. Nessas vezes, provavelmente já nutrimos uma certa expectativa sobre o conteúdo do mesmo, e já temos uma idéia do que esperar.

Outras vezes vamos ver filmes sem muito compromisso. Ontem (sábado) fui ver um filme romeno, chamado “Irina Palm“, que até foi legal. Mas o melhor foi ter visto o cartaz de “Apenas uma vez” (”Once“, no título original), que fui ver hoje. Eu tinha visto apenas o cartaz, mas ele me despertou a curiosidade e então fui vê-lo hoje. Sem nenhuma expectativa prévia, e sem ter muita idéia do que iria ver.

Bom, o filme é excepcional. Excepcional e diferente. Altamente musical e cativante. Cativante de tal forma que eu já estou viciado nas músicas e não tiro o filme da cabeça. Além da satisfação pelo filme, agora tenho várias novas músicas legais pra escutar.

O filme é irlandês e nele um músico irlandês (Glen Hansard) conhece uma jovem tcheca (Marketa Irglova) e então eles começam a se conhecer e tocar música juntos. Não vou falar mais do que isso para não estragar a supresa de quem quiser assistir ao filme.

O tal músico é extremamente talentoso, e as músicas são muito legais. Depois de chegar em casa eu fui pesquisar sobre o filme e descobri que o músico e a jovem tcheca são músicos na vida real, e tocam juntos em turnê e tudo. Eles na verdade não são atores, são músicos mesmo. Todas as músicas do filme são compostas pelo Glen Hansard, e a interpretação delas no filme contagia bastante.

Eles ganharam o Oscar de Melhor Canção original este ano, e devo dizer que fiquei satisfeito em saber, pois foi muito merecido. Para quem quiser dar uma olhada, estou colocando abaixo um vídeo do filme. Altamente recomendado!!

E esta música abaixo é muito legal também

Kubuntu 8.04: primeiras impressões

Neste fim de semana eu atualizei o Linux do meu desktop em casa, instalando o Kubuntu 8.04 (Hardy Heron). Inicialmente eu instalei a versão com o KDE 4, pois já é a versão 4.0.3, e imaginei que já poderia usar tranqüilamente.

De mais chato, encontrei apenas um problema para instalar extensões do Firefox. Nenhuma extensão estava sendo instalada com sucesso, devido a um problema com o Extension Manager do Firefox. Pelo que pude ver, o problema é específico do pacote do Firefox que veio com o Kubuntu, pois ele estava configurado para utilizar um diretório de extensões incorreto. Eu consegui resolver o problema baixando o Firefox do site oficial e instalando-o por fora do gerenciador de pacotes.

O que me incomodou mais não foi nem isso, foram questões referentes ao KDE 4 em si. Pelo que pude ler depois, o pessoal do KDE não está recomendando ainda esta versão 4.0.x para os usuários em massa. Eles estão recomendando esperar pela versão 4.1.

O motivo por trás disso eu pude constatar. Diversas funcionalidades básicas de configuração que existem no KDE 3 simplesmente não foram implementadas no KDE 4 ainda. Por exemplo, eu não conseguia diminuir a fonte do relógio, e quando eu reduzi a altura da barra de tarefas do KDE, o relógio simplesmente ficou cortado no meio. Eu também não consegui criar atalhos na barra de “Quick Launch”, o que me incomodou bastante.

Um último detalhe que eu me lembro é que tanto o Dolphin como o Konqueror estavam com problemas para guardar as preferências de gerenciamento de arquivos. Eu gosto de deixar o modo de visualização de arquivos e pastas como “Lista Detalhada” e sempre ordeno a lista por tipo de arquivo. Por algum motivo que eu não cheguei a descobrir, eles não estavam salvando corretamente esta minha escolha e sempre que eu abria uma nova pasta, a exibição voltava para o formato “Ícones”, com alguma ordenação qualquer.

Depois de pouco mais de uma hora me irritando com estas limitações do KDE 4, resolvi instalar a versão do Kubuntu com o KDE 3 (3.5.9 especificamente). Esta versão já é bem melhor, totalmente estável e personalizável. Não tive absolutamente problema algum e tudo funcionou corretamente e de forma fácil, como já me acostumei em relação ao Kubuntu.

Eu recentemente usei em casa o Mepis e o PcLinuxOS, mas a verdade é que a melhor distribuição com KDE é o Kubuntu. No meu notebook eu ainda estou com o Mepis, e gosto bastante da distro. Não pretendo trocar não. Entretanto, a distribuição que mais recomendo é mesmo o Kubuntu e esta versão 8.04 está rodando redondinha aqui em casa.

Quanto ao KDE 4, embora ele seja bastante promissor, ele ainda não está adequado para a maioria dos usuários. Eu gosto bem mais do KDE do que do Gnome, e estou certo de que em breve o KDE 4 será a melhor opção disponível. Nos próximos meses, entretanto, recomendo a confiabilidade do KDE 3.5.x.

Apresentação sobre web services REST

Hoje de manhã fiz uma apresentação sobre web services REST aqui na Globo.com. Espero que o pessoal tenha gostado. Provavelmente eu farei mais apresentações sobre o assunto este ano.

Estou disponibilizando aqui os slides da apresentação, e depois vou colocar os fontes do projeto de exemplo em algum lugar, pois o WordPress não me permite fazer upload de zips.

Update: o Antônio Carlos tirou umas fotos da apresentação, estou colocando a seguir:

Grails - ótima ferramenta para alguns projetos

Toda semana eu e o Silvano discutimos vários aspectos das nossas aplicações. Como melhorar algumas delas, novos componentes que podem trazer ganhos interessantes, mudanças de arquitetura, etc. Os principais objetivos são: trazer mais qualidade para os projetos e produtividade para a equipe.

Alguns meses atrás estávamos falando com freqüência sobre frameworks web. A maioria das aplicações na Globo ainda usa Struts 1.x. O Struts 1 foi por muitos anos o framework web padrão Java. Ele trouxe muitos ganhos interessantes, comparando com o desenvolvimento usando apenas Servlets + JSP.

Um ponto “fraco” do Struts 1 é que ele não tem nenhum suporte a componentes visuais. Toda a parte visual das aplicações fica por conta dos desenvolvedores, assim como os recursos “Web 2.0″. O problema é que desenvolver esta parte visual de forma customizada em todos os projetos é muito trabalhosa, não é produtiva. Com isso surgiram inúmeros frameworks mais modernos, com suporte visual muito mais rico, trazendo boa produtividade neste aspecto.

O fato é que com esta enorme gama de opções, não temos mais um framework que se destaque de forma absoluta sobre os outros. Temos várias opções para cada projeto. Entretanto, não dá para querer abraçar o mundo, então é comum que busquemos 1 ou 2 opções que nos atendam em quase todos os casos.

Na nossa equipe nós já temos uma aplicação com JSF, que na verdade foi concebida ano passado, antes da minha mudança de equipe. Eu estou usando o Wicket em um projeto pessoal e ainda estou aprendendo o framework, ainda não o domino a ponto de usá-lo de forma produtiva. Com alguma freqüência nós discutimos sobre estes 2 frameworks, e eu ainda tenho a opinião que descrevi anteriormente.

Neste escopo das discussões sobre JSF vs Wicket, também falamos algumas vezes sobre Rails e Grails. Algumas semanas atrás eu e o Silvano começamos a estudar Grails, e fizemos pequenas aplicações de exemplo. Eu já li inteiro este livro de Grails disponível no InfoQ. Ele estava aqui na minha lista de “Livros que quero ler quando tiver tempo”, mas já o movi para a lista de livros que li

Eu estou gostando bastante do Grails, pois ele é extremamente produtivo para aplicações nas quais eu acho que ele faz sentido. Você consegue em 2 dias desenvolver aplicações que provavelmente você demoraria 1 semana ou mais com frameworks Java tradicionais. Eu ainda não o utilizei o suficiente para saber os limites de uso do mesmo. Provavelmente para projetos com requisitos mais críticos de carga e customização das interfaces, ele já não será uma opção tão boa assim. Entretanto, em aplicações internas, com carga limitada e sem grandes necessidades de customização visual, ele é perfeito.

O próximo passo para mim é tentar utilizá-lo em casos mais complexos. Estou pensando seriamente em utilizá-lo no @dvogado.com, um software para advogados que eu desenvolvo no meu tempo vago, mas que está congelado há alguns meses por falta de tempo. Quando eu conseguir um pouco mais de tempo vou tentar implementá-lo com o Grails, e acho que consigo fazer isso bem rapidamente. O Grails atenderia bem à minha proposta de distribuir um pacote completo com tudo que o usuário precisa, tornando o deployment o mais simples possível. Com o Grails eu utilizaria o Jetty + HSQL que ele traz por padrão, e precisaria adicionar apenas o JDK no pacote.

Uma discussão muito interessante também é a de Grails vs Ruby on Rails, mas isso fica para um outro post em breve

Blogueiros “comuns” conseguem ganhar dinheiro com o Google Ads?

Isto é algo que eu gostaria de saber. Recentemente eu estava conversando com o Bruno Tonetto sobre o WordPress, e aí ele me perguntou se o WordPress permite usar o Google Ads.

Atualmente o WordPress hospedado no wordpress.com não permite este recurso, mas eles dizem que futuramente isto pode ser liberado. Como eu não sou nenhum superstar e meu blog não é nenhum fenômeno de audiência, eu nunca tinha ligado muito pro Google Ads no que diz respeito ao meu blog.

Entretanto, o Bruno me passou um link bem interessante que me despertou a curiosidade sobre o assunto. Neste link o dono do site comenta que colocou o Google Ads em Fevereiro de 2005, quando seu site tinha 86000 acessos. Neste mês ele ganhou US$ 53, o que não é lá grande coisa. Já em Janeiro de 2006 os acessos do site tinham subido para 715000, e a receita dele com o Adsense subiria para US$ 4700, o que já é bem interessante.

Considerando que estes números são do começo de 2006 e este mercado evolui bem rapidamente, eu gostaria de ter uma idéia de quão interessante é o Google Ads para blogueiros “comuns”. Blogs de pessoas que não sejam superstars, e portanto tenham uma quantidade de acessos bem mais humilde que este site do link.

Eu recentemente tenho pensado em utilizar o wordpress em uma hospedagem própria, para poder mexer um pouco na estrutura do blog e poder colocar mais conteúdos também. Eu uso uma hospedagem bem interessante para projetos freelance, e ela me dá vários serviços como hospedagem php (pro WordPress e phpPgAdmin), servidores Tomcat ou JBoss, SVN/CVS, Postgresql/MySql e mais uma porção de coisas.

Utilizando o wordpress em uma hospedagem separada eu teria uma liberdade maior para mexer no que quisesse, e também poderia usar o Google Ads, se fosse o caso.

Depois de ver que com 715000 acessos em 2006 um cara ganhava US$ 4700 por mês, eu não consigo entender como o Matt Raible não usa o Google Ads no site dele, que tem cerca de 2 milhões e meio de acessos mensais.

O meu blog é bem mais humilde. Este mês ele deve fechar com pouco mais de 4000 acessos. Eu o criei em novembro do ano passado, e ele vem crescendo progressivamente, num ritmo constante, mas não muito rápido. Eu tenho a curiosidade de saber se daria para ganhar alguns trocados tendo uns 10000 acessos mensais. Acho que este é um valor normal para um blog pessoal. Claro que alguns blogs têm muito mais acessos do que isso, mas já é bem mais difícil.

Se alguém utilizar o Google Ads e souber responder a esta pergunta, por favor responda por aqui ou diretamente por e-mail, se preferir. Eu não criei meu blog pensando nisso, e definitivamente este não é um dos fatores mais importantes pra mim. Mas é legal ter uma idéia do nível que estamos em termos de propaganda na internet, e claro que se for interessante para mim eu farei uso deste recurso

Java Magazine 56

Nos próximos dias chega às bancas a edição 56 da Java Magazine. Nesta edição saem 2 artigos meus sobre Web Services REST. Como vocês podem ver pela imagem, desta vez os editores me deram a honra de ser a capa da edição

Outra honra que tive no artigo maior foi a de contar com a excelente colaboração do Alexandre Bairos. Durante nossos trabalhos em cima deste artigo pudemos discutir com todos os detalhes as várias nuances dos serviços REST, com os quais já estamos trabalhando há alguns meses e estudamos já há um bom tempo.

O artigo maior é uma continuação dos artigos das edições 54 e 55. A proposta dele é pegar o exemplo dos serviços de leilão da edição 55 e implementar uma solução utilizando serviços REST.

A abordagem deste artigo foi implementar os serviços REST de forma que ficassem nítidos os principais aspectos do desenvolvimento desta linha de serviços. Tomamos a decisão de não incluir componentes sofisticados que pudessem tirar o foco do cerne do problema. Com isto, não incluímos componentes como o Jersey e o Apache Abdera, que por sua vez devem ter artigos na revista este ano.

O artigo pequeno é no formato “Quick Update” da revista. Nele eu falo sobre os principais projetos relacionados aos serviços REST e os principais acontecimentos nestes projetos. Esta linha de web services vem evoluindo bastante, e por trás disso estão muitos projetos interessantes.

Na minha humilde opinião o artigo maior desta edição é certamente o melhor dos artigos que já escrevi para a revista e acredito que ele pode contribuir como um bom ponto de partida no assunto. Este assunto é talvez o que mais me interessa atualmente, então caso vocês tenham opiniões, comentários ou críticas a fazer, estou aqui para trocar idéias

Scrum Master x Líder Técnico: nova faceta de um fenômeno recorrente

Essa semana eu troquei umas idéias com o Bairos sobre Scrum, e após acompanhar as discussões no post do Guilherme pensei ainda mais sobre o assunto deste post.

Eu já conheci inúmeros casos de profissionais que saíram da linha de desenvolvimento para assumir papéis gerenciais. Deixam de lidar diariamente com atividades técnicas para lidar com coisas mais ligadas à organização dos projetos, definição de estratégias, planejamento, etc. Em alguns casos as pessoas de fato desejavam esta mudança de atividades. Depois de desenvolver por alguns anos algumas realmente “enjoam” de atuar com desenvolvimento e preferem abraçar o caminho da gerência. Já em outros casos esta “escolha” na verdade não é um anseio autêntico do profissional, mas uma alternativa que ele inevitavelmente adota para poder continuar crescendo na carreira, ter mais responsabilidades, mais reconhecimento e mais grana.

Com a adoção do Scrum, freqüentemente o antigo líder técnico da equipe assume o papel de Scrum Master. Pela definição da metodologia a responsabilidade principal deste papel é a de eliminar impedimentos do time, e garantir que este tenha as melhores condições possíveis de trabalho para poder produzir bem. Isto acarreta numa mudança significativa para o líder técnico. Ele vai sair das “trincheiras” para ajudar o time a chegar da melhor forma possível ao final dos sprints. Seu contato com a arquitetura e desenvolvimento dos produtos inevitavelmente vai diminuir bastante, pois isto é responsabilidade do time.

O Scrum nos trouxe uma nova faceta para o fenômeno recorrente do profissional com alta capacidade técnica que muda seu perfil de atuação para atingir maiores objetivos de carreira e finanças. Sim, porque em todos os casos que já vi o Scrum Master é superior hierarquicamente na empresa que todos os integrantes do time, com raras exceções. Sendo assim, a escolha entre fazer parte do time ou ser o Scrum Master não tem muita margem para dúvida. Assumindo que a diferença financeira entre ser um membro sênior do time e ser o Scrum Master esteja na faixa de uns 30 a 40%, raros serão os indivíduos que irão decidir-se por continuar no time, se tiverem a opção de escolher. Certamente a grande maioria dos líderes técnicos é formada por profissionais que gostam muito de software, e renovam sempre seu interesse por novos desafios técnicos. Entretanto, todo mundo gosta e precisa de dinheiro, e isto obviamente pesa muito nas decisões.

Na teoria eu sou líder de equipe da Concrete, mas como atuo em tempo integral na Globo.com, sou parte de um time de Scrum. Isto quer dizer que provavelmente se eu estivesse alocado dentro da Concrete em um projeto com Scrum, eu seria o Scrum Master. Entretanto, na Globo.com eu faço parte de um time, e atuo bravamente nas trincheiras do desenvolvimento. Considerando essa dualidade da minha situação, eu penso bastante sobre estas questões do Scrum, e o que ele representa na carreira de um profissional de software.

Eu gosto muito de produzir software, e no horizonte que se apresenta à minha frente existem inúmeros desafios técnicos que eu ainda quero enfrentar. Estou longe de querer me afastar do contato técnico intenso que tenho a oportunidade de ter atualmente. Um exemplo que me vem à cabeça é o do Joshua Bloch. Eu nem sei qual é o processo de desenvolvimento que ele usa no Google e qual é o seu cargo oficial lá. Mas sei que ele é um dos caras mais sinistros que já trabalharam com Java e a experiência que ele acumulou em vários anos de desenvolvimento deve ser um ativo extremamente valioso para o Google. Tenho certeza que ele deve ganhar muito mais que a média dos gerentes de projeto de TI nos Estados Unidos. Ele é um fora de série, e é tratado como tal. Considerando um exemplo como o dele, será que vale mais para o Google deixá-lo intimamente ligado com desenvolvimento ou colocá-lo em funções talvez mais estratégicas? Será que os profissionais de ponta de tecnologia têm realmente espaço para continuar crescendo na área técnica ou é de fato inevitável uma mudança para papéis gerenciais em troca de mais responsabilidade e mais de L’Argent?

Considere um horizonte de vários projetos interessantes e desafiadores tecnicamente pela frente para você atuar. Suponha também que você vai poder escolher entre fazer parte do time que vai entregar estes produtos ou ser o Scrum Master dos projetos. E finalmente suponha que você vai ganhar exatamente a mesma coisa se escolher atuar no time ou atuar como Scrum Master. O que você escolhe?

Certamente eu posso e talvez mude de idéia no futuro, mas com o enorme tesão técnico que eu ainda tenho e com a quantidade enorme de desafios que eu ainda quero vencer “nas trincheiras”, pelo menos durante alguns anos eu faria parte do time. Tudo bem, eu ainda sou relativamente jovem (26 anos), ainda não sou casado (mas não falta muito) e não tenho filhos. Certamente a mudança das variáveis desta equação poderia mudar muito o meu ponto de vista. Mas por enquanto, considerando as suposições que eu falei, eu seria um orgulhoso combatente nas trincheiras, e continuaria me empenhando ao máximo para entregar software “do estado da arte”. Just my 2 cents

Query strings in RESTFul web services

I said before that I don’t like query strings in RESTFul URIs. You cannot cache the results in the web server and in many cases they lead to a poor design of your URIs.

However, there are cases where query strings are useful and make sense. In the project I’m working right now, we have an asynchronous queue which several server instances consume periodically. This queue has events that must be processed, and each event belongs to a given user. Each user may have several events in the queue.

We have this queue of events that must be processed and we register them in another list when they are successfully processed. When an event is processed, he goes to the “processed” list if everything goes right or he stays in the queue if something gone wrong. In the queue we register how many times we tried to process each event.

In my team we have an application that helps us manage our infrastructure. This application does many things that we previously needed to ask to the operations team or DB team. Something very desirable is to be able to check how the queue is going without needing to check server logs or the database. So we’re adding some features in the management application to help us check the queue.

Ok, now let’s talk about the RESTful services. We’ve implemented some services that access the queue. One the of services allows us to check how many events are still in the queue with at least N tries. For example, how many events are pending with at least 1 try?

What’s the Resource here? In my opinion the resource is “Pending event”. Considering this, I would access this resource doing GET /event/pending. Ok, but doing GET /event/pending would probably give us the whole list of pending events. I want pending events with at least 1 try. How can we do that? We could do a GET /event/pending/1, and it would work. However, this URI is bad, very bad. If I didn’t know what this service was about, I’d probably say this URI returns the first pending event according to some order. Probably it would be the oldest or newest one.

So how do we form this URI? We could also have a GET /event/pending/tries/1. This would indeed be much better than the first URI, but I don’t like it either. My resource is “Pending event”. Pending events with at least 1 try are still just pending events for me. What I want is just to filter the pending events. So, I ended up using GET /event/pending?t=1. “t” in this query string stands for “tries”. I could also have used GET /event/pending?tries=1. As a matter of fact, I think supporting both is nice. It would be similar to command line options in Unix applications.

Now, let’s say I want to know the pending events of a given user. Looking at the previous URI, You might say GET /event/pending?u=123 or GET /event/pending?user=123. But in this case, I wouldn’t use query strings. The best URI in my opinion is /event/pending/user, and that would lead to GET /event/pending/user/123. What’s the difference here? I consider the “User” as a meaningful thing. It’s another resource. However, “number of tries” for me is just a filter. I don’t need to know anything about a specific try, so it’s just a filter in this case. Another similiar filter would be “Pending events created before today”. We could have another query string parameter to filter events by creation date. Something like GET /event/pending?c=03/04/2008 or GET /event/pending?creation=03/04/2008.

So, I changed my mind a little bit about query strings. They are indeed useful in some cases, such as this example. They are good to filter results. Filter by something that it’s not a resource. To decide our URIs we must always think of what’s really a resource in our application, and what’s just a filter. Such as in the world wide web, URIs identify Resources. After deciding what’s a resource and what’s just a filter, we can design our URIs much better. Meaningful URIs are among the most important things in RESTFul web services.

Scribefire

Ontem descobri o ScribeFire através do Bairos. O ScribeFire é um plugin do Firefox que oferece uma interface para publicação em blogs.
Eu não gosto do editor visual do WordPress. Ele possui uma área de escrita muito pequena, e é muito pesado. Escrever a minha página de livros nele foi horrível. Como a página é muito grande e cheia de imagens, ficava muito ruim navegar por ele.

O ScribeFire já traz uma interface de publicação bem melhor, com a caixa de texto ajustável e com todas as funcionalidades do editor do WordPress. O editor de texto traz todas as opções de formatação normalmente usadas. Dá pra preencher as categorias e tags do post, adicionar imagens e praticamente qualquer coisa que você pretenda fazer num post de blog. Eu gostei bem mais de escrever por ele e passarei a usá-lo sempre para publicar aqui no blog. Segue abaixo um screenshot da interface:

Update: Depois que escrevi este post eu vi que o WordPress atualizou a versão da sua engine nos blogs que hospeda, e meus motivos para reclamar do editor do WordPress diminuíram muito. O editor de texto nesta versão 2.5 passou a ser ajustável, e dá até pra colocar em tela cheia. Além disso a interface melhorou um pouco a usabilidade. Já consigo usar legal o editor agora, mas também gostei do Scribefire. Acho que os posts sem imagens eu vou escrever no Scribefire e os com imagens eu escrevo no WordPress, pois as opções ao inserir imagens são melhores neste.