Gaslight

Video

cdmwebs — Tue, 21 May 2013 20:43:37 -0400

My QCMerge-Inspired Todo List

nockitoff — Mon, 20 May 2013 13:47:00 -0400

“It’s not what you know. It’s what you do that defines you.” - Todd Henry, speaker at QC Merge 2013

Whenever I travel somewhere new, I make a list of three things I want to do or experience while there. Even though I live in Cincinnati, I technically “traveled” downtown and stayed in the 21c Hotel there (a first, therefore new) and so here was my list of three things before attending QC Merge:

1. Reclaim joy and freedom by leaving the confines of my office.

2. Gain some professional and personal motivation.

3. Have an interesting conversation with someone I don’t know.

With this in mind, I merged in our Queen City for the first time last week. Because there are few things I love more than being dramatic and making lists, I’m combining the two below to share a little bit of my QC Merge experience. You will note the list ranges from UX to death. Enjoy.

Photo by Thadd Fiala

Five things on my to-do list after attending Queen City Merge

1. Create more.

I’m an awesome producer at my day job, but when it comes to the projects I really want to do (i.e. actually launch socialbusinesstoday.org) it always seems to come last in the long list of stuff to do in life. After hearing advice at QC Merge on topics like how to pitch stories, create a good UX, and fight creative block - I’m moving creating stuff I care about closer to the top of the list.

2. Email Sara Morgan.

Sara Morgan rocks. Her energy is amazing, her advice was grounded and real. I loved her tips on pitching stories, creating a brand voice, designing for emotion, and the importance of being persistent (and by persistent I’m pretty sure she meant annoying - which was really great news for me). Also, Sara can curse like a sailor in a somewhat southern accent which makes her sound like a bad-ass-southern-belle.

Plus, from what I could tell, Sara is a dream chaser - and I’m always looking for inspiring people to share their dreams as part of our Dream Chasers campaign.

3. Do more of my part in Cincinnati.

I admire what Gaslight and the people behind QC Merge are doing in our city. I should do more to see who I can help in Cincinnati with branding and communication strategy and implementation.

4. Conduct UX research internally.

Probably the most practical takeaway for me was the workshop by Jessica Ivins on user experience. My day job is working at a university on a marketing team with a limited budget and little to no time for external research. Jessica opened my eyes to the possibility of doing user research internally through the Affinity Diagram (disclosure: Affinity Diagram is a fancy term for brainstorming - love it). I love the idea of getting together with our IT, web developers, marketing and recruitment teams to brainstorm our users (students) experience both on our website as well as on campus in the building.

5. Die empty.

Todd Henry, who wrote Accidental Creative was the most inspiring talk for me. I keep recounting in my head the story Todd shared on how graveyards are the most valuable pieces of lands on earth - because this is where great ideas that were never executed are buried. Such a great point, and I made a silent pledge not to take my great ideas with me when I go!

Laurel Nock

Finding your brand’s voice and building a community with...

cdmwebs — Sat, 18 May 2013 01:43:21 -0400

Finding your brand’s voice and building a community with strategic (but genuine) marketing, public relations, and social media efforts can seem overwhelming, but it doesn’t have to be! As a founder of couple of startups and now a PR firm created for an entrepreneur, by an entrepreneur, Sara is bringing her experience to QCMerge to talk about building a company from the ground up by securing press placements, engaging in social media, and keeping an honest and consistent voice across all mediums.

Greg talks about the revitalization of Cincinnati’s...

cdmwebs — Sat, 18 May 2013 01:43:19 -0400

Greg talks about the revitalization of Cincinnati’s brewing heritage and how his Christian Moerlein Brewing Company has taken a leadership position in bringing back a city’s brewing culture. He will explore the Brewery District’s strategic master plan and how it will create a new energy for the city and be an economic driver through heritage tourism.

Building custom applications is hard, expensive, and risky; but...

cdmwebs — Sat, 18 May 2013 00:13:23 -0400

Building custom applications is hard, expensive, and risky; but it’s the custom code that differentiates our businesses. How can we mitigate the risk and get the most of the money we spend on development? Very few projects fail because of technology problems. The number one success criteria for a project is the level of engagement between stakeholders and the development team. This talk explores that relationship. We’ll talk about ways to evaluate your relationships and techniques to improve them. By the end of the presentation you should have a better understanding of what highly effective teams look like and how to engage with them.

Chris Glass is a designer at Wire & Twine. A Cincinnati...

cdmwebs — Fri, 17 May 2013 22:43:37 -0400

Chris Glass is a designer at Wire & Twine. A Cincinnati native, his work blends visual design, identity development, user-interface, photography, motion and from time to time, t-shirts. He has worked with organizations throughout the area and beyond in his 19 years, helping visualize ideas, sites, applications and products for Artworks, Adobe, The Breeders, Cincinnati Opera, Cincinnati Parks, The National Outdoor Leadership School, The Smithsonian, Sun Microsystems, Spark People, Sprint, Tattly and the U.S. Government.

Video

cdmwebs — Fri, 17 May 2013 21:43:48 -0400

Is how you work getting in the way of great work? Kevin Comer...

cdmwebs — Fri, 17 May 2013 19:58:25 -0400

Is how you work getting in the way of great work? Kevin Comer and Rob Sloan will show how Ample has evolved their process to create higher efficiency, better results and a more cohesive team effort.

Mark Treas

cdmwebs — Fri, 17 May 2013 19:58:24 -0400

Mark Treas

cdmwebs — Fri, 17 May 2013 18:43:45 -0400

Mark Treas

How can each individual within the Cincinnati area startup...

cdmwebs — Fri, 17 May 2013 18:13:50 -0400

How can each individual within the Cincinnati area startup community help make it better? Based on experience building communities around geographies, interests, products, and companies, Tim will provide QC Merge attendees with tangible takeaways to guide each person’s contribution to a more awesome community for all.

Nate Westheimer is an entrepreneur, analyst, and social web...

cdmwebs — Fri, 17 May 2013 14:43:34 -0400

Nate Westheimer is an entrepreneur, analyst, and social web expert. With experience ranging from leading groundbreaking startups to advising top national media brands on distribution and monetization strategy, Nate has command over the cutting edge and actively deploys his expertise in a wide range of startups and initiatives. Beyond the startup, Nate is also known as a leader in the New York technology community. He is the Executive Director of the area’s largest and most important industry group — the NY Tech Meetup — and represents the industry to government as well as corporate interests.

Announcing the CWT Study Group!

jturnbull — Fri, 10 May 2013 14:03:20 -0400

We all benefit from a healthy and vibrant tech community in Cincinnati. My biggest takeaway from @timfalls’ talk yesterday at QCMerge was this: If you want to promote and nurture an awesome tech community in your city, you have to be willing to give before you receive.

With this mission in mind, Gaslight’s Chris Nelson has just announced the Cincinnati Web Tech (CWT) Study Group! The course follows an actual Stanford class (CS142), and gives students the opportunity, weekly, to learn with one of the best developers and trainers in Cincinnati. Students will learn:

HTML
CSS
Javascript
Ruby
Ruby on Rails
SQL Databases
Security

If you’re not a web developer but you want to learn, there couldn’t be a better opportunity, at a negligible cost. Sign up here!

Horsemask and didgeridoo. What more in life could you want?

jturnbull — Wed, 08 May 2013 15:57:44 -0400

Horsemask and didgeridoo. What more in life could you want?

Beautiful code needs a beautiful interface. Ok not necessarily...

cdmwebs — Wed, 08 May 2013 12:58:15 -0400

Beautiful code needs a beautiful interface. Ok not necessarily beautiful, but at least usable. I’ll offer some quick tips on type, color, grid, hierarchy, and other elements to help your project be successful. Kristin Lasita is a designer at Gaslight. Born in Cincinnati, trained in print design, and now a craftswoman of HTML, Kristin is on the trail of finding the best way integrate development and design. You can find her stylish self in a hip bar you probably haven’t heard of with her favorite companion, Ellie the dog.

We packed the room with Gaslighters this week to talk about an...

mitchlloyd — Thu, 25 Apr 2013 07:40:00 -0400

We packed the room with Gaslighters this week to talk about an upcoming conference called QCMerge. We discus the origins of the conference and some of the exciting things in store for this year.

RubyMotion is a revolutionary toolchain for iOS. It lets you...

cdmwebs — Fri, 19 Apr 2013 17:05:40 -0400

RubyMotion is a revolutionary toolchain for iOS. It lets you quickly develop and test native iOS applications for iPhone or iPad, all using the awesome Ruby language you know and love.

http://www.rubymotion.com

Bio:

Jim Weirich first learned about computers when his college adviser suggested he take a computer science course: “It will be useful, and you might enjoy it.” With those prophetic words, Jim has been developing now for over 25 years, working with everything from crunching rocket launch data on supercomputers to wiring up servos and LEDs on micro-controllers. Currently he loves working in Ruby and Rails as the Chief Scientist at neo, but you can also find him strumming on his ukulele as time permits.

enjoythearts: Check out Enjoy the Arts’ brand new website -...

cdmwebs — Fri, 19 Apr 2013 11:46:17 -0400

enjoythearts:

Check out Enjoy the Arts’ brand new website - complete with an inclusive calendar of #cincyarts events and an easy-to-use membership sign-up!

This project was lots of fun and we’re really excited about growing the local arts community. Thanks for the opportunity!

How we Cuke

jturnbull — Thu, 18 Apr 2013 10:02:00 -0400

Two styles of step writing in Gherkin sparked a discussion about Cucumber practices here in the office. @mguterl has been doing a lot of research, reflection, and has been taking a lot of good notes from The Cucumber Book. We this in mind, we recently sat down as a group to attempt to define some Gaslight specific Cucumber conventions and best practices.

Here are examples of the two styles that sparked the discussion:

Scenario: User has questions
      Given I belong to a group "Sales Reps"
      And the group "Sales Reps" has a question
      When I login
      Then I should be prompted with the question for "Sales Reps"

and

Scenario: User has questions
      Given I belong to a group with a question
      When I login
      Then I should be prompted with the question

The assumption is that each style better serves a certain contingent. The first contingent being developers of the system. The other being the non-technical clients or owners of the system.

The second example is customer facing. It’s in plain english. It’s easy to read and reason about. However it prohibits reuse, and the steps cannot exist in isolation. Implementers will need to introduce instance variables in order to tie together the Given and Then steps. As a developer this is hard, our tendency is eliminate coupling and always promote code reuse.

It follows from software design practice that steps written in this way create more work for the developer. However, I the more I think about this, the more I start to disagree.

Why are we doing this?

The goal of any kind of acceptance testing should be to keep stake-holders engaged with the project. It’s a way for non-technical people to communicate the functionality of the system in a practical way. It creates a document that describes exactly what the system should do, and simultaneously verifies that it does it.

Stake-holder involvement is the most important factor in a software project’s success. Therefore, every effort should be make to write Gherkin in a way that communicates with the stake-holder and keeps them engaged. Don’t bore the stakeholders!

If there were no benefit to be gained from stake-holder involvement, there would be absolutely no need for native Ruby speakers to write anything but RSpec. The whole idea of acceptance testing, and the tools that are built around it, exist to create this beneficial relationship. It only makes sense to optimize that aspect.

Besides, is writing more step definitions really so painful to a developer? Is it more painful than having a client who is unhappy or unable and unwilling to communicate?

What are we communicating?

The other problem with the first example is that it doesn’t really communicate to either contingent, especially if they are coming into the project cold. “Sales Rep” is an implication. As such, there is another mental step to take there. What does the role “Sales Rep” represent? Oh yeah, a role that provokes a question on login. So just say that.

The tendency to write steps in the way of the first example is a result of trying test too much through the UI. @too_mitch gave the example of a signup form with many required fields, each doing a validation that will prevent the signup and display some kind of message. E.g. “Name is invalid”, “Email is invalid”, “Username is invalid”. The tendency is to write a step like:

I fill in "email" with "invalid_email_address"

And then to reuse this step for each required field. However, this proliferation of scenarios is going to simultaneously bore the consumer of the feature, and slow down your test suite. The correct place to test these validations is in RSpec unit tests. In Cucumber we should write:

I fill in the form with invalid data

Test that. Validate that a message appears, sign in is prohibited, and move on!

Another way to quickly bore and confuse Gherkin consumers? Insert unnecessary incidental details into a step definition. If we are testing authentication we might write things like:

When I log in as "dave@gmail.com" with password "l0ck3d!"

Because that’s the data the login form accepts. But does it matter? Compare to this:

When I log in as "dave@gmail.com"

Clarity is important. See how many incidental details can be removed, while retaining the scenario’s meaning. Is it important who we are? Are we testing anything about Dave specifically? How about this:

When I log in

Every effort should be made to pare down steps. When in doubt go with plain English. Get the scenario itself down the the magic number of three steps, i.e. “Given”, “When”, “Then”. Even the “Given” step can be extraneous. Eliminate the incidental!

Where should the programming be done?

@mguterl likened a step definition to an programming interface. We only need to have an idea of what the step does, we don’t care about the implementation ( how it is done ). But, because steps can act like functions that pull and apply parameters, the trap is often to move logic into them, and to use them like methods.

Cucumber is not a programming language. At every point the tendency should be to move logic and variables into the implementation and out of the steps themselves. Even the first scenario example introduces coupling between steps, it just does it on the Gherkin side instead of the Ruby side. Even though Cucumber supports it, do not call steps from steps in the implementation, call Ruby methods from steps.

In Cucumber, a developer should resist the temptation to always reuse. Don’t always sift through the step definition files to locate the existing step that already does the thing you are trying to do. One should write the step with the language that makes sense for the scenario.

On the other hand don’t fall into this trap:

When I sign in
When I login
When I authenticate

This is bad. You still need to work towards ubiquitous language. There is no increase of communication or context that rationalizes three different steps for the same login action.

It’s a balance thing. Remember, programming concepts are not our first priority here. The first priority with Cucumber is communication. Sometimes there are better ways to communicate the same functionality, depending on the context. In these cases, it’s best to avoid shoehorning the language of an existing step into a feature, just for the sake of re-use.

Is there a good way to organize step definitions?

Because you’re dealing with a big mess of globally applicable step definitions, it can be painful to locate any one implementation. Grepping seemed to be my goto method for locating step definitions, but I just verified that ctags in vim does the trick quite nicely. Still, it’s never clear exactly how to organize steps and features, or where to find them when you come onto a project.

If there’s a Gaslight convention, it’s to organize step definitions by domain object or concept, and features by user role. In this way, it’s easier to answer the question “what are the things this user can do”?

What else?

Our favorite new pattern here at Gaslight is the Page Object. Page Objects are a way to in step implementations to encapsulate step code into classes that provide an interface for creating test objects and interacting with the UI. The results are vastly simplified step definitions and better code organization.

Page Objects are probably a topic that warrant their own blog post. Until then I invite you to read up on them here.

Conclusion

Working with Cucumber and writing Gherkin are skills unto themselves, with best practices that can seem antithetical to those that define good software engineering. That is because the real goal of these tools is not testing. Cucumber and Gherkin are about communication and stakeholder engagement, and should be implemented with those goals in mind, first and foremost.

Training Resources for Folks Getting Started on the Web

dougalcorn — Tue, 16 Apr 2013 12:14:00 -0400

From time to time I get asked about resources available to help a self-starter learn more about web development. We try to foster a culture of learning here at Gaslight. As such, we’re continually looking at new stuff. This is the short list of what we like. If there is something missing, let me know and I’ll take a look at it.

code school

Overall, I really like these guys. I think they got their start with the “Rails for Zombies” course. My impression is they are stronger on the Ruby/Rails side than they are on other languages and frameworks. The cost is very reasonable: $25/mo for unlimited access to all their content. The material is all available in the browser and does not require any setup on your local machine. They focus on “gamification” by providing challenges to “unlock” the next level and badges.

Codecademy

This is another broad-spectrum in-browser curriculum. I think they started with more with Javascript and filled in Ruby and PHP later. Right now they are funded and don’t charge for their curriculum. It’s not clear to me how they make money. They also provide ways for the open community to submit content for the curriculum. This shows in some places as the content isn’t always as polished as code school’s.

Girl Develop It

I really like GDI. This is in person training at a nominal cost. I think they also have a scholarship program for those who need it. Their goal is to help people get into development who might struggle in other environments. They focus on the basics in a welcoming community setting. If you’re not sure about development, this would be an excellent place to start. It’s a great way to meet people who are in your same situation trying to learn technology from scratch. The community aspect of it can’t be overstated. Even though “girl” is in the name, they welcome us guys too. I think I heard something like 25% of the students are male.

Other specific resources

These resources are a little more focused and a little more advanced. After having worked through some of the stuff above, you might be left wondering where to go next.

User Groups. This is the number one resource for continuing your education. Get plugged into your local community. Here in Cinci we have all kinds of good user groups.
Git Immersion - An excellent intro to git source control written by our local friends at neo.
Ruby Koans - A deep dive look at Ruby using an innovative fill-in-the-blank style test driven approach; also by neo.
Shay Howe’s Beginning and Advanced Guides to HTML & CSS. This curriculum was developed as part of The Starter League.
Greg Smith and Isaac Durazo of Bocoup have written a follow-on guide to Shay’s called Learn CSS Layout. This more about the building blocks of laying out a site rather than the details of HTML and CSS.
For a different approach, Gregory Brown’s Practicing Ruby is a great resource at a quite low cost.
Geoffrey Grosenbach (@topfunky) started peepcode. These are inexpensive screen casts on specific technologies. Most of them are more programmer oriented than design. I’ve enjoyed many of these.
A great resource is Rails Casts and the corresponding ASCII Casts. These are obviously geared towards Rails. They cover very specific topics like authentication or asset pipeline. The ASCII version is a transcript of the screen cast.
I feel I should mention Destroy All Software which bills itself as “screencasts for serious developers.” There’s no doubt Gary is a fantastic developer. He covers some fascinating topics and shows some great principles. I feel I should also mention a word of caution. His style of development is somewhat hard to adopt and also somewhat controversial.