Evolucao

Evolucao
Evolucao

domingo, 24 de junho de 2012


Amigos, segue imagem de meu sistema de helpdesk, interessandos podem deixar comentários ou entrar em contato comigo.

sexta-feira, 22 de junho de 2012

Invista em voce


Em 2013, num tempo de mudanças como o que estamos vivendo, o maior risco que corremos é o de ficarmos para trás, de nos fossilizarmos, de ficarmos atrasados com a tecnologia, com novos processos que surgem a cada dia no setor em que trabalhamos.

Conheço muita gente que fica esperando que a empresa ou que outras pessoas lhes forneçam os meios para que aprendam mais, para que cresçam mais. Isso é um grande erro. Outro dia mesmo, numa multinacional de origem americana, havia um supervisor sendo cogitado para ser promovido a gerente. Quando lhe perguntaram se falava inglês, ele respondeu: "Esse é o meu problema. Eu não sei falar inglês". E é claro, não foi promovido. Ele veio conversar comigo e eu lhe perguntei há quantos anos trabalhava naquela empresa americana. Ele respondeu: "15 anos" e emendou "justo agora que aparece essa minha grande chance, eu fui preterido só porque não falo inglês." Eu não tive outra reação a não ser dizer a ele o seguinte: "- Você trabalha há 15 anos numa empresa multinacional americana e nunca se interessou em aprender inglês?" Ele respondeu: "- Fiquei esperando que a empresa me fornecesse um curso de inglês e o tempo foi passando...".

Ninguém investe em pessoas que não investem em si próprias em primeiro lugar. Ninguém gasta vela com mau defunto, como diriam os antigos. Quem tem a primeira obrigação de aprender sobre o que fazemos ou de nos aperfeiçoarmos somos nós próprios. Por menos recursos que tenhamos, é preciso que disponibilizemos dinheiro, tempo e energia para nos aperfeiçoarmos fazendo cursos, aprendendo, nos interessando pelas coisas que fazemos e por novas tecnologias, como aprender a trabalhar com computadores, por exemplo. Se você trabalha em uma empresa que produz ou vende cerveja, trate de saber a diferença entre Pilsen, Bock, Lagger e outros tipos de cerveja. Se você trabalha numa empresa que produz ou vende papel, saiba os vários tipos de papel existentes no mercado mundial e quais os seus usos, e assim por diante. Vá numa biblioteca, pergunte, consulte uma enciclopédia, se interesse, envolva-se com aquilo que faz. Invista em você em primeiro lugar.

Pense nisso. Sucesso!
(por Luis Almeida Marins Filho)
Fonte:Primeiroprograma.com

Oracle x Google

Os advogados da Oracle já apresentaram sua moção para declinar o pagamento de 300.000 dólares em danos do Google no processo que diz respeito à infração de patentes e direitos autorais do Java pela máquina virtual Dalvik do Android. No mês passado, o juiz William Alsup conduzindo o caso decidiu que a estrutura, sequência e organização (structure, sequence and organisation -- SSO) das 37 APIs Java em questão não são passíveis de proteção sob direitos autorais e que o Google não infringiu as patentes da Oracle. Isso deixou o demandante apenas com a possibilidade de buscar danos determinados em lei (statutory damages), que não passariam de 300.000 dólares nesse caso. A Oracle, a princípio, havia pedido bilhões de dólares em danos.
A rejeição desses parece ser parte de uma preparação da Oracle para apelar da decisão da corte. O advogado da Oracle, Michael Jacobs, até mesmo fez troca durante os procedimentos: "Espero ver você novamente após a apelação." As partes de um recurso, caso ele seja aceito, deverão passar novamente pelo julgamento no tribunal do juiz Alsup. A Oracle provavelmente está declinando os danos para avançar com processo o quanto antes para a fase de apelação.
Durante um novo julgamento, a Oracle poderia ser capaz de exigir danos punitivos baseados em uma nova tentativa de provar que o Google infringiu suas patentes e também tentar assegurar mais uma vez que as APIs Java são passíveis de proteção pelos direitos autorais.
Fonte: h-online, em inglês.

quarta-feira, 13 de junho de 2012

Qcon-2012

A Caelum e o InfoQ organizam, pela terceira vez no Brasil, o principal evento de arquitetos e desenvolvedores do mundo.

O QCon SP traz, dias 4 e 5 de agosto, ícones internacionais e nacionais de diversas áreas, com apresentações aprofundadas de alto nível técnico.
O QCon aborda não apenas uma única tecnologia ou aspecto: passa por Arquitetura, Linguagens Funcionais, Mobile, Agile, Práticas de Engenharia Ágil e outros. Dentre os keynotes desse ano teremos Tom Soderstrom, CTO do laboratório de propulsão da NASA, Martin Fowler, chief scientist da ThoughtWorks e Zach Holman, arquiteto do GitHub.
Fonte:http://qconsp.com/

segunda-feira, 11 de junho de 2012

UP-Utilidade Pública-Hospital da Mãe

Dia 14 de Junho será inaugurado o Hospital da Mãe - em Mesquita
O Hospital Estadual da Mãe, em Mesquita, será inaugurado no dia 14 de junho, para atender gestantes da Baixada Fluminense. A Unidade terá ambulatório de atendimento pré-natal e maternidade para partos de baixas e médias complexidades.
De acordo com a Secretaria de Estado de Saúde – SES, o novo Hospital realizará nove mil consultas e cerca de 600 partos, por mês, com ambulatório de atendimento pré-natal e maternidade para partos de baixa e média complexidade. A unidade terá 70 leitos de internação, oito leitos de UTI Neonatal, 12 salas de Pré-Parto e Parto - PPP, além de leitos de recuperação pós-anestesia, assistência a recém-nascidos, e centros cirúrgicos, ampliando a assistência Neonatal na Baixada Fluminense.
A abertura do serviço às mulheres da Baixada será feita por fases. Nos primeiros 45 dias, o funcionamento começa pelo ambulatório, que fará o acompanhamento pré-natal das gestantes, numa parceria com a Secretaria Municipal de Saúde – SEMUS, no caso da população mesquitense. Apenas as pacientes com o pré-natal em dia vão poder fazer o parto no Hospital da Mãe. Não haverá demandas espontâneas. A metade da capacidade de atendimento será dedicada às moradoras de Mesquita; e a outra metade será dividida em cotas para pacientes de médio risco, como adolescentes, portadoras de diabetes ou mulheres hipertensas, dos outros municípios da Baixada.
Durante o pré-natal, a gestante fará, sempre que necessário, o exame de sangue e a ultrassonografia, no mesmo dia da consulta, quando receberá os resultados e medicamentos. “As pacientes que serão atendidas ali deverão fazer o pré-natal na rede de atenção básica de saúde do seu município, com clínico geral, onde receberão um cartão e terão o atendimento complementado no Hospital da Mãe, com obstetras, nutricionistas e enfermeiros. É importante vincular o atendimento dela ao município, que é onde ela vai acompanhar o crescimento do bebê”, detalha Sérgio Côrtes.
“A gente quer dar garantia de linha de cuidado na atenção materna. A gestante vai visitar as instalações ao longo do pré-natal e sabe que ali é a maternidade dela. Ela vai passar por cursos para saber trocar fraldas, fazer curativo no umbigo, e vai receber um kit bebê para ter na bolsa, e o material preparado para levar no dia do parto”, complementa Sérgio Côrtes.
Fonte: Governo do Estado

domingo, 10 de junho de 2012

TDC2012-The Developer`s Conference

Estão abertas as incrições para TDC em São Paulo, e custam R$40 por trilha, vale a pena conferir. O TDC2012 traz trilhas tradicionais, cobrindo uma variedade de tecnologias e assuntos relacionados, como: Java, .NET, Ruby, Android, Cloud, Python, Empreendedorismo, Agile, Web e Testes, entre muitas outras trilhas. A novidade dessa edição é o conceito das trilhas University, destinadas a estudantes e profissionais que estão iniciando na tecnologia apresentada.
mais informaçõe navegue até o site:http://www.thedevelopersconference.com.br.

Dicas E mais Dicas.....

Entrando em grandes projetos em andamento: Dicas para novos desenvolvedores

Começar a trabalhar em um grande projeto é sempre um desafio. Como entender o código se os desenvolvedores seniores - aqueles que mais poderiam te ajudar - provavelmente estarão muito ocupados? Ou quando a documentação é escassa e será necessário mostrar trabalho rapidamente. 

1. Não tente entender toda aplicação de início
Não há motivos para buscar entender todo o código no começo de um projeto. Muito provavelmente, no início, será solicitada a reparação de um bug ou a melhoria de uma funcionalidade existente na aplicação. A primeira coisa que não se deve fazer é tentar entender toda a arquitetura da aplicação. Quando se está começando em um projeto, esta abordagem pode ser um pouco otimista demais.
Mesmo um desenvolvedor sênior com mais de 10 anos de experiência pode não entender certas partes da aplicação apesar de estar no mesmo projeto há mais de um ano (considerando que não seja da equipe inicial do projeto). O desenvolvedor sênior pode produzir bem e ainda assim não saber detalhes sobre o mecanismo de autenticação ou sobre os aspectos transacionais da aplicação, por exemplo.
Então como fazer? Um caminho é simplesmente procurar entender bem a parte em que se está trabalhando e procurar entregar valor para a equipe. Entregar valor hoje em dia é mais importante do que passar horas procurando entender algo que talvez te ajude somente no futuro.
2. Tenha foco em entregar valor imediatamente
Não seria importante, portanto, entender a arquitetura da aplicação? Sim. Entender a arquitetura é importante. Porém, entregar algo de valor o mais cedo possível deve ser o foco ao começar em um projeto. Uma vez preparado o ambiente de desenvolvimento, não se deve demorar mais do que uma ou duas semanas para entregar algo de valor, não importa o quão pequena seja tal entrega. Ser um programador experiente e não entregar algo em duas semanas, poderá gerar desconfiança nos gerentes e deixar uma má impressão.
O foco inicial, portanto, deve ser "entregar algo". Não é aconselhável explicar o fato de não entregar nada de valor com a justificativa de ser necessário estudar a arquitetura da aplicação. Isto não é justificável. Adicionar uma validação de Javascript pequena e específica pode gerar um valor considerável ao negócio e a expectativa inicial da gerência irá diminuir.
Com o passar das semanas e com a entrega de algumas correções e melhorias, toda a arquitetura da aplicação ficará aos poucos mais clara. É preciso ter cuidado para não subestimar o tempo necessário para entender todos os aspectos arquiteturais da aplicação. Talvez seja necessário alguns dias para entender o mecanismo de autenticação e um pouco menos para entender o gerenciamento de transações. O ponto-chave, entretanto, é entender algo por completo, não importa o tempo que isso leve.
É de grande importância a pré-existência de testes unitários bem escritos. Testes unitários são uma ótima maneira para entender grandes bases de código. Os testes unitários ajudam a começar pelas menores partes do código, entendendo as interfaces externas dos testes unitários (como uma unidade deve ser invocada e o que se deve esperar de retorno) e também suas implementações (analisar testes unitários é bem mais simples que analisar toda uma funcionalidade).
Ao compreender um conceito ou uma parte do sistema muito bem, é interessante também aproveitar para criar anotações ou diagramas de classes, de sequência e modelo de dados. Estes documentos também auxiliarão outros programadores no futuro.
3. Habilidades importantes para se manter grandes aplicações
Quando um programador é contratado para o trabalho, é necessário que apresente bons conhecimentos da tecnologia. Porém há outras habilidades que o ajudarão em grandes projetos de aplicações:
3.1 Capacidade de encontrar as principais classes rapidamente
Para qualquer tipo de atividade, seja correção de bug ou melhoria, a primeira tarefa é identificar quais as classes relacionadas à correção ou à melhoria. Uma vez identificadas as classes e/ou métodos necessários à correção, metade do trabalho estará feito.
3.2 Capacidade de analisar o impacto de uma mudança
Depois de fazer as mudanças necessárias para a correção de um bug ou uma melhoria de uma funcionalidade, o mais importante é garantir que tal mudança não afete outras partes do código. Com base nos conhecimentos da tecnologia em conjunto com os diversos frameworks existentes é possível deduzir onde as mudanças poderão impactar. Seguem dois exemplos sobre essa última afirmação:
a) Quando o método equals() de uma classe A é alterado, todas as chamadas para o método contains() em listas que contenham instâncias de A serão afetados. A menos que se saiba bem sobre a tecnologia empregada no caso, é bastante provável que não se perceba isto;
b) Em uma aplicação web, assumindo que o 'id do usuário' é armazenado na sessão. Um programador júnior pode associar algo ao 'id do usuário' como parte de uma correção de bug sem saber que esta ação irá impactar outros casos de uso que dependem do ´id do usuáio'.
Logo, é importante conhecer suficientemente bem tanto a linguagem da tecnologia como também os frameworks utilizados para se poder analisar os impactos de uma mudança.
Uma vez dominadas estas duas habilidades, a maioria das atividades de manutenção serão fáceis, mesmo sem ter muito conhecimento sobre a aplicação. Caso se trate da correção de um bug, é necessário primeiro localizá-lo no código, corrigi-lo e garantir que a correção não afete nenhuma outra parte da aplicação. Caso seja o desenvolvimento de uma melhoria ou implementação de uma nova funcionalidade, na maioria das vezes, basta seguir a estrutura de uma funcionalidade existente.
Isso posto, considerando uma aplicação bancária, toda a arquitetura de uma funcionalidade, como por exemplo "Resumo da Conta", não irá diferir muito de outras funcionalidades, como por exemplo "Histórico de Transações". Uma vez entendida a arquitetura de "Resumo da Conta" é possível utilizá-la como base para criação da arquitetura de "Histórico de Transações".
Em resumo, não é necessário entender qual o papel de todas as 2000 classes de um sistema ou todo o fluxo do código de uma aplicação para realizar correções ou melhorias. Com as habilidades descritas anteriormente é possível identificar as partes do código que necessitam de alterações, realizar as alterações com base nos conhecimentos da tecnologia e de seus frameworks, garantir que as alterações não afetem outras partes do sistema e, por fim, entregar correções e melhorias mesmo com pouco conhecimento da arquitetura da aplicação.
4. Ferramentas para encontrar oportunidades de melhoria e para conhecer o impacto de uma mudança
Continuando com a temática da importância de se entregar algo de valor o quanto antes, deve-se procurar ferramentas que contribuam para a entrega de valor, mesmo com pouco conhecimento sobre a aplicação.
4.1 Ferramentas para encontrar oportunidades de melhoria
Tanto para correções quanto para melhorias, a primeira coisa a se fazer é encontrar qual a classe ou o método correspondente. Há basicamente duas abordagens para se entender uma funcionalidade - análise do código-fonte e análise da funcionalidade em tempo de execução.
Ferramentas de análise de código-fonte realizam uma varredura por todo o código e mostram as relações existentes entre as classes. Há várias técnicas de análise de código-fonte e há várias ferramentas no mercado. Alguns exemplos são: Architexa, AgileJ, UModel, Poseidon, etc.
Todas essas ferramentas fazem a análise do código-fonte, porém não conseguem dizer com precisão todas relações entre classes e chamadas de métodos que ocorrem em tempo de execução. A razão disto é a utilização de load [carregamento] em tempo de execução, utilização de métodos de callbacks [rotina para tratamento de evento], etc. Por exemplo, nenhuma ferramenta consegue inferir qual servlet [componente do lado servidor que gera dados HTML e XML] será chamado quando um determinado botão for pressionado.
Há ferramentas que realizam a análise do código em tempo de execução determinando quais classes e métodos são chamados. Algumas dessas ferramentas são: MaintainJ, Diver, jSonde, Java Call Tracer, etc. Essas ferramentas geralmente capturam a sequência de chamadas em tempo de execução e se utilizam destas informação para gerar diagramas de sequências e de classes para cada caso de uso.
O diagrama de sequências mostra todas as chamadas a métodos em tempo de execução. Logo, tratando-se da correção de um defeito, o problema provavelmente estará em algum dos métodos chamados.
Tratando-se de melhorias, é importante entender o diagrama de sequências de uma determinada funcionalidade e, a partir daí, melhorá-la. Tal melhoria poderá ser a adição de uma validação, ou a alteração de um DAO [Data Access Object], etc.
Ao desenvolver uma nova funcionalidade, deve-se procurar uma funcionalidade semelhante, entender o diagrama de sequência de tal funcionalidade e utilizá-lo como base para o novo desenvolvimento.
Escolha a ferramenta de análise com cuidado. Um grande problema relacionado com essas ferramentas consiste no alto grau de detalhes que algumas delas geram. Deve-se escolher uma ferramenta que permita filtrar detalhes desnecessários, de maneira a facilitar o entendimento.
4.2 Ferramentas para conhecer o impacto que as mudanças podem causar
Se casos de teste estão disponíveis, é necessário executá-los para garantir que as mudanças não afetarão o resto dos testes. Provavelmente, os testes unitários não irão cobrir todo o código de uma grande aplicação empresarial. Nessas situações, é interessante procurar a ajuda de alguma ferramenta.
De novo, as duas maneiras de realizar a análise são em tempo de compilação e em tempo de execução. Há várias ferramentas de análise de código em tempo de compilação presentes no mercado. Alguns exemplos são: Lattix, Structure101, Coverity, nWire and IntelliJ's DSM.
Dada uma determinada mudança em uma classe, as ferramentas citadas no parágrafo anterior realizam uma análise no código em tempo de compilação em busca das dependências entre as classes. Com estas informações, os programadores deduzem quais as classes afetadas pela mudança dado que a ferramenta não consegue determinar quais classes invocarão o método em tempo de execução.
Não há muitas ferramentas que realizam uma análise do código em tempo de execução. Uma das poucas ferramentas é a MaintainJ, que começa identificando todas as classes e métodos envolvidos em uma determinada funcionalidade. Uma vez em posse dessa informação, é possível identificar as funcionalidades impactadas pelas mudanças em um determinado conjunto de classes. Uma pré-condição para o funcionamento do MaintainJ é a de que todas as funcionalidades devem rodar ao menos uma vez para que as dependências possam ser capturadas.
Em resumo, atualmente há pouca ajuda de ferramentas para a análise de impacto de uma mudança. Primeiro é necessário identificar a forma correta de realizar a análise de impacto e determinar qual será o impacto da mudança, que dependerá do resultado dessa análise ou a de um desenvolvedor sênior. As ferramentas citadas acima devem ser utilizadas como suporte às decisões tomadas.
5. Duas ressalvas com relação aos argumentos acima
5.1 Não comprometa a qualidade do código
O fato de se buscar entregas rápidas não deve ser usado como desculpa para comprometer a qualidade do código. Os exemplos a seguir demonstram situações em que pode ser tentador abrir mão da qualidade do código em troca de uma entrega rápida.
A adição de novas funcionalidades geralmente possui um risco menor do que a alteração de uma funcionalidade já existente com inúmeras dependências. Por exemplo, pode existir um método que faça parte de cinco funcionalidades diferentes. Como parte de uma melhoria de uma dessas funcionalidades, será necessário realizar alterações na implementação desse método. O mais fácil a se fazer pode ser copiar o método, renomeá-lo e chamá-lo na mudança que se está desenvolvendo. Porém isso nunca deve ser feito. Duplicação de código é ruim e para evitar que isso aconteça deve-se verificar a possibilidade de construir um wrapper para este método, sobrescrevê-lo ou simplesmente alterá-lo e testar novamente todos os casos de uso.
Outro exemplo é a mudança de um método de 'privado' para 'público' para que possa ser invocado por uma outra classe. É sempre ruim expor mais do que o necessário. Se um pouco de refactoring for necessário para não ter que expor um método privado como público, deve-se realizar o refactoring.
A maioria das aplicações possuem uma certa estrutura e um padrão. Mesmo na realização de uma correção ou na adição de uma melhoria, deve-se manter tais padrões. Na dúvida, um desenvolvedor sênior deve avaliar as alterações implementadas. Caso não seja possível seguir as convenções, deve-se ter cuidado para que isso fique de forma localizada, em pequenas classes (um método privado em uma classe de 200 linhas por exemplo).
5.2 Entender a arquitetura no médio / longo prazo
Seguindo o que foi sugerido neste guia, entregar algo de valor o mais breve possível entendendo o mínimo necessário sobre a arquitetura é mais importante que passar grande tempo entendendo toda a arquitetura da aplicação. Porém, deve-se tomar cuidado para que o contrário também não ocorra, ou seja, sempre trabalhar em entregas rápidas e pontuais e não se preocupar em conhecer toda a arquitetura da aplicação.
6. Conclusão
O foco do artigo é em como entregar algo rápido, aprendendo o necessário, sem comprometer a qualidade do código.
No caso de uma correção, encontrar o bug e corrigí-lo rapidamente é muito importante. As ferramentas de análise de código em tempo de execução podem ajudar. No caso de uma melhoria, uma funcionalidade similar pode ser utilizada como exemplo para entender o fluxo e implementar a melhoria.
Tudo isso pode parecer bem simples, mas é possível aplicá-lo na prática? Sim. Mas a pré-condição é de que os conhecimentos básicos necessários sobre a tecnologia e frameworks são fundamentais para realizar as primeiras alterações no código e então analisar o impacto da mudança. O que mais se destaca é a capacidade de analisar o impacto de uma alteração, mais do que fazer a alteração em si. A ajuda de um desenvolvedor sênior para analisar o impacto é sempre de grande importância.
Aproximadamente 50% de todo o custo operacional em TI é gasto com correções e pequenas melhorias. Seguindo o proposto neste artigo é possível economizar uma quantidade considerável de dinheiro.
fonte:InfoQ

 

 

ACM premia o Eclipse com Software System Award

Compartilhando...

Associação para Maquinaria da Computação (ACM) anunciou no dia 26 de Abril que o Eclipse, devido as suas contribuições para conceitos de projeto de software e aceitação de mercado, é o mais novo vencedor do Prêmio de Sistema de Software(Software System Award), que é destinado a instituições ou indivíduos reconhecidos por desenvolver sistemas de software com influência duradoura. Segundo o comunicado à imprensa:

Concebido para preencher as lacunas deixadas pelas ferramentas de software proprietário, o Eclipse permitiu que desenvolvedores integrassem, de forma harmoniosa, suas próprias extensões, especializações e personalizações. O Eclipse revolucionou o conceito de Ambiente de Desenvolvimento Integrado (IDE) por identificar a essência conceitual subjacente a qualquer IDE.

O apoio financeiro para o Prêmio de Sistemas de Software é fornecido pela IBM, mas a ACM é uma organização completamente independente. O prêmio, que é muito prestigiado, conta com uma lista ilustre de antigos vencedores, incluindo Eiffel (2006), Java (2002), Apache (1999), NCSA Mosaic (1995), a World Wide Web (também em 1995), assim como PostScript (1989), Smalltalk (1987), e UNIX (1983).

A equipe do Eclipse da IBM incluía John Wiegand, Dave Thomson, Gregory Adams, Philippe Mulet, Julian Jones, John Duimovich, Kevin Haaland, Stephen Northover (atualmente na Oracle), e Erich Gamma (atualmente na Microsoft). Escrevendo em seu blog, o diretor executivo da Fundação Eclipse, Mike Milinkovich, disse:

É muito importante o reconhecimento das contribuições feitas pelo Eclipse para a Computação. Entre os anos de 1999 e 2001, época em que o Eclipse foi criado e disponibilizado, a idéia de que era possível construir uma plataforma de ferramentas cuja arquitetura fosse completa e uniformemente modular era revolucionária. Em muitos aspectos esta ideia é inovadora, mesmo nos dias de hoje,. O modelo de plugins do Eclipse (posteriormente adaptado para inclusão no padrão OSGi) possibilitou a construção da maior e mais aberta plataforma de ferramentas do mundo. O Standard Widget Toolkit (SWT) provou ao mundo, no ano de 2001, que era possível construir interfaces de qualidade utilizando Java e competir de igual para igual na plataforma Windows com o Visual Studio.

De acordo com Milinkovich, o Eclipse também teve grande impacto no movimento open source, pois "demonstrou que até mesmo empresas grandes e conservadoras passaram a compreender o valor de negócio na formação de plataformas e comunidades open source".

Atualmente, a IBM utiliza o Eclipse em mais de 500 produtos, incluindo muitas das ferramentas da Rational como o Rational Application Developer para WebSphere e o Rational Asset Manager, bem como ferramentas no modelo cliente-servidor, como o Lotus Notes 8 e o Lotus Symphony. Existe ainda uma série de empresas desenvolvedoras de software que construíram seus produtos baseados na plataforma Eclipse, entre eles a Adobe com o Flash Builder e o ColdFusion Builder, a Red Hat com o JBoss Developer Studio, a SAP com o NetWeaver Developer Studio, a VMware com o SpringSource Tool Suite, a Wolfram Research com o Wolfram Workbench (uma IDE baseada em Eclipse para o pacote Mathematica), e a Zend Technologies com o Zend Studio (uma IDE para desenvolvimento em PHP).

Mais informações sobre a história do Eclipse podem ser encontradas na InfoQ Brasil.

segunda-feira, 4 de junho de 2012

Aprenda a Programar em 2012

Poder armazenar a inteligência em forma de código e distribuí-la pelo planeta é algo incrivelmente transformador, de forma a contribuir para expandir seus conhecimentos.
 No começo deste ano,  a startup CodeAcademy(codeacademy.com) lançou um projeto diferente:uma chamada geral para que as pessoas aprendam a programar. È a iniciativa CodeYear(codeyear.com) ou Ano da Programação. A coisa ficou tão interessante que gente famosa como o prefeito de Nova York, Michael Blomberg, tuitou que uma de suas resoluções para 2012 é aprender a programar.E já passa de 340mil pessoas participante da iniciativa.
 Mas por que programar pode ser algo interessante? Para responder precisamos entender porque os programas de computador  são tão importantes, com a crescente digitalização de nossas vidas, estamos cada vez mais rodeados por software. Se o hardware é o corpo de um dispositivo, com sua estrutura física, sua força mecânica, sua aparência, seus sentidos, ou melhor, sensores, o software é a consciência, a inteligência e a alma.
Seja embarcado em um tocador de mp3 ou em um marca-passo, em uma aplicação de engenharia rodando em uma estação de trabalho ou ainda em um aplicativo social para smartphone,  o software  é resultado de centenas ou milhares de horas do pensamento de especialistas condensadas e empacotadas para serem consumidas por não programadores. É a inteligencia de um grupo compartilhada  em forma eletrônica.
Podemos armazenar inteligência na forma de código e fazê-la chegar a qualquer lugar do planeta, por meio da internet.Isso é incrivelmente transformador.

Sob Demanda  
Outra característica  que faz do software algo tão valioso é o fato de ser flexivel por natureza. Isso faz com que as coisas sólidas, como circuito eletrônico, também sejam flexíveis. Se é o software que determina a maior parte do comportamento de um circuito digital moderno, basta alterá-lo para o mesmo circuito realizar atividades diferentes, bem como expandindo os horizontes de serviços compartilhados que hoje em dia, estão preparados para fornecer serviços nas seguintes áreas:
-Contabilidade
-Processamento de transações
-Recursos Humanos
-Logistica
-Tecnologia de informação e outros mais..
 Empresas que exergam o software como parte fundamental do negócio entenderam que os programas são uma das principais fontes  de eficiência na produção, criação de vantagens competitivas sustentáveis e de inovação, citando um exemplo o Groupon. e isso se aplica a qualque tipo de Empresa.
Os sistemas inovadores não estão disponíveis  na forma de pacote de prateleira, precisam ser criados sob demanda ou requerem um trabalho pesado de customização. Além disso, como as necessidades dos negócios estão em constante modificação, a tecnologia também evolui e quase sempre é necessário que o trabalho com software esteja em evolução contínua. Deixar de desenvolver é perder a corrida para concorrência.
Pense agora na Internet, um site nada mais é do que um conjunto de sistemas desenhados para oferecer melhor serviço possível. Apenas os mais aptos e otimizados conquistarão a audiência necessária. E isso requer abraçar o software como parte fundamental do negócio. E voce o que está esperando para aprender a programar? 

domingo, 3 de junho de 2012

Tecnologia Java

Nos últimos anos, vimos também uma consolidação generalizada em todo setor de software. A Oracle, atual dona do Java, é uma combinação da antiga Oracle com uma longa lista de empresas adquiridas. TopLink, BEA, PeopleSoft, Siebel, Tangosol, Sun, e muitas outras. Outros gigantes como a Microsoft, Adobe, Apple e até a relativamente jovem Google, também engoliram centenas de outras empresas e isso se reflete na complexidade dos seus portfólios de produtos e serviços, e na sofisticada estratégia que cada empresa estabelece usando uma mistura às vezes confusa de projetos proprietários e livres, secretos e abertos, conservadores e visionários, etc.
No meio desse fogo cruzado, o desenvolvedor comum se sente arrastado por tsunamis de grandes anúncios-cada JavaOne, Google I/O,BUILD,WWDC,MAX entre outras conferências, nos pressiona a investir em novos produtos e tecnologias. E como isso não bastasse, temos também a realidade paralela da comunidade de código Livre e de inovadores de menor porte, que possuem uma dinâmica completamente diferente. Finalmente, as restrições mais "pé-nochão" do nosso trabalho diário , em especial empresas cujo o departamento de TI não tem nenhuma pressa em acompanhar a onda dos últimos browsers, sistemas operacionais ou servidores JavaEE. Concluimos que a vida é dura, mas é bem melhor com Java,com olhar bem mais atencioso para os desafios e oportunidades para o futuro.
Fonte:Java Magazine Edição100.