Responsibilities
The developer will serve as a team member and, where appropriate, mentor other associates in solutions to meet business needs. The ideal candidate will have experience working on agile teams developing software in a collaborative and iterative manner.

Knowledge Areas
The ideal candidate will have 2-6 years of experience in various programming environments as summarized by the following:

Summary
- Highly desired: Ruby/Rails, PHP, javascript frameworks (prototype, YUI, extjs, etc), mySQL, SQL Server, XHTML/CSS
- Next Best: Perl, Python, PostgreSQL
- Nice-to-Have: .NET

Detail
- Bachelor’s degree in software engineering or computer science
- Strong architectural design and implementation skills
- A demonstrated ability to keep abreast of new technology
- Ability to establish and maintain effective working relationships with team members, managers and product specialists
- Ability to maintain own work flow and meet deadlines
- Ability to work in a fast-paced and dynamic environment
- Ability to respond to frequent pressure to meet deadlines when work speed and sustained accuracy are paramount
- Ability to respond to frequent demands of multiple customers (internal and external)
- Experience developing multi-tiered web applications on open source platforms utilizing Ruby/Rails, PHP, REST, XML, SQL, AJAX, REST, SOAP, AOP, SOA, JavaScript, HTML and other related technologies and concepts
- Familiarity with open source frameworks and technologies including XAMPP/LAMP
- Experience with Agile Development (SCRUM / Extreme Programming) practices, such as Test Driven Development, Continuous Integration, Iterative Development, and Pair Programming
- Ontology and Semantic Web technology experience, such as RDF, OWL, SPARQL, and Jena/SDB, is a big plus
Rules / Recommendation / Personalization engine experience is a plus
- Leader or contributor in open-source software is a big plus

Qualities
- Energetic and communicative
- Highly Analytical, fact-based decision maker
- Ability to inspire and lead
- Champions change and effectively manage the implementation of new ideas
- Supports and solicits input from team members at all levels within the organization
- Communicates effectively.
- Ensures that we consistently deliver superior technical solutions
- Interest in or experience with internet and startup businesses
- Works well in a team environment

ALTERthought is an Equal Opportunity Employer. To be considered for this position, please contact us at at_careers@alterthought.com. Full-time and contract benefits include a combination of paid holidays, sick days, personal days and vacation, premium health and dental insurance and a casual work environment.

About ALTERthought
ALTERthought is a management and technology consultancy that specializes in the engineering of large-scale distributed systems and is guided by a vision to help its clients win. ALTERthought TM marshals its Research, Development, & Management capabilities to combine innovation with precision management for the success of its clients.

Clients include the Global 2000, esteemed online brands, and leading mid-market companies. Since its inception in 1998, the engineering consultancy has collaborated with its clients to envision, architect, and deliver business results through intelligent technology solutions. ALTERthought is headquartered in Richmond, Virginia with offices in the National Capital Region, Research Triangle Park, and the New York Metropolitan Area.

ALTERthought’s software engineering and business consulting offerings include: full lifecycle software development, enterprise architectural re/engineering, mentoring, estimation and budgeting, project management, business strategy, business process engineering, information technology strategy, open source technologies, and digital security. For more information, visit the company’s website at: www.alterthought.com.

Technorati Tags: ruby on rails, ruby jobs, rails jobs, ruby, rails careers, ruby careers, RoR jobs

Our client is a Fortune 200 company for who we began an enterprise initiative on May 30, 2007. Thanks to our tool Planix and our friends and their framework, 6th Sense Analytics, we’ve been capturing projected and actual effort on this project.

For the work (user stories) completed to date (8 weeks/40%) of the project, the actual productivity of Grails is outperforming our estimate for J2EE, Java/Spring, and, yes, Rails. Qualitatively, it can also be argued that we’re also performing integration in an Grails/Java environment that may pose challenges for a Rails/Ruby/Integrated environment.

As is the case with most of our clientele, we agree not to publicly disclose the specifics of who they are/the nature of their project. So, we will be a bit limited in the amount of context we can provide. However, this occasional series of posts is largely a quantitative examination, so we look forward to sharing with you the data from our findings as the project progresses.

Why Do this ?

There is a lot of ongoing debate regarding the “speed of development” in various technologies; we simply wanted to add some data to that conversation and elevate beyond a developer/team’s “gut feel” about why a particular technology is more productive.

Why Groovy/Grails ?

We began this project on May 30, 2007. Prior to its start, we proposed and obtained approval to utilize Groovy on Grails from the client’s Architecture Team. Our reason for championing the use of Grails arose from a handful of factors. Chief among these factors, in no particular order, were:

(a) Our company history and charter to continually examine promising emerging technologies for the benefit of our clients
(b) The potential level-of-effort productivity boosts promised by a couple of Grails prototypes we completed
(c) The flexibility of Java-based technologies in tackling what we thought would prove to be a relatively complex systems integration initiative
(d) Java-based/EE technologies are the client’s preferred platforms; their teams and processes are organized around Java. We needed a technology that could help maximize the value of existing application investments while offering RAD capabilities

Why Should I Believe your estimates for the Other Technologies?

This is a fair point, but we’re pretty confident that the estimates are faithful and accurate to the respective platforms. We estimated the effort using our estimation and planning tool, Planix (written in Rails). We’ve used this tool for 5 years in various forms and have lived by its accuracy. The tool does embody a fair bit of our own methdologies; however, if you’re looking for objectivity, you should know that many of its principles are adopted from the giant, Gustav Karner, of the objectory whose work is adapted from *the* giant in software economics, Barry Boehm. A quick Google search will turn up plenty of studies on the proven accuracy of the Karner Use Case Point approach for a project. What we’ve done throughout our history is to benchmark the productivity of a variety of technologies to give businesses trade-off options when it comes to cost and schedule.

What are the Takeaways ?

Grails is the latest in our effort to benchmark technologies and their respective productivity; to date, Grails is showing itself to be slightly more productive than using Rails – to the tune of about 5.8%. As others have observed, we do believe Grails to be a “formidable challenger” to Rails .. and we’re gathering data to back up our claim. Yes, premature precision will get us in trouble and the sample size is characterized by 1 project that is 40% complete, but … well, you get the picture.

Stay tuned for more productivity analysis as well as technical analysis on the resulting code base.

Technorati Tags: Rails, Ruby, Ruby on Rails, Grails, Groovy, Groovy on Grails, Grails Productivity, Rails Productivity, Software economics, Barry Boehm, Gustav Karner

“no government [technology movement] has ever fallen before attackers [rival technology] until it has lost control over its armed forces [engineers, bloggers, and evangelists] or lost the ability to use them effectively” – Crane Brinton

Its interesting to do a ‘find and replace’ on “regime, government, antiregime, radicals, extremist etc.” and substitute technology-related terms and movements in the summary I’ve excerpted below.

Its interesting to think about this model both from the perspective of the replacement/challenge of an ‘old line’ technology (.e.g J2EE, .NET) by an emergent technology (e.g. Rails). Its also interesting to perform the same ‘find and replace’ considering a split or schism within a particular technology movement (as has been hinted at in the Rails community and others before it)

I found a summary of Brinton’s work that allows this ‘find and replace’ on the Davis School District’s (Farmington, Utah) servers.

Perhaps its a stretch, but break out your favorite ‘find/replace’ tool and give it a shot yourself …

*The first stage of actual revolution comes with the growth of antiregime groups and the growth of their power to affect political thinking and behavior. Some critical problem arises which acts as a trigger for pent up dissatisfaction – such as whether the three estates should meet together or separately. The old regime can’t handle the problem. They lag in deciding or decide unpopularly. Rioting breaks out, but troops sent in to crush the rioters desert to the rioters side. The antiregime people take power relatively easily amidst widespread rejoicing. Popular expectations raise still further.

*Moderates initially wield power. They earlier had opposed the old regime but as critics rather than as revolutionaries. They want major reform rather than total revolution; to “fix” the government rather than replace it. The moderates tend to be motivated by morality, plurality, justice, and high ideals. Extremists accuse them of being weak and cowardly, and true enough, they are NOT ruthless enough to crush the extremists. The extremists begin to crush them.

*Extremists take over because they are more ruthless, purposeful, ideologically motivated, and are better organized than the moderates. In what Brinton likened to a fever during an illness, the extremists whip up revolution to a frenzy, throwing out everything old, forcing people to be “good” according to the new revolutionary standards. and punishing real or imagined enemies in a reign of terror which is intended to sweep away any potential threat to the revolution. In France, this stage came with Robespierre; in Iran, with Khomeini; and in Cambodia, with Pol Pot.

*A “Thermidor,” or calming-down period, ends the reign of terror. Brinton named Thermidor after the French Revolutionary month – the revolutionaries even threw out the old calendar – in which Robespierre fell. Every revolution has a Thermidor, which Brinton likened to a convalescence after a fever, because human nature can’t take the extremists and their revolutionary zeal and purity for too long. Power usually then falls into the hands of some opportunist/dictator, who restores order but NOT liberty, protection but not participation – in short, a Napoleon.

Just some food for thought …

Technorati Tags: crossing the chasm, Ruby on Rails, RoR, Anatomy of Revolution, Crane Brinton, Java, J2EE, .NET

Ruby on Rails as a Platform of Choice? The Case for Rails: examines why a business person *should* evangelize Rails as his or her chosen platform
Revenue on Ruby on Rails: examines our quantitative observations about productivity using the Rails framework

Two of the most interesting, legitimate, and constructive responses/rebuttals to both my post and the comments it engered that I’ve seen are the following:
From a noted Groovyist, Graeme Rocher: 5 More misconceptions about Grails
Graeme takes issue with the Rubyists and Railers denegrating Groovy/Grails.

“An interesting aspect of the above post however, was the reaction of Ruby/Rails users to the outrageous comment that Grails is a more realistic alternative in the enterprise. Some of the comments including even more classic misconceptions and knee-jerk reactions which I will address in this post..”

From Jon Dahl of Rail Spikes: Rails Develpers: Experts or Script Kiddies

Jon finds my statement regarding the mixed quality of developers in the Rails community to be interesting. Jon has the intellectual honesty to recognize that in a burgeoning movement such as Rails, its difficult and impossible to separate the technology from the enthusiasts as well as the poseurs. Both groups become ambassadors for the technolgy; and, given the groundswell in recognition for Ruby/Rails, the good, bad, and ugly come along with the territory.

“At the same time, there are a more and more mediocre Rails developers watering down the community. This wasn’t true two years ago, but as Rails grows, it attracts more and more newbies. There is nothing wrong with this; Rails is pretty welcoming to newbies, and today’s newbies are tomorrow’s experts.”

Jon does take issue with my statement that Rails encourages bad code and asserts the opposite. A position that I find to be accurate under the assumption that the developer is strong and legitimate. If not (see poseurs) business people tend to get apps that are problematic because Rails’ goodies and infrastructure can help cloak weak code as mediocre developers churn out features.

Skills Demand > Skills Supply …There appears to be considerably more demand for Rails programming than there are Rails programmers (irrespective of whether they are good programmers or mediocre ones). The theoretical speed of development and speed of enhancement (read: potential cost saving) as well as the trendiness (let’s face it) of Rails has inspired a legion of business visionaries to increase their demand for Rails programmers in order to get their own facebook-meets-amazon mind bender to market faster than the other guy.

Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 – $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours]

The Visual Basic effect … A corollary to the fact that “pretenders” are besieging the market is that Ruby on Rails provides so much scaffolding, hand-holding, and out-of-the-box functionality for developers that inexperienced/unsophisticated developers are able to initially delight clients with early releases. Like Visual Basic in the mid/early 1990s, Rails allows non-computer scientists to put together seemingly impressive applications. However, as a project progresses or application matures the truth becomes clear: (1) Rails helps bad coders write unscalable, unmaintainable, unmentionable code faster, ergo (2) Rails helps organizations fail faster.

No Swiss Army Knife … Ruby on Rails was developed to do one thing and one thing well: help teams write web applications with user interfaces that perform basic operations on relational databases. Period. If you have complex processing needs such as message queuing, quantitative optimization, etc you’ll need to either (a) look somewhere else (b) write it into the framework (not likely as the shepherds of the framework are zealots and opinionated about protecting it from “unintended uses”) or (c) find a way to integrate with other technologies which support your business requirements.

No Throat to Choke and a Chasm to Cross … If what you want is an alpha, beta, or a version one application that you may re-write down the road, Rails may be right for you, but if you’ve got shareholders you must answer, teams you must attract, grow, & maintain, or business groups you must support with vendor options and a cadre of capable employees, Rails is an iffy choice. There are no/very few established vendors backing Rails at this point either from an implementation or education standpoint. This makes adoption of the technology and its ability to cross the technology chasm questionable. Rails is still early on the S-curve. It may make inroads into enterprise application environments the way Linux did through techie revolutionaries. However, for it to truly become a technology that is well understood, well-supported, and, consequently, well entrenched, it will need the backing of a behemoth or two. Perhaps RoR will gain the support of IBM or an equivalent, but the backing of a programming framework — at least on the surface — seems a heck of lot more pock-marked with landmines (variability in installations) than supporting and advancing the kernel of an operating system that has been in existence for decades.

The Java Defense … Perhaps the biggest reason not to choose Rails is, well, Java. The “old guard” Javaists are adapting. They may not be benefiting from the “hoola hoop” craze that is all things Ruby. However, they’re not taking the RoR attack lying down. In fact, in a very Zen-like fashion, they are borrowing from the “one thing well” manifesto of RoR to develop equivalents including Groovy on Grails, Trails, and the like (We’ll write about some quantitative benefits of these developments which we’ve seen first-hand in upcoming posts; suffice it to say, Groovy/Grails is proving itself to be a formidable challenger). In enterprise-friendly terms this means companies will be able to “maximize and enhance their existing Java technology investments.” And, with Java you get the Swiss army knife.

EDIT: For completeness and for the sake of those who did not have the time to navigate our blog, In a previous post, we examined the virtues of Ruby on Rails from a business perspective…and the potential economics of Rails in another post ….

Technorati Tags: crossing the chasm, Ruby on Rails, RoR, Rails productivity, technology adoption, Groovy, Grails, Trails, time to market,

There is much hullabaloo about RoR being the best thing to hit software development since the compiler (for the techies, the pun was not intended, but I’ll take it). While it may be something less revolutionary than compiler innovation, one thing is for sure RoR is currently — and promises to continue being — a Disruptive Technology.

So, Why Rails ?

From our first hand experience, these are some reasons why Rails should or could be your platform of choice.

This post is decidedly one-sided, I’ll explore why *not* to choose Rails in my next post.

There are a number of assumptions behind the reasons I am about to enumerate for choosing RoR. While we’ll save the play book for setting up a project team for other posts, I will say that a major assumption here is the quality of your team. That established, if you do assume a strong team while using development framework ‘A’ versus development framework ‘B,’ the benefits of Rails are as follows:

$$$$$ -You get stuff sooner. Its that simple. As a stakeholder, I’ve seen Rails teams turn features around in ½ the time as it would have taken them to do it using J2EE or .NET (see this post for a little comparison on development speed)

$$$ -You get more stuff sooner. Not only do you get your agreed upon set of features faster, but also you can expect to get incremental improvements and non-trivial enhancements sooner than using other platforms.

$$$ -You get to see stuff sooner. The underlying technology allows development teams to show business stakeholders features and changes in a much more expedient fashion (literally while looking over the developer’s shoulder). This makes the requirement clarification and refinement process much more real-time and iterative (read: Agile Manifesto-friendly).

$$ -You get goodies that come along for the ride. Rails is chock full of helpful technology that allows you, the business stakeholder, to present web applications that have really rich user interfaces. You’re able to present these rich interfaces to your user community without having to ask your team to undertake science projects (read: expensive) to get the equivalent functionality on other frameworks.

$$$ -It plays nicely with others. REST (pun intended) assured, with Rails as your platform choice, you’re able to integrate with other technologies. Rails is not only open source, but it strives valiantly to facilitate integration with data and other applications. These features of the framework come out-of-the box and are native to the thinking behind the development of Rails.

$$$ -Its Open. Like JBoss (J2EE Container) Rails is an open source project which means you don’t have to pay a nickel to use it. It also runs on things you can get free; like Linux.

$$$ -There is a fever. Similar to the manner in which Java ascended as a choice of web and enterprise development, Rails has zealots. The community that has sprung up around Rails is breathtaking. While this is an unscientific statement, it does seem that we are seeing the type of fervor, support, and evangelism that benefited Linus Torvalds’ Linux; and we all know, how that turned out.

Next up – The case against Rails …

Technorati Tags: software economics, Ruby on Rails, RoR, Rails productivity, software development costs, time to market,

Obligatory Caveat: While we’ve not built the same application in a variety of langugages to assess the potential savings, we have normalized by analyzing applications of similar complexity with comparable team competencies (using Planix as our steward).

To cut to the chase, in general the economics and adaptability of a Rails-based application versus other applications look something like this –

A medium complexity application with approximately 20 medium-to-high complexity features (use cases or user stories)*

* We are speaking of applications where a ‘pure’ Rails approach is applicable; where other non-Ruby on Rails technologies are not required ro realize the solution.

Pretty impressive, eh? We believe so as well, but — again — just because you can develop faster, does not mean you should. In my next post, we’ll discuss more of the pros and cons of using RoR as your platform of choice.

Technorati Tags: software economics, Ruby on Rails, RoR, Rails productivity, software development costs, time to market,

The Trails project is a rough analog to this approach (although the author seems to regret somewhat the ‘Trails’ moniker as it people naturally jump to the conclusion that it is a java version of Rails; which it is not.) This post describes my recent experimentation with the Trails framework, and my subsequent opinions on when/where/etc it might be appropriate.

Let me first start out with a disclaimer of sorts, around RoR. I have very little practical experience to date with Rails, let alone Ruby; and as such, I am not attempting to compare Trails to Rails. Also, this is not a tutorial on Trails…Several links off the Trails project homepage provide an excellent and easy to follow tutorials which will guide you thru the basics.

Trails in a Nutshell

Trails can be neatly summed up with a (slightly modified) quote directly from the project home page:

The trails project aims to make [web based] java enterprise application development radically simpler by allowing developers to focus on the domain model and having other portions dynamically generated.

Basically, you, the developer, provide:

• A POJO domain model (i.e., Plain Old Java Object representations of the data to be persisted to a database)
• Annotations within the Domain Objects that indicate which fields are to be persisted and their relationships with other Domain Objects.

The Trails framework in turn automagically provides just about everything else. Including :

• Project directory structure and build environment (Using Ant)
• Simple Web based CRUD (Create-Read-Update-Delete) screens; one-per Domain Object (Using Tapestry)
• Object relational mappings to a persistence store and the underlying Data Access Objects (DAOs) (Using Hibernate)
• A basic workflow lifecycle and wiring between the View and the Model (Using Spring)
• A packaged Web Application (.war) file ready for deployment into a standard Servlet container

So lets say you had an application that dealt with an inventory of Automobiles. You would first set up a trails project (using a provided ant task), and then define a basic POJO Domain Object:

@Entity
public class Car
{
private Integer id;
private String make;
private String year;
private String model;

@Id @GeneratedValue(strategy=GenerationType.AUTO)
public Integer getId(){ return id; }

public void setId(Integer id) { this.id = id;}
public String getMake(){ return make;}
public void setMake(String make){ this.make = make;}
public String getModel(){ return model;}
public void setModel(String model){this.model = model;}
public String getYear(){ return year;}
public void setYear(String year){this.year = year;}
}

The only interesting thing in this class are the handful of annotations that indicate that we want this object to be persisted (@Entity) and we want an unique Object Id auto assigned. Basically we are using the JPA to indicate to Trails (and in this case Hibernate) what gets mapped to our database.

That’s all the code we write.

When compiled into a war and deployed into a servlet container (using the ant build script that Trails provides for you), we get this when we point a browser at http://localhost:8080/blog

Clicking around allows us to enter some new car data:

… which we can then list out here:

WOW. Pretty nifty. And not bad for about 5 minutes work. Less even.

OK. This is obviously a very simple/dumb application. Its straightforward and (generally) easy to add additional Domain relationships (OneToMany, ManyToMany,etc), automatic data validation, and UI customization with a bit more work (all of which is detailed in the links available from the Trails project home page)

The Pros & Practical Applications

• You can quite literally have a complete working and very usable application running in minutes.
• Its a terrific way of providing the tedious, yet mandatory, backend admin interfaces to your existing application.
• There are lots of cool built in graphical widgets that come along for the ride, like calendars, list selectors, etc. that are generated as a result of your Domain Objects underlying data types and relationships.

The Cons

• Trails makes numerous fundamental assumptions for you– this is both its core strength and weakness. If these assumptions don’t fit within your applications overall paradigm you are going to have to do a fair amount of research/work to retool.
• Establishing relationships between Domain Objects requires JPA knowledge; and as soon as you start getting into anything remote complicated you will likely get stuck for a bit. This is not a Trails flaw per se, but its a bit of a wall nonetheless.
• Trails uses Tapestry for its view. I don’t really know squat about Tapestry, so from my standpoint that’s a con.
• Its not clear (to me anyway) how to provide ‘controller’ type logic or how one would integrate the Trails constructs cleanly with existing structures. Once again, this may be due to my general ignorance of Tapestry.
• Don’t be fooled into thinking that the resulting app is close to lightweight. It requires a servlet engine, and the generated war itself is over 20mb(!)

The Conclusion

Trails is cool. Very cool. And for certain types of applications it gets 2 thumbs up. Don’t let the listed cons keep you from exploring its value to you. That being said, it seems most valuable for quickly generating Administrative interfaces to existing applications, where the look and feel can be CRUDe (crude, get it?). Working the basic CRUD paradigm into an application with significant business logic seems daunting; and probably more work then solving the problem in a more ‘conventional’ J2EE approach.

Technorati Tags: trails, domain driven development, java, RoR

To that end, ALTERthought has selflessly suspended its efforts to build the world’s largest free-standing Mackerel shrine built completely out of Mac-Minis and has donated one fresh from the factory as a RailsDay 2006 prize. (no, really – check out the logo bar on the RailsDay page – ’bout halfway down … no, not there … yeah there! … oh yeah, that’s our logo right there)

If ever there was a reason to blow a Friday and Saturday night coding – I’d say a free Mac-mini qualifies? Hurry up and sign up before it’s too late.

Do it for the mackerel.

RailsDay announcement
Our announcement

Technorati Tags: railsday, railsday2006, rails, rubyonrails, alterthought