Capistrano wouldn’t do much, I kept getting errors about “bundle” not being found. Seems the newer versions of Rails and Capistrano prefix everything with “bundle” so the right Gems etc. are used.

Turns out there’s a problem with the path that my Capistrano scripts get when they ssh into the Linux machine. Seems there’s a different environment for interactive SSH sessions, and the non-interactive SSH sessions that Capistrano uses.

To diagnose this, I added this to my deploy.rb:


desc "Echo environment vars"
namespace :env do
task :echo do
run "echo printing out cap info on remote server"
run "echo $PATH"
run "printenv"
end
end


Which when I do cap env:echo tells me the path that my Capistrano scripts see – which crucially doesn’t include /var/lib/gems/1.8/bin.

Turns out you set the environment in ~/.ssh/environment, adding a PATH line in the normal way.

But then you need to edit /etc/ssh/sshd_config and add a line

PermitUserEnvironment yes

And restart SSH.

After that your Cap deployments will be smooth…

Have you ever had a really fun day? A day that starts like this:

Feb 24, 2011 10:50:42 PM org.apache.catalina.core.ApplicationContext log
SEVERE: unable to create shared application instance
org.jruby.rack.RackInitializationException: stack level too deep
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:348:in `catch'
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:348:in `resolve_requirement'
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:299:in `resolve'
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:298:in `reverse_each'
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:298:in `resolve'
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:349:in `resolve_requirement'
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:348:in `catch'
from c:/console/ROOT/WEB-INF/gems/gems/bundler-1.0.10/lib/bundler/resolver.rb:348:in `resolve_requirement'
... 213 levels...
from file:/C:/console/ROOT/WEB-INF/lib/jruby-rack-1.0.3.jar!/vendor/rack-1.2.1/rack/builder.rb:46:in `initialize'
from <script>:2:in `new'
from <script>:2

This was how my morning looked a week or two ago when I was starting up an installation of our Custodian’s Console on a Windows server. Take another look at that stack trace. (full trace here) It looks like bundler is causing some trouble in this app, right? In fact, it reads like bundler is in some sort of recursive blackhole and JRuby just gives up – as it should. Let’s see what Google has to say about this.

First search: JRuby, bundler and this error message

The results for my first search include a Warbler issue. WARBLER-21. In the comments, Nick Sieger recommends increasing the stack size:

“We’ve heard increased reports of “stack level too deep” with Bundler lately. In fact, we bumped up the default stack size to -Xss2048k in JRuby master as of ea20ac17. Can you try running Warbler as follows:

jruby -J-Xss2048k -S warble ...


Sounds perfect. This could be the answer… annnnnd nope. I try making these changes with no effect. In fact, I try passing in stack size changes in just about every conceivable way. (In the Tomcat docs they point out that you can also pass in an increased stack size with the -JvmSs option to the service itself.)

Hrm. Case of bad Google-Fu?

What about JRuby itself? Or Bundler?

I’m able to find another mention of this problem pretty quickly. This JRuby issue speaks about the *exact* same error. No suggested solution but to upgrade JRuby to 1.6 RC1 and bundler to latest (1.0.10)

Okay. I’ll bite.

I upgrade bundler. Same error.

Then I try using JRuby 1.6 RC1. No love.

I’m going to have to dig deeper – it could be 3 or 4 pages of Google search results before I find my answer!

Liferay?

After several pages of results and no luck I stumble across some postings on a message board (yuck!) for something called Liferay. Never heard of it. Turns out it has something to do with “market leading”, “portals” and “enterprises”. Oh, and message boards.

One such post talks about the same error I’m having and a working solution. Sort of.

I found out some further information. I am running Tomcat 6 as a service through the 64-bit Tomcatw.exe (procrun implementation). If I use the “jvm” startmode I get the above error. If I use the “java” startmode I don’t. Wanting to know why still.

That poor guy made the last post in that thread. I really dislike message boards.

Startmode, what’s that all about? Turns out that Tomcat Tomcat uses “procrun” to allow it to run as a service on Windows. Ahhhh, a mention of Windows. I like where this is going.

“Procrun is a set of applications that allow Windows users to wrap (mostly) Java applications (e.g. Tomcat) as a Windows service. The service can be set to automatically start when the machine boots and will continue to run with no user logged onto the machine.”

From the procrun docs:

“startmode” is here:

One of jvm, Java or exe. The modes are:
jvm – start Java in-process. Depends on jvm.dll, see –Jvm.
Java – same as exe, but automatically uses the default Java executable, i.e. %JAVA_HOME%\bin\java.exe. Make sure JAVA_HOME is set correctly, or use –JavaHome to provide the correct location. If neither is set, procrun will try to find the default JDK (not JRE) from the Windows registry.
exe – run the image as a separate process

Confirmed. Starting in ‘java’ startmode allows the console to start up but shutdown via the service console is now broken and the process runs as java.exe instead of tomcat6.exe. That’s a start but not really a long-term solution. Why would this be working when running as a separate process?

That question leads me to spend several hours trying to figure out if my parameters are actually being passed into the JVM. If you are trying to do the same let me save you some time. Edit the line in service.bat that looks like this:"%EXECUTABLE%" //IS//%SERVICE_NAME% to include --LogLevel Debug at the end. This little change will dump lots of useful information to the catalina or commons-daemon log.

If I set the startmode to java I can get things to run, just not the way we need or want. Time to try something else.

Back to the Liferay messageboards! Hooray.

Here is a post that actually proposes a solution to the problem:

The last post says:

“Tomcat 6 ships with v1.0.2 of Commons Daemon (in the form of tomcat6.exe and tomcat6w.exe). It seems this version is not compatible on certain combinations of 64-bit Windows and JDK6.

To resolve this, simply download v1.0.4 from http://commons.apache.org/daemon/download_daemon.cgi, replace tomcat6.exe and tomcat6w.exe with prunsrv.exe and prunmgr.exe respectively, rename to tomcat6.exe and tomcat6w.exe and run service.bat.”

THAT’S what I’m talking about! I follow the proposal and it works. Neat-o.

Onward to a permanent solution

The newest procrun (v1.0.5) works just fine on Windows Server 2008 64bit and 32bit. Although I can’t find the specific bug fix in daemons (procrun) JIRA, I can confirm that it works. I see some vague references to a reorg and some other moves happening in the code but nothing concrete. I’d rather not have to maintain versions of procrun along with Tomcat so I go hunting for Tomcat updates … Tomcat has since released 6.0.32 which includes commons daemon (procrun) v1.0.5 since version 6.0.30 – the console is currently on 6.0.29 so an upgrade fixes the problem.

If you are fighting with these kinds of issues with JRuby and Tomcat (or just Tomcat) it would behoove you to try a newer version of Tomcat first, they update regularly and pull in upstream changes for other components. You can check the Tomcat 6.0 changelog for details. For instance, the procrun update message went something like this:

Update to Commons Daemon 1.0.5. (mturk)

Good hunting!

During a recent upgrade of one of our applications to Rails 3 I encountered some interesting (frustrating) errors while running the unit tests.

For reference, application was moving from 2.3.4 to 3.0.4, the database was PostgreSQL using the pg gem, and the unit test suite included shoulda + factory_girl. The tests were run with `rake test` and `autotest`.

Here is an example of some of the error messages I beheld:

4) Error:
test: A PatentSafe error email with suspect headers should create a ticket with the correct title. (EmailInTest):
ActiveRecord::StatementInvalid: PGError: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"original_emails"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum



5) Error:
test: A received email note from a user should be assigned to the user if found. (EmailInTest):
ActiveRecord::StatementInvalid: PGError: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT "users"."id" FROM "users" WHERE ("users"."login_id" = 'some-email@amphora-research.com') AND ("users".id <> 9) LIMIT 1



31) Error:
test: An email re-sent to the notes address should return a single note. (MailReceiverTest):
ActiveRecord::StatementInvalid: PGError: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT "roles".* FROM "roles" WHERE (is_active = 't' and is_default = 't') LIMIT 1


As you can see, the errors aren’t really that similar except for the annoying transaction message and the traceback showed the errors weren’t coming from the same parts of the application. This happened so many times that it pains me to copy the messages here. What a weekend …

Amongst my attempted solutions were:

1. commenting out transactions in the application
2. turning off transactional_features in test_helper.rb with self.use_transactional_fixtures = true
3. running the tests with rake test
4. running the tests with autotest (not that I expected this to change my previous experience)
5. switching to minitest with minishoulda
6. starting a new rails 3 application with just a few tests

The most promising of which was starting a new application, but as soon as I had added most of the models, the errors returned. In all cases, the transaction errors were there, all 75 of them. Oh yes. I remember the count.

It occurred to me that I had read something about transaction and tests in the ActiveRecord documentation. From the doc:

Warning: one should not catch ActiveRecord::StatementInvalid exceptions inside a transaction block. StatementInvalid exceptions indicate that an error occurred at the database level, for example when a unique constraint is violated. On some database systems, such as PostgreSQL, database errors inside a transaction causes the entire transaction to become unusable until it’s restarted from the beginning.

Could the database be the problem? At least, in the short-term?

A quick edit to config/database.yml wasn’t too much to ask given all that I had already tried.


test:
adapter: sqlite3
database: db/test.sqlite3
pool: 5
timeout: 5000


Lo! The true errors showed themselves unto me!

No, really.

As soon as I was on sqlite3 I could see the actual application errors that were causing me such trouble. My assumption is that the way sqlite handles transactions, without nesting, allows my application to keep on trucking when it encounters an error while wrapped in a unit test transaction.

If, you’re in a time crunch as I was, you can use this method to get your tests running and get the application upgraded but this isn’t a long-term solution. It leaves you vulnerable to differences in Sqlite and your production database, PostgreSQL in my case.

This solution raises more questions than it answers, however.

Why wasn’t I having this problem in Rails 2.3.4?

I’ve taken a quick poke around Rails and a lot has changed. It’s highly likely that my tests were passing in 2.3.4 as a fluke and not by design. Would that I could answer this question definitively.

Is the problem in the Rails test framework/runner or in ActiveRecord?

As this project needs to be upgraded now, I don’t have the luxury of working through this one. My initial attempts to use minitest for testing show that the transaction problem still existed so this makes me thing something bigger is at play.

Am I following the prescribed path with regards to Rails testing?

I copied the test setup over after setting up the new Rails 3 app and am using this as my template (mainly just test_helper.rb). It looks like I’m following the Rails Way™. I can’t shake the feeling that I’m doing something wrong in my tests.

Got any thoughts for me? Share them in the comments and help me get this figured out once and for all.

I was recently wrestling with an obscure JDBC bug in Sequel. I was seeing an error connecting to the PostgreSQL database but it was being rescued by the Sequel JDBC adapter and hidden a little bit. (If you’re curious to see the fix it’s over on Github). Anyway, the original error led me to believe that the JDBC adapter for postgres wasn’t being loaded at all.

What to do?

What else? Get on the #jruby IRC channel on Freenode. Seriously, when you’re running JRuby and you come across a problem you go to there. Charles, Nick, and Tom (JRuby core) are always lurking around and very willing to help. Charles told me to look at $” and see what was loaded.

$”

A magic-pre-defined variable in Ruby (and JRuby) – see what I did there with the title? According to zenspider’s QuickRef:

$" The array contains the module names loaded by require.

Huh. Okay, cool. As a bonus JRuby throws the loaded jars in there as well. ( I really should learn all of these, come to think it, so should you. )

So what

You take a look at that array and you’ll see all of the modules names currently loaded. Good stuff. Here is the part from the project that helped me resolve my issue:

jdbc/postgres.rb
postgresql-8.4-702.jdbc4.jar
arjdbc/postgresql/connection_methods.rb
active_record/connection_adapters/postgresql_adapter.rb
arjdbc/postgresql/adapter.rb

I was able to see that the postgresql jar was loaded along with the supporting cast of characters. This led me to the #sequel IRC channel where Jeremy Evans and I were able to figure this little guy out. Trying to troubleshoot a potential jar loading problem in JRuby? $” is your friend. (and so is IRC it seems!)

The Stack

One of our production servers is running OpenSolaris version OpenSolaris 2008.11 snv_101b_rc2 X86, Ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-solaris2.11], and PostgreSQL 8.3.4. We use Capistrano for deployment with some bundler goodness thrown in the mix.

The Problem

Here’s what we see when bundler tries to build the gem:

ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/usr/local/rubies/ruby-1.8.7-p302/bin/ruby extconf.rb
checking for pg_config... yes
checking for libpq-fe.h... yes
checking for libpq/libpq-fs.h... yes
checking for PQconnectdb() in -lpq... no
checking for PQconnectdb() in -llibpq... no
checking for PQconnectdb() in -lms/libpq... no
Can't find the PostgreSQL client library (libpq)
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/usr/local/rubies/ruby-1.8.7-p302/bin/ruby
        --with-pg
        --without-pg
        --with-pg-config
        --without-pg-config
        --with-pg-dir
        --without-pg-dir
        --with-pg-include
        --without-pg-include=${pg-dir}/include
        --with-pg-lib
        --without-pg-lib=${pg-dir}/lib
        --with-pqlib
        --without-pqlib
        --with-libpqlib
        --without-libpqlib
        --with-ms/libpqlib
        --without-ms/libpqlib

Oh yeah! Good stuff right there.

The Investigation

At first, I thought the problems were to do with the development libraries being missing. This is frequently the case, and the error message pretty much says just that. Wrong – libpq was (and is) present. In fact, prior to the pg gem, we had the postgres gem running and it had the same dependencies. Next up: must be a mixup in the deployment situation. Not so. Capistrano and bundler both checked out okay.

After my searches on The Google provided ample proof that compilation on a Solaris box can be tricky, my next suspect was a wonky compiler toolchain. Nope, toolchain was just fine. Heck, I even checked the rbconfig.rb to make sure. That’s right, I’m thorough.

The (Temporary) Solution

On a lark, and after a day of trying all kinds of weird little tweaks … I figured, what about 0.9 ??? A quick look through the commits on 0.10.0 showed some recent work on the build system. Why not? Quick, change the Gemfile:

source 'http://rubygems.org'

gem 'rails', '3.0.3'
gem 'pg', '~> 0.9.0'

# That '~>' operator tells Bundler/Rubygems to allow gem updates to
# the least significant portion of the version number for that gem. 

# In the Gemfile snippet above, I am signifying that I will allow any pg version
# in the 0.9.x branch. Had I specified '~> 0.9', bundler would install
# the newest pg gem with a major version of '0.'.

Then

  > bundle install
  > git add .
  > git commit -m "Attempt to use pg 0.9"
  > git push
  > cap deploy

SUCCESS!

I just opened this issue on the pg project and will update this space when we come up with a solution. For now, just install the pg gem from the 0.9.x version.

Epilogue

You might be wondering why I would care if I’m running this particular gem for Postgres connectivity. There are three postgres gems out there that I know of: pg, postgres, and postgres-pr. Let’s take a look at some stats from rubygems.org:

gem                 version             date            downloads
----------------    -----------------   -------------   ----------
postgres (native)   0.7.9.2008.01.28    Jan 28, 2008          49K
postgres-pr (ruby)  0.6.3               Dec 14, 2009          35K
pg (native)         0.10.0              Dec 01, 2010         210K

Even taking the subjective versioning and download numbers, I want us to use a library that is actively maintained and well used. Michael Granger is all over pg and having the most downloads by far, gives me the warm fuzzy that errors will have been encountered and (hopefully) fixed. Since we run on a platform that can use the native gems, pg is the obvious choice – for us. Of course, as they say, your mileage may vary.

UPDATE Dec. 15, 2010:

The issue has been updated – looks like this isn’t an isolated problem.

The net result of this is we have a pure Java print server which you can print to from an iOS device. You can print from your iPad to the server, which will produce a PDF as a result.

We’re aware this might be of interest to other people; if you have an application where you feel it might be of use, drop us a line and we can discuss… and if you need help writing/perfecting your own iPad print server I am sure we can help.

In our main pound.cfg file we have a line like this:

Include "/etc/pound/morescience.config"

The morescience.config file contains just what we’d normally put in the pound.cfg file.

Seems to work fine, we haven’t tried with anything other than a full pathname in quotes.

Hope that helps someone who also can’t find the Include directive in Pound’s documentation…

GlassFish

GlassFish v3 is a reference implementation of Java EE 6. Quite a mouthful. For Rails developers: it uses some of the latest and greatest technology available on the Java 6 Enterprise Edition, and that means the deployment environment is going to need JDK 6 (Java Development Kit), which clocks in between 42-63MB.

The GlassFish application server has first class support for two deployment methods for Rails applications:

• Directory-based
• WAR-based

(Technically, you could use the GlassFish gem and deploy your applications this way, but it seems to be the same style of deployment you all know and love with mongrel/thin/unicorn/etc – and who wants to read another article about that?)

The differences between the deployment methods are subtle but important: a WAR can have JRuby bundled with it, whereas you’ll need to install JRuby separately with directory deployment. A WAR deploy can get you closer to a self-contained application, if that is your goal. Additionally, with the WAR file, you can drop it into the GlassFish autodeploy directory and the application server will automagically detect it and deploy. (We use Warbler, a library that will take a Rails application and package it up in a WAR with JRuby and jruby-rack, both of which you need.)

A note on asadmin: Most of what you do with GlassFish will be done using the asadmin command. In fact, it seems to be the hub of the GlassFish universe.

Installing GlassFish

Installation is a simple affair – just head over to GlassFish v3 Downloads and pick your poison. There is a GUI installer for Windows, Solaris, Linux and MacOSX. Thankfully, there is also a platform independent zip file.

GlassFish Architecture

Here is where it gets interesting(?) … *deep breath* This GlassFish “server” can house multiple domains, which in turn, have many server instances, and these server instances are where your applications are deployed. *whew!* A good resource for truly understanding the GlassFish architecture is GlassFish Administration by Xuekun Kou (also on Safari Books Online). Luckily, with the out-of-the-box install you get a default domain (domain1) and a default server instance. Remember that GlassFish is intended to do all the fancy things that a Java application server can do, so you can have clustering, multiple domains, multiple applications running in a single domain, the same application running on multiple server instances – pretty much whatever you can think of.

Deploy That App!

So, GlassFish is installed. You need asadmin to get things going.

> asadmin start-domain

This command will, um, start the domain. (If you had the war file in autodeploy, or if the application had been previously deployed, it would be deployed/started during domain initialization.)  GlassFish features a fairly complete administrative UI which is available at http://yourserver:4848. The admin site takes a little bit to start up as GlassFish doesn’t load anything until it is requested, this includes your Rails application. That first request is a biggie! From the admin site you can monitor performance, view logs, change settings, and all kinds of fun stuff. Take a look around, and ask yourself, “Do I really need any/all of this?”.

Deploy from a directory or “It sounds easy but it may be the same dance you do now”

Remember, if you aren’t bundling JRuby with your application you’ll need to tell GlassFish where it is …

> asadmin configure-jruby-container --jruby.home=/path/to/jruby-x.x.x

and you’ll need to have all the gems installed, etc, etc. (Sound familiar?) In this case, it would be wise to have your gems vendored in your Rails application. From the directory above your rails application run:

> $GLASSFISH_HOME/bin/asadmin deploy your-rails-app/

This will deploy the application to your server at http://localhost:3000/your-rails-app. Any errors will be available in $GLASSFISH_HOME/domains/domain1/logs/server.log

Deploy from a WAR or “It sounds easy and it is“

Assuming you’ve got your Rails application all WAR’d up (using Warbler, of course). Warbler ensures that JRuby, jruby-rack, and all your gems are included.

> asadmin deploy /path/to/your-rails-app.war

This will deploy your application to your server at http://localhost:3000/your-rails-app. Same as above. Notice you didn’t have to do anything to tell GlassFish about JRuby or the gems. Nice!

Alternatively, you can drop your-rails-app.war in $GLASSFISH_HOME/domains/domain1/autodeploy and GlassFish will do the rest.

Making your app the root application (and changing the deployed app name)

You may want your rails application to be available at http://localhost:3000/ (or the root of the server). Again, asadmin is your friend:

> asadmin deploy --contextroot / /path/to/your-rails-app.war

Now your application is served at the root of the GlassFish server instance.

Want to change the name of the deployed application?

> asadmin deploy --name myapp /path/to/your-rails-app.war

Now you have http://localhost:3000/myapp

Our thoughts

As mentioned earlier, GlassFish would seem to shine when used for internal application deployments where you want to leverage existing infrastructure by hosting multiple Rails application within a single GlassFish install or using the GlassFish clustering options. Imagine using Capistrano to just push up the newest WAR and having GlassFish autodeploy that, no more stopping and starting your webservers! The monitoring and administration would also provide you with insight that isn’t provided in other Rails installation methods.

We played with GlassFish for a bit and decided that for our purposes it was a bit heavy. What were we looking for?:

• easy deployment (not just for internal techies)
• ability to provide a zip file with everything needed in it, no install needed
• no admin UI
• deploy without dependence on a central command (asadmin anyone?) – we could have used autodeploy here
• smallest download possible
• least amount of external dependencies (GlassFish requires the JDK and your run-of-the-mill Rails app isn’t going to need all that!)

Keep in mind our Custodian Console is a Rails application installed at customer sites, we do not always have direct access to the servers so we need deployment to be fire and forget. This led us to pursue Tomcat as an alternative and this set up will be the topic of a future post.


// Set the attributes of the file we've just created which is a little clumsy - you have to create a dictionary of attributes
NSDictionary *attributes;
NSNumber *permissions;
permissions = [NSNumber numberWithUnsignedLong: 493];
attributes = [NSDictionary dictionaryWithObject:permissions forKey:NSFilePosixPermissions];
// This actually sets the permissions
[[NSFileManager defaultManager] setAttributes:attributes ofItemAtPath:filePath error:&error];


I should preface this with the fact that I really have no idea what I am doing, which makes it kind of fun for me although I might be making some basic mistakes! Anyway, I hope this helps someone…

I want my App to respond to a URL scheme, so I followed the example here on CocoaDev. Which worked first time when I had the application running in the debugger. You put your URL schemes in the .plist file and then I had done this in my applicationDidFinishLaunching: method (as I didn’t have an init() method in the class already – maybe I should have created one but I wondered if that had been deprecated):


[[NSAppleEventManager sharedAppleEventManager] setEventHandler:self
andSelector:@selector(getUrl:withReplyEvent:)
forEventClass:kInternetEventClass
andEventID:kAEGetURL];


My problem was when the application wasn't running, it would launch in response to the URL click, but it wouldn't process the URL - it was being thrown away.

The trick was to put it in the applicationWillFinishLaunching: method, which now looks like this:

// This is called just before it will finish launching
- (void)applicationWillFinishLaunching:(NSNotification *)aNotification {
// Register ourselves as a URL handler for this URL
[[NSAppleEventManager sharedAppleEventManager] setEventHandler:self
andSelector:@selector(getUrl:withReplyEvent:)
forEventClass:kInternetEventClass
andEventID:kAEGetURL];
}


(note in the code examples above, I've split the lines to make them more readable)

We like most technies benefit greatly from the free Technical resources out there – Open Source software, other people’s blogs, Google etc. If I compare how I can work today to when I started working in Software Development (and I’m not that old, I promise!), the ability to just type an error message into Google saves me hours every week.

The question is, how can we participate in this, to give something back? We’ve tried a variety of solutions:

• Personal blogs, but none of us really have the time or inclination to keep one going.
• A Wiki where we were going to write interesting stuff up, which never really got populated because it was too much work.

We think a blog might work, and if we use a shared one then individuals can just add stuff as they feel moved to and not have to feel pressured to write to meet an audience’s expectations.

The material here won’t fit well on our other blogs, which are more ELN-related. So we’ve created this blog, where our techies can just contribute back tot he community we’ve benefitted so much from. I don’t have high expectations in terms of influence or regular readership, and clearly we’ll have to keep an eye on the competitive issues!

Our hope is that if we spend an hour figuring something out, instead of writing it up internally, we can put it here – and one day someone will themselves Google for a problem, find a post here which helps, and be on their way.