I hereby decree

by David LeMieux

 

I think I finally figured it out. Based on the way I manage my friends/followers I have this weird dichotomy going on with Twitter and Facebook. Twitter is all the people I like to keep tabs on but we never say anything useful. Facebook is all the people I feel obligated to connect with but am mostly uninterested in.

Now, if I could get all my Twitter friends to be my Facebook friends and then have real, meaningful social conversations we would be on to something.

 

Comments (View)

 

 

I hereby decree that the following rules shall be in effect immediately.


  • If you want to be a tough guy with a questionable past you have to carry a worn picture of your family or offspring.

  • "Hot" girls will no longer carry their lunches in Victoria Secret bags. (inspired by Penston)

  • Or get your degree shall be the last item on every bulleted list.

 

Comments (View)

 

 

E.ggTimer in the Palm Pre Browser
The WebOS Browser is surprisingly compliant.

Over the weekend I made a port of the basic functionality of E.ggTimer from Flash to HTML5. By basic I mean that things like titles and sequences are still missing, though I intend to add those soon, for full parity. And when I say HTML5 I really mean that I used the HTML5 doctype and new, proposed tags. Specifically, I used the canvas tag and the audio tag. I also used some new CSS and JavaScript features.

The End Result
In the end, it works pretty well on desktop browsers as well as on the iPhone, iPad, Android, and WebOS browsers with some interesting differences. As far as I can tell, the beep sound at the end only really works on the Pre, so props to Palm for supporting audio. You can try it out here: http://e.ggtimer.com/m/3min.

Next, while Safari supports Workers, you can currently only post messages as Strings. When I first implemented the Worker to do the date calculation I was passing objects. Since I got lazy and didn't want to refactor my code I just disabled the Workers for Safari.

As I tried the new code out on various devices I came to realize that the ability to leave the timer running in the background (WebOS, Android) really made it a nice feature. It works on the "i" devices, but you have to leave it open. A native app would take care of that, but I am hoping that in some future update the browser will be able to run in the background (and have sound).

For now, if you hit E.ggTimer (or the new domain, C.ountDown.com, and start a timer you will be redirected to the HTML5 code if you are using a mobile device. If for some reason you just hate Flash you can use the "/m" site and be Flash Free(tm). On the desktop it works best in Google Chrome.

Conclusion
The transition from Flash to HTML5 was pretty straight forward and I believe that those Flash developers that can stop worrying and actually play around with the new stuff will quickly find it suites them well. It isn't an end-all, be-all solution and it has a long way to go before we have full cross-browser interoperability, but it is pretty slick. I come away less stressed about the whole ordeal.

I also removed the affiliate banner stuff since it was performing poorly. I replaced it with a nice update section and a small donate button. Cheers.

 

Comments (View)

 

 

Exectute Section 3.3.1
The Emperor is not pleased.

Inspired by @gpenston's tweet.

 

Comments (View)

 

 

This is a re-post of a guest blog entry I did for Widgetbox

When Apple, Inc. announced that the iPad would not support Adobe's Flash Player, the developer community began to talk. The debate about Flash as a web technology is not new, but the decreasing amount of support for Flash-enabled websites on mobile devices has made the issue more prominent.

When talking about the lack of Flash support on devices like the iPhone, iPod Touch, and the iPad, people are generally talking about Flash Player, the runtime piece of the Flash Platform. As more people start using internet-capable mobile devices, fewer people are able to consume Flash content on the web. At its peak, Flash enjoyed a 98% market penetration. Now some websites are reporting that the number of Flash-enabled browsers visiting has dropped to as low as 88%. Websites that are built entirely in Flash are now at a disadvantage when it comes to the mobile web.

There are other technologies that are also called by the name "Flash." The Flash authoring environment (e.g. Flash CS4) is the tool created and sold by Adobe that enables development for Flash Player. Flash Video (flv) is a file format used to deliver video through Flash Player. High profile video websites like YouTube and Hulu depend on Flash Video. Its ubiquitous nature means that it is simple to deploy video to a wide range of users using different Internet browsers and computer operating systems. Flash also comes with a built in protection system, making it harder for people to pirate the video they are watching. Web video is possible today because of Flash. That said, there are some drawbacks. Flash Video is a proprietary format made by Adobe. You can only use Flash Video in Flash Player. That means that nearly all the video on the Internet is controlled by one company.

Flash also has performance issues. While it claims to be interoperable between different systems, there are some noted differences. Flash Player on OS X based machines performs slower and takes more processing power than its Windows counterpart. New technologies, like HTML5 are helping to combat this issue and remove our dependency on Flash for video. HTML5 video will be less processor intensive. It will also make video a native part of the web instead of an optional, separately-installed plug-in. For now though, the major browser vendors haven't decided on what the default video format should be. This indecision essentially removes any interoperability that would otherwise be inherent. Format wars notwithstanding, look for HTML5 and the new "video" tag to soon start replacing Flash as the go-to video solution.

But Flash Player can do more than play video. Video is at the heart of the discussion, but other features like animation, hardware acceleration, and device access have made Flash what it is today. HTML5, even when combined with the web programming language JavaScript, does not currently have such an advanced feature set. JavaScript and ActionScript (the Flash programming language) share a common ancestor, ECMAScript. Unlike ActionScript, however, JavaScript has not been seriously updated in a long time. JavaScript is periodically updated, but those updates are not all supported in every browser, again taking away the interoperability.

In conclusion—Flash is not dead. It may be past its prime, but until browser makers and the web developer community can form a more-solid set of features and standards and get nearly ubiquitous market penetration, Flash will still be around. Flash Video will be the first to go, unless media companies don't see HTML5 video as a safe (i.e. pirate proof) solution. Flash as a development platform may never die. Adobe is already broadening the platform's reach with products like AIR which will make it possible to use the Flash authoring tool to create application for the iPhone and Nexus devices. Flash Player 10.1 will be available on a large set of mobile devices. As long as developers use the right tools for the job (i.e. don't make a 100% Flash website) and follow best practices it won't matter what technologies are around. That said, if you are Flash developer and you've never heard of HTML5 you may want to start looking in to it, right now.

 

Comments (View)

 

 

The current HTML5 working spec gives the script tag some interesting new attributes. The first is "defer" which tells the browser to wait until the page is ready to run the script. The second is "async" which tells the browser to, when possible, run the script without blocking, or asynchronously. While the benefits of using "defer" may be more-readily perceived, asynchronous JavaScript is a little harder to grasp.

To implement the async attribute, you must add is as an empty string or with the value "async". Even though it is a boolean attribute, the value "true" is not accepted, though different browsers may be kind in that regard. The async attribute can only be used when the "src" attribute is also being used. Inline JavaScript cannot be asynchronous. A script tag with async turned on would look like this:

<script src="code.js" async></script>
or
<script src="code.js" async="async"></script>

The same implementation is used for "defer".

You should not use document.write in your asynchronous JavaScript. Because the browser does not block, and because you cannot be sure the DOM is complete, doing so may break or completely remove the DOM.

To see async in action you need a modern browser. Firefox 3.6 will do the trick.

I have put together a couple of examples on using the async attribute and decided it would be best to demonstrate them in video. The following video shows the script running in regular, blocking mode, and then with async turned on. I am using Firebug to dramatize the difference.


Sorry for the bad audio quality.

So, what if you still need to do document.write? Well, you can use a regular JavaScript call to insert whatever you need on to the page, then add a script tag to the head with the async attribute to act upon the items you have inserted. In this way you can have a lightweight script that ads a few small things to the DOM, then the browser can load the async script and run it as it will.

Some things to note:
1) If loading JavaScript asynchronously, you may need to be sure that you don't have code elsewhere that depends on that script being loaded. It may not always load before you need it.

2) Currently it seems as though it will load multiple JavaScript files asynchronously, but in order. Some have reported that as currently implemented that is not the case. It may depend on the browser, so again beware if you have multiple files that rely on a shared library.

This change will most likely be beneficial for things like ads or widgets that have self-contained scripts that run on the page. That way the ad and widget code won't block the rest of the site if it is slow to load.

Here is the code used in my video demo:
http://www.lemieuxster.com/dev/js/asyncTest.html
http://www.lemieuxster.com/dev/js/asyncTest2.html
http://www.lemieuxster.com/dev/js/asyncTest.js
http://www.lemieuxster.com/dev/js/contentInsert.js

On a semi-related note, I recently finished JavaScript: The Good Parts and I recommend it to anyone that does any amount of JavaScript coding. Especially if you are like me and have learned JavaScript through mostly trial and error. It lays down a solid foundation upon which to build JavaScript expertise. It is not a book for beginners, but it does cover the fundamentals.

 

Comments (View)

 

 

Widgetbox, my current employer (full disclosure), recently introduced a slick mobile site builder. It works much like our popular Blidget product. You take Internet feeds and other content sources and include them in to a mobile-compatible web site. It literally takes minutes to get a basic site up and running and it works really well. My hats off to the team at Widgetbox that put it all together. I got to help a little, but I have been working on another project.

One really nice feature of the mobile site is that Widgetbox gives you a JavaScript snippet to put on your normal site that will redirect mobile users to your new mobile site. I put a mobile site together for myself and now whenever you visit this site or my portfolio from a mobile phone (iPhone, Android 2.0, or webOS) you will see my mobile site. For those of you on a non-mobile computer, it looks a lot like this:

David LeMieux Mobile Site
This Is Huge!

You can also go take a look at http://m.wbx.me/lemieux if you use Safari or Chrome.

As I stated before, in a parenthetical, the mobile sites currently work best on the iPhone and Android 2.0+ phones. The sites work decently on webOS phones, but the webOS browser isn't as feature rich. webOS 1.4 did improve things quite a bit, however.

For those interested in the technology we are using, it is mostly based on JQTouch though I know the team made some enhancements and other changes.

I encourage anyone interested to give it a try. Especially since having a mobile presence is becoming increasingly important.

 

Comments (View)

 

 

Let X equal the amount of time since an event, E, has occurred. Let Op equal the predicted occurrences of E over the lifespan of the event's perpetrator measured in time, L, and let Ok equal the known occurrences of E.

The probability of E increases as X increases according to:

P(E) = (X(Op - Ok))/L

*thanks to Steve Astle for the inspiration.
**this is also known as the Gambler's Fallacy
***I love The Onion

 

Comments (View)

 

 

I added a not-so-subtle Amazon affiliate link to E.ggTimer. Why? Ever since closing up shop at WidgetNest my web projects have been a drain on resources instead of self sustaining. Also, I really want a new bicycle (my old bike was stolen).

The last time I tried something like this I got about $20 over a two year span. We'll see how well it works out this time.

I had intended to use Google AdSense but they didn't think my site was cool enough. Actually, at first my account was stuck in some never-ending black hole of not being able to sign up because I already had an account, but not being able to use my account because I hadn't actually signed up. When that was finally resolved I applied and got denied. The official reason is because E.ggTimer "looks like it is under construction." I took that as meaning they couldn't find any content that would be relevant to advertise against. I don't blame them. It really is just a utility site, so there isn't much there in the way of content.

As far as making my sites self-sustaining goes, I at least have the luxury of being able to afford decent web hosting. That said, why not strive to have a product that can keep itself afloat? If I can break even I'll consider it a success.

 

Comments (View)

 

 

If you have any interest at all in the current "Is Flash Dead?" debate (http://isflashdead.com) then you might want to read the following:


That is all, for now. While I wrap my whole head around this one thing definitely sticks out: there is a lot of pent up animosity toward Flash for some reason. I continue to love Flash, but I've never intentionally pigeon-holed myself to it. I will continue to build cool things with whatever technology I see as the best fit.

 

Comments (View)