June 12, 2014
If you've ever built an e-commerce or SAAS application, there's a good chance you've provided your customers or users with randomly-generated product keys, invoice numbers, redemption codes, order numbers, etc. Flexkey is a Ruby gem to assist in this process.
Consider a standard "Microsoft-style" product key: QPFLS-3OM4I-QQWXS-3QWX0-YQGSP. With Flexkey, generating keys in this format is a simple two-liner:
February 02, 2014
Most of the discussion of programming as it relates to learning and assessment revolves around best practices or the right way to do things. However, worst practices have value, too. And when I say "worst practices", I'm thinking about any of the following:
Any beginning Rails developer can synthesize Rubydocs, Railscasts, and Stack Overflow posts into a functioning application, but as that application grows in scope and complexity, worst practices will start to creep in. A more experienced developer, however, can draw on years of legacy code maintenance and messy refactoring projects to keep a codebase in check.
When interviewing potential Rails developers, I've found that the quickest way to gauge the experience of a potential hire is to show them some shockingly bad Rails code and ask them what they see. This process takes as long as whiteboarding FizzBuzz while being vastly more revealing. Plus, it can be easily done over the phone.
January 09, 2014
Whether you're developing the latest offering in the monthly subscription box space or simply adding a recurring subscription option to your e-commerce platform, you'll likely find that figuring out how to model subscriptions isn't the most obvious thing. Well, it's not obvious unless you've come across modular arithmetic in a discrete mathematics or CS course.
Say you're launching a fruit delivery business where a customer can sign up for recurring shipment of (hopefully) fresh fruit at an interval of their choice.
A new customer signing up on January 1 wishing to receive a shipment of fruit every 14 days will need their subscription processed on January 1, January 15, January 29, February 12, and so on. Another customer visiting your site on January 5 might opt for a less frequent delivery of every 30 days and will need their subscription processed on January 5, February 4, March 6, and so on.
An inexperienced developer might think: "I know…I'll generate a hundred years of processing dates (just to be safe) and store them in my database."
Obviously, this solution is less than ideal and ignores the fact that there are simple mathematical concepts underlying this system. Recognizing these concepts when coding will make it easier to do things like:
