Joyent

Joyent Weblog

Open Sourced Connector: A $5 million gift?

By Jason Hoffman 9 August 07 Comment [15]

Linda D. recently pointed out to me that the connector is currently in Ohloh as a project.

There’s some stats that are interesting:

  • 7 contributors,
  • 214,377 LOC (with a significant portion in the “view logic”),
  • 55 man years
  • An estimate to write this project from scratch of $5,545,809

What it doesn’t show is that the project went through over 10,000 commits over the last three years.

Of course, I’ve also warned against such measures.

Upcoming Slingshot Roadmap

By scott 2 August 07 Comment [3]

If you hadn’t heard, I’ll be presenting Slingshot at Railsconf Europe in Berlin this September. For the presentation I would like to have product to show and answers to all the questions posed at the last presentation at Railsconf US – so I’m stepping up Slingshot development between now and mid-September.

I want to periodically lay out roadmaps on the list and the Joyent Open Source wiki so that you can keep tabs on what is happening and when it’s expected to happen, as well as provide feedback and testing throughout the process.

I’ve been putting some thought and dry erase marker into Slingshot architecture the last couple weeks and I wrote the first bit of code today. So here I’m going to lay out the first phase, in addition to what we can expect to have produced at the end of the phase. For the time being, the current svn repository will remain AS IS, and all of my work will be occurring in the new directory. Once things have become more solid, and we have a workable base that is at least as complete as what we have now, I will do some repository housekeeping.

On with the description of phase one. I’ll start out with some definitions so we’re all on the same page:

  • Primary application: The Web application running on your production servers – the one normally seen through a Web browser (e.g. Joyent Connector)
  • Local application: A locally running version of the primary application – runs on the computer using the Slingshotted app
  • GUI: The graphical part of Slingshot an end user directly interacts with
  • Proxy: A small proxy server that sits between the GUI and the primary and local applications (described in detail below)
  • Connectivity: Describes the ability of the proxy to connect to the primary application (i.e. are we “online” or “offline”)

This first phase deals with the development of the proxy component. This component is fairly simple, and is very close to user interaction so it seems like a good place to start. I’ll break its development down into three steps.

Step 1. Create the proxy and make it aware of connectivity. The proxy will know when it is online and offline, the user will not need to manually set this. Provide an API for the GUI to get the connectivity status. This step is about 95% complete at this writing.

Step 2. Give the proxy the ability to start and stop the local application. Many people have voiced concern over the heavy memory footprint of a Rails application. It is true that some applications can grow pretty heavy. This is generally not a problem on production servers, so we don’t give it much thought, however, on the desktop the memory usage of an application becomes much more important, even if it’s only 50MB. So, when Slingshot is in online mode, we’re going to shut down the local application. When Slingshot detects it’s offline, we’ll start the application up. In short, there’s no reason for the local application to run unless we’re directly interacting with it.

Step 3. Give the proxy the ability to fire synchronization events. There are a handful of points where up and down synchs should be fired off. Most of these will be automatic, but the user may want to trigger a sync as well. So at this point we’ll build a mock synchronizer that the proxy can fire events on as if it were really syncing.

After this phase we’ll have a system that can interact with the primary application when online and interact with the local application when offline. This will be seamless to the end user, only the two data stores will be separate. That’s the next phase.

While we’re adding the feature of automatic connection detection, it may seem like we’re taking a step back from what’s currently available in Slingshot. In a way we are, but it’s a necessary step back so that we can take larger steps forward sooner. We’re not discarding the current Slingshot, but we are making some overall architectural changes, and sometimes it’s better to start a new frame from scratch and then integrate existing pieces than to try to mold the existing thing as a whole.

Once this phase is complete, I will move into the data synchronization portion – the main guts – the “hard” stuff. I’ve got a number of cool things sketched out for this, which I’ll detail in my next installment. Also expect a similar post regarding the GUI itself – I have plans to make the GUIs lean and easy to create (so this means PPC and Linux support, etc.).

Until then, please follow development using the Open Source wiki feeds, try things out, give feedback, voice concerns, ask questions, and all that good stuff.

Project Indiana (OpenSolaris) Session at OSCON 2007

By Kristie Wells 25 July 07 Comment

If you want to know what is going on with OpenSolaris and you happen to be in Portland at the OSCON conference, get yourself to the Project Indiana session taking place on Thursday, July 26th at 2pm in Room D132. On hand will be Sun’s OpenSolaris gurus and our own Ben Rockwood, so this is a session you won’t want to miss.

Hosted by Sun and yours truly

And don’t forget about the big party tonight in the Exhibit Hall at the Doubletree hotel. Games, DJ, free booze, you name it. Be there or be square.

Ruby / Rails community building in action

By Mark Mayo 18 July 07 Comment [2]

One of the nice things about living in a city like Vancouver is that there’s enough geek population to support user groups, even for rather “niche” languages like Ruby or Python.

I’ve always been interested in community development (opensource and otherwise) and in particular what happens when communities are “tested”. That’s happening right now in Vancouver where there are two Ruby / Rails “user groups”. One was started by Nathaniel Brown (“VanRuby”), the other by Zed Shaw and Jeremy Hubert (“Vancouver Ruby Brigade”). Gerald Bauer has called Nathaniel out with an open letter that gets right down to business:

Your ‘community’ sites seem only setup not to help and serve the local community but – if I dare to say – to promote your Rails workshops and conferences and drum up some business for yourself. — Gerald Bauer

Oh my! That’s going to get a response, huh? And it did. The resulting discussion is playing out on the mailing list , and it’s pretty fascinating. People got angry, accusations got tossed about, and things were looking pretty bleak. But then Miles called for a CTRL-C, and Peter stepped up with a nice little message and an offer to take the lead on a fresh start:

But if there’s too much politics associated with everything that has happened so far, this can be viewed as a new, neutral beginning. I’m not trying to exclude anyone. I just want to meet fellow Ruby/Rails programmers, drink beer, talk geeky things that my wife doesn’t appreciate and see the occasional interesting presentation … I am volunteering to do the boring organizational crap (starting with paying for the Meetup group and bringing a projector) that needs to happen in my opinion. This kind of stuff is no fun, but someone has to do it. I have already profited a ton from Ruby & Rails, so this is my way of giving back. — Peter Armstrong

Building communities around opensource projects is no easy task. There’s a lot of varying personalities and ideologies at play, and as such there are high points and low points. Things can be pretty unpredictable. For me the true litmus test of any community is how it rebounds from lows. If today is any indication my local Ruby community has certainly got its share of “interesting” personalities that can shake things up, but that’s ok because we also have the counter-balancing personalities that come up with creative alternatives, like the Vancouver Ruby/Rails Meetup Group!

Anyhow, the whole exchange hit close to home since Joyent is built on, and we in turn build, opensource software. Building communities around our projects, and getting even more involved in other opensource projects we believe in is something that’s priority #1 for us. It got me thinking about what really makes open source communities succeed. There’s a lot that’s been said about this, of course, but really it boils down to one thing: It’s got to be fun. Really. That’s it. Once I realized that, my anxiety about projects we’re involved in vanished. Why? Because if there’s one thing Joyeurs know how to do well, it’s have fun! :)

Joyent Connector: Free + Open

By Luke Crawford 17 July 07 Comment

Last Friday, Joyent made Connector free + open. Free in that anyone can sign up for a complimentary 2 User/ 2 GB plan and Open in that anyone can view the source, download it via svn, and contribute.

Continue reading to learn a little more about what Free + Open Connector means for users, developers, + for the web as a whole.

Using the Connector Suite

From a user’s perspective, Connector is an amazing way for your team to collaborate. The suite of web applications allows your team to manage + share all of their information in an open, consistent way.

The Connector suite currently includes the following applications:

  • Connect: A customizable dashboard for all of your Connector data.
  • Mail: Simple + powerful web-based email with 2 great (and unique!) features: tags + IMAP access!
  • Calendar: Manage your meetings, appointments, and events on multiple calendars. Notify your co-workers of events to invite them to a meeting.
  • People: Manage all of your contacts + easily import + export your address book. Tag people to create smart groups that you define.
  • Files: Share files with each other easily + securely via the web or SFTP.
  • Bookmarks: Just like a social bookmarking site, but for your team!
  • Lists: An outline creator + editor on the web. Make a todo list, manage a project, or even do simple math operations.

Connector apps all share a common, very refined look + feel. The UI is consistently people’s favorite part of the app. Also, all Connector applications have tags, RSS feeds, comments, smart groups, adjustable permissions, notifications (a great way to flag something for yourself or someone else). With excellent support for industry-standard file formats + protocols your data is never locked-in either.

Developing for the Connector Platform

From a developer’s perspective, Connector is the best platform for creating easy-to-use web applications that integrate well within a suite of inter-related applications. We’ve used the Ruby on Rails language + web framework, and have built a rich application framework on top of that.

By taking advantage of Connectors libraries + conventions your applications can seamlessly blend into the suite. You can add to the feature set of our current applications. With a real option for an open framework you now can leave the closed application suites for something better.

So, download the code!

svn co http://svn.joyent.com/opensource/connector/source/trunk/ joyent_connector

And here are some more tools to help.