JavaFx/Introdução
Dispensamos comentários a respeito do Java que é a linguagem de origem (do projeto atual) do JavaFx (Linguagem de Script Orientada a Objetos). O que percebemos pela estrutura de organização do projeto lançado pela Sun Mycrosystems e adquirido pela Oracle é que todo o projeto inicial foi repensado criando um promissor e envolvente segmento.
Em setembro de 2005 a empresa SeeBeyond Technology Corporation desenvolveu um projeto chamado F3 (Form Follows Function) que era baseado em uma linguagem interpretada e tinha como seu responsável criador Chris Oliver. A Sun comprou a empresa e Chris Oliver tornou-se funcionário. F3 foi alterado para o nome atual e se tornou open source no JavaOne 2007.
Em um curto espaço de tempo JavaFx evoluiu e adaptou-se a ponto de tornar comandos e técnicas de produção das antigas versões incompatível e improdutiva (diferenças entre as versões 1.0 e 2.0), onde mesmo os desenvolvedores habituado com produção direta com Java utilizando atualmente JavaFx, precisaram reorganizar conceitos e técnicas para acompanhar a realidade tecnológica (conceito abordado a respeito do profissional e da linguagem adaptar-se a realidade). Não é correto afirmar que JavaFx, devido ao seu grau de evolução seja superior ao Java mas concordamos que é o resultado de um processo evolutivo. A linguagem incorporou o CSS, HTML, JavaScript e XML diretamente em sua produção adaptando algumas delas para seu ambiente, como é o caso do XML que foi criado um "dialeto" com o nome FXML que serviu para um ambiente voltado para criação de layout.
Entre os diversos modelos de desenvolvimento dentro da tecnologia JavaFx, a Oracle aprimorou um método de trabalho que mudou as regras para criação de telas utilizando a linguagem FXML. Uma API (Scene Builder) cria o layout e grava em arquivos interpretados pelo JavaFx. Uma técnica simples, rápida e elegante para desenvolver aplicativos sem carregar o código principal da aplicação e que pode ser implantado em diversos projetos, inclusive os projetos para Computação em Nuvem.
Desenvolvedores sabem que design gráfico, programação e banco de dados são habilidades distintas. Designers gráficos ou Webdesign focam na interação humana com a aplicação e seu objetivo maior é manter o interesse humano e tornar o sistema mais intuitivo usando técnicas audiovisual. Os Desenvolvedores ou Programadores estão tipicamente preocupados em implementar lógica de negócio e interagir com os servidores back-end usando conceitos de Programação Orientada a Objetos. Por outro lado os Data Bank Administrator (DBA) estão com o foco na linguagem para estrutura de armazenamento dos dados seguindo conceitos como consultas, relacionamentos, transação e replicação. É uma espécie rara os que possuem as três habilidades. O nosso objetivo é construir ligação entre este segmentos produtivo. O designer gráfico se aprofunde no visual do empreendimento, o desenvolvedor implemente as regras do negócio enquanto o DBA se preocupe com o método de armazenamento.
Para entendermos JavaFx com maior facilidade vamos imaginar um ambiente de desenvolvimento corporativo, pois, o conceito de errar passa a ter um significado diferente daquele que temos em um ambiente puramente didático, no ambiente de trabalho erro significa perda de tempo e prejuízo mas que a regra é comete-los em menor número já que não podemos evita-los. Para isto a empresa cria mecanismos e conceitos como equipe de trabalho, organização, qualidade, produtividade e disciplina e a experiência cria as normas e regras a serem cumpridas. Novas idéias e conceitos devem sempre ser incentivados dentro do ambiente de trabalho, desde que os riscos sejam estudados e os resultados analisados pela lógica e pela razão.
A inspiração vem de uma empresa focada no ramo de produção de aplicativos multiplataforma constituída do quadro de funcionários contendo Analista de Sistemas, Engenheiros, Desenvolvedores, Operadores, outros profissionais e departamentos necessário. O leitor assumirá o cargo de Desenvolvedor e acompanhará de perto todas as etapas do projeto, assumindo riscos, cometendo erros e ajudando a equipe a superar dificuldades e corrigir falhas.
A Direção da empresa solicita evitar utilização de módulos, classes, componentes e ferramentas de terceiros que venham causar qualquer tipo de dependência principalmente aquelas que dificultam ou proíbem acesso ao código original. Poderá ser utilizado API e/ou Frameworks nativos ou de empresas, organizações e instituições comprometidas em contribuir para o avanço tecnológico da linguagem, oferecendo serviços com clareza e transparência sem nunca inserir no código do projeto rotinas que sejam obscuras ou desvie do conceito original provocando falta de controle e compreensão. Ciência e tecnologia aplicada a experiência com resultado de sucesso comprovado conta muito para um trabalho concluído, portanto deveremos optar sempre pela técnica de reaproveitamento como forma de agilizar a produtividade, reinventar a roda é perda de tempo, o que faremos é o reaproveitamento de técnicas aplicada com sucesso e adaptando-as a nossa necessidade.
Produzir com técnicas para multiplataforma implica em reduzir ao máximo o consumo dos recursos dos dispositivos pelos aplicativos produzidos. Portanto tornar a empresa produtiva evitando métodos complexos e adotar simplicidade é desafio e o lema para todos participantes deste (projeto) livro.
"A leitura traz conhecimento, mas para o bom profissional, apenas conhecimento não é suficiente. É preciso experiência. Para adquirir experiência é necessário praticar. A prática requer sucessivas tentativas entre erros e acertos, falhas e sucessos. Portanto é sábio dizer que muitos afirmam que sabem, alguns fazem mesmo sem saber e poucos sabem o que faz."
Antes de iniciarmos nossos trabalhos precisamos estabelecer as hierarquias, efetuar a ordenação e o agrupamento de atividades e recursos, ou seja, precisamos esclarecer a Estrutura Organizacional para podermos alcançar os objetivos e resultados do nosso empreendimento. Se a empresa efetua esta tarefa de forma adequada aumenta significativamente as chances de alcançar resultados positivo no projeto proposto pois deixa claro aspectos como:
•Identificação das tarefas necessárias ao alcance dos objetivos estabelecidos;
•Organização das funções e responsabilidades;
•Informações, recursos e feedback aos membros envolvidos;
•Medidas de desempenho compatíveis com os objetivos; e
•Condições motivadoras para a realização das tarefas estabelecidas.
Sabemos que este assunto se estende e não vamos nos aprofundar, por isso efetuaremos um comparativo entre uma empresa de Desenvolvimento de Software e uma de Arquitetura na Construção Civil que trata de uma área de conhecimento mais popular e de fácil compreensão.
Construir uma casa, mesmo que seja a mais simples, é necessário um projeto. Um programa ou aplicativo simples não foge da regra, a base fundamental do aplicativo é o Banco de Dados e a casa tem como base o alicerce. Em ambos os casos uma estrutura mal construída implicara em problemas futuro. O Analista de Sistemas e o Arquiteto tem como função principal a interpretação e representação gráfica das necessidades do cliente. Construir Plantas ou ciar Fluxogramas/UML tem o mesmo objetivo. Não se importam com a estrutura mas com o design e aparência.
Interpretar as Plantas e Fluxogramas é a função do "Engenheiro" que determina terreno, material e Pessoal (Ajudantes, Eletricistas, Encanadores, Mestre de Obras e etc.) no caso da realização do projeto da casa e equipamento, linguagem e Desenvolvedores (DBA, Programadores, Designers, Desenvolvedor de relatórios, etc.) no caso de realização do projeto do aplicativo.
Fica claro que foi definida a Organização das funções e responsabilidades dentro da empresa:
•Analise
•Engenharia
•Desenvolvimento
Em momento oportuno, abordaremos Analise e Engenharia de Sistemas que são áreas promissoras e envolventes, neste momento voltamos nossa atenção para as regras e técnicas utilizada pela empresa repassadas para a equipe de desenvolvimento.