Posts Tagged “Josh Berkus”

Quem estava no OSCON 2008 viu… O Sr. Josh Berkus desenvolvedor do PostgreSQL em luta franca com Monty Widenius fundador do MySQL. E digo mais, o Josh apanhou feio! Confira o vídeo:

Ok, a notícia é velha, mas uma coisa é verdade: os eventos de Software Livres são realmente divertidos. Bem que a gente podia fazer umas coisas assim por aqui. :-)

Tags: , , ,

Comments Nenhum comentário »

Há alguns dias divulguei na lista PGBR-DEV a chamada de trabalhos sobre os Hacker Talks. A idéia veio de algumas conversas sobre a necessidade de ter mais desenvolvedores no Brasil e ao mesmo tempo a vontade de colocar palestras mais avançadas na grade do evento. Então tivemos algumas conversas com o Josh Berkus no FISL e ele estranhou a idéia de utilizar um auditório de 340 lugares. Na verdade eu até acho que em 2009 podemos realmente ter 2 ou 3 salas menores com trilhas separadas. No entanto, nós não tínhamos idéia se teríamos um volume de palestrantes suficiente para este tipo de evento. Para a nossa felicidade o número de propostas de trabalho aumentou significativamente do ano passado para cá.

No entanto quando a chamada de trabalhos terminou, já tínhamos reservado o espaço e tudo o mais. Então conseguimos uma sala a parte com capacidade para 25 pessoas. Nesta sala haverão até 4 palestras com o objetivo específico de estimular novos desenvolvedores. Pouca gente, formato livre (1 a 3 horas) e público reduzido. Os dois palestrantes internacionais (Bruce Momjian e David Fetter) já confirmaram uma palesta de cada um nos Hacker Talks, além da palestra que realizarão no auditório. Para os Hacker Talks, os palestrantes internacionais vão poder falar sem tradutor, dando maior liberdade ao palestrante e exigindo mais da platéia.

Apesar de não ser uma novidade que atingirá diretamente a maioria dos participantes do evento, pode ser que indiretamente isto traga um impacto positivo para todos, uma vez que poderemos ter mais desenvolvedores do PostgreSQL no Brasil. Ter mais desenvolvedores brasileiros, significa a possibilidade de ter mais pessoas aptas a dar um suporte de alto nível no Brasil e um maior reconhecimento da comunidade brasileira internacionalmente. Então, se você tem a intenção de virar um Hacker PostgreSQL, esta pode ser a sua grande chance.

Por outro lado, se você já é um Hacker em PostgreSQL, esta é a oportunidade de compartilhar o seu conhecimento e ganhar novos colegas e até mesmo alguns padawans :-)

Bom, por enquanto é isso. Em breve teremos mais novidades sobre o PGCon Brasil 2008.

Tags: , , , ,

Comments Nenhum comentário »

O lançamento do Drizzle não é notícia nova mas, é realmente interessante. Ao invés de comentar o assunto, veja o que dois grandes desenvolvedores do PostgreSQL dizem sobre o assunto, o Sr. Josh Berkus e o Sr. Bruce Momjian. Vale a pena conferir o post do Guto Carvalho também.

Bom, vou lhes dizer que eu concordo com os mestres em gênero número e grau. Vejamos como a Sun vai reagir quanto a isso no caminho. Alias, o Sr. Josh Berkus escreveu sobre o Drizzle logo após anunciar sua saída do time da Sun. Ele ainda não falou para onde vai, mas já apresentou quem será o seu sucessor, o Sr. Peter Eisentraut, outro grande desenvolvedor do PostgreSQL.

Não percam os próximos capítulos desta saga que promete muitos lances curiosos no caminho. ;-)

Tags: , , , ,

Comments Nenhum comentário »

Há alguns tempos eu postei aqui sobre dois novos blogs falando sobre PostgreSQL, hoje vou comentar sobre alguns artigos que andei sapeando neste fim-de-semana sobre bancos de dados. Não são muitos, portanto eu aceito novas contribuições.

Agora só para lembrar… 15/09/2007 será o Software Freedom Day!

Tags: , , , , ,

Comments 6 comentários »

Mais um texto simples e genial do Sr. Josh Berkus (desenvolvedor do PostgreSQL). Não resisti e acabei traduzindo mais um de seus artigos…

Tradução não autorizada do texto do Sr. Josh Berkus, originalmente publicada aqui. Segue o texto traduzido:

Eu passei oito anos como consultor de banco de dados em tempo integral. Uma vez que eu estou fora deste mercado por enquanto, eu penso que deva escrever abaixo algumas lições que eu aprendi de forma difícil antes que eu esqueça de todas elas. Sinta-se a vontade para adicionar os seus próprios nos comentários.

  1. Os Dados Refletem os Negócios: me mostre um cliente com um problema crônico de banco de dado, e eu lhe mostrarei um cliente com problemas crônicos de gerenciamento.
  2. Três Coisas que Você Nunca Vai Ver:
    1. Um prazo bem generoso;
    2. Um cliente que pague muito rápido;
    3. Uma especificação precisa e completa;
  3. Aplicações de Banco de Dados são imortais: a vida útil média de uma “aplicação temporária, uma exceção” é de 4 anos e há código dos anos 60 que ainda estão rodando hoje. Sempre se planeje para a longevidade.
  4. Maus Clientes Vão Destruir o Seu Negócio: metade do seu sucesso estará na habilidade de reconhecer maus clientes e evitá-los ou encerrar seus contratos antes que eles suguem todos os seu tempo e recursos. Sempre tenha a capacidade de sair.
  5. Não Pergunte o que É Possível: a questão não é o que você pode fazer, a questão é o quanto o cliente está disposto a pagar por isso e por quanto tempo eles vão esperar.
  6. O Tempo Substitui o Dinheiro Numa Escala Logarítmica: cortando o prazo em 20% irá requerer o dobro do orçamento. Cortar o orçamento em 30% irá quadruplicar o prazo.
  7. Todas as Estimativas são Otimistas: o desenvolvimento de novas aplicações irá tomar o triplo do tempo e custará o dobro. Ou vice-versa;
  8. Três Coisas que Você Nunca Fará:
    1. Perder muito tempo na especificação e na prototipação;
    2. Escrever muita documentação;
    3. Estar concentrado na facilidade de manutenção do código;
  9. Toda Grande Aplicação de Banco de Dados Tem Ornintorrincos, que são pequenos pedaços de dados que não se enquadram em nenhuma tentativa de encaixa-los num processo de negócios bem definido. Os Ornitorrincos são ao mesmo tempo o motivo da integridade de dados perfeita ser impossível e fonte de pelo menos 40% dos problemas a serem resolvidos.
  10. A Integridade dos Dados é a Sua Própria Recompensa: cada 1% de falhas de integridade de dados irá dobrar o tempo gasto para conserta-los.
  11. O Ponto Típico da Integridade de Dados: qualquer banco de dados que contenha 20% ou mais de dados não confiáveis é inútil e irá custar menos substituí-lo a partir da sua fonte de dados do que tentar conserta-lo. Para muitas aplicações nível de falha total é mais baixo.
  12. Use o Seu Próprio Contrato, não o do cliente e tenha o seu contrato escrito por um advogado de verdade. Isto é valioso.
  13. O Processo de Escrita do Contrato É um Indicador Para o Seu Cumprimento. Se o cliente passa muito tempo criticando o contrato, então trabalhar com ele (ou ser pago por ele) será mais difícil ainda. Se o cliente insiste numa cláusula ímpar e obscura, então eles planejam exercê-la. Se você não pode sair da mesa, não pode sair da negociação.
  14. O Cliente Tem Memória Muito Pobre: não importa o que eles digam, o cliente irá se esquecer do que eles combinaram em dias, senão horas. Documente todos os pedidos e mudanças e guarde cópias.
  15. Nunca Concorde Com uma Proposta Fixa para nada onde você não tenha feito exatamente a mesma tarefa pelo menos duas vezes antes.
  16. Terceiros São Incompetentes: nunca concorde com uma proposta fixa ou baseado na entrega,para uma tarefa que mesmo que parcialmente dependa da velocidade, documentação, ou qualidade de produto de um terceiro que não esteja sob o seu controle direto. Isto significa nada de propostas fixas para transferência de dados ou consertar o código de outros, nunca.
  17. O Cliente Não Tem Gosto: nunca permita ao seu cliente escolher suas ferramentas, seus empregados ou o seu ambiente de trabalho. Ou ao menos, cobre um grande extra pelo privilégio de fazê-lo.
  18. Sempre Cobre por Reuniões, ou você passará a metade da sua vida atendendo eles.
  19. Quanto Mais Você Espera pela Refatoração, Mais Ela Demorará: mudanças de esquema na produção são particularmente mortais.
  20. Uma Caixa de Correio pela Metade é Exceção: normalmente, quando um cliente decide lhe pagar mais tarde que o normal num mês, todos os seus cliente o farão. Sempre tenha a habilidade de sobreviver pelo menos 60 dias a partir das suas economias.
Tags: , ,

Comments Nenhum comentário »