JPz’log

Mon manuscrit de thèse sera rédigé en LaTeX (le premier qui me parle de Word se fera frapper avec violence ) et histoire d’automatiser les choses, j’ai écrit un script de compilation en Ruby.

J’aurai pu utiliser un Makefile, un des scripts existants (il y en a un très bien en Perl dont j’ai oublié le nom), du Python, du Groovy… mais ce script là me va très bien !

#!/usr/bin/env ruby
 
require 'optparse'
require 'fileutils'
 
MAIN_FILE = "phd-thesis"
PDFLATEX  = "pdflatex #{MAIN_FILE}.tex"
BIBTEX    = "bibtex #{MAIN_FILE}.aux"
 
def build_pdf
  return unless system PDFLATEX
  return unless system BIBTEX
  callcc do |stop_build|
    3.times do
      status = system PDFLATEX
      stop_build.call unless status
    end
  end
end
 
def single_compilation
  system PDFLATEX
end
 
def clean_artifacts
  extensions = %w[blg log pdf aux bbl lof lot out toc tps]
  files = extensions.map { |ext| "#{MAIN_FILE}.#{ext}" }
  FileUtils::Verbose::rm files, { :force => true }
end
 
def open_pdf(how)
  system "#{how} #{MAIN_FILE}.pdf"
end
 
def run
  options = {
    :command => :pdf
  }
  OptionParser.new do |opts|
    opts.banner = "Usage: build.rb [options]"
 
    opts.on("--pdf", "Build the PDF output (default)") do |pdf|
      options[:command] = :pdf
    end
 
    opts.on("--oneshot", "Single LaTeX compilation") do |oneshot|
      options[:command] = :oneshot
    end
 
    opts.on("--clean", "Clean the build artifacts") do |clean|
      options[:command] = :clean
    end
 
    opts.on("--open-pdf [HOW]", "Open the generated PDF with HOW)") do |how|
      options[:openpdf] = how
    end
 
    opts.on_tail("-h", "--help", "Show this message") do
      puts opts
      exit
    end
  end.parse!
 
  case options[:command]
 
  when :pdf
    build_pdf
    open_pdf(options[:openpdf]) if options[:openpdf]
 
  when :oneshot
    single_compilation
    open_pdf(options[:openpdf]) if options[:openpdf]
 
  when :clean
    clean_artifacts
 
  end  
 
end
 
run

Je ne garanti pas que le code soit parfait, alors n’hésitez pas à émettre des critiques constructives !

I just wanted to let the world know that I have just revoked my last 2 active GnuPG keys (see on the MIT GnuPG servers) as I haven’t used them for a while, so it was about time to revoke them.

In my very own case, I have rarely found a valuable usage of email signing and I don’t sign IzPack releases anymore. The terrible truth is that outside some sensible enterprise contexts nobody uses such techniques… except geeks. Maybe one day I’ll get another key if need be.

During the christmas break, I took an hour or so to play with Groovy and EJBs. EJB 3 are very easy to use (especially compared to what they used to be before that) so I decided to investigate how I could make them even simpler to use with Groovy.

Indeed, Groovy shares mostly the same meta-model as Java and you can easily mix Java and Groovy code in the same project (actually you can put .java and .groovy files side-by-side in your packages).

I opted for a simple hello-word style of project using Groovy 1.5 and GlassFish v2 ur1.

I started with a single HelloEJB.groovy file to host both the EJB remote interface and implementation as a stateless session bean:

package ejb
 
import javax.ejb.Remote
import javax.ejb.Stateless
 
@Remote
interface HelloRemote
{
    String hello()
}
 
@Stateless
class HelloEJB implements HelloRemote
{
    String hello()
    {
        return "Hello world!"
    }
}

The Groovy compiler takes care of generating 2 .class files (one for the interface and one for the class). Nice

Then I packaged this inside an EAR having groovy-all-1.5.jar so that GlassFish could make the Groovy runtime available to the EJB. Then I wrote this simple remote client to test it:

import javax.naming.InitialContext
 
def ctx = new InitialContext()
def ejb = ctx.lookup("ejb.HelloRemote")
 
println ejb.hello()

For this client to work, you need to put appserv-rt.jar from GlassFish in your classpath. Also, you will need to tweak a jndi.properties file at the root of your client classpath if you are not using the default GlassFish ports for your target domain.

I guess I can now save quite a lot of time using Groovy to implement EJBs

Disclaimer: I am dynamic-languages agnostic as I use Python, Ruby and Groovy for various things and I like them all. Really!

In a typical opensource fashion, I receive patches for IzPack.

I always review them carefuly, then I try to apply them on the latest source code tree. I am using either the BSD or the GNU implementation of patch.

For whatever reason, I can never apply the patches using these tools if they have been generated by Eclipse… The only way to merge is to launch Eclipse and apply the patch from there.

I haven’t yet managed to figure out why these patches cannot be applied using BSD or GNU patch. They really look like normal unified-style diff output…

Any idea?

MySQL is going to integrate some code from Google customizations. That is extremely good and healthy, however I came across a paragraph that made me wonder if MySQL will ever stop being insane at times…

Oracle having acquired the vendor of MySQL main data storage subsystem (InnoDB), the company decided to write a new one called Falcon. This is a safe move as it could potentially threaten MySQL if Oracle decided not to play nice anymore regarding InnoDB.

However… read this:

Falcon will do crash recovery and roll-back operations faster than InnoDB because they are done from main memory, Schumacher said, but some InnoDB features, like foreign key support and full-text indexing, won’t be supported until MySQL 6.1.

Come on! How can you pretend making an enterprise-grade RDBMS and not support foreign keys? Just remember that MySQL only started to support them in version 5… I think I’ll never understand why MySQL is so bitchy about foreign keys while any other RDBMS just provides it (PostgreSQL, Firebird or Derby just do it right).

If you don’t have basic referential integrity, then please don’t call it a RDBMS: just call it a “table-based database” with SQL support.