Fragmental

para poder indicar este artigo para ainda mais gente.

As you can see from the graph, there is a certain point at which a developer starts learning more about the domain and not learning much, if anything, new technically. For many developers this may not be an issue, but for other developers this can result in a loss of interest in the company, the product, or their job as a whole.

A developer may be seeking to improve their skills, and not care as much about domain specific knowledge. If that is the case, this is the point at which a developer can become dissatisfied with his job and look on to bigger and better horizons.

No javaSoft:

J2EE Team Leader - SP

A XXX procura um J2EE Team Leader com as seguintes características: Ele gera uma equipe de 4 desenvolvedores Java. Ele é responsavel pelo respeito dos prazos, custos e qualidade dos desenvolvimentos. Ele é reconhecido pelas qualidades de liderança e é conhecido como um ótimo motivador. Ele tem uma experiência comprovada com metodologias de desenvolvimento de softwares (RUP), modelagem de casos de uso e desenvolvimento de test cases. Conhecimentos de alto nivel do UML é um requisito. Parte das atividades incluirão também desenvolvimento. Por isso, ele já é um desenvolvedor J2EE experiente, com domínio do desenvolvimento multi-câmadas usando tecnologias tais Struts, EJB, Junit, etc. Estes conhecimentos serão usados para coachar a equipe sobre pontos de design, guidelines, etc. Tem 5+ anos de experiência em desenvolvimento de software. Enviar currículo, preferencialmente em inglês, junto com expectativas salariais

E no dicionário:

{verbete}

Datação
a1805 cf. BocOp

Acepções
? verbo
intransitivo
1 soltar ou fazer ouvir a sua voz (a rã ou o sapo)
Ex.: rãs e sapos coaxavam próximo
transitivo direto, bitransitivo e intransitivo
2 (1858)Derivação: sentido figurado.
grasnar ou soar como a rã ou o sapo
Ex.:

Etimologia
lat. coaxo,as,ávi,átum,áre ‘coaxar’, de coax ‘voz imitativa da rã’, do gr. kóaks ‘id.’

Sinônimos
ralar, relar

Homônimos
coaxo(1ªp.s.)/ coaxo(s.m.)

…que paguem muito bem…

A critério de curiosidade, mandei um e-mail para a Locaweb (onde já hospedei alguns projetos e ficam o site do GUJ, Portal java e RioJUG) e Infolink (onde tenho o domínio fragmental.com.br) perguntando sobre a disponibilidade do Ruby on Rails.

Tudo começou porque estava conversando com um amigo recém-promovido a gerente de uma agência web, e estava pensando em sugerir para ele o rails. Eu sugeri o Mentawai, mas conheço bem o tipo de negócio de uma agência deste tipo e existem muitos projetos compostos apenas de “gerenciadores de locadora”. Neste caso uma linguagem de script é melhor, mas usar ASP clássico, para mim, é fora de cogitação, e usar PHP ou CGI me parece algo retrô demais.

Semrpe que alguém fala em produtividade ao jsutificar uma arquitetura fedorenta utilizando JSPs ou Servlets/Actions com regras de negócio e acessando um SGBD, eu me indago se esta pessoa acredita que só existe Java no mundo.

Bem, a Infolink ainda não respondeu, mas a locaweb mandou um e-mail:

Boa tarde,

Disponibilizamos nas hospedagens em platafoma Linux o Ruby.
Para mais informações sobre os componentes e linguagens suportadas nos
servidores pedimos que acesse o endereço
http://site.locaweb.com.br/assinaturas/planos_de_hospedagem.asp

Apesar da página em questão não mencionar o Ruby (a página que menciona é a http://site.locaweb.com.br/assinaturas/caracteristicas.asp ), parece que sim.

A Locaweb é conhecida por seu suporte técnico ruim e pela droga que é ter um contexto de testes e um de produção que só é reiniciado se você implorar, mas se você for paciente acaba dando certo na maioria das vezes.

Como a Infolink suporta Python, não acho que deva ter problemas. O suporte deles é bom e disponibilizam um shell SSH para você (todo provedor deveria fazer isso!).

O TaQ disponibilizou um excelente tutorial de Ruby em portugues, que tal dar uma olhada no rails agora?

Ataulizado (28/07 15:31):
Resposta da Infolink:

Prezado Philip,

Desculpe-nos a demora na resposta. O ambiente ruby não era padrão em nossa
hospedagem. A partir de hoje o ambiente está disponível em nossa hospedagem
a partir de nosso plano premium.

Atenciosamente,

Comercial
Roberto Ribeiro

Pra variar, o Joel fala pela voz dos oprimidos engenheiros de software: Hitting the High Notes deve ser lido. Agora. Não tô brincando.

Minhas ferias acabam na prática em oito minutos (23:52 hs).

Eu e Tatiana acabamos de voltar de Lumiar, uma cidadezinha fantástica com um website horrível. Fica antes de Friburgo. Ficamos hospedados na simpática Pousada Pierro, recomendadissima pelo ambiente calmo, rio de aguas limpidas e principalmente a simpatia do casal Rosana e Marcus, os proprietários, que entre uma cachacinha e outra servem pratos que você não encontra facilmente nem na cidade (truta com alcaparras, recomendadíssimo). Tinham que ser de Niterói :)

Ficar lá me fez parar e pensar sobre largar tudo e viver de fazer software pra pousada no meio do mato. Claro que a lembrança de quão longe eu estava da familia, de uma praia e de um bar com Heineken me fez desistir imediatamente, mas acho que este pensamento não vai embora completamente tão cedo, se for.

Momento Turístico acabado, vamos a um breve resumo das férias. Eu tinha muito o que fazer e não fiz quase nada. Ponto final.

Amanhã tem palestra do Sérgio Oliveira sobre o Mentawai no RIOJUG. Espero encontrar todos os (dois) leitores cariocas deste blog lá. Mais detalhes no site do JUG.

Falando no Sérgio, ele acabou publicando um artigo no Java World sobre o menta, bem legal e vale uma lida. Após a publicação, eu enviei a notícia para o theServerSide, e como sempre meteram o pau em tudo (será que o hani leu?).

Amanhã é meu útlimo dia oficial de férias, e eu ainda tenho muito o que fazer. O Conexão Java’05 já tem data (20 e 21 de Agosto) e uma grade provisória definida, a galera do GUJ e PortalJava está trabalhando muito nisso.

Um dos diferenciais do CJ vai ser o LiveForum. A idéia é trazer o mesmo clima que temos nos fóruns virtuais para o mundo real.

Falando em fórum virtual, eu tive uma idéia e psotei no GUJ outro dia. É sobre utilizar metadados para expressar estereótipos padrão da UML, dêem uma olhada. Como disse lá, mandei um e-mail ao comitê que especifica a JSR 250. Ainda não obtive resposta.

Nesses quase quinze dias eu desenvolvi uma Bloglines-fobia. Fui enrolando, enrolando e tenho mais de 7000 itens novos para ler, a preguiça tem me feito passar longe do bichinho. Acabo de dar uma olhadela, criei coragem e entrei nos blogs de java. Marquei alguns posts interessantes, podem valer comentários aqui, mas deixemos para amanhã ou depois.

Bom, depois dessa rápida atualizada, espero aparecer com posts menos chatos (eu sei que tenho prometido isso há algum tempo, uma hora eu acerto :P).

O blog do XP Rio dá a dica de um ótimo artigo por Pete McBreen. Pete é o autor do aclamado livro Software Craftmanship, que aidna não tive o prazer de ler.

No texto, o autor fala do que está acontecendo com o mercado hoje, onde todo mundoe stá dizendo “eu sou ágil”. Isso, como ele afirma, aconteceu com Orientação a Objetos, também com componentização, RAD, MVC e tantas outras coisas.

Realmente isso está acotnecendo, basta olhar em volta. Me lembra uma empresa brasileira que vende uma IDE RAD dizendo ser um “método ágil”. Também já ouvi alguns líderes de equipes de desenvolvimento falando uma série de besteiras sobre como sua metodologia é ágil.

Então, Pete dá a dica com dez lições simples para provar que algo não é ágil (tradução livre resumida com comentários adicionais meus):

10. O “Project Plan” acaba de ser divulgado, mostra o primeiro release acontecendo 18 meses depois do início do projeto.Num projeto ágil o foco é na atividade cosntante de planejar, não no plano resultante. Não adianta ter datas que não serão cumpridas.

9. O gerente de projeto fala sobre artefatos que os analistas vão produzir para os arquitetos. Modelo Cascata (Waterfall) em cheio. O próximo passo é entregar as especificações de arquitetura aos projetistas, que entregam aos programadores. Isso é tudo, menos ágil (ou bom).

8. Arquitetos e analistas afirmam orgulhosamente que não codificaram uma linha sequer no último projeto. Mostra que se pensa em codificar como atividade trivial. Isso vai totalmente contra o Agile Manifesto, que diz claramente que software funcionando tem mais valor que documentação.

7. Programadores e testadores estão no nível mais abaixo da cadeia alimentar. Como no anterior, fazendo isso torna impossível um processo ter Agilidade. Porgramadores são a alma do processo.

6. O analista cosntantemente tenta fazer os usuarios assinarem o tal documento dos requerimentos. Congelar os requisitos é o sonho dequalquer analista, ams isso não vaia cotnecer nunca, não importa que o cliente assine o documento com seu sangue. A proposta Ágil é colaborar com o cliente, não limitar suas escolhas.

5. Desenvolvedores reclamam quando uma mudança nos requisitos passa por cima do burocrático processo de controle de mudanças. Processos ágeis acolhem mudanças.

4. Você está a mais de dois meses no projeto e aidna não foi exibida nenhuma funcionalidade útil aos usuários. PowerPoint e telas mock não contam.

3. O líder do projeto considera documentação mais importante que comunicação. Fazer registros em documentos oficiais para poder rastrear o significado de qualquer mudança costuma ter como efeito uma equipe confusa sem a menro noção do que está fazendo (ou do que os outros estão fazendo). Se algo é importante para valer um documento, é importante para ser conhecido por todos.

2. Testes e verificação de qualidade não são partes integrantes e respeitáveis do processo. Ser Ágil é escrever software de qualidade, e a comprovação que um software tem qualidade é dadas de forma prática através de testes. Mesmo empresas com grandes departamentos de QA mutias vezes não elvam a sério esta etapa, deixando a verificação da qualdiade apenas como última etapa, logo antes da entrega.

   Finalmente, você finge ser ágil se em seu processo:

1. Tarefas são dadas a pessoas, que pegam seu trabalho, se isolam num lugar quieto (sua baia) e tratam aquilo como um trabalho solo. Num lugar onde as pessoas usam fones de ouvido ou se isolam para não serem perturbados por outros membros do time, você pode apostar que o líder de projeto não entende desenvolvimento colaborativo. Se não entendem o básico disto, podem ter certeza que o processo não é ágil, não importa os quadro-brancos, reuniões em pé ou programação em par.

Estou de férias do meu daily job, 15 dias, por isso estou meio longe. Sim, eu sou nerd e estou boa parte do dia no computador, ams tenho feito algumas coisas que não são ão ligadas ao meu dia a dia seja de trabalho ou projetos paralelos, então não tem muito o que postar aqui. Minha programaçõa de férias inclui muitas horas de Monty Python, comemoração de um ano de namoro, bebedeiras, Catan e outros jogos, coisa que há muito eu tenho deixado de fazer.

Ok, estou sempre no GUJ e na RioJUG.

Hoje a noite resolvi dar uma reformatada em alguns dos textos que tem por aqui. Fiz um modelo gráfico para usar, modifiquei a formatação (e alterei o texto em algumas partes) do Contratos Nulos, feedback, please!

A versão nova está aqui.
As versões antigas estão fora do ar.

Já tenho tema para um próximo textinho, vamos ver quando a vontade se junta a possibilidade :P

Continuando o papo sobre freelancers, eu tive péssima experiência como emrpeendedor (imaturidade, provavelmente), mas essa apresentação de Wil Shipley fala bem ao estilo do post. Claro que é focado no mercado americano e fala sobre o bizarro mundo dos ISV para Macintosh, mas é leitura obrigatória para uma visão diferente e algumas risadas.

Se você ver minha lista no AudioScrobbler vai ver que eu já sabia disso!

Ok ,ok, sem flames, eu sei que é exageiro, mas de que Pearl Jam é MUITO bom, disso não há qualquer dúvida :)

Dá para acreditar nisso?

Nota: são 15:18, os atentados ocorreram por volta de 8:51.

Da Webopedia:

wiki
Last modified: Friday, June 24, 2005
(n.) A collaborative Web site comprises the perpetual collective work of many authors. Similar to a blog in structure and logic, a wiki allows anyone to edit, delete or modify content that has been placed on the Web site using a browser interface, including the work of previous authors. In contrast, a blog, typically authored by an individual, does not allow visitors to change the original posted material, only add comments to the original content.

The term wiki refers to either the Web site or the software used to create the site.

Wiki wiki means “quick” in Hawaiian. The first wiki was created by Ward Cunnigham in 1995.