Techlahoma - Multiple Authentications (Part 2)
In the last episode we started to implement the feature to allow a user to connect multiple social profiles to their Techlahoma account. Today we’ll finish that feature.
In the last episode we started to implement the feature to allow a user to connect multiple social profiles to their Techlahoma account. Today we’ll finish that feature.
For Techlahoma we’ve decided that we want to allow a user to connect multiple social profiles to a single account. In this installment we’ll look at writing some feature scenarios that describe the functionality that we need, and then we’ll fill out the step definitions needed to turn those scenarios into fully executable tests.
In previous posts we looked at creating the Techlahoma app and writing a few Cucumber feature scenarios, writing the first step definitions to make the Cucumber scenarios pass, and integrating OmniAuth to allow us to delegate authentication to 3rd parties like GitHub and Twitter. Today I’m going to set up my local environment with GitHub and Twitter integrations to complete the user sign in experience.
In the last post we created step definitions for the first part of a sign in scenario, and we got as far as adding a dead "Sign In" link to the page. Now we're ready to actually build the sign in system. We've decided that we do not want to be storing passwords in our system, instead we'll depend on 3rd party authentication providers, namely GitHub and Twitter to start.
Today I'm going to document the process of building the first step definitions for Techlahoma. This will turn the Cucumber stories that we built in part 1 into runnable test scenarios.
Rob Sullivan and Amanda Harlin have been kicking around ideas for something called Techlahoma and they recently asked me to get involved to help. We decided early on that the app would be a Rails project, and I suggested that we use Cucumber to describe the main user features that we hope to build. In the early stages these stories will act as our design document, allowing us to formally capture the description of the features that will be available to end users. These documents will live in the project repo, and will be just like any other code/text file. We'll be able to track the history of feature descriptions, make drastic changes to them without fear of losing previous work, use pull requests to initiate discussion about new features, and all of the other great benefits that you get with git and GitHub.
Today I gave a short presentation at OkcRuby called "Background SmackDown : Resque vs. Sidekiq" in which I examine some differences in basic performance patterns of the two projects with jobs of various types. Then I show some ways that you can minimize those differences. Here are the slides for the talk.
Today I was honored to be a speaker at the Thunder Plains Developer Conference. The original title of the talk was "Service Oriented Architecture for Singe Page Apps", but after getting started working on it I decided to go with "Stumbling Towards SOA - The Story of CloudHDR" Here are the slides for my presentation.
Octopress and Github Pages work great together to host a small site in a way that feels very developer friendly. The documentation for Initial Setup and Deploying to Github Pages do a great job of walking through the process of getting started. However, there’s not much documentation to be found about working with collaborators, or setting up development on a shiny new machine.
Last week I gave a short presentation at OkcRuby called "JSON all the things! The Wrong Way, The Rails Way, The RABL Way". Here are the slides for the talk.
Earlier today I gave a talk at OkcJs entitled “Intro to Ember”. Here are the slides from my presentation.
Later this afternoon I'll be giving a lightning talk at RailsConf about my projects GemLou.pe and Easymarklet. Here are the slides that I'll be using.
GemLou.pe is a new project of mine designed to allow Ruby developers to see the dependency tree of gems before adding a new gem to their Gemfile. It uses a bookmarklet to allow easy inpection while browsing rubygems.org. If you click the bookmarklet...
Tomorrow I'll be giving a lightning talk at OKS.js about the many JavaScript libraries that I used in construction of ThePhotoLabs.com. Here's a link to the slides that I'll be using.
Today I made a very small change to an app and then deployed it to Heroku. After the deploy was complete I visited the app and was presented with an error page. The error message in the logs let me know that application.css was not compiled, but I couldn’t figure out why. Here’s what I did to break my app, and what I did to track down the issue.
Heroku_san is a gem that helps streamline setup and deployment of apps on Heroku. Today I’m going to add heroku_san to the Foo vs. Baz project, and I’ll use it to create a staging site.
In this post we’ll look at using Cucumber to test the experience that users will have with our SimpleDB/Devise integration. Cucumber allows us to specify large grained features, or scenarios, that we want to test and to describe those scenarios in plain language. Then we can implement step definitions that turn our descriptive scenarios into executable functions to excercise the app.
I started this series nearly two weeks ago with a pretty solid understanding of both Devise and SimpleDB (via AWS::Record::Model in aws-sdk) as individual pieces. In the course of getting them to work together I’ve learned a lot about the internals of both projects (also ActiveModel and ActiveRecord), created three new gems, and had a few pull requests accepted into the aws-sdk gem. In this post I’m going to do some more refactoring of the ongoing SimpleDevise project to correct an early mis-step and to remove some methods that are now provided by aws-sdk.
Page 2 of 3
