One of my favorite new tools is the Bourbon gem from thoughbot. It is a set of Sass mixins that greatly increases the speed of front-end development. While there are a lot of other options out there like Compass, the simplicity of Bourbon has been its best feature.
I was coding away this afternoon, and I introduced a destroy link to my codebase. It looked something like this:
Don’t be jealous that we’ve been integrating facebook and chatting with babes all day.
As I work my way through User Stories Applied and begin to write my own for an upcoming project, I keep coming back to Bill Wake’s INVEST acronym. It helps me get in the right mindset. A good user story is independent, negotiable, valuable, estimatable, small, testable. If it can meet all those requirements, you’ve done a good job.
Stories that are independent make the whole development process easier. You don’t have stories waiting for others to be completed so estimation of development time becomes more precise. Be creative, sometimes stories can be combined or defined in a way to decreases dependencies.
Stories help in the discovery and planning phase of a project. They facilitate the conversation between client and the development team. Remember to note high-level details and decisions that are made in these meetings.
Make sure each story provides value to either the purchaser or user of the product. This type of focus can help in the proritization of stories. Some clients are comfortable writing their own stories and this can provide good insight into their vision of the product.
If a story is not estimatable, it is usually too large or the development team lacks the domain or technical knowledge necessary for an estimation. A conversation with the client can increase domain understanding, while a developer can build technical understanding before estimation.
Small stories allow for the most accurate predictions. If they are too big or small, it is difficult to block out the correct about of development time. Combine or split stories to managable sizes. Stories can be split by user actions (separate create, edit, update stories).
A story is not complete until it can pass automated tests. Non-functional or overly subject requirements can lead to untestable conditions and should be avoided. As the code base evolves, you will continually use your tests to ensure old stories are not broken.
Exceptions can be perceived as non-local GOTO statements. This can adversely affect the readability of your code and mislead team members as to the actual intent of your method. Let’s take an oft-used controller action for example.
This is bad for a few reasons. First, we’re utilizing what’s called a catch all exception here. This is bad design because we could be burying an error that developers need to know about. Perhaps there’s a hook that sends an email out upon creation, and the SMTP server is down. With this implementation, the developers would have no way of knowing about that exceptional case and users would continue to receive unprocessable entity status codes.
This is also a violation of REST. When something is exceptional or in an errant state, like an SMTP server being down, the proper status code to return is 500 (Server Error). Returning an unprocessable entity infers to the client that they have supplied invalid information and that they’re disobeying the API’s contract.
So, let’s improve this example a bit to remove the catch all exception:
This is better because it expressly handles for an expected exception as opposed to any error that can happen in the ruby universe of errors. This way, if an SMTP server was unavailable or timed out, developers could be notified about that problem and address it.
There’s still a problem here, however. The code above is not intentional and should be considered a violation of the Principle of Least Astonishment. Programmers read code a heck of a lot more than they write it so your code should be clear and intentional. Utilizing a conditional expressively states “I’m expecting this case to fail sometimes, and here’s how we handle it.”
This also allows us to evaluate all the lines in each side of the conditional whereas a rescue halts execution.
There are also moderate performance gains to using conditionals because Ruby is optimized for that logic as opposed to exception handling.
This conversation is not new. To quote one of my favorite books (first published in October, 1999), The Pragmatic Programmer,
“…exceptions should rarely be used as part of a program’s normal flow; exceptions should be reserved for unexpected events”
If you’re still not convinced, let me google that for you.
Congratulations to the organizers of Ramencamp, a new Boston conference for bootstrapping your startup. The content was amazing and it was a great crowd of Boston professionals.
After using SpringPad on my iPad for the day, I can see myself taking notes at other conferences in this way. I’ve really been enjoying the application, and I recommend you check it out. I also dig the Android app.
Another great idea the organizers incorporated into the agenda were lunch conversations with all of the speakers. It was a great way to facilitate a more interactive chat. The highlight of the day for me was watching Elizabeth Yin guide business oriented founders towards not rushing to build products and to make small steps towards building complex feature sets. She did a phenomenal job expressing Lean Startup sentiments in a simple and understandable manner. Launchbit has done a great job assembling a toolkit for founders to assess their business ideas. I definitely recommend checking out the Launchbit site.
Security is important. You don’t want malicious users chatting on IRC about how they Pwnd your web application.
If you’re using Rails and you want to be secure, you should be protecting against mass assignment. Basically, without declaring attr_accessible or attr_protected, malicious users can set any column value in your database, including foreign keys and secure data.
Here’s a brief introduction to how mass assignment protection works. Let’s say you have a user that belongs to a group:
When I set group_id to be protected, I’m disallowing it to be set by mass assignment.
My recommended approach, however, is to always set a whitelist of mass assignable attributes with attr_accessible instead of a blacklist with attr_protected. That way, you don’t unintentionally leave a secure attribute unprotected.
This was a great addition to the Rails framework, but I always found myself wanting to conditionally protect attributes based on the state and authorization of my user. For example, I might want disallow users from setting their roles when they update their profiles, but I might want to allow admins to adjust their role via an administrative backend. This is how you can get it done in Rails 3.1
Along with this helpful change, you can also circumvent mass assignment protection entirely. This is useful, for example, if you’re loading data and you control the source.
You should really only use without_protection if you control the inputted attributes. It isn’t something you’d want to have in a controller action, generally speaking.
For more information on scoped mass assignment and additional attack vectors you should be securing against, check out the edge Rails guide on security