Imagine you have an element which is dynamically added to your web page (an image in a lightbox, for instance) and you want to centre it on the screen both horizontally and vertically.
You could do so with CSS (as this article explains), but if you don’t know the dimensions of the element you want to centre or you need to support older browsers, things can become quite tricky quite quickly.
I recently helped someone with a project where they had to select a bunch of records from a database, then on the client side use AJAX to filter those records according to certain criteria.
This was a fun thing to work on and a good opportunity to demonstrate the power of AJAX, so I thought I’d write it all up in the form of a quick tutorial.
For the impatient among you, here’s a demo of what we’ll end up with.
I was recently working on a project and realised that I needed a file that I had long since deleted.
On the one hand, this wasn’t very tragic as I had the project under version control using GIT. However, finding the exact command to restore a single file from a rather old commit proved to be a little more difficult, so I thought I’d make note of it here.
The other day my colleague mentioned that she’d like a simple calendar on the front page of her website. This didn’t sound too difficult, so being a nice chap I said I’d take a look.
Unfortunately, it turned out that my colleague works with this rather rigid content management system and beyond a few pre-defined widgets, she didn’t have the ability to alter much on the page.
On closer inspection however, I found that one of these widgets allowed us to create arbitrary HTML elements, as well as to include script tags. This sounded like a perfect case for a jQuery plugin…
Today I got a phone call from a relative, who was rather annoyed that Yahoo! had upgraded their mail interface.
She complained that she didn’t like the way that conversations were now arranged and that she was generally confused by the changes.
While I quite like the new look myself, I can appreciate that others might not, so I had a look at what can be done.
As it turns out, switching back to the old version isn’t so difficult. Here’s how to do it.
I was recently working on an application, that lets people from all over the world apply for a programme at the university I work at.
The application works well and does what it should, but we were seeing quite a lot of double submissions, that is to say, the same person applying multiple times in short succession.
Here’s how I fixed that.
The problem: you have a RESTful resource with default routes. The form to create a new item is located at
http://mydomain.com/resource/new/. When you submit the form with valid input, a new item is created and that works fine.
However, when you submit the form with invalid input, the controller re-renders the form and the URL is changed to
http://mydomain.com/resource. This is potentially confusing for end users.
How can we avoid this?
In Rails, virtual attributes allow you to create form fields that do not map directly to the database.
This can be useful in a variety of situations and can help you customize your interface to make it more intuitive and user-friendly.
In this short tutorial I will show you how to create three text fields to allow a user to enter a date (day, month, year), then combine the values entered into these ‘virtual’ fields and save the new value to the database.
At work, I’m currently working on a rather large form. And when I say large, I mean seriously large – I just counted, it has 136 fields.
Now when a user submits the form, the input is validated. If everything is correct the user’s data is saved to a data base, otherwise the form re-renders, displaying appropriate error messages.
I have written unit tests to test the form’s logic, but nonetheless I still want to test the form manually, just to be 100% sure that things are displaying as expected.
But there’s no way that I’m going to manually fill out 136 fields over and over again. No Sir! A much better solution would be to use Tampermonkey to do it for me.
It often occurs that I make changes to an existing website for a client, then send the client a mail informing them of what I have done.
However, it is not an infrequent occurrence that I then receive a mail back from the (sometimes disgruntled) client, saying that they cannot see any changes.
Hmmm… I know I made the changes and I’m viewing them on the live site, so why can’t the client see the same thing?
The answer is because of browser caching.