Rails Sessions Subdomains And Internet Explorer

Posted on: Tuesday May 01, 2012

When using Rails, subdomains, and sessions; IE will give you fits. IE cannot handle the subdomains and the cookies that Rails uses to store session data. It will not produce any warnings. It just drops all session data because it considers it a cross-site request even through the TLD is the same.

Also worth noting that IE will remove any sessions from subdomains with underscores. This is why I named the session without any underscores in the Gist, just to be safe.

Quick fix. Make sure you pass the TLD prepended with a "." as the domain to the session config.

The Problem With Rss Is The Content Creators

Posted on: Tuesday May 01, 2012

If there is anything that is going to kill RSS for me, it will be websites somehow resending all of there posts/articles. Several times I have ended up 20+ posts from one website all at once. This is the type of thing that will kill RSS, the content creators.

Oh yeah, and the 'click here to read more' malarkey.

Quit Crying And Build Something

Posted on: Tuesday April 17, 2012

The latest exchanges about semicolons and testing on Twitter may have done me in. I don't seem to enjoy the service as much as I once did. I can remember having the chance to meet and chat with people that I otherwise wouldn't have had the chance to. Now it's just a hotbed of crying. Everything from "my testing process is better than yours" to "I'm too cool for semi colons in my JavaScrip". What an complete waste of time, and I suspect there are many like me that just don't care what everyone else is doing.

As a reminder for those that get caught up in the processes and tools arguments, a quote from the Agile Manifesto (if that's your thing)

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

More and more, all I care about is working software. How we get there doesn't matter to me much. As long as I am confident in the code that I write, I'm happy. Sometimes that's acceptance tests with Cucumber; sometimes it's not. Sometimes it's unit tests at the model layer because the HTML and URL are unimportant; sometimes it's not. It's really, really simple. Use the best tool for job and don't worry about what Joe Programmer uses. You are ruining it for everyone else.

Exploring A Code Base With Integration Testing

Posted on: Thursday April 05, 2012

I work with a lot of code that I don't understand. Going from file to file tracing the path of methods is not always the best method for understanding how a system works. 

There are a few methods for exploring a system. The console is a great option. Unit tests that create objects and check the values of the objects is another good method.Bug the best way I know for exploring an application that I am not familiar with yet, is integration testing.

Whenever I have any code to write to an unfamiliar code base, I can count on integration testing to reveal parts of the system that are unknown to me. My process is very simple. In true TDD/BDD style, I write the smallest amount of code I need to get some result. I will start with just a few steps; visit a page, fill out some fields, and maybe click a link or two and compare the actual result of my actions with my expected result.

This will reveal parts of the system that I didn't know existed, every time. 

Developer Professionalism Guidelines

Posted on: Tuesday April 03, 2012

This post is a reminder to me of the importance of professionalism as a developer. It's way too easy to fall into a trap of quantity and speed over quality and deliverable software. The following is a (growing) list of things that I think are important in preserving professionalism when creating software.

• Never write code until you completely understand the problem.

• Strive for zero bugs in production code.

• Plan and write your code for simplicity and future collaborators.

• Empower users to perform tasks free of developer interaction.

Hit me up on Twitter if you have more @scottradcliff

Exposing Bugs With Tdd

Posted on: Tuesday April 03, 2012

Today, I sat down to write a feature in an existing application that takes two csv files, parses them, and generates orders in the system based on their data. As I generally do with any code that I write, I thought about the problem for awhile, came to what I thought would be a decent solution, and started writing code.

How I write code has changed over time. I enjoy coding with TDD in mind, so I usually open or create a test file, and make comments about the steps that I think I need to take to complete the feature. And drive the feature out one test case at a time. Usually 2 - 4 tests, depending on complexity.

I was reminded again today of the power of TDD. While driving these tests out I found two bugs that I may have never seen. They didn't produce any errors, just resulted in missing data. Had I built the feature without any tests, I may have spotted the bug, but it's highly unlikely. The bugs were very similar, so I will describe only one.

The bug existed with an after create callback. The callback expected 6 attributes, but I was only using 4, so I only supplied the 4 I needed. It appeared that records were created correctly, but they actually were not because all of the data was not being passed in correctly. The model file is extremely fat and the callback didn't have any comments and was not obvious.

Because my assertion was failing, I knew data was missing. This forced me to look a little more closely. This is a perfect example of a bug that slides through non TDD based development all the time.

By driving out a feature through tests I was able to expose bugs that were hidden by silent failures. There is no doubt in my mind that the users of the system would have found it in record time.

All code that I write has tests and documentation. I prefer both, for different reasons, but if limited, I will go with tests every time.

I Always Forget What Environment I Am In When Using Rails

Posted on: Sunday March 25, 2012

I finally got tired of making changes in the wrong environment. More often than not, when coding, I will have the production site up and the dev site. I've editing the wrong one more times that I would like to admit. So I added a simple banner across the top when working in the development environment.

It's real simple.

Then some simple CSS

Now I have a decent looking reminder where I am at.

Life Is Good

Posted on: Saturday March 17, 2012

For all of the complaining I might do. About my job, stress, money, etc. When I sit on the back porch looking over a beautiful country setting with a cold Guinness, I know life is just about perfect. It's important for me to be reminded of just how fortunate I am.

I have a great family, a great job, my kids go to an amazing school, and I get to build software every day, all day. Life is good.

The Bubble Goes Pop

Posted on: Friday March 16, 2012

The past week has taught me a lot about hosted/free services. First, all of my private repositories on GitHub were locked due to a billing issue. I felt bad for them, they are a great service and have had a hard time lately with DDoS attacks and such. I made sure my credit card was valid and asked support to resubmit. Failed again. I tried repeatedly over the the next few weeks until I gave up, used another card, moved all my private repositories to my server, and downgraded to free.

Not only have I been having problems with GitHub, there seems to be a rash of services either having problems or simply shutting down. Posterous was acquired and will be shut down, Oink shut down their only service claiming they had to and plan on using my data for other projects (err wut?), and CopyCopter decided it wasn't profitable and it's closing. In CopyCopter's defense, they are open sourcing the code, which is a good move.

Now I am wondering why do I pay for a service? I pay for a service to make my life easier. Yes, more often than not, I could build it myself. But I pay for someone else to handle all of the details for me so I can do other things. I can host my own Git repositories, I can build my own blog platform, I can post what I like and where I got it, and I can write a service to update content in real time. That covers all of the services that I mentioned. I don't need to pay for any of those services.

A bubble is getting ready to pop. People are going to start getting real gun shy about what is a legitimate service and what is a temporary hobby for someone. If you're building an app, and you plan on selling it, either monthly or a one time fee, you had better be in it for the long haul. Don't provide something and just close it down because it's not working for you. Your customers/users are counting on you to provide what you promised.

I know I will never pay/participate in a Kevin Rose service again. That was a coward move. It's a good thing he joined Google because he hurt his reputation a ton.

This is just the beginning. Other services will follow suit. I mean why not. It worked for insert app name here. They just shut it down when it became difficult. I am currently reviewing every service I pay for and dropping them before they drop me.

While I'm on a bit of a rant. Imagine this: You pay Heroku and use some service for your app. Said service decides that they no longer are producing enough profit and want to work on other projects and discontinue the service. You're in quite a pinch if that is part of your business. Find a replacement , build it yourself, or remove the feature. iit could happen and is starting to seem very realistic.

It Only Takes An Hour

Posted on: Wednesday February 29, 2012

I've tried and left many half-finished side projects. The reasons vary, but more times than not, I attempt to dedicate more time to the project than I have available. It usually goes something like this: "I am going to work on insert project name on Tuesdays and Thursdays". The problem is that I plan on a 4 hour block. Say from 7 - 11. That leaves zero time for my family, and after working a day job all day, that's not really fair to them. The result is a project that sits half finished because the time requirement is just too much.

For about the past week or so, I have been setting aside one hour a day, from 7-8. That hour is for whatever side project I have at the time. I work on it for that hour, maybe I get the UI cleaned up, maybe I get a feature or two implemented. It doesn't matter. At the end of that hour I close the lid and watch TV with the kids, help clean up the kitchen, or get some things done around the house And it has been eye opening. Focusing for an hour a day is extremely productive.

Of course this doesn't mean anything unless I release some of these projects. I can say I'm further along with an hour at a time than I ever was before.