@scriptnode

Should be:

@<href="http://twitter.com/scriptnode">scriptnode</a>

Which looks like:

@scriptnode

And here’s how to do it in PHP and JavaScript:

PHP

<br /> $text = preg_replace(’#@([a-z0-9_]+)#i’, ‘@<a href=”http://twitter.com/\\1″>\\1</a>’, $text);<br />

That was easy! Now let’s get to the more interesting JavaScript, which allows us to test inline!

JavaScript

<br /> text = text.replace(/@([a-z0-9_]+)/gi, ‘@<a href=”http://twitter.com/$1″>$1</a>’);<br />

You can run this code right here:

Format

I’m awful at regular expressions; please do let me know if I could optimize somewhere or if I missed something.
Edit: + instead of *

Funny stuff! But all kidding aside, I personally feel like PHP was ugly enough without goto. To me, one of the language’s biggest downfalls has always been that it practically encourages sloppy design, and this is a huge step in the wrong direction. How do you feel about it?

(Link via Isaac Schlueter)

And let’s just skip right past Internet Explorer and its plethora of headaches, shall we? We all know it sucks. Here’s why else it sucks to be one of us:

1. Everyone Thinks It’s Your Fault

   So you’re QA. You’re testing a website and something is broken. It looks to you like the frontend, because that’s what you see. What may separate good QA from excellent QA is the ability to determine where the error lies, but sometimes that’s out of QA’s scope.

   Regardless of who the owner is, chances are the issue will go to you first. You must then determine if it’s even your issue, and either fix it, or pass it on. Bringing us to …

2. You Are Also a Project Manager

   The frontend is the very last thing to get done. That’s because the design needs to be finished way in advance so that assets can be delivered, and the backend has to be complete before you have access to data to use in your implementation.

   This means that you must act as Project Manager to keep everyone else on track, because otherwise you can’t ever get to work! And that’s why …

3. You Always Seem Late

   Since you’re the last one that gets to begin implementing, chances are you’ve got less time than everyone else. And sometimes you can’t even get started until after your deadline! And even when you do finally get your assets and can get to it, sometimes …

4. You Must Know Photoshop

   To be fair, I actually use The Gimp, which works fine. What I mean by this point is that you must learn to use a competent image manipulation program. Why? Because although you may have an excellent design person/team, chances are they’re not going to cater to you and your crazy CSS hacks.

   You know what I mean. Sometimes you’re wanting to sprite your images to get better page performance, or sometimes you need to pull off some crazy rounded corners hack to get the positioning cohesive across browsers. You could go back-and-forth with design all day, or you could say “screw it” and alter the image yourself. It sucks but that’s how it gets done. And that’s part of …

5. You Must be a Jack-of-All-Trades

   In addition to competency with a decent image manipulation application, you’re going to need at least a familiarity in many other areas. It’s very rare to find a frontend engineer who doesn’t ever need to modify at least some server-side code.

   For example, although I am official a frontend engineer, I probably spend 30-50% of my time in PHP. That’s because, before I can even render the markup I need to tweak, I’ve got to setup the data I receive from the backend.

   Not to mention the various other tasks that randomly pop up in the webdev stack, such as Apache rewrite rules or cronjobs. I’m sure the same could be said for most jobs, but it seems like frontend engineers’ skillsets must be broader than most.

But it’s not all bad. Especially right now in Silicon Valley, frontend engineers are quite valuable, so it’s a great time to know how to code for the browser. Either way, did I miss something? Let me know!
]]> http://scriptnode.com/article/5-things-that-suck-about-being-a-frontend-engineer/feed/ 1 http://scriptnode.com/article/simple-loading-bar/ http://scriptnode.com/article/simple-loading-bar/#comments Mon, 03 Aug 2009 06:56:36 +0000 Matt Hackett http://scriptnode.com/?p=316 Haven’t had a Script Sunday for a while, so here’s a quick, simple script for you. Ever see those Loading … overlay images and wonder if JavaScript can handle it? Turns out it’s extremely simple:

<br /> animate = (function() {</p> <p> var busy;</p> <p> return function(id) {</p> <p> if (busy) return;</p> <p> busy = true;<br /> var width = 0;<br /> var interval = setInterval(function() {</p> <p> var el = document.getElementById(id);<br /> el.innerHTML = ‘@% <div style="width: @px;"><span>@%</span></div> <p>‘.replace(/@/g, width);</p> <p> if (width++ >= 100) {<br /> busy = false;<br /> clearInterval(interval);<br /> }</p> <p> }, 50);</p> <p> };</p> <p>})();<br />

You can view this by itself in the lab.

]]> http://scriptnode.com/article/simple-loading-bar/feed/ 0 http://scriptnode.com/article/php-to-use-backslash-as-namespace-separator/ http://scriptnode.com/article/php-to-use-backslash-as-namespace-separator/#comments Sun, 26 Oct 2008 21:23:52 +0000 Matt Hackett http://scriptnode.com/?p=235 After much debate, the minds behind PHP have made an important decision. The good news is, PHP will support namespaces. The (arguably) bad news is, the namespace separator will be the backslash character.

Here’s a simple example of what this will look like:

<br /> $object_instance = new My\PEAR\Module(’myvar’);<br />

PHP 5 already already has its criticisms. The developers looked at many different options, including **, ^^, %%, :>, :) and :::, but eventually decided on \, which is an odd decision, given that it doesn’t remotely resemble its cousins. In fact, it most closely resembles directories in MS-DOS or other Windows features.

The argument was also made that current operators such as :: or -> could have been used, but they already had other duties. The argument doesn’t go far, however, because PHP of course uses the backslash character for escaping.

]]> http://scriptnode.com/article/php-to-use-backslash-as-namespace-separator/feed/ 3 http://scriptnode.com/article/simple-cookie-script/ http://scriptnode.com/article/simple-cookie-script/#comments Sun, 19 Oct 2008 09:22:23 +0000 Matt Hackett http://scriptnode.com/?p=222 I often chat with a lot of new JavaScript developers. Many of their questions are really easy and can be answered with single-line responses, such as, “How do you append to an array?”

<br /> myArray.push(thevalue);<br />

Easy stuff. What’s unfortunate, though, is when the questions are a bit more involved, and these developers have already searched around a bit and found lousy code to read and learn from. The problem is that there’s much ancient, awful JavaScript code out there, and when performing simple search queries, these sites come up. My goal is to improve this process.

One common topic is that of cookies. Dealing with cookies is really basic stuff, but hey, that’s what the novice category is for. So here’s a simple script to assist with managing cookies:

<br /> /**<br /> * Global cookies object to manage cookies<br /> * @return {Object} The exposed methods<br /> * @public<br /> */<br /> var cookies = (function() {</p> <p> /**<br /> * Gets a cookie’s value<br /> * @param {String} name The name of the cookie to get<br /> * @return {String} The cookie’s value, or false if it can’t find the cookie<br /> * @member cookies<br /> * @public<br /> */<br /> var get = function(name) {</p> <p> var cookie = document.cookie,<br /> end,<br /> pre = name + ‘=’,<br /> begin = cookie.indexOf(’; ‘ + pre);</p> <p> if (begin == -1) {<br /> begin = cookie.indexOf(pre);<br /> if (begin !== 0) return false;<br /> } else {<br /> begin += 2;<br /> }</p> <p> end = document.cookie.indexOf(’;', begin);<br /> if (end == -1) end = cookie.length;</p> <p> return decodeURIComponent(cookie.substring(begin + pre.length, end));</p> <p> };</p> <p> /**<br /> * Removes a cookie that has already been set<br /> * @param {String} name The name of the cookie to remove<br /> * @param {String} path The path of the cookie to remove<br /> * @param {String} domain The domain of the cookie to remove<br /> * @member cookies<br /> * @public<br /> */<br /> var remove = function(name, path, domain) {</p> <p> var cookie = name + ‘=’;</p> <p> if (!get(name)) return;<br /> if (path) cookie += ‘; path=’ + path;<br /> if (domain) cookie += ‘; domain=’ + domain;<br /> cookie += ‘; expires=Thu, 01-Jan-70 00:00:01 GMT’;</p> <p> document.cookie = cookie;</p> <p> };</p> <p> /**<br /> * Tells the browser to set a cookie<br /> * @param {String} name The name of the cookie to set<br /> * @param {String} value The value to set in the cookie<br /> * @param {String} expires The date that the cookie expires (must be a valid date string)<br /> * @param {String} path The path of the cookie to set<br /> * @param {String} domain The domain of the cookie to set<br /> * @param {Boolean} secure Whether to make the cookie secure or not<br /> * @member cookies<br /> * @public<br /> */<br /> var set = function(name, value, expires, path, domain, secure) {</p> <p> var cookie = name + ‘=’ + encodeURIComponent(value);</p> <p> if (expires) cookie += ‘; expires=’ + expires.toGMTString();<br /> if (path) cookie += ‘; path=’ + path;<br /> if (domain) cookie += ‘; domain=’ + domain;<br /> if (secure) cookie += ‘; secure’;</p> <p> document.cookie = cookie;</p> <p> };</p> <p> return {<br /> get : get,<br /> remove : remove,<br /> set : set<br /> };</p> <p>})();<br />

You can download this script below:

• [Download cookies.js] (2,160 bytes)
• [Download cookies-min.js] (634 bytes; compressed)

Also, PPK has an in-depth article about cookies. His code examples get the job done, but unfortunately create too many functions in the global scope (which, as we all know, should be avoided).

]]> http://scriptnode.com/article/simple-cookie-script/feed/ 0 http://scriptnode.com/article/how-webdevs-view-webpages/ http://scriptnode.com/article/how-webdevs-view-webpages/#comments Tue, 07 Oct 2008 20:25:39 +0000 Matt Hackett http://scriptnode.com/?p=194 Web developers don’t usually browse the net like your average surfers. We will often view pages with a critical eye, tear them apart and see how they tick. I know I do. Sure, I’ve got periods when I’m lazy and just feel like surfing around or watching videos. But usually the engineer in me will take over and criticize a page when I first see it. Here’s what us webdevs do when we first see a webpage.
1. Disable Styles
2. View Source
3. Check the favicon
4. Validate
5. Check Firebug
6. Disable JavaScript
7. Run YSlow

Note: This article focuses on browsing with Firefox, the browser “real” web developers use!

1. Disable Styles

   
   The first thing I do when viewing a new webpage is hit ctrl+shift+s to disable styles and see a page in its design-free, naked state. What you should see after doing this is a really basic page with headers, text, and maybe some images. The Internet in its easiest-to-consume form, really. If nothing or very little changes, you know the page was developed incorrectly.

   Firefox added a keyboard shortcut (I believe in version 3) to map ctrl+shift+s to toggle the sidebar. I’m used to this shortcut disabling styles instead because I’ve been using the Web Developer Toolbar for a few years now. Thankfully, there’s the keyconfig add-on to allow users to alter keyboard shortcuts to their liking.

2. View Source

   This one’s a given and can be very revealing. Hit ctrl+u to view source and open up a world of shame or glory.

   Viewing a page’s source reveals many things about the developer(s) responsible. It’s one thing to disable styles to see how well separation of design and content was practiced, and quite another to see how semantic the page’s markup is (typical things to look for include headers in <h*> tags, paragraphs in <p> tags, and lists in their proper ordered or unordered tags).

   It’s also pretty revealing when a developer tries his or her damnedest to get spacing and/or tabbing consistent in the markup. It takes a lot of effort and shows a real discipline for cleanliness and organization.

3. Check the favicon

   Having a favicon can be a pretty good indication of whether a site is serious business or not. Web developers that are devoted to high performance would shudder at the thought of pushing a site live without a favicon.

   Other than the technical reasons, favicons have high visibility by showing up in your browser’s tabs, can have considerable branding benefits (or consequences), are easy to make and can be really fun or just adorable. Why the hell not have one?

   … Then again, even web standards evangelists like Yahoo! have some properties lacking favicons (Yahoo! Profiles is guilty as of this writing; I have filed a bug), so not having one only says so much.

4. Validate

   This is one of my favorites. The W3C Validator is one of the most useful development tools I’ve ever had access to. Now, there has been much debate about whether making a page 100% valid has any value at all. The usual consensus is to remove obvious or easily fixed errors (like malformed tags), but not to put too many resources into validation just to be valid.

   But it’s a pretty good indication of careless development when a page has hundreds of errors, especially when most of them are easily fixed. Honestly, I’d say a large majority of pages have errors, and that’s fine, but when a page is 100% valid, it shows that the developer(s) went that extra mile.

5. Check Firebug

   
   Oh, Firebug, where were we without you? Typically I will glance at Firebug to see if there are any JavaScript errors and to see what XHR calls are getting sent off (mostly just out of curiosity). The JS errors can be pretty revealing, but overall Firebug is just a great development tool that really lets you look inside of a page.

   As of Firebug 1.2, you now have to add a site to its whitelist to enable it, so I do this much less often than I used to. Oh well.

6. Disable JavaScript

   I only do this when I’m feeling overly critical or just hardcore. Maybe I simply love JavaScript too much, who knows? I don’t have a quick shortcut for this; instead, up in my toolbar I click Disable > Disable JavaScript > All JavaScript, and then releod the page. Often, this tells me nothing. But sometimes it tells me that the page isn’t as accessible as it should be.

   A good example is the current Yahoo! Developer Network homepage, which as of this writing doesn’t properly display its footer when JS disabled (see it with JS and with JS disabled). For shame!

7. Run YSlow

   YSlow is a fantastic tool that gives a letter grade to a page based on how well it follows Yahoo!’s high performance recommendations. Again, this is only if I’m particularly bored or curious, and Firebug must be enabled so I very rarely do this. Getting a B or higher can be challenging, so it’s a terrific indicator of developers that really care about a snappy user experience.

These habits are pretty common among webdevs. Hopefully they come across as endearing instead of obsessive compulsive. Either way, they come in especially handy when looking for a reason to praise a site, or when wanting to scrutinize an applicant’s resume sites.

]]> http://scriptnode.com/article/how-webdevs-view-webpages/feed/ 0 http://scriptnode.com/article/dynamically-load-css-and-js-files/ http://scriptnode.com/article/dynamically-load-css-and-js-files/#comments Sun, 28 Sep 2008 08:04:29 +0000 Matt Hackett http://scriptnode.com/?p=183 I hear a lot of developers asking about loading
CSS and JS files dynamically.
Surprisingly, creating script and link nodes is just like creating any other nodes.
All you have to do is create them using DOM methods and append to the head:

The Script

<br /> var loadCSS = function(file) {<br /> var link = document.createElement(’link’);<br /> link.href = file;<br /> link.rel = ’stylesheet’;<br /> link.type = ‘text/css’;<br /> document.getElementsByTagName(’head’)[0].appendChild(link);<br /> };</p> <p>var loadJS = function(file) {<br /> var script = document.createElement(’script’);<br /> script.src = file;<br /> script.type = ‘text/javascript’;<br /> document.getElementsByTagName(’head’)[0].appendChild(script);<br /> };<br />

Example 1 – JavaScript

First let’s load up a JavaScript file. Here’s what the external JS file looks like:

<br /> alert(’Loaded!’);<br />

And by using the above script, loading it is easy:

<br /> loadJS(’/assets/misc/dynamic-load/example-1.js’);<br />

Load JS file

Example 2 – CSS

Loading CSS is not much different. Here are the contents of the external CSS file:

<br /> body {<br /> border: 3px solid red;<br /> }<br />

Note that you can also use relative URLs or even files on another server:

<br /> loadCSS(’http://scriptnode.com/assets/misc/dynamic-load/example-2.css’);<br />

Load CSS file

This has been tested and works in all of the standard browsers including
Firefox, Chrome, Internet Explorer, Opera and Safari.

]]> http://scriptnode.com/article/dynamically-load-css-and-js-files/feed/ 8 http://scriptnode.com/article/software-development-meme/ http://scriptnode.com/article/software-development-meme/#comments Thu, 18 Sep 2008 23:50:21 +0000 Matt Hackett http://scriptnode.com/?p=171 I’ve been tagged by the insanely creative Jacob Seidelin, which means it’s my turn to fill out the Software Development Meme!

How old were you when you first started programming?

I was about 12 years old. That combined with my love of Nintendo really makes it sound like I never left the house, but I found time to play sports and get in trouble, really… …

How did you get started in programming?

A mysterious friend of mine (Jim MacDonald, who all but doesn’t exist online) and I used to play games all day, like Dragon Warrior and Shining Force. Then one day he wondered how games were made, and found…

What was your first language?

QBASIC! This has gotta be the easiest language to learn, and that says a lot in an age where PHP exists. I think more developers would benefit from starting with this fantastically simple language.

What was the first real program you wrote?

I wrote a program I simply called Dragon, which was a direct ripoff of Jim’s game Wizard or something. It used QBASIC’s DRAW commands to draw shapes and PLAY for sound effects. It was a single-battle, turn-based game pitting you (a knight) against a dragon. It was amazingly bad but pretty fun (for 12-year-olds anyway).

What languages have you used since you started programming?

Professionally: Only PHP and JavaScript

For fun and/or school: BASIC, C, C++, Perl, Python, QBASIC, Turbo Pascal, Visual BASIC

What was your first professional programming gig?

Working for Dav Glass at SchoolCenter. I was a PHP programmer making a measly $10/hour coding content management tools for K-12 schools. I was quickly promoted to lead designer (odd, right?), then when the company realized we needed engineers more than designers, put back into the development department. About a year after Dav moved to Yahoo!, I followed.

If you knew then what you know now, would you have started programming?

Oh hell yes. I’m always trying to learn as much as I can. Learning new languages is fascinating, and learning more about what you already are familiar with to me should be a daily exercise. If I had had the knowledge I have now when I was younger, I can’t imagine what I would have built by now. Interesting to think about!

If there is one thing you learned along the way that you would tell new developers, what would it be?

In a normal curriculum in school, students are taught to read well before they are taught to write. I’m not sure why this isn’t the case in programming. You’ve always got these wannabe developers that try to run before they can walk, and they end up tripping. There’s no shame in beginning modestly.

I recommend to anyone of any programming level: read other people’s code. The Internet is the ideal place to learn.

What’s the most fun you’ve ever had… programming?

Everytime I learn a new language, my first task is to build a game. I’ve been doing this for over a decade, in every single language I’ve dabbled in. But I think it was the most fun in QBASIC. I built an intentionally awful game called Seanbaby’s Magic Bus Ride Trip for you guessed it… Seanbaby. Working in Flash is really fun too, but nothing beats JavaScript.

Who’s next?

Let’s go with Isaac Schlueter, since he’s a great writer and always has interesting things to say!

]]> http://scriptnode.com/article/software-development-meme/feed/ 1 http://scriptnode.com/article/5-ways-qa-ruin-developers-lives/ http://scriptnode.com/article/5-ways-qa-ruin-developers-lives/#comments Sat, 06 Sep 2008 04:06:23 +0000 Matt Hackett http://scriptnode.com/?p=106
A Scholastic quality assurance employee

Quality Assurance people are important and valuable, to be sure, but they can also make developers’ lives much more difficult. This is particularly bad because (like many roles in an organization), their end goal is to help the developers make better software, not stress them out.

Here are some of the common ways QA workers ruin developer’s lives and how these behaviors can be avoided:

1. Misunderstanding the technology

   I’m often shocked by what somebody on the team didn’t know about. Understanding when software is working properly and when it isn’t can sometimes require a deep understanding of the technologies involved in making the software… And sometimes you just need to know enough.

   My favorite example of this is a bug I got about a year ago, in which the report was something along the lines of, “Page is dumping out plain markup, no CSS.” Sounds kind of like an RSS feed right? It was. This person had never heard of RSS.

   How to avoid this

   I hate to say it, but sometimes people just need to be qualified for their jobs. A unique perspective on a product is sometimes great, even sought after (for example, during usability tests). Other times, people need to do research and read up on the projects they’re working on. Most projects have awful documentation, but if they have it at all, it will probably mention in there what something like RSS is.

   On the other hand, nobody can know everything about everything. Technology moves quickly (especially when dealing with the Internet), so it’s understandable to be behind in a given area. A better way to handle this issue might be to suggest that perhaps the page could provide more information about what was misunderstood so that if others come across the same page, they’d understand too.

2. Assuming the software is buggy

   A friend told me about a bug he received recently. A QA person had tried three different features in the software that were supposed to display images. None of them worked, so three different bugs were filed. Thing is… those three areas of the software worked fine. It was the image that was broken. This person just assumed the software was buggy.

   How to avoid this

   When something is not behaving as expected, all reasonable checks should be made before branching out and getting others involved. Sometimes it’s as low-level as checking the Internet connection, and other times (as in the example above), it’s seeing if something works in other software. Pulling the image up in a browser or editor would have shown that the image was broken. Instead, everyone’s time was wasted.

3. Omitting necessary information

   I very recently received this email:

   Hi Matt there is Javascript errors on Devtool editor and preview pages. Do you want me to file a bug for them in one bug or are you already fixing (have fixed ) them?

   This email was next to useless. First off, I don’t know what environment these errors were found in. Typically at work we’ve got a handful of environments, sometimes up to five or six, and almost always I don’t know when they were last updated. All I know at any given time is about my development box, which I doubt people test on.

   Secondly, what browser and operating system were these errors found on? This is critical in a world where browsers behave so differently.

   Lastly, what were the actual errors and (probably more importantly) how did you produce these errors? Sometimes it’s very obvious. Load up a program or hit a webpage and the same error pops up for everyone on every operating system or every browser. Sometimes. But not usually.

   My all-time least favorite among the “not enough info” issues are the bugs that say something like, “looks funky” or “is broken”. I know what I think is funny. I don’t know what you think is funny. It’s ambiguous. If someone says, “it’s blue but it’s supposed to be red,” then I understand perfectly. Otherwise, there are blanks that need to be filled in, and a failure in communication has occurred.

   How to avoid this

   In short: I’m the developer. Need the info.

   All that really has to be done is to answer each of the questions above. I’d love to know about errors if there are any, but I must have the bare essentials of information about them, and usually the more information the better. Help me help you.

4. Not knowing the specifications

   Long ago, I lost track of how many bugs I’ve closed with a comment along the lines of, “This is by design.” Sure, sometimes nobody knows how the hell something is supposed to work, but if you’re doing it right there is documentation that answers these questions. It’s especially frustrating because the software is behaving exactly as intended and a bug is filed that (unknowingly to the creator) basically is saying, “Everything’s good, but I’m not aware of that.”

   How to avoid this

   Read the documentation. Know how it’s supposed to work. Don’t assume it’s broken. If all else fails, ask before filing a bug.

5. Over-filing bugs

   I’m primarily a front-end guy, so I get a lot of design tweak bugs. Sometimes a character is missing, sometimes a border is too thick, sometimes a font is one point too large… These tiny issues often take mere seconds to fix. What takes longer is managing each of the bugs created for these issues.

   A site I was working on a while back had a list that looked something like this:

   • Upgrade users
   • Truncate users
   • View users
   • Mass edit users
   • Import users

   For each bullet point in this list, I was assigned a bug whose summary was something like, “Add a period to the end of ‘Upgrade users’”. That’s five bugs for five really easy fixes. What a waste of everyone’s time!

   How to avoid this

   Bugs happen. Tickets for these bugs need to be filed. Usually they are unrelated and separate tickets are not just good, but necessary. However, knowing when to create fifteen bugs and when to create just one is very important to know in order to be efficient. Sometimes it’s best to think about the issues at hand and consider if they’re similar enough to be filed together.

   Another cause of over-filed bugs are duplicate bugs. This one’s easy, folks; just search for similar bugs before filing.

Note: I certainly hope this article hasn’t offended any kind QA folk. When they’re good at their job, they make my job way easier. Let’s hear it for QA!

(Special thanks to Isaac Schlueter.)

]]> http://scriptnode.com/article/5-ways-qa-ruin-developers-lives/feed/ 2