Being an awesome developer is all about being a genius. It’s the only way you can get a job at a cool company and it’s the only way you can build anything amazing.
Oh wait, no it’s not.
Here’s the thing. If you care enough to actually want to be a better developer, you’re already ahead of 99% of field. So now what? Get smarter? Start a project with the perfect blend of flavour of the month and pop culture that goes viral on github? You could do that or you could do something with a concrete return on investment…
Build good habits.
Building good habits is a great investment for a developer because it goes a long way to making what you do consistent, repeatable and valuable. Building good habits takes those things we know we should be doing and makes them just, “the way”. Let’s be honest, if you don’t make a habit out of something, it’s going to be dropped the second any pressure is applied.
Good habits I’m working on:
- Smaller steps! Whether it’s a new feature or refactoring legacy nonsense, taking smaller steps is great.
- Making sure tests really are driving what I’m doing. It’s so tempting to race off ahead, but it ends in tears every time.
- Automate it. Rake, powershell, whatever. Just stop doing it manually.
- Keep the excitement, keep the love. There’s more to life than coding and it’s easy to burn out. Mix it up, do other things.
What are you working on?
The single responsibility principle (SRP) is one of the foundations of good object oriented design, taking pride of place as the “S” in SOLID. It states that a class should have a single responsibility which should be encapsulated by that class and that the class’s interface (i.e. public methods) should be closely aligned with that responsibility. Let’s look at an example.
# woof woof!
# om nom nom
Our (albeit contrived) Dog class adheres to the single responsibility principle as all its operations relate directly to Dog stuff. Good dog! Now let’s give our dog one more ability.
# woof woof!
# om nom nom
Now our Dog can build its own kennel, great! Or is it? Well, no. There’s two problems with this. One is that, dogs don’t have thumbs and as such cannot use hand tools and as we all know a dog with thumbs is an abomination. The second is that it has two concerns, dog stuff and carpentry. There it is, the “and”. You can easily spot that something violates the single responsibility principle whenever you find yourself saying “and” about class functionality.
But, why do we care? Well, adhering to the single responsibility principle helps us keep out code more loosely coupled, conceptually clean and here’s the big one, IT MAKES CHANGE EASIER. Change is what’s hard about building software (that and naming things) and the single responsibility principle helps us make sure that when we do need to change something, it’s nicely encapsulated, decoupled and much less likely to break other stuff.
TLDR; You should follow the SRP because dogs don’t have thumbs.
Staying up to date with good practices in software can be difficult. What was a good practice only a moment ago has fallen out of favour replaced by something leaner, more agile and completely incompatible with the way we used to do things. While it’s great for all those guys who need ways to fill time between giving conference talks, we mere mortals have things like clients, bosses, legacy code and less than stellar teams to deal with.
So, I believe an easy win is in order. Presenting, the data clump.
“Whenever two or three values are gathered together – turn them into a $%#$%^ object.”
— Martin Fowler
So, what is a data clump?
Whenever the same variables are being passed around together, it’s generally because they’re related. This sort of implicit relationship means something within our code, it represents a “thing”. The problem with this is, we want our code to be explicit, no muddied waters, no things that aren’t things but really are things. Data clumps make code harder to understand, harder to change and as a result, harder to live with.
Awesome, now what?
Work out what the implicit relationship between the variables is, throw them in a meaningful class and marvel at your cleaner, explicit code.
Easy win, you say?
You only need to do this once and you’ll see the benefits. Do it twice and suddenly it starts to jump off the screen at you. Keep doing it and it becomes a habit that makes you a way better developer.
Is your enterprise software missing something? Can’t take building another boring app at your 9-5?
Introducing SEESHAHP, the first Nuget package designed to translate from English to lolcat! With this easy to use package you’re guaranteed to get promoted, marry the owners daughter and build the next super big social media thingy*.
What are you waiting for? Push this to production today!
* or you’ll get fired. idk lol.
This error is due to RSpec expecting to run with the rails environment loaded.
`': uninitialized constant ActiveRecord (NameError)
Require the rspec helper in your spec file.
Installing RVM on OS X Mountain Lion.
1. Install command line tools for XCode.
2. Install RVM with stable ruby.
curl -L https://get.rvm.io | bash -s stable --ruby
3. Source the RVM install.
4. Verify your RVM install and view installed ruby versions.
5. Set your default ruby version (2.0.0 in this case).
rvm --default 2.0.0
6. Install Rails
gem install rails --no-rdoc --no-ri
The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'NTLM'.
Right click on the project, select property pages > Start Options > Uncheck NTLM Authentication.
Setting up font awesome with Ruby on Rails is very quick and gives you access to all the font awesome…awesomeness.
Copy the font awesome files to app/assets/font
Add the font directory to the assets path in application.rb
config.assets.paths << Rails.root.join("app", "assets", "fonts")
Modify font-awesome.css as follows
src: url(/assets/fontawesome-webfont.eot?#iefix) format('embedded-opentype'), url(/assets/fontawesome-webfont.woff) format('woff'), url(/assets/fontawesome-webfont.ttf) format('truetype'), url(/assets/fontawesome-webfont.svg#FontAwesome) format('svg');
Move font-awesome.css to your assets/stylesheets directory and restart the rails server.
Active Record supports the following database column types
Active Record offers many pre-defined validation helpers that you can use directly inside your class definitions. These helpers provide common validation rules.
- acceptance: validates that a checkbox on the user interface was checked when a form is submitted.
- validated_associated: ensures valid? is called on associated models.
- confirmation: ensures two text fields contain exactly the same data. This validation creates a virtual attribute with “_confirmation” appended to the field name. Useful for email and password validations.
- inclusion: ensures an attribute’s value is within a given set. The set may be an enumerable object.
- exclusion: ensures an attribute’s value is not within a given set. The set may be an enumerable object.
- format: ensures an attribute’s value matches a regular expression specified using the :with option.
- length: ensures an attribute’s value falls within, under, over or is exactly the specified length.
- numericality: ensures an attribute’s value contains only numeric characters.
- presence: ensures an attribute’s value is not empty.
- absence: ensures an attribute’s value is empty.
- uniqueness: ensures an attribute’s value is unique right before it is saved. It does not create a unique constraint in the database so concurrent connections may create duplicates.
- validates_with: this helper passes the record to another class for validation.
- validates_each: this helper validates each attribute against a block.
Check out the documentation for more information.