O pessoal do College Humor sempre faz uns vídeos originais muito, mas muito engraçados. Mas desta vez eles se superaram, pelo menos pra mim, que tenho Matrix como o meu filme preferido.

Acho que a maioria já deve ter visto uma animação que mostra como seria a Matrix rodando no Windows. Mas desta vez, não é uma animação, mas um filme com atores reais. E o texto é muito, mas muito melhor e mais engraçado (pelo menos pra geeks!)

Momentos memoráveis:

(Procurando o plug na cabeça do ‘Neo’):
- Qual desses plugs é o USB?

- Matrix costumava rodar bem, mas ficava lenta o tempo todo. Cypher baixava muitos filmes via bittorrent…

(‘Oráculo’ acabando de tirar os biscoitos – cookies – do forno):
- Olá. Espero que tenha habilitado os cookies.

E claro, não podiam faltar o clipe mega-chato do Office, nem a tela azul da morte.

Mas a melhor frase foi essa:
- Ubuntu? Eu vou aprender Ubuntu?

HUAHAUHAUHAUHAU. GENIAL!

Fonte: Estou sem criatividade para bolar um título bacana

por Ronaldo Melo Ferraz
22 de Outubro de 2008 – 21:57

Um papo semi-presente na área de TI é a velha dúvida: generalista ou especialista? Como em essencialmente qualquer carreira em que a dicotomia é possível, há sempre uma grande questão em torno do que decidir quando se pensa em um plano para o futuro.

De um lado, especialistas justificam sua escolha em termos de melhores salários, pouco rotatividade, maior reconhecimento. Do outro lado, os generalistas justificam com maior estabilidade, menos rotina, maior amplitude de oportunidade. Sempre há uma certa tensão entre as duas versões do profissional de TI e como qualquer dicotomia, geralmente a verdade é uma coisa inteiramente diferente.

No tempo que eu tenho de carreira, o que eu observo é que a dicotomia é inteiramente falsa. Se existe o bom profissional, não há como o mesmo ser especialista ou generalista. Em um área como a nossa, onde a velocidade de transformação é enorme, medida em meses e semanas ao invés de décadas e anos, qualquer coisa que não seja a fusão dos dois conceitos é simplesmente impensável.

Ironicamente, algumas das raízes dessa separação refletem, ou talvez até tenham sua origem, na antiga disputa entre consultores e empreendedores–centrada, por sua vez, na igualmente inválida dicotomia entre engenheiros e artesãos. Como a maioria das comparações feitas para explicar o desenvolvimento de software, as analogias passam longe de explicar a realidade.

Recentemente, a popularização de frameworks e linguagens fora do mainstream como Rails/Ruby e Django/Python permitiu uma rara observação de como qualquer separação explícita geralmente é de aplicação limitada.

Um caso usual é tomar um profissional que trabalha com uma dessas tecnologias, que está tentando sair do comum em seu trabalho, seja como forma de criar uma nova carreira ou mudar sua empresa para obter uma carreira mais interessante, e por via dessa necessidade forja uma aliança entre áreas díspares como gerência, design, usabilidade, programação e outras (às vezes acumulando todas essas funções sobre si mesmo) e usar isso como exemplo de que o generalizado é melhor do que o especializado.

O mesmo erro é tomar uma disciplina como medicina e usar para ilustrar a outra proposição. Enquanto o exemplo do parágrafo anterior é um erro ao assumir que o mesmo é um exemplo de arte, o segundo é um erro em assumir que “engenharia” é uma metáfora inteiramente válida para o desenvolvimento de software.

A realidade é que, como em qualquer área, o nosso grau de proficiência é inteiramente dependente do âmbito do que estamos fazendo no momento e das circunstâncias transitórias em que esse trabalho se exprime. A especialização, nesse sentido, vem mais como força da acumulação de experiência do que de uma escolha explícita.

Um desenvolvedor é um engenheiro? Sim. É um artista? Também. Por extensão, a mesma pergunta pode ser feita para a dicotomia inicial. É um generalista? Sim. É um especialista? Também.

Isso é o que Dave Thomas fala quando explica sobre o Dreyfus model. Você vai de um lado do espectro ao outro e às vezes está em vários pontos em várias áreas. Quando isso é considerado, a dicotomia cai imediatamente por terra.

Em última instância, como a maioria das preocupações similares, o único resultado da eterna discussão é o gasto de tempo e calorias que poderiam ser postos para melhor uso em projetos mais interessantes. Na próxima vez que alguém quiser discutir isso com você, dê de ombros e ignore. Você não estará perdendo nada de valor para sua carreira futura.

Atualização: A propósito, acabaram de chamar a minha atenção que o Carlos Brando e o Fábio Akita fazem essencialmente o mesmo ponto no Rails Podcast Brasil #34 (a partir dos 37 min). Desnecessário dizer, concordo.

Fonte: Superfície Reflexiva

Michael E. Bullock, CIO USA
Publicada em 20 de novembro de 2008 às 15h23

Entenda como, a exemplo do Estado do Oregon, não transformar em pesadelo as ações para reduzir custos e melhorar a performance dos data centers.

Nenhum executivo do C-level, seja ele o CIO ou CFO, pretende investir no data center da sua própria empresa, especialmente durante períodos de turbulência econômica. Contudo, o funcionamento perfeito – ou mesmo adequado – desse tipo de ambiente não deve ser encarado como um luxo, mas, sim, como uma necessidade empresarial.

E há boas chances do data center de sua companhia não estar adequado ao que seria ideal. Na verdade, segundo um estudo realizado pela AFCOM Data Center Institute, nos Estados Unidos, 53% das empresas pretendem mudar ou expandir os atuais data center, nos próximos anos. E quase um terço das corporções vão precisar deslocar a infra-estrutura, ao passo que 45% esperam fazer grandes melhorias nas suas atuais instalações.

O que há de errado com os data centers? Eles são antigos, o que significa que não foram projetados para a alimentação de energia e a refrigeração necessárias na atualidade. Além disso, o TCO (custo total de propriedade) está aumentando de forma expressiva para a maioria das empresas; e as instalações – que há cinco anos eram as ideais -, muitas vezes, não suportam mais a crescente quantidade de dados a ser recolhidos, armazenados e processados.

Assim, as empresas que prentendem mudar, consolidar ou reformular os atuais data centers em curto e médio prazo precisam estar atentas a alguns pontos, voltados a garantir tanto a eficiência quanto a melhor relação custo-benefício. Mas, principalmente, devem ficar preocupadas em evitar os problemas mais comuns nesse tipo de operação.

O pesadelo do Oregon

Em 2004 o Estado do Oregon (Estados Unidos) lançou um projeto para consolidar os data centers de 12 agências estaduais e seus cerca de 1700 servidores em um único e novo local, baseado no padrão Tier 3. O objetivo era reduzir o número de equipamentos e sistemas operacionais – diminuindo assim hardware, licenças, gestão e custos -, conseguindo melhores acordos de nível de serviço, além de garantir uma melhor segurança de dados.

A instalação do novo ambiente foi concluída em janeiro de 2006 e envolveu US$ 20 milhões. Um ano depois, as informações de 11 agências foram migradas para o data center a um custo de US$ 43 milhões. Só com a realocação dos servidores foram gastos US$ 25 milhões, ou cerca de US$ 4 milhões por agência, um gasto espantoso.

Em julho de 2008, o Estado emitiu um relatório admitindo que, na realidade, apenas 70 dos 1700 servidores haviam sido eliminados, e novos acordos de nível de serviço foram efitivados. Além disso, a segurança do ambiente era tão pobre que o Departamento de Educação não pôde mudar para a nova instalação, devido ao risco de não cumprir as regulamentações federais em relação à privacidade. E uma outra agência do Oregon teve de retornar para seu velho data center, uma vez que o novo ambiente não tinha a alimentação de energia suficiente.

Se não bastasse, não havia uma forma de medir a economia de custos obtida com o projeto.

O que deu errado? O Oregon caiu em quase todas as armadilhas que podem representar o fracasso dos projetos para mudança e consolidação de data centers.

As cinco armadilhas e como evitá-las:

1. Planejamento inadequado: O administrador de tecnologia do Oregon admitiu que o plano de realoção dos servidores para a nova instalação foi subestimado. E subestimar a complexidade de uma mudança de data center, o tempo necessário e as competências exigidas para fazer ajustes representa mais uma regra do que uma exceção entre as companhias.

Isso é especialmente verdadeiro quando se trata de aplicativos. Nos ambientes heterogêneos, que caracterizam a maior das infra-estruturas de TI – com muitas adequações caseiras nos sistemas desenvolvidas ao longo dos anos – nenhum ferramenta de software existente pode ver todas as interdependências. Para dar conta disso, é necessário prever um tempo para recolher e gerenciar todos o conhecimentos dos profissionais que gerenciam as aplicações. Com efeito, a mudança do data center muitas vezes coloca uma sobrecarga para os departamentos de TI, os quais, na maior parte dos casos, já estão sobrecarregados.

As experiências indicam que é necessário criar uma equipe dedicada a esse planejamento das mudanças ou, ainda, as empresas precisam buscar a ajuda de profissionais externos para essa tarefa.

2. Subestimar o consumo de energia: O responsável pelo projeto no Oregan disse que a capacidade de 55 watts por square foot (pé quadrado) prevista no projeto foi muito baixa. Isso porque, calcula-se que atualmente os data centers demandam algo entre 150 a 300 watts por square foot.

Mas o caso do Oregon não é isolado, uma vez que os profissionais de TI freqüentemente subestimam os requisitos e o custo da energia do data center, uma vez que não se consideram responsáveis por esse tipo de gasto.

Um levantamento recente indica que 68% dos gestores de TI não são responsáveis pela conta de energia elétrica relacionada ao uso dos equipamentos do data center. É importante certificar-se de as áreas administrativas e de tecnologias discutam suas preocupações para que o planejamento das mudanças no data center prevejam todas as diferentes perspectivas. Esta é a única forma de prevenir que os atuais problemas fiquem ainda maiores e virem um novo centro de custos.

3. Não ter uma base confiável de comparação: Foi difícil para o Oregon determinar quanto a mudança para o novo data center representou de economia de custos. Isso porque, a base de dados fornecida sobre os antigos ambientes – fornecida por cada uma das agências – não tinha informações consistentes e os números eram subestimados ou inexistentes.

Mas é impossível melhorar aquilo que não se pode medir. Assim, antes de fazer mudanças no data center, a empresa precisa ter muito claro qual o TCO atual. Só com esses números, as corporações podem analisar quanto um projeto pode representar, efetivamente, em termos de redução de custos e melhoria de qualidade.

4. Atualizar sistemas durante as mudannças: O Oregon consolidou as suas instalações antes de o padrão de arquitetura e as questões de licenciamento terem sido resolvidas. E qualquer alteração realizada durante esse tipo de mudança adiciona riscos e complica o projeto. O que vale, especialmente, para a tendência de que os data centers invistam na consolidação e na virtualização de servidores.

Embora interessante, a virtualização é um projecto significativo em si mesmo. Assim, tentar implementá-la durante a mudança dos servidores significar fazer duas coisas bastante complexas, ao mesmo tempo, o que aumenta os riscos de fracasso.

5. Não há substituto para a experiência: Como mudar um data center é, geralmente, uma experiência única na carreira dos profissionais de TI, as empresas têm pouco conhecimento acumulado sobre a forma de conduzir bem esse projeto. Além do entendimento das mudanças, o processo exige conhecimento específicos sobre a instalação e operação desse tipo de ambiente e que é muito particular.

Dessa forma, se a corporação tem alguém com a experiência nesse tipo de projeto, deve colocá-la como líder da equipe responsável pela mudança. Ou, caso não tenha profissionais com conhecimento no assunto, deve buscar alguém no mercado para assumir essa função.

Fonte: CIO

Responsável pela movimentação de 4 milhões de informações diárias e a segurança de 645 municípios do Estado, a instituição tem a meta de garantir o controle de sua infra-estrutura de TI.

Tatiane Seoane, do COMPUTERWORLD
Publicada em 20 de novembro de 2008 às 09h00

Disposta a melhorar a eficiência da área de tecnologia da informação e assegurar o controle em relação à demanda de 4 milhões de informações diárias, a PMESP (Polícia Militar do Estado de São Paulo) aderiu a biblioteca de melhores práticas ITIL 3.0.

De acordo com o itSMF Brasil (capítulo brasileiro do fórum internacional de ITIL), este é o primeiro caso de sucesso da nova versão da biblioteca em todo o mundo.

“Alguém pode morrer se a área de TI falhar”, enfatiza o major Roberval Ferrari França, responsável pelo projeto dentro da organização. A PMESP é responsável pela segurança de 645 municípios do Estado e conta com 93 mil policiais militares pelas ruas.

Contudo, o major relembra que convencer a diretoria da PMESP sobre o projeto não foi uma tarefa fácil. “Tivemos que demonstrar em números os benefícios que poderíamos usufruir com o ITIL 3.0”, conta.

Entre as principais expectativas com o sistema de gestão estão o incremento em 10% a disponibilidade da TI e reduzir em também 10% os custos com o departamento.

A área de tecnologia do órgão possui orçamento anual de 280 milhões de reais. Além disso, 174 profissionais possuem certificado e/ou capacitação ITIL, dentro do total de 290 colaboradores da área de TI.

A infra-estrutura robusta da PMESP conta com data center, rede de comunicação de dados, rede de rádio e de telefonia e 26 sistemas desenvolvidos internamente.

Com início em dezembro do ano passado, a implementação do ITIL 3.0 foi baseada no PMBOK (Project Management Body of Knowledge – um conjunto de práticas de gerenciamento de projetos) tem conclusão prevista para o fim de 2009. “Porém, é possível que ocorra um atraso de até quatro meses”, informa o major.

De acordo com ele, o governo do Estado de São Paulo irá investir 2 bilhões de reais em segurança nos próximos anos.

Fonte: CIO

Ray Krock, fundador da rede McDonald´s, constantemente aplicava o conceito “kiss” aos seus comandados. Nada relacionado com beijo mas com “keep it simple, stupid”, ou “mantenha simples, seu idiota”.

Para desenvolvedores de software, “Kiss” é um princípio que diz respeito à simplicidade de recursos que um software disponibiliza. É a principal filosofia dos sistemas Unix. Fazer programas simples e pequenos que interajam entre si para obter tarefas maiores. Ou seja, primar pela simplicidade e facilidade e modularizar tarefas mais complexas.

Que empresas fazem exatamente o contrário?

Em Programação

KISS, Keep It Simple and Stupid (há muitas outras formas como a, mais ofensiva, “Keep It Simple, Stupid”), consiste em manter o código e a arquitetura dos programas o mais simples e intuitivo possível, de forma que qualquer um conseguiria, rapidamente, entender e manter o código. Os ganhos são muitos, quanto mais simples o código, menos lugares obscuros há para bugs bizarros se esconderem, o custo operacional com a troca de recursos em um projeto (programadores vão e vem, ninguém é insubstituível) é muito mais baixo, enfim… o principal contra seria a performance. Código otimizado, geralmente, é mais complexo que código sem qualquer otimização. Programadores não escrevem códigos para máquinas lerem, mas sim para que outros humanos leiam e mantenham, por isso, confie no seu compilador/interpretador para fazer as otimizações necessárias e mantenha o código simples e estúpido
Se você não pode confiar no seu compilador/interpretador o suficiente para isso, troque de tecnologia.

Usabilidade na Web

O que é
Fui apresentado a essa filosofia de programação há relativamente pouco tempo, enquanto estava trabalhando em um projeto e um amigo meu, ao ver a complicação que eu estava fazendo, me falou um pouco sobre o “KISS”.Vou tentar mostrar aqui sua aplicação em um site, no seu planejamento e algumas vantagens.

É um princípio utilizado na programação ou desenvolvimentos de alguns softwares (muitos consideram site um software…) que “prega” a simplicidade, partes pequenas (os chamados módulos) que se unem para resolvem um problema maior.

Para quem não entende bulhufas de inglês, o significado é mais ou menos “mantenha a coisa simples, estúpido” (amigável né?) que poderia ser comparado ao famoso “menos é sempre mais”. A idéia é bem simplória, “pra quê complicar?”, muitas vezes o jeito simples, modulado, “dividido”, é o melhor, mais fácil, mais atualizável, mais dinâmico, mais “limpo”. No fim, a relação custo/benefício é altamente positiva.

Pra que complicar?
“Mas se o jeito simples é tão bom, por que tem gente que faz do jeito complicado?”. Basicamente por pura falta de conhecimento. Vale lembrar que “simples” não é sinônimo de fácil. Às vezes é bem o contrário. Mas no final, acaba sempre “menos difícil”. Um exemplo bobo: Imagina um cara que fez um site sem CSS (sim, tem gente que faz ainda, e o pior, tem gente que tem que consertar isso… ) e quer mudar a cor da letra do site de preto (#000) para um cinza escuro (#333 por exemplo), imagina o trabalho que ele vai ter… Mas se o cara tivesse usado estruturas menores para basear as informações de cor de texto (um arquivo css), ele teria uma solução simples, onde bastaria ele mudar uma coisa que tudo fica diferente.

Ás vezes, a complicação é gerada também por uma falsa ilusão de que fazer um site sem nenhum projeto é mais fácil. Que chegar na frente do computador e criar algo bonitinho em um editor de imagem qualquer e usar o Front Page (argh!) para gerar um HTML qualquer é o jeito mais fácil (acho que peguei pesado na parte do front page…hehe).

Muitas pessoas poluem as páginas, colocam coisas demais que invés de ajudar a agregar mais informação útil, só atrapalha a navegação. Acho que isso ocorre porque há milhares de recursos diferentes para se utilizar em sites (muitos compensam mesmo serem utilizados), e as pessoas não sabem escolher o que utilizar, então cabe ao profissional puxar essa responsabilidade e falar de vez em quando algo do tipo “Acho que isso vai poluir demais, melhor não colocar”.

Considerações finais
Só uma interface bonita não é o suficiente para “fidelizar” o usuário. Ele tem que conseguir navegar no site, e a simplicidade muitas vezes é fundamental. Uma das grandes vantagens é que com uma navegação boa além do usuário gostar (se o site tiver um conteúdo interessante também) ele recomenda o site para um amigo, que recomenda para outro… Assim a coisa cresce, e muito.

A melhor tecnologia que pode (e deve!) ser usada em um site é a simplicidade.

Princípios relacionados

Este princípio teve a sua inspiração diretamente do princípio da Navalha de Occam e das máximas de Albert Einstein (“tudo deve ser feito da forma mais simples possível, mas não mais simples que isso“) e de Antoine de Saint-Exupéry (“A perfeição é alcançada não quando não há mais nada para adicionar, mas quando não há mais nada que se possa retirar“).

Referências:
    The Top Tips
    Rau-Tu Linux
    MXStudio
    Wikipedia

21 de Novembro de 2008 | 09:13

A decisão da Vale de apertar o cinto por causa da crise internacional já inclui demissões no eixo Pará, Espírito Santo e Minas Gerais. Fontes que acompanham as atividades da mineradora calculam que cerca de 400 dos 2,3 mil funcionários que entraram em férias coletivas no final de outubro já foram dispensados. A companhia não confirma oficialmente esses números, mas reconhece que está em curso um ajuste.

O quadro de funcionários está sofrendo um ajuste à redução da produção de minério de ferro em 30 milhões de toneladas, afirma Fernando Thompson, porta-voz da Vale. Mas estamos tentando tudo que é possível para aproveitar funcionários de minas que foram desativadas em novos projetos.

Na tentativa de evitar um corte ainda mais expressivo, o presidente do Sindicato dos Ferroviários de Minas Gerais e Espírito Santo, João Batista Cavalieri, marcou audiência para hoje com executivos da área de recursos humanos da Vale.

Atualmente, a mineradora tem em sua folha de pagamentos, no Brasil e no exterior, 56 mil funcionários. Queremos buscar uma saída para essa crise. Estamos fazendo um esforço para ganhar tempo e ver se as coisas melhoram. A Vale tem uma responsabilidade com o País, com a manutenção do emprego, afirmou Cavalieri.

Na quarta-feira, em Brasília, o próprio presidente da mineradora, Roger Agnelli, admitiu que a companhia tem feito ginástica para evitar demissões após a decisão de cortar a produção em 30 milhões de toneladas de minério de ferro- 9,2% do total de 325 milhões de toneladas que estavam previstas para este ano.

Até fevereiro ou março de 2009, o que a gente está fazendo é uma ginástica no sentido de manter os nossos empregados, porque sempre fizemos um investimento pesado na formação de nossos técnicos. Não é hora de perdê-los, afirmou. E completou: Agora, isso tudo tem limite, e a gente está torcendo para que as coisas melhorem mais rapidamente. A estratégia da Vale hoje é transferir os empregados das minas paralisadas para outras, que tenham custo de produção mais barato e, por isso, foram mantidas nesse período de desaceleração de atividades.

Mas, de acordo com Cavalieri, as demissões vêm afetando principalmente os trabalhadores da ferrovia Vitória-Minas. Isso porque, explica, houve uma queda no volume transportado pela estrada de ferro com o fechamento de algumas minas e o corte na produção de outras em Minas Gerais. Acredito que entre 3,5% e 4% do pessoal já tenha sido demitido. Isso dá cerca de 100 pessoas somente nessa região, calcula.

Fonte: Portal Exame

por Davi Carvalho
25 de Julho de 2008

Pouco falamos das falhas das implementações ou implantações dos nossos projetos e iniciativas. Acho que compartilhar estas informações pode ajudar outras pessoas e empresas a reduzir os riscos e, no mínimo, faze-las parar e pensar se estão mesmo no caminho certo. Com a arquitetura SOA não é diferente.

Muitas iniciativas falharam (e falham). É claro que as empresas e consultorias que “vendem” SOA não irão te contar nada a respeito disto e muito mesmo irão colocar em seus sites os “cases de falha de implementação SOA”, esqueça!.

E por que falham? Porque a tecnologia ou produto é ruim? Não necessariamente. Iniciativas de SOA, como qualquer outra, são conduzidas por pessoas. Parece óbvio (e é!). Logo, muitas vezes, a falha está em nós mesmos que lideramos e propomos esta nova abordagem orientada a serviço.

Isto é o que Mike Kavis escreve neste artigo para o site CIO.com. Resumo abaixo as 10 razões que ele destaca. O artigo vale a leitura porque o autor não se limite a apontar os erros; ele faz recomendações para cada umas das razões.

Iniciativas SOA falham porque as pessoas…

1. …não sabem explicar o valor de SOA para o negócio
2. …subestimam o impacto da mudança organizacional que SOA traz
3. …não garatem o patrocínio dos executivos ou alta gerência
4. …tentam implementar uma arquitetura SOA “baratinha”, apenas com base em produtos “free”, sem ajuda externa (nós sabemos tudo, certo?!)
5. …não investem em treinamento e pessoas com conhecimento suficiente e experiente para conduzir uma mudança de arquitetura
6. …não tem um gerenciamento de projetos eficiente. Empresas com forte cultura de gerenciamento de projetos tem 2 vezes mais chances de sucesso
7. …acham que SOA é um projeto e não uma arquitetura. Sem comentários!
8. …subestimam a complexidade que a arquitetura orientada a serviços traz
9. …não acreditam na importância da governança SOA
10. …deixam os fornecedores e consultores externos ditarem e “dirigirem” a arquitetura

Fonte: SOA, Simples Assim!

nov.13, 2008

O Brasil vem se destacando ainda mais quando o assunto é offshore outsourcing (se tem dúvidas desse conceito, siga o link). É o que mostra uma reportagem do portal Infoworld. Embora o Brasil concorra com países tradicionais no ramo, como a ìndia e a Rússia, algumas características por aqui tem chamado a atenção de algumas empresas

Foi entrevistado para essa reportagem o CIO da Stefanini para as operações da América do Norte, Antônio Moreira. segundo Antonio, o Brasil aparece como uma alternativa de mitigação de riscos como um site alternativo. Diversificar é preciso, num mundo tão instável como o de hoje.

A proximidade cultural (incluindo-se a cultura do trabalho) e a diferença de fuso horário foram citadas. como diferenciais nessa escolha entre os centros de offshore outsourcing. Este último coincidentemente foi considerado um fator chave por ambas as empresas entrevistadas, que as fizeram transferir parte das operações ao Brasil e não a algum outro pólo tradicional no setor.

Uma das empresas locais entrevistadas, que faz uso de offshore outsourcing no Brasil citou o nível diferenciado dos profissionais de TI brasileiros, que não são apenas executores, mas analistas, sempre em busca de melhorar o que foi proposto pelo cliente. Cita ainda o comprometimento do profissional brasileiro com o prazo dos projetos, que não importa de trabalhar por longas horas para entregar o que foi pedido dentro do prazo.

Bom, quanto ao porque do offshore outsourcing, a resposta não poderia ser outra, ainda mais em tempos de apertar o cinto: “CUSTO”, sendo mais claro, no caso de uma dessas empresas, que teria de pagar o dobro para manter um profissional de TI local.

Ainda segundo o artigo, o Brasil tem a segunda maior comunidade Java fora dos EUA.

Os investimentos em TI no Brasil em plena turbulência econômica só tende a deixar o país mais forte e mais estruturado para recebe a demanda externa.

Agora cabe a nós, profissionais de TI, estarmos preparados para fazer jus a essa boa reputação que está sendo construída, através de especialização, melhora da comunicação em inglês, conquista de certificações de nível internacional. Essas são algumas das ações que eu e você não podemos ignorar, se quisermos manter a competitividade.

A crise também gera oportunidades…e você , como tem se preparado? O acha que torna o profissional de hoje, competitivo, ou até quase imune à crise?

(Veja o artigo na íntegra na InfoWorld, em inglês)

Fonte: Carreira e Certificações em TI

Levantamento do instituto aponta que 85% das empresas já são usuárias de software open source e os 15% restantes vão adotar em 2009.

Por Computerworld/Reino Unido
20 de novembro de 2008 – 07h00

Uma nova pesquisa do Gartner mostrou o ritmo de adoção do software de código aberto no ambiente empresarial. Segundo os dados do instituto, 85% das empresas estão usando código aberto e os 15% restantes devem adotar a tecnologia em um ano.

O levantamento foi feito entre os meses de maio a junho de 2008, ouvindo 274 organizações na região Ásia/Pacifico, Europa e América do Norte.

No entanto, o Gartner disse que 69% das empresas pesquisadas não possuem uma política formal para avaliar e catalogar a utilização de open source. Isso tem “um grande potencial de criar violações de propriedade intelectual”, alerta o instituto.

“Apenas por algo ser gratuito, isso não significa que não tenha custo,” disse Laurie Wurster, diretor do Gartner.

“As empresas precisam ter políticas para aplicações em código aberto, decidindo quais áreas terão open source e identificando quais são os riscos associados com propriedade intelectual ao usar o open source. Quando as políticas estiverem estabelecidas, é preciso ter um processo de governança para garanti-las.”

De acordo com o Gartner, o código aberto está sendo instalado de maneira equivalente tanto em ambientes de missão crítica quanto nos que não são críticos. No data center, o open source funciona?

Razões para adotar open source
As três principais razões para adota open source estão relacionadas com o custo total de propriedade (TCO), custo menor para o desenvolvimento e maior facilidade para começar novas iniciativas usando uma base de código aberto.

“Alguns dos entrevistados disseram que eles também utilizam open source para se protegerem de ter apenas um fornecedor que é ‘dono’ de todo o seu departamento de TI,” ressaltou o Gartner.

Outros entrevistados disseram que a principal razão de negócios para adotar código aberto estava em um time to market mais rápido para novos produtos e a capacidade de evitar procedimentos e regras de vendas complexas.

Contudo, ter governança no ambiente aberto é o maior desafio para as empresas, seguido pelos termos conflitantes ao ter vários tipos de licenças e formulários.

“Entender quando e como a alternativa aberta deve ser usada é um processo frustrante. Mas essas questões vão ser resolvidas lentamente. A maior popularidade do código aberto vai gerar as mudanças,” disse Wurster.

Fonte: Computerworld

Indicação do meu amigo Paulo Barros.

Fonte: Eu Podia Tá Matando