10/07/2012

Ruby, SSL and Untrusted Certs

It has been a long time since focusing exclusively on writing Ruby code. So much fun.

The last two years have been groovy only which is a great language but there is something pure and simple about Ruby that just takes your breath away.

Enough of the emotional stuff, why, on earth, is it so hard to disable SSL cert trust verification. Such a common problem, google is full of Rails ActionMailer solutions but of coarse that doesn't help the rest of us.

Ruby 1.8.7

I approached the problem from Net:HTTP library makes it pretty easy. You just have to remember to require the correct classes and note that you are not disabling SSL just the trust verification part. # irb(main):001:0> require "net/https" # => true # irb(main):020:0> h = Net::HTTP.new("YOUR_SSL_SERVER",443) # => #<Net::HTTP YOUR_SSL_SERVER:443 open=false> # irb(main):021:0> h.use_ssl = true # => true # irb(main):022:0> h.verify_mode = OpenSSL::SSL::VERIFY_NONE # => 0 # irb(main):023:0> h.get("/") # => #<Net::HTTPOK 200 OK readbody=true>

My actual goal was to access a WSDL, over SSL, with an untrusted cert. This was not so easy. Took me about 5 hours to work out this solution. Expensive.

I used the Soap4R gem and since performance is not an issue I figured the dynamic proxy from the WSDL parsing would be the way to go:

factory = SOAP::WSDLDriverFactory.new("#{@url}?WSDL")

The problem was that there is no simple API to set the verify_mode of the connection so you have to root around in the code until you find where to monkey patch. This is what I came up with.

# # Monkey Patch HTTP Client # Sets SSL verify mode to NONE so that we can connect to an SSL server # that does not have a trusted certificate. # class HTTPAccess2::Client def initialize(*args) super(args[0], args[1]) @session_manager.ssl_config.verify_mode = OpenSSL::SSL::VERIFY_NONE end end

If someone has a cleaner solution I would love to hear it.

Ruby 1.9.3

Upgrading to 1.9.3 broke my Monkey Patch as expected so here is the updated one that handles both for the time being:

# # Monkey Patch HTTP Client # Sets SSL verify mode to NONE so that we can connect to an SSL server # that does not have a trusted certificate. # # The 1.8.7 patch adds a new constructor. # The 1.9.3 patch intercepts the existing constructor now that the class # name has changed. if RUBY_VERSION == "1.8.7" class HTTPAccess2::Client def initialize(*args) super(args[0], args[1]) @session_manager.ssl_config.verify_mode = OpenSSL::SSL::VERIFY_NONE #@session_manager.debug_dev = STDOUT end end else # > 1.8.7 class HTTPClient alias_method :original_initialize, :initialize def initialize(*args) original_initialize(args[0], args[1]) @session_manager.ssl_config.verify_mode = OpenSSL::SSL::VERIFY_NONE #@session_manager.debug_dev = STDOUT end end end

10/25/2010

Southwest Ohio Give Camp - Review

Ending with the demo of the charities new sites and the excitement on their faces as they looked up at the giant screen, was certainly the best thanks we could have received.


Moments.

Arriving back at the MUVOALC early Sunday morning to find volunteers outside banging on the doors and windows trying to get in. Six a.m. days are no match for these awesome people.

The 10 year old son of one of the volunteers asking how he can help. Dropping the xbox controller to rush off to notify the teams that more pizza had arrived.

The quiet that descended on the team rooms as everyone focused on doing their best work.

Team leads complaining that they don't want to wait 15 seconds for a standup to start because they have customers waiting.

Volunteers with decades of experience reveling in talking about what their young team members have been producing.

The worry expressed by people that working till 3am would not be enough and would the charity like what they have done.

Hearing the charities talking about "their developers", bringing then brownies and taking group photo shots.

10 Charities, 10 Solutions


Conclusion

As much as we were thanked for this one weekend, it is clear that the charities themselves have 51 others this year to do their work. These are the true champions of this weekend. It has been a privilege to get to know them and offer a small amount of assistance.

7/16/2010

Southwest Ohio Give Camp



On October 22 through 24th we are running a Give Camp located in Southwest Ohio. Collect your project manager and developer friends and we will connect you with a team to help out a Charity for one weekend. This is a great way to use my professional skills for a good cause.



We have an awesome group of volunteers putting the event together. We are organized into 6 teams to ensure we have a focus on the various areas that have to be worked on.

The Charity team focuses on identifying Charities, collecting the details about what they need. Our goal was to support 10 charities and we already have 20 submitted proposals. This team is comprised of Andy Erickson (@axerickson), Eric Schwartz (@SchwartzE), Darrell Hulshult (@dhulshult) and Andy Douglas (@GoodPiper) all doing an amazing job pulling together all these organizations to coordinate so many successful projects. Just imagine the problem of running 10 projects simultaneously in one weekend.

The Developer team focuses on setting up the website and attracting all the tallent that will work on the Charities products. With a goal of 50 people, to give us 5 person teams for each Charity, we are now at 37 with 3 months to go. With this kind of ramp-up we may have to consider expanding our goals. This team is made up of Ernie Stormann (@EStormann), Jennifer Griffin (@jengriff), Bill Barnett (@agilous) and Matt Brewer (@MattBrewer).

The Facilities team is responsible for finding the location for the event and managing the setup and orchestration of the event over the weekend. This is a mammoth task, to plan, find and acquire food for everyone, to manage the registration and leading of people to their work environments, and ensuring that everyone is getting everything they need. The idea of 100 people descending on a single location for two days is going to be quite an experience. Fortunately, the team is incredible, made up of Ryan Cromwell (@cromwellryan), Matt Brewer (@MattBrewer) and Sandi Sumerfield. They found a fabulous facility in the Miami University Voice of America location which has the most up-to-date and state-of-the-art video, network and teaching facilities I have ever seen. This building is basically being donated to us for this event because Miami University is so invested in helping the charities in this community.



The Finance team is just me but I am fortunate to have made contact with some great partners to help me through this process and so many generous sponsors. However, I am learning that the financing of charity events is much harder than for-profit events. It seems that the word Charity discourages companies from sponsoring it. If anyone is interested in donating please let me know.



The Marketing team is a combination of people from all teams since each team has requirements to reach the people they need to reach. I just manage it but everyone contributes what they need. Andrea N. Brady from The Marketing Shop Consultants has been a great help, donating her time to craft articles for publishing.

The process for putting this together starts with lots of enthusiastic smiles and then you start to realize all the details that are involved. The key to success rests on the team you choose. it's the Charities that need to win, not us.

4/15/2010

Cincinnati Day of Agile - Registration Opens Today

Registration opens TODAY at noon. Seating for this event is very limited and this event is going to quickly sell out. Do not wait - register today at http://cincydayofagile.eventbrite.com/.

What is Cincinnati Day of Agile?

As the Agile project management process sweeps across the software industry, businesses not understanding the details are being left behind. The Cincinnati Day of Agile is an opportunity to understand what Agile is all about and hear from people that have used it, succeeded with it and have the results to prove it.

At this one day event on Saturday, May 15th, a host of industry experts will be on hand to offer their hard won experiences. By bringing together a mix of developers, managers, Agile professionals, and technologists, the Cincinnati Day of Agile also provides excellent networking opportunities for its attendees. We hope you will join us to learn how Agile can make your software development process more effective, productive, and profitable.

More about the event can be found at http://cincydayofagile.org/.

12/06/2009

Kanban - A small practice project

A few months ago I completed my first Kanban project. The team was small and the introduction informal but it went well.



Background

The team comprised 5 people. A technical manager, 3 web developers and me. They managed many projects simultaneously which resulted in a great deal of task switching for the developers.

There were no detailed plans and few team planning sessions. The technical manager was able to keep track of the teams goals on the fly. As tasks and priorities changed, the team would be notified.

Three of the team members had experienced a full agile project in the past which resulted in the team continuing daily stand-up meetings. They stated that they wanted to continue using TDD but that hadn't persisted as strongly. While one of the developers had used TDD in the past, they did not use it consistently, and the rest of the team did not have any training on the technique.

Project

The project was estimated at 2 weeks and involved a UI replacement of an existing web application. A couple of minor business flows were going to change but essentially it was just large segments of the site getting new HTML/CSS. All HTML/CSS was developed by a 3rd Party design company so the in-house work was limited to verifying what was delivered and implementing the designs.

Process

We started with a little presentation on what Kanban is. Ran through some examples of how a project might be run with a focus on software projects. The whole team was in attendance along with a couple from other teams and a Director.

Feedback seemed good with statements like "We need something like this" and "I wish we could get all teams to do this".

From there we got the team together to chunk up the tasks and played Planning Poker to come up with some high level estimates on how long it would take. Each task was written on a post-it note and stuck on a white board in the left hand column ready to be pulled forward into the work in progress.

The columns we started with were:

o Backlog
o Work in progress
o QA
o Complete

Even though "everything had to be done" it was agreed that some were more important than others so a loose prioritization scheme was devised that ensured that the correct post-its were pulled forward first. The manager took on the role of adding priorities to post-its in the Backlog column when needed.

Results

Team members initially needed some encouragement to move the post-its on their own. This soon past as they were offered the opportunity to take control of the work they were going to do.

By the end of the first day we had blocked tasks. We started adding red stickies to the post-its but eventually moved them to a new blocked column between the Backlog and Work in Progress columns.

When asked, the team said they liked the process because it helped them see what was needed and completed.

A great indicator of the teams investment was the exclaimation "Wow, look how much we have got done" as they looked at the completed column full of post-its.

Since the team was switched to and from other projects the estimated two weeks was not an elapsed time but the project was released before the business needed it.

Comparison with Agile

We did take the time to estimate the stories which wouldn't necessarily be part of a Kanban project. However, there was concern about the completion time which needed some up front guestimates to allow the team size to be predicted.

Beyond release estimating, no time was spent planning what tasks should be worked in the first iteration. While it was only a two week project, in a Scrum or XP project we might have tried for 2 one week iterations. Not doing this did save us a little time and since the Kanban board continued to show tasks getting completed there was always a clear understanding that things that were getting completed.

Additionally, without iterations we didn't ever ask ourselves about what to do if we had not finished the estimated work in the iteration. Instead we maintained the column constraints and monitored how long items stayed there.

If this team ran all their projects using Kanban, the lack of planned iterations might allow some projects too fall through the net. This can be handled with simple organizational changes so shouldn't be a risk.