The banking industry can – and must – do better as it relates to securely enabling limited access to third-parties on behalf of their customers. Account aggregators like Yodlee and Intuit – and the myriad of other products built on top of Yodlee and Intuit aggregation services – rely on customers sharing their account credentials for the service to work. Banks know this and in many cases are active participants in enabling the services provided by account aggregators. And yet, this very fact contradicts many bank’s security recommendations and, in some cases, their own terms and conditions. For example, one of the top 5 U.S. banks has the following their terms and conditions for online banking:

You agree to … keep your passcode secure and strictly confidential, providing it only to authorized signers on your account…

Another top 5 bank’s terms and conditions state:

You agree that … in circumstances where locations of the Website require identification for process, you will establish commercially reasonable security procedures and controls to limit access to your password or other identifying information to authorized individuals.

How many of Mint’s more than 10 million customers are breaking these terms and conditions? Is it really reasonable for banks to expect that customers are abiding by these terms when they themselves enable customers to so easily violate them? How would an average consumer banking customer even know how to “establish commercially reasonable security procedures and controls”?

It’s no secret that non-traditional bank competitors like PayPal, Dwolla, and Square have taken aim at banks. Five years ago, it was difficult to have a serious conversation inside a bank about the possibility that PayPal would become a serious threat; now many bank executives accept it as a fact. One needs to look no further than the breakneck pace of growth by companies like Square to find evidence of the value that a non-traditional approach to banking products brings to the marketplace. Some bank executives will say that these new competitors have an unfair advantage because they are less regulated than “real” banks. While there is an element of truth to this, the regulatory playing field is becoming increasingly level in the United States every day. Other bankers will decry “legacy systems” or other IT-related causes that make the banks disadvantaged. Again, there is some truth to these claims, but neither technology nor regulatory constraints fully explain how the banks ended up playing defense against the fintech startups.

The reality is that most traditional banks have a much deeper and more fundamental impediment to innovate like their non-traditional competitors. Most of these legacy banking institutions are structurally and organizationally ill-prepared to bring to market products that are predominantly technology-centric. Many banks have been organized around “products” that are really services: checking accounts, cash management, credit cards, merchant accounts and the like. While there is certainly a technology component to these offerings, that technology has historically played a supporting role. Technical solutions – those that are primarily exposed or consumed using APIs or mobile applications – have not been the dominant feature of the products or services banks have offered; they’ve merely been an enabler.

The xml-mapping gem provides a very useful interface if you want to be able to easily marshal data between XML and native Ruby objects. It’s great at mapping XML to Ruby documents, but there is one potential catch when you want to marshal a Ruby object into XML: adding namespaces that may be required by the parser digesting that message. Luckily the gem provides an easy hook to fix this with the post_save method:

The post_save method is called after the xml-mapping gem has marshalled the source Ruby object into an REXML::Element object but before it is returned. Within this method you can manipulate the XML and insert the namespaces that are required for the message to be parsed correctly. One other gotcha is that setting the default namespace using REXML’s add_namespace did not work for me – instead you can set this namespace using add_attributes.

The foreigner gem is great for creating foreign key constraints with ActiveRecord. One potential problem arises when you want to destroy a record that is the foreign key in another model. In situations like this, it’s desirable to know before attempting calling the destroy method that the destroy will fail. (For example, to notify the user or avoid presenting a link for destroying the record.) This capability isn’t native in ActiveRecord but can be added with the following monkey patch:

With this patch you can just check if .can_destroy? is true before attempting the destroy or providing the user the option.

Good programs have a structure that anticipates - but is not overburdened by - the possible modifications that will be required in the future.

ActiveRecord migrations in Rails allow you to supply a default value for a column, but that default value has to be static. If you want to default the value to something like the current time, the migration won’t help you even though the underlying database can usually support it (e.g. using MySQL’s CURRENT_TIMESTAMP() function). So, if you want to simulate this in a Rails-y way, you need to use callback hooks in the ActiveRecord model. A friend asked me today if it would be better to use the after_initialize method or before_create callback to set a column value to the current time if the value was nil. While the results may be nearly identical in most common use cases, they are very different in terms of what they do under the hood. Code in after_initialize is executed after the object is instantiated whereas before_create callbacks are executed right before the record is created in the underlying database. In a scenario where you have code like:

1
2

my_new_record = SomeRecord.new( {:value1 => "something", :value2 => "something else"} )
my_new_record.save

… then there is really no practical difference between the two. (When .save is called from ActiveRecord::Base, it calls create_or_update, and create_or_update tests to see if it’s a new record. If it is, the create method is called so the before_create callback will be invoked even though .create wasn’t called expliticly.) The difference is more apparent when you have something like this:

1
2
3

my_new_record = SomeRecord.new( {:value1 => "something", :value2 => "something else"} )
# insert lots of really long running code here
my_new_record.save

In this scenario, if you used after_initialize to set a default value, and that default value is somehow time sensitive, then it will be set at a materially different time than using before_create. So, the bottom line is that if you want to approximate setting a default value using some kind of dynamic value/function in the database using ActiveRecord, before_create is your best choice.

One simple error during a merge conflict resolution last night cost me two hours of troubleshooting what I thought was a devise problem. During the process of resolving conflicts caused by a branch merge on one of my projects, I inadvertently left two devise routes for the same resource in routes.rb Something like:

Simple mistake. Result: anytime you tried to login as an admin, you’d get a “Invalid email or password” even thought the email and password were correct.

I started working with iUI recently and had a very long form (22+ “rows” of form input data) and noticed that if you tapped in an input field that was near the bottom of the screen, the page would automatically scroll to the top of the page. I started looking into the problem after not having much luck on my original Stack Overflow question on the subject I did a little digging. I found that in iUI.js there is a function called checkOrientAndLocation(). In this function, setOrientation() is being called when hasOrientationEvent hasn’t been set. After setting height/width/orientation, it makes a call to setOrientation which eventually calls a scrollTo(…) to scroll to the top of the page. As far as I can tell though, the scroll to the top of the page should not be necessary if the call to setOrientation() wasn’t triggered by a change in device orientation, as is the case with the timer that periodically calls checkOrientAndLocation(). In checkOrientAndLocation, if no change orientation event has occurred, a call ends up being made to setOrientation() which will cause the browser to scroll back to the top of the page.

If you want to be able to send a calendar invitation that works with Outlook (i.e. can be opened and “accepted” to be added to the user’s calendar) but is also readable as an email (or at least a valid calendar invitation) in non-Outlook email clients, there are a couple things you need to know:
1. The vCalendar record needs to be sent as an attachment with a content-type of “text/calendar; method=REQUEST”. If your mail library automatically encodes attachment (as Rails ActionMail does), you also need to force the encoding type to 8bit and NOT encode the text.
2. When creating the vCalendar text, you need to add two custom properties: The first is called METHOD with a value of PUBLISH. The second is X-MS-OLK-FORCEINSPECTOROPEN with a value of TRUE. These properties ensure that the time appears on the recipient’s calendar.
If you’re using Ruby on Rails, the iCalendar plugin works great for this. If you’ve created a calendar object by doing:

Then in your mailer, add an attachment like this:

Where notification.ical_text is the output from cal.to_ical.

One problem that crops up as a Ruby on Rails application evolves is that new attributes are added to existing models, sometimes with new validation rules. For example, you may have a Customer model with name, address, email and phone number, then realize you want to add an attribute to store email marketing preferences many months later. If you add a validation to the new attribute, any new records will be appropriately validated, but the old records won’t have any value. In some cases you may be able to provide a default value in the database migration but this might not always be desirable or possible. These old model records that no longer pass validation can cause serious problems in an application, especially if you validate records through model associations and you have validation errors that aren’t expected. To work around this, I created a quick little rake task that will find all your model classes, find all the model records and run validation on each record. In instances where the validation fails it will output the model name and the ID of the record that failed validation.