This is mainly down to the campaigning of @PunKeel so you have them to thank!

Here is my post where I talk about turning them off, hopefully I won’t change my mind again!

The post Comments are back appeared first on Toby's Ramblings.

Just wanted to share it as one of those LOLWTF things you find every so often.

The post Internet Explorer Version 999.1 appeared first on Toby's Ramblings.

The database server was getting hit hard and slowing down the application, we narrowed the issue down to one potentially bad query.

We then took a copy of some production data, put it on our local machines and started hacking to see if the query could be improved.

Even though using EXPLAIN we were able to see it was a bad query, and running our new query through EXPLAIN made it look like a good query, we couldn’t actually benchmark how much better it was. You see our issue was that when ran once the query finished in a reasonable amount of time, the issue only seemed to appear under production load.

There are plenty of tools available for testing your code under load, but I didn’t want anything above these queries dirtying the results, for example I didn’t want ActiveRecord to try and do anything smart with caching, I wanted only to see what SQL statement worked best.

Turns out MySQL comes with a tool to help you do just that, MySQLslap.

MySQLslap

As the name suggests MySQLslap slaps your MySQL tables with a load of queries at a rate and concurrency that you set.

After the queries have ran it will produce a small table breaking down the times for you, which allows you to easily compare and contrast.

Here is an example of some output from MySQLslap;

	Average number of seconds to run all queries: 0.014 seconds
	Minimum number of seconds to run all queries: 0.012 seconds
	Maximum number of seconds to run all queries: 0.017 seconds
	Number of clients running queries: 50
	Average number of queries per client: 2 

This was generated from one command, that took a very small amount of time to set up.

MySQLslap – Setting it up

In order to get the above output I just needed to enter one line into my terminal;

mysqlslap --concurrency=50 --iterations=5 --query=/Users/me/Desktop/test1.sql --create-schema=my_database  -umy_username -pmy_password

I will go through each flag in turn;

• mysqlslap – This is the program we are running, if you don’t have it installed make sure you are running at least MySQL 5.1.4
• –concurrency – This is how many connections you want to emulate  very roughly this adds more load onto MySQL, imagine 50 people hitting the same page at the same time.
• –iterations – This is how many times you want to run the test, obviously the more you do it the more accurate your average will be.
• –query – You can type the query or queries into here, but I preferred to have them saved in a .sql file, so in my case I just reference where my file is located (note: you cannot reference the home directory by typing ~/ mysql doesn’t understand it)
• –create-schema – This is the most confusing flag in my opinion, this means which database you want the test to use, because it is called create I wrongly assumed at the start it would kill my current database, it does not (but any queries you run will affect it)
• -u – The username you use to connect to your database (optional depending on your setup)
• -p – The password you use to connect to your database (optional depending on your setup)

Hopefully that will help get you on your way.

MySQLslap resources

Here are a collection of useful resources (I will add to this over time);

• MySQLslap from the MySQL docs

The post MySQLslap – A quickstart guide appeared first on Toby's Ramblings.

Obviously in some situations there is an advantage to being first to market, and this applies to blog posts as well. If you are writing about some form of breaking news or writing a ‘live blog’ about something then it would make good sense to ignore this post, but for most other types of writing I think you would benefit from taking a break between writing and publishing.

There are several reasons for this;

• During the time you finish writing and the time you publish you might come up with a new idea or angle to explore in the post.
• Grammatical and spelling errors are easier to pick up with fresh eyes.
• Social media along with sites like Reddit and Hacker News mean your post could be being seen by thousands of people within minutes, so you don’t have the luxury of making small incremental changes after you post.
• You might think of better wording for something or a more eloquent way to write it.

I have read some people like to wait a week or more before revisiting a body work, I have done this before but I haven’t found that any more effective than just leaving it for a day or two. Your mileage may vary.

It also helps to steady your output, I for one have this massive creative surge for writing at around 11PM at night, depending on the length of the post I could have it written and proof-read by midnight, even if it was good to go and I didn’t think anything could be added it to this would not a good time to post, holding off means I have content that I can share at more opportune times.

The post You should never publish a blog post on the day you write it appeared first on Toby's Ramblings.

I had thought about writing up a “first impressions” post, but unfortunately my sim card won’t fit into it and I wouldn’t feel comfortable reviewing it purely based on its offerings over WiFi.

The packaging it came in was very nice, simple but nice. I was kind of reminded of the packaging that the Amazon Kindle came in, that sort of recycled cardboard look.

Accessories (not pictured) that came with the phone include;

• Ear Buds
• A USB charger
• A USB power block (unfortunately this is 2-prong and is of no use to me)
• A FireFox OS Developer Preview Sticker (I am partial to a good sticker now!)

Here is the phone turned on, and as I say this is pretty much as far as I will take this blog post. I will say that the screen isn’t as responsive as I would like, but I am happy with the weight and build of the phone and it picked up WiFi straight away and grabbed the latest update, which is all good.

The post Unboxing the Firefox OS Developer Preview Phone appeared first on Toby's Ramblings.

I have been using jQuery for several years now on a mixture of commercial and personal websites and on various web applications and whilst I don’t always think it is the right solution for a problem, when a library is the right solution jQuery is one of the best. In my current role we heavily use jQuery so I believe I am qualified to accurately review this book.

For this review I am reading the Kindle version of jQuery HotShot which you can buy now from Packt and from Amazon, the book is also available as a paperback for all you cave-people.

jQuery HotShot

So, is jQuery HotShot a good read? Or does Dan fall into the trap that so many jQuery writers do and leave you with pages of poorly written jQuery that doesn’t conform to any best practice?

I am happy to report that true to form Dan has produced an excellent book that manages to explain some of the core features of the library in interesting and memorable ways. He has greatly increased my understanding of some of the features that make jQuery an excellent library.

With hardly any preamble we are thrown straight into a fun example of using jQuery to create a sliding puzzle game. The example manages to assume no prior knowledge but at the same time doesn’t bore someone with prior knowledge by walking at a snails pace, as the book continues the examples get more and more involved.

One of the reasons that jQuery HotShot is able to get straight into good examples is that the examples themselves are littered with little best practice tidbits, for example;

Joining an array of substrings to form a single string is much faster than building a string using the + operator on substrings, and as we’re working repetitively inside a loop, we should optimize the code within the loop as much as possible.

Without needing a chapter or section dedicated to optimisations we have been able to find out about the need to take care about what we do inside loops and also learn a quick performance tips when dealing with strings. This certainly doesn’t have any direct bearing on the task at hand, but helps point the reader towards the best way of doing things.

My favourite example used in the book is probably the Bounty Hunter mobile site that hooks into StackOverflow looking for questions to answer, but the book covers a wide range of examples including building browser add-ons using jQuery and how to build your own jQuery (which introduces things like grunt.js, node.js, git etc.).

I am kind of cheating, because I was already aware of Dan’s writing and work so I knew that he knows his stuff, but you honestly do get the impression that a real expert in their field is writing this book, the way the information is presented shows that he has a deep and broad understanding of the subject material.

Something that I loved but that some might not was how involved the examples were, by this I mean that you could tell the feature or features an example was trying to explain and there are far more concise examples that could have been used, but they would either not have been as fun or wouldn’t have had a grounding in the real world.

One small niggle I have with the book is that the terminology for the sections within a chapter don’t suit my personality, subtitles like “Prepare for Lift Off” and “Engage Thrusters” belong more in the fluffy self-help books I love to read as opposed to a technical book, but I am fully aware the majority of people probably love that kind of stuff! Another tiny irk is that one of the examples talks about infinite scrolling, and I personally think that infinite scrolling is the devil!

My Conclusions

All in all I thoroughly enjoyed this book, and as someone who has been using jQuery in anger for a very long time I did come away haven’t learnt a truck load and I imagine you will too. One day I might write a blog post about the things I have learned from this book, in the mean time you should just go ahead and buy it!

jQuery HotShot Resources

Here are some resources you might find useful related to this review;

• You can buy the book here or here.
• My review on Amazon.
• The official jQuery website.
• Dan Wellman on Twitter.

The post Review: jQuery HotShot appeared first on Toby's Ramblings.

I have recently started working in the center of Belfast, which is the first time I have ever worked so close to plenty of places to shop and eat and I have to say I didn’t think location would matter as much to be, but it totally does. And it subconsciously probably does to you as well.

Belfast is a small enough city that you can get to most places in the city centre in about five to ten minutes, which essentially means there are very few places you couldn’t get to on your lunch break. This is a strain I didn’t even know I had lifted of my shoulders.

Things like collecting your post from a collection point, grabbing a quick birthday present for someone or picking up a bit of shopping so that you don’t have to on the way home are all massive plus points and it means that instead of sitting all day with a problem floating around the back of your mind you can take a quick note to pop out before work, at lunchtime or after work to do what you need to do, which leaves more capacity inside your noggin’ for problem solving.

The other massively useful thing I have found about working in a city is that you can easily meet up with friends, peers and collaborators at a moments notice, doing so really helps to properly relax you during lunch and helps keep your social wheels lubricated (I can’t believe I just said that, literally shaking my head at myself).

Finally, I really like the choices to do stuff for lunch, Belfast isn’t the greatest city in the world for places to eat, but it sure beats being limited to one or two choices. I would say most people working in a large town or city probably chose from 3 places regularly, but even knowing there are options is just a really nice feeling.

From a business point of view I can’t see why you wouldn’t want to be in town, your clients will know how to travel into town, your workforce are happier and yes I am sure the prices are a bit higher but I would say the returns you get from happier staff and the value of opportune meetings at lunchtime would surely make up for this.

Now that I have been exposed to working somewhere in the city I don’t think I could work in places like industrial or business estates again, and I don’t think I am the only one – I would imagine this is why more and more startups are biting the bullet and paying up for good property in town instead of saving some pennies and moving even 10 minutes out of the way.

If you aren’t in town, you should be.

The post Location, Location, Location appeared first on Toby's Ramblings.

Do you believe that in order to produce great work in large quantities you need great kit?

This isn’t a leading question, I am genuinely interested and it is something I to-and-fro on fairly regularly.

One side of me thinks in order to be the most efficient you can be you need the fastest machine you can afford, I mean there is nothing worse than waiting for an application or a process to open when you are in the flow of something. This is something that is at least in part backed up by the likes of Joel Spolsky when he wrote the Joel Test (see point #9).

The other side of me thinks that the bottlenecks to productivity are only superficially to be found on your machine, I mean people *did* get stuff done before the MacBook Pro came out, so what is my excuse? This point is something similar to what was mentioned in a recent Back to Work podcast episode where Merlin Mann said that if you are a writer then in theory you should be able to at least do part of your work with a pen and a bit of paper.

I can see the benefits of both, and I suppose that probably want you want is the mindset of the latter with the equipment of the former, but in saying that there are some drawbacks to following either road.

If you are happy using your 5 year old netbook to code on that is running 2GB of RAM and is rocking a sweet 60GB SATA drive then you are probably well versed in its quirks and you have saved a load of money compared to someone who upgrades their laptop every year, this is a good thing, but if you splashed out on a better machine 3 years ago that shaved 3 minutes off your day, every day for those three years it would save you over 50 potentially billable hours, that is a lot of money you could be leaving on the table.

Conversely, if you are always throwing RAM at the problem and have been playing with SSDs since they were released then you haven’t wasted those 3 minutes a day waiting on something chugging itself along, but you have maybe failed to appreciated what you have and maybe you haven’t thought about smarter ways of working because you haven’t had that 9 second wait while something reloads.

One part of me wants to resolve this by saying, even the fact that I am aware of the advantages afforded to me with the latest kit means I have an appreciation for what it would be like to use sub-optimal gear, but I think there is a massive difference between hypothesising about something like this and actually living and working with old stuff.

Then of course there is the cloud, why would we need good hardware when we do everything on the cloud these days!

Thanks to Ryan McDonough for creating this image when I couldn’t find the original. Find him on http://twitter.com/ryanmcdonough

Funny picture aside, it is true, there are many things we used to think we needed to process on our hardware that we now do on someone else’s over the internet, I think so far the pinnacle of this is something like the Chomebook which doesn’t allow you to easily code directly on it, but with a plethora of web services that allow you to code with them it isn’t really an issue.

The next question then is do web developers need high bandwidth? For me there is nothing to think about, bigger is better and I think the faster your internet speed the more productive you can be in this day and age.

We download and upload large files more than we probably realise, and with the amount of events and tutorials that are either live streaming or high quality downloads/playback the bigger your pipe the quicker you can get access to this content. The only potential upside to having a slow internet connection is that it would really give you an appreciation that your site needs to be performant when being forced through narrow pipes, but we have plenty of tools that allow us to check if that is the case without actually limiting ourselves.

Side note; If you do want to throttle your bandwidth for any reason, I made a quick script that will work on *nix machines and Mac OS X.

One best of both worlds example would be to have the best gear money can buy but be ultra strict about spotting failings in your current workflow, basically finding anytime you have to type something over and over again, or anytime you need to complete a series of events, make sure you log them and attempt to eliminate them.

An example this of occurred to me just this morning, I use the terminal a lot in web development and I am working on one main project right now which is located in my Sites directory. So every morning I would turn on my machine, open the terminal and type cd ~/Sites/ExamTime, it is only a couple of key strokes to do this, but I have better things to be doing that moving into a directory every morning (or every time I close a terminal window by mistake) a quick visit to the settings panel and I have made my terminal do those key strokes for me, I will never need to worry about that again.

To wrap up my admittedly rather loose thinking on the subject I suppose I should share my setup, before I do, I would love to hear your thoughts on the subject, Twitter, Reddit, Hacker News.

I hack on an early 2011 MacBook Pro with 16GB of RAM and an i5 Processor, I have a 255GB SSD in it and it is running Mountain Lion.

I write on a 2012 Samsung Chromebook, it has 2GB of RAM and a 16GB SSD, it is on the dev channel of ChromeOS.

I have no plans to upgrade either of these machines.

The post Web Developer Equipment appeared first on Toby's Ramblings.

The first thing I want to say is if you are seeing this page because you were expecting to see BornInBlood I want to say thanks for sticking around all this time, people like you are what keeps the metal scene alive and are part of what makes metal the best scene to be a part of. Hail! Now onto my ramblings around BornInBlood…

On the face of it the site was a forum, ran on PHPBB and it was pretty dead. Whilst there were a few folk who posted regularly it never really achieved a critical mass and it never really made it. Therefore on the face of it it shouldn’t have been a big deal to kill it.

The problem is though, it was a big deal to kill it, such a big deal that I have fought with the idea for over a year, here are my reasons that it should stay alive;

• It was my first ever proper domain name, and my first real site.
• It genuinely helped people (back in the day).
• I hate the idea of information and data just disappearing.
• People were using it (in small amounts).
• It had potential, the main driver of the website (after its first inception) was to help metal bands, and I still think this is an untapped area.

Here are the reasons that I decided to kill it;

• I hadn’t visited the site as a user properly for years.
• I couldn’t find reasons to make the time to make the improvements it needed.
• My love for metal is still there, but my love about talking about metal is not.
• Every time I thought about the site I felt a pang of depression about how much of a failure it was compared to what it could have been.

This last point is really the clincher for me, I am not 100% convinced you have to be a user of your system to make a good system (I am doing a good job with The Footy Tipster and I don’t know anything about football), I could find the time if I really needed to, there is always time. But I just hated that feeling.

The feeling always left me with three options, make the site awesome, take the site down, or leave the site as is for now. For years I opted for keeping the site as is and it only prolonged the inevitable and let me tell you — as hard as it is was to make the post and email everyone to say that the site was closing, I wish I had done it as soon as I had doubts.

I don’t really know where this blog post is going if I am honest, but for those interested here is a very brief bit of background on the site;

BornInBlood started as a fan site for the death metal band Evoke (they had a lyric that contained the phrase BornInBlood), it quickly changed into a metal blog and then a metal forum. Supplementing the forum was a social network for bands to promote themselves, this came about just around the same time as MySpace but offered a slightly curated list, for example the bands had to be European and had to create the profiles themselves.

Bands could post news, people could write reviews and organise gigs and what have you, it was a pretty good package and it really helped me cut my teeth into learning about how database driven websites work.

One day I took down the site functionality and just left the forum, I should have known then that it probably wouldn’t have lasted but I persisted and every so often would run a competition for bands or people to try and breath some life into the project, but I never really followed it up with anything.

There are probably some learnings to take away from this;

• Build on momentum, as soon as something stops it is so hard to get going.
• Don’t be afraid to kill something as soon as you start having doubts.
• If something is making you feel bad, fix it.

I have killed loads of sites in my time, including ones that were making me a good living and I never really felt that bad about it, but killing your first site is not a nice feeling, I am going to console myself by listening to some great music;

The post BornInBlood appeared first on Toby's Ramblings.

If you are merging your own stuff in with your own stuff then most of the time you are going to know which bit of code to keep or if to keep them both.

Things get interesting when either of the following two cases apply;

• You are merging in someone else’s code
• You can’t remember why you had written the code that is causing the issue.

Both of these cases can be solved by a using git’s blame.

git blame will show you a line by line breakdown of who wrote what line of code and as part of what commit and why this is useful for helping with merges is that it will;

• Let you know who you need to contact to discuss what needs to happen with this merge if it is non-obvious.
• Give you a commit hash that you can then query to find out the bigger picture and the context of the smaller change that is currently causing you issues.

To run git blame on a file simply call git blame my_file_name.rb and the output will be the contents of the file with each line prepended with the commit hash, the commiter and the the date and time it was commited.

The post Working out which merge to keep in Git appeared first on Toby's Ramblings.