The GoGoEgo framework supports most popular scripting languages via Java Scripting (JSR 223) plugins.  Javascript, which comes with the JVM, and Python (Jython), which is installed by default on our cloud sites.

Of these, Jython has been the more common for server side scripting, and is what we generally recommend to new developers on the platform.  It's blazingly fast, and has a handy standard library of features.

But we've been writing an awful lot of Ruby lately, since we develop and maintain several large Rails apps.  JRuby 1.4.0 works great under GoGoEgo, and there's a port of JRuby-Rack which allows Rails apps to run directly (and super efficiently) under GoGoEgo sites -- the IUCN Red List of Threatened Species is one monster example.  Believe it or not, The Red List is running measurably faster and about 1/3 lighter under JRuby and GoGoEgo than under its old lighttpd and MRI stack.  The performance advantage comes primarily from the ability to offload a huge amount of view processing to GoGoEgo.

Now for those folks scripting simple page behaviors in PostLaunch Studio ... Ruby is also a pretty snazzy option.  With the latest (1.5.0dev) Ruby plugin, all the behaviors that work in Jython and Javascript now work in Ruby.  Here's a working script fragment ported from its Jython equivalent.

you = $GoGoEgo.getPlugin("Identity").getId
if you == nil
 $document.write "Please <a href='/portals'>log in</a> to use this page."
else
 mode = you[-2,2]
 you = you[0..-2]
  if you != $base.getCollectionID and mode != "+a":
 $document.write <<-END
 Your account is not allowed to use this page.
 Please <a href='/portals/logout.html'>log out</a> and log in as an administrator
 or the user #{base.getCollectionID}
 END
 else
 $document.write <<-END
 <div id='portal_files_header'>
 Files available for : <b>#{$base.getCollectionName}</b> &#160; &#160;
 <span style='font-size:small'>[<a href='/portals/logout.html'>Log Out</a>]</span>
 </div>
 END
 for i in 0..$base.getItemCount
 $document.writeEL "/collections/portals/storage/#{$base.getCollectionID}/#{$base.getItemObject(i).itemID}/storageitem.html"
     if (i+1) < $base.getItemCount()
 $document.write "<hr color='#e83f22'>"
 end
 end
 $document.write <<-END
 <div style='margin-top: 20px'></div><div>Upload a new item:</div>
 <form method="post" enctype="multipart/form-data">
 <div><input type='file' name='file'/></div>
 <div>Name:<br/>
 <input type='text' name='name' size='60'/></div>
 <div>Description:<br/>
 <textarea name='description' rows='3' cols='60'></textarea></div>
 <div><input type='submit' value='Upload'/></div>
 </form>
 END
 end
end

Just install the org.jruby bundle (1.4.0) and use script type server-parsed/ruby.  There are only two really important differences to note -- the JSR 223 support for Ruby (via @yokolet's very nice Red Bridge integration) delivers ScriptContext variables as globals by default.  This means that the document and base objects will be referred to as $document and $base respectively.

The script performance isn't as mind-blowing as Jython, but as Ruby people are fond of saying, it's "fast enough" and it's a nice, expressive language.  If you're writing a lot of Ruby anyway, it's easier to dash off some Ruby syntax than switch mindsets into another language.

In the near future, I hope to emerge a couple of plugins that provide alternative and more Ruby-friendly access to content collections.  This would allow Ruby scripters to use the very expressive iteration idioms of the language instead of writing Ruby that looks suspiciously like Java.  This is mostly a matter of naming methods the right things, but I also know a lot of JRuby internals by now, so I can put that to good use.  A version of DataAccess, using the same idioms, would be great for fast prototyping of light database features.

Down the road, we need some way to load gems scoped specifically to one site.  Currently, gems can be loaded just fine, but they need to be installed at the system level where JRuby can find them, and can't be dropped in through the PostLaunch Studio.  But, there will need to be some security restrictions and JRuby runtime management put in place first, so this is no small undertaking.  The Rails integration already handles this by looking for vendored gems in your Rails application, but the idea is to expose similar capabilities to someone who just wants to write a few lines of script.

Anyway, I'm having fun with it so far.  I like having Ruby at my disposal in places other than full-stack Rails projects.

Because of the variety of my work, I get to use a number of different Web development environments.  In the past two weeks, I've done non-trivial work on projects using:

JSP
ASP.NET
Django
GWT
PHP (WordPress)
Restlet
Rails
Sinatra

I'm fortunate to get front-line experience with the good and bad of all these ways of producing something on the Web.  Of course I have certain favorites that work really well for the way I think, and the dynamics of my team at Solertium -- everybody knows I love Restlet and GWT, and the latest bleeding edge trunk versions of each.

I have other favorites.  I think you can't beat the terse elegance of Ruby with a DSL like Sinatra and an awesome ORM like ActiveRecord.  I'm still wowed by Rails' ability to scaffold a complex application with a couple shell commands.  Even my non-favorites have their bright points:  ASP's performance really is the number to beat, and while I personally lack the Microsoft-fu to get good results with it, I'm blown away by the sheer transaction-per-second output of a platform virtuoso like Scottie Nguyen of NACA.  I can't make a maintainable application in PHP, but obviously some other people can: WordPress and its plugin community are proof.

But ... can't we all just get along?  It's very frustrating how heavily each framework optimizes for its own development community, and typically gives lip-service to interoperability.  Microsoft, of all unlikely entities, is often in the lead with its COM-based cross-language, interconnected-framework approach, and heavy leverage of SOAP and similar APIs ... assuming you're running a Microsoft OS and web server, interoperability within those constraints is a breeze.

So this is me coming clean about my hidden agenda behind GoGoEgo as a Web development framework: creating a friendly framework that provides one solid development model, but warmly embraces others.  Working in order of favoritism (because that's my prerogative as a CTO), we began by laying out a development strategy based on Restlet, GWT, and OSGi in the Java world.  Now that the model is mature, we're heavily embracing JRuby -- Rails, Sinatra and friends -- essentially making GoGoEgo into a super-performant and manageable container for Ruby deployment, that happens to support injection of static artifacts via a rich browser based Studio.  We have three very large projects going on now that combine GoGoEgo Java and Ruby bits in this way -- announcements to follow later this year.

Other JVM-hosted languages and frameworks are easy to bridge in later.  I'm looking for a Groovy/Grails expert to get on board.  Scala will probably get its own terse version of the Restlet-powered GoGoEgo API, sometime after Restlet 2.0 GA.  Python scripting is already the best way to do server side script in GoGoEgo -- now with Jython 2.5 -- and no reason we couldn't do Rails-like tricks with Django.  The guys at Caucho already have a really solid PHP emulation on the JVM, and they're brilliant, so why not support PHP as well?  I doubt a Microsoft-optimized GoGoEgo will ever come out of Solertium directly, but that's the miracle of open source ... as the platform keeps expanding exponentially, someday an enterprising soul will make a port.

Of course, to live up to my friendly framework objective, at some point we'll have to expose some kind of session model for non-RESTful applications.  But, again in order of favoritism, this can be at the bottom of the queue.  Nobody said we had to be that friendly!

After Gmail, Docs gets the heaviest workout here at Solertium. We love it because anyone can collaborate on a document - it’s operating system-independent and doesn’t require the purchase or download of a suite of office tools like MS Office or OpenOffice. Google Docs includes text documents, spreadsheets, presentations, and forms, all of which can be shared with anyone with an email address.

Most frequently, we use Docs for:

• Writing up requirements for a new custom software development project: Solertium staff & our clients can hammer out all the details, and then the client has all the language needed for their contracts. Keeps us organized in that we’re not sharing around multiple docs with track changes turned on - everyone’s working from the same copy
• Spreadsheets for tracking individual contract line items: Solertium staff & our clients share the same view of costs, status of work (authorized, in progress, delivered, accepted, etc.), invoice status, notes, etc. There’s also chat functionality, so we can chat & clarify any line items on the fly with our customers
• Collecting form data: Data from web forms can be automatically dumped into a Google Docs spreadsheet. For customers who used to just receive the information via email, this is a handy repository for their data.
• Internal documentation for the company: In addition to basic forms like expense reimbursement, we also use spreadsheets to track potential and upcoming projects and work out budgets for new lines of business. We can share docs like these with our board, so they always have up-to-date information on the health of the company.

Docs comes with a huge template gallery, filled with handy tools for business owners. You can find project management schedulers, invoice templates, calculators, expense reports, card/letterhead/newsletter templates, themes for presentations, “contact us” website forms - the list is almost never ending. There’s even a template for a venture capitalist pitch!

In addition to keeping everyone literally on the same page, Docs has the added benefit of helping to keep our printing needs to a minimum. Maybe once a quarter an office supply rep will swing by to try to sell us stuff. It’s always a short conversation, because I have a great metric: it takes us more than a year to go through a single box of paper. Google Apps is a big part of making us a close-to-paperless office.

You can learn the basics of Google Apps: Docs by watching the introductory video below. And, as always, if you need any assistance with setting up your Google Apps Premier Accounts, please contact us.

We have been busy re-plumbing our support infrastructure and have some new resources to share:

Help Desk for direct customers
help.solertium.com

Our new help desk is powered by ZenDesk and integrates with FreshBooks, so we have a simple path between customer requests, time tracking and invoicing.  Emails to "support" will automatically create issues in the help desk, but you can create them with better detail by going to help.solertium.com on the Web.  The help desk and its attached knowledge base are only available to our direct customers.

We're especially excited that ZenDesk gives us the ability to monitor turnaround times, so we can finally offer and monitor customer service SLAs.

Don't worry if you're used to emailing each of us directly -- we chose ZenDesk for our current needs because it helps us out, instead of getting in the way.  When you open a ticket at help.solertium.com or via the "support" address, the system automatically emails all of us and makes it easy for the right person to pick up your work, then track it and notify you when it's complete.

You'll also see some check boxes on the issue report form that allow you to pre-authorize up to 15 minutes, 2 hours, or 8 hours of work toward the ticket.  When you're ready to get something new done and don't want to have a long back-and-forth about estimates and authorization, this checkbox cuts out that entire step; we can address the issue immediately without extra paperwork.

We look forward to hearing your feedback on the help desk.  With your help, we can improve the process even more as we go along.

Google Group for GoGoEgo Open Source developer and partner discussion
http://groups.google.com/group/gogoego

The Google Group has actually been around for a while -- it's attached to our Google Code project at gogoego.googlecode.com -- but was set to private and was mostly unused.  The group is now public, and receives issue notifications from the Google Code tracker.  We invite anyone developing with or contributing to GoGoEgo to join the group.

I can't believe this first message about JSR223 scripting was posted to the group just a little over a year ago.  It seems like we have been using scripting in production Web sites forever!

We are getting very close to the public code drop of GoGoEgo Open Source 1.1 and the opening of our early access program for GoGoEgo Commerce integrators.  We're wrapping up the 1.1 code freeze and I look forward to branching the Google Code project as soon as I get a chance to review the snapshot.

I was asked recently, in conjunction with this, what to expect from version numbering in GoGoEgo.  I've posted it before elsewhere, but here are the general rules:

• Major versions (1.x, 2.x) may diverge in very significant ways from each other, and are expected to have only limited portability.
  • No major (2.0) version of GoGoEgo is currently on the roadmap, although we hope to change that in a long range planning session soon.
• Minor versions (1.0, 1.1, 1.2) are expected to be mostly compatible and architecturally similar, but may introduce some breaking changes.  For example, a site that runs on 1.0 will require some small changes in scripts and templates in order to run on 1.1.  Plugins may also need to be targeted to a specific minor version; a plugin for 1.0 will not necessarily run on 1.1.
  • A 1.2 version of GoGoEgo is already well into planning.  Many of the planned features are emerging in the issue tracker at gogoego.googlecode.com.
• Revisions (1.1.1, 1.1.2, 1.1.3) are meant to be transparent and introduce only additive changes or non-breaking bug fixes.  The only exception to this is a critical security problem, exploitable by a non-privileged user, that require a breaking change; we will introduce this category of bug fix in a prompt revision to each actively maintained version, regardless of impact.  Still, revisions should be largely transparent and of interest mainly to project contributors.
  • Revisions happen all the time without much formal planning; it looks, right now, like the first public binary drop of 1.1 will actually be revision number 1.1.4
• You may also see package identifiers or dates appended as a fourth term, e.g. 1.1.1.2009061901 -- but this is significant only to packaging details, the software inside should be the same regardless of the package identifier.

Plugins may have their own version numbering scheme that has nothing to do with GoGoEgo version numbering, but we do recommend the following:

• Follow a hierarchical versioning scheme similar to the one above -- which in turn echoes the practices used by GNU, Eclipse, and Debian -- don't change major versions every time you update the plugin with a new feature.
• Use a major version number of 0 (e.g. 0.1.1) for a plug-in that is experimental or in a state of rapid flux.
• Make sure to use the manifest to state which GoGoEgo API minimum version your plugin requires.  But, don't specify a maximum version unless you know for a fact that a later version of GoGoEgo won't work.

I'll cross-post this information in the Google Group and Help Desk Forum so it's easy to find in the future.

Finding a good fit with your business email provider is crucial, especially for a tech company. Our needs are simple; we just need to be able to receive and send email at all times. Sure, when you’re 35,000 feet in the air that’s a little impossible - but even that is changing as airlines are starting to add wifi to some flights.  Talk about cloud computing.

We’ve been on Google Apps Premier Edition for almost a year and a half now. The world knows about the few times we’ve had outages, as whenever Gmail goes down there’s a hue and a cry. Aside from those brief episodes (and we weren’t affected by all of them), Google Apps has been fabulous. And their downtime compared to previous solutions we’ve tried is a rounding error.

We can get mail at work, at home, and on our cell phones (FYI - those new Androids we scored at Google I/O last month have the tightest integration yet!). We use the web client, which means no additional software to purchase and support. And the client is stellar: loads fast, threaded conversation view, integrated Chat, and labels are all great features. And the search functionality can’t be beat. Don't believe me? The video below details the Gmail features in Google Apps.

I am a list moderator for DC Web Women, and Google Apps makes makes my job easy and fast. A filter slaps a “DCWW” label on all incoming list mail and automatically archives it for me. When I send out a message, it’s easy to make sure it sends from my “listmom@” address. The threaded conversations keep topics organized, and I can star messages/topics that I want to track. Plus, 26 Gigs of storage and the ability to search helps back me up if I need to track the history of an issue or list member. Listmomming would be overwhelming if I wasn’t using Google Apps.

Google Apps makes business communication easy, and the price point makes it a great equalizer. At $50/account/year, there is no barrier to a small business using the same quality product as a company as large as, say, Google. Contact us if you need help setting up your Google Apps Premier Edition today.

Rob & Alison are heading out to Google I/O in San Francisco today.  Google's largest developer gathering, it promises to be 2 days chock full of events, releases, learning, and networking.

Alison is planning on tweeting throughout; you can follow her updates at @alisonheittman and get an idea of what's going on. She's got a few blocks of time uncommitted, so feel free to tweet her & request attendance & updates from a session.  The hashtag for Google I/O is #io2009, for those who want to follow all the coverage.

Solertium is proud to be a technology partner of the Protect Planet Ocean portal.

In mid-2008, Dr. Dan Laffoley and the steering committee of the Protect Planet Ocean initiative asked for our help integrating exciting new Google technologies into a proposed new Web portal.  The timetable was short.  Dozens of stakeholders were contributing.  And the key elements of the project relied on technologies in alpha or beta, with feature sets changing from week to week.

Together with IUCN, Google, and the other Protect Planet Ocean partners, we launched Protect Planet Ocean on schedule at the World Conservation Congress in Barcelona, in conjunction with a Google Outreach Marine Protected Area layer that offered a tantalizing glimpse of things to come in Google Earth coverage of the ocean.

Now, with the release of Ocean in Google Earth, we look forward to helping fulfill the promise of Protect Planet Ocean, bringing millions of new Earth-surfing minds to a deep awareness of the plight of the oceans, and the urgent efforts needed to save the world's last frontier.

We're ready to do it all over again.

What's the next challenge?  We look forward to hearing from committed non-profits with enterprising ideas for using new technology to save a challenged world.  We're immersed in the Google developer community, pioneers of open source, and wizards of the iPhone.

Portals.  Databases.  Online, offline, and mobile systems.  Mapping and GIS.  Impossible deadlines and tight budgets.  We've been there, done that, and are ready to do it again.

Contact us with your wildest ideas, and let's get started.

-- The team at Solertium
   Alison, Rob, Carl, Adam, Dave, Liz, Tiffany and Mary

Whether it's your first project or your fiftieth, here is a handy list of 6 things to keep in mind when working with a company like Solertium. Each of these come up on a pretty frequent basis, and I have found that confusion about any or all of these points can be avoided by just making things plain up front.

1. Whatever you want, we’ll tell you if we can build it. We’re pretty sure we can deliver most anything you can think of, but if we can’t, we’ll be straight with you. And if you want us to build something that we’re not great at, we’ll tell you that, too. Because, while it’s nice to be paid for the things we’re good at, it’s downright painful to send a bill for something we’re slow at. We’d rather another superstar got paid to shine on that job.
2. We’re not a temp agency, we're a team. Trust us to task the right person for the job. You’re ordering deliverables from us, not a set # of hours of a specific resource’s time. We commit to meeting your deliverables within an agreed-upon budget; we can do that only when you allow us to determine the best resource for each part of your job. That said, if you have your heart set upon a specific resource, it can be arranged. But it may be pricey, as you will be asking us to re-work our schedules and perhaps pull that person away from another commitment.
3. If you ask us to spend time with you in meetings, sending hourly status updates, or answering out-of-bandwidth technical questions, expect to receive a bill for our time. We like to be responsive and give you all the time you want from us, so it can be hard to remember that we’re not your co-workers receiving a straight salary. When you ask for us to spend additional time, you are likely increasing the hours we will be invoicing you for. And, when we check with you to make sure you know this is happening (and, in some cases, to make sure you’re authorized to do it), please don’t be upset with us. We’re looking out for you, and trying to avoid unpleasant conversations when you get the bill.
4. If you change your mind, it could change the price & timing of the job. It’s kind of like building a house: if you delete the detached garage from the project, you don’t have to pay for it. But if you decide you want to make your stairs four inches wider and raise your ceilings a foot, the job is going to take longer and just got a lot pricier.
5. Good, fast, cheap: pick two. Just like in construction, this old adage also holds true for the software industry. We like to think we can meet all three – and often do – but you’re safest if you pick two. For example, we’re always going to be good – but if you try to get us to jam a month’s worth of work into a week and won’t authorize payment for additional resources to complete the job, even we have our limits.
6. Learning is a two-way street. You may not know a lot about software; chances are we’re not experts in your industry, either. We’re going to have questions about what you do, so we can better understand the software we’re building. We expect you to have a lot of questions about custom software projects. Most of your questions about process should be answered by the consulting services agreement, but we know that a lot of it will be new to you. All we ask is that, if we’re confusing you, you let us know. And that you help us to learn how to better communicate in a way that you, specifically, can understand. We’re excited about what we do, and we’d prefer that you “get it” and become excited, too!

I make no guarantees that this list, or our perspective on any of the individual points, is representative of the industry as a whole. I can only say it's how we roll at Solertium.

We're excited to tell you that we've moved our office a couple of blocks over to The Design Center in New Town. While it's a very welcome change for us, most of you won't notice the difference since you rarely make it to Williamsburg to see us! And, for you locals (and those who choose to visit), the first thing we set up was the training lab.

Drop by sometime, and check us out at:

4350 New Town Avenue
Suite 202
Williamsburg, VA 23188

See you 'round the neighborhood!

PS - thanks to the William & Mary track & field team for moving us on Saturday - you were fabulous!!!

Four of us from Solertium just returned from the World Conservation Congress in Barcelona, where we supported our largest strategic customer, IUCN, the International Union for the Conservation of Nature.  IUCN is a democratic membership union including some of the largest organizations in conservation (WWF, The Nature Conservancy, Natural England, Birdlife International, Conservation International, etc.), governments, and almost 11,000 volunteer scientists.

In many ways, our most important contribution was to develop the Species Information Service (SIS) software used to compile IUCN's Red List of Threatened Species™  (http://www.iucnredlist.org)  This is the authoritative worldwide reference on threatened species.  2008 represented the largest update to the Red List ever, compiled by IUCN's team in Cambridge, UK using Solertium's software.  Our success in developing the SIS software follows many efforts by some of the largest names in the software and conservation sectors. SIS represents two years of continuous work and a significant investment by IUCN.

IUCN passed out USB sticks containing the SIS software and other resources, and conducted quiet and enthusiastically attended training sessions in between other business.  While the Red List -- SIS's output -- makes the headlines, it is very exciting and satisfying for us to know that our team built the system that made the 2008 Red List possible, and will power the scientific community's assessment of threatened species for years to come.  We continue to work on SIS, and to strategize with IUCN on how to build on and consolidate initial SIS successes.

We're thankful to Jim Ragle, Manager, Species Information at IUCN for his deep involvement, his commitment to the SIS mission, and his confidence in Solertium to achieve results.  We're also very grateful for the patience and diligence of Craig Hilton-Taylor and Caroline Pollock at the IUCN Red List Unit, who struggled through a long year of reconciling three diverse forms of Red List data, and launching a real product based largely on emerging technologies.

Our "splashiest" success at Barcelona was the launch of the Protect Planet Ocean portal (http://www.protectplanetocean.org).  This project was a joint effort between IUCN, Solertium, and Google, and ties in with Google's ongoing efforts to empower nonprofits and improve ecological awareness in Google Earth.  Protect Planet Ocean brought together content from more than a dozen NGO's in a historic collaboration, and exercises a broad combination of Google technologies, from Google Earth to YouTube to Blogger.  It also represents the first truly large-scale application of our GoGoEgo content management software, powered by Google Web Toolkit and hosted in production by Google App Engine.

We are thankful for the opportunity to work with everyone on the Protect Planet Ocean steering committee, and especially thrilled for the chance to roll up our sleeves with the core portal development team: Andrew Hurd, Dan Laffoley, Elizabeth De Santo, Louisa Wood, and Steve Miller.

Please be sure to check out these important global resources on the Web. We're proud of our entire team's contribution to these successes, but I especially wish to thank:  Adam Schwartz, who has very effectively led our involvement in SIS for nearly two years now; Liz Schwartz, who developed key SIS components and ported GoGoEgo to App Engine for Protect Planet Ocean, and Carl Scott, overall technical lead for the GoGoEgo CMS.