Minificação de Javascript com Ant Task

{ December 16th, 2008 }

Autor: cmilfont

Em um post passado eu falei da importância de unir e minificar arquivos js em determinados casos e discuti “quando” fazer isso, vou mostrar “como” minificar usando o YUI Compressor com tasks do Apache Ant montados por Viktor Lieskovsky do Javaflight.

Esse pequeno tutorial-guia faz parte do material dos meus cursos de Javascript e Ajax e serve para deixar um histórico acessível aos alunos e fácil para leitores que por ventura precisem.

Preparei um ambiente de execução com todas as dependências no projeto Remendux onde vocês podem fazer checkout e rodar o build ant localmente como um projeto do eclipse – estou usando o plugin para o SVN Subclipse.

Montei um script ant padrão bem simples de ser entendido por iniciantes:

<?xml version="1.0" encoding="UTF-8"?>
<project name="jsmin" default="main" basedir=".">
	<!-- Propriedades para definir nomes de pastas que usaremos -->
	<property name="js" value="js"/>
	<property name="build" value="build"/>
	<property name="lib" value="lib"/>
	<property name="output" value="output"/>
	<!-- Propriedades para definir nomes os arquivos necessários -->
	<property name="yui-compressor.jar"
		location="${lib}/yuicompressor-2.4.2.jar" />
	<property name="yui-compressor-ant-task.jar" 
		location="${lib}/yui-compressor-ant-task-0.3.jar" />
	<!-- Incluir as libs necessárias no classpath -->
	<path id="task.classpath">
		<pathelement location="${yui-compressor.jar}" />
		<pathelement location="${yui-compressor-ant-task.jar}" />
	</path>
	<!-- Definição da task para o Ant reconhecer -->
	<taskdef name="yui-compressor" 
classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
	<classpath refid="task.classpath"/>
	</taskdef>
 
	<target name="clean">
		<delete dir="build"/>
		<delete dir="output"/>
		<mkdir dir="build"/>
		<mkdir dir="output"/>
	</target>
 
	<target name="main" depends="clean">
		<!-- Tag do Ant para concatenar arquivos 
		[ http://ant.apache.org/manual/CoreTasks/concat.html] 
		os arquivos são unidos na sequência de definição 
		no fileset
		-->
		<concat destfile="${output}/remendux.js" force="no">
			<fileset file="${js}/util.js" />
			<fileset file="${js}/remendux.js" />
		</concat>
		<!-- Task do yui-compressor -->
		 <yui-compressor warn="false"  munge="true"  
				preserveallsemicolons="false" 
				fromdir="${output}" todir="${build}">
		</yui-compressor>
	</target>
 
</project>

Após a importação, para executar o script – que chamei de build-yui.xml – basta apenas executar com o ant pelo eclipse – vide imagem abaixo – ou em linha de comando. Estou usando o Ant 7.1 com java 6u10 e Eclipse 3.4, portanto caso haja um erro atente para a versão das ferramentas usadas.

Após executar, observe a redução de tamanho na versão minificada [../build/remendux-min.js] para a versão concatenada [../output/remendux.js ]. A versão final ficou com 30% do tamanho com documentação e identação.

Buildfile: C:\workspace\remendux\build-yui.xml
     [echo] Building output
clean:
    [mkdir] Created dir: C:\workspace\remendux\build
    [mkdir] Created dir: C:\workspace\remendux\output
main:
[yui-compressor]
 [30%] remendux.js [5775] ---> remendux-min.js [1734]
[yui-compressor]
 [JavaScript] Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
[yui-compressor]
 [CSS] No files to compress, or all files already up to date
[yui-compressor]
 Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
BUILD SUCCESSFUL
Total time: 12 seconds

Posted in Ajax, Engenharia de Software, Frameworks, High Performance, JSON, JavaScript, Melhores práticas, Otimização, Scripting, Web Development, YUI ~ No Comments

Tomcat: Rest in Peace?

{ October 10th, 2008 }

Autor: cmilfont

Ultimamente tenho lido o depoimento de uma gama enorme de profissionais sobre os problemas de Memory Leak do Tomcat e alguns levantam a hipótese de uma possível descontinuação.

Fábio Kung publicou no blog da Caelum sobre os problemas enfrentados pelo GUJ (maior e melhor fórum sobre Java e arquitetura de software do Brasil) de quedas e lentidão. Há poucos dias o Diego Plentz também publicou sobre experiência recente, até citando o artigo do Kung e dando explicações sobre as mudanças necessárias que teve que realizar nas aplicações durante a mudança do Tomcat para o Jetty.

Na Java Magazine desse mês, edição 61, o autor OSVALDO PINALI DOEDERLEIN – no artigo denominado “WTP 3.0 – Novidades do Ganymede para desenvolvimento Java EE” – escreveu no quadro: “Glassfish? Por que não Tomcat ou JBoss?”, o seguinte sobre o Tomcat:

O projeto Apache Tomcat não me parece ir bem. O Tomcat 6 (versão atual) só teve dois builds estáveis: o release inicial de 2007 e um único update. Houve defecção de colaboradores importantes “como pessoal da Sun, realocado para o Glassfish quando este começou a levantar vôo, e para outros projetos como o LWUIT. Tecnologicamente o Tomcat parou no tempo há um par de anos. Fez a opção de reusar o APR (biblioteca de código nativo do Apache HTTPD), ao invés de investir forte no caminho “puro Java” de APIs como java.nio – opção que o Glassfish provou ser superior. Não tem havido atualizações de correção & segurança com a regularidade que considero necessária para software dessa natureza. Continuo considerando o Tomcat uma boa opção apenas para ambientes onde toda a comunicação HTTP tem que passar pelo Apache HTTPD.

….

É interessante observar que o Tomcat é o container web embutido no JBoss, e o JBoss é outro colaborador importante do projeto Tomcat. O que possivelmente indica que as dificuldades de ambos os projetos possam estar relacionadas.

Com a onda crescente do Jetty sobre a base instalada do Tomcat é possível que nos próximos meses os retardatários movam seus sistemas jogando a última pá de terra.

E vocês? Já estão usando o Jetty em alternativa ao Tomcat?

Posted in High Performance, JEE, Jetty, Melhores práticas, Tomcat ~ 3 Comments

Compare a velocidade dos seus sites

{ July 19th, 2008 }

Autor: cmilfont

O Webslug é um serviço onde você pode comparar a velocidade de carregamento do seu site com outro qualquer, interessante para verificar dois sites hospedados no mesmo servidor e observar o carregamento afim de descobrir problemas se um sempre carregar mais rápido do que outro.

Posted in High Performance, Melhores práticas, Otimização, web2.0 ~ 1 Comment