Arquivo da tag: linux

40 anos de evolução das shells

Uma verdade que não se pode negar, ou rebater, é que as shells estão aí para ficar, mesmo que cada vez mais só nos bastidores, em modo não-interativo, ou nas mãos de usuários experientes, que apreciam seus recursos.

Mas você sabia que a shell original – o primeiro /bin/sh, escrito por Ken Thompson – surgiu há quarenta anos, em 1971 (dois anos depois do nascimento do próprio Unix) e tinha menos de 900 linhas de código? Isso porque boa parte do que hoje conhecemos como comandos builtin da shell (incluindo elementos essenciais, como o if), na época, eram apenas utilitários externos, até mesmo recursos como o glob (que “interpreta” caracteres especiais como * e ? em parâmetros correspondentes a nomes de arquivo) eram implementações à parte, e a shell era exclusivamente interativa. A capacidade de interpretar scripts veio mais tarde.

Em compensação, recurso,s como pipes (| ou, na época, ^) e redirecionamento de entrada e saída (<, >, >>, etc.) já estavam presentes.

Daí pra frente a evolução foi acelerada: Stephen Bourne criou a Bourne Shell (que ainda pode ser vista em sistemas contemporâneos) em 1977, fazendo a base do que no final da década de 1980 surgiu como o mestiço /bin/bash (Bourne Again Shell) que hoje vemos como shell default em boa parte das distribuições Linux, do OS X e de outros sistemas UNIX e Unix-like atuais.

Um livro que trata do assunto e está sendo muito comentado pelos profissionais é o Bombando o Shell, do Júlio Neves. O foco do livro está na interatividade das shells, incluindo o controle de diálogos em modo gráfico.

Com informações de BR-Linux.org

Fonte: IMasters

Um guia para pacotes Python

O principal para um projeto de software livre de sucesso é o pacote. Um ingrediente chave para um bom pacote é a versão. Como o projeto é de software livre, o ideal é publicar o pacote para aproveitar os muitos benefícios que a comunidade de software livre oferece.

Diferentes plataformas e linguagens têm mecanismos diversos para pacotes, mas este artigo se concentra especificamente em Python e seu ecossistema de pacotes. O artigo discute mecânica de pacotes para oferecer uma base e fornece exemplos práticos suficientes para que o leitor comece imediatamente.

Por que se preocupar com pacotes?

Além de ser a coisa certa a se fazer, há três motivos práticos para empacotar software:

  • Facilidade de uso
  • Estabilidade (com versões)
  • Distribuição

Tornar a instalação do aplicativo o mais simples possível é uma questão de consideração para com os usuários. Pacotes tornam o software mais acessível e mais fácil de instalar. Se for mais fácil de instalar, será mais fácil para que usuários comecem a usar o software.

Ao publicar um pacote no Python Package Index (PyPI), ele poderá ser facilmente acessado por meio de utilitários como pip oueasy_install.

Além disso, ao criar versões de pacotes, o desenvolvedor permite que os usuários “fixem” a dependência que seus projetos têm em relação ao software a uma versão em particular. Por exemplo, fixar Pinax para a versão 0.9a2.dev1017 seria expresso como:

Pinax==0.9a2.dev1017

Isso forçaria o projeto a usar o release 0.9a2.dev1017 do Pinax.

Versões garantem maior estabilidade caso sejam lançadas alterações de releases para seu software mais tarde que possam ter quebra de interfaces. Permitem aos usuários saber exatamente o que estão obtendo e facilitam para eles acompanhar as diferenças em releases.

Além disso, os desenvolvedores de projeto podem saber exatamente para o que estão criando código.

Um método comum para publicar pacotes no PyPI (ou em um servidor de distribuição próprio) é criar uma distribuição de origem para upload. Uma distribuição de origem é uma maneira padrão de empacotar a origem de seu projeto como uma unidade distribuível.

Há maneiras de criar distribuições binárias, mas, para o software livre, faz sentido também distribuir a origem.

Criar distribuições de origem facilita o uso de ferramentas que procuram o software na Internet, fazem download e instalam automaticamente. Esse processo ajuda não só no desenvolvimento local, mas também nas implementações do software.

Portanto, ao tornar mais fácil para usuários integrar e instalar o software, usar boas versões que permitem uma técnica confiável de fixação e publicar o pacote para distribuição mais ampla, você terá uma chance maior de que seu projeto tenha sucesso e obtenha aprovação ampla. Aprovação ampla pode levar a mais contribuidores — algo que certamente todo desenvolvedor de software livre deseja.

Anatomia de um arquivo setup.py

Um dos propósitos do script setup.py é servir como o executável que pode ser executado para empacotar o software e fazer upload para servidores de distribuição. O script setup.py pode variar bastante em conteúdo conforme você navega pelos repositórios Python populares. Este artigo se concentra no básico.

O arquivo setup.py pode ser usado para muitas tarefas diferentes, mas aqui você cria um que permitirá executar os seguintes comandos:

python setup.py register
python setup.py sdist upload

O primeiro comando, register, toma as informações fornecidas na função setup() no script setup.py e cria uma entrada no PyPI para seu pacote. Ele não faz upload; em vez disso, cria os metadados sobre o seu projeto, de modo que posteriormente seja possível fazer upload e hospedar os releases lá.

Os próximos dois comandos estão encadeados: sdist upload desenvolve uma distribuição de origem e faz upload dela para o PyPI. Mas há alguns pré-requisitos, como configurar seu próprio arquivo de configuração .pypirc e escrever efetivamente o conteúdo de setup.py.

Primeiro, configure o arquivo .pypirc. Ele deve estar em seu diretório inicial, que varia dependendo do sistema operacional. No UNIX®, Linux® e Mac OS X, chega-se lá digitando cd ~/. O conteúdo do arquivo deve conter suas credenciais PyPI, como mostrado abaixo:

[distutils]
index-servers =
pypi
 
[pypi]
username:xxxxxxxxxxxxx
password:xxxxxxxxxxxxx

Em seguida, acesse o PyPI e registre uma conta (não se preocupe, é grátis). Coloque o mesmo nome de usuário e senha criados no PyPI em seu arquivo .pypirc e nomeie o arquivo ~/.pypirc.

Agora, ao criar o script setup.py, é preciso decidir o que será exibido na página de índice do PyPI e qual será o nome do projeto. Comece copiando um modelo de setup.py que eu uso para projetos (consulte a listagem abaixo).

Ignorando as importações e funções, olhe para a parte inferior do modelo, para o que precisa ser mudado para se adequar ao seu projeto.

PACKAGE = ""
NAME = ""
DESCRIPTION = ""
AUTHOR = ""
AUTHOR_EMAIL = ""
URL = ""
VERSION = __import__(PACKAGE).__version__
 
setup(
name=NAME,
version=VERSION,
description=DESCRIPTION,
long_description=read("README.rst"),
author=AUTHOR,
author_email=AUTHOR_EMAIL,
license="BSD",
url=URL,
packages=find_packages(exclude=["tests.*", "tests"]),
package_data=find_package_data(
PACKAGE,
only_in_packages=False
),
classifiers=[
"Development Status :: 3 - Alpha",
"Environment :: Web Environment",
"Intended Audience :: Developers",
"License :: OSI Approved :: BSD License",
"Operating System :: OS Independent",
"Programming Language :: Python",
"Framework :: Django",
],
zip_safe=False,
)

Primeiro, observe que este modelo espera que o projeto tenha dois arquivos diferentes. O primeiro é usado para long_description: ele lê o conteúdo do arquivo README.rst que está no mesmo diretório que setup.py e passa o conteúdo como uma cadeia de caracteres para o parâmetro long_description.

Esse arquivo preenche a página de entrada no PyPI, portanto é bom descrever brevemente o projeto e mostrar exemplos de uso nesse arquivo. O segundo arquivo é __init__.py . Ele não é mencionado explicitamente aqui, mas a linha que define a variável VERSION importa o pacote; e quando isso acontece, Python precisa de um arquivo __init__.py e espera uma variável definida naquele módulo, chamada __version__.

Por enquanto, basta defini-la como uma cadeia de caractere:

# __init__.py
__version__ = "0.1"
 

Agora vamos ver as demais entradas:

Package é o pacote Python no projeto. É a pasta de nível superior que contém o módulo __init__.py que deve estar no mesmo diretório que o arquivo setup.py — por exemplo:

/-
|- README.rst
|- setup.py
|- dogs
|- __init__.py
|- catcher.py
 
Portanto,
 
dogs

seria o pacote aqui.

  • Name é geralmente o mesmo que Package ou semelhante, mas pode ser qualquer coisa. Name é como as pessoas chamarão o software, o nome pelo qual ele será listado no PyPI e — o mais importante — sob o qual os usuários irão instalá-lo (por exemplo, pip install NAME).
  • Description é apenas uma breve descrição do projeto. Uma frase é o bastante.
  • Author e Author_Email são o que parecem: o nome e endereço de e-mail do autor. Essas informações são opcionais, mas é uma boa prática fornecer um endereço de e-mail caso as pessoas queiram entrar em contato com você devido ao projeto.
  • URL é a URL do projeto. Essa URL pode ser o Web site do projeto, repositório Github ou qualquer URL que você queira. Novamente, essas informações são opcionais.

Pode ser útil também fornecer a licença e classificadores. Para mais informações sobre a criação de um arquivo setup.py, consulte a documentação do Python logo abaixo em Recursos.

Versão

Versões podem facilmente ser um tópico próprio, mas vale a pena mencioná-las no contexto de pacotes, pois um bom empacotamento envolve versões apropriadas. Versões são uma maneira de comunicar-se com o usuário: também permite que os usuários desenvolvam mais estabilidade e confiabilidade em seus aplicativos.

Com versões, o desenvolvedor diz aos usuários que ele mudou algo e dá limites explícitos para onde essas mudanças ocorreram.

Um padrão para versões em pacotes Python pode ser encontrado em Python Enhancement Proposal (PEP) 386. Essa proposta declara regras pragmáticas.

Mesmo que você não tenha lido e entendido a PEP, ou mesmo que não concorde com ela, seria sábio segui-la, pois mais e mais desenvolvedores Python estão acostumados a vê-la.

Além disso, versões não são apenas para releases estáveis transferidos por upload para PyPI, mas também são úteis para releases de desenvolvimento usando o sufixo devNN.

Geralmente não é bom fazer upload dessas versões de desenvolvedor para o PyPI, mas você ainda pode configurar seu próprio servidor de distribuição público (ou privado) para disponibilizá-las; dessa forma, usuários que queiram usar a versão mais recente podem citar isso em seu arquivo requirements.txt do pip. Aqui estão alguns exemplos de versões:

1.0.1        # 1.0.1 final release
1.0.2a       # 1.0.2 Alpha (for Alpha, after Dev releases)
1.0.2a.dev5  # 1.0.2 Alpha, Dev release #5

Publicação

As pessoas geralmente não irão localizar e instalar software que não tenha sido publicado. Na maioria das vezes, você deve publicar seus pacotes no PyPI.

Após configurar o arquivo de configuração .pypirc, o comando upload passado para setup.py transmite seu pacote para o PyPI. Geralmente isso é feito em conjunto com o desenvolvimento de uma distribuição de origem:

python setup.py sdist upload
 

Se você estiver usando seu próprio servidor de distribuição, inclua uma seção para autorização em seu arquivo .pypirc para esse novo local, e indique-o por nome ao fazer o upload:

python setup.py sdist upload -r mydist

Configurar seu próprio servidor de distribuição

A principal razão para usar um servidor de distribuição próprio em software livre é oferecer um lugar para publicar releases de desenvolvedor, pois o PyPI deve consistir apenas de releases estáveis. Por exemplo, você provavelmente quer que instale o release estável mais recente localizado no PyPI:

pip install MyPackage

No entanto, se posteriormente você instalar releases de desenvolvedor, esse comando acabará instalando o release mais recente, o que significa o de desenvolvedor.

É geralmente bom fixar um release, mas nem todos os usuários fazem isso. Portanto, garanta que o release estável mais recente seja sempre retornado se o usuário não especificar um número de versão.

Uma maneira de ter as vantagens tanto de um método (expor apenas releases estáveis para padrão do pip) como do outro (permitir que os usuários instalem pacotes de releases de desenvolvedor) é hospedar um servidor de distribuição próprio. O projeto Pinax faz isso para todos os seus releases de desenvolvedor.

O servidor de distribuição é apenas um índice, servido em Protocolo de Transporte de Hipertexto (HTTP), de arquivos no seu servidor. Deve ter a seguinte estrutura de arquivos:

 
/index-name/package-name/package-name-version.tar.gz

Dessa forma, é possível tornar o servidor privado configurando Basic-Auth no servidor da Web. É uma boa ideia incluir alguns recursos para upload de distribuições de origem também.

Para isso, é preciso incluir código para lidar com o upload, analisar o nome do arquivo e criar os caminhos de diretório para corresponder ao esquema acima. Essa estrutura existe para o projeto Pinax, que hospeda diversos repositórios.

pip e virtualenv

Embora este artigo tenha se concentrado primariamente na criação de pacotes, esta seção descreve o consumo de pacotes, oferecendo um pouco de apreciação para o que bons pacotes e versões fazem para os usuários.

pip é uma ferramenta que pode ser instalada diretamente, mas eu recomendo usá-la como parte de virtualenv. Recomendo usar virtualenv para tudo relacionado a Python, pois mantém os ambientes Python limpos.

Assim como uma máquina virtual permite executar diversos sistemas operacionais lado a lado, virtualenvs permitem executar diversos ambientes Python lado a lado. Eu não instalo nada no Python do meu sistema; em vez disso, crio um novo virtualenv para cada novo projeto ou utilitário em que trabalho.

Agora que você instalou virtualenv, pode brincar um pouco:

$ mkvirtualenv —no-site-packages testing
$ pip install Pinax
$ pip freeze|grep Pinax
$ pip uninstall Pinax
$ pip install —extra-index-url=http://dist.pinaxproject.com/fresh-start/
Pinax==0.9a2.dev1017
$ pip freeze|grep Pinax

Observe que a primeira instalação do pip foi transferida por download e instalada a partir do PyPI. pip freeze mostra todas as versões de pacotes instalados no virtualenv atual. pip uninstall faz exatamente o que você imagina: remove-se do virtualenv.

Em seguida, você instala uma versão de desenvolvedor do repositório novo para obter a versão de desenvolvimento do Pinax versão 0.9a2.dev1017.

Não é preciso ir para Web sites, fazer download de tarballs e criar links simbólicos para um pacote no site. (Era assim que eu costumava fazer, e causava muitos problemas.) Seus usuários obtêm tudo isso como resultado de bons pacotes, publicação e versões de seu projeto.

Conclusão

Em suma, vale muito a pena aprender a arte e ciência dos pacotes. Você obterá uma adoção maior dos usuários devido à facilidade de instalação e estabilidade que a divisão dos pacotes em versão oferece a eles.

Usando o modelo de setup.py fornecido abaixo em Recursos e discutido neste artigo, deve ser possível incluir pacotes em seu projeto rápido e facilmente. Comunicar-se com seus usuários por meio de versões apropriadas é uma questão de consideração com eles, pois facilita o rastreamento de mudanças entre releases.

Por fim, à medida que pip e virtualenv aumentam sua adoção, a confiança nos pacotes publicados — seja no PyPI ou em um servidor de distribuição próprio — aumenta. Portanto, não deixe de publicar os projetos que você quer compartilhar com o mundo.

Fonte: developerWorks Brasil/IMasters

Python volta a ganhar o premio de melhor linguagem de programação

O Python novamente ganhou o prêmio de melhor linguagem de programação oferecido pela Linux Journal, uma das revistas de referência dedicada a sistemas operacionais, e uma das mais populares entre os programadores amadores. E essa já é a terceira vez. O Python voltar a se impor ante seu mais ardente rival, o clássico C++, que ficou 6% atrás nas pesquisas.

Para aqueles que não estão familiarizados com o assunto, o Python é uma linguagem de programação de alto nível e muito jovem, já que sua primeira versão foi lançada há 20 anos em 1991. Sua vantagem sobre os demais é que é muito fácil de usar, com uma sintaxe que se caracteriza pela sua simplicidade e limpeza. Para se ter uma idéia, o clássico “Hello World”, exemplo comum em linguagens de programação para mostrar como se imprime uma linha na tela, você pode conseguir com esta simples sentença: print “Hello World”.

Fácil, não? Atualmente se encontra em sua versão 3.2 e já tem se consolidado o suficiente para influenciar outras línguas no mundo da programação, a qual tem crescido ainda mais.

Estas foram algumas das características que deram ao Python o posto de melhor linguagem de programação, mas destacamos principalmente, a facilidade com que se pode iniciá-lo e começar a trabalhar nele. Python é sinônimo de simplicidade e potência, duas palavras que devem ir juntas e que fazem com que algo esteja em mudança no mundo da linguagem de programação graças a linguagens como está.

Fonte: Auricelio Barbosa/forumpc

PyPy 1.7: o mais rápido interpretador de Python, ainda mais rápido

Foi lançado nesta semana, o PyPy 1.7, nova versão do interpretador da linguagem Python escrito inteiramente em Python. O principal foco desta versão foi o aumento de desempenho de bibliotecas, em relação ao CPython e ao próprio PyPy 1.6.

O PyPy é uma alternativa a outros interpretadores como CPython (o padrão), Jython e IronPython, e de acordo com os diversos benchmarks publicados, o mais rápido entre eles. Segundo os desenvolvedores do projeto, “se alguma implementação for mais lenta que o interpretador CPython, então é um bug”.

A performance excepcional do PyPy se deve principalmente ao seu compilador JIT. O interpretador já é suportado em Linux 32/64, MacOS 32/64, mas o atual release (com JIT) ainda não foi concluído para o Windows.

Algumas funcionalidades estão em fase avançada de desenvolvimento, mas ainda não ficaram prontas para este release:

  • Implementação especializada de listas: Está já em fase de testes a implementação de listas de inteiros/float/string compactadas como um array de arrays, o que deve aumentar a perfomance e reduzir o consumo de memória de algumas aplicações.
  • Duas novas implementações do compilador JIT direcionadas aos processadores PowerPC e ARM

Para conhecer mais sobre o PyPy, fazer o download ou ajudar nos testes da plataforma, visite a página oficial do projeto.

Fonte: Rafael Nunes/InfoQ

Fedora Linux 16 em detalhes: foco em cloud computing

A comunidade Fedora lançou a versão 16 da popular distribuição do Linux. Entre as principais novidades, estão o suporte ao Kernel 3.1, Gnome 3.2 e KDE Plasma 4.7, além de várias melhorias em relação ambientes de nuvem e virtualização.

Embora seja tradicionalmente voltada para desenvolvedores de projetos open source, oferecendo as últimas atualizações (potencialmente instáveis) destes projetos, a distribuição Fedora vem também sendo reconhecida como uma boa distribuição para usuários domésticos e corporativos. A nova versão foi dedicada pela comunidade a Dennis Ritche, um dos criadores da Linguagem C e do Unix.

Recursos para nuvem

Vários recursos de cloud computing estão embutidos no novo Fedora, com destaque para:

  • Aeolus Conductor – Interface web para gerenciamento de ambientes de nuvem de vários fornecedores, públicos e privados, por exemplo Amazon EC2, Rackspace, VMWare VSphere e Eucalyptus.
  • OpenStack e Condor Cloud – Duas opções que fornecem infraestrutura completa para criação nuvens privativas.
  • HekaFS – Antigo GlusterFS, é um sistema de arquivos de cluster com recursos de multitenancy para nuvem e criptografia OpenSSL.
  • pacemaker-cloud – Extensão do pacemaker (para do Red Hat Cluster Suite) para gerenciar disponibilidade e fail-over de aplicações e recursos em nuvem.
  • Matahari – Coleção de APIs e agentes para monitoramento e gerenciamento de sistemas.

Virtualização e mudanças para o administrador de sistemas

O Fedora é a base para o desenvolvimento do RHEL (Red Hat Enterprise Linux) e suas distribuição derivadas, como o CentOS. Assim o administrador de sistemas corporativo (também conhecido como sysadmin) tem no Fedora uma prévia do que virá em versões futuras destas distribuições; por exemplo:

  • Capacidade de inspecionar o conteúdo de arquivos em imagens de VM (read-only), e o conteúdo do Windows Registry armazenado nestas imagens.
  • Suporte a Dom0 do Xen (parte do kernel 3.1), de modo que não é mais necessário usar um kernel modificado com o Xen Server da Cytrix, Oracle VM e outros produtos baseados no Xen. O Dom0 é o domínio que realiza todas as operações de entrada e saída, para os demais domínios (VMs); ou seja, é ele quem fornece os drivers para o hypervisor.
  • Mudanças no processo boot, que agora usa Grub2, permite particionamento utilizando GPT em lugar do antigo MBR do MS-DOS (fim dos limites de tamanho das partições!) e suporta o Trusted Boot da Intel, quando disponível no hardware. O antigo subsistema HAL para detecção de novo hardware foi descontinuado, sendo substituído pelo udev e serviços relacionados.
  • Chrony, novo servidor NTP mais tolerante a relógios imprecisos de PCs e sistemas que passam longo tempo desconectados da internet, como notebooks e VMs que ficam suspensas frequentemente.
  • Ike (Shrew Soft VPN Client), novo cliente VPN que facilita o uso do IPsec.

Também há suporte ao compartilhamento de dispositivos USB 2.0 do host com máquinas virtuais KVM. Isso, somado ao suporte a SPICE, torna o Fedora Linux uma plataforma melhorada para virtualização de desktop. Um dispositivo USB também pode ser compartilhado com outras máquinas em rede.

Novidades para o desenvolvedor

O Fedora Linux traz recursos importantes para o desenvolvedor corporativo. É a distribuição do Linux com suporte mais abrangente ao Eclipse e outros recursos para desenvolvimento Java, PHP, Python e Ruby.

Entre as novidades do Fedora 16 para desenvolvedores, podemos destacar:

  • BE (Bugs Everywhere) – Um bug tracker integrado a sistemas de controle de versões distribuídos, para simplificar a gerência e o rastreamento de mudanças.
  • btparser – Ferramenta para análise de backtraces do gdb.
  • D2 – Nova linguagem que tenta reunir as vantagens de Java e C++.
  • WSO2 – Framework de Web Services SOA e WS-* para C++.

O OpenJDK 7 também é oferecido, mas apenas como Technology Preview. O Eclipse, o Tomcat e outras aplicações Java continuam sendo compiladas com o Open JDK 6. O motivo é a falta de um TCK (kit oficial de testes de compatibilidade/aderência) para o Java 7, de modo que empresas que usam o Fedora em produção podem preferir usar os downloads (proprietários) da Oracle. (Também foram descobertas diversas pequenas incompatibilidades entre bibliotecas Java populares e o Java 7, que não puderam ser resolvidas a tempo para o lançamento do Fedora 16.)

Novidades para usuários finais

Para usuários finais, a grande novidade é a inclusão do Gnome 3.2, que continua despertando reações ame-ou-odeie pela sua nova interface com desktop limpo e suporte a tablets. Um destaque é o gerenciamento integrado de contas de serviços internet (Google, Facebook, Jabber etc.) e de serviços de armazenamento em nuvem.

Entre as novas aplicações inclusas no Fedora 16, podemos citar:

  • Routino – Navegação via OpenStreetMaps.
  • WriteType – Ajuda crianças a escrever corretamente, com predição de palavras, autocorreção e suporte a voz para leitura.
  • Ease – Software de apresentações baseado no Cutter, integrado ao Gnome 3 e com interface otimizada para tablets.

Obtendo e instalando o Fedora 16

É possível baixar imagens ISO para mídias live em CD ou pendrive, ou então baixar um DVD (.iso) contendo os principais pacotes para servidores e desenvolvimento. É possível também usar uma mídia para instalação a partir da internet. Além disso, já estão disponíveis imagens prontas para nuvens Amazon.

Quem já tem o Fedora 15 ou versões anteriores, pode fazer uma atualização diretamente pelo gerenciador de atualizações gráfico da distribuição, ou pela ferramenta preupgrade.

É importante lembrar que o Fedora não inclui softwares proprietários, como alguns drivers para placas Wi-Fi e vídeo NVidia, ou codecs para MP3. Mas estes são facilmente instalados usando o EasyLife (que em breve estará atualizado para o Fedora 16), ou então o repositório RPM Fusion (já atualizado). Usuários habituados ao Debian e Ubuntu podem consultar este Guia de Transição do Ubuntu para Fedora.

Fonte: Fernando Lozano/InfoQ

Oracle propõe tornar o JavaFX open source

Recentemente, na conferência JavaOne, a Oracle disse que tem a intenção de tornar o JavaFX uma plataforma open source. Agora, a empresa está propondo formalmente que a toolkit JavaFX seja open source sob o projeto OpenJDK e está quer que ela seja incorporada ao Java 9. O arquiteto desktop da Oracle, Richard Bair, ao fazer a proposta, disse que a empresa já vinha conversando a respeito há muito tempo, “mas finalmente estão preparados para atuar nessa área”.

JavaFX foi criado pela Sun como uma tecnologia independente, com sua própria linguagem de script. Mas desde a aquisição da Sun pela Oracle, ela foi reposicionada como uma toolkit Java com uma moderna arquitetura, dando suporte para, por exemplo, aceleração de hardware e estilização utilizando CSS.

O projeto se chamará JFX e a Oracle espera que durante o processo uma comunidade se desenvolva em torno dele; o projeto inclui mais de 6 mil membros de APIs públicas, 11.500 unidades de testes, bibliotecas core, efeitos, suporte a CSS e a aceleração de hardware e controle UI e gráficos. Eles também esperam que a transparência vinda dos códigos open source irá melhorar a aceitação. O código já existe para portar uma camada que suporta Linux, Mac OS X e Windows.

Bair espera que existirá um JSR para JFX a tempo do Java 9, que incluiria JFX como “uma parte adequada do JDK”.A proposta dele formalizada por Iris Clark, que foi quem colocou a proposta para votação. Inicialmente, o projeto – que será liderado por Bair – terá o código JavaFX publicado pela Oracle, começando pelos controles UI. Ao longo dos meses, o código completo será publicado. O OpenJFX não dependerá dos binários por muito tempo. A votação deve ser concluída até o dia 16 de novembro.

Plano a longo prazo da Oracle é ver o JavaFX superar o toolkit UI já existente, como o Swing. Mas não há planos de remover o Swing do Java e é possível usar os dois em um aplicativo. O código fonte para o JavaFX deve ser lançado sob a GPLv2 com a exceção do Classpath.

Com informações de The H

Fonte: IMasters

Microsoft anuncia driver SQL Server para Linux

A Microsoft anunciou que está desenvolvendo um driver ODBC SQL Server para o Linux. A notícia foi anunciada pelo vice-presidente da corporação de sistemas de banco de dados da empresa, Quentin Clark, durante a PASS Summit 2011 deste ano. Também foi noticiado que a Microsoft está planejando portar a plataforma Hadoop MapReduce para Azure (lei a notícia completa aqui).

Em um post do blog MSDN, Brian Swift forneceu alguns detalhes específicos que ele conseguiu conversando com Shekhar Joshi, o gerente de programação do driver. A versão de pré-lançamento será para sistemas de 64-bit que rodam Red Hat Linux 5; o suporte para o Red Hat Linux 6 está planejado para o lançamento do RTM, e um driver de 32 bit já está em desenvolvimento. A versão para Linux do utilitário para SQL via linha de comando da Microsoft, o BCP para importar e exportar dados e o SQLCMD para consultas e roteiros SQL também serão incluídos.

A equipe de desenvolvimento está usando o driver ODBC do Windows como base, e está trabalhando para modificar o código para compilar sob o Linux. Swift disse que “a Microsoft tem trabalhado junto com parceiros para obter um feedback de lançamentos privados do driver”. Ele será lançado publicamente no outono.

Com informação de The H

Fonte: IMasters

WordPress, Drupal ou Joomla: qual a melhor solução para o seu projeto?

Com tantas opções de CMS’s disponíveis hoje em dia, com funcionalidades e finalidades diferentes, não faz muito sentido dizer qual deles é o melhor, mas sim qual deles atende melhor as suas necessidades. E, para chegarmos a essa resposta, nada melhor do que uma boa análise das opções que temos disponíveis.

Para começar a brincadeira, trago aqui um pequeno comparativo entre as principais opções livres em CMS’s, baseado em algumas informações do infográfico feito pela DeviousMedia, além de um bate-papo com três especialistas nessas soluções.

WordPress, joomla ou drupal?

Um breve histórico de WordPress, Drupal e Joomla

O mais velho entre os três sistemas é o Drupal, que foi criado pelo programador Dries Buytaert e lançado em 15 de janeiro de 2001. O nome Drupal vem da palavra holandesa “druppel”, que significa “gota”, e atualmente está na sua versão número 7, com uma frequência média de uma atualização a cada 36 dias, desde a sua versão 4.3, lançada em novembro de 2003, num total de 77 atualizações. Aproximadamente 1,6% dos sites da web usam o Drupal, entre eles o The Economist, The White House, MTV, London.gov.uk e The Onion.

Já o WordPress foi criado por Matt Mullenweg a partir do sistema B2/Cafelog, e teve seu lançamento em 27 de maio de 2003. O que começou como um simples sistema para blogs, hoje já na sua versão 3, está consolidado como um CMS bem completo, com uma frequência média de uma atualização a cada 17,8 dias, num total de 164 atualizações. Hoje ele é usado por aproximadamente 14,3% dos sites da web, entre eles o MTV Newsroom, The Ford Story, entre outros. Uma curiosidade é que, desde a sua versão 1.0, a maioria das versões do WordPress leva o nome de um cantor de jazz, como Coltrane ou Gershwin.

Por fim, temos o Joomla, criado a partir do CMS Mambo e lançado em 16 de setembro de 2005. Mantendo uma grande comunidade em vários países e línguas, o Joomla possui 6 versões lançadas, com uma frequência média de uma atualização a cada 49 dias na sua versão 1.5, e uma atualização a cada 25 dias na sua versão 1.6. São 27 atualizações (incluindo versões Beta) entre essas duas versões. Aproximadamente 2,7% dos sites da web usam o Joomla, entre eles estão sites como o Linux.com e o IHOP.

Ambos os sistemas são escritos em PHP, além de serem projetos de código aberto, distribuídos sob a GNU General Public License.

Plugins e Templates

Em praticamente todos os CMS’s, podemos acrescentar novas funcionalidades através de plugins ou módulos, que podem estender o uso do sistema para diversas finalidades. Nesse sentido, o WordPress leva vantagem, tendo os desenvolvedores um número de aproximadamente 14.629 opções disponíveis. No Drupal, esse número é de aproximadamente 8.039, enquanto o Joomla possui uma média de 8.000.

Para quem possui um projeto mais modesto, e pretende abrir mão de uma identidade visual personalizada, usando um modelo de site com funcionalidades definidas e layout pronto, são muitas as opções de templates disponíveis para os diferentes CMS’s. Considerando apenas os templates gratuitos disponíveis nos sites oficiais, temos uma marca de 1415 templates para WordPress e 878 templates para Drupal. No site oficial do Joomla, não constam informações referentes a templates.

Otimização para os mecanismos de busca

Elemento obrigatório na concepção de qualquer projeto web, as técnicas de SEO são hoje uma exigência de praticamente todos os clientes, até daqueles que não têm nem ideia do que isso venha a ser. Mesmo que hoje os principais influenciadores para a definição do posicionamento das páginas nos resultados de busca estejam relacionados à qualidade do conteúdo e à popularidade dos sites, podemos dizer que os primeiros passos para um bom SEO começam na estrutura do código HTML.

Por seguirem bem as práticas recomendadas pela W3C para o desenvolvimento web, ambos os sistemas possuem uma estrutura de código apropriada para o SEO. Contudo, o WordPress ainda leva uma pequena vantagem, por possuir uma estrutura um pouco mais semântica.

Ambos os sistemas possuem boas extensões para SEO, que buscam aprimorar a qualidade de elementos como títulos, sitemaps e URLs. Entre as extensões disponíveis, podemos destacar o WordPress SEO para WordPress, o Pathauto para Drupal, e as extensões AceSEF e sh404SEF para Joomla.

Tecnicamente falando

O WordPress, que ganhou popularidade como uma plataforma para blogs, vem se mostrando a cada dia como um dos CMS’s mais completos que existem. Para Leo Germani do Hacklab, o WordPress foi a ferramenta com a qual ele conseguiu obter os melhores resultados com maior eficiência. “No final de 2006 resolvi adotar um CMS para trabalhar, e experimentei as principais opções. O que me atraiu no WordPress desde o início foi sua simplicidade. Enquanto outros CMS’s demandavam uma curva aprendizado maior, o WordPress se mostrava direto e fácil, tanto do ponto de vista do usuário quanto do ponto de vista do desenvolvedor”, afirma Leo.

Nadir Alves da Bule Comunicação, que já trabalhou com CMS’s como o Plone e o WordPress, afirma que o Joomla possui um grande poder de customização de templates e uma curva de aprendizado muito leve. “As opções de expansão do Joomla sempre foram muito grandes, atualmente existem mais de 8.000 extensões no diretório oficial. Somando isso ao sistema de permissões de usuários e à facilidade de criar websites rápidos e completamente diferentes um do outro, o Joomla tornou-se uma escolha excelente e recomendada aos nossos clientes”.

Já o Drupal é considerando o mais complexo entre as três opções. Mas para Alex Piaz, que trabalha no Instituto Socioambiental (ISA), apesar de a curva de aprendizado do Drupal ser maior em relação aos seus similares, uma vez que você “pega o jeito” tudo fica muito claro, e o desenvolvimento passa a fluir sem maiores dificuldades. “Trabalho com o Drupal desde meados de 2006, pela facilidade de customização e construção de módulos, instalação multisite out of the box, localização e tradução com gettext totalmente desacoplados do core, comunidade atuante e extensa documentação. Tudo isso permite criar websites complexos com muito menos esforço de programação”, conclui Piaz.

As vantagens de cada CMS

Uma das maiores vantagens do WordPress é, sem dúvida, a sua facilidade. Leo Germani considera que esse CMS possui simplicidade e eficiência em todos os sentidos. “Do ponto de vista do usuário, temos um painel administrativo simples, bonito e fácil de usar. Do ponto de vista do desenvolvedor, temos uma arquitetura de templates muito fácil de entender e explorar, uma arquitetura de plugins muito eficiente, e uma estrutura de banco de dados muito simples e poderosa. Além disso, possui uma comunidade imensa e um desenvolvimento consistente, que se mantém firme aos seus princípios: manter o core simples e enxuto, deixando qualquer coisa mais específica para plugins e templates“.

Nadir acredita que a atual expansão e acesso ao Joomla para os novos desenvolvedores pode ser uma grande vantagem sobre os outros CMS’s. “Outra vantagem está no novo gerenciamento de usuários e permissões, que foi a funcionalidade mais esperada para a nova versão, e que agora (versão 1.7) está bem madura e extensível. Nesta nova versão, o sistema multilíngue nativo permite criação e administração de conteúdo para diversos idiomas de forma muito fácil para o cliente”.

Outras vantagens do Joomla levantadas são relativas aos templates e extensões. “A facilidade na criação de templates possibilita que, através de poucas linhas de HTML, seja criado praticamente qualquer tipo de layout em pouco tempo. Outro ponto muito importante são as extensões, que melhoraram muito desde a nova versão, integrando-se bem às novas funcionalidades do core do Joomla, e que possuem uma variedade de funções dificilmente alcançada por outros CMS’s”, conclui Nadir.

Para Piaz, estão nos módulos as maiores vantagens do Drupal. “A quantidade de módulos disponíveis é absurdamente grande, além de o roadmap ser muito claro quanto aos releases. Isso nos dá uma visão de longo prazo (cerca de 3 anos) sobre o caminho a seguir”.

Ainda sobre os módulos, o quesito “compatibilidade” é um dos pontos fortes do Drupal. “Temos praticamente 100% de garantia de que todos os módulos são compatíveis com a versão instalada, ou seja, um módulo feito para a série 6.x irá rodar sem problemas no Drupal 6.1, 6.2 e assim por diante. Um outro ponto importante é que o Drupal sempre oferece um upgrade path a cada nova versão lançada (6.x para 7.x, por exemplo). Assim, a nova versão só é declarada stable quando o upgrade path é disponibilizado”, afirma Piaz.

Para quais projetos cada CMS é indicado?

Muita gente considera que o WordPress é um sistema indicado apenas para a produção de blogs. Leo Germani considera que não há dúvidas de que o WordPress seja realmente a melhor plataforma para essa finalidade, mas que além disso ele é uma ótima solução para sites institucionais ou portais de notícias. “Se você tem um site que é 90% editorial, mas que necessita de funcionalidades como área restrita ou importação de conteúdos externos, o WordPress também é ideal, pois a sua arquitetura de temas e plugin facilita muito para que possamos usá-lo como uma espécie de framework, podendo desenvolver muita coisa sobre ele”.

Quanto ao Joomla, Nadir acredita que ele seja ideal para projetos que vão desde sites de pequeno porte até grandes portais. “Existem projetos específicos para Intranet muito facilitados pelo novo ACL nesta nova versão, e já vimos também uma excelente integração do CMS com o Magento. A gama de possibilidades é muito grande, inclusive diversos sites do governo que requerem muita segurança e estabilidade, hoje utilizam o Joomla“.

Piaz também considera que o Drupal é uma ferramenta ideal para sites e aplicativos web de todos os tipos e tamanhos. “O código do Drupal é bem estruturado, e permite um alto grau de customização sem que seja preciso alterar seu núcleo. Sua robustez pode ser atestada pela quantidade de websites de alto tráfego rodando Drupal“.

Conclusão

Ambos os CMS’s possuem pontos fracos e fortes. Muitos profissionais procuram optar pela ferramenta mais fácil, como é o caso do WordPress, o que pode ser bom em determinado projetos, mas deixar a desejar em outros. Considerando também a questão financeira, profissionais que trabalham com ferramentas mais complexas como o Drupal acabam por ser mais raros, e por isso mais caros.

A verdade é que muitas vezes o uso de um CMS acaba sendo condicionado pela identificação e pelo conhecimento prévio que os desenvolvedores têm na ferramenta. Mas o ideal é que, mesmo que você tenha preferência por um determinado CMS, ainda assim procure conhecer as possibilidades de outros sistemas.

Acredite, saber escolher a ferramenta ideal para cada tipo de projeto pode fazer a diferença.

Fonte: Edu Agni/IMaster

Silverlight 5: o que está por vir na plataforma RIA da Microsoft

A plataforma para criação de aplicações RIA (Rich Internet Applications) da Microsoft está próxima a ter nova grande versão lançada. A empresa liberou um RC para o Silverlight 5 no início do mês e já se pode testar a maioria da funcionalidades planejadas. O release definitivo está planejado para o final do ano.

Em dezembro de 2010, foram anunciadas as novidades da futura versão, e a primeira versão beta foi disponibilizada em abril de 2011 durante o MIX11. Entre as principais mudanças destacam-se o suporte para P/Invoke para 64 bits, impressão vetorial (usando PostScript), e a possibilidade de aplicações rodarem em modo “Trusted” no browser (antes só disponível fora do browser). Aplicações baseadas no Silverlight 5 também passam a poder utilizar o controle PivotViewer.

O Silverlight nasceu com o codinome WPF/E (Windows Presentation Foundation/Everywhere), como versão reduzida do framework .NET combinada com o WPF. A plataforma vem tendo sucesso como tecnologia para desenvolvimento de aplicações web com forte apelo gráfico, ou que demandem acesso a recursos privilegiados dos computadores em que são executadas.

Mesmo depois de um começo incerto, chegando a ter sua utilidade questionada devido à possibilidade de substituição pelo HTML5, o Silverlight conseguiu se firmar como alternativa séria para desenvolvimento RIA em diversas plataformas. Há plugins da própria Microsoft para ambientes Windows e Mac OS, e o plugin Moonlight, desenvolvido pelo time do Mono, permite o desenvolvimento para Linux. Além disso, o Silverlight é a plataforma oficial de desenvolvimento para o Windows Phone 7.

Outra novidade é a API 3D do Silverlight 5, muito semelhante ao XNA, que traz avanços para o desenvolvimento de aplicações 3D distribuídas pela web. (Essa funcionalidade gerou alguma controvérsia em função de uma possível vulnerabilidade DoS.)

Atualmente, a Microsoft vem utilizando Silverlight na entrega dos vídeos desenvolvidos em todos os portais da empresa. A plataforma também foi utilizada com sucesso na transmissão online das últimas olimpíadas de inverno.

Por permitir o desenvolvimento de código com linguagens como C#, Visual Basic, IronPython, IronRuby e F#, e contar com recursos semelhantes ao .NET framework, a plataforma é considerada simples de aprender e utilizar. Além das extensões necessárias para desenvolvimento com o Silverlight 5 RC no Visual Studio 2010, estão disponíveis para download as versões aprimoradas da suite Expression.

Espera-se que a Microsoft faça mais anúncios sobre novas funcionalidades para o Silverlight 5 durante o Build conference, nas próximas semanas.

Fonte: Elemar Jr./InfoQ

Bazaar 2.4 Apresenta Suporte à Longo Prazo

Desenvolvedores que trabalham com o sistema distribuído de controle de versão Bazaar, lançaram uma nova edição, que inclui suporte à longo prazo. As atualizações para o ramo de desenvolvimento 2.4.x irão, a partir de agora, ser limitadas a correções de bugs, com novos recursos para a versão 2.5. Esse suporte à longo prazo implementado, será executado até fevereiro de 2013.

Bazaar 2.4 é compatível com versões anteriores; dessa forma, a equipe de desenvolvimento aconselha os usuários a atualizar para a nova versão. Lembrando que o o sistema de controle de versão distribuído não é limitado para o Linux, pois a instalação dos pacotes está disponível para outros sistemas operacionais, incluindo Windows, Mac OS X, Solaris e BSD.

Fonte: Under-Linux

TrueCrypt 7.1 com Suporte Completo à Mac OS X Lion

O projeto TrueCrypt anunciou a chegada da versão 7.1 da sua ferramenta de código aberto, multi-plataforma e destinada à criptografia de disco. TrueCrypt 7.1, a nova versão estável do projeto, dentro de um período de quase um ano, é uma atualização de manutenção que acrescenta compatibilidade total com sistemas de 32 e 64-bit (versões do Mac OS X 10.7 Lion).

Os desenvolvedores ressaltam que várias melhorias realizadas e algumas correções de falhas, (que afetam todas as plataformas suportadas) também estão incluídas neste release. Todos os detalhes sobre o TrueCrypt 7.1, podem ser encontraoas no seu histórico de versões. Além disso, ele está disponível para download para sistemas Windows, Mac OS X e Linux, e um tutorial para iniciantes também está sendo disponibilizado.

Fonte: Under-Linux

Plataforma ezNcrypt 2.0: Criptografia de Dados Transparente

A ezNcrypt 2.0, plataforma de segurança de dados agora expandida para fornecer criptografia transparente de dados (TDE) para a LAMP stack, incluindo quaisquer dados, logs ou arquivos criados/geridos por qualquer aplicação Linux ou serviço, tais como sistemas Apache, Alfresco, Drupal, Joomla e WordPress.

Esta versão mais recente inclui também suporte para bancos de dados PostgreSQL, MongoDB, Cassandra e bancos de dados Drizzle, além do tradicional MySQL, e está disponível em duas versões: EzNcrypt para bancos de dados e Flex ezNcrypt.

O ezNcrypt 2.0 aproveita um estado de armazenamento de chaves no art system (KSS), que fornece autenticação dupla e alta disponibilidade, além de assegurar que as chaves de criptografia nunca sejam armazenadas no servidor,mesmo que os dados sejam criptografados.

Fonte: Under-Linux