..but do I need it?

Well that depends:

• do you have any objects in whose alteration history you’re interested in? Think about any financial or business object.
• social network app? think automatic activity feeds..
• do you have any analysis workflow that produces a single output from multiple input data points? Provenance can retroactively create the relationships between the input and output datums.
• do you want to monitor a given object’s access patterns temporary? Think debugging.

Actually, the longer you think the more use cases appear.

After the break I’ll talk about my master thesis (that dealt with provenance), the corresponding RoR prototype and future plans w.r.t. provenance within Ruby on Rails.

Background Information

I’ve spend some time with my master thesis focusing on provenance. It’s academic so do not expect readability or real-world usability. For that there’s a short paper detailing the rails prototype, an additional use case was detailed in another paper. All source code can be found on github, it might take some days to get the newest versions into the repositories.

My basic idea was that developers do not want to deal with the details of provenance gathering or storage. They should focus upon their domain application. I developed a system that allowed automatic provenance capturing (through a rails plugin), networked storage and dedicated network query facilities.

The prototype did work, unobtrusive provenance capturing is perfectly possible in Ruby on Rails. Why do I believe that the master thesis prototype is not perfectly suited for real-world applications? Well,

• storage was done through a separated RDF graph engine, encapsulated within an own RoR application. This is well suited for large academic test applications but I believe that something using an embedded storage solution (thus easier to integrate within existing systems) might be better suited for Rails.
• provenance queries had to be done through SPARQL or a special (easy) REST-based interface. An interface directly integrated within Ruby would be preferable.
• It’s all still Rails 2.3 based. I’ve finished the prototype some time ago and did work the last months mostly on the documentation. So the prototype should be forward-ported to Rails 3.0.0beta3.

Towards a bright new future!

So I have finally finished my master thesis and would need a embeddable provenance solution for one of my side-projects. I will base it upon the work done during my master thesis but it will differentiate in various points:

• use embedded storage. Application developers should be able to install the plugin, call a rake task and enjoy the benefits of automatic provenance gathering. Does anyone know a good ruby only RDF/graph engine?
• no more special query language.. users should not have to learn a new query language nor interfaces. Provenance should be be provided through virtual ActionModel methods and act as ‘normal’ object methods.
• update the plugin to work with Rails 3.0, investigate Rack and ActionModel
• keep the plugin as simple as possible.. so other people can play with it too.

I’m not perfectly sure when my side-project will need need that functionality (or if it even gets towards that point), but if you’re interested in provenance on rails just watch the repository or, even better, branch it and get involved..

Alas I did not find too many introductions so I thought that I’ll write a bit about my experience with cmake. As I continue to find out more stuff about cmake the post will be updated with new findings.

Read after the fold for an introduction into cmake. We’ll create a build system capable of creating debian or redhat (RPM) packages. It will include advanced stuff as automatically creating and installing documentation, subversion-derived version numbers and creating optional features.

Basic Project Layout

We have a fairly standard project layout (currently using autotools):

All files are stored within a subversion software repository. The final package should include the current subversion revision number in their package description (as well as output it from within the executable) to improve bug report’s quality.

The build system should generate the support library, the binary and utilize Doxygen to generate documentation. All those files need to find their way into automatically build distribution packages (Debian and Redhat packages in our case).

Basic cmake setup

We start with a skeleton cmake file that only tests various standard compile flags. We name our project, search for various default libraries (through find_package) and set various compile flags.

The simple boilderplate text files are also installed. At this time the destination directory is hard-coded, this will change in the future.

project(test-program)
cmake_minimum_required(VERSION 2.6)

# check libs and packages (headers + lib)

# std C libraries
find_package(stdlibs REQUIRED)

# libpthread with pthread.h
find_package(pthread REQUIRED)

check_include_file(argp.h HAVE_ARGP_H)

# additional compiler flags
add_definitions(-Wall -Wextra -pedantic -Werror -std=c99 -D_BSD_SOURCE)

# 'other' documentation files
set(DOC_FILES AUTHORS NEWS README)
set(DOC_PATH "share/doc/testprogram-0.1")
install(FILES ${DOC_FILES}
        DESTINATION ${DOC_PATH})

So far we have the skeleton outline of a cmake project that just sets some compile information about our project and finally installs some documentation. Let’s add some “real” stuff.

Adding support libaries

Our project contains one library that is needed for compilation of the executable file. To build the lib a new CMakeLists.txt was added to /lib and the /lib directory was added to the main CMakeLists.txt by:

add_subdirectory(lib)

The cmake library definition is pretty straightforward: we define the needed source files (through the EXAMPLE_LIB_SRC variable) and add a new shared library named ‘example-lib’ to the build targets. The only “weird” thing is that we have to add the library to the linker flags manually (by setting CMAKE_REQUIRED_LIBRARIES): it would be nice if this could happen automatically.

# sources and linkage

# define the sources
set(EXAMPLE_LIB_SRC  lib_a.c lib_b.c)
add_library(example-lib SHARED ${QKD_APP_SRC})
target_link_libraries(example-lib ${CMAKE_REQUIRED_LIBRARIES})

# additional includes
include_directories(. ..)

# enable gcc specific stuff
if (CMAKE_COMPILER_IS_GNUCC)
    set_source_files_properties(${EXAMPLE_LIB_SRC} PROPERTIES COMPILE_FLAGS "-std=c99 -Werror -Wall -pedantic")
endif ()

set(CMAKE_REQUIRED_LIBRARIES "example-lib;${CMAKE_REQUIRED_LIBRARIES}")

# install
install(TARGETS example-lib LIBRARY DESTINATION lib)

Adding executables

Now we add the executable file to the build. To achieve this we add a CMakeLists.txt to the /bin directory. Within it we define our executeable (consisting of part_a.c and part_b.c) and its compile flags. The include directive states where the compiler should search for header files. With the install command we define it’s final position when being installed as part of a package.

We also add a manual dependency of example-prog upon example-lib. Cmake now always builds example-lib before it attempts to build example-lib. Alas we still had to manually add the example-lib linker flags to CMAKE_REQUIRED_LIBRARIES at the /lib section

include_directories(
    .
    ..
    ${CMAKE_CURRENT_BINARY_DIR}
    ${CMAKE_CURRENT_SOURCE_DIR}
    ${CMAKE_SOURCE_DIR}
    ${CMAKE_BINARY_DIR}
    ${CMAKE_SOURCE_DIR}/bin/
   )

# define the sources
set(EXAMPLE_SRC part_a.c part_b.c)

# define executable
add_executable(example-prog ${EXAMPLE_SRC})
target_link_libraries(example-prog ${CMAKE_REQUIRED_LIBRARIES})
add_dependencies(example-prog example-lib)

# compiler switches

# enable gcc specific stuff
if (CMAKE_COMPILER_IS_GNUCC)
    set_source_files_properties(${EXAMPLE_SRC} PROPERTIES COMPILE_FLAGS "-std=c99 -Werror -Wall -pedantic")
endif ()

# install binaries
install(TARGETS example-program RUNTIME DESTINATION bin)

Test it

This would actually be a good time to test our build system. cmake supports two different ways of separating source code from build programs: out-of-tree builds and in-tree builds. With in-tree builds source code and generated files are always stored within the same project directories. This is the way of building that you might know from autotools. With out-of-tree builds all generated files are placed into a separated directory: this keeps your project directory clean (and you can do interesting stuff as speeding up build time by placing the out-of-tree build directory on a ramdrive/tmpfs). So we will try to do an out-of-tree build:

$ cd $PROJECT_DIRECTORY
$ mkdir build
$ cd build
$ cmake ./..
$ make

This will build all binaries within the build directory. Partey!

Create debian and redhat packages

We won’t distribute a tar-ball or plain pre-compiled binaries to our users but want distribution-specific packages. They provide a better user experience through features as dependency tracking (which other packages must be installed to run this program) or easy package management (install, reinstall, uninstall packages).

cmake provides CPack for package creation. To enable it our main CMakeLists.txt was adapted in the following way:

set(CPACK_PACKAGE_DESCRIPTION "Do the example thingie")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "A longer description about our example app.")
set(CPACK_PACKAGE_NAME "example-app")
set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.6), libgcc1 (>= 1:4.1)")

set(CPACK_PACKAGE_CONTACT "Andreas Happe ")
set(CPACK_PACKAGE_VENDOR "Andreas Happe Inc.")
set(CPACK_PACKAGE_VERSION_MAJOR "0")
set(CPACK_PACKAGE_VERSION_MINOR "0")
set(CPACK_PACKAGE_VERSION_PATCH "1")
set(VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")

set(CPACK_GENERATOR "DEB;RPM;")
set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}-${CMAKE_SYSTEM_PROCESSOR}")

include(CPack)

The variables contain package descriptions and version information that will be converted into the new packages meta-information. CPACK_GENERATOR specifies for which output types the generated packages should have. We have chosen DEB (Debian, Ubuntu) and RPM (Redhat, Suse, Fedora) packages to be generated. They should suffice for the vast majority of installed Linux distributions. We also added some package dependencies for debian distributions: this ensures that libc and libgcc1 will be installed with their correct versions before our package is installed.

To finally build our distribution packages just change into the build directory and enter cpack:

$ cd build
$ cpack

The resulting distribution packages will lie within the build directory.

Another advantage is that we can use those cpack variables throughout the whole CMakeLists.txt file. For example: instead of installing documentation files into a fixed directory through:

set(DOC_PATH "share/doc/testprogram-0.1")

we can install them into a properly versioned directory:

set(DOC_PATH "share/doc/${CPACK_PACKAGE_NAME}-${VERSION}")

Add include files to distribution package

Other programs might link against our example-lib but they will need some header files to learn about the lib’s available (exported) function signatures. To install them we add the “include” subdirectory to our build by adding the following to the main CMakeLists.txt:

add_subdirectory(include)

Now we need a “/include/CMakeLists.txt” that specifies which header files need to be installed into our distribution package. As we want this to happen for all existing header files we just add a catchall install statement:

install(DIRECTORY example-lib-headers
        DESTINATION include
        FILES_MATCHING PATTERN "*.h"
                       PATTERN ".svn" EXCLUDE
       )

This installs all “*.h” files (ie. header files) from the directory “/include/example-lib-headers” into the package’s include directory (which will later be installed into the system’s include files directories). Notice the EXCLUDE-pattern: as we are using Subversion as a SCM we do have various internal subversion files lying around in our source code tree. Those include copies of header files. Without this EXCLUDE those copies would also be installed into our distribution package what we do certainly not want.

Add current subversion revision

As all programs our example program contains bugs. To improve bug reports we want to include a reference to the exact subversion release this package was build from. This information should be included within the package meta-information as well as within the compiled program itself

First of all we need to gather the subversion revision information. To achieve this we utilize the Subversion module that is installed with cmake (you can find those modules under /usr/share/cmake/modules*, there are lots of useful tools within that directory). It’s configuration and usage within the main CMakeLists.txt can be seen in the following code snipplet:

find_package(Subversion)
if(Subversion_FOUND)
  Subversion_WC_INFO(${CMAKE_CURRENT_SOURCE_DIR} ER)
  set(SUBVERSION_REVISION ${ER_WC_REVISION})
endif(Subversion_FOUND)

Now we have the current subversion revision stored within the SUBVERSION_REVISION variable and can easily use it to set our packages patch level (the patch level is the most insignificant part of the whole package version):

set(CPACK_PACKAGE_VERSION_PATCH "${SUBVERSION_REVISION}")

To reference this information from within a compiled program we want a header file that contains a #define that acts as a placeholder for the current subversion revision string. To achieve this we utilize the cmake configure_file directive. The directive states a source and a destination file: the source file is read, processed and stored as the stated destination file. During processing all cmake variables can be accessed and output into the destination file, ie.:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cmake/revision.h.in ${CMAKE_CURRENT_BINARY_DIR}/revision.h)

With an config.h.in file of:

#ifndef __REVISION_H
#define __REVISION_H
#define SVN_REVISION "${SUBVERSION_REVISION}"
#endif

The cmake variable SUBVERSION_REVISION is used as value for the SVN_REVISION #define. The #ifndef guards are just thrown in for good style and are not mandatory.

Automatically create man pages/documentation with Doxygen

We can utilize the same configure_file-mechanism to automatically generate documentation through Doxygen. We already have a doxygen file describing the documentation extraction but need to adapt it to the actual build directory, ie:

PROJECT_NAME           = ${CPACK_PACKAGE_NAME}
PROJECT_NUMBER         = ${VERSION}
OUTPUT_DIRECTORY       = api-doc
INPUT                  = ${CMAKE_CURRENT_SOURCE_DIR}

Now we need to include Doxygen within our build configuration. We achieve this through including the following into our main CMakeLists.txt:

# check if doxygen is even installed
find_package(Doxygen)
if (DOXYGEN_FOUND STREQUAL "NO")
    message(FATAL_ERROR "Doxygen not found. Please get a copy http://www.doxygen.org")
endif (DOXYGEN_FOUND STREQUAL "NO")

# prepare doxygen configuration file
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)

# add doxygen as target
add_custom_target(doxygen ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)

# cleanup $build/api-doc on "make clean"
set_property(DIRECTORY APPEND PROPERTY
	     ADDITIONAL_MAKE_CLEAN_FILES api-doc)

# add doxygen as dependency to doc-target
get_target_property(DOC_TARGET doc TYPE)
if(NOT DOC_TARGET)
	add_custom_target(doc)
endif()
add_dependencies(doc doxygen)

# install HTML API documentation and manual pages
set(DOC_PATH "share/doc/${CPACK_PACKAGE_NAME}-${VERSION}")

install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api-doc/html
         DESTINATION ${DOC_PATH}
       )

# install man pages into packages, scope is now project root..
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api-doc/man/man3
         DESTINATION share/man/man3/
       )

First of all we verify that Doxygen is even installed. Afterwards we automatically adopt the Doxygen.in configuration file to our needs (configure_file). This makes sure that generated documentation is always placed within the build directory. To make sure that current documentation is always available we add a custom target called “doxygen” and let the “doc” target depend upon it. The “doc” target will automatically be called after compiling and through the dependence doxygen will be called then too. In addition we add the “api-doc” directory (which will contain all generated files as specified within Doxygen.in) to the lsit of files that should be removed after a “make clean” run.

This is sufficient to create documentation but we also want it to appear within the generated distribution packages. The two install statements at the end achieve exactly that: they install HTML documentation into the official /usr/share/doc/ directory and generated man pages into their corresponding directories.

Add some optional parts

So far our build environment has been pretty monolithic: it always builds everything. Sometimes you do not want that as some features are only needed in special circumstances. As an example we do not want to add header files to the distribution package all the time.

Optional features are supported by cmake through the option statement. An option consists of a variable name and a short description. The user is displayed the option description and if he enables it the option variable is set. A short example illustrates this far better:

option(ADD_INCLUDE_FILES "Add include files to the generated distribution packages")
if (ADD_INCLUDE_FILES)
    add_subdirectory(include)
else(ADD_INCLUDE_FILES)
    message(WARNING "include files will not be included within the distribution packages")
endif(ADD_INCLUDE_FILES)

The include directory is only processed if the user selects the option. But how can an user actually enable an option? cmake provides various user interfaces, i prefer the ncurses-based ccmake:

$ cd build
$ ccmake ./..
# enable the wanted options and build it afterwards..
$ make

Ruby on Rails provides various helpers for generating dynamic web content but sometimes you need documents that users can easily store and share between them. The ubiquitous file format for this is Adobe PDF nowadays.

The common solution fro this problem is Prawn [github, introduction]. Alas it requires a custom DSL for document description, no existing Rails views or partials can be reused. An alternative is princeXML which transforms HTML/CSS into pdf through an external binary. This would allow reuse of existing templates and knowledge (think CSS designers) but has the downside of its price tag of $3800.

The solution

Enters wicked_pdf: it utilizes wkhtmltopdf to create a PDF document from a Rails HTML template. HTML rendering is done through the well-known webkit-engine. This allows developers to do PDFs in the right way™: define the document’s structure through a simple HTML document and theme them through CSS. You’ll get the automatic benefit of themability: exchange the CSS and you have another format. There are also lots of CSS artists out there that can supply you with different designs.

I’ve used this solution with a test Ruby on Rails 3.0-beta application, the steps involved were:

Install wkhtmltopdf:

This program will convert the HTML into the PDF format. To make it work you’ll need at least version 0.9 which isn’t installed in Ubuntu 9.10 by default. Just download the static compiled version from the wkhtmltopdf website and place it under /usr/local/bin.

Install the wicked_pdf plugin:

Just install it in the usual Rails way:

git submodule add git://github.com/mileszs/wicked_pdf.git vendor/plugins/wicked_pdf

Additionally a sample configuration file is needed. You could use the plugin’s generator script for it but alas this didn’t work for me with Rails 3.0. Let’s just copy it form the plugin’s directory into config/initializers.

$ cp vendor/plugins/wicked_pdf/generators/wicked_pdf/templates/wicked_pdf.rb config/initializers

and alter the wkhtmltopdf path within it:

  WICKED_PDF = {
       :exe_path => '/usr/local/bin/wkhtmltopdf-amd64'
  }

Add pdf instructions to your controller..

For example I’m using the invoice#index action to render a simple PDF document.

  format.pdf do
          @example_text = "some text"
          render :pdf => "file_name",
                 :template => 'offers/show.pdf.erb',
                 :layout => 'pdf',
                 :footer => {
                    :center => "Center",
                    :left => "Left",
                    :right => "Right"
                 }
  end

We are rendering the view with a predefined footer containing some sample “center”, “left” and “right” strings. The render :pdf call has various options which can be seen on the wicked_pdf homepage.

.. and create PDF templates

The other half of the PDF templates is the view code consisting of a special layout and template for pdf generation.

The layout (app/views/layouts/pdf.html.erb) resembles a normal Ruby on Rails layout file:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <%= wicked_pdf_stylesheet_link_tag "pdf" %>
  </head>
  <body>
    <div id="content">
      <%= yield %>
    </div>
  </body>
</html>

The view code should not be too surprising, just place it under app/views/offers/index.pdf.erb :

<div id="someid"><%= @example_text %></div>

Lets also create a simple CSS file (public/stylesheets/pdf.css):

#someid {
  margin-left: 430px;
  display: float;
  height: 150px;
  background-color: green;
  width: 250px;
}

This is the whole rendering code.

Reference the PDF view and download it

We still need a reference to the newly created rendernig link, we can easily create this through:

link_to 'Create PDF document', invoice_path(@invoice, :format => :pdf)

When the link is clicked a pdf document will be generated and downloaded.

Conclusion

wicked_pdf allows easy pdf generation in a very Ruby on Rails’ way. It’s free, it works and is easy to employ..

..but not everything is perfect within the wicked_pdf world, especially error handlnig is lacking sometimes. When you’ve debugging initial problems you can expect the only error feedback to be a HTTP return code of 406. Just start with limited controller (rendering) options and double check that you’ve referenced the right view and layout paths and you should be fine.

The final presentation of the prototype happened this Wednesday. The last days and nights before that were filled with applying the last fixed but finally it was worth the time. But let the newspapers do the talking: orf, heise, der standard, sueddeutsche, Austrian Telekom News. There was quite good news coverage in german-speaking Europe (and some eastern europe countries) but sadly the news didn’t seem to have jumped over the pond (at least some American physicists were at the presentation so it got noticed anyway).

Feels strange to know that something that big and cutting-edge is finally successfully finished.. and that I’m an unemployed student agai

Lines of Code comparison

Ruby beats Java if you want an easy and fast web development framework, but as soon as you exit the web user interface niche it looses many of its advantages, still the lines-of-code count in java is around 4 to 6 times as large as Rails’s. Good for you if you’re paid by the line of code that you write, bad for you if you want to get things done.

Both frameworks rely on convention over configuration. As I wrote the Java application after the Rail’s one I had to configure Java to fit Rail’s way which resulted in lots of configuration which would be unnecessary if I’d written the application in Java from day one. Much of the simpler code (setter/getter for entity classes) were also auto-generated, so the LOC count should be looked at with a grain of salt.

Readability

The Java code is better readable which surprised me. While the Ruby code is more verbose and beatifuller the Java code tends to be longer, but overall simpler structured. It is a lot easier to debug and as my application will be deployed as a war file in an Java Enterprise container there’s lot of functionality (e.g. logging) which can easily be tapped. I had some very ugly functions dealing with mime parts in Ruby, those are a lot easier to read because of the static typing. Once again: while duck-typing is perfect for writting an application quick, static typing might come in handy if you want your application to be robust and long-lived.

Different approach to business object authority

Another difference (and source of increased Java LOCs) is the different approach to business object responsibility. That term describes who is responsible for declaring objects, their content and constraints. Rail’s ActiveRecord maps the a database table into a business object data type, a row into an object and a attribute into a class member. Each change in the data backend automatically changes your business objects. You can write automatic tests to check if your object model is still sufficient, but those tests are not run automatically when the application starts. Some definitions (i.e. constraints and relationships) are defined on business object level, so you have split definitions between the database and your object model.

With hibernate you write your business objects and add annotations (as you do with Rails) to describe how they are mapped to the database. But the final  authority lies at the application and the business objects. If there’s a database change no attribute appears or disappears automatically, but an exception is raised on application startup. You have to write more code, but you have all your data definitions (incl. tables, attributes, relations and constraints) in one single conceptional place. You can even generate your database layout from your object model.

The later approach is clearer for me (and does less automagic than the Rails approach), but there’s also a payoff: you’ll need many more lines of code to define your business objects. Also if you want to add a change you’ll have to change your data definitions in the database as well as in your application. This will never happen in Rails with it’s D-R-Y way (Dont Repeat Yourself). Choose ease and speed of writing code vs. IMHO more safer code as your database format and input is double checked.

The next part will talk about the differences in Rails and Java/Springs exception handling.

• Compared to PHP, Python or Java there are just too few communication libraries. And even the libraries that exist are lacking fundamental features and almost all of them come without useable documentation. That there is no encryption (SSL or TLS) support in the whole Ruby 1.8 mail libraries is an outright shame. The IMAP library is so clumsy that a web company sells their own (still not perfect library) through their online store and they seem to make a good buck with it.

  On the Java side is just a completly different picture: Lots of libraries, even documented ones are available. After having to touch the TMail (rail’s MIME mail handler library) API using javax.mail is a heavenly gift. And it seems that the TMail generated MIME messages were invalid in a couple of cases. Not the best feature of a support library. Also the chance of finding unsolved known bugs and errors seems to be lot smaller in Java.

• This brings me to another point: I might change my opinion on Java’s constraints on its users. Java tries hard to prevent errors (i.e. the forced exception catching). I always thought that that took too many stylish possibilities away from the user, but by now I must confess that I think that this is exactly what I want from something that I’m using on the network side. I’m a lazy programmer, I want to be reminded and forced to write secure and stable code. This is the quite different to Ruby and Rails ‘make it easy for the programmer’ attitude.
• Background processing is hard. As Ruby on Rails is not multi-thread safe you can’t just spawn a thread if you need to perform some longer running task. Another disadvantage of using a single-process model is that the long running request will occupy one rails worker (i.e. rails cluster process) until it has finished – in our case that costs us around 60MB of memory per long running request, even if it is just waiting for some simple SMTP feedback. If you can find a situation where you can delay the execution of a network related task (and if you don’t you’re not thinking) for two seconds, 6 requests per seconds will DoS a standard rails cluster.

  The only solution that’s actually usable is BackgroundRb. But projects that just change their background communication system just don’t sound to production-grade ready for me. Also the admin start/stop scripts for their background server didn’t work too well for me.

• For a language that interferes it’s object’s attribute types directly from the database the ActiveRecord layer is weak. Don’t get me wrong, I understand that the Simplicity is needed to make it easily usable but I ran into various situations where I’d love to have a full blown ORM behind me. One feature that is needed quite often by our application is inheritance. ActiveRecord only offers single table inheritance, and even there you have to make sure that each row is valid (ActiveRecord should have all needed information to do that by itself BTW) or you will run into problems later on. One problem is, that it tries to abstract too much functionality away from the database while not provided as advanced interfaces by itself. Data integrity handling? Abstracted away by rails, so all databases can be used the same. The drawback is, that the data constraints and relations are fully handled by rails and not passed on to the database. Any process that might produce invalid data (e.g. a faulty rails component) might corrupt the data. Rails is able to handle that cases by itself (due to ducktyping and very few default checks), but access that data with any other framework and it blows up directly into your face.
• Transaction handling. Just try it. Then cry. Also I’m not sure if Transaction handling is even done on database level or in Rails (as done with constraints). If the later is true, it’s acutally not worth anything as soon as more processes try to access the database.

The library and documentation problems where the main reason for me to reimplement the mailing and campaigning backend in Java. The front end is still a Rails application — which is exactly what Rails is for. As I’m no friend of blown-up EJB based solutions I’ve choosen a simple Spring and JPA based solution for that problem.

I’m currently testing the last features and replacing the Ruby code part by part. As soon as I’ve done that another blog post will examine the two implementations, how much time was spent on coding them and how they perform when compared to each other.

What to do? It’s a shame that a web framework like Rails doesn’t support secure transmission of mails.

So I rolled my own Ruby on Rails plugin that extends the base Net::SMTP class with STARTTLS features. You can just call Net::SMTP.enable_tls (or do the same with an instance variable) to enable secure communications.

Honestly I didn’t write all the code on my own but searched the net and adapted some around-floating patches to this plugin as this is the easiest way of providing the needed TLS support to rails.

So if you need it, just grab it from here. More Information can be found in the plugin’s README file. Have fun and share your improvements to the plugin.

1. checkout a new copy of my project from the SCM
2. upgrade the used rails version to EdgeRails
   (through executing “rake rails:freeze:edge” twice)
3. adopted the RAILS_VERSION variable in config/environment.rb
4. Got a “500 Internal Error” without any usable logging information on starting the Rails server (“script/server“)

So what? I upgraded everything as planned and got an error without any real debugging help. What to do now?

After some googling around I found Mislav Marohnic’s excellent r2check.rb script. Just run it in your Rails directory and it will report a lot of errors and deprecated features that might hit you. One of those reported errors was the new notation for singular resources, after it converted my resources.rb the application finally started (albeit I had to fix some errors in the restful_authentication plugin, but nothing to heavy). So now I’m running Rails 2.0.1 and some pages really fell a lot faster.

Thank you very much for that script!

So I’m back to Rails. By now I feel more comfortable in the framework, but there are still some open issues but most things just work (TM).

You’re an atheist?

Only on Christmas or Easter,
the rest of the time it doesn’t really matter

House, M.D.

I spent most of today’s afternoon coding a quite simple web application using JavaServer Pages with a Spring2, Hibernate and Java Persistence Architecture back-end.  Security is handled through acegi, packaging through maven. Although this is more time-consuming compared to the last Ruby on Rails application I coded but there’s less Voodoo involved. Overall the resulting system feels more secure and stable.