|
|||||
|
O mercado de tecnologia de informação possui dezenas de subdivisões e dentre elas a que trata de segurança tem felizmente avançado. Uso o ‘felizmente’ para indicar que a preocupação com segurança, algo que sempre foi necessário mas igualmente ignorado, passa a ter cada vez mais relevância dentro das corporações. O primeiro sinal de que uma determinada área ou subdivisão ganha importância é o aparecimento e solicitação por parte das empresas de certificações. Dentre as certificações que tratam do assunto uma tem apelo especial : CISSP. Esta é conhecida por requerer que o pretendente tenha um conhecimento muito vasto em várias áreas da segurança, muitas delas fora do ambiente tecnológico ao qual todos estamos mais acostumados a atuar. O CISSP define 10 domínios de conhecimento denominados de CBK (Common Body Knowledge) :
Recomendo a todos os que estejam interessados seriamente em segurança que pelo menos estudem para o CISSP. Mesmo que não consigam a certificação o escopo e abrangência dos assuntos irão abrir horizontes e lhe permitirão analisar de maneira mais crítica a segurança e como a mesma é tratada dentro de sua organização. A melhor proposta que vi até hoje para se resolver o debate sobre qual a melhor linguagem
Um dos mercados mais ágeis tem sido o de telefonia celular. Com modelos novos sendo lançados mensalmente para um público cada vez mais ávido por avanços. As tecnologias antes só encontradas nos equipamentos de ponta passam gradualmente a ser encontrados nos celulares mais populares. Agenda de compromissos, câmeras, bluetooth e GPS são algumas dessas tecnologias que vem se tornando largamente disponíveis. Visando se diferenciar as empresas de celular passaram a procurar segmentos onde pudessem oferecer produtos com maior valor agregado e sem uma pressão por preço tão forte quanto no mercado comum. A categoria escolhida foi a dos smartphones. Surgidos há alguns anos estes equipamentos procuram disponibilizar as funcionalidades de PDAs e de celulares em um só, com integração com outras ferramentas do desktop e assim serem extensões deste para o público corporativo. Um dos campeões de venda nessa categoria tem sido o Blackberry da RIM com uma integração com o email corporativo tida imbatível até hoje. O Palm com a linha Treo também é um participante de destaque apesar da decadência da sua participação de mercado dos últimos anos. Tudo ia bem com cada fabricante essencialmente provendo pequenos avanços de tecnologias existentes (ex. câmera de 1 Megapixel, 2 Megapixels etc). Isso tudo foi alterado recentemente com a entrada do iPhone. Este definiu um novo conjunto de características que todos tentaram copiar ou se equiparar. Todo modelo novo, quer seja do Android, quer seja do Palm Pre, é comparado pelo fabricante ou mesmo pela mídia como um ‘iphone killer’. Na verdade considero que o iPhone esteja em uma categoria a parte. Seu enorme sucesso se deve a vários fatores, um deles o seu posicionamento não como um smartphone, cuja missão primária é o trabalho, mas sim como um veículo de entretenimento. Com sua tela e capacidades multimídia ele é a escolha preferida de quem deseja um MP3 player, uma câmera e plafaforma de jogos em um só aparelho. Nesse aspecto acredito que o mercado de smartphones, da qual a RIM é campeã, deva se preocupar com o Android e o Pre, e não com o iPhone. E você o que acha? Qual o seu smartphone preferido? Participe da pesquisa clicando aqui. O uso de frameworks para auxiliar no desenvolvimento tem crescido nos últimos meses impulsionado pela promessa de um desenvolvimento mais ágil. Na mesma proporção entretando é possível encontrar reações adversas ao seu uso. Em ambos os casos muitas das reações não possuem uma fundamentação adequada para explicar o por que cada lado defende a sua opção. Proponho uma avaliação dessas reações (e suas razões) de maneira a facilitar o processo de decisão : usar ou não usar um framework. Antes entretanto precisamos definir o que é um framework. O que é um framework? Existem várias definições sobre o que é um framework mas este é normalmente utilizado para explicar uma biblioteca de código e suas convenções que provêem uma infra-estrutura para o desenvolvimento. Desta maneira aqueles que adotem um framework tem, sem necessitar desenvolver nenhum código adicional, acesso a um número de funcionalidades geralmente comuns a várias aplicações. A alternativa ao não uso de um framework é o de desenvolver in-house tudo que se necessita, usando possivelmente apenas as diretivas nativas da linguagem de programação que foi escolhida. Argumentos para não se usar um framework
Primeiramente é importante reconhecer que qualquer framework irá oferecer uma penalidade em termos de performance. Ao inserir componentes genéricos e com graus diferentes de adaptabilidade, são introduzidas camadas de abstração que explicam a maior ou menor penalidade. Um framework também introduz uma curva de aprendizado com maior ou menor inclinação. Afinal as convenções ou mesmo a API, por não ter sido desenvolvida por você, deverão ser conhecidas e dominadas. Argumentos para se usar um framework
Ao usar um framework você evita de ter que desenvolver internamente todas as funcionalidades que você precisa. Todos os frameworks trazem componentes pré-testados para realizar um conjunto de operações comuns. Deseja gerar um PDF? Use o componente do framework. Deseja uma classe de acesso ao banco de dados? Use o componente do framework e por aí vai. O que fazer? Os argumentos de quem defende o uso de framework apontam normalmente para a agilidade no desenvolvimento, ao deixar que os aspectos mais comuns das aplicações sejam cuidados pelo framework enquanto os itens específicos fiquem a cargo do desenvolvimento em si. Os argumentos de quem defende que não seja usado um framework indicam que um framework impõe um overhead muito grande, com penalidades em performance e que dificultam por impor uma estrutura rígida. Existem aqueles que resistem por achar que serão capazes de fazer algo melhor do que existe nos frameworks. Como quase sempre a situação é que ambos estão certos em sua colocações e que o equilíbrio entre ambas é a melhor solução. Particularmente defendo o uso de framework mas que o mesmo seja feito com cuidado para evitar os problemas que uma adoção irrestrita normalmente acarreta. Novamente o que temos que evitar é a síndrome do silver bullet. Esta síndrome é aquela a qual a indústria é acometida de tempos em tempos ao adotar, quase que fanaticamente, uma determinada solução (metodologia, linguagem etc) como sendo a que irá resolver todos os problemas ou prover ordens de grandeza de melhoramento no processo. Quem acompanha se recorda do Delphi/Visual Basic como sendo as ferramentas que iriam resolver os problemas. Depois foi a vez do Java e C# e mais recentemente tivemos no Ruby on Rails o posto de nosso salvador. A pergunta que temos que fazer não é mais se devemos ou não usar um framework e sim “Qual framework devo usar?” Qual framework usar? É claro que não existe um framework perfeito. Todos eles tem que fazer escolhas e com isso concessões são feitas. Alguns oferecem mais ou menos componentes, alguns impõem uma estrutura rígida a qual seu aplicativo deve seguir etc. Como fazer então para decidir? Além da linguagem do mesmo proponho então algumas recomendações na escolha de um framework: a) Código-fonte aberto Ao adotar um framework de código aberto você tem a oportunidade de ver como o mesmo é feito, aprender o que de bom (e ruim) o mesmo tem e propor mudanças e melhoramentos. Se o framework for descontinuado você tem a chance de continuar o desenvolvimento. b) Comunidade de suporte existente e ativa Qualquer framework trará com si vários desafios, quer seja no aprendizado do uso, quer seja na manutenção e crescimento do mesmo. Quanto maior for a comunidade do mesmo mais facilmente será a ajuda, a identificação de possíveis problemas e a colaboração com novos componentes ou melhoramentos dos já existentes. c) Possui política de segurança Como segurança é um fator crítico em qualquer projeto de software, o framework e a sua comunidade devem possuir uma política para tratamento de incidentes de segurança e auditoria do código. Isso minimiza a ocorrência de problemas e permite que eventuais problemas sejam mais facilmente resolvidos. d) Segue as boas práticas Periodicamente as boas práticas na área de desenvolvimento são acrescidas de novas técnicas. O framework escolhido deve adotar essas práticas como sendo um indicador que o mesmo se mantem atual. Uso de design patterns, orientação a objeto, unit testing, controle de versão são algumas das práticas desejáveis nos frameworks que você considerar usar. O mercado de desenvolvimento de software sempre foi dividido segundo várias categorias : a) Cliente-servidor Há pouco tempo uma nova categoria apareceu : móvel Inicialmente tímida esta categoria, voltada para celulares, parecia estar fadada a ter uma participação pequena, quer seja em faturamento, quer seja em procura. O que encontrávamos na maioria eram pequenos jogos, alguns que lembravam os que existiam há 20 anos na plataforma Atari/MSX. Foi somente com o aparecimento dos smartphones e mais precisamente com o iPhone que tudo mudou. Os aparelhos com telas maiores, capacidade de processamento e memória elevados permitiram ter aplicativos realmente interessantes e cuja interatividade é passível de comparação com o ambiente desktop tradicional. Hoje a loja da Apple já ultrapassou mais de 1 bilhão de downloads de aplicativos, entre pagos e gratuitos, e fez com toda a indústria se modificasse. Os demais players do mercado como Google (Android), RIM (Blackberry) e mesmo a esquecida Palm (Pre) fizeram questão de apresentar as suas versões para não ficar de forma do mercado. Isso nos leva a considerar o mercado móvel com outros olhos dada a perspectiva de crescimento para os próximos anos. E ao fazê-lo temos uma nova decisão a tomar: que plataforma seguir? Apesar de características cada vez mais em comum (telas touch screen, multigesture, acelerômetro) as principais plataformas tem diferenças quanto a metodologia e ferramentas de trabalho. Hoje temos essencialmente a seguinte situação: É fácil notar que cada um adotou uma solução com vantagens e desvantagens. A Apple favoreceu o ambiente já nativo para os desenvolvedores daquela plataforma. Objective C é muito parecido com o tradicional C que muitos já programaram. Com isso reduziu a barreira de entrada para a adoção desta plataforma para quem já programava para a Apple. O Google escolheu o Java, o que facilita para aqueles que já tem experiência com a linguagem, quer seja no ambiente desktop, quer seja no ambiente móvel – com o Java ME. De todos a Palm foi a que talvez tenha feito a escolha mais estranha para alguns e mais natural para outros. Com a convergência do ambiente Web como ‘a plataforma’ a Palm decidiu que as mesmas ferramentas e conhecimentos usados para o desnvolvimento de sites seria possível de ser usado. Decisões técnicas a parte uma das maiores dúvidas está em que cavalo apostar. Não é possível esperar que a mesma equipe detenha conhecimentos para desenvolver em todas as plataformas. Assim se tivermos que escolher em qual iremos nos especializar? Apesar da escolha estranha para os padrões atuais, nos quais se espera Java, C# ou alguma linguagem interpretada, a Apple aparece com uma grande vantagem. Como ela controla o hardware hoje, quem desenvolve para o iPhone tem uma padronização quanto a várias características, quer seja do tamanho da tela quanto das funcionalidades do hardware. A mesma coisa não se pode dizer do Android, que possui um número ainda pequeno, mas suficientemente diferente de aparelhos que tornam o desenvolvimento mais difícil. Corre-se o risco de desenvolver aplicativos ligeiramente diferentes ou para modelos específicos e fragmentar a sua audiência. É difícil fazer qualquer previsão mas tenho grandes expectativas quanto ao Pre (talvez por ser usuário de Palm há mais de uma década) como plataforma corporativa (competindo com o Blackberry) e o iPhone no mercado de entretenimento/mídia. Dentre os vários assuntos pelos quais me interesso/atuo o desenvolvimento de software é um dos que mais vejo controvérsias quanto a metodologias, técnicas e recomendações visando garantir resultados. Design Patterns, RUP, Agile, Extreme Programming, Design by contract, Java Server Faces, Spring, Hibernate e Ruby on Rails são alguns dos termos mais encontrados na literatura atual quando se trata de desenvolvimento de software. A dúvida que todo desenvolvedor, analista, gerente ou cargo diretamente relacionado com produção de software tem passa invariavelmente em como realizar seu trabalho de maneira que o resultado:
Por mais simples que os pontos acima pareçam na prática vemos que o resultado é diferente. Dependo da fonte é possível ter referências entre 70 a 90% dos projetos de software falham em um ou mais dos tópicos citados. É com frequência que vemos novas (ou nem tanto) tecnologias, metodologias ou mesmo filosofias de trabalho que me maior ou menor grau prometem resolver todos os problemas. Nesse sentido é possível encontrar centenas de livros que abordam esta ou aquela técnica. Como qualquer um que se interessa pelo assunto procuro colocar minhas crenças à prova e me aventurar nessas novidades, sempre à procura de insights e práticas que tragam ganhos reais no projeto final. Assim me aventurei a ler o livro “Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software“. O que me chamou a atenção , além das revisões dadas por outros leitores, foi o próprio título, mais especificamente as partes de ‘Dreaming in Code’ e ‘Quest for Transcendent Software’. Acredito que se chegarmos ao ponto de sonhar em código e vencer o desafio de produzir um software com características excepcionais, teremos nos aproximado do ponto qual software certo, no prazo e custo serão uma norma e não excessão. Confesso que no primeiro momento, após as primeiras páginas, achei que tinha feito uma escolha errada. O livro, diferentemente de outros que tratam de desenvolvimento (Ex. Code Complete, Pragmatic Programmer), é escrito em uma forma quase que ‘novelesca’ ao contar até a cronologia dos eventos que acompanham o autor e outros ‘atores’ do processo. Pensei que estivesse lendo um livro de auto-ajuda para desenvolvedores de software em crise existêncial e por pouco não encostei o livro para outra ocasião. Felizmente avancei na leitura e passei a acompanhar as ‘aventuras’ dos desenvolvedores e seus desafios, sempre encontrando paralelos com situações pelas quais já passei dentro dos vários papeis que desempenhei nos últimos 15 anos. Desde já quero recomendá-lo para todos que atuam na área, quer seja como programadores, quer seja como gestores do processo. O livro, diferentemente de outros, não tenta vender nenhuma metodologia, ferramenta, técnica ou linguagem como sendo a melhor ou a que irá resolver todos os problemas. Em vez disso ele provoca a reflexão e apresenta idéias que deram certo e errado no desenvolvimento, ainda hoje não terminado, de um projeto desafiador. Links: |
|||||
|
Copyright © 2010 Bicatu - All Rights Reserved |
|||||
