Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Takeaways from the second quarter in cloud and data
• Cloud computing infrastructure: 2012 and beyond
• Amazon’s DynamoDB: rattling the cloud market

That’s why it’s fun to come across a startup like Firefly, the creation of four University of Pennsylvania undergraduates who want to make it drop-dead easy for companies to guide customers through their websites by co-browsing or sharing screens without plugins or downloads.

So if you’re perusing your a healthcare provider’s web site and get stuck on a form, the customer service agent can with a button click,  get in and share that screen — without seeing any of the user’s other tabs or screens — to walk the user through the process. To facilitate this, the company just adds a few lines of JavaScript code to the URL header.

The product has gotten some ink  and it is cool. But what impressed me was the co-founders. I met two of the three – Wharton undergrads Patrick Leahy and Justin Meltzer  – at Boston AngelHack last spring, when Leahy was in in the midst of a hackathon road trip.

Just coming off the 48-hour Penn Apps hackathon, Leahy Bolt-bused up to Cambridge for the 30-hour Boston AngelHack, before jumping aboard StartupBus, a 70-hour hackathon-on-wheels to South By Southwest, where he was going to participate in — wait for it — another hackathon. Code means a lot to this guy…

Firefly co-founder Patrick Leahy

Foresaking Wall Street for code

So much, in fact, that Leahy turned down an investment banking internship with a New York financial services giant to focus on programming. “I did one internship on derivatives trading last year and liked it and was going to go back for investment banking, but I want to build the company,” Leahy told me by phone last week.

Leahy and another Firefly co-founder Dan Shipper are startup veterans, having already launched Airtime for Email, which gives companies a way to brand their marketing messages in email and track how those emails are treated. Were they read? Nuked? Forwarded? Never opened?

Leahy speaks about code as someone who is knowledgeable but still eager to learn. “We wrote the first version of Firefly at Penn Apps using Ruby on Rails but we couldn’t get to the level of complexity we needed so we rewrote it at AngelHack in Node.js. We learned that language at AngelHack and it’s perfect for what we needed,” Leahy said.

Picking the right tools

“Programming languages are like different sized kitchen knives — they suit different jobs,” he said. Ruby on Rails is a great framework for building “CRUD”  or Create, Read, Update, Delete — applications, he said. ”If you have a big table you want to edit — a customer information page, your sales rep page, Ruby on Rails if fine,” he said.

But for Firefly, which needs to handle fast browser-to-browser communication, Node.js was better. “We have to pass messages back and forth so our server sits in the middle and we wrote code to connect all those browsers. This is an evented pattern where you’re having a conversation, listening for things to be said and holding till you hear them. Ruby on Rails is not good for that but a functional programming language like JavaScript makes it easy to call a function to handle an event,” he added.

The Firefly foursome used to work out of dorms and apartments but is moving into the offices of First Round Capital, although there are no plans to take venture funding yet.

To be sure, Firefly isn’t entering an empty stage. LogMeIn offers a popular screen charing application and Salesforce.com bought GoInstant a screen-sharing company in July for $70 million. But Salesforce is attacking big companies with a full array of analytics and other perks while Firefly focuses on customer service and might be more attractive to smaller companies. Whatever the competitive landscape,  I wouldn’t sell this team short. They show a remarkable maturity that complements their youthful exuberance. Asked if Firefly was seeking venture capital, Leahy was cautious.

“We want to get to free cash flow and get stable before thinking about raising money from outside. We want to make sure we can manage our own money first,” Leahy said.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• There is more to Node.js than buzz
• Cloud and data third-quarter 2012
• A near-term outlook for big data

Goyaka Co-Founder Rajagopal Natarajan said the startup was motivated because he and his two co-founders wanted to move their own Flickr photos over to Facebook so they could be more easily shared and commented on.

To use the free service, you sign on to Flickr, sign on to Facebook and push a button. The service automatically moves your photos onto your Facebook page  – and your timeline — but the photos are initially marked private so you can check them out before sharing them with friends and family. That’s, after all, why most people want their photos on Facebook, said Natarajan.

Other services like Photosync don’t put photos in the Facebook timeline. Selecting photos to sync and selecting the privacy level is “not intuitive” with those products. “They sync all sets by default and post them to the default list of friends,” Natarajan said.  Other tools also don’t let the user track progress of the synchronization while it’s happening, he said.

“The timeline piece is important. I have so many photos from 2005, and without timeline [integration], they’d all show up [categorized] for the same time,” Natarajan said.

Goyaka’s Ruby on Rails-based service is hosted on Amazon Web Services and uses Flickr and Facebook APIs to do its thing.

A Picasa version is in the works, but Flickr, which has been the preeminent photo-sharing site, was the low-hanging fruit.  The site targets Facebook because “Zuckerberg owns me already. Facebook photos are more social. Tagging just nails it,” according to the website.

Goyaka launched a test service over the weekend and as of Thursday, had already uploaded some 270,000 photos and was adding more AWS instances to handle the queue, Natarajan said.

“We want our friends to see our photos. So many people started commenting and many old photos are bubbling up [on Facebook] now,” Natarajan said.

I tried Goyaka just now with a limited number of Flickr photos. The process was simple, but the queue must be long because they haven’t populated Facebook yet. Still, they’ve sat in Flickr for months; what’s a few more minutes? Stay tuned for an update.

UPDATE: My photos are still not up. In response to an email, Natarajan apologized for the backlog delay, attributing it to a component failure.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• 12 tech leaders’ resolutions for 2012
• In Q4, Data Centers, Not the Cloud, Were the Big Story
• The evolution of consumer-media cloud storage

Martin Odersky

To hear Typesafe tell it, the Scala programming language is about to join the ranks of top-tier development tools such as Java, C++, Ruby, and PHP. A new Scala plugin for the Eclipse integrated development environment (IDE) should help pave the way.

The Scala software stack attacks two sticky problems for software developers. The Scala language aims to make it easier to write code for multiple cores, and the Akka middleware attempts to ease the creation of applications that run across multiple servers.

A third piece, a Ruby-on-Rails-style framework called Play, makes development more productive and fun than is usually the case in Java, said Donald Fischer, CEO of Typesafe, the startup charged with promoting and supporting the stack.

The ability to better automate programming for multi-core chips and distributed servers is a key criterion for developing cloud applications that scale up big time.

Recapping Scala history

Scala was initially developed by Martin Odersky, who wrote the original Java compiler for Sun Microsystems. ”He did [the compiler] in 2000 as part of making Java better. Then he handed it off to Sun and turned to making a better Java. That’s the genesis of Scala,” Fischer said.

Scala is used by some pretty big names in web infrastructure: Twitter, LinkedIn, and Yammer for key parts of their infrastructure. There was a ruckus last month when an email between a Yammer employee and Typesafe leaked that seemed to indicate that the company was pulling back from Scala use. Yammer clarified the matter in a subsequent blog post.

Typesafe, Menlo Park, CA., was founded earlier this year with $3 million funding from Greylock Partners.

Getting beyond those awkward years

One thing still lacking for Scala, an eight-year-old programming language that runs on the Java Virtual Machine (JVM), is that some of its ancillary tools remain a “little raw,”  Fischer acknowledged.

“The support for Eclipse wasn’t all cooked. With 2.0, working with the Scala community, we’ve smoothed out the rough edges,”  Fischer said. Eclipse is the IDE of choice for the vast majority of Java developers, so smooth integration with it is key for any tool targeting that constituency.

The Scala IDE for Eclipse 2.0 adds automatic type-checking to ping programmers of errors before they build the code. There is also better dependency tracking between source files.

There is anecdotal evidence to back up Fischer’s contention that Scala is outgrowing its awkward years: the community and number of projects is growing, as evidenced by stats on Github and other sources.

“We think there’s one Scala job for every 100 Java jobs advertised,” said Fischer. “That sounds small, but 1 percent of 10 million is pretty good.”  (The 10 million number is Oracle’s estimate of the Java programmer population.) This is impressive because Scala has only been around since 2003. Fischer said the number of Scala jobs has tripled in the past year.

A quick check of Indeed.com finds that there are 404 listings when “Scala developer” is the search term compared to 44,769 for “Java developer” and 5,841 for Ruby developer.

As the demand for scalable and capable cloud applications continues to grow, it’s likely that the demand for capable — and polished — development tools will mushroom as well.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Open-Source Startups Follow Red Hat’s Path To Profit
• Cloud and data third-quarter 2012
• Continuous delivery and the world of devops

This is just the latest indication that Node.js, a server-based and event-driven JavaScript framework, is becoming table stakes in cloud development and deployment environments. Engine Yard competitors like AppFog and Heroku, now part of Salesforce.com, already support the framework.

Developers like using Node.js because it supports JavaScript — a very popular language for client-side development — and because it is fast and scalable.

Specifically, Engine Yard said that the first release of Engine Yard Labs — a program to give developers early access to new features — will  include support for Node.js. That access will be enabled on Friday, the company said.

There is a caveat however. According to a blog post announcing the news:

Features released through Engine Yard Labs are not officially supported and may or may not become supported as part of Engine Yard products in the future.

San Francisco-based Engine Yard started out focused on Ruby on Rails but added PHP support through its acquisition of Orchestra in August. Virtually every PaaS player from AppFog to Microsoft Azure   is in an arms race to support as many languages as possible.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Cloud computing infrastructure: 2012 and beyond
• Amazon’s DynamoDB: rattling the cloud market
• Quality of the cloud: best practices for ISVs

A level up from Infrastructure-as-a-Service on the oft-cited cloud computing stack, PaaS offerings have become very popular among individual developers within their particular languages. That’s because PaaS lets developers write applications without regard for infrastructure-level concerns such as server count or operating system. However, PaaS has attracted its fair share of critics because, historically at least, offerings have often focused around one language, which left developers using multiple services when they wanted to write applications in multiple languages.

This has begun to change in the past year, however, with myriad multi-language PaaS offerings hitting the market, and with legacy providers (if we can say that in a field only a few years old) continuing to add support for additional languages. Even notoriously single-language platforms such as Heroku (Ruby) and Google App Engine (Python) now support multiple languages and/or frameworks.

For its part, Engine Yard CEO John Dillon told me, the company has been considering such a move at least since he joined three years ago. In fact, he said, the first question he asked when he joined the company was “Just Ruby, or more?” By his thinking, the company couldn’t fully leverage what it has learned over the past five years by sticking with Ruby on Rails alone; it was unnecessarily limiting itself to a discrete customer base.

Furthermore, Dillon noted, sticking with Ruby on Rails only meant that other PaaS providers “would eventually learn what we spent the last five years learning [about running a PaaS business and] mount a competitive threat.” So, when the company began reworking its core code about 18 months ago, he said, it made sure the code could support multiple cloud providers and programming languages.

However, Dillon is sure to make clear, Engine Yard did not rush into its decision to buy Orchestra and support PHP. It has built such a solid business, he explained, because the company knows Ruby inside and out and can answer pretty much any question a customer might have. When Engine Yard entered into talks with Orchestra last year, Dillon knew he had found a PHP PaaS provider that shared in Engine Yard’s vision of providing deep programming knowledge within its field.

Dillon said that Engine Yard isn’t going to stop with Ruby and PHP, though. Already, he noted, the Engine Yard supports JRuby in a beta-like manner, and, he said “you’re going to see us support Node.js in the not too distant future.” The plan is to add languages one-by-one when the timing is right, he said.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Cloud computing infrastructure: 2012 and beyond
• Infrastructure Q3: OpenStack and flash step into the spotlight
• Cloud computing 2013: how to navigate without a map

San Francisco-based Stackmob offers mobile developers a back-end cloud platform that allows them to easily build, deploy and manage their applications without having to fuss with many of the infrastructure issues that can plague startups. That means developers can spend less time building out the basic services that most mobile apps have anyway and focus on a differentiated experience. Especially with many startups scrambling to add talent, StackMob allows them to avoid having to hire as big a team.

“We see ourselves as the experienced back end for the masses. Everyone forgets how early we are in mobile. There will be great ideas out there but people don’t know how to implement the back end,” said CEO and co-founder Ty Amell.

StackMob offers things like simple API creation and management, social integration, messaging and analytics. Monetization tools are coming shortly. Startups tie into StackMob’s platform and they don’t have to build those services themselves. They still need to hold on to some back-end programmers, but they don’t need the same number of employees working on infrastructure.

So far, StackMob has been in private beta with about 200 iOS apps on the platform. Amell said the company, which has a wait list of thousands, is preparing to open up later this year when it starts supporting Android. While StackMob builds out most of its services, it will likely need to partner for some things like location. Amell said the company is looking to integrate data from Simple Geo or Location Labs for that.

StackMob has been compared to Heroku, a Ruby on Rails cloud platform that has caught on with web developers. It’s not coincidental. Some of StackMob’s original seed investors — Harrison Metal and Baseline Ventures — were also funders of Heroku, which has been bought by Salesforce. Harrison Metal founder Michael Dearing will be joined on the StackMob board by Dan Scholnick, general partner at Trinity Ventures.

StackMob could be a major success if it follows in the footsteps of Heroku. There’s a lot of opportunity in helping power apps, and there are very few tools like this for mobile developers in particular. By empowering developers, StackMob can help apps go from ideas to real software much faster and can give rise to a lot more start-ups that don’t have enough technical talent but have some interesting takes for their apps. Amell is right, it’s still early in mobile and platforms like StackMob could ensure that the app boom continues to explode well into the future.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Examining the rise of crowd labor platforms in 2012
• How to stand out in the app development game
• Infrastructure Q1: Cloud and big data woo enterprises

With this latest investment, Engine Yard will scale the Engine Yard Cloud to meet enterprise requirements, build support offerings for JRuby development teams, and continue to invest in open-source projects. “Engine Yard has made a number of important moves over the last 12 months to become a dominant platform for cloud computing,” Peter Fenton, general partner at Benchmark Capital, said in a press release.

Fenton sees Engine Yard as the key catalyst that would help scale Ruby on Rails and move into the enterprise. He sees similarities between Java in the late 1990s and RoR today. In the ’90s, many argued Java wouldn’t scale, and the same arguments are made today about Ruby on Rails.

When we first wrote about the company back in early 2007, it was focused almost entirely on small web startups. Many startups are shying away from the company because they feel that Engine Yard is more than what they can afford. Perhaps this diversification into large enterprises is a better move for the nearly 3-year-old company, which recently lost a marquee client, GitHub, to Rackspace. Big corporations can cut larger checks than a startup as well.

In a conversation, Fenton argued that developers don’t really write to operating systems anymore and instead focus on developing for frameworks. Just like BEA Systems (acquired by Oracle) rode the web wave in the web 1.0, Engine Yard wants to be the outsourced application server platform for Ruby.

“Developers wrote to App Servers in the late 1990s and early part of this decade,” he said, pointing out that Engine Yard can do the same for developers now, and have them write to this middle layer without thinking about the complexity. Engine Yard will have to work hard to realize this big idea — it needs to graft a lot of DNA into its existing team in order to scale to the level of BEA.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• GigaOM Research highs and lows from CES 2013
• How HR can make the case for workforce analytics
• The 2013 task management tools market

With more and more web applications being built by Mac-addicted developers, I thought I’d have a chat with Stephen Caudill over at FatJam. Stephen not only codes his creations on Apple hardware but also relies on it to serve up the applications to the public.

Travis Vocino for The Apple Blog: Hey there Stephen! To me, it feels like the Mac, and specifically the MacBook Pro, is the web developer’s absolute choice when it comes to deploying an environment suited to the work. It definitely hasn’t always been that way though, as you know. What about you? What’s your history with developing for the web on Apple hardware?

Stephen Caudill for FatJam: In August of 2004, I started looking at the programming language Ruby, in response to the philosophy of “developer joy” that Ruby on Rails’ creator, David Heinemeier Hansson was extolling. At the time I was working in Big Java and really just hated it… the job, the tools, the verbosity of the language were all a millstone around my neck and I wanted this golden path that David was describing.

In and amongst the various doctrines of Ruby on Rails was this devout love of the Mac computer that I kept being inundated with. Around the same time Paul Graham penned an essay in which he observed that all the smart hackers he knew were migrating to OSX… That was apparently all the coercion I needed, as I soon found myself exploring a first gen Mac Mini. In retrospect, I guess I was drinking the Koolaid, but it was good Koolaid after the sour taste Windows left in my mouth.

TV: Absolutely. In fact, these days sometimes it’s hard to find a Windows laptop at a developer’s conference — especially the more current spaces like Ruby. So, you’re really hot for Ruby these days?

SC: Definitely. It’s been revolutionary to my entire thought process, let alone my habits as a programmer. A forthcoming project I’m working on, FatJam, is a significantly large Ruby on Rails application.

TV: Can you tell me a little about FatJam?

SC: FatJam is a service that helps musicians meet and collaborate over the internet. We’ve been explained as “Match.com for musicians” and that’s pretty accurate, but only one facet of the application. To elaborate on that bit though; we use data that the user supplies about themselves, objective analysis of their usage habits on the site and automated analysis of finished music they upload to suggest other artists in the community that they’re likely to be compatible with. From there we make it very easy to form bands (the conceptual hub of our interpersonal collaboration), collaborate over distance and promote and distribute your music. We’ve just entered our limited public beta and are due to launch the full service in September.

TV: Another key point I think web developers love about Mac is the shared love for open-source software. How has using OSS technology like the Ruby on Rails framework helped you and your team build a large-scale project like FatJam?

SC: We’ve gotten a lot of benefit from Open Source technologies like Ruby, Ruby on Rails and a plethora of client libraries. Honestly, it would have taken us much longer to develop FatJam if we weren’t standing on the shoulders of these Open Source communities. As a company, we are firm believers in Open Source and we’re making a concerted effort to give something back. We’re starting out by releasing an internal library we use for versioning database records: Acts As Revisable. We’re going to continue to release other extractions from our endeavors as OSS software on github, so keep your eyes on our account.

TV: OK, let’s talk Apple nerdery. What’s your (and perhaps your developers’) setups like as far as software and hardware? How do you utilize them in your day-to-day workflow?

SC: We’re all running MacBook Pro’s as our development machines. Rich Cavanaugh (our senior architect) and I both use TextMate and Terminal.app for our primary development. Our other developer, Rogelio Samour is a recent Mac convert though and a big linux guy, so his primary development is done in Vim and iTerm.

On my rig, apps that run all day every day for me are: Textmate, Terminal, Things (LOVE this app), several Fluid.app instances (for CampFire, GitHub and LightHouse) and Twitteriffic, in addition to the usual suspects… iTunes, iChat, Mail (with all its warts) and Safari. Notable occasional use apps are Changes.app, Pixelmator (screw you Adobe), NetNewsWire, Skitch, Interarchy and of course FireFox (still the best game in town for debugging JavaScript).

As far as workflow goes, we work in a distributed fashion (I’m in North Florida, Rich is in South Florida and Rogelio is in Northwest Arkansas), so Leopard’s screen sharing capabilities have become vital for us. Using Screen Sharing, we can do pair programming and collaborative debug sessions. It’s almost as good as being in the same room. I also coordinate on a daily basis with my partners in Miami and Greece and consultants in California and less frequently with our board members, most of whom are in New York and London… keeping up with these guys makes my iPhone pretty crucial. Now, admittedly, I could be doing the same stuff on a CrackBerry, but I’d be doing it in much less style and without the super-convenient integration features that the iPhone has with my Mac life.

TV: You definitely deliver on Apple nerdery. I love getting to know how people work, what they’re using and how they use it. It speaks a lot to the real-world usefulness of an application when you can experience what someone has built using it. What about the other side — the infrastructure that actually runs and serves up FatJam?

SC: We’re running brand new 8 core Leopard servers with 16GB of RAM apiece. Our staging environment is on a single PPC Xserve running Leopard.

TV: How does using Apple hardware for server infrastructure compare to what most people are used to — generally greybox servers or Dell PowerEdge type stuff? Is the workflow different? Is the deployment easier, more difficult?

SC: Coming from a Java/Sun server background, it honestly feels pretty familiar, albeit minus some warts (and some configurability). I would guess that people who are used to running virtualized Dell PowerEdge’s would have a bit of an adjustment to make. Speaking of which, that’s one thing Apple’s server platform is screaming for: virtualization. It’ll be interesting to see how Parallels Server performs when they’re out of beta… we’ll certainly be looking closely at it.

Deploying to Apple hardware has some specific challenges, but I don’t think they’re any more difficult to deal with than a large scale deployment on any other platform. One thing I’ll give some kudos to the Leopard Server devs for is the great support that Rails enjoys in it’s server environment… mongrel_rails_persist is a super simple utility with a familiar (to a Rails dev) interface that gracefully hooks into and leverages two of my favorite Apple technologies: Launchd and Bonjour. Starting up a Rails app via mongrel_rails_persist automatically creates a launchctl instance for the app and advertises it’s presence over Bonjour, which is in turn integrated into the Apache Web Server interface in Server Admin. It’s all very slick. Beyond the simple elegance of tools like mongrel_rails_persist, it’s just a sound and performant all-around platform for running Ruby based applications from.

Workflow is really why we’re on Mac on the server though, the rest of it is icing. Specifically, we have the ability to access Apple-specific technologies for server side processes. I’m sure you can imagine the benefits that we reap from having a platform exposes sophisticated audio processing systems like QTKit and CoreAudioKit to our server side application.

TV: Plus, just looking at a rack of Xserves should make anyone giddy. In addition to server technology, I dig checking out these fabulous audio production setups that incorporate both Xserves and usually Mac Pros. Being involved with that space, do you think Macs lead the market in audio production? What tools do you or FatJam users utilize on the product end before the work gets to the site?

SC: My personal experience has been that Macs have dominated professional audio production for some time now. More generally though, it seems that many savvy users these days are gravitating toward macs because of their current level of sophistication, and this is true of much of the new breed of digital musicians I know as well. Don’t get me wrong though, I still know a ton of really talented musicians that happen to use Windows.

The jury is still out as to what tools are going to be prevalent amongst our users. We encourage people to use what they know and we’ll be actively looking at what they do use, so expect more concrete observations on that later. My gut feeling is that we’re going to attract an audience that’s disproportionately Mac-based — say 35% of our overall user base. Platform will affect tool choice to some extent, but I think we’ll see representations of all the usual suspects: Pro Tools, Logic, Acid, Fruity Loops, Reason, Digital Performer, Ableton Live, etc, etc.

My setup is currently oriented around using Reason for beat production and Pro Tools for recording analog sources (though I’m actively trying to move away from Pro Tools). I’ve been starting to tinker with Ableton Live and I love it so far… it’s a really fun, creativity-oriented interface for doing the discovery phase of production in. I’m also looking forward to devoting some time to learning Max/MSP post-beta, which is in a personal sweet spot for me at the intersection of programming and music.

TV: You mentioned that you expect Windows users, of course, but do you consider Apple-specific user apps (like iPhone apps, Dashboard widgets, straight for the desktop) to be crucial to the success of emerging sites like FatJam. I happen to think they’re quickly becoming an integral part. I actually attribute a lot of the success of Twitter to be tied to the early availability of Twitterific. What do you have currently in the works, already deployed or on the to-do list?

SC: With so much of what we consider important available over ever-present networks, it’s silly not to expose that data for consumption, in my opinion. Ubiquity of data is a goal all developers should be working toward these days, or else they’re going to miss the boat. Keeping that in mind, Apple provides some really sweet, fun-to-build-for platforms for getting at and exposing data to users, so it’s a no-brainer for us to get on board with it.

We’re currently putting the finishing touches on native Mac and Windows client apps that pair with the web service suite. We’ve got a couple of widgets in the works for Dashboard as well as Vista and Google Gadgets. As an iPhone user, I tend to think that any application that doesn’t have an iPhone interface is incomplete… so that’s definitely in the works too.

TV: Excellent stuff, Stephen. Endless thanks for sharing your Mac-addiction with me and our readers. We’ll be on the lookout for much more Apple-enabled goodness to come from you in the near future, including the launch of FatJam and your open-source contributions. Good luck!

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Cloud and data third-quarter 2012
• How do developers ride the Siri wave?
• There is more to Node.js than buzz