During development of the Mumboe Contract Management product we have created and modified several open source Ruby gems and Rails plug-ins. While that code has been on GitHub, it has been managed under individual developer’s private accounts. We have now consolidated development under a single Mumboe account for all of our open source projects. The Mumboe GitHub user currently hosts our forks of:
- aasm Fork of the acts_as_state_machine (AASM) gem. The fork adds support for logging state changes in a DRY way.
- amatch Fork of the Approximate string matching gem. This fork incorporates Michal Granger’s Ruby 1.9 patch
- has_easy Easy access and creation of “has many” relationships for ActiveRecord models. Forked to fix some bugs around validation errors.
- param_protected A Rails plug-in that provides param_protected and param_accessible methods on controllers. This fork allows the use of a Proc for generating the action list in include/exclude from protection.
- soap4r Modified soap4r library to run on Ruby 1.9
June 24th, 2009
Author: ScottD
Small companies like us can’t perform a lot of usability studies or afford focus groups; we just don’t have the resources. So, we’re constantly asking ourselves, “How are we going to get in better touch with what our customers are doing and what they need to better manage their contracts?”
Among those with answers are our Business Development and Support folks. Turns out, they take pretty good notes when they talk with customers, both current and prospect. They readily shared the info they have, in the name of improving the user experience.
We’ve recently spent some time reading that info. It has immediately begun to refine our understanding of what’s important to our customers. We’re always looking to narrow the gap between the real world of working with contracts and what our perception of that is, and this is an excellent, resource-affordable way to do that.
June 12th, 2009
Author: wmeurer
Adobe Fireworks is my prototyping tool of choice, but it’s got a lot of problems. It crashes often when using custom symbol scripts, and gives no useful response. After working hours on projects, I often find Fireworks “quits unexpectedly” when opening a file or that it is “unable to drag and drop” when dragging a symbol from the Common Library. In this post, I’ll describe best practices to keep errors to a minimum.
(more…)
February 27th, 2009
Author: wmeurer
We just finished conducting a usability study of the administration (admin) area of the Mumboe application. The admin area includes features like adding users, upgrading, and customizing agreement types and agreement fields. We tested 6 participants and got a lot of great feedback and results.
The most pertinent finding was low discoverability for admin features. Participants were largely successful completing tasks but had difficulty finding where they needed to go to get to admin features. Improving discoverability of admin features will require a combination of solutions, but one method we have used to begin this effort is observing the paths our participants took looking for these admin features.
A professor of mine at the UT Austin School of Information told me a story of a university planning committee that needed sidewalks put in a new area of campus, but the committee didn’t know where best to put those sidewalks. They decided not to create the paths for the students, but rather wait and see where students wore paths into the grass and then build the sidewalks there.
Likewise, we watched multiple participants going down the same fruitless paths, looking on the same pages, trying to find features they needed to complete the tasks. Taking into account potential biases and considering related use cases, these observations helped us identify places in the application where crosslinking to admin tasks could very well improve admin feature discovery.
We’re working on sweeping changes in the user interface in the coming months, during which we plan to implement these and other usability enhancements.
October 31st, 2008
Author: wmeurer
I was tasked with incorporating our system with a 3rd party credit card processing company called Lecayla. Initially this was written using PHP which was extremely easy, but now I needed to do it with Ruby. Lecayla had examples written in PHP but it seemed that no one was using Ruby. This created all kinds of issues all of them dealing with Soap4r. Hopefully this will help some people out there using Lecayla and Ruby and other people who are fighting with getting Ruby and Soap to work together.
- Documentation (or lack there of)
Soap4r is an implementation of Soap 1.1 for Ruby. One of the major problems is the complete lack of documentation. There are documentation entries for all the various classes but there isn’t any sort of explanation as to what does what. The only real way to figure all this stuff out is to use google and search other forums.
Soap isn’t very speedy and neither is Ruby. Soap4r doesn’t support caching of the wsdl and xsd files so every time you initialize the driver it will go out and get a new copy of the wsdl. This slows down the system tremendously. I implemented a really basic caching check into my class that solved this problem. I think this should be a part of Soap4r but it isn’t.
t_wsdl = 'config/lecayla.wsdl'
if (! FileTest.exists?('config/lecayla.wsdl')) || (! FileTest.exists?('config/lecayla.xsd'))
File.open('config/lecayla.wsdl', 'w') do |f|
f.write(Net::HTTP.get(URI.parse(billing.wsdl)))
end
File.open('config/lecayla.xsd', 'w') do |f|
f.write(Net::HTTP.get(URI.parse(billing.xsd)))
end
end
This will store the wsdl and xsd files in your config directory for use in your driver setup. If you don’t cache them in some form you will have a huge speed hit.
- Multiple ports in the same wsdl file
In PHP soap you just tell php to use the wsdl and everything just works. It doesn’t matter if the calls you are making are designated within different ports or not. PHP just does its thing and you do yours. With Soap4r it isn’t quite as simple. For Lecayla there are 3 different ports in their wsdl file, ContractHttpPort, MeteringHttpPort, and SSOHttpPort. In your initialization of your class you need to specifically setup each one. I did this:
@contractDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'ContractHttpPort')
@meteringDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'MeteringHttpPort')
@ssoDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'SSOHttpPort')
Now in your class if you for example want to add a user you simply do
@meteringDriver.registerUser(params)
This is another reason to cache your wsdl, otherwise for each of these it would go out and get the wsdl. You can guess as to how long just this process took.
For Lecayla the structure of your hashes can be complex for the calls that you need to make, and it isn’t completely clear as to what the format should be for some of them. In PHP this was easy because they provided a sample and it was quick to get it up and running. In Ruby this took a little work figuring out. Soap4r contains a script called wsdl2ruby.rb that takes a wsdl file and outputs a driver file and a script that you can use to test based upon the xsd and wsdl that you give it. I found it a lot easier though to just read the wsdl and xsd files myself. The code generated by wsdl2ruby seemed to be extreme overkill for what I wanted. With some help from the Soap4r maintainer and some sorting out by myself. Here are some of the structure formats.
Also make sure you wrap your calls in begin blocks so you can catch any exceptions that come across. The Lecayla documentation on their web site for developers is extremely helpful for what you will get in return and what the errors mean.
Thats about it. The above should be enough to get you started really quickly with implementing Lecayla in your system. Hopefully this is also some help to those folks out there that have been given a wsdl and don’t know what to do with it in Ruby. There is a Google group for Soap4r that I found useful for asking questions. The maintainer of it actually answers questions which is a lot better than what some other maintainers of Ruby projects do.
December 7th, 2007
Author: Mike Alletto
Before we moved from our own internally developed PHP framework to using Ruby on Rails, I had written a database migration library that mimics Rail’s with two key differences:
- It allowed for retroactive running of migrations with versions at or below the current database version.
- It allowed a developer to force run a migration, even if that migration had already been run before.
Point one solves the problem where you have multiple developers sharing the same development database and all writing migrations at the same time. For instance, you create a migration 002_blah, but before you run it and check it in, another developer created, ran and checked in migration 002_bleck. By default in Rail’s, your 002_blah migration will never be run because the database is already on version 002. My library instead says “ok, I’m on version 002, but lets see if there any new migrations at or below that version that have not been run yet.”
Point two is dangerous and indeed has lead our database to get all mucked up more than a few times, but hey, it’s a feature no one is forcing you to use. The “force run” feature lets you run a migration (either up or down) even if it has already been run before. This feature is nice for when you realize you made a mistake in an already run migration and instead of making a new migration, you just want to edit and fix the existing one. You “force down” it, edit/fix it, then “force up” it.
I made a plugin for Rails called Retroactive Migrations (r_migrations) that implements this behavior. For installation and documentation, please see my personal blog post about it.
October 22nd, 2007
Author: Christopher Bottaro
FineTooth will be at the AMIA 2006 Symposium for a poster presentation with the Fred Hutchinson Cancer Research Center. The presentation is on the use of our automated text extraction service to build a cancer tumor registry from pathology reports. The poster presentation is part of S13 Poster Session 1. If you are going to AMIA this year stop by and say hi. If you can’t make it here is a link to a PDF of the poster. Please note the real poster is 4 feet high and 8 feet wide, so the file is large.
November 8th, 2006
Author: ScottD
We are in the hunt for another UI developer for our contract management web application. If you are in the market or know someone who is, shoot them the job info. Here is a repost of the information from our corporate site:
Senior UI Developer
FineTooth is currently seeking a Senior UI Developer to join our team and contribute to the front end development of our web based, scalable, on demand applications. Working together with a small team of web and database developers in an agile environment, the Senior UI Developer will have the opportunity to develop and gain experience in a fun, fast-paced, and flexible environment.
Qualifications:
- 4+ years experience in UI development, preferably with scalable production web applications
- Strong experience with HTML, CSS, JavaScript and AJAX programming patterns
- Experience with PHP and XML
- Familiarity with graphic design and associated tools including Photoshop and Illustrator
- Good sense of usability in graphical UI design running on real time systems
- Ability to work both independently and as a member of a small team
- Desire to work in a fast-paced, fun, and flexible environment with great benefits, developing cutting edge technologies
- Undergraduate degree or equivalent years of industry work experience
Applicants are encouraged to provide examples of past UI development work or sample applications that demonstrate UI and software engineering skills.
For immediate consideration, please send a word doc resume to careers@finetooth.com with “Senior UI Developer” in the subject line.
November 6th, 2006
Author: ScottD
Last week was the second face-to-face meeting of the OpenAjax Alliance membership, fresh on the heels of the AJAXWorld conference in Santa Clara, CA. The meeting was two-days long, with day one focused on a mix of show-and-tell, group breakout discussions, and objective proposals. Day two focussed on the future of Ajax and mobile development. The result is that the group has solidified plans to produce an event and markup scanner component for developers to help ensure framework and code compatibility as well as toolkit interoperability - i.e. say you want to use a MooTools Accordion and a Dojo Fisheye together somehow. That might actually be perverse, but anyhow you get the drift. California was beautiful and Sun has a great layout and cafeteria. The Chinese Steamed Fish was superb!
October 14th, 2006
Author: Lindsey Simon
Despite a close call where the original venue pulled out at the last minute, BarCampTexas took place without a hitch at Club Elysium in Austin, TX. The goth bar scene + noon o’clock beer + many caffeinate barcampers was both fun and educational. I heard presentations on search engine optimization, programming in Cocoa, better ways at describing user interface interactions in Visio, and some unique ways to fund ideas. I even took a crack at my presentation on the XSLDataGrid. All in all, it was cozy, initimate, and the spirit of bar camp was in full effect. We attendants are forever in debt to the hard work that Lynn Bender, Whurley, Erica, and Wordlife Productions put in to set up such an awesome un-conference.
August 27th, 2006
Author: Lindsey Simon
Previous Posts
