04.01.2010   |   0comment

This April Fools edition of Sharpening the Blades only has two serious articles and we’ll let you decide on the last one. Luke talks about the Future of Web Typography, Benjam talks about jQuery Methods and Mac, well, Mac is the playful one at the office so he chimes in with his April Fools joke for all you PHP gurus.

Luke, Future of Web Typography
For years typography on the web has been very limited when compared to what can be in the print world. Over the last few years though we have been given more and more tools to help us accomplish good typography on the web. As time goes on these tools will get better and will become more widely supported. There was an article on Smashing Magazine this week that talked about a lot of these tools that are available to web designers. I really enjoyed reading up, refreshing my memory of code I haven’t used in a while, and also learning some new ways of styling type. Read it over, the text on your website will be very happy you did.

Benjam, 20 Helpful jQuery Methods You Should Be Using
While developing a website, I use a lot of tools, both in the creation of the website files (my text editor of choice, file manager, etc.), and within the website itself (CakePHP, jQuery, CSS, etc.), and I’m always interested in finding features of those tools that I might not be very familiar with.  While I have a deep familiarity with the features I use regularly, and a passing familiarity with most of the features of these tools, it’s always good to get a refresher on what I could be using more.  Here is a post highlighting 20 jQuery methods/features (actually 33 methods in 20 groups) that should be in everybody’s familiarity tool box.

Mac, April Fools – PHP Style
This discusses a topic that we often only think about once or twice a year, but it is still worthy of our attention and deserves some practice to improve our skills. Also, while you are there, subscribe to the PHP Developers feed. The main guy, Chris Cornutt, does an excellent job of filtering the best PHP articles.


03.05.2010   |   1comment

This edition of Sharpening the Blades features an article from Mike about using jQuery, CSS and image sprites to create stylish forms, an article from Benjam about Passwords on the web and Mark chimes in with an article about the possibility of HTML5 in Internet Explorer 9.

Mike, Get your form on with Uniformuniform
We’ve all been there. You finish an amazing design using some sweet custom form elements that perfectly match the theme of your design. Then after a few frustrating attempts, you realize that some form elements just can’t be styled. Or if they can, not consistently. So you throw on a border, maybe a background image, and hope for the best as dreams of your custom UI vanish into nothingness. But fear not! Using the clever jQuery script Uniform and some CSS sprites, your form designs can once more be glorious! Works beautifully in all major browsers (degrades gracefully in IE6).

Benjam, The Problem with Passwordspasswords
Being in the Web Development industry for a while now, and having had a few third-party scripts that were on my site hacked, I have become more and more interested in web security.  Passwords are on the front lines to that.  Being a user of Web technologies, I’m also interested in usability and choice, and when it comes to showing or hiding passwords (what? you can do that?) I’m in the boat of give the user the choice.  This article nicely explains a few examples that offer people the choice to show or hide their passwords, both of which are very useful.

Mark, Microsoft to Double Down on HTML5 in Internet Explorer 9internetexplorer
Doubling down seems like the wrong approach to me. If I were the CEO at Microsoft I would instead of thinking of trying to put their foot down harder, they should instead learn to bend in the winds of the market and work on compliance with the other browsers. Though I hate to say it even forced upgrades like Firefox does would be good, to keep people current and reduce the amount of cross browsers compatibility problems Microsoft gives developers. I don’t think Microsoft realizes that by making developers lives bad by trying to be different they are actually building up a mass market of developers who hate them because it is so difficult to make cross compatibility easy and affordable.


Benjam,on the topic of  JavaScript, PHP, Tools, Usability
02.25.2010   |   5comment

Why is coding so personal?
I’ve been noticing that often times, when getting or giving feedback on code, or browsing my favorite programming forum, or just reading posts about programming, that people often get very emotional about their code. I was wondering why this is, and because I am not a psychologist, I’ll just give you my thoughts.

Coding to me is like creating art, and there’s a great quote that backs me up on this:

Programming is an art form that fights back. —Unknown

Because code is like art, I get very attached to my code, as well as my style of coding. My code is like my baby, my something from nothing that wouldn’t be there if it weren’t for me. It’s just a bunch of characters on the screen that, from somewhere in the blue smoke, creates a function, or a game, or a website. I have received criticism on my code (as everyone has), as well as given criticism on other’s code (as everyone has), and those times when I’ve received criticism on my code, depending on how it was delivered, or what was said, it was almost like a personal attack on me. And I’ve noticed a few other coders react the same way to criticisms on their code. It’s like the person who called your code ugly or inelegant was saying that your child was ugly (and those of you who have kids know… that’s a huge no-no, punishable by any means available).

It may be because I think that my coding style is the best, it’s what I’m used to, and it’s the format I use because it’s the easiest for me to get at the information I need as fast as possible. I know this because I’ve tried other styles (sometimes flipping back and forth in the same day), and looking at someone else’s code that uses a different style from me, is often times hard to peruse easily. It’s what I like, and sometimes I have to hold myself back from reformatting code I come across into my own style.

So maybe we should stop thinking of code and coding styles as being “right” or “wrong”, and think of them more like the tool that they are, a means to an end. And the way you react to someone else’s means should be a little more like a suggestion for a different method of painting. Not a matter of fact, but just another tool for the tool box.

To continue the art analogy, it’s like everybody is given all the art supplies in the world, and told to make/paint/draw/create a box. Everyone will come up with a different way of doing it, some will be huge and bright red; others will be small and drawn in pencil; others still might be made of clay or brick. No matter what, it’s the way you chose to do it, and it’s no better or worse than the person’s next to you. You might think so because yours was faster, fancier, more elegant, or more “boxy”; but they might think the opposite. In the end, you still have a box, and so do they.


01.19.2010   |   0comment

This edition of Sharpening the Blades features articles about creating admin sections with CakePHP,  how $(document).ready( ) can slow down your site, and the wonderful things CakePHP can do “automagically.” Hopefully these articles will help you sharpen your coding blades.

Chad, Creating an Admin Section with CakePHPcakephp-admin
I have come across James blog just recently (about 2 months). The guys blog is great. He does so much with CakePHP that it is great to see what he is doing and what he can do. But the reason I suggest this specific post is because it seems to be the first stumbling block that every developer comes across while using CakePHP. This article specifically will explain how to get an Admin section set up and working. I consider this one of the must needed to know things to develop correctly in CakePHP.

Benjam, Don’t let Document Ready slow you downdocument-ready
Everybody wants to have a faster loading website, and I am certainly guilty of putting every DOM related jQuery snippet into the $(document).ready( ) function.  This post showed me that this wasn’t absolutely necessary and gives good examples of when and how to break out of the document ready mentality.

Mac, The Dark Side of CakePHP’s Automagicautomagic-cakephp
I’m not sure I like the title of this article so much as I like the article itself, but it does point out some useful information about the “automagic” things that CakePHP does for you. Some of the things they discuss are definitely features that were designed very wisely, even though the article seems to disagree with me on that. There are definitely some automagic things in Cake that they mention that drive me crazy too though, and I don’t really see the necessity for the seemingly poor decision made by Cake’s developers. My biggest peeve they mention are the behavior it has (or had, this may have been fixed/changed now) for many-to-many relationships (a.k.a. HABTM). It is really a pain in the neck when your relationship table has other data in it, like the date/time when the relationship was added, or by whom, or a quantity, etc.


Benjam,on the topic of  JavaScript
03.25.2009   |   0comment

Before we start this discussion, I’d like to point out that while dynamically inserting JavaScript and CSS can easily be done with PHP, or your server-side scripting language of choice, those solutions don’t apply to static HTML pages (what? static pages? what are those?), and I came across a situation where I needed a non-PHP solution.

On my personal website, I have a single static page, my home page. This page does nothing but provide links to the rest of my site, and as such, it does not need to be PHP driven with all the bells and whistles that go with it. Just some clean code, and some clean CSS to make it pretty. Recently I found a small JavaScript snippet that I wanted on my home page, so I added it, and it looked good. The trouble is that it’s a seasonal script, and it makes no sense to leave it on all year. So instead of editing my page twice a year to add and remove this script, I figured I could go one better and dynamically add the script to my page via JavaScript. After a quick search I found Dynamically Loading External JavaScript Files which has a couple of methods listed to do this. After looking them over, I decided the DHTML method would suit my needs better.

Here is that method:

function load_script(url) {
   var e = document.createElement("script");
   e.src = url;
   e.type = "text/javascript";
   document.getElementsByTagName("head")[0].appendChild(e);
}

continue reading Dynamically inserting JavaScript and CSS with JavaScript”


Benjam,on the topic of  jQuery
03.23.2009   |   5comment

A colleague of mine (Tim) introduced me to a jQuery plugin that I had not heard of before. The plugin is called cssWithVars. This plugin makes use of some JavaScript and jQuery magic to bring variables and reuse to the CSS world. I recently looked through the example given with the download, played around with it, took a look at the backend magic, and here is what I thought about it.

While the background magic is actually pretty simple (look for any properties using a variable, which are wrapped in [ ], and if found, look for the related selector, and insert the properties defined in that selector into the variable instance), the implications are great. What this means is that you can create various pieces of style that can be reused anywhere and when it comes time to edit those styles, you simply edit the one instance and they all work. Here is an example style sheet:

text_box { /* this becomes a variable */
	width: 100px;
	height: 100px;
}

notice { /* this becomes a variable */
	color: #F00;
	font-weight: bold;
}

p {
	[text_box] /* a variable in use */
}

h2 {
	[notice] /* another variable in use */
}

h3 {
	[h2] /* normal selectors can be variables as well */
	font-size: smaller;
}

p.alert {
	[text_box]
	[notice]
	/* normal properties can be used as well */
	border: 2px solid #000;
}

As you can surmise, changing the details of the [notice] variable (or any of the other variables) would be extremely easy. Simply change the color, or font-weight, in the selector where it gets defined and it propagates through to all the other instances. This, to me, is what got me intrigued by this plugin. It has far reaching implications, and can be a very powerful thing. But as with all great power comes great responsibility (and confusion.) With this, it becomes increasingly difficult to say what properties are applied to what selector, or even where they come from. Say for instance I have a variable that sets a border style and I use it in a property that also sets a border style, which one gets used? I would imagine the one that is set explicitly in that selector gets used, but then what if I am using two variable styles that both try to apply conflicting styles, one floated left, and the other floated right… what then? Which one is the intended style?

This could get ugly.

One more thing that you may or may not have thought of… What if JavaScript is turned off?

This little question is a deal breaker for me on this plugin. Not only is it a deal breaker, but it completely turns the tables on my recommendation of this plugin. Not only is the CSS completely invalid, but in the (not so) rare case that the user has JavaScript turned off, they are going to see, in the best case scenario, a completely unstyled page, and in the worst case scenario, a page that looks like it was rendered with IE (yes, that’s bad.)

It is for this reason that I recommend that, while this plugin has it’s intriguing ideas, and is certainly fun to play with, should not be used in a production environment, because it has a poor execution (through no fault of the developer, but due to the possibility of broken pages due to invalid CSS and disabled JavaScript.) But CSS spec writers take notice, this would be a great and powerful addition to CSS. But it would take a lot of thought to get some of the caveats I’ve mentioned here (and more that I didn’t) working together as the designer intended.