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.


<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’.

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.

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


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

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.

By creating Pivotal Labs, Rob Mee has been successful in bringing agile techniques to hundreds of companies. The impact has been more dramatic than if he had written a book or created a training course. When Blazing Cloud was just starting, Rob was supportive in offering advice and referring smaller clients, but even more importantly, Pivotal Labs had set a tone in San Francisco of how good software development was done. Since those values aligned with mine, it was easy to create a consulting business that followed similar software development practices, providing a firm foundation to innovate complementary product development techniques.

In addition to agile techniques, Pivotal Labs culture also embraces open source as an effective means of achieving velocity. They have created and contribute to many open source test frameworks and tools. They have a culture of supporting the community and sharing knowledge. In addition to publishing their tech talks, they have hosted countless SFRuby Meetups and the San Francisco office has committed to hosting RailsBridge workshops quarterly.

Acquisitions are always challenging, but Pivotal Labs is well-practiced in working with larger companies while retaining their culture and instigating positive change. I expect they’ll have a positive impact on EMC, as well as current and future clients. We wish Pivotal Labs all the best in their future expansion.

This way i don’t have to remember the name of the app all the time for every project and i can
easily work with heroku the way i work with git for pushing to heroku :D


$ git remote show production


* remote production
Fetch URL: git@heroku.com:XXXY.git
Push URL: git@heroku.com:XXXY.git
HEAD branch: master
Remote branch:
master new (next fetch will store in remotes/production)
Local ref configured for 'git push':
master pushes to master (fast-forwardable)


Here is an example of running a heroku command with this option

heroku pgbackups:capture --remote production


tl;dr; A little impatient, are we? Just go to the git repository.

Step 1. How the #!@% do I setup Closure?

I’m glad you asked. Follow these steps.

1. mkdir godzilla # why not? godzilla will hold your HTML and JS files for experimenting with Closure

2. cd godzilla # I know it’s scary going near godzilla, but be brave

3. gem install sinatra # install the sinatra web server, a lightweight web framework for Ruby

4. echo “require ‘sinatra’” > server.rb # create the file used to run our sinatra server

5. mkdir public # create a public directory for all of our static HTML, JS, and CSS

6. mkdir public/javascripts # holds application javascript files

7. svn checkout http://closure-library.googlecode.com/svn/trunk/ closure-library # grab a copy of Google Closure

8. cp -R closure-library/closure/* public/ # copy the static assets that you need to write Closure JS, also grabbing the Python scripts needed to eventually compile your javascripts

Step 2. Write a very simple Javascript application with Closure.

The application we will be creating simply writes messages to the viewer by appending elements to the document body. The godzilla.test.MessageWriter class is responsible for writing to the DOM.

1. Create a file public/test.html with this source:

<!DOCTYPE html>

<html>
  <head>
    <title>Testing Closure</title>

    <!-- Include the Closure base.js file, responsible for bootstrapping the Closure runtime -->
    <script type="text/javascript" src="/goog/base.js"></script>
    <!-- This is our application-specific javascript file -->
    <script type="text/javascript" src="/javascripts/test.js"></script>
  </head>

  <body onload="execute()">
    <h1>Messages</h1>
  </body>
</html>

2. Create a file public/javascripts/test.js with this source:

// This file provides this namespace to other code
// that may reference this namespace.
// This information is used by the compiler to
// optimize your code.
goog.provide("godzilla.test");
goog.provide("godzilla.test.MessageWriter");

// We want to use some functionality defined in this module.
goog.require("goog.dom");

// A simple object constructor.
// MessageWriter will append messages to our document body with a given prefix
godzilla.test.MessageWriter = function(prefix) {
  this.prefix = prefix;
}

// Append a message to our document's body
godzilla.test.MessageWriter.prototype.write = function(message) {
  var m = goog.dom.createDom("div", null, this.prefix + message);
  goog.dom.appendChild(document.body, m);
}

// Let's write some messages
function execute() {
  var writer = new godzilla.test.MessageWriter("Info: ");
  writer.write("Mothra is coming!!!");
  writer.write("I see your Schwartz is as big as mine.");
}

// Feel free to write more awesome messages

Step 3. Watch your uncompiled script run beautifully.

1. ruby server.rb # start up your sinatra server

2. Navigate to http://localhost:4567/test.html # see that your messages made it onto the page

Step 4. Cry when your script fails to compile properly with advanced optimizations.

1. Download the latest compiler jar here: http://closure-compiler.googlecode.com/files/compiler-latest.zip

2. Extract it and move compiler.jar into public/compiler.jar

3. cd public

4. bin/build/closurebuilder.py –root=../closure-library/ –root=javascripts/ –namespace=godzilla.test –output_mode=compiled –compiler_jar=compiler.jar –compiler_flags=”–compilation_level=ADVANCED_OPTIMIZATIONS” > javascripts/test.compiled.js

5. Notice the warnings :(

6. Modify your test.html file to point to the compiled javascript.

<!-- Include the Closure base.js file, responsible for bootstrapping the Closure runtime -->
<!-- <script type="text/javascript" src="/goog/base.js"></script> -->

<!-- This is our application-specific javascript file -->
<!-- <script type="text/javascript" src="/javascripts/test.js"></script> -->

<script type="text/javascript" src="/javascripts/test.compiled.js"></script>

7. Browse to your page again: http://localhost:4567/test.html

8. Notice that nothing happens, and the Javascript error is “Uncaught ReferenceError: execute is not defined” (at least in Chrome this is what you will see)

9. What happened? Move on to Step 5 to find out.

Step 5. Export your execute function and let Closure know that MessageWriter is a constructor.

1. Add this line to the end of test.js: window["execute"] = execute;

2. Recompile your javascript and note you still have some warnings

3. Navigate to your test page and see that everything is working again! This is because the Closure compiler renames your execute function to a shorter name in order to reduce the size of the final output file. In order for your old references to the function to work, you need to export the function to window.

4. To get rid of the compiler warnings, we need to tell closure that our MessageWriter function is actually a constructor. To do this, add the following lines directly above “godzilla.test.MessageWriter = function(prefix) {”

/**
* @constructor
*/

5. Recompile your javascript, and look… You have no warnings or errors!

Step 6. Eat a cookie and ponder what just happened. Nom nom nom.

Also, after you are done eating your cookie, you could view the git repository.

For a list of compiler warnings that Closure could give you, go to: https://developers.google.com/closure/compiler/docs/error-ref

A final note. If you are looking for a method that you are sure should exist in Closure, but you can’t find it in the API docs (I was looking for a filter method for arrays), then search in Google for it: “google closure array filter”. You may find what you are looking for in the source code, even though I couldn’t find anything on goog.array in the online docs.

Some good folks have been putting together gems that really help getting started with Javascript testing in Rails, which became somewhat more challenging with the Rails 3.1 asset pipeline.  I decided to dig through some of this and get up to speed with a fresh install of Rails 3.2.2 using my favorite JS testing framework, the BDD-style Jasmine.

I started with Derek Hammer’s testing coffeescript tutorial — I’m not sold on coffeescript, so I reimplemented the first “sanity” spec in plain old javascript.

Note: do not name your .coffee files the same root name as your .js file — only one of them will be executed twice.  Here’s a comparison of the syntax:

Coffeescript Jasmine Spec:

describe "sanity", ->
  it "1 should == 1", ->
    expect(1).toBe(1)

  it "says hello", ->
    expect(helloWorld()).toEqual("Hello!")

Javascript Jasmine Spec:

describe("sanity js", function() {
  it("2 equals 2", function() {
    expect(2).toEqual(2);
  });

  it("says hello", function() {
    expect(helloWorld()).toEqual("Hello!");
  });

});

Ok, I’m almost won over to coffeescript by this example — it’s nice that I can write my specs in coffeescript and code in Javascript (and I assume vice versa), so I can experiment without having to make a binary decision.

I can see failing specs by running rails s and going to http://localhost:3000/jasmine and it looks like this (when I’ve defined the helloWorld() function but it returns the wrong thing):

Even better, using jasmine-guard, I can see this on the command line:

Summary of getting this all working:

Using rails 3.2.2…

$rails new jasminerice-example
$cd jasminerice-example

add the following to your Gemfile

group :development, :test do
  gem "jasminerice"
  gem "guard-jasmine"
end

bundle
brew install phantomjs

I got a “SHA1 mismatch” error, fixed with

  brew update
  brew install phantomjs

Then

bundle exec guard init jasmine
mkdir -p spec/javascripts
touch spec/javascripts/spec.js
touch spec/javascripts/spec.css

in spec/javascripts/spec.js

//= require application
//= require_tree .

in spec/javascripts/spec.css

/*
 *= require application
 */

Now any coffee or js you put in spec/javascripts will be executed when you rails s and go to http://localhost:3000/jasmine or see your specs run on the command line with:

bundle exec guard

Happy Testing!