Sprint Towards 1.8 Release

written by Tyler Keating

SproutCore is about to get a new release on February 29, 2012 and we want to kick it off with an important sprint over the last weekend of the month.  As an open-source project, the success of SproutCore depends on you and others like you, so please consider setting aside some time to get involved.  Thanks!

 

Aside:  We’ve decided that the next release of SproutCore will be titled 1.8.  It’s simply an indication that the code base has changed enough since the 1.7 beta, which should have been finalized some time ago but was missed during the rocky period when SproutCore 2.0 was determined no longer to present the future of SproutCore.

Welcome to Maurits Lamers and Mitch Oliver

written by Tyler Keating

Hot on the heels of last week’s introduction of five new team members, I’m pleased to announce that Maurits Lamers and Mitch Oliver have also signed on as SproutCore Committers. As with the people from my previous post, these names should be of no surprise to anyone who has been with SproutCore for some time.

For those that aren’t sure of the difference between Committers and Reviewers, Committers are actually required to work in their own branches in the repo and submit every change as a pull request to be accepted by a Reviewer. The Reviewers are allowed to make direct fixes, but will most likely submit anything at all substantial as a pull request too in order to get another Reviewer’s feedback and acceptance. Both roles also include the responsibility to try to move the outstanding issues and pull requests towards a resolution.

As you can tell from the above description, both roles are a lot of work and it takes people with a real dedication to the project to accept what can be a thankless and demanding task, so please take a moment to catch all of these people on #sproutcore and sproutcore@googlegroups.com and show them your support.

Welcome to SproutCore’s newest Committers and Reviewer

written by Tyler Keating

As noted in the previous post, we are in the beginning of a major new thrust in SproutCore development and community involvement. As part of this work, we’ve created a guideline to becoming a contributor and list of contributors.

Today, I’m pleased to announce that several people have already graciously accepted the offer to take on roles and contribute even more towards shaping the future of SproutCore as the best application development framework, period.

Please join me in welcoming:

Jason Dooley,
Jeff Pittman,
Tim Evans, and
Wesley Workman

as the first SproutCore Committers and

Geoffrey Donaldson

as a new SproutCore Reviewer.

Undoubtedly, you will have come across these individuals on IRC and the mailing lists and will recognize them for their commitment to SproutCore and to the community. We are very excited and lucky to have them onboard.

In the future I expect to write many more posts like this, so to those that wish to be included, keep contributing, keep learning and we hope to hear from you soon.

Hubbub ❤ SproutCore – Socket.IO & Modular Loading

written by Tyler Keating

As promised in my last post, I’ll go into more detail on some of the technical aspects of Hubbub. And since there was only a single request to talk about Socket.IO integration with SproutCore, that’s the topic for today. In order to keep these posts down to a nice bite-sized length, today will strictly be about how Hubbub uses SproutCore’s modular loading to include Socket.IO.

Socket.IO! I Choose You.

There is actually some nice stuff that happens in Hubbub in real time if you have the app open. For example, if someone sends you a message, signs out an item to you, makes a new item available, or any number of other events occur, then the application updates instantly without requiring a page reload. Sure it’s not new, but with Socket.IO and SproutCore it’s also not a difficult-to-implement kludge.

So for those that haven’t yet tried it, Socket.IO is available here. There are really good instructions on using Socket.IO on their site, but it’s so simple I will include my entire setup here.

My Setup – Server Side

Hubbub’s app server is written with Node and Express. So after installing Socket.IO, there’s nothing more to getting it working server-side than:

app = require('express').createServer({key:, cert:, ca:});
io = require('socket.io').listen(app);
app.listen(3443);

Note: I use port 3443 locally with TLS/SSL encryption, which is not strictly necessary. Continue reading

Hubbub ❤ SproutCore – Introduction

written by Tyler Keating

I was recently asked to do a write-up about my SproutCore app, Hubbub (@hubbubapp), as a general anecdotal guide to those interested in writing large scale applications in SproutCore for the first time.

I’m afraid this first post won’t be very technical, but I will at least attempt to make it an enjoyable read, and to tell you about some of my early bumps in the road so that you can avoid them. My overview of Hubbub will also span a few posts, so if you have particular questions, I can spend some time on them in future.

What’s all the Hubbub?

This isn’t the place to talk up the app itself, only how it operates, so i’ll just give you the briefest of descriptions now to help set the stage.

The premise for Hubbub is that we still live in the physical world; that we all have real families, real friends and real coworkers and that we also all have a lot of real stuff. Hubbub is a companion app for our real lives, helping us keep track of our real stuff and helping us share with our real friends and neighbours.  So with that idea in mind, let me present to you the development history.

Uh, but I don’t remember much about writing Hubbub.

It’s true, but not in the drunken orgy of code way that you’re imagining (calm yourself!). It’s just that Hubbub was written entirely in my spare time, evenings and weekends, going back over a year, which means my brain has jetissoned a lot of those early efforts to make space for everything I’ve learned since then (and to not lose the essentials, like using a spoon, my kids’ names and the order of pants vs. underwear).
Continue reading

The Run Loop: Part 2

written by Tyler Keating

Previously, we delved into the operation of SproutCore’s RunLoop, a powerful mechanism that we rarely work with directly. While understanding the function of the Run Loop is akin to understanding the function of your vehicle’s transmission– you don’t need to know how it works in order to go really fast – they both definitely help you go really fast.

So, as promised in the last post, let’s look a bit further at what we get out of having a Run Loop in SproutCore.

You DOM the Truth? You DOM the Truth!? The DOM can’t handle the Truth!

In a lot of web applications, the first wall that developers hit as the application grows in complexity is that they can no longer keep data synchronized throughout the application. This is typically because they’re using selectors to pull and push data to and from the DOM and it quickly gets out of hand, in particular when you add the complexity of synchronization with a backend and multiple event entry points.

SproutCore’s answer to this has always been that the application has a single “truth” which is maintained in the Model layer. To represent a change in the View layer, you make a change to the underlying Model data and let bindings take care of the rest.
Continue reading

The Run Loop: Part 1

written by Tyler Keating

The following post cuts to the very core, pun intended, of SproutCore: the Run Loop.

What is a Run Loop?

In order to ensure that we’re all talking about the same thing, here’s the definition from Wikipedia:

In computer science, the event loop, message dispatcher, message loop, message pump, or run loop is a programming construct that waits for and dispatches events or messages in a program. It works by polling some internal or external “event provider”, which generally blocks until an event has arrived, and then calls the relevant event handler (“dispatches the event”).

That’s a bit of a high-level definition, but I’ll try to expose the “bare metal” of SproutCore’s Run Loop enough so that it makes sense not only theoretically, but practically too.

What is the Run Loop?

In the context of SproutCore, the Run Loop is a function that coordinates code, key-value notifications, and timers within your application. Typically, a new Run Loop will automatically be started by SproutCore in response to the browser firing certain events, but a new Run Loop can be manually started at any time by placing your code between a `SC.RunLoop.begin()` statement and a `SC.RunLoop.end()` statement.

At this point, you may be thinking, “All right, smart guy, it’s easy to make general statements like ‘firing certain events’, but what events exactly?”. All right, smart reader, heaven forbid we leave anything to ambiguity. Let us look at the events that SproutCore listens for.
Continue reading

SproutCore Baby Steps for OS X

written by Tyler Keating

With the recent release of SproutCore 1.5, it seems like the perfect time for a “Getting Started With SproutCore” refresher. Whether you’re tired of trying to get the benefits of client-side code execution into your server-side apps, or whether you’re tired of trying to get the benefits of multiple platform support into your client-side apps, there’s no better time to give SproutCore a try.

This post will walk you through the very first steps you need to get up and running. It assumes you’re using OS X and have at least some basic familiarity with the command line (come on, it’s not so bad!).

Installation

Installation has been getting simpler and simpler, and the team is working on making this even simpler in the coming releases of SproutCore. Subscribe to the RSS feed to be notified of new posts on the blog; I’ll be sure to post an update once things change.

So let’s get into it; I’ll work my way from the bottom layers on up.

Step 1. Install the Xcode Developer Tools

You’ll need the Xcode Developer Tools to compile some of the RubyGems that the build tools depend on. The appropriate version of Xcode for your current version of OS X should have been included in your install DVD. If not, or if you’ve long-since lost the packaging from your machine, you can get a free copy of Xcode 3.2.6 by signing up for an Apple Developer account. Alternatively, you can buy Xcode from the Mac App Store for $4.99.

Follow the instructions for whichever install path you choose, and report back here when you’re done.


Continue reading