Anyone who knows me knows that I have long been a big supporter of Firefox. Back in the day, Firefox was the breath of fresh air in the otherwise olfactory-oppressing wasteland of an IE-dominated interwebs. Firefox was fast, innovative, and, best of all, let you add stuff on to it.
Add cool stuff. Like Pay-Pal plugins. Like RSS readers. Like Firebug.
It was the bees’ knees, and looked like it was going to gobble up all the stragglers that IE left in its “who cares about the experience” attitude toward the internet.
But then Chrome came along. It was sleek. It was fast. And best of all, it brought some fresher-than-Firefox ideas to browsing.
Better, fresher ideas. Like tabs-on-top. Like better architecture for faster…everything. Like not-having-to-upgrade-every-2.5-seconds.
So I’ve been using Chrome alot lately. Sure, it’s different. But what I’ve found is that it’s better. Sure, it doesn’t have Firebug (which is probably the only reason whatsoever that I continue to use Firefox). But every version gets better. And faster. And awesomer.
And Firefox? Perhaps its my groaning, Vista-laden PC, but Firefox hates everything. It’s slow, it freezes, it crashes…and very few of the plugins that I depend on for Firefox to be awesome can keep up with the More >
A common requirement in the era of Web 2.0 (and beyond) technologies is the ability to have “smart” client interfaces that are aware of changes that occur on the server (data, sessions, etc.). Most approaches include some manner of AJAX that regularly polls the server for changes. While this is easy enough to accomplish, it can be a taxing and somewhat annoying process. After all, wouldn’t it be much better if the server could communicate to the client when it has something share, rather than the client mindlessly asking over-and-over-again for the same thing?
In HTML5, this becomes a reality. Enter Server-Sent Events. In a nutshell, server-sent events “enable servers to push data to Web pages over HTTP or using dedicated server-push protocols.” This means, basically, that the client doesn’t have to keep asking for information: the server will notify the client when new information is available.
In it’s present state, server-sent events are only available for Opera and Chrome (6) dev releases. Additionally, they are currently implemented in two different ways. For Opera, the technology utilizes a DOM element (), while Chrome is entirely JS based. For this overview, I’ll be concentrating on the Chrome implementation.
For the example I worked up, More >
Something that’s coming down the pike pretty soon in tandem with HTML5 is the related, but independent W3C draft of a “Notifications” interface. Basically, this new interface provides a way for the browser to send notification messages on your desktop or device. So as example, while Facebook Chat will currently use AJAX to update the content on the browser page (causing the annoying tab “flicker” when a new message arrives), using the Notifications interface will allow a browser-independent message to be displayed directly on your desktop.
As with the other items we’ve been exploring in our look at HTML5-related technologies, Notifications are really easy to work with. A word of warning, however. Right now, this is only implemented in Chrome, and the W3C spec is itself based upon a webkit-specific API. So in order to make these work right now, you have to use the Chromium API, not the W3C spec. The fundamental principles are precisely the same (since the latter is based on the former), but has some minor differences.
First, let’s create a reference to the Notifications object:
var notification = window.webkitNotifications;
(Notice the “webkit” More >
I recently worked on a project which, among other things, involved implementing the "easybe 1-2-3" music store software (basically, it's a pretty simple-to-use platform for managing for-sale music downloads).
One of the major drawbacks of this software is that it doesn't come pre-built with a music player. While it does provide links to file samples that users can download and listen to (way too many steps for 30 seconds…), there's no one-step player for checking out clips from all the songs on an album.
No fear! There are ways around this, and in the following I'll walk you through the simple steps to deploy a free, light-weight mp3 player that can play the music you want your visitors to hear.
First, let's get the mp3 player. While you could use many of the freely-available mp3 players out there, I like the one from premiumbeat.com. It's super-stipped down and simple to use. Plus, it accepts an XML file, which will work perfectly for our needs.
Once you have the mp3 player of your choice, go ahead and deploy it on your server. Don't worry, I'll wait until you're done.
All set? Excellent. The next step is to open up the Album Details template file in More >
Ok, if you're like me and aren't the smartest cookie in the jar, something like specifying a connectionString in a web.config file can be maddening. Of course, it doesn't help that there are literally 123 billion possible ways to do a connection string…but I digress.
While searching for an answer, I ran across a pretty neat little technique that will make the development of your connection string quite painless.
First, open Explorer, and create a new file. Now, rename the file to X.UDL. Double-clicking this file will open up a Data Link Properties dialog window.
The super nifty thing about the DLP is that you can actually create a full-on connection to a datasource, and test out various settings. Nice.
But the really beneficial part (well, besides verifying that, yes, this particular service account does, in fact, have access to SQL Server…) is the "All" tab. Here, you'll see all of the properties of your connection. While nice information, this is super sweet because these properties are precisely the parameters that you need to enter into your web.config connection string in order to make SQL Server happy. That's awesome, and a huge time saver if building connection strings isn't something that you do on a More >
Today, I got around to trying to tackle some of the XHTML validation errors we've been receiving on our sites at work. One of the peskiest errors was what appeared to be a simple unclosed <img> tag–easy to fix, right? Well, I promptly navigated to the xslt file, opened it up, and quickly found the offending tag.
…it was already closed.
Honestly, I couldn't figure out what was going on. Just to make sure, I recopied the most recent, seemingly correct version.
I went back to the file, made ABSOLUTELY sure that the tag was closed and that there were no weird quotes floating around.
By now, I was desperate. I even started commenting out random bits of code around the <img> tag until I was POSITIVE that nothing else was causing this issue.
Well, it turns out the fix is pretty easy, and it all has to do with the "method" attribute of the <xsl:output> directive. On my xslt file (which I did not create, BTW), the method was set to "HTML" like so:
<xsl:output method="HTML" …./>
For whatever reason, this method of output can do funky things like remove the self-closing parts of tags. Dumb.
Anyway, I simply switched the More >
With Aptana, this kind of stone-age button pecking is over. Aptana has a nice, built-in "Outline" toolbar that helpfully shows all of the functions in the selected file, along with any declared variables. Plus, each More >
So a coworker and I are always talking about code. Not terribly interesting (especially for people who aren't in the biz…), but sometimes we make ourselves laugh. Yes, I know. I am a huge nerd for finding conversations about code to be funny…
But anyway, the other day we were talking about XHTML validation (you're welcome to start sleeping about right now, if you wish) and how validation fails if there are markup tags that are not "closed" (e.g., a "div" tag that hold an image, text, etc. needs to have a "closing" tag to tell the browser what it's dealing with).
Somehow, the comment was made that life feels like failed XHTML validation–replete with open "tags" of disappointment that never close…
Boy, I made myself bored just writing this. Appartently my line of work is dorky and lame. Oh well.Share this:
- Click to share on Google+ (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Share on Facebook (Opens in new window)
- Click to email this to a friend (Opens in new window)
- Click to print (Opens in new window)
A few months ago, I ran across ScrnShots. It's basically a service for uploading, tagging and sharing screenshots of websites. This is pretty useful for me given my profession :).
One of the things, however, that has always impressed me about the site is how easy and fun to use it is. It features really deep networking capabilities, the tagging is pretty robust, and everything is fast, fast, fast!
Of course, while uploading from the site is easy, I've been waiting with baited breath for them to release an API. Well, recently this happened, and I couldn't be more excited!
The API is alot like Twitter's in that it uses Basic Authentication for user-specific http calls. While not the most secure form of authentication, it is ridiculously easy, especially if you're using ColdFusion whose cfhttp tag has a built in mechanism for managing it.
So tonight, I spent a couple minutes digging into the API, and came away with an easy function for uploading, tagging and providing a description and link for an image. And of course, if you're using ColdFusion, it's cake!
Here it is:
<cfhttp url="http://www.scrnshots.com/screenshots.xml" method="POST" charset="utf-8" username="existdissolve" password="password" multipart="yes"> <cfhttpparam name="enctype" type="header" value="multipart/form-data"> <cfhttpparam name="screenshot[uploaded_data]" type="file" file="#filearea#" mimetype="image/jpeg"> <cfhttpparam More >
Over the last week and a half, I have been working with an old co-worker of mine on a project that he started about a month (or so) ago: searchwebjobs.com. This site is a pretty cool job listings site that is really easy to browse for jobs.
In brainstorming how to make the site better, I suggested that we create a WordPress plugin that would allow others (presumably, CSS galleries…) to grab a feed of our jobs and display them on their site.
So, grabbing my PHP 5 manual (and dusting it off…), I set to work. Fortunately, I have had some recent exposure to WordPress, so I felt reasonably sure that something could be done.
In all honesty, I couldn't be more impressed with WordPress' support for plugins. Consider this: it took me–a complete idiot at PHP–only 3 hours to program then entire plugin from nearly scratch. Not bad.
The beauty of WordPress' plugin support–IMO–is the default database that is so easily exposed. Instead of having to create stupid PHP connections, that stuff already exists, so all you have to do is basically write SQL. Plus, there are a few native functions to WordPress that allow you to use a row More >