I’ve been playing around with the HTML5 history API today, in order to make certain parts of our new product page bookmarkable. Here’s what we’re aiming for:
- On page1.html, the user clicks an a tag which has a href value of page2.html
- Instead of refreshing the page with the contents of framing.html, a panel in the page slides across to reveal the contents of page2.html in the current page
- The URL changes to page2.html
This is relatively easy to achieve by intercepting these links, and replacing them with Javascript behavior and using the HTML5 History API to push a new URL into the address bar. So, as an example, the following code will find every a on the page and instead of navigating to the href, just push the state into the address bar.
So we can quite easily intercept links to page2.html (either based on their href attribute or a CSS class), push the href into the address bar and load the content into the current page in some fancy-pants way.
But say you want the back button to navigate the user from page2.html back to page1.html. This won’t work, because unless you tell it to do otherwise, the back button will change the address, but do nothing else.
This is where popstate comes in. Using popstate we can listen for changes in the address, and act upon them accordingly. So my code ended up looking something like this:
It’s also possible to pass objects and titles through to pushstate, but I won’t go into that for now as it’s not yet well supported by browsers. Simply finding out the address of the page was good enough to solve the immediate problem.
Resources:
http://diveintohtml5.info/history.html
https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
Leave a comment
I’ve spent some time in the last couple of weeks taking the learnings from an early API prototype, and starting a new Rails application from scratch, complete with RSpec tests. Here are some notes on some of our tools and methodologies.
Model specs
We’re overriding the as_json method in our models and we’re using json_spec to test the documents have the right structure.
Request specs
We have hundreds of lines of request specs, and no controller specs. Here is a simple example:
Because we’re getting an actual HTTP payload back (in the response variable) we can inspect whatever part of it that’s relevant to us. We know the structure of the responses should come back in a known format because we’re testing the to_json method in the class specs. So it’s just a matter of using JSON.parse on the response.body and testing it as a native Ruby object.
Of course, this means that we are trusting JSON.parse to behave reliably but that’s an assumption worth making. If we were really pedantic, we could check that each object in the response array matches the expected structure:
Though I’m not sure that’s actually testing anything meaningful.
Another great advantage is that it makes refactoring simple. As far as the specs are concerned, a request to is the same whether the heavy lifting is done in the model or the controller. This really helped me recently when I moved a bunch of logic from the controller to the model as I could let the specs tell me which parts starting misbehaving.
Update: An interesting post by DHH about over-testing.
Leave a comment
Source control is fairly commonplace these days. Most people use the likes of GIT or SVN as part of their process, however there are still plenty of people out there who don’t use version control because they either don’t see a reason to or they don’t know where to start.
Until mid-way through last year, I fell into the latter category. I worked alone as a freelancer and made good use of Dropbox. The thing is, I was really missing out. It wasn’t until I started working as part of a team that I saw the real benefits.
I had tried to used these tools a few times, but quickly became overwhelmed by the magnitude of documentation that was presented to me. It all seemed to complicated and still, I couldn’t understand how I would benefit from this extra step in my workflow.
The thing is, once someone sat down with me and took me through what I needed to know about these systems, it almost became second nature. I have now got experience using both SVN and GIT and would highly recommend GIT over SVN to anyone, especially with the use of Github.
These days, particularly if you use a Mac (which I assume most developers do), there are some great, simple user interfaces for both GIT and SVN which will help you to get started and give you an understanding as to how these technologies work. Once you understand this, its really easy to learn the terminal commands.
The apps I would recommend are Versions for SVN and Github:Mac for GIT. Both are relatively self-explanatory but also have good documentation available.
Stick with it and you will wonder how you ever worked without this stuff. Personally, I would never start a project without using GIT now, even when working solo.
Leave a comment
I recently wrote about CodeKit and how it has improved our workflow when using pre-processors, but at the time I didn’t allude to the reason that we would use such things. Whilst LESS and SASS are certainly gaining traction, there are many developers out there who just don’t see the point in using something like that.
I must admit, I too was sceptical when I started reading about this new-fangled way to write CSS. I was confident that my code was of a high standard, efficient and maintainable, and I also loved the hand-crafted feeling you get from hand-coding everything (including vendor pre-fixes). The thing is, I just could see how pre-processors could make my code any better.
Of course I was missing the point. In order to really get the most out of these tools, you need to be writing good quality code anyway. LESS will not make you a better developer, but it can make you more efficient.
The first thing that normally wins people over is the use of variables. How many times have you scrolled up and down that stylesheet, looking for that colour value? Well, not with LESS. Here’s another one. You want your box-shadows to be consistent, and you can’t remember the exact code you used. Again, you could spend a few minutes searching through your stylesheet, or you could just use LESS.
The point is, LESS is great for enabling you to work faster and it can really eliminate the tedious parts of the job too. Really, there is no reason to repeat ourselves in code, time after time. Why not use a tool that takes care of the repetitive tasks for you.
Now, what I have just talked about only scratches the surface of what LESS is capable of, and there is much of it that you might not find useful, and that»s fine. Take what you need from it, but don’t write it off until you have taken the time to see how it can really benefit your workflow.
Links and resources
Here are a few links and resources that will help you learn more about LESS:
Leave a comment
There has been some debate internally about how naming our systems and applications. On the surface it may seem trivial, I find having a naming scheme really helps for:
- Discussing how systems relate to one another. It’s much easier to talk about Bootstrap than “The Twitter CSS Framework”. Significant advances in the application may result in new names, meaning less talk of “the new system” and “the old system”.
- Organising Git repositories. Calling things “API” or “CSS framework” is boring and not specific enough to be useful.
- Every project deserves a little personality of its own.
So, with that in mind, we have decided to use movie directors as the naming scheme for our systems, starting with our new API-driven platform, Kubrick. So if “there are only two hard things in Computer Science: cache invalidation and naming things”, perhaps we have reason to celebrate!
Leave a comment