I hereby decree

 

Merry Christmas!

Valerie and I don't often remember to send out holiday cards. You know the type, the ones with a picture of the family and sometimes a note recapping the year's activities. We always talk about doing it, but never do it.

This year on Christmas Eve I had an idea to make a digital card. The original idea was something like an 8-bit snow-globe but I knew the first thing Val would say would be "but our picture doesn't look very clear" (or something along those lines) so I came up with a little trick. The picture starts out clear, but then as the 8-bit carol plays and the holiday greeting appears from the bottom, the picture is blocked in to a more 8-bit-like image (not true 8-bit, of course). You can check it out here, make sure to have your speakers on.

I have been doing a lot of Flash programming at work so for this card I decided to use just HTML, Javascript and CSS. I took advantage of some of the code libraries I made this year, like Cigar and my previous canvas experiments as well as some third-party code libraries, mostly from Grant Skinner. I tested the card in Chrome, Safari, and Firefox (all the latest version) and I took a glance at it in IE. The only major difference was that I still haven't gotten the font-face to work in IE.

In theory it should work on mobile safari or any html5 compliant mobile browser but it doesn't because of restrictions in place by those browsers (e.g. no sound loading unless dictated by user action). I could have added more support for those devices, but I put this together in about three hours late Christmas Eve and any more time spent would have meant it wouldn't have been ready for Christmas Day. It almost wasn't as it is.

My favorite part is the snow, and my lovely family of course.

UPDATE: I added support for iOS devices now, too.

 

 

Sometimes you need an invalid feed or some random artifact crucial to helping you debug and test your web application. I hope to turn My Imaginary Site a resource for just that.

I've owned the domain for long enough now. I purchased it as a kind of personal inside joke. Now I want to make something useful of it. I have been ever-so-slowly filling it in, and it is still really sparse.

Please send any suggestions my way.

Keep in mind that this isn't meant to be some amazing end-all be-all resource. I just want a quick index of all those things you find yourself needing in application development. "Man, I really wish I had a way to load a feed url that timed out after 'n' number of seconds." - I will soon have a link for that up on the site. So that kind of thing.

 

 

It is with a little sadness that I admit that I did not participate in this years Trunk or Treat.

Sigh.

I had an awesome idea and about a month ago I got started on the beginning work for it. Somewhere along the way, though, it became apparent that I wouldn't be able to complete it and unfortunately after that I never switched to another, perhaps easier, idea.

The creative process is interesting. Not every idea takes off and of the ones that do not many are ever completed. I am not upset that I wasn't able to participate this year and protect my reign as King of the Trunk or Treat. In fact, it was relaxing to just take my kids and enjoy the evening. But when I am not making things I feel like I am just sitting around twiddling my thumbs. It isn't a feeling I like.

That is why I am such a proponent of just doing things. Have an idea? Work on it in some small way. A sketch. A list. Initial research.

This has been an off year. I have gotten a lot done, but not in the areas I expected.

 

 

A few weekends ago I got to participate in Node Knockout with some friends. It was a 48 hour contest to see who could come up with something great using Node.js. My team, myself and some coworkers, decided to try and make something like a multi-user game platform where you could use your computer screen as the output screen and a second device (mobile phone, for example) as the game controller. What we came up with was Fly By Wire (more info).

It was a lot of fun but there are some pretty bad bugs. We didn't win either. But I learned a lot about Node.js, CoffeeScript, and web sockets. I hope to do it again next year.

 

 

I've been doing some experiments with JavaScript and the Canvas tag. Here are some results:


Starry Blocks


Launch Pad Quads

The first just traverses an image and chunks it in to blocks of a configurable size and displays the average color for the block. The second recursively subdivides the image based on color threshold and size and then, again, displays the average color if the rules are met.

You can see them compute live here and here. (Google Chrome or a very modern browser recommended)

The code isn't completely optimized, and I have found some interesting irregularities while working with the Canvas Context object, but in all it seems like a straightforward piece of technology.

For more Canvas fun, check out EasleJS by Grant Skinner (not used here). He has essentially taken a lot of the vocabulary and paradigms from Flash and ported them over in to a performant Canvas render engine.

 

 

Part 1

So, its been a year and I would like to re-comment on the state of Flash. Flex/Flash consultant Jesse Warden put up a nice post today about some current Adobe news. One thing Warden mentions is the fact that the passion behind Flash is dying, not the technology itself. I would add my voice to that same sentiment.

In my own professional life (I am not a consultant) I have been using Flash less and less as time progresses. This has nothing to do with the platform or its capabilities. It has a lot to do with how my company values Flash and the time we decide to put behind it. Flash continues to be an important part of what we do, but many of our new projects are striving to be Flash-less. The reasons for this vary, but the biggest are these: 1) We are trying to be cross-device compatible, inclusing iOS. 2) We are a group of young, "hip" developers that often get caught up in the new coolness.

Lets talk about reason #2 for a moment. Things like Node.js and Ruby as well as the many GitHub projects are the cool thing at the moment and are proving to be fun to play with. In an effort to say ahead of the curve and also be a part of the "bleeding edge" we sometimes pick new technologies over old ones (it is also very educational). Bottom line, we never say "lets use Flash to implement this cool new idea."

So, it doesn't matter that in many cases Flash would be a great solution.

There are allegedly some cool technologies coming in newer versions of Flash, but I haven't felt the need to look in to them. If I am any indication (and I don't know that I am) I would say that the trend is similar elsewhere. (Also, I've seen demos of WebOS running Flash and yet it is still nowhere to be seen.)

There are a lot of cool new toys to play with, and whether because of marketing or timing or any other reason the new Flash toys just aren't as stand-out and amazing any more. It used to be that if a developer made a cool Flash library they could get some traction and some attention. Now the new hotness is putting up a new JavaScript or Ruby project on GitHub.

So Flash as a technology is still not going anywhere, but it may start to disappear if the community stops caring.

 

 

I've been working on a side project of sorts. What makes this one different is that I don't know where it will take me. I would like to introduce Cigar.js - a JavaScript dependency importer. Basically, it acts kind of like import does in Java, but it works client side and it is for adding JavaScript files to your runtime environment.

It works like this: After loading the Cigar.js file you can call _import and load javascript files from your own domain (for now, though I do hope to add the ability to do external files as well). You can chain the imports together, essentially creating a queue of files to load. At the end you can specify a callback that will be initialized once all the files have been loaded.

I've had this idea in the my head for a while now, but it wasn't until I saw a tweet from Jeff Remer that I thought "well, Groucho always has a cigar, so I should make a js library called 'cigar'."


Yeah, it was all based on a bad pun

What is emerging from this wandering idea of mine is that you could use this to structure your JavaScript files more like Java classes. This could be handing for creating reusable code snippets and have dependencies, but help remove all the circular references.

You could have a utility "class" called "AwesomeUtility" that is used in "Object1" and "Object2". Cigar would allow you to save those in separate js files and test them independently, then you can use Cigar to import them in to your main script file and the dependency will only be loaded once.

As it is, Cigar is no-where near production ready. There is still a lot to test out and play with. Also, I have know idea where this is going.

 

 

I sometimes get to work while I ride in to The City on BART and I am always a little disappointed that my coding/terminal skills don't seem more hackeresque, especially when someone is looking over my shoulder. Though I certainly don't want to have my computer taken away for looking suspicious I decided to make my onlooker's experience more fun.

Today while on BART I put together this little number:


I'm in your phones, hacking your numbers

What this really shows is a bash_profile alias that points to a Java thread I made that spits out a random quantity of random, not even valid, phone numbers at interchanging intervals with either a success or failed message. It then tallies the successes and outputs the success/total ratio at the end. What it looks like it is doing, though, is hacking all the nearby phones.

Why make this? So that the people sitting next to me get mildly freaked out. I mean, to start this baby up I have to type "hack_nearby_phones". Everything Hollywood teaches us about computers allows this to make sense, so it will surely fool everyone.

 

 

I hereby decree that the links section shall be restored. Just visit http://iherebydecree.com/links and see for yourself. I started this links section a long while ago and then stopped as I found that I was user Twitter and Facebook more for sharing. Time has passed and again I find myself wanting to consolidate.

For the three people that read this blog, I hope you enjoy.

 

 

Bow chicka bow wow

Err... wait, Inception. I really enjoyed the film. It was a great action movie; intelligent and original enough to be worth watching multiple times.

One aspect of the movie I really enjoyed was the musical score. In fact, I find myself keen on many of the movie soundtracks composed by Hans Zimmer (Batman Begins/Dark Knight, Pirates of the Caribbean, Sherlock Holmes, and more).

Anyway, if you've seen Inception you know that the protagonists do much of their deeds in a dream state. In fact, they induce dreams within dreams. For every level deeper they go in the dream worlds, time slows down. In other words, you have more perceived time in a second layer dream than you do in a first layer dream, even though the same real time is passing. Confused? Watch the movie.

Whenever they want to be awoken from their dream state, someone has to initiate a "kick" - or some kind of semi-violent wake up call, like the feeling of falling or being hit. To signal that said "kick" is coming, they use an audible hint: The song Non, Je Ne Regrette Rien by Edith Piaf. (Seriously, if you are totally not following me go watch the movie then come back.) So that is why when I found this YouTube clip:


Same music, just slowed down.

I was amazed. "What a clever trick," I thought to myself, "I wonder if it is on purpose. It has to be." It turns it was. In fact, Hans Zimmer has admitted that much of the soundtrack is based on that one song.

So, a clever movie with a subtly clever soundtrack. If you haven't seen it already, go see it. Now.

 

 

We got your back, Frodo.

 

 

At work I've begun to use JS Test Driver to run JavaScript Unit and Functional tests. It was very easy to get up and running and it is more-or-less straight forward to use.

Specifically, I have been using the IntelliJ plug-in. It was easy to install and get started, but it does seem pretty finicky and there doesn't seem to be any reliable way to determine what version of JSTestDriver the plug-in uses, only the version of the plug-in itself.

I have never been big on test-driven development but I am starting to be converted to its ways. Of course I would test and validate that my code worked as expected, sometimes even putting it through peer review and a light layer of function stress testing. The idea of thinking about test in a more prominent way, however, is mostly new to me. So far I've found that it can be quite helpful.

My first positive experience came this week when I was writing a test for an already-in-production piece of code and the test failed. It failed on a strange edge case, but it failed nonetheless. This enabled me to fix the issue before anyone else could find in the "real world."

"Of course," you say, "this is what testing is supposed to do." But I feel like it takes "ah-ha" moments such as that to reinforce a concept and I had never had one with testing before.

If you are looking for a way to test your JavaScript code, give JS Test Driver a try. QUnit and JsUnit are also available though I have limited experience with the former and none with the later.

 

 

So, it took a while (sorry Ben) but Steep.it - the tea timing cousin of E.ggTimer - now has mobile support.


Screen shot from early test version on Palm Pre

Features

I decided to go a step beyond the mobile implementation I did for E.ggtimer. Mostly because Steep.it has a much more compelling multi-use case. Here is what you get:

• Offline support: Yep, if your device/browser supports HTML5 manifest files you should be able to bookmark your favorite tea timer and come back to it later, even if you aren't connected to the internet.


• iOS Home Screen Icon: Add the timer to your iOS home screen and you will have an always-ready timer.


• Core upgrades: This is less noticeable (hopefully) than the others, but I updated the core E.ggTimer mobile code to be more flexible and more efficient.

Of all the features, the Offline support was probably the hardest to test.

A Rant
(I apologize up front for being such a whiner.)

Unfortunately a recent update of iOS broke some of the functionality. I suppose what I was doing before was a workaround, but now you can't invoke sound or media to play through JavaScript in HTML5 on certain mobile browsers (iOS 4.2, some android) unless through user interaction.

This makes sense from a bandwidth point of view, but it is frustrating that companies like Google and Apple tout HTML5 as a solution for building mobile web applications but then remove some of the abilities. It is, of course, their prerogative to do so and it probably makes sense, but having to special case how the app runs depending on what device it is on seems like the very thing we were trying to get away from.

Obviously web applications developers like myself need to remember things like progressive enhancement, but because of native apps any "downgraded" (or not enhanced) performance from a mobile web app appears even more dramatic. For example, why can't the timer play a simple noise at its expiration? (Answer: because javascript can't invoke the sound in the device browser without direct user action).

I have already thought of ways to work around this issue, like require that the user "unmutes" the sound - which would put it in to a playable state. Or that instead of auto-starting the timer the user has to start it manually. Both of these options, though, break from the most basic user experience of E.ggTimer and Steep.it - that you start the timer via URL and don't have to do anything else.

But enough complaining. As the mobile and web worlds continue to merge and collide new solutions and opportunities will present themselves.

Try it out
Just go to Steep.it on your mobile device and give it a whirl. You will be redirected to steep.it/m and all your wildest tea timing dreams will come true.

 

 

Every year my local church congregation holds a Halloween event called "Trunk or Treat." Children dress up in costumes and go Trick-or-Treating from car trunk to car trunk in a closed off parking lot. People decorate their cars and it is a lot of fun.

Since moving to California we have participated every year and each year we have won "Cutest Car." Two years ago I quickly put together a Pumpkin Car. Last year I had a lot of ambition and free time and I made a Working Photo Booth. This year I didn't have quite as much time and I made a Car Mouth. I have not hidden the fact that I have been trying to win Most Extremely Awesome Car of All Time but I don't know what the categories are and if that is even an option.


Car Mouth about to devour my daughter.

Unfortunately on the day of the event our camera batteries were dead and by the time we realized it, it was too late to do anything. Therefore I don't have any "at the Trunk-or-Treat" photos. Or any photos of the final product, for that matter. Oh well.

Parts

Not pictured, the red pillow tongue and the gray mouth lining.

The mouth was made up of these basic parts:

• Teeth: Cut from thick presentation board


• Tongue: Made of a plain red shirt over a pillow


• Uvula: Cut out of construction paper


• Mouth lining: A large grey piece of fabric. (The backdrop from last years photo booth)

It was all held together with packaging tape and duct tape.

Award

Funniest is not cutest. It's a start.

This year we were awarded Funniest Car. We got this cool certificate (pictured above) and some chocolate ghosts from See's Candies. They were most delicious.

While I am somewhat relieved to break free of the "cutest" category, I can't help but wonder what made my ferocious, flesh-eating, murderous car so funny to the judges. My guess is the uvula.

 

 

Perhaps not an original idea

Just threw this together. Scan it with your phone or other QR reader and visit the site it points you to. Enjoy.

 

 

I have a backup of many, but not all, of the Jots made in J.otDown. If you would like to take a stab at data recovery, please send me the url to your Jot and I will send you back the file.

Please note, not all Jots were saved. The reason I had to shut J.otDown off was due to database memory. This means that some of the data was lost. Recently updated Jots should be in tact but I make no promises. I apologize for the inconvenience.

Also, going forward I would like to recommend Notepad.cc as a simple replacement for your jotting needs.

 

 

Today I made some tough decisions. I turned off PictureNest and I decided to shut down J.otDown. The driving factors for these decisions are varied, but ultimately the same result comes of them; I no longer have to worry.

PictureNest
PictureNest, to be brief, was a fun project that allowed people to take photo-booth-like photo strips using their webcams. The images were hosted on Amazon S3 and I created a uniquely database-free environment that made scalability a non-issue; nearly 30,000 strips (or 120,000 pictures) were taken in a time-span of almost a year. It was awesome. Recently, however, people have been using PictureNest to create obscene and inappropriate images. Ultimately I wanted the site to be G-rate (or PG), and I didn't want to have to manually moderate all the images every day. Neither did I want to face any trouble that may have come of it.

It was not an easy decision, and the problem wasn't unmanageable yet, but it was a preemptive strike against future problems. It is sad it had to be so.


J.otDown
J.otDown has been more or less useless for the past few weeks. My database account maxed out on file size and I didn't find a suitable replacement. I did make some headway on creating an S3/SimpleDB version, but ultimately decided that I really don't have the time. My life has gotten a lot busier, in good ways, and instead of trying to maintain a site that would eventually need more updating I again decided to plug the leak.

I hate to turn off things I make. It makes me sick, almost physically. I feel like I am letting people down. I feel like I am losing a part of me. That said, I now feel like a burden has been lifted.

Am I running away from the problems? Maybe. But I honestly don't feel like I have time to face them. The problems were not insurmountable, but there is a tipping point when something turns from a hobby in to a full-time gig. Sometimes that can be a great thing. This time, however, I contemplated that path and decided against it.

I may bring these services back. They will most likely be back in a different form.

For now they are over. I hit the reset button on my personal projects. The only real survivor is E.ggTimer and even that needs some attention. I will get to it soon, I hope.

 

 

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.

 

 

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.

 

 

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.

 

 

The Emperor is not pleased.

Inspired by @gpenston's tweet.

 

 

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.

 

 

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.

 

 

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:


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.

 

 

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

 

 

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.

 

 

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:

• Apple, Adobe, and Flash


• Flash, iPad, Standards


• Hands-on with the iPad - it does make sense


• Who Can Do Something About Those Blue Boxes?


• I need to talk to you about computers...


• Building iPad Applications with Flash


• The iPad provides the ultimate browsing experience?


• HTML 5 and Flash video


• Open Access to Content and Applications


• My Thoughts on the Future of Flash


• Flash, Google, VP8, and the future of internet video

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.

 

 

My own kids were afraid of me!

Or How I used candy to get children to sit on my lap and tell me their deepest desires.

Due to a last-minute schedule conflict, the designated Santa was unable to make it to the Christmas party. I was asked to fill in. I resisted at first, but then I had fun. The beard made me gag.

Huzzah!

 

 

Oops, you are so two thousand and late.

J.otDown got a small update this weekend. As I work to improve J.otDown and enable multi-user collaboration and editing (which is going to take while, I am busy!) I have been trying to take small steps. The first finished step is alerting the user that changes have been made. Now when you try and save the Jot, if it is out of date you will be alerted. You can then get the latest (and lose your changes) or save the file and overwrite whatever was there. It isn't perfect. In fact it may even be confusing, but it is a step in the right direction, I feel.

 

 

Or How I lured children to my car with candy then took their pictures.

Every year my church congregation holds a Halloween activity called "Trunk or Treat." The premise is simple, it is like Trick-or-Treating except it is done in a parking lot from car trunk to car trunk. It is a fun activity with games, candy, and some friendly competition.

Last year I totally spaced the event and with less than half an hour before starting I whipped up an "award winning" design. We won the "Cutest Car" prize. This was satisfying, but part of me wondered if I could win "Most Awesome Car" or "Super Deluxe Ninja Car of Extreme Skill and Coolness" (I don't even know if that is a real category, but it should be). Anyway, I more or less forgot about it until this last September, 2009. That is when I came up with a plan.


Look at all that technology!

I was working on PictureNest at the time as a fun side project when it struck me that it would be super awesome to make a real photo booth. Around that same time people at church began to talk about the upcoming Trunk or Treat activity. Genius struck. I would make a real photo booth in the back of my car and crush the competition. No more "Cutest Car" for me. I was going to make a trunk so awesome that the Super Ninja category would be invented for my sake.


The Parts:

The Photo Application: This came easily. Mostly because I took what I had already made for PictureNest and turned it in to an AIR application. I added a few new features and tested it thoroughly for memory leaks and performance.

The Print Service: I wanted the user experience to be that when someone got their photos taken at the end the photos would print immediately and without having to confirm printing. AIR, unfortunately (and for good reason) does not allow this. My solution was to save the photos in a known directory then asynchronously read that folder and print whatever was inside of it. Not 100% fool-proof, but since I would be running it myself I could be sure that things were set up properly. I turned to Java for my printing needs. I wrote a handy Java print service (which only worked on Windows, more on that later) that would scan a given directory for images then print them to a chosen printer. It worked wonderfully. Again, I tested this service for memory leaks and performance over time and with high capacity.

The Computer: I had originally planned on using my work laptop to run everything. It is small, and would travel well. It would not, however, print. Apparently, and obviously I suppose, the print services aren't the same on Windows and OS X. I was developing on Windows but I figured that because I was using AIR and Java that moving to a new operating system would be cinch. I was mistaken. The AIR app worked perfectly, so props to Adobe. I didn't take the time to try and figure things out, and so I suppose the Java printing issues could have been worked out.

The Printer: My trusty nine-year-old Ink Jet worked like a charm. I used HP Photo Paper, cut to 3 by 8 inch strips.

The Booth aka Car: The back of my car, a hatchback, was big and roomy and perfect for a photo booth. I used a Gorilla Torch to light the backdrop. The backdrop itself was made of some bargain fabric from the local fabric store and a hat rack I rigged to hold the fabric like a projector screen. I used a folding camping chair for people to sit upon.


The Set Up

With all the parts planned out I had one major obstacle to overcome. If I was going to run a computer, monitor, web cam, and printer in the back of my car with lighting I was going to need power. I researched every conceivable battery/generator/car-adapter method I could think of. When it came down to it, though, unless I wanted to spend a ton of money on a probably noisy power generator I was going to have to plug my car in. But where? I searched the entire perimeter of the parking lot we were going to be in and eventually found one outlet. Just one power outlet! Luckily it was fairly close to a parking spot but it meant two things. First, I had to get to the spot early to make sure I could get it. Second, since I didn't have anything to test it with, I was going to put a whole lot of work in to something that might not even be able to turn on.


Claire helped me do the signage.

The day of the Trunk or Treat went so smoothly that I thought nothing could go wrong. I got home in time, I took the car to the church and got the perfect parking spot and I double and triple checked my supplies. I was ready. When it was party time, we walked over to the church building and had a generally fun time. Our kids were pretty cute (Tinker Bell and Peter Pan, in case you were wondering). Then I went out to the car to set things up.

I got to the car, opened up the trunk and got out the extension cord. I plugged it in to the equipment in the back and then rolled it out to the wall. I was three feet short. I almost started to cry. I had estimated that a 50 foot cord would do but apparently I needed 53 feet. Did I let three feet stop me? No. I was prepared to drive my car up on the curb if need be. That said, I had a bit of serendipity as I saw some other people taking down the haunted house portion of the party and I got to borrow another extension cord. I ended up with 47 feet too much.

Disaster averted, at least until I started to set up the backdrop and a crucial piece of hardware went missing. I wasn't going to be able to put up the backdrop but then I spotted the hardware underneath a neighboring car. After that I got everything set up and turned on the computer and started the program. Then I unplugged the keyboard and mouse and plugged in an external keypad I had bought to use as the starting mechanism. All you had to do was hit "ENTER" and away it went!


The Crowds

My proximity to the outlet was important for functionality, but one thing I hadn't counted on was that everyone with cool trunks would conspire against me and park on the opposite side of the parking lot. In theory, anywhere in the parking lot was game, but by some weird coincidence (or unspoken rule) everyone parked in one area. So no-one came by for a while until a group of more adventurous older kids came over. They were impressed. The first group left and then soon returned with even more of their friends. Then, as time went on and the word got out there was a line. Lots of people, and groups, wanted to get their pictures taken. Unfortunately my printer, stalwart as it is, was not very fast. So towards the end people were waiting as long as 10 minutes for their prints. This fact drove people away, I think. I ended up having 50 people use the booth though more might have done pictures if not for the long wait time. I tried to be upfront with people as best I could. I even encouraged leaving and coming back later to pick up your photo, but not very many people listened. A good crowd of people surrounded my car the rest of the night.


What the pictures looked like, mostly.


The Award

So, as I had hoped I was given an award. "Cutest Trunk" - can you believe it? The judges said they loved my trunk but didn't know what category to put it under and "most awesome" wasn't a category. (I don't know what the categories were, but I am imagining something like "spookiest" and "best candy")


Cutest Car? Again? COME ON!


The Code

I want to make the code for this available, but I am currently in the process of moving from Windows Vista to Windows 7 and have not yet reinstalled my development tools. Once I do that I will make the code available, but as you can see it has taken over a month to write this blog post about it, so lets see how long it will take me to get the code up.


What's Missing

I didn't get many pictures of the actual event, ironically. Nor of the final setup.

PictureNest: http://www.picturenest.net