Gaslight @teamgaslight - Tumblr Blog

Here’s Gaslight Co-Founder and Developer Chris Nelson at the Gilt podium, leading yesterday’s free AngularJS class at our NYC office. Sixty technologists from Gilt, Urban Compass, OnDeck Capital, AppNexus and other companies joined us for the all-day course, which covered everything...

We're bringing our introduction to AngularJS training class to NYC thanks to our friends at Refinery29! If you're curious about AngularJS and want to dive in, we're here to help!

Check out the details and register at https://gaslight.co/training/courses/8.

Hope to see some of you there!

#training #angularjs

Any designer worth their salt working in interfaces has to have some basic understanding of how to run a dev project. On the flipside, you don't need to be one of those des/dev demi-gods to work with developers. Here's a few things I've learned along the way!

#design

We just shipped a new version of our blog. It's a [Rails app][app]. It's not some fancy-pants, johnny-come-lately static site generator. Why on Earth would we do such a thing? Well, it turns out there are several reasons.

We moved the blog from Tumblr to our own Rails app. Here's why.

Don't worry, we'll still post here for your dashboarding pleasure!

#ruby on rails

July CincyRB: Ruby Warrior - Ruby Warrior code review, Ifs the Command Pattern and you. Followed by Ruby Warrior round 2 (the intermediate levels)

#video

July CincyCocoaDev: Lightning Talks - Dominic Macanas: UIAutomation from the command line with Tuneup.js Jonathon Hibbard: Cocoa Controls Top Picks Alex Robinson: View layout debugging with Reveal Jeremy Black: Project Nomad Doug Sjoquist: AppCooker and AppTaster demo - building quick prototypes

#video

#data

Style Guides: Or How I Learned to Stop Worrying and Love the Grid

Bam, I have created the perfect design. Every checkbox is in place, all the type is perfectly aligned. Oh wait, I resized the window and everything IS WRONG. One of the things I miss the most about print design is the certainty that an element will appear precisley where I have placed it in the page. I know exactly the number of words on a page and it will not change. That level of control really appeals to my perfectionist personality.

When I made the jump to the web, I still wanted to do full-on mockups. All this accomplished was giving the client a reason to be angry when things didn't turn out exactly the same. A year later and a year wiser, I've finally embraced the fact that I can't control everthing, but I can control the important parts. Combine a framework for a responsive grid and careful design of the main page elements, then throw it all together and let it do it's thing.

Ok it's a little more complicated than that. My saving grace has been style guides. They come in a vareity of names, but for this purpose, a style guide is a compilation of a site's main elements. This usually consists of buttons, navigation, and anything along those lines. By establishing a strong visual style through the page elements, the feelings behind the design still come through.

The Style Guide Process

Create Wireframes

Like any good interactive project, start by creating wireframes of the project. Hand sketches are perfect for this. Your main takeaway from these is to establish what elements you think will be used more than once on a page. This can range from icons to pagination. Make a list of these elements. I would try to limit this to around 10 elements. Of course, you'll end up with changes down the line, but hopefully this will cover the majority of your elements.

Create Cohesive Element Page

In theory if you're a bad ass and design straight in the browser, then you can skip this step. Personally, I like to use Illustrator to help get my thoughts in order, without fighting with implementation. Start by creating a grid based on your framework. Then slowly start building your elements. Do the design dance until you have a page of elements you think work together and represent your project well. Although this is a lot of work upfront, I have used my initial elements page as a template for other projects.

HTML Styleguide

Great! You know what you want things to look like. There are a variety of styleguide templates out there or you could chose to create your own. Again, there is a lot of work upfront, but if you plan on making this your workflow, it's worth it to establish your own template. Creating classes that you are compfortable with and know is worth the effort. Knowing you want to have 3 different styles of buttons, allows you to create cohesive class names. I start by creating all the markup in HTML first, then go in and add the styling. In the end, you should be left with a fully functioning page of elements that you can pull class names from to style your actual pages.

Conclusion

Although the workflow is a heavy upfront, having a cohesive guide of elements for a large project ends up being worth the effort. As we all know, a website is never done. Syle guides allow for flexability to grow a site, while also having it stay within the correct brand guidelines. If a project is handed off, your extremely helpful and thoughfully named classes will make the design of the site very easy. Easier, cohesion, and it makes a cool page. What more can you ask?

#web design

How We Handled the Problem of JS Date/Time Equality

We are using Konacha and Chai on a project and we needed to compare a bunch of time values in our specs. This post describes some of the pain we experienced testing JS Date/Time equality, and what we did about it. As a result of this work, we've released a Chai plugin for datetime assertions that you can find here:

Chai-Datetime

Github Repo

NPM Package

Comparing Dates and Times in JavaScript

Date equality in JavaScript is not based on value.

var t1 = new Date(2013, 4, 30, 16, 5) var t2 = new Date(2013, 4, 30, 16, 5) t1 == t2 // => false t1 === t2 // => false t1.getTime() === t2.getTime() // => true

Example Specs (Before)

I was growing very tired of calling getTime() on my expected and actual values. Here is what the specs were looking like before we added custom assertions.

describe('time equality', function() { it('returns true when they are the same time', function() { var actual = new Date(2013, 4, 30, 16, 5), expected = new Date(2013, 4, 30, 16, 5); actual.getTime().should.equal(expected.getTime()); }); it('returns false when they are not the same time', function() { var actual = new Date(2013, 4, 30, 16, 6), expected = new Date(2013, 4, 30, 16, 5); actual.getTime().should.not.equal(expected.getTime()); }); });

Not only does this seem like a lot of repetition, it also provides poor feedback when the assertion fails because we're comparing numeric values instead of the times themselves.

describe('failing time equality', function() { it('fails to have readable failure messages', function() { var actual = new Date(2013, 4, 30, 16, 6), expected = new Date(2013, 4, 30, 16, 5); actual.getTime().should.equal(expected.getTime()); }); });

AssertionError: expected 1369944360000 to equal 1369944300000

Custom Chai Assertions

chai.Assertion.addChainableMethod('equalTime', function(time) { var expected = time.getTime(), actual = this._obj.getTime(); return this.assert( actual == expected, 'expected ' + this._obj + ' to equal ' + time, 'expected ' + this._obj + ' to not equal ' + time ); }); chai.Assertion.addChainableMethod('equalDate', function(date) { var expectedDate = date.toDateString(), actualDate = this._obj.toDateString(); return this.assert( expectedDate === actualDate, 'expected ' + actualDate + ' to equal' + expectedDate, 'expected ' + actualDate + ' to not equal' + expectedDate ) });

Example Specs (After)

Here are the specs from above with less getTime() noise and better failure messages.

Passing with less getTime() noise

describe('better time equality', function() { it('returns true when they are the same time', function() { var actual = new Date(2013, 4, 30, 16, 5), expected = new Date(2013, 4, 30, 16, 5); actual.should.equalTime(expected); }); it('returns false when they are not the same time', function() { var actual = new Date(2013, 4, 30, 16, 6), expected = new Date(2013, 4, 30, 16, 5); actual.should.not.equal_time(expected); }); });

Failing with Better Message

AssertionError: expected Thu May 30 2013 16:06:00 GMT-0400 (EDT) to equal Thu May 30 2013 16:05:00 GMT-0400 (EDT)

Date Assertions

You can also compare dates regardless of their times.

describe('date equality', function() { it('compares dates regardless of their associated times', function() { var actual = new Date(2013, 4, 30, 16, 6), expected = new Date(2013, 4, 30); actual.should.be.equalDate(expected); }); });

Conclusion

Too much detail? Go check out the README and jump in!

#javascript #chai #testing

Announcing Web School Cincy!

The Windup…

The number of “paid apprenticeship" schools has experienced a bit of a surge recently, especially in web development, and specifically those teaching Ruby on Rails. This phenomenon is due largely to the realignment in the work force from material workers to information workers.

We’ve seen the demand for tech talent grow steadily and we’re beginning to feel the pinch ourselves. Recruiters are becoming a more frequent “guest" at Cincy RB which is kind of a new thing for Rubyists, at least locally, and it’s not only recruiters but companies sponsoring meetings in order to pitch to attendees. We see this as a good problem to have but a problem nonetheless and one we feel capable of helping to address.

Gaslighters have established a tradition of teaching, from the inaugural Cincinnati Day of Ruby, to mentorship of students at several local high schools. We’ve spoken at regional and national software developer conferences and host the Cincinnati iOS, Javascript and Ruby user group meetings each month. From a training perspective, our current focus is the formation and guidance of the Cincinnati Web Tech study group which aims to introduce Web development to those who have an interest in the subject and provide support for their desire to explore the subject in greater depth.

About a year ago, we began kicking around the idea of a gSchool-like program here in Cincinnati but we were busy doing many things and really had no desire to own the program. So we asked if anyone else was interested in partnering with us to launch a program and Scott Baron from Neo’s local office said to count him in. Erin Kidwell, from Girl Develop It said to count her in. Mike Bott of The Brandery said he was interested too. So we all got together and started talking, but despite our best intentions, we realized this was a bigger undertaking than we thought. We then decided to talk to Jeff Casimir, co-creator of Hungry Academy and gSchool and it became evident that if anything were going to be done we simply had to look to others who have been successful and follow their lead.

The Pitch…

So, in the spirit of “good artists borrow, great artists steal," we are actively working to launch a full-time six month training program here in Cincinnati with the aim of graduating 24 competent Web developers twice a year. Our desire is to welcome the first class before the end of this year, 2013. The program will operate in and around a vibrant Rails consultancy, Gaslight’s new (and hopefully soon to be announced) location in downtown Cincinnati. This may seem like a bold plan but we have little doubt there is an urgent need for it and have faith that our community will respond to this announcement.

Our goal is to create a program that will meet the needs of our community and not simply our own. To be frank, there was a point when we didn’t understand that but Erin and Mike drove that point home. We hope to produce young developers with fire in their bellies and a desire to build something awesome who will team up with entrepreneurs at The Brandery, Cintrifuse or NKU’s INKUBATOR. We also want to attract career change minded 30 and 40 somethings seeking the stability of product work with one of the many companies in our region clamoring for Rails talent. We especially hope to reach veterans looking to transition to a civilian career in a growth industry that is as rewarding as serving their country. Perhaps most importantly, we want to attract students in under- represented socio-economic groups. Who knows, maybe we’ll even find a hippy or two wanting to join us at Gaslight.

So we’re seeking sponsors and students for Web School Cincy. Don’t worry, that’s just a working name. You can sign up today and we’ll keep you in the loop with all the latest developments. Just visit signup.webschoolcincy.com and leave us your email address or email us at [email protected] and tell us how you’d like to be involved.

#cincinnati #training

Encouraging Gender Diversity: 3 Reasons Why QCMerge Attracts A Different Audience

In early May we helped put on QCMerge, a conference hosted downtown in Cincinnati. The conference is designed to bring together developers, designers, entrepreneurs, marketers, and anyone else who makes a living on the web. This is a fairly unique approach to tech conferences, and what we’ve found is that it dramatically affects the gender diversity among attendees. It’s no secret that this has been a problem in the web/software industry as a whole, and it’s certainly obvious at most conferences. Female attendance under 5% at technical conferences is common. And if you go to many user groups, you can often find even fewer women there. We didn’t want that to happen at QCMerge, so here’s what we did to reverse that trend.

Attendance follows speaker makeup.

Each year we’ve organized QCMerge, we’ve been careful to have a speaker lineup that includes many women. Each year, at least a third of our speakers have been women. Last year, it was closer to 50%. Don’t expect to have strong female attendance when all of your speakers are male. Be intentional about inviting female speakers for your conference. If you’re inviting speakers, it really isn’t hard to find extremely qualified men and women for a given subject. If you’re doing a CFP, you may have to work hard to encourage submissions from a diverse audience.

Bridge the gender gap through related fields and interests.

It’s well known that the vast majority of developers are male. Thankfully, other fields don’t have quite as bad of a problem. A good way to introduce women to software development is through other skill sets that are part of the web/tech world. Perhaps someone is currently a designer, but they’re not sure how to get involved in development. Maybe someone in marketing knows their material is presented through the web, but they know nothing about the technical details. A conference that promotes cross-over between these industries provides a better stage for introducing women to software development.

Watch your blind spots.

Even if you are intentional with your speaker makeup and conference subject matter, it’s still easy to not pay attention to small details that can exclude certain groups from your conference. Things like venue, marketing channels, messaging, etc, can influence the audience you attract to your event. It makes sense to include several voices in your planning to make sure you’re not turning a blind eye to details that affect your potential attendees’ choice to attend.

For those who’ve succeeded in bridging the gender gap at tech conferences, have these approaches been part of your success? Or, have you tried to do these and failed to increase the diversity of your attendees? We’d love to hear your feedback and ideas about how to further solve this problem.

#qcmerge #culture

Intermediate Ember Controller Concepts

I’ve been finding issues in an Ember application I’m working on where the author (me) didn’t fully grasp Ember controllers. Here are a few controller concepts I’ve learned.

Controller Concepts

A controller is a decorator for your models. It proxies all the get and set calls to the underlying model unless that property is defined on the controller itself.

Controllers are fleeting, but models are forever (if you’re taking an Ember Data-like approach). As you route around your application, controllers will be destroyed so don’t count on them surviving very long. An exception to this is the immortal application controller.

You don’t necessarily need a controller, especially if you’re not holding onto application state. The router events object is a great place to save, create, and delete models.

A Day in the Life of a Controller

In this example I’m going to show a list of items and let the user select one at a time. This is a pretty common use case where controllers shine.

First we’ll setup a route with some dummy data and render a list of names.

App.IndexRoute = Ember.Route.extend model: -> [ {firstName: 'Gut', lastName: 'Bomb'} {firstName: 'Rock', lastName: 'Tastic'} {firstName: 'The', lastName: 'Fish'} ]

<ul> {{#each}} <li> {{firstName}} {{lastName}} </li> {{/each}} </ul>

Earth shattering stuff.

But now it gets interesting. When the user clicks on an item we want it to appear selected.

<ul> {{#each itemController="name"}} <li {{action select}} {{bindAttr class="isSelected"}}> {{firstName}} {{lastName}} </li> {{/each}} </ul>

App.NameController = Ember.ObjectController.extend select: -> @set('isSelected', true) unselect: -> @set('isSelected', false)

First we’re telling each to use the nameController to wrap each name. Then we send the select action to the nameController when an item is clicked. The select action changes the isSelected property which in turn adds the is-selected class to the li element.

But oh no! If we click another item it also gets selected without unselecting the other one. Try it out.

We need a way to unselect names. Let’s introduce an array controller to manage the array of names.

App.IndexController = Ember.ArrayController.extend selectedName: null toggleSelect: (controller) -> # Grab the previously selected name and unselect it. @get('selectedName').unselect() if @get('selectedName') # Set the newly selected name and mark it selected. @set('selectedName', controller) controller.select()

In this new controller we’re calling our action toggleSelect to more explicitly describe our behavior. Next we’re accepting the clicked controller as an argument to this function. We need this argument because without it the IndexController doesn’t know which item was clicked.

This warrants a change to the template.

<ul> {{#each itemController="name"}} <li {{action toggleSelect controller}} {{bindAttr class="isSelected"}}> {{firstName}} {{lastName}} </li> {{/each}} </ul>

There’s a lot going on in this new action call. The toggleSelect action gets sent up the chain of controllers all the way up the router unless something implements that method along the way. In this case, our IndexController will catch this call. Also notice that we’re passing in controller to action. This is important because we want to set properties on the controller, not on the model itself. If we used this, the controller would be unwrapped and we would be working with the naked model.

So now check it out. It works!

However we have committed a huge sin without even realizing it. Even though it looks like we’re changing the isSelected property on the controller we’re actually changing it on the model! Here is the fix.

App.NameController = Ember.ObjectController.extend # Initialize the property on the controller isSelected: false select: -> @set('isSelected', true) unselect: -> @set('isSelected', false)

So remember that every property will be proxied to the model unless you define it on the controller.

#Ember.js #javascript

Chaminade Julienne Summer STEMM Camp

A Chance Encounter

Through a connection at the Southwest Ohio Givecamp we were contacted by Meg Draeger, coordinator for Chaminade Julienne Catholic High School's STEMM Summer Camp in nearby Dayton, OH. The program targets grades 7-9 and strives to provide campers with a sampling of science, technology, engineering, math and medicine. Meg was interested in adding a session on software development. A couple emails and a phone call later, and we were on the schedule for a 90 minute session entitled simply, "Web Development with Ruby on Rails."

Perfect Timing

Through previous experience teaching web development at Little Miami and Ludlow high schools we knew that maximizing learning and minimizing distractions would be our greatest challenge. That's where our friends at Nitrous.IO came to the rescue. With Nitrous we could just login and get to work with a fully functional and completely integrated Rails development environment.

Furthermore, the Nitrous team hooked us up with sufficient invites to allow all the students to pair up and program to their hearts' content. We literally couldn't have done it without them. NOTE: They're just coming out of their private beta. So we encourage you to check them out!

Chaminade Julienne Summer STEMM Camp attendees running their Ruby on Rails application live on the Web.

CJ Eagle Pride!

On the day of our session, Chris Nelson and I headed up I-75 excited to share our love of Ruby, Rails and Nitrous. Again drawing on previous experience we had decided to have the students create a simple wish list application using Ruby on Rails' scaffold generator. After some experimentation with their running apps we refactored them to add some desired functionality, mainly the ability to click on links to wish items which introduced views in Rails and to hide wishes that had already been granted which introduced controllers.

Observations

As previously mentioned, we paired up the campers and gave them the basic rules about switching roles; the navigator can request the keyboard at any time and to avoid swapping roles too frequently which I thought might become a problem but didn't. One third of the nine pairs swapped without prompting. The remainder had to be encouraged to do so. There were no major logistical issues.

The campers were very engaged and warmed to the material quickly. There was the usual mix of eager and timid campers but no one seemed too lost or aloof. The first a-ha moment came when the campers started their skeleton Rails apps the first time then previewed them running live on the Web. The second a-ha moment came when they removed the default index page and displayed their empty wish list for the first time. Once we demonstrated that they could enter and save data all we had to do was sit back and watch. For us, that's the most rewarding part.

Thanks to Nitrous it is easy to share our passion for learning, building and sharing. Chris and I would like to thank Meg for inviting us to participate in their program and hope that we inspired the students. Thanks also to the students for sharing their energy and inspiring us!

#sharing #teaching #students

Why I Chose AngularJS

I chose AngularJS because it seemed closer to what I know. More like Backbone. Data-binding is touted as Angular's killer feature over Backbone, but there's a lot more to Angular. I also chose Angular because everybody else here in the shop was learning Ember. What is wrong with me?

Views

Angular templates are HTML. I know HTML, that side of Angular gives me comfort. You write valid HTML and "sprinkle" it with Angular directives (ng-repeat, ng-hide, etc). Angular traverses the DOM, collects the directives, and produces a live view that is plugged into your application's scope. It's cool. You can write directives to customize your UI.

Scopes

Angular scopes are something you encounter quickly and it's an important piece. Scope is actually $scope in an Angular app, and it is the connection between an Angular controller and the view. Every object or function you attach to $scope in the controller is available to the view. Scopes model the DOM and are hierarchical.

Models

I was intrigued by the lack of an Angular Model. I've always liked the flexibility and simplicity of Javascript objects. Models in Angular are any object, simple or complicated, that you choose to attach to the app's scope.

But modeling the relationships between objects in my app wasn't simple. When I have a Post that has an Author, and Author that has many Posts, and no "database", things get trickier. This isn't Angular specific, and probably speaks to my inexperience a bit. I had to be very diligent about maintaining a single source of truth, and eliminating state. It feels like this would be easy in Ember.

Services

The Data problem is the arena of Angular services. You write Angular services to share things between controllers in your app. In my case it was a collection of Post models and a collection of Author models. That was my data and every controller in my app needed access to it. You hear a lot about dependency injection. Services is where that comes into play. When you define a controller you also define what services it's going to need, and pass those in.

Documentation

Documentation is really good in Angular. In fact I'm sitting here reading it and realizing I haven't even scratched the surface of how cool this is. Here are some of my favorite pages:

Overview of Concepts

API

Examples

Conclusion

There's not a huge learning curve for Angular. There are a few unfamiliar concepts that you run into early, and can read about. The "right way" to do things isn't apparent at first, but it's up to you and you can go fast. That can be a double edged rope with which to hang yourself. All in all, writing an Angular app was enjoyable and painless, and Angular does some cool simple things that make sense.

Thanks to Michael Ball for giving me some exposure to this awesome tool.

#angularjs #javascript

Visit Original Link

In this episode, four Gaslighters gather in the podcast studio to explore our evolving Kanban process. We talk about the incredible shrinking story, why we’re moving away from using Pivotal Tracker, and how to improve our communication as we develop software for our clients.

Subscribe with RSS | Subscribe with iTunes

#podcast #kanban

Client-Side IDs with Ember Data

Why Client-Generated IDs?

In most client-side frameworks (e.g. Backbone, Angular, Ember) models created in the web browser get temporary IDs (client IDs) and get their permanent ID from the server after a successful save.

For client-heavy applications, generating IDs on the client can simplify interaction with the server. Consider the case where the user creates a post with several attachments. You’ll need to make sure that the post is saved and has its ID resolved before attempting to save the child models in order to preserve this relationship. Take a look at this Ember issue and you’ll start to appreciate the complexity of this use case.

It can be liberating to know the ID of a model before it is saved. While uploading an attachment, you could associate it with other models or send someone a link to where the attachment will be. Users could work offline and save records to the database later without worrying about how to resolve and update IDs.

Because we’re using UUIDs, you could hypothetically find any record in your application given only an ID. I’ve not seen this used for anything practical yet, but there could be interesting possibilities if we kept a global store of IDs and their associated objects on the client.

If you find yourself generating secret IDs for resources (think account activation URLs) you may save yourself some code by using unique IDs. Security-wise, it really can’t hurt.

A Brief History of (My Experience With) Client-Side IDs

I first encountered client-generated IDs when working with Spine. Looking back at older versions you can see that Spine included a UUID generator. Every model was was given a unique ID upon creation.

Spine Author, Alex Maccaw, was critical of Backbone’s temporary client IDs:

… a solution that Backbone uses is generating an internal cid (or client id). You can use this cid temporarily before the server responds with the real identifier… I’m not such a fan of that solution, so I’ve taken a different tack with Spine.

However, in one commit that says it all ("add CIDs (inspired by Backbone)") Alex brought Spine inline with Backbone’s server-generated ID strategy.

Despite this new direction, Spine remained flexible and is a great platform for client-generated IDs. Backbone isn’t as friendly for client-generated IDs, mainly because it uses the existence of a permanent ID to determine whether a record has been persisted. But, as Zed Shaw would say, Programming Motherf*er.

class App.Model extends Backbone.Model initialize: -> unless @id @set('id', utils.guid()) unless @id @_new = true @once 'sync', => @_new = false isNew: -> @_new

Client-Side IDs with Ember Data and PostgreSQL

Ember Data is rarin’ to go with client-generated IDs. Override the dedicated method in the RESTAdapter and you’re golden.

DS.RESTAdapter.reopen generateIdForRecord: -> 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace /[xy]/g, (c) -> r = Math.random()*16|0 v = if c == 'x' then r else (r&0x3|0x8) v.toString(16)

This simple ID generating algorithm has been working from me, but If you’re looking for really robust ID generation you may want to check out Eric Elliot’s CUID library.

The generateIdForRecord function and the inclusion of a specification for client-generated IDs on jsonapi.org gives me confidence that Ember will continue to be a good fit for this approach.

Even though we’re talking about client-generated IDs, there will be times when the server needs to generate IDs of its own. If you’re using Mongo, you’re in luck — it already uses unique IDs. Here’s how you can whip up some matching unique IDs in PostgreSQL and Rails 4 with a couple of migrations.

# Enable UUID generation in PostgreSQL class SetupDatabase < ActiveRecord::Migration def change enable_extension "uuid-ossp" end end

class CreateDocuments < ActiveRecord::Migration def change # Use {id: :uuid} to use UUIDs as the primary key. create_table :areas, id: :uuid do |t| t.string :name # t.belongs_to :category will use an integer. You'll need to setup your # associations like this. t.uuid :category_id end end end

Tradeoffs

I haven’t hit any major pain points with client-generated IDs yet but here are some quick considerations before you dive in:

Model.first and Model.last won’t behave the way you expect in Rails, since the IDs may not be sequential.

There are some rumblings on the Internet about the impact of unique IDs relation join performance, but I couldn’t find anything conclusive.

URLs are uglier.

So give client-generated IDs a try if you’ve got a good use case. It can go a long way to making a user experience less dependent on a round trip to the server.

#ember data #Ember.js

Trending Blogs

Recently Viewed Blogs

Gaslight