This one stumps me. Really. So here I was, surfing YouTube (as any true blooded modern-day geek does after a long day of work), and I came upon one of Beethoven’s symphonies. I listened for a few minutes, then looked upon the sidebar and saw this:

Now, I’m not really sure why that happened. Gordon Ramsay is about as far from Beethoven as you can get. I mean, they sort of *look* alike (crazy hair, mean face), so perhaps there is some facial recognition thing going on? Even weirder – there was a link for a sushi video right under it.

My algorithm-orientated mind is having a really hard time trying to figure out how the heck Google thinks those videos are “related” Even weirder – when I refresh it shows a different video of Gordon Ramsay each time, but all the other “related” videos remain exactly the same.

Sometimes you just gotta love Google quirks.

Hey all,

I just uploaded a minor bug fix for my frame buster plugin. It has some extra sanitation code to remove slashes from host entries. For some reason slashes make it through the PHP host filter… odd. Anyhoo, you can download the newest version here.

I’ve also tested the plugin on WP 3.5.1 and it works great!

Yep, I am still alive, and I’ve got some great news.

Over the past couple of weeks I have moved down to Atlanta to fulfill some contracts with a marketing company. It has been nuts, but incredibly fun and rewarding. As a result of this massive change I will no longer be taking on as much extra work – not because I don’t want to – but because I honestly don’t have the time. My week days are shot, and the last thing I want to do is fill up my fun Atlanta weekends with the drudgery of work. Little things here and there are fine – but no major projects!

As much as I love money – health and happiness always come first before work! I’m just keeping it real, and being honest.

I know this news has been a bit disappointing to those of you who I have already contacted, and I do appologize. While most of you have been very happy about this news – a few of my now “former” clients have chewed me out, claimed I’ve sold out, and said some really nasty things. One person even asked me to justify my decision… who asks something like that?

Anyway, thanks again to all of my past, present, and future clients! Stay tuned, for this is surely just the beginning of a really wild ride!

Web browsers have come a long way since the 90s, but they still have a long way to go before they can reach their full potential.

I’ve been an Internet user since 1995, when I was just 6 years old. Back in the 90s browsers were pretty awful, at least when compared to modern versions. If you resized a window the entire page had to reload (which on dial-up took forever), designs were purely frame and table based, if a page had more than a few images it was pretty much impossible to display due to memory restrictions (16-32 megs ram), and they were insecure like you wouldn’t believe.

Let’s not forget about the “walled garden” of AOL, where you had to literally dial into the world wide web to surf any non-AOL sanctioned content. Those were the days…

Nowadays we can go on facebook and post a video of our cat jumping onto a balloon and comment on our friends’ posts with no reloading and very minimal network traffic – all thanks to the breakthrough transition to dynamic AJAX-based layouts. There was also the amazing advances in CSS that made it possible to literally create a WYSIWYG design in Photoshop. Back in the 90s you could sure make a sweet layout… but it would look nothing like it in reality… with CSS, it can.

Even the editor I am using on my WordPress install to write this now is a testament to how far browsers have come. It would have been 100% impossible to make a web-editor work this well on a browser in the 90s. Heck, an editor wouldn’t have worked this well in 2002!

However, even with the advances there are still quite a few predictions that haven’t come to complete fruition. Back in the early 00s when dynamic browsing really took off I often read tech articles and watched seminars about how all of our applications would be on the web, and the browser would be the new “desktop environment” to use these apps.

Yeah… it hasn’t quite happened that way. The biggest obstacles in the way are security issues and the lack of functionality in many of these apps.

Functionality Challenges

Take Google Docs for instance – sure it does 90% of what the average person may want, but they are seriously lacking on that extra 10% of  features that forces so many of us to use desktop apps like LibreOffice or worse… Microsoft Office. The other major challenge with online apps is offline access. While HTML5 has gone a long way toward solving this… it still isn’t quite there. It’ll take another generation or two of markup and scripting languages until this works flawlessly.

And what about games? Unless you are happy with the (terrible) framerates and quality of “cloud-based” gaming services, or unless you are a farmviller, you won’t be able to game through your browser for many years. Sure WebGL is nice and all – but javascript just isn’t as fast as the compiled C++ that most major games are written in.

Until the day comes when we have a real cross-browser “compiled”  language -  full gaming on the browser just won’t happen. Again, this is slowly changing… but it isn’t quite there yet.

It’s a shame flash was so terrible – it could have met this need.

Cloud Security

I dare you to ask 100 people in the general population of non-geeks if they would store their personal data on the cloud. I would bet you at least 50% of them still don’t feel comfortable with it. Despite how many statistics you quote that say it is safe… they won’t do it.

The biggest challenge with moving all apps to the browser will surely be convincing the public it is safe… especially when they are constantly bombarded with stories about malicious users going around taking down sites and stealing data.

The fact is it’s pretty darn safe. I would reckon you are more likely to get a check stolen from your mailbox than you are getting an online bank account cracked. This is of course assuming you follow common sense security procedures (long passwords, change passwords often, avoid phishing, etc), and assuming you are using a reputable service.

Sure, stuff does happen… but you know what… banks and other physical locations get robbed all the time by creeps in ski masks (or painter’s uniforms, man I love that movie!)

I think people are slowly getting more used to the idea that the Internet is safe – but I know from dealing with the general public in both my personal and business life we still have a long way to go in this regard.

Plain Ol’ Browser Views

For whatever reason – many developers still refuse to accept the fact you can develop an app using HTML, CSS, and JavaScript that is just as good looking as most iPhone and Android apps.

A few months back I took on a little project for a friend. His previous developer told him it was impossible to do certain things, such as convert it to a fluid layout with anchor points so certain elements stay in place (like a desktop app – try resizing one sometime!). It was a slightly complicated layout – but in 5 minutes I did just that with some css tweaks.  No problemo.

You can do nearly everything in a web view that you can do in a desktop app, as far as the UI goes. This includes creating custom controls. Whether or not the backend will work the same is another topic entirely…

Conclusion

Browsers have come a long way since the 90s, but they still have a long way to go before they become “the” app platform for everything. It’s getting there – but it is a slow and arduous process.

Hash collisions… the bane of any algorithm engineer’s existence. The severity of them and how often they occur can make or break whether or not a hash algorithm will be a success or a failure. In this post I will quickly explain what a collision is, why they happen, and why they are unavoidable…. all using terms that anyone can understand.

Before we begin: a hash algorithm turns some chunk of data (text, binary, whatever!), like “Hello, World” into another set of data (oftentimes ascii text) like “x9375vs4g”. They do this by running the data through complex mathematical formulas to generate “unique” hashes for each chunk of data. These algorithms generally work on data using a fixed size, one chunk at a time (64-bit, 128-bit, 92-bit, etc), and then it runs some final (math) procedures to make a single “unique” hash out of all the pieces. If a chunk of text it needs to work on is smaller than what the hash requires for the math to work, it will pad it (add junk data) using more complex math.

If you haven’t gotten the pattern yet – hash functions are a giant pile of math, to put it simply. Look up the source for even a relatively old  algorithm like md5 and you will be amazed at how complex it is. The most important part of hashing algorithms is that they will always return the same hash as long as you input the same data.

Hash collisions occur when two pieces of data generate the same hash. They are also unavoidable, especially when you are trying to hash large sets of data. For example, if you were to hash this entire blog post using SHA-256 (one of my favorites ) it will have the same hash as another set of data. For the most part, any hash algorithm will have an infinite number of possible collisions for nearly any hash it could possibly return – granted it would be impossible to find all them because of technology limitations (you can’t very well find infinity). Of course there are exceptions to the rule – but for all intents and purposes this is true.

To put it even more simply, if you try to cram “1234567890″ into a space that is only 3 digits long, will a collision occur with another set of data? Yes. You cannot cram 10 digits into 3 digits without collisions occurring. This is what hash collisions are all about – and this is why they are unavoidable. This is due to the pigeonhole principal. This is also why scientists can look quite foolish when they claim they invented some new algorithm that has no collisions. No one may have found one yet – but they do exist – it is mathematical law.

While there is generally an infinite number of collisions – they occur quite rarely, for all practical purposes. For example – if you do something simple like hashing user passwords and storing them in a MySQL database, the chances are pretty damn low you will ever have the same hashes in the table… unless two passwords are literally the same. You would have to have billions/trillions of combinations before a collision were to occur.

If you start talking about more complex algorithms, your computer couldn’t find a collision before the universe died. Literally.

Tip: On some websites they seem to pick arbitrary password limits like “40″. Many times this is to prevent such collisions from occurring inside their databases (read: they are paranoid). On small sizes the odds of a collision are virtually nil. Some sites limit the sizes even smaller… but that is because they are stupid (and super paranoid). Many other sites don’t even hash the passwords and store them as plain text. Now that is scary!

So how do computer scientists design algorithms to minimize collisions? The easy way is to increase the length of the hash. For instance, if you double the size you will exponentially decrease the chances of having a collision occur in the first N bits (N depends on the algorithm). Of course this sounds easy, but increasing the size can easily require intense changes to the entire algorithm. Remember: this is all just complex math – but even in the most complex of math everything must properly equal out (remember algebra?). If it does not equal out – it breaks… and planes could very well fall from the sky.

The other problem is increasing the sizes also increases the number of CPU cycles and RAM needed to process the data. It will take your computer far longer to generate a million 512-bit hashes than it would to generate a million 40-bit hashes.

Some designers also add in additional randomness to their code – although this doesn’t avoid the pigeonhole principal at all. You are still trying to cram 5 digits into 3 spaces. It will collide… sorry!

If you’d like mathematical proof: If you have 10^15 different combinations of possible hashes from an algorithm – and you have 10^24 unique combinations of data to run through the algorithm… you will have collisions. Math doesn’t lie

So there you have it – a quick lesson on collisions. What do your think of this topic? Please leave your comments below!