Hoje temos oportunidades com Struts 1, Struts 2, JSF 1.2, JSF 2, Spring MVC 2.5, Spring MVC 3, VRaptor… A verdade que o mercado não deixa uma base firme para que um profissional se especialize em uma determinada ferramenta. Há quem ache horrível, há quem ache ótimo. Eu, sinceramente, não acho nenhum dos dois. Eu não olho com bons olhos essa tamanha diversificação de frameworks, mas entendo que a mesma é necessária para a evolução de conceitos e da própria especificação da tecnologia, incluindo também a diversificação de soluções para determinados problemas. Mas que é um martírio, é. Por exemplo: para atingir o nivel de maturidade que o meu colega atingiu, foi necessário cerca de 1 ano e meio de experiência com a ferramenta. Então, de repente, ele tem que deixar de lado todo esse tempo de maturidade e mudar a forma de se trabalhar/pensar/modelar para colocar um projeto legado com o desenvolvimento web abstraido com o Struts 1. Olhe só o dinamismo que o mercado forçou o profissional! Primeiro, porque ele está deixando de trabalhar com um poolMVC para trabalhar com um pushMVC. Segundo, que o conceito de trabalhar a view com Facelets muda totalmente para o HTML/JSP/JavaScript/CSS na unha. Terceiro, apesar dos Struts 1 funcionar (logicamente), o mesmo deixa de incorporar vários conceitos revolucionários que facilitaram (e muito)  a vida de todos os desenvolvedores, como o CoC (ConventionOverConfiguration). Ou vai me dizer que você, que está lendo esse post, tem como hobby principal a configuração de parâmetros em um XML?

Então, podemos assimilar que todos os profissionais que trabalham com Java precisam dominar todos os framework’s? Por incrivel que pareça, a maioria pensa que sim! Existe quem apóie o fato de que porque determinadas soluções exigem determinadas arquiteturas, o profissional precisa ser especialista em todos os framework’s e especificações que a plataforma disponibiliza. Mas eles estão errados. O importante é a base do conhecimento. Não a nível de especialização, mas a nível de adaptação, o profissional que realmente conhece como um ambiente web funciona ( e quando afirmo isto, afirmo que o profissional sabe realmente o ciclo de vida de uma requisição, o gerenciamento de sessões, o que é uma TLD, etc ) não terá dificuldade nenhuma em se adaptar a um determinado framework. O único empecilho se encontra no tempo de maturidade para se chegar em um nível de desenvolvimento prático que o core business das empresas exigem.

Então, qual seria a solução para essa questão?

A postura de seleção dos Departamentos Pessoais. O mais importante não é a quantidade de certificações, graduações, treinamentos, experiência e lato/stricto sensu que um profissional possui, mas sim a característica de conseguir aprender, evoluir e se adaptar a solução que um determinado problema necessita com a bagagem que o mesmo possui. De que adianta ser um doutor em engenharia de software se o profissional não é dinamico o suficiente para absorver uma tecnologia em uma plataforma que apesar de conhecer não domina, na hora que um requisito exige que o mesmo implemente uma determinada solução baseada na mesma?

A Capacidade de Evoluir.

Essa é a característica mais importante de um profissional.

Normalmente a gente sempre encara esse tipo de problema quando estamos começando a trabalhar com a plataforma Java. É um problema simples, conceitual, mas que muita gente não entende de verdade. Vamos tentar chegar ao porquê desse problema discutindo alguns aspectos no meio do caminho: quando estamos no processo de desenvolvimento, utilizamos uma IDE, certo? Vamos supor que estamos desenvolvendo uma aplicação web em que o Controller (Servlet) vai ser desenvolvido na “unha”. Como todos sabemos, uma Servlet deve extender HttpServlet. Mas HttpServlet faz parte de um JAR que não se encontra no Eclipse e então temos que adicionar a API da Servlet na nossa aplicação. A questão aqui é a seguinte: você adicionou a API da Servlet na sua aplicação, mas como toda solução, vamos precisar deployar (colocar) a mesma em um servidor de aplicação, então vamos considerar o Tomcat. Uma das funções de um servidor de aplicação é prover toda uma infraestrutura para que a aplicação funcione. Então, meus caros, a ServletAPI já não estará lá? Claro que sim! Essa situação abre o leque para duas questões: A primeira que o conceito de JAR Hell entrou em cena, e a segunda é a de que para que precisamos importar uma API para a nossa aplicação se o Tomcat já possuí a maioria das necessárias?

Vamos debater a segunda questão primeiro e vamos inverter os papéis. Nós usamos como exemplo a ServletAPI que já está na library do Tomcat. Mas e se, por exemplo, quiséssemos manipular XML’s e utilizassemos o XStream? A API do XStream não é nativa (não pertence, não vem na livraria padrão) do Tomcat. Então, nesse caso sim faz sentido a importação da API para a nossa aplicação, para que a mesma pertença ao WAR que iremos deployar no servidor. Aonde eu estou querendo chegar? Nas dependências. Qual é a forma correta de acoplar dependências no projeto? Vamos por passo a passo.

O que podemos fazer para não incluirmos dependências que já estão no Servidor de Aplicação no nosso projeto?

Bom, sempre que você associar uma dependência você deve verificar na documentação a lista das que já são nativas do Servidor de Aplicação e verificar se a sua já existe. Ah, dica: o search está desabilitado. (…)

Fala sério, né pessoal… O que fazer então? Importe para o seu projeto a livraria nativa do Servidor de Aplicação. Assim você irá evitar a maioria dos problemas com as dependências. Abaixo temos um exemplo de como utilizar a library do Servidor de Aplicação, que no nosso caso, é o Tomcat:

Abra as propriedades do seu projeto, vão em BuildPath, aba Libraries, e clique em Add Library:

Escolha ServerRuntime

E voa-lá: Escolha o Tomcat! (Lembrando o mesmo só irá aparecer se você já o tiver configurado na Aba Servers do Eclipse)

Agora você pode desenvolver uma aplicação sem a necessidade de inserir a maioria das dependências nativas do Tomcat no seu projeto. Mas e as não nativas? Aí não tem jeito: temos que importar para o projeto. Mas, de repente, um warning novo aparece na sua aplicação:

Um ClassPath Dependency Validator Message, dizendo que a API não irão ser exportada ou publicada no WAR.

Aqui é que corremos o risco de tomar uma ClassNotFoundException. Ah sim, o que é um ClassNotFoundException? É quando você faz um deploy de uma aplicação sem uma library que é necessária para o funcionamento de alguma coisa. Como o JAR não vai ser exportado junto com a aplicação e o mesmo não se encontra no container, vai ser apenas uma questão de tempo até que um cliente quebre a sua aplicação. Como evitar? Importe corretamente. Todos os jar’s externos devem estar na pasta lib da sua aplicação. Não confundam com WEB-INF/lib. Estou falando da pasta lib que se encontra na raiz do projeto. Ou você pode simplesmente usar o QuickFix que está disponível na visualização do warning. O que ele faz: marca a dependência diretamente no arquivo MANIFEST.MF que se encontra na pasta META-INF.

Finalmente! Chegamos na pasta META-INF!

A utilidade da pasta e do arquivo MANIFEST dentro do contexto do projeto é simplesmente a “marcação” do que vai ser publicado junto com o WAR na hora do deploy. E nada mais. O QuickFIx faz isso para você quando o warning aparece: ele simplesmente joga manualmente a declaração dentro do arquivo dizendo que aquele determinado jar vai ser exportado no WAR. Simples, não? Mas acreditem se quiser: eu já vi gente excluindo a pasta com a afirmação de que a mesma não servia para nada. Mas agora você não tem desculpa: você sabe o porque da necessidade da pasta META-INF no seu projeto.

Uma ultima consideração sobre o JAR Hell, que foi citado lá em cima no post: um problema que pode acontecer é o deploy de vários projetos com o mesmo JAR publicado com versões diferentes. Quem disponibiliza as classes para a aplicação é o ClassLoader, que faz parte da JRE e disponibiliza as classes para a JVM poder rodar a aplicação. O que vocês acham que acontece quando o ClassLoader for buscar a classe na sua lista de library’s disponíveis, que possuí dois JAR’s com o mesmo nome? Essa eu vou deixar para vocês pensarem.

Bem, espero que esse post tenha contribuído um pouco com seu knowhow. Admito: eu passei por muitas dificuldades no inicio com dependências e achei legal fazer um post sobre o assunto. Ah sim, para quem interessar, segue alguns links sobre algumas coisas que conversamos aqui:

XStream – Òtimo manipulador de XML’s

Documentação do ClassNotFoundException

Definição do ClassLoader na Wikipedia

Até a próxima!

Quem nunca teve que escrever código para validar CPF? Ou exibir uma string de acordo com uma informação numérica?

Parece uma operação default, não é verdade? Todo projeto exige uma implementação de certas características, muitas vezes, ligadas á uma lógica de domínio brasileira. Você reescreve a implementação em todo projeto? Para quê? O Stella está aí para te ajudar com esse problema.

Pergunta básica de gerente de departamento:

Cara, preciso que o sistema tenha a opção de geração de boletos no nosso módulo financeiro, você estima quando você consegue me entregar essa funcionalidade?

Se você não conhece o Stella:

Poxa, preciso verificar, posso te dar uma previsão depois do almoço?

Se você conhece o Stella:

Sim, posso colocar em produção depois do almoço?

Simples assim.

Precisa de uma implementação rápida para alguma funcionalidade ligada a um domínio brasileiro? Visite o Stella. Quem sabe o que você procura já não está lá, só esperando por você?

Qual é o livro que você mais usa como referência ou que eventualmente sempre revisa um capitulo ou outro?

Quase todo colega de trabalho que eu convivi possuía um “companheiro” ao lado que sempre lembrava alguns detalhes obscuros que o cérebro ainda não havia “indexado” ou que usava como guia em uma nova empreitada de design na aplicação. Alguns que aparecem na minha mente agora: aquele livro azul do Evans (Domain Driven Design), o Core J2EE (Gambi?) Patterns e até o Head First Design Patterns.

Bem, o meu leal seguidor é esse daqui:

Por quê?

Acho o melhor livro prático que eu já li. Quem já leu, ou pelo menos deu uma folheada por cima, sabe que o conteúdo é básico, ou seja: não espere uma proposta de metodologia que vai revolucionar a sua visão sobre o que é realmente uma aplicação, mas espere uma coisa: algumas propostas, que mesmo sendo simples, vão revolucionar um pouco o seu dia a dia.

Exemplos? Sem mencionar capítulos ou itens, posso citar algumas observações rápidas como nunca retornar Null em um método, mas sim uma lista ou até mesmo um array “vazio”, a dica sobre o uso desnecessário das checked exceptions, o favorecimento de membros estáticos no design da classe sobre os não estáticos e até a útil dica de sempre se referenciar pelo contrato em uma declaração ao invés da implementação.

Normalmente, e não é mentira, eu sempre procuro revisar uns 3 itens por semana e sempre que sinto um “bad smell” no que estou desenvolvendo ou no que estou analisando e não entendo o porquê (como se fosse aquela coisa de 6º sentido), eu abro o capítulo sobre o assunto para que eu possa consolidar uma opinião.

Eu adotei o Effective Java como meu livro de cabeceira, e ainda não achei um motivo para arrependimento.

Adote-o também! Quem sabe você, igual a mim, nunca encontre um motivo para arrependimento?

Escolher um assunto polêmico dessa maneira, logo no primeiro post, é dar a cara a tapa. Todo mundo partilha de uma opinião diferente sobre as certificações existentes no mercado. Muitos “endeusam” um certificado, como se fosse uma coisa sagrada que torna você diferente de todos os profissionais que estão no mercado. Outros simplesmente denigrem, acreditam que é perda de tempo, ou uma procura por uma afirmação que não é necessária se você realmente possui um knowhow sobre a tecnologia e já até ouvi pessoalmente de que é somente uma estratégia a mais da corporação que mantém a certificação de obter lucro sobre os profissionais que absorvem o meio de solução proposto.

Ah sim, qual é a minha posição? Nenhuma das duas acima.

Acredito que os dois lados da moeda têm suas razões. Concordo com o fato que uma certificação o torna um profissional melhor. Você é obrigado a estudar alguns detalhes que passam despercebidos e também a explorar todo o leque de soluções que a tecnologia tem a lhe oferecer. Mas também concordo que uma certificação pode lhe tornar um profissional pior ou nem mesmo um profissional. Um exemplo? Já vi muitas pessoas decorarem o conteúdo necessário para aprovação só para conseguir aquele famoso “cartãozinho”, que é exibido com gosto naquelas conversas informais na hora do cafezinho. Ou até mesmo para conseguirem o primeiro emprego. Não que eu tenha alguma coisa contra os aspirantes ao mercado que definem como a sua meta de porta de entrada para um emprego uma certificação, mas eu enxergo mais do que isso: uma certificação existe como meio de completar um profissional.

E já que o assunto é certificação, vou falar da qual tive a aptidão de conseguir e que acredito que tenho competência para discutir sobre a mesma:

OCJP – Oracle Certified Java Programmer, é a antiga SCJP – Sun Certified Java Programmer, mais conhecida como a certificação de Programador Java.

A lenda que eu ouço e leio por aí é de que essa é a certificação mais difícil do mercado de TI. Eu não posso afirmar isso, porque nunca tive experiência com outros testes, mas uma coisa eu garanto: ela é meio “enrugadinha” sim. E foi um pouco disso que me atraiu. Afinal, se uma certificação não possui um conteúdo que desafia o profissional e faz com que o mesmo tenha que explorar a tecnologia para que tenha a capacidade de poder driblar os problemas do dia a dia, qual é o seu verdadeiro mérito? E eu não vou mentir. Tive SIM dificuldades para estudar e passar na prova. Mas isso só provou o quão era grande o meu grau de alienação na época e o quanto eu poderia melhorar.

Bom, o que eu pretendo fazer é aqui é tentar chegar, de certo modo, á um percentual considerável em cima do conteúdo aplicável, de maneira que possamos avaliar se, do ponto de vista técnico, a prova vale a pena.

Nossa, mas isso é impossível de se fazer! A sua experiência com uma determinada tecnologia pode ser muito diferente da de outros profissionais! Você não acha que é uma avaliação muito intrínseca tentar colocar todo o valor da certificação dentro de um percentual?

Sim, tem razão. Mas o objetivo aqui não é dar um percentual e dizer: Olha, chegamos á 80%, vá fazer a prova porque realmente vale a pena. Claro que não. O objetivo aqui é tentar mostrar o quanto da prova foi importante no meu contexto profissional e tentar, repetindo novamente, TENTAR colocar essa análise em um contexto geral, que acredito eu, é o contexto da maioria dos profissionais do mercado.

Bom, se baseando no livro de guia de estudo da Kathy Sierra, temos classificados em 10 capítulos todos os tópicos necessários para a realização da prova. Então podemos considerar que cada capitulo pode chegar á um valor de 100% que corresponde á 10% dos 100% possíveis do que eu considero realmente bom e necessário dentro dos aspectos que serão discutidos. E por favor, mesmo parecendo, não estou discutindo o livro em si (apesar de realmente parecer), mas sim seu conteúdo, já que o mesmo reflete o que está na certificação, não é verdade?

Então, mão na massa: Vamos discutir os capítulos!

CAPÍTULO 1 – DECLARAÇÕES E CONTROLE DE ACESSO

Acho muito legal e essencial esse capítulo. Aqui discutimos sobre os modificadores de acesso, modificadores de comportamento, declarações de variáveis, Enums e o que achei um pouco mais interessante: Convenção de Código dos JavaBeans. Por quê? Parece incrível, mas a maioria não segue a convenção. O pessoal acha que get e set são apenas para modificação de variáveis internas de uma classe. Absurdo. Alias, existe até uma documentação detalhada sobre convenções, encontrada aqui. Outra curiosidade: muita gente não sabe afirmar corretamente o grau de acesso de um membro Protect, e nem imagina que ao declarar uma outra classe no mesmo .java da classe publica o modificador Default é atribuído á mesma.

Então, nível de importância? Vou considerar os 100%. Porquê? Esse é um assunto que todos nós temos que dominar. Nivelamento de acesso, declaração e modificadores é um assunto que todos têm que dominar, e a manipulação de enums e o uso da convenção tem que ser trabalhado no dia a dia.

CAPÍTULO 2 – ORIENTAÇÃO A OBJETOS

Feijão com Arroz! Esse capítulo é a base para a verdadeira essência do Java! Como dominar a tecnologia sem a noção de Polimorfismo, Herança ou até Instanciação?

Porcentagem na importância: 100%. De olhos fechados, mãos atadas sentado na beira de um precipício.

CAPÍTULO 3 – ATRIBUIÇÕES

Esse capítulo fala bastante sobre tipos primitivos e wrappers, alem de dar uma boa explanada em arrays e no Garbage Collector. Mais uma vez, conteúdos básicos que muita gente não sabe são abordados no capítulo, como por exemplo: o java passa valores por referência ou por cópia? O que é o AutoBoxing e o que mesmo pode influenciar no seu código? E o GarbageCollector? Você confia nele?

Vou considerar 70% no mesmo. Mais pelo conceito, que é muito importante, do que pelo lado prático. Afinal, ao enxergar somente o lado prático, como a maioria, o conceito fica para trás. Mas considero que não seja um ponto que pese tanto assim no desenvolvimento de uma aplicação.

CAPÍTULO 4 – OPERADORES

Básico. Não dominar os operadores seria a mesma coisa de dirigir um carro e não saber o que é o volante. Mas concordo que a certificação exige um pouco mais do assunto, como no caso dos operadores Bitwise, que, sinceramente, nunca usei e nunca vi ninguém usar.  Mas de qualquer maneira, 100%. Afinal, não conhecer sobre o assunto é dar um tiro no próprio pé.

CAPÍTULO 5 – CONTROLE DE FLUXO, EXCEÇÕES E ASSERTIVAS

Outro capítulo 100%, sem hesitação. Condições e Iterações é o dia a dia do desenvolvedor. É o que define a implementação correta da lógica da aplicação, sem mais nem menos. Não diria nem que o assunto deveria ser dominado. Tem que ser absorvido de uma tal maneira que vire um costume de todo profissional, não tem nem o que falar. Sobre as exceções, um conteúdo muito rico. Afinal, quase ninguém sabe realmente como trabalhar com exceções. Muitos nem sabem sobre as exceções de RunTime. Exagero? Não, amigos, vivência. Fora o mau uso do mecanismo no dia a dia. Que levante a mão aqui quem nunca viu uma aplicação cheia de printStackTrace()’s dentro dos catch’s ou cheio de throws nas assinaturas dos métodos. E quando falamos de sobrecarga e sobrescrição de métodos com exceções sendo lançadas na sua assinatura? Conhecimento Legendário! Não tem como questionar o conteúdo exigido nesses objetivos do exame.

CAPÍTULO 6 – STRINGS, E/S, FORMATAÇÃO E PARSING

Eu considero esse capitulo especial pelo fato de podermos discutir sobre Strings. Compreender a imutabilidade é muito importante numa aplicação em que a escalabilidade precisa ser o carro chefe. E a manipulação desse tipo faz a diferença SIM no desempenho de uma aplicação. Alem do mais, é muito interessante saber quando usar um StringBuffer e um StringBuilder, afinal, a má utilização das mesmas não sana o problema que a imutabilidade pode trazer. Alias, seria mesmo a imutabilidade um problema? O fato não é discutido nem exigido nos objetivos da certificação, mas é muito legal saber os pós e os contras, e até mesmo usar quando necessário. A Caelum, famoso centro de treinamento, que inclusive mantém o GUJ, aborda o assunto no livro que esta sendo desenvolvendo por eles, e a quem interessar, o trecho do livro sobre o que é explanado se encontra aqui.

Sobre a E/S (Entrada e Saída), acho importante salientar, e na verdade, e até o que o guia de estudos motiva, que mesmo sendo exigido aquele conhecimento detalhado sobre o mecanismo na certificação, o mais importante é a aplicação prática do assunto. Afinal, entrada e saída é uma implementação básica em qualquer aplicação, independente da extensão trabalhada (txt,xls,etc). Essa questão eu acredito sim que precisa ser decorada e guardada com carinho em algum lugar da mente, porque é mais um dos artifícios que é usado freqüentemente no dia a dia.

Agora, na abordagem da formatação e do parsing, eu realmente achei um exagero o conteúdo exigido. Normalmente a formatação é feita na camada de View (quando usado o MVC), seja em uma aplicação Web ou Desktop, e sobre o parsing, sinceramente, qual é a freqüência de desenvolvimento de uma solução que exija a tokenização de um arquivo? Claro, não se pode descartar o conteúdo, afinal, o princípio básico é de que a certificação lhe permita conhecer todas as ferramentas disponíveis da plataforma, mas, mesmo assim, achei que o assunto foi tratado de uma maneira muito profunda e, sinceramente, de uma forma que exija que o profissional  o decore. Decorar não é bom. Saber que existe, seus conceitos básicos e consultar a documentação quando necessário? Esse é o correto na minha opinião.

Então, considerarei 60%, que seria a manipulação de strings e o conhecimento sobre as API’s de entrada e saída. Posso até estar errado, mas descarto a maioria das exigências sobre formatação e parsing existentes nos objetivos, com base no explicado acima.

CAPÍTULO 7 – GENÉRICOS E CONJUNTOS

E aqui, literalmente, o “bicho pega”. Quem já teve a experiência de mockar o exame ou até mesmo realizá-lo pessoalmente, sabe que a prova exige bastante do assunto. Se concordo ou discordo? Prefiro ficar em cima do muro. Não vou dizer que o estudo das particularidades dos diversos conjuntos não adicionou nada ao meu conhecimento técnico, mas também não tenho coragem de dizer que o conteúdo não é adequado quando conversamos sobre exigências básicas para afirmar que sou um “Desenvolvedor Java”. É interessante e muito bom saber os diversos tipos de conjuntos e suas aplicações dentro do contexto de uma solução. E só. Na minha opnião, a verdadeira riqueza desse capítulo se encontra na discussão sobre Generics. É um conceito que ajuda muito no tratamento de tipos quando se referimos a alguns erros de desenvolvimento. Mas mesmo não sendo o objetivo do post, tenho que concordar: poderia sim ser uma coisa mais legal. Quem sabe não entro em um assunto futuro sobre o tema?

No meu conceito? 80% de importância. Devido ao leque que abre ao estudarmos os diversos tipos de conjuntos e a exigência sobre os Genéricos.

CAPÍTULO 8 – CLASSES INTERNAS

Já vou dizer logo de cara: 20%. Porquê? Somente pelo fato de termos a oportunidade de lermos sobre o assunto. Eu nunca usei uma Classe Interna. E aposto que 95% dos que irão ler esse post também nunca usaram. Aliás, existe uma grande discussão na comunidade que debate realmente a utilidade das classes internas. É claro, a prova pega um pouco pesado com esse assunto também, o que faz com que tenhamos de realmente conhecer as classes internas, mas isso não quer dizer que, na minha sincera opinião, não seja um pouco de tempo perdido. Alguns irão atirar pedras quando lerem isso daqui. Mas aposto que a maioria irá concordar.

CAPÍTULO 9 – THREADS

Outro capitulo que é muito exigido na prova. Aliás, se vocês me permitem, foi o assunto que eu mais gostei de estudar. Acho interessante o fato de dois processos serem executados ao mesmo tempo. Ah, esqueci, não é isso que acontece! Acreditem, pode até parecer besteira, mas muitos dos meus paradigmas caíram por terra abaixo. E acho que vocês irão concordar: o conceito discutido no capitulo é muito importante. Agora, a aplicação? Nem tanto. Consigo contar nos dedos ás vezes que tive que me preocupar com threads ou desenvolver alguma coisa relativa. Mas o conceito sempre está lá. Exemplo? Servlets. Existe o conceito por trás, mas normalmente um framework já lhe dá um controller pronto para lidar com o problema.

Vou eleger então uma porcentagem de 90% para o assunto, mas pensando mais na importância da absorção do conceito do que na aplicação prática, já que lidamos com o assunto todos os dias mas na maioria das vezes, e na maioria das vezes mesmo, não colocamos a mão na massa para lidarmos com a aptidão técnica que a prova exige.

CAPÍTULO 10 – DESENVOLVIMENTO

100%. Gerar um JAR? Saber o que é ClassPath? Tem que ser o almoço de todo dia. E ponto. Claro que hoje, temos o Maven, Ant, etc. Mas mesmo assim, não podemos ignorar o conceito.

Bom, é a hora da verdade.

Fazendo as contas, chegamos á média de…  (trombetas tocando?) … 72%.

Achei uma boa proporção. Afinal, é válido o estudo e o esforço, mas a OCJP não é nada de outro mundo. No meu contexto, valeram a pena esses 72%. Os outros 28%, simplesmente carrego com carinho para momentos turbulentos. Afinal, não é de se jogar no lixo. A questão é, do ponto de vista técnico, vale a pena para você?

E o mercado? Como o mesmo encara a certificação?

A resposta é: não tem resposta. A maioria dos departamentos de RH consideram um diferencial. Os gerentes de TI tem opiniões diversas, mais ou menos como as citadas no começo do post. Eu, como avaliador, consideraria um diferencial somente após uma conversa com o profissional, assim como faço normalmente na minha rotina. Afinal, existem as pessoas que realmente tiram proveito da vantagem e existem pessoas que usam a vantagem da certificação para atestar uma qualidade e um conhecimento que na maioria das vezes, não possuem.

Então, uma certificação seria uma Vantagem ou simplesmente uma Perda de Tempo?

Depende. Você é um profissional que utiliza recursos com a consciência das vantagens envolvidas e dos benefícios da mesma, ou prefere perder tempo, tentando iludir a si mesmo e aos outros e esperando que o longo prazo não mostre que o seu objetivo era apenas uma manobra temporária sem muitas esperanças?

A minha experiência foi a de que, a Certificação, foi uma Vantagem.

Manter um blog parece ser uma coisa meio trabalhosa devido as responsabilidades do dia a dia, mas também parece ser desafiadora e curiosa.

Eu não sei qual vai ser o resultado dessa experiência, mas como todos relatam um bom feedback, vou explanar minha opinião sobre assuntos que eu acho relativamente interessantes e desafiadores. Não irei prometer nada, mas tentarei manter uma certa regularidade na publicação de alguns assuntos, acho que mensalmente.

Mas o que eu espero realmente desse blog é que eu consiga publicar a minha opinião sobre determinados assuntos e a minha visão e experiência sobre algumas tecnologias que eu tive ou tenho contato, incentivando discussões e explanações, porque, afinal, eu não sou o senhor da certeza nem mesmo o mestre da sabedoria: sou apenas um profissional de TI que já rodou um pouco com um bom conhecimento e uma boa experiência sobre diversos assuntos.

Mais um blog por aí? Não creio. Pode ser para os outros. Para mim, é uma forma de consolidar e divulgar o que eu penso. Por isso, considero o mesmo especial!

Que a aventura tenha inicio!!!