Ok, ok, Javascript pagination sucks, we all know it does - there’s little point in loading a whole heap of data that is then split down into chunks; your best bet is to do the job properly and use some server slide pagination script.
But like us, if you ever do come across the need to use some quick pagination, this MooTools class will do the trick for you.
Google Analytics does a nice job in referrals but the default report only shows the domain that the referral came from.
To get the full referral with domain and full URL path, just set up a simple custom report:
Separate mobile versions of websites are great - imagine going to Google on your mobile and being shown the standard view? The search box would be lost amongst the vast white space that would be your mobile screen; however, luckily for our zooming fingers, they display a specially formatted version for your browser. It’s perfect, everything within touching distance.
Now, go to your website. How’s that text coming out? I’m guessing not good if you’re reading this far on. Now, you could create a separate mobile domain for your website (like the previous example of Google does) and use one of the many mobile frameworks to achieve a pretty standard, well formatted but basic website. Of course, you could spend a while reformatting the framework but why not save yourself some time..?
Enter “Responsive Designs”, or the ability to respond the environment that the website is being shown in. It’s a simple concept of retrieving the browser properties and processing some CSS depending on the selection made, or none at all if the no match is found.
In order to keep the layout pretty, a recent site of ours needed to have scrolling content areas. Normal scroll bars are pretty ugly, so an overflow:auto wasn’t going to cut it.
With Chrome, styling the scrollbars is pretty easy (see all their new design updates for examples), but with all other browsers it’s either difficult or impossible (good you might say, changing a users interface to how you think it should be? Not always favourable). However, Facebook like content scrolling areas are ok in my book, so I set about finding a good plugin for MooTools. I found several, but none worked 100% correctly either jumping too much, needing too much custom markup, or were just simply overcomplicated.
So I set about creating my own one and after a short time, I came up with this. It works fully in IE8+, Chrome, FireFox 3+ and Safari 5+. Simply call the class with the below and the rest is done automatically.
See the demo: www.needathinkle.com/slider
Update: v2:
I just added scroll wheel support which registers on the parent to enable quick easy scrolling.
Kohana has a great cascading file system which allows you to have a code base for all sites you have, and then extend these for specific site customisation. In Zend Framework, while you can cascade through view paths, unfortunately this is all you can do - controllers, forms, models etc. are all fixed in their location.
This is usually fine, but when I absolutely had to extend a class for a specific client need, I needed to extend on my base controllers. This was, as it turned out, a lot more confusing but essentially quite simple.
My method, which is mainly based around the dispatcher, essentially allows you to specify a several possibly module locations, and when needed, it will iterate through them until the desired controller is found.
Many of our websites use external API’s and services to fetch data, examples include Google Docs, SongKick, SoundCloud, Picasa, Twitter, Tumblr and several more. Fetching data from these API’s is often pretty quick (unless it’s Tumblr) and we implement caching on all the calls which expires after a few hours so grabbing the data on fly is often no problem.
However, as Tumblr started to fall over last week, the noticeable speed difference on the Tumblr API was huge, and Google Analytics started to show page speeds of > 10 seconds (which during the Tumblr outage, failed anyway) so I thought it was about time I did something with the service calls.
The 123-Reg SSL is really cheap and does the job for small sites perfectly, but their email giving instructions on how to install it is no where near quite as adequate.
Firstly, the several spelling mistakes, poor sentence structure, and grammar gives me the impression the email was written 5 years ago for another system and then re-hashed for 123-Reg, and along the way they forgot to re-read and check it properly. Secondly, the reference to FireFox 2, which is now 4 major versions out of date, and was released in 2006 affirms my previous thought that it probably was written 5 years ago.
I recently had to upload nearly 5,000 contact entries to a MailChimp list for a new client. MailChimp’s interface, which is great, let me upload tab separated list files with no problems. Great, I thought, until I received an email from MailChimp informing me nearly 500 had been rejected becase they are “role based addresses” (basicaly anything with info@, enquiries@ etc).
I understand that spam is the internet’s biggest problem, but rejected all role based emails without even an interface to pick and select those that were rejected, is simply annoying. I use info@, hello@ email addresses all the time for my personal and client emails, why they should be rejected with no choice is stupid. I would have wandered off else where to another mail client if I hadn’t already paid for a monthly subscription plan. So I had no choice but to manually enter the 500 rejected by hand.
Entering 500 email addresses, with a first name, surname, title and company by hand (which would be a lovely 2,500 copy and paste jobs into a fairly slow interface)? No thanks.
Thanks to the MailChimp API not checking any email addresses, I produced the following script to loop through the rejected email list that MailChimp sent me, and got them all in pretty quickly.
We use the SongKick API across several of our sites to retrieve artist gig information without them having to manually enter the data and it works really well. However, when I wanted to find events for a specific venue, we found the API doesn’t have an API call for it (it’s also missing the ability to search for venues, add events and several other things - hopefully they’ll come up with something soon).
The next logical step in getting data is an RSS feed - but again, there isn’t one. RSS is so easy and simple to implement it is surprising they haven’t done this yet, it would be much better than the daily email alerts that I get, and promptly delete.
So the next method to get data is to scrape the venue page on SongKick. This is definitely not the best, easiest or quickest way to get data, but when there’s no alternative… needs must. After an hour or so, here’s the service call I came up with.
If you visit Facebook in a different language to English, all future Facebook elements across the web will keep the translation you chose.
This is great for keeping content locale to the user, but what (if like us) if you’ve spent a whole bunch of time designing a site and placing a nice little Like button somewhere?
About Ashley @ Thinkle
