Posts By: Karle Durante

The other day I saw a pull request, on a Rails project, that declared a private inner class. Having my fair share of experience with Java, I am very familiar with the construct. Essentially, you declare one class inside of another class and declare it as private. This is often done to clean up your internal data structures and hide the implementation details from others. I couldn't recall ever seeing this in Ruby before, so it gave me pause. As...

Halloween is a special time at CustomInk, especially for a group of technologists who have a healthy appreciation for Sci-Fi and comic books. This year, our eCommerce group decided to hold an eComic-con and let our imaginations run wild.

Fall is in the air and so our engineers will be heading back to college! We are looking for Summer 2015 interns and early career software engineer hires. You can learn more about our early career software engineer position by visiting our careers page: http://www.customink.com/about/jobs/openings

Ken Collins and Jonathan Lehman will be presenting "Like A Ross! - Building The CustomInk.com Living Style Guide" at SassyDC this Wednesday, September 10th. Be sure to register if you plan on attending: https://nvite.com/SassyDC/f4a

The engineering team at CustomInk is always looking to learn new things. We've come to realize that the density of the information is not always the most important thing. Rather, exploring a single idea in depth can be a lot of fun. Avdi Grimm's Ruby Tapas has provided us with a really simple way to execute on this idea.

CustomInk technology is proud to announce that Chris Mar is our newest Inker! Following the new hire tradition, Chris pushed his first deploy to Booster.com within hours of arrival.

CustomInk technology is very excited to welcome one of our new summer interns, Sukhada Kulkarni.

CustomInk technology is very excited to announce that Ken Collins has joined the team!

We had a fairly severe production issue the other day. The kind of issue where you get sick to your stomach as you begin to realize what...just....happened...... As the issue escalated, news spread and a core group of people took control to work towards a resolution. The questions were always "what's happening" and "what's changed recently" and "what kinds of things might cause this" and never "who deployed last" and "who worked on this code originally". It says a lot...

The CustomInk technology team would like welcome Jason Gilbertson. Jason, a native of Iowa and a graduate of the Georgia Institute of Technology, has relocated himself to McLean, VA to join our team and we couldn't be more excited. Like everyone on the CustomInk technology team, Jason was quick to create a feature branch and then deploy his first feature to production. But there is another important aspect of our continuous deployment strategy that Jason participated in: feature verification. When...

Last week the CustomInk Tech team welcomed two new interns, Nolan Carroll and Seth Vargo. Nolan and Seth are joining us for the summer from Carnegie Mellon University where they are both majoring in Information Systems. Nolan and Seth wasted no time hopping on our deploy train last week, but they couldn't have done it without the help of our (semi) automated build process. A while ago, Nathen Harvey talked about our Green Screen build monitor. While this serves as...

The CustomInk technology team wants to extend a warm welcome to our newest member, Josh Born. Josh wasted no time and hopped onto the deploy train today for his first production release. At CustomInk we like to continuously deploy changes to our site. This means no sprints, no iterations, no milestones. We work, and when we are satisfied with our work, we deploy it. On average, engineers deploy updates to our site about five to seven times a day.

One of the most common production issues I run into are missing indexes. The other day I got to thinking that they are usually missing because of the evolution of the software. We might use some rails generators to prototype some basic functionality. Then we'll iterate over a set of stories incorporating new behavior. Maybe we'll do some refactoring, scrap some features, pull out some dead code and "harden" some areas we've identified as brittle. But we almost never analyze...

RubyNation is awesome. Most ruby events are awesome, but in particular I enjoy RubyNation because it's local to me. It's not that I don't like traveling to other conferences or that I think Washington DC is the best possible place for a conference. What I love about RubyNation being local is having 200+ ruby developers from my immediate locale in one single place, at one single time. Of course, it doesn't hurt to have Jim Weirich and Corey Haines show...

I recently tackled a pretty typical data migration task where some source model had to be transformed into some target model. About 80% of the elements were mapped field for field, and the other 20% had to be mutated in some way. Tired of writing one off rake tasks to pull and transform data, I came up with a little data mapper class that I cold reuse in the future.

Like people, applications start out small. Unlike people, applications do not always have a predictable growth pattern. Sometimes they grow really big, and sometimes not at all. When applications grow large, organization becomes important because it is no longer possible to remember every detail about your application without consulting the source code. "We use Rails, the convention tells us how to organize our code". Yes, but having 50 or more files in your app/models directory is hardly being organized.