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:
$ echo "<3"

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
$ git clone git@github.com:robotarmy/monkey-flyer-radio-protocol-death-claw-alpha.git
  • The repository has been setup to use bundler with a Gemfile – you will need to install bundler
$ gem install bundler
  • With bundler installed you can use the Gemfile to manage installation of gems :
$ bundle

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
$ foreman start 
  • 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
  post "/deathclaw" do
      """
      Name
      Deathclaw alpha male

      ID
      00167ec1

      Level
      25

      Experience points
      50

      Perception
      8

      Hit points
      750

      Damage Threshold
      15

      Damage Resistance
      0%

      Aggression
      Confidence
      Assistance

      Melee (300 Damage)
          dead 15% Deathclaw egg
          dead 35% Deathclaw hand

   """
  end
  • run your service again
$ foreman start
  • run a post with curl on the command line in a new console window
$ curl -d var=1 http://localhost:5000/deathclaw

Check in your changes

$ git add .
$ git commit -m 'I made a post /deathclaw'

Release to Heroku (ON CEDAR STACK)

  • create a new heroku app ( i named mine )
 $ heroku create radio-protocol-death-claw --stack cedar 
  • 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
 $ git push heroku master
  • check your get
curl http://radio-protocol-death-claw.herokuapp.com/
  • check your post
curl -d var=1 http://radio-protocol-death-claw.herokuapp.com/deathclaw

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:

describe(@"Kiwi", ^{
    context(@"when newly installed", ^{
        it(@"should work", ^{
            [[theValue(true) should] beTrue];
        });
    });
});

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:

+ (id)scenarioToLaunch
{
    KIFTestScenario *scenario = [KIFTestScenario scenarioWithDescription:@"Test that a user can start the app"];
    [scenario addStep:[KIFTestStep stepToWaitForViewWithAccessibilityLabel:@"Welcome"]];
    return scenario;
}

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:


$(document).ready(function(){
  $(window).bind('resize', function() {
    alert('resize event triggered!');
  });
  $(window).bind('orientationchange', function() {
    alert('orientationchange event triggered!');
  });
});

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:

Simple Update Field

Curtis Schofield wrote a gem (originally for a Blazing Cloud project, but released as open source) that lets you edit your text data right on the webpage! It’s called simple_update_field. It’s designed for the simple use case of having a webpage with a bunch of text fields that you want to edit one after the other. After the gem is in place in your Rails app, you click on the text you’d like to edit, type in your changes, then press enter or tab to save your edit to the database and move your cursor on to the next editable field, for rapid editing. You can also press escape to ditch your current edit. See it in action!

I got to help test the gem as it was still being cut! Here’s what I did to get set up with a sample rails app so I could try out simple_update_field.

$ rvm gemset create simple_update_field
$ rvm gemset use simple_update_field
$ gem install rails
$ rails new contacts
$ cd contacts/
$ echo 'rvm --create use ruby-1.9.2-p290@simple_update_field' > .rvmrc
$ cd ..
$ cd contacts/
$ rails generate scaffold person name:string phone:string
$ rake db:migrate

I opened up my Gemfile and added:

gem 'simple_update_field'

Then the gem was just a
$ bundle install
away! After the magic of getting the new gem from Curtis’ computer to mine via rubygems.org, it was time to set up my Rails app to use simple_update_field.

First, I updated my app/views/people/index.html.erb with the attributes that the gem needs to function. I wanted to turn a person’s name and phone into editable items, so I left the scaffolds in place and added simple_update_field’s custom attributes directly to the td elements for each field, along with css classes. For each person, I did this:

<% @people.each do |person| %>
  <tr class="person">
    <td editable-resource-attribute="name"
        editable-resource-model="<%=person.class.model_name.downcase%>"
        editable-resource-uri="<%=url_for(person)%>"
        class="name">
        <%= person.name %>
    </td>
    <td editable-resource-attribute="phone"
        editable-resource-model="<%=person.class.model_name.downcase%>"
        editable-resource-uri="<%=url_for(person)%>"
        class="phone">
        <%= person.phone %>
    </td>

    <td><%= link_to 'Show', person %></td>
    <td><%= link_to 'Edit', edit_person_path(person) %></td>
    <td><%= link_to 'Destroy', person, confirm: 'Are you sure?', method: :delete %></td>
  </tr>
<% end %>

I left my routes.rb and my people_controller.rb as their scaffolded selves, so simple_update_gem could make use of people#update.

The only other thing I had to do was javascript integration. The gem needs to know what css selectors to look for. I opened up app/assets/javascripts/application.js and added the following lines to the bottom of the file:

//= require simple_update_field
$(document).ready(function() {
  SimpleUpdateField('.person .name, .person .phone')
})

Then I restarted my rails server and checked out my people/ page, added some people, and clicked on them. It worked! It’s super-easy-to-use. If you’ve got a series of text fields you’d like to be able to edit quickly, check out simple_update_field!

REPL Mocks in Rspec 2.9

REPL (Read-Eval-Print-Loop) is a great way to learn.

Sarah Allen has a great post on REPL and rspec.
Sarah’s Post on REPL Rspec

In Rspec 2.9 there is a nice way to get the standalone way working


$ irb
1.9.2p290 :001 > require 'rspec/mocks/standalone'
1.9.2p290 :002 > Time.stub(:now) {1}
1.9.2p290 :003 > Time.now
=> 1

Installing RSpec and Sinatra with Rake

Installing Rspec into Sinatra with Rake

This will give you a friendly ‘rails-like’ interface to running your automation tests.

Sinatra doesn’t come with any test harness by default and so you’ll find yourself needing to integrate something.

As a bonus I include a way to gain access to an instance of your sinatra module while the test is running. This allows you to do unit style testing on the Module object itself as it moves through the request life-cycle.

  1. Open the Gist GIST with complete instructions and files
  2. Update the Gemfile
  3. Update the Rakefile
  4. Create a .rspec file
  5. Follow the Instructions

Instructions

# run the bundle command
$ bundle
# .rspec file
$ echo "--color" >> .rspec
$ echo "--backtrace" >> .rspec
# .rspec file
$ echo "--color" >> .rspec
$ echo "--backtrace" >> .rspec
# spec directory
$ mkdir spec
$ touch spec/spec_helper.rb
# Update spec/spec_helper.rb to match file in gist.
# mkdir spec/sample
$ touch spec/sample/instance_variable_spec.rb
# update spec/sample/instance_variable_spec.rb to match file in gist

looking for great developers (mobile & web)

Blazing Cloud isn’t your typical startup or consulting agency. We’re a bunch of startup people who work together to deliver products for hire, creating a structure to give us freedom to pursue our own entrepreneurial ideas or other life plans.

I’ve been intentionally slow to grow the company over the past year, as we settled into a groove, focusing on mobile apps (native and web). We’ve defined some great processes and techniques for agile product development that are our own mix of XP and Lean Startup, and we’re always learning. In fact, learning and teaching are part of everything we do. In addition to the formal instruction we do in our classes and events, we all love to learn new APIs and languages, and getting really good at the best techniques. We always aspire to create beautiful, usable products and we collaborate with our clients in making that happen.

I’m excited that we’re ready to grow the company just a little bit more. Our last few awesome engineers were hired opportunistically thru the grapevine, but I strongly believe that the best practice in hiring is to post a job description and have an open process.

We’re looking for someone excited about native and/or mobile web development — we usually work with Objective-C for iOS, Java for Android, and Ruby/Rails/JavaScript for mobile web. You can be a generalist or specialize in a specific area. On Day 1 you’ll be coding on a customer facing project appropriate to your skill level. We are optimized to teach you whatever you don’t know. We are open to full-time employees or project-based contractors.

As a full-time employee you can look forward to:

  • Opportunity for advancement. We’re small and growing. You’ll be instrumental in shaping the company and we encourage you to pursue a leadership role.
  • Flexibility. In addition to paid vacation, we’ll allow you to take a sabbatical or incubate your own startup. Last summer, one of our engineers took of 6 weeks, spending most of her time learning Spanish in Guatemala. Another of our engineers took a few weeks off to develop an idea for his startup. Other engineers have spent extra time off farming, studying dance, and working on a mobile game.
  • Mentorship. We believe in helping each other.  You can leverage our deep experience to learn what it takes to build and ship successful software products, and we expect we’ll learn a lot from you.
  • Transparency. You’ll have visibility into all aspects of the business, from how decisions are made to the financial health of the company.
  • Benefits. We offer full medical, dental, vision and paid vacation. We’ll pay for one SmartPhone expense (monthly plan + device) and provide a top-of-the-line MacBook if you need one. Also, you can take any of our classes for free.

Equality Opportunity Employer: we welcome applicants from diverse backgrounds. We currently have 50% women/men and engineers with and without CS degrees.  We welcome ninjas, rockstars, and pirates, but you also need to be able to write great code and work well in a team.

Feel free to contact me or anyone else at Blazing Cloud directly, but also apply with Captain Recruiter — they’ll make sure we don’t lose track of anyone. Github and LinkedIn profiles are a fine substitute for a resume if they are up to date.