In classic eat-your-cake-and-have-it-too fashion, the company didn’t give me a raise.  They told me that both of us were part of the old, failing agenda, and that we would have to prove our new plan works before reaping the benefits.  I guess hard work doesn’t pay off.  It’s total bullshit, and I’m probably getting played, but what the hell: At least I answer to fewer people now.

There are no related posts.

After organizing my code, I ran a quick test with “asdf@asdfasdf.com” and was pleasantly rewarded with a successful validation message.  Then I decided to get tricky and see what cakePHP was made of.  I erased the email and tried again with “blahblah@poiuytrewq.co.uk” which promptly failed to validate.  Eghad!

Turning to google I started searching for “cakePHP bad email validation.”  Surely someone more clever than I had noticed that cakePHP’s email validation was not up to snuff, and hopefully I could find a better solution.  Google assaulted me with silence.  All I could find were links back to cakePHP’s Core Validation Rules Documentation.

After about twenty minutes of searching elsewhere, I began to think the error must be in my own code, so I returned to the cakePHP Cookbook, only to discover this little tidbit of information:

Passing a boolean true as the second parameter for [the email validation] rule will also attempt to verify that the host for the address is valid.

<mindblown>

CakePHP’s core validation not only checks whether or not an email address is well formed, it also determines whether the host for the address exists!  Changing the email in my application to “blahblah@amazon.co.uk” prompted me with a fresh success message.

</mindblown>

Time to clean my brains off of the wall.

There are no related posts.

I love it.  I’ve been experiencing renaissance-like growth in my own programming expertise, and I believe that this project will only further advance and broaden my circle-of-knowledge.  So, I say to dreamincode:  ”Challenge Accepted!”

Every week the good people at DremInCode post a new challenge to complete, and I’m starting the challenge three weeks late, so I’ve got some catching up to do.  The first challenge was easy for me:  write something in jQuery.

The second challenge is way outside of my core skill set.  I have to program something in Microsoft XNA Game Studio 3.1, which is based on the .NET Framework in the C# programming language.  I’ve never written a line of code in C#, so this should be interesting.

As the challenges roll by I’ll be posting my results here as well as the DreamInCode forum.

There are no related posts.

A Little History

I recalled that years ago I asked myself the same question. After some extensive (read: cursory) research, I settled on MooTools. I remember fighting for days to get an accordion widget up and running. To be fair, I was rather green.

Eventually I became quite versed in manipulating the DOM with MooTools. I loved MooTools so much that I scoffed at other frameworks.

Then I found a new day job, and guess what? Their design infrastructure demanded that I learn jQuery. For many reasons—some of which I’ve concentrated into the list below—this was the best thing to happen to me since learning “alert();”

The Inspiration

After regaling my friend with a lengthier version of the above, I decided to search for the most recent thoughts on the debate. This is how I found jQuery vs MooTools by Aaron Newton of Clientcide. After reading the article, it was plain to me that Aaron Newton is a smart entrepreneur, an elitist, and a master of manipulation.

His article is loaded with extreme bias toward MooTools, as well as some subtle wording tricks that emphasize how much better MooTools is. He unfairly states in his disclaimer, “Obviously, I have a perspective that is somewhat biased,” only to follow up with, “My objective here is to be helpful and accurate to people – not to sell one framework over another.” Yet, he often cleverly accentuates that MooTools is more explicit, makes more sense (to him), is more robust, and is easier (for him) to use. He silently calls to the inner “elitist/pedant” that resides within all good programmers (even me). MooTools is the right way, the strong way, the one true JavaScript ninja stance. To completely paraphrase and prune his entire article down to two sentences, I offer the following:

Ain’t jQuery a cute, easy to use little toy? MooTools is for “know-betters” who do things besides manipulating the DOM.

Much to my further chagrin, Aaron thoroughly reiterates throughout the document that he does not know what he is doing when coding with jQuery:

“[jQuery’s] methods don’t always make sense to me … When I do work with jQuery, I often find myself unsure what a method is going to return to me. Obviously this doesn’t bother everyone else as jQuery has a lot of people happily using it, so I’ll chalk it up to personal preference again [and again, and again, and again].”

I encourage Aaron to RTFM.

Most of the code examples that he provides for comparison emphasize how “MooTools code is … more verbose [than jQuery], but also more explicit.” I believe that Aaron is afraid of abstraction.

The List

I must thank Aaron, because he inspired me to write this jQuery-biased, yet non-partisan list of the top ten reasons (according to someone who is familiar with both frameworks) why you should use jQuery, and why I will never go back to MooTools.

I promise to keep my opinions to myself from this point onward. False.

10. Write Less, Do More

Aaron explains it best. “MooTools … takes longer to learn and requires you to write more code.” In the real world, we all want to write less and do more, do we not? Therefore, if my framework forces me to write more code to accomplish the same result, I must ask myself why I am using my framework. That leads me to the next reason.

9. 99% of all JavaScript is written with the intention of manipulating the DOM

If you were to make a list of the things you need JavaScript to do for you, it would look like the following:

1. AJAX
2. Form validation
3. Animation
4. Event handling, and
5. Traversing the DOM

Both frameworks will allow you to do these things, albeit jQuery allows you to do them faster and easier.  Occasionally (1% of the time) you discover that you need to perform some complex logic. With jQuery you’ll have to write some plain ‘ole JavaScript, whereas MooTools offers quite a few tools to handle these (1%) situations.

I wave my magic wand and now you’re a carpenter. Your task is to build 100 houses. You have two magical super tools at your disposal, and must choose only one.  One of them will allow you to hammer nails, measure and saw wood, drill holes, and cut a variety of special and complex wood joints.  Only one of the 100 houses will require the complex wood joints.  The other tool just hammers nails, cuts wood, and drills holes, but it does so with half of the required effort.

8. Abstraction

This is pretty much the same reason as number 10, but I felt like it required further emphasis. The reason you are writing less code in jQuery is that the library whisks-away all of the more explicit JavaScript that you would otherwise have to write. This is the only reason anyone uses a framework in the first place.   More Code = Less Abstraction = Less Productivity = jQuery Wins.

7. Selectors

jQuery uses CSS selectors.  You can grab an element by id, but you can also quickly grab all elements with a certain class, or all form inputs, or all form inputs that are password fields. It’s amazingly simple. This eliminates many hoops that you would otherwise need to jump through. It also makes working with designers a breeze.

6. Plugins

Back when I was forced to switch to jQuery, this was the first thing that I started to love about it.  Do you need to do something that the jQuery core does not do?  There is a plugin for that.  Hell, there are 10 plugins for that, each with their own level of complexity, and most use a single line of code to incorporate into your project.

MooTools has plugins too.  Again, you need to write more code to implement them, and there are FAR fewer options available.  This is because MooTools encourages you to write your own.  I am sorry, but I am too busy standing on the shoulders of giants to bother.  I will be drinking cocktails and toasting to my successful deadline completion while a MooTools developer is figuring out how to write a plugin to accomplish his goals.

I love original code.  Writing new code is fun!  However, that is not why I use a framework.  I use a framework to make my life easier.

5. Speaking of plugins: jQuery UI

jQuery UI is the single greatest web developer’s friend. You get tabs, dialogs, accordions, a progress bar, and sliders; it has pretty much everything you need to make a smart little web application.  If you program with jQuery, you are doing yourself a disservice if you are not using jQuery UI for some of your projects.  MooTools has a couple of options too, like JxLib and Mocha UI. I really dig the Mocha UI canvas approach, but I’m convinced that neither of these are as easy as jQuery UI.

4. Who needs MooTools?

Here’s Aaron again to further my agenda: “Most of the code you write when you write MooTools still feels like JavaScript.”  That’s because it still is JavaScript.  MooTools is a collection of extensions and prototypes.  MooTools makes low-level tasks a bit easier while ignoring that what you really want to do is just make things work.

3. The community is amazing.

Popularity is an annoying yet powerful thing.  jQuery is freakin’ popular, as shown here by Google trends. There is a veritable plethora of jQuery developers out there to answer your questions, build amazing plugins, ferret out bugs, and basically make everyone’s life easier. MooTools supporters say that jQuery fan boys talk loud and promote jQuery more than they ever can. This is true, but it is a symptom of the underlying issue. jQuery makes itself so easy to promote.

2. Google uses jQuery.

So does many other respected names like Digg, Technoratti, WordPress and Drupal. What is that famous saying about the company you keep?

1. Speed

Mootools is fast. jQuery is faster, period. This became especially true after jQuery 1.3.

The Last Word

Go download jQuery, take the brief amount of time that is required to read the documentation, and thank me when you’re done.

If you think you can convince me that MooTools is worthy of another look, or if I’ve misrepresented your framework, by all means let me know in the comments.

Related posts:

1. DreamInCode.net – The “52 Weeks Of Code” Challenge!

WRONG

include_once('myscript.php');
function somefunc(code){$d1=1;$d2='foo'; $d3 = "bar";
   $d4 = new myscriptClass;
  $d9    =false;
foreach ($d4->aligator as $crocodile) {
     if ($crocodile['scales'] !=true){
      if ($crocodile['legs'] !=true) {
    if ($crocodile['teeth']!=true){
		echo 'not a crocodile';
	  }
		else {
			echo 'still an alligator';}
}
else{
echo "still an alligator";  }
  }else {
echo "this is in fact, still an alligator";
}}
return strtolower(code);}

  echo somfunc('ThIsCoDeSuCkS');

How could you possibly debug that mess? Proper code indentation is crucial to successfully reading, debugging, or modifying your code. There are a few different conventions, and everyone has their favorite style (for better or worse), but the most important things to remember:

1. choose a convention and
2. stick with it

Indentation is not required in most program languages; it is something you have to force yourself to do.

Wikipedia’s entry on code indentation lists eight styles and one variant. I won’t cover them all here, but I will provide a couple of popular examples, beginning with my preferred style.

The One True Brace Style

include_once('myscript.php');
function somefunc(code) {
	$d1 = 1;
	$d2 = 'foo';
	$d3 = "bar";
	$d4 = new myscriptClass;
	$d9 = false;
	foreach ($d4->aligator as $crocodile) {
		if ($crocodile['scales'] != true) {
			if ($crocodile['legs'] != true) {
				if ($crocodile['teeth'] != true) {
					echo 'not a crocodile';
				} else {
					echo 'still an alligator';
				}
			} else {
				echo "still an alligator";
			}
		} else {
			echo "this is in fact, still an alligator";
		}
	}
	return strtolower(code);
}
echo somfunc('This is better');

You cannot go wrong with the 1TBS. Why is this style so great?

• Bracing occurs for every while, if, else, etc.—even when only one line of code is needed. No matter what happens to this code in the future, inserting or deleting a line of code is considered “safe” anywhere in the script.
• Beginning braces do not take up a line by themselves.
• The Unix kernel and Linux kernel are written in this style.

K&R Style

This is similar to my preferred style, the difference being that opening function braces are placed on their own line. Why you would want or need to differentiate functions any more than they already are is beyond me.

Allman Style

I see this one a lot on the web. All braces are placed on their own lines. I understand the proponents’ argument for white space and readability, but those opening braces annoy me. Especially on if, else statements like this:

	if ($crocodile['teeth'] != true)
	{
		echo 'not a crocodile';
	}
	else
	{
		echo 'still an alligator';
	}

Most of the other styles covered by the Wikipedia article are what I consider bad choices. The BSD KNF style incorporates too much white space. Whitesmith’s Style is a quirky, strangely perverse version of Allman. The GNU style’s odd choice of two-space indentation of braces makes for ugly code. Horstmann, Pico, and Banner styles all come highly un-recommended by yours truly, and are basically garbage.

There are no related posts.

Last Night on Earth: The Zombie Game fulfills on many levels.  Here is the description from the developer Flying Frog:

Last Night on Earth, The Zombie Game is a fast-paced game of brain-eating Zombies, small town Heroes, and horror movie action. Players take on the role of either the Heroes, working together to make it through the night; or the Zombies, unending waves of undead spreading over the town like a plague. Featuring a modular board, eight Heroes to choose from, and several different Scenarios to play that drastically change the game, Last Night on Earth is designed to create a cinematic feel as the story and game unfolds.

The game is well made, with excellent plastic miniatures, tough pieces, and a great board that can be distributed in multiple configurations.  It’s great fun!  I’ve played the game a number of times, and every time I get that “omg-zombies-are-going-to-get-me-run!” feeling.  I like the game so much that my family bought me the Growing Hunger expansion for Christmas, and it doesn’t disappoint.

One of the cool aspects of the game is that it includes many random pieces (like bio-canisters, ritual altars, a meteorite, and an evil old book) that are not associated with the original rules.  These pieces are intended for you to make up scenarios of your own!

The game is not overly complex, and it can be played in under an hour after memorizing the rules.

I have only two issues with the game:

1. Although the rulebook includes great art and was easy to read, it contains a few ambiguities that made our first couple of play-throughs difficult.
2. The game favors the zombies in an almost unbalanced way.  I’ve read on the website that the author intended the game to feel exciting and dangerous, and the game tries to simulate surviving (or not) a true zombie apocalypse.

If anyone reading is on the fence about purchasing it, I say this to you:  The fact that you are interested in buying a board game about zombies indicates to me that you will enjoy the hell out of this game.  There are enough good points to support it’s drawbacks, and because the game encourages improvisation and house rules, you can easily modify the game to your tastes and start experiencing that zombie-killing-thrill.

There are no related posts.

While implementing some essential WordPress optimization, I installed the following plugins:

• Google XML Sitemaps — Sitemaps are a key element of SEO, and this plugin makes updating and maintaining a sitemap easier than eating cake.
• HeadSpace2 — This plugin does utilize the feckless Keywords Meta Tag; however, the unparalleled title and meta description tag management offered by this plugin makes John Godley deserving of a pass.
• Redirection — Redirection allows me to easily manage and monitor 301 redirects and 404 page hits after making changes to my slugs (which I did twice after launch).
• Robots Meta — Fresh out of the zip, WordPress is a duplicated-content-fun-house.  This plugin offers the easiest method of narrowing the search engines’ scope of the site.
• SEO Friendly Images — I try to be particular about my images’ attributes, but if I miss something this plugin adds them for me.  Can’t beat it.
• SEO Slugs — When I first designed my URL structure, I wanted something like “full-title-in-the-url.html” However, this plugin strips the stop-words from the slug which looks nicer and apparently offers a small SEO boost (I repeat small, but what the hell?).
• WordPress Database Backup — I perform regular backups of my databases without this plugin.  Only Morons and Lazies don’t back up their data. The plugin provides a second layer of protection by emailing me weekly sql backups of the blog.  It does this automatically with minimal configuration, so that’s nice.
• WP-SpamFree — Akismet filters spam into a spam-box.  This plugin stops spam before it can be submitted. When the two are combined the world becomes a better place.
• Yet Another Related Posts Plugin — I’ve never used this type of plugin or it’s ilk, but it seems like a better-than-average way to boost internal site linkage and reader retention.
• Yoast Breadcrumbs — There are two fantastic reasons to offer breadcrumb navigation on blog posts:
  1. Google’s SERP Site Links and
  2. Google’s SERP Site Hierarchy Links

I have a thing for code indentation, but WordPress’ design makes it difficult to ensure that all of the final xhtml markup follows a perfect indentation structure.  While it would be too much of a pain to modify the indentation of  certain sections of the post body, I did take the time to hack the plugins and a few core WordPress scripts to force meta, link, script and title tags to follow a clean indentation. I’ll probably modify them further to achieve better grouping of these header tags.

I have a lot of plans for the design of the site, and I’ve begun the process of modifying the Purple Swirl Theme.  After installing jQuery I downloaded some free images from http://www.sxc.hu/ to use as categories in the sidebar and wrote some animation chains to add a nice overlay effect.  I also added my favorite design toy, Cufón.  I usually pick a beautiful, easy to read font for my headers.  For Anonymous Programmer I settled on Microsoft’s Consolas programming font as a quaint touch.

Over the coming months I’ll doubtlessly hack, slash, and modify the site further, so “stay tuned.”

There are no related posts.

Meta elements are HTML or XHTML elements used to provide structured metadata about a Web page. Such elements must be placed as tags in the head section of an HTML or XHTMLdocument. Meta elements can be used to specify page description, keywords and any other metadata not provided through the other head elements and attributes.

The key phrase here is “any other metadata.”  So, when writing HTML or XHTML webpages it is technically allowable to describe or identify whatever-the-hell-you-want about “Page X” using meta tags.  Many years ago this was an excellent way to explain things to search engines so that they could categorize your websites and deliver more relevant results in their indexes.

Eventually, the internet started to revolutionize the way the world did business, and where there’s money to be made people find ways to exploit.  For example, the once useful “keywords” meta tag was used to help search engines know what search terms were most relevant to your content.  Eventually webmasters started stuffing the most commonly-searched-for terms into their keywords tag–even if those terms had nothing to do with their own content.  This worked like a charm for a while, until the big search engines eventually decided that they could not display reliable search results to their users.

For many years now the keywords meta tag has been ignored for ranking by the most commonly used search engines.  It is actually still used for retrieval (not ranking) by Yahoo.com and Ask.com, and I found this article that explains the difference in more detail, but you can suffice to say that it’s relatively useless.  People still use it, however, and I can’t really blame them:  there’s a lot of circulated misinformation and confusion about the tag.

Now for the best part, and this is where my coworker fits into the scene.

Since meta tags can be used to describe anything you want about the page, somewhere along the line some really (really) crazy meta tags started cropping up on the web.  A few of them look okay at first glance, but a little rational thought should help dissuade a real web designer from using them.  On the other hand, some of these are so stupid that I really think they were invented by a prankster web designer and they somehow got stuck in the internets for good (as does most bullshit).

I need to mention that my coworker is very good at his job (he’s an SEO guy) (no I am not one, per se).  He has developed premium and effective internet marketing campaigns for some big customers.  You can imagine my surprise when I opened up the source for one of his current projects, and I see this:

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

<title>–edited for anonymity–</title>

<meta name=”description” content=”–edited for anonymity–” />

<meta name=”keywords” content=”–edited for anonymity–” />

<meta name=”title” content=”–edited for anonymity–” />

<meta name=”subject” content=”–edited for anonymity–” />

<meta name=”abstract” content=”–edited for anonymity–” />

<meta name=”classification” content=”–edited for anonymity–” />

<meta name=”alexa” content=”100″ />

<meta name=”googlebot” content=”all, index, follow” />

<meta name=”pagerank” content=”10″ />

<meta name=”revisit” content=”1 days” />

<meta name=”revisit-after” content=”1 days” />

<meta name=”robots” content=”all, index, follow” />

<meta name=”serps” content=”1, 2, 3, 10, 11, 12, 13, 20, ATF” />

<meta name=”page-name” content=”–edited for anonymity–” />

Everything starts off okay.  Content-Type, Title, and Description are all valid and useful tags.  Of course Keywords shows it’s face, but I’ll give him a pass.  It’s all downhill from there.

I don’t know why you’d want to identify a redundant/useless Title meta tag when there is already a perfectly good Title tag.  Subject and Abstract seem to be variations of the Description tag, ergo redundant ergo useless.  Classification seems to be a variation of the useless Keywords tag.

And now things go from misguided to wtf?

The mysterious Alexa tag apparently will make your alexa ranking magically improve for no reason other than the fact that you included the Alexa tag in your markup.  The same thing applies to the Pagerank tag.

To be fair, there is a such thing as a googlebot meta tag, but it is only used to tell googlebot NOT to index or follow your content.  If googlebot has already arrived at your website, it’s going to crawl your page without you having to tell it to do so.  Along the same vein are the Revisit and Revisit-after tags, which supposedly tell search engines how often to come back and crawl the site.  The content on the internet is growing in size exponentially.  Search engines have developed very sophisticated algorithms that determine how relevant and unique your content is, and how often they need to crawl your website.  Do you think Google is going to throw out that analysis because you told it to come back to your page every day?  If this worked, everyone would use it.  How could any search engine possibly crawl every page on the internet, once per day?

The robots tag is similar to the googlebot tag.  I don’t even want to try to fully explain the Serps (search engine results page) tag:  it has something to do with telling search engines exactly where on the page you want to be indexed, and it’s bullshit.  Page-name is another exorcise in redundancy.

I pointed these out to him and tried to spare his ego by explaining tactfully yet logically why most of them were worthless.  All I got were some blank stares, a few “but but but…” and “Yahoo still uses some of these.”  Seriously?

If any web developers or SEO people happen to find this article, take five minutes and revist the meta tags you’ve used and are currently using in your projects.  Ask yourself if the meta tags look like voodoo, or if they are designed to manipulate search engine results.  If so delete them.  Or, since the search engines ignore them all anyway, have fun with it!  Make up some really cool/funny meta tags like the Bacon meta tag, or the All-Your-Base-Are-Belong-To-Us meta tag.  At least then people who know better won’t think of  you as an idiot.  Or as a sheep, I haven’t decided yet.

There are no related posts.