Black Girls Code Needs Our Support

Black Girls Code seeks to increase the number of women of color in digital careers, starting with 7-14 year olds. The campaign to support their “summer of code” ends in just a few days and they are almost half way to their goal. Blazing Cloud is pledging up to $1000 as matching funds if employees or anyone in our community (teachers, students, TAs, or anyone who has worked with us in the past) gives to this campaign before Thurs. 11:59 p.m. Pacific Time. Contribute now and let us know, so we can match your contribution.

Blazing Cloud offers “pay it forward” scholarships to professional and aspiring developers who want to improve their skills and who will make a commitment to taking what they learn and giving back to the community. We believe that a small contribution from our organization, our sponsors and our teachers can make a big impact. A shining example of this effect is Kimberly Bryant, founder of Black Girls Code.

What inspired you to start Black Girls Code?
I decided to leave a large corporation at the end of 2010 and look into starting my own startup company in the mobile health field. As I started my research and networking in San Francisco and the valley I noticed an interesting lack of women or techies of color at many of these events. I distinctly remember bringing up this issue during a panel session with Lisa Stone of BlogHer during a Stanford women’s leadership conference and having many other women in the room echo my concerns. This planted the seed for me to stop complaining about the issue, to take a slight detour from my original plans, and do something tangible to address the problem.

As an engineer myself I had spent many years being the “only one” during my career and I understood the importance of getting girls interested in tech and STEM fields early. Our original focus for BGC was middle school girls but we had so many parents with younger girls request classes we expanded to elementary.

When did you run your first session? Tell us about that experience.
We launched Black Girls Code in April 2011, but we didn’t host our first pilot class until October 2011. We started with a very small core team with only one “true” coder; Mjumbe Poe a Code for America fellow who I met at a CfA event and convinced to help us. We started this movement fueled on pure passion. We bootstrapped everything. Although we sat in the seat of innovation there were no large companies writing us large checks. But we were very lucky to find a computer lab in the basement of a Bayview Hunters Point non-profit ( 100 Percent College Prep Institute) and we paid for everything else from class materials to food from our own pockets. We planned on about 6 girls for the first class and saw our numbers grow by more than twice that over the next six weeks. That was gratifying. But more than anything we were inspired by the girls and their enthusiasm. They took to coding right away and came back week after week excited to learn more.

Tell us about your experience taking the class at Blazing Cloud and how that helped you.
I got introduced to the classes at Blazing Cloud after attending a few Railsbridge Saturday workshops. I wanted to build upon the knowledge I’d built in the weekend classes. I was very happy to receive a scholarship for a Ruby on Rails class which was a major help to me since all of my extra funds were going to BGC. The class actually helped me tremendously in increasing my comfort level with coding and helped frame my ideas on what methods would work with the girls.

Do volunteers make a big difference in your programs?
Volunteers make a BIG difference in our programs. I’ve always felt that BGC is very lucky to have been founded here in San Francisco. Although our the number of women in tech roles in the bay area is still small there are a number of incredible women whom I met at events such as Railsbridge, Women2.0, and WomenWhoCode events who have volunteered for our classes from the beginning.

Ladies such as Judy Tuan, Margaret Le, Carina Zona, Kisha Richardson, Winnie Tong, Joy Dixon, Becky Gessler, Sasha Landry, and of course you Sarah; have all reached out to help by either volunteering their time, giving me advice, or making an introduction for me to contacts in the industry. The women volunteers are especially important in our classes because it allows the girls to see themselves in these roles. I was especially excited to be able to work with Kisha Richardson and Becky Gessler during our HTML/CSS classes. I met Kisha when she first arrived in the Bay Area from New York at a Black Founders networking event at 500 Startups. She left a position in investment banking on Wall Street to come to California and work on her startup company, Fizzburg. She is an outstanding role model for our girls of the possibilities in technology and demonstrates the potential for versatility in your career. I also met Becky at the same Black Founders event and was immediately drawn to her story of building a successful gaming website when she was only 13! I immediately thought about introducing her to my daughter who is also a big gamer.

I am always looking at the potential for mentors and role models. So we were very lucky to have both Becky, Kisha, and Joy volunteer to be lead teachers during our Build a Webpage class. They are all amazing developers and designers and are the definition of “paying it forward”.

How can someone sign up to volunteer?
We have a volunteer link right on our website or folks can email us at [email protected]. We are always looking for good volunteers and we have opportunities for folks to help out in other areas as well. We had almost 80 girls at our last class and continue to grow and expand to other cities as well so help is always welcomed.

How do the students find you? is there an application process?
We have a very basic signup process and there is no formal application requirement despite the age limits (7-17). We try to keep our programs open and accessible to any student open to learning. We also do outreach directly to schools and other youth organizations.

What impact does the program have in the lives of the students?
The impact of our program goes beyond just teaching the students to code. We try to instill self confidence in these young ladies and truly believe we are building the leaders of tomorrow. Black Girls Code’s impact with students also extends to the classroom. Most of the students leave the class and continue to explore concepts and learn on their own. This focus will inevitably extend to the classroom. We are also really trying to shape their perceptions (and societies as well) on what a computer scientist “looks like”. We want to destroy the image of a computer scientist as a male geek-and if we can actually make being a geek cool? MISSION ACCOMPLISHED!

How has the program grown since its inception?
With our Summer of Code Campaign, BGC has started to experience exponential growth. We had almost 80 girls attend our last class in Oakland and our Part II class in San Francisco is almost sold out in 3 days during the July 4th holiday! This is in addition to classes in Atlanta, Chicago, and other cities that are also seeing a great demand. The response to our program has been incredible and I think provides evidence of the need for programs such as ours in this market. If we can convince some of the larger companies here in our own backyard to see the value of what we offer and give us the support we need we could truly make a lasting impact.

What are the limiting factors in the growth of your program?
We are extremely limited by funding. That was the motivation for our Summer of Code campaign on Indiegogo. We struggled during the planning of our last class to provide laptops for the 80 girls who registered. We currently have only 5 loaner pcs and about 30 girls did not have access to a laptop to use during the class. These are the challenges of the digital divide and reaching an underserved community. So we scrambled at the last minute to find a space with a computer lab who could accommodate us. DeVry University stepped up and offered us the use of their space.

The lack of equipment is but one of the struggles we have in sustaining our program. We have a waiting list of more than 150 girls for our classes around the country and requests for BGC chapters in approximately 15-20 cities. But despite our rapid growth, we still struggle to find the financial support to support our programs. It can be discouraging but not enough to deter us from our mission. But we truly do need both physical space, equipment, and seed funding to make our journey lighter.

What is your vision of Black Girls Code?
Although we will always be based here in the bay area my vision is to see BGC chapters in cities across the US and in Africa and Latin America within 5 years. When I stated this same vision on a recent grant application recently the funder thought my plan was too aggressive. Perhaps it is. But I think the problem we are trying to solve with educating our youth is urgent. I am determined to plant the seeds with this generation of youth that will flourish and grow. We need them, especially our girls, to take a prominent role in the future of tech. I’m on a mission and I can’t wait.

Please join us in contributing to Black Girls Code 2012 Summer of Code by Thurs. 11:59 p.m. Pacific Time, and send us a note, so we can match your contribution.

Undelete a branch in git

The other day I had a bit more insomnia than usual. As such it seemed like a good idea to clean up my local repository’s branches using the immediate and seemingly permanent -D option:

git branch -D my_important_branch

With just one tiny statement on the command line, I managed to delete the very stuff I was working on. Apparently, git plans for this kind of stupidity, and it is quite easy to go back in time to a place free of grievous errors. Here is the fix:

git checkout -b my_important_branch HEAD@{1}

Some of this will look like very ordinary git stuff. Up until the “HEAD@{1}”, the above git command is just checking out a new branch. The HEAD@{1} specifies that the source for the new branch is … not the current branch. So what is this HEAD@{1}? It turns out that git keeps track of changes to the head of each branch using a tool ‘reflog’, with is short for reference log. You can look at what reflog is storing at any time:

git reflog

Here is an example of what I have on my current reflog at my wheel.js project:

121f1ea HEAD@{0}: commit: refactor EventManager drag events to be less aggressive about removing listeners from target
cbb109f HEAD@{1}: rebase -i (finish): returning to refs/heads/master
cbb109f HEAD@{2}: rebase -i (squash): Bug: swipes generated during drag
bacc417 HEAD@{3}: rebase -i (squash): updating HEAD
9e327e8 HEAD@{4}: rebase -i (squash): # This is a combination of 3 commits.
bacc417 HEAD@{5}: rebase -i (squash): updating HEAD
7b90379 HEAD@{6}: rebase -i (squash): # This is a combination of 2 commits.
bacc417 HEAD@{7}: rebase -i (squash): updating HEAD
fa11efd HEAD@{8}: checkout: moving from master to fa11efd
9a7d080 HEAD@{9}: commit: event managers no longer trigger swipe during drag

Reflog says that I did a normal commit. Before that I squashed some commits using an interactive rebase. Before that I switched branches.

So in the magic undelete code “HEAD@{1}” refers to reflog for the branch before it was deleted.

Of course, it is always wiser to use the -d option when deleting. That way git provides a nice warning if a branch is being deleted before it has been merged into master. Even better is advice is to get plenty of sleep. It will much improve the git workflow.

Show Test Coverage in Xcode

There is CoverStory - an open source utility that can show you test coverage for your XCode unit tests.

The problem is that CoverStory requires you to pick correct directory where object files and coverage metrics are stored. The directory could change from time to time.

If you add this osascript as post test action in your scheme the CoverStory will open automatically.
To do that select Product->Edit Scheme in Xcode menu. When the drawer opens expand Test and select Post-actions. Click on (+) and pick “New Run Script Action” from the drop-down.
Set Shell to

Set “Provide your build settings from:” drop-down to your test bundle, which is called Unit Specs in our case.
And copy and paste this code:

Here is the screenshot (click to enlarge):


To enable test coverage measurements in your project, you have to set the following build Settings on your test target:

If your Xcode test target fails with the following error:

Then you can add this workaround for missing symbol:

Try it out, let us know how it worked for you.

Eric Ries at GetLeanSF

New Relic put together GetLeanSF on Monday evening, hosted at the fabulous Microsoft office above the Westfield Mall. Hundreds of people gathered to here Eric Ries talk about Lean Startup.

I’ve seen Eric speak a few times and read his book, yet the event still managed to inspire me — reinforcing previous ideas about Lean Startup, without feeling repetitive. Eric gave a short talk, followed by long Q&A with Chris Cook, President and COO of New Relic, and an unconference facilitated by David Nielson.

Eric Ries gave a brief background of how he started evangelizing Lean Startup. As a consultant, he found that people did not believe his advice would work, despite his actual experience from IMVU about continuous deployment and radical practices for early customer feedback. This led him to seek a foundation for his ideas and a framework to help others think about them.

The word “Lean” in Lean Startup comes from the lean manufacturing process which began in Japan with Toyota. He was surprised to learn that many of the practices on which modern software processes were modeled were considered obsolete. The core of lean manufacturing was to figure out:

How do we tell the difference between what activities add value to the customer, and which ones are wasteful?

The audience was engaged throughout the discussion of what Eric calls “the boring stuff,” the process of invention, of figuring out what parts of your new idea have value and tracking what makes a difference with customers.

He spoke of putting out your software early, when you have only features A & B, and you know that the product doesn’t make sense without C. If people complain that your product doesn’t have feature C that is the best, and least likely, scenario. That would be great news! The more likely thing to happen is that people don’t care about your product at all and never sign up to use it. Or maybe they sign up and ask for XYZ instead of C.

He cautioned to be wary of vanity metrics, “the numbers you put in the press release to make your competitors feel bad” — we sent 10M messages on our platform! …is that 10M people who tried it once and never came back? or one very active user? neither one shows traction. What you want to see (and should be tracking internally) are actionable metrics, using boring accounting techniques that let you see how those metrics change over time.

We’re so good at accounting now, that it is easy to forget about what it is for. Accounting was originally developed so that managers could be held accountable. He told of car companies with projections and forecasts for standard volumes, and sales targets that actually meant something because the industry was so stable. In our industry and our modern world, we need innovation accounting.

Eric advocates the use of cohort analysis and advises that you measure as few things as necessary to prove your hypothesis. In the early days of a startup, when you lack a large volume of data — don’t worry about it. Trade statistical measures for rich, in depth feedback
Unlike presidential elections, product market fit has a high signal to noise ratio. You are trying to figure out if anyone cares: is this the right product? are you showing your product to the right people?

A few more notes:

Ried Hoffman: “If you are not embarrassed, you waited too long”
Eric’s Corollary: “No matter how long you wait, you will be embarrassed by it.”

Hypothesize what they customers do when they use your product…”All you need is a Starbucks.”

MVP (minimally viable product) should be defined by what are you trying to learn. What are your risks… What are the biggest risks?

“Science is only as good as your hypothesis.”

“Vision is too precious a commodity to be wasted on faith-based initiatives.”

Overall, it was a delightful evening — many thanks to Eric, Chris, Dave and the folks at Microsoft and New Relic who made it happen.

Paid Design Internship

Blazing Cloud creates innovative mobile products to clients ranging from startups to Fortune 500 companies. At the core of our success is a continuous appetite for becoming experts at new techniques and technologies, paired with our willingness to pay it forward. Over the past year, our classes and events were the main outlet for sharing our knowledge with the community. Today, we are happy to announce our Design Mentorship program.

We are ready to take one design trainee under our wing, opening up a full time, paid internship for a junior designer who can show good design sense and the drive to become great in this profession.

To benefit fully from what we have to teach, you’ll need to be very comfortable in Photoshop or other graphics software, familiar with HTML + CSS, and a good writer. In addition, you will demonstrate the ability to think critically and show a true passion for products and design. These required building blocks will allow you, under our mentorship, to develop into a full stack product designer capable of tackling UX problems in a cross-disciplinary way.

The Program
From Day 1 you will be involved in design activities for client projects, under the guidance of one of our lead designers. You will be expected to learn and contribute to all aspects of product design, from research and brainstorming to visual design and asset production.
Given the focus of the company, you will learn mobile design from the inside out. You will have insight into methodologies like Agile and Lean UX, and you will learn what types of activities and deliverables are suitable to fast-paced, iterative design.

At the end of the program, we hope to graduate you into a full time design position with our team, perhaps the best indicator that we take our investment in you very seriously.

To Respond
* Captain Recruiter will be the first point of contact.
* All applications will receive a response.
* To apply, click here.

Building Small Web Services with a Heroku and Unicorn Sinatra Template Project

Using Sinatra Unicorn and Heroku (CEDAR stack) Together!

I have been asked

  • “How do I get started with Unicorn and Heroku?”
  • “How can I made a remote HTTP webhook?”
  • “How can I make a simple web service?” ,
  • “How can I get started with a free ruby hosting evironment?”

I want to take a moment to answer a few of these questions in a small package I have extracted from one of our small services. This package is avalible on https://github.com/blazingcloud/sinatra-with-unicorn with a MIT License

This blog posts assumes basic familiarity with the ‘git’ command : http://gitimmersion.com/

  • ‘$’ will prefix every command example:

Follow these steps to get started :

  1. Login or create a github.com account
  2. Visit https://github.com/blazingcloud/sinatra-with-unicorn in your web browser and ‘FORK’ the repository.
  3. Rename your fork by clicking the ‘ADMIN’ button
  • I gave mine a name off the top of my head : monkey-flyer-radio-protocol-death-claw-alpha

Follow these steps to set-up development:

I will follow each of the steps with the command that I used - replace ‘monkey-flyer-radio-protocol-death-claw-alpha’ with your project fork name

  • clone your repository

  • The repository has been setup to use bundler with a Gemfile - you will need to install bundler

  • With bundler installed you can use the Gemfile to manage installation of gems :


Follow these steps to change the default GET uri ‘/’ and see the results

  • open ./modules/site/main.erb in your editor
    • you can put html in here or text
  • run the server

  • Use ‘CTRL-C’ to stop the server

Follow these steps to add a post uri ‘/deathclaw’ and see the results

  • open ./modules/site.rb in your editor
    • this is a Sinatra Module - it has a get ‘/’ defined already.
  • add a line of code in the body of the class after the ‘get’ part

  • run your service again

  • run a post with curl on the command line in a new console window


Check in your changes


Release to Heroku (ON CEDAR STACK)

  • create a new heroku app ( i named mine )

  • release your code to heroku ( heroku creates a git remote ‘heroku’ )
    • you should see messages about heroku recieving your push and installing your gems via bundler

  • check your get

  • check your post


DEBUGGING HELP

  • foreman start
    • this command will not reload your code changes - you will need to use ‘rerun’ if you want that.
    • rails does this for free - at the cost of increased learning curve
  • curl ARGS URL
    • no args
      • does a get
    • -d var=1
      • this tells curl to do a post with a post variable (unused, but simulates a post)

Keys to iOS testing: KIF and Kiwi

Most recently Blazing Cloud iOS developers use these open source libraries: Kiwi for unit testing and KIF for acceptance testing.

Kiwi is a BDD (Behavior Driven Development) testing library that supports mocking, stubbing and asynchronous invocations of Objective-C methods or units of code.
KIF (Keep It Functional) library allows to use Objective-C code to write scripts to simulate user taps, gestures and keyboard input and assert on expected updates on a device screen.

Here are the Github forks we use in Blazing Cloud production apps:
https://github.com/blazingcloud/Kiwi
https://github.com/blazingcloud/KIF
Many thanks to Square, Allen Ding and many open source contributors!

Usually we setup separate build targets on iOS Xcode project, which have no impact on the app target.

  • Specs could be invoked within XCode by ⌘-U keyboard shortcut.
  • Integration Tests could be run by ⌘-R keyboard shortcut.

Both test targets could run on iOS Simulator as well as iOS device. Simulator is great in day-to-day rapid development and device to validate behavior in realistic environment.

To start with Kiwi, let’s write a simple spec that should pass when Kiwi is correctly installed. Adding tests to an existing iOS project could be a challenge, so start small.

According to Kiwi docs we create a new (Specs) target on our iOS project and add first spec as a new file to the this target:

For Integration Tests, let’s start by adding simple scenario that validates app was launched successfully. We can do this by asserting on presence of some UI element, like label or button. For example, below should pass when user sees Welcome screen.

After installing KIF and creating an Integration Tests taget we add this scenario to our category of KIFTestScenario class:

There are many other ways to test the apps, including manually. We usually do manual testing thinking the app will be small and quick to test by just using it. On our experience apps grow in complexity quite fast and manual testing leads to fear of change what’s working and embarrassing bugs.

Legacy frameworks like SenTest and OCMock are great when you already have tests. OCMock tests are hard to read, debug and refactor.
We have used GHUnit, which was a minor improvement over OCUnit in the past.

As Objective-C developers we want to author the integration tests instead of dedicating QA resources to do repetitious tasks. Integration tests give us an additional safety net, save time testing in different environments (iOS versions, iPhone and iPad versions). Seeing your apps running through multiple automated scenarios gives you confidence and allows to focus on more interesting and creative test cases.

Let us know in comments how do you test your iOS apps. What are your challenges in testing Objective-C?

orientationchange and resize events on the iPhone

Changing the orientation of your mobile device triggers a resize event. Here’s a very simple page showing that both orientationchange and resize events are triggered when you change the orientation of your mobile device. I used the following viewport meta tag in my html because of the iPhone Safari viewport scaling bug:


<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0">

Using this tag prevents the browser from zooming in, and ensures that the user will not have to pinch or zoom to get back to full page view when changing orientation.

I used this javascript to popup an alert whenever an ‘orientationchange’ or ‘resize’ events happen:

I used jQuery’s resize(), and I found the orientationchange event in table 6-1 of Apple’s Safari Web Content Guide on handling events.

So if you visit it on your iPhone, and turn it back and forth, you’ll see alerts on each orientation change saying that ‘orientationchange’ and ‘resize’ events are getting fired.

In my project, I had a div that I wanted to be the full size of the window and it acted as a container for other objects. On window resize the height and width of the div was set to that of the window.

As a result, when I turned the iPhone to landscape, the width of my div got set to 480px. It turns out that if the width of something in your webpage gets set to 480px or more, weird stuff happens:
- If you start in portrait and go to landscape, both resize and orientationevents are triggered.
- Then if you go from landscape back to portrait, an orientationchange event is triggered, but a resize event is not!
- After that, no more orientation changes trigger resize events (though orientationchange events do continue to go off).

Similar problems happen when starting in landscape:
- If you start in landscape and go to portrait, both resize and orientationchange events are triggered.
- Then if you switch from portrait to landscape, only an orientationchange event goes off.

In the end I had to bind the resize of my div to the ‘orientationchange’, not ‘resize’.

About.me for iOS: 50k downloads in 3 days

We are very pleased about the buzz around the release of AOL’s new about.me iPhone app. Blazing Cloud engineers worked collaboratively with the sumptuous designs of Aaron Martin and the fabulous David Brock of the about.me server team within the media giant.

Founder Tony Conrad tweeted that there were 50k downloads in the first 3 days of its release. Around the same time, the about.me team released a mobile web version of their popular site to format profiles for mobile devices. In addition to the browsing features available on the web, the iPhone app enables you to search Twitter, Facebook and the Address Book on your phone to see about.me pages. There’s also a fun location-based feature which allows you to see profiles of about.me users nearby who are also using the app.

The iPhone App has received rave reviews in several outlets, including the New York Times which highlighted the app’s sensible approach to privacy:

“The about.me team put privacy at the forefront of this experience, Mr. Freitas said, asking people to opt in to share their location or personal information. It is different from an app like Girls Around Me because both sides have to opt in to have their location displayed.”

What other sites are saying about the app:

“Now, about.me iPhone app users can make pages on-the-go as well as connect with people on the street with the mobile app. The ‘Who’s Nearby’ feature — unique to the app — is something that will appeal to people watchers, co-founder Ryan Freitas told Mashable….The app brings many pieces of the successful web platform to the iPhone.” — Mashable

“AOL-owned about.me website launched an iPhone app, helping you take your online identity with you, no matter where you happen to go. Aside from bundling many of the web service’s functionalities, the mobile app also allows you to “Check Out” nearby users’ pages presuming they’ve enabled the option…So if you’re into about.me and you also happen to own an iPhone, grab the app now and take it from there.” -IntoMobile.com

“About.me just released their official iPhone application for searching through each and every About.me profile. No matter whether you’re looking for a potential new hire or trying to find a specific details about a new contact you made – about.me should prove quite useful.” -.Me

About.me has done a fabulous job of gaining a lot of users since its launch in Dec 2010, combined with great SEO and its aggressive integration of services where people publish data about themselves, it has emerged as a key player in an ecosystem which allows us to connect and keep in touch with an astounding number of individuals. The native iOS app which leverages your contacts and social networks is just the beginning of how about.me can enable us to tap into a deep reservoir of information available on the Web.

Reinventing the Wheel? Introducing Wheel.js

For the past couple of months I have been focused on mobile web application development — almost exclusively front-end work. When we started work, we thought for sure there was a framework that could help us through the usual grinds of front-end development, allowing us to focus on our app logic. We looked at heavy-weight champions like Sencha. We looked at the fly-weight jQuery Mobile. We looked at collections of tools: Backbone + jQuery + Mustache. What we started to realize is that as much need as there is for a framework that met all our basic needs, there wasn’t one that we were satisfied with. As a team, we were disappointed. As a tinker, I was inspired to build my own wheel.

The Problem Space

Until 2007, jQuery did a lot for developers to ease the pain of normalizing development across different browsers. In 2007, the iPhone came out with an amazing touch interface. Because Apple wanted the mobile browser to just work, they helped convert touch events into some expected browser events, like ‘click’. While this meant that iPhone users were able to browse the web almost like they did with a mouse on desktop, it also meant that providing a specialized mobile touch experience has not been critical for web developers. Analytics show that more and more browsing is happening with these specialized mobile-micro-browsers. The websites who optimize for the mobile experience win users.

Other than touch events, there are a variety of issues specific to mobile web. Here are the biggest ones:

  • Connectivity cannot be assumed
  • Bandwidth significantly reduced
  • Reduced real estate.

None of these problems require a rocket science solution. On the other hand, using a desktop framework and applying afterwards a mobile software shim is not going to address these huge differences. In most cases, this approach will degrade mobile performance. On the time and money topic, cobbling together a set of tools for each front-end app means lots of (unacknowledged) time devoted to concerns other than app ‘business’.

The Dream Space

There are an infinite amount of possible solutions to the problems of a front-end framework that takes into account the mobile web. Recently, I gave a talk at BlazingCloud about Wheel.js and the first thing I said is that we should all be trying to develop the right framework, because one does not yet exist. The world is ripe for a solution. With that caveat, I want to talk about my own dreams for this solution.

Big picture: The first thing I want is for the framework to be easy and intuitive to use. When I came across Rails in 2006, I had been building mini-MVC-like frameworks for clients in various languages. What made Rails a clear winner when I first saw it was how approachable and easy it was. I want that on the front end. That means there are intuitive defaults that I don’t need to tinker with unless I want to customize in some way. When I reach that customization need, I want it to be easy. For me that means that it is object oriented.

Related in some way to ease of use is the notion that the ‘View’ is king. A lot of frameworks seem to be duplicating server-side MVC on the client with huge emphasis on the model. While I want models that spawn events and talk to the server, the model concern is less critical than managing my views. Client-side applications have more in common with GUI MVC development than HTTP server-side MVCs. The thing I am calling a ‘View’, might be called a controller in Cocoa Objective-C land. In server-side MVC, I am not sure it exists. In this king of a ‘View’, I would like the concern of where the DOM is generated to not be a concern. I want it to be really easy to switch between server generated DOM to ‘View’ generated DOM. Why? When some of the DOM is delivered with the initial page load, the user has the experience of content availability more quickly. In other situations it makes clear sense to render the same DOM on the client. The ‘View’ should be able to be the king of all such situations, with very little change to the code.

Mobile First: I want a framework that is built with mobile concern addressed first and not as an add-on. That means there is an event layer that normalizes touch and mouse events while make gestures listening easy. It also will mean that file sizes are small and that there is a stepped loading process. Files will be conditionally loaded as needed. There will be a base layer delivered quickly that knows how to load the remaining code/templates/CSS while also giving the user visual feedback that something (or everything) is happening.

Outgoing requests also need to be managed differently. The application structure needs to monitor connectivity and send out requests when connectivity is available. That will mean storing a request queue, and allowing the application to continue functioning offline.

Widgets: JavaScript widgets have a lot of the same problems that I have seen with CMS style apps. Initially there is an amazing velocity payload. Then developer’s spend all their time working around the CMS. So, my icing on the framework cake would be an optional library of widgets that are useful but flexible. If they have a theme, it usually gets in my way. I would love a scaffold style basic javascript functionality that can be overridden and customized via their object-oriented flexibility.

Wheel.js

So, I am trying to build my dream. You should build your framework dream too. Or you could just read along and play.

The repository is on github: https://github.com/baccigalupi/wheel.js

Here are the slides from the presentation I gave this week:

http://www.slideshare.net/baccigalupi/wheeljs

Some of what I have created is original, but most of it is cobbled from other tools. That may sound like an irony given my earlier railing, but the point is to cobble a framework together once, not once per project. Here are some of my inspirations and/or open-source theft sources: