unwiredben

If you've not seen my Twitter feed, you may not know that on Monday, I'm returning to a position with Palm. I'm heading back to be part of their Developer Relations group, reporting into the dynamic team of Ben and Dion of ajaxian fame that Palm brought in last summer to shake things up with webOS.

It was a hard decision to leave Mozilla; they've been very good to me over the last year, and I feel pretty happy about the 1.0 release of Firefox for Maemo (aka Fennec) that came out in January. I'll miss the fun chats on IRC and the visits to their offices in Toronto and Mountain View.

However, in the last year I found that my real passion lies in communication and teaching. I'd had a blast with my classes at NYC Resistor, and I've loved working with developers in past positions at Metrowerks, PalmSource, and Palm. Being the expert in an online forum suits me very well. With that background, I'm looking forward to evangelizing the webOS platform, and I hope that I'll be able to assist some people in writing great native apps and plugins on the Palm Pre and Pixi phones.

Wish me luck! I'll be posting details on my new Palm webOS developer blog as soon as it is ready to go.

This is for reference by future programmers using Google to find out something on this topic.

When using gdbserver with the Android 2.0.1 emulator to debug native command line applications, you can get into a situation where it won't stop the child application, instead letting it run to its death before setting up the debug connection to gdb.  I wasn't able to figure out why this was happening, but rebooting the emulator allowed for the correct operation again.  When you start getting communication errors from gdb, a reboot is a good call as other things may be hosed.

The first time I had spaghetti squash was as a kid; it was mushy and too sweet and just didn't work for me.

Fortunately, Annelies reintroduced it to my life a couple of years ago, and I attempted my own version last night.  It was really simple and very tasty.  You can make it in about fifteen minutes.

1. Mince garlic.  Take a few cloves of garlic, chop into little pits, and fry up those bits on medium heat in a skillet in olive oil.  You want little golden crisp pieces, about the same size and crunch as vegan bac'n bits.
2. Stab the squash.  Take a knife and poke about sixteen slits in the squash.  I did four rows of four.
3. Microwave the squash on high for four minutes, turn over, go for four minutes again.
4. open a can of Rotel tomatoes.  You can pick your variety depending on your spice level.  If you don't like spicy, go for diced tomatoes and basil.
5. Cut the squash in half lengthwise.  Use a fork to scoop out the seeds and throw those away.  Then use the fork to remove the squash flesh.  It will already be stringy, and if you use the fork to scrape out the shell, you'll have plenty of the squash threads.
6. Put a portion of squash in a bowl, apply black pepper, salt, Rotel, and some of the garlic bits.  Put this back in the microwave for a minute to heat up the sauce.
7. Enjoy!  You can add some grated cheese too to make it more savory.

I also tried this with some homemade pesto, but I found that creaminess didn't go as well with the slightly sweet squash as the tomato mixture.

Note: using the microwave is key.  It allows the squash to cook nicely inside the shell without getting mushy and gives it a great texture.  I think the time I had it before where I didn't like it was because the squash was cut open and cooked on a stove like noodles.

So, the Chumby One has been my main hacking activity for the last few weeks. Here are some of the things I've done:

1. made a viewer for items stored in a drop.io "drop" with my fellow NYC Resistor hacker Eric Skiff. This ended up winning the drop.io hackathon.  This is now documented at http://code.google.com/p/chumby-dropio/.
2. made a SMS powered doorbell for NYC Resistor. This is a mashup of TextMarks (used to receive a text message with the payload "NYCRDOOR R", Google App Engine (running a couple of Python scripts that implement a simple counter), and a Perl script running on the Chumby (this pings the App Engine scripts looking for a counter change). When it sees the counter change, it plays a doorbell sound quite loudly.
3. got a audio monitoring script running on the Chumby's web server. You can access this URL from VLC or some other streaming client and listen to what ever is happening near the device.  Details at http://forum.chumby.com/viewtopic.php?pid=26321#p26321.
4. made a Chumby widget to show the password-protected webcam inside the NYC Resistor space. This required making a proxy on Google App Engine as there's no way in Flash Lite to specify the Authorization header needed to pull down the picture through the normal loadMovie call.
5. make some simple one frame Chumby widgets using the free SWF Tools. I used this to make a NYC Resistor logo widget that's played from time to time on the device in the space.
6. mount my music volume over NFS so I can SSH into the Chumby and play music files from the command line. Details at http://forum.chumby.com/viewtopic.php?pid=26346#p26346.
7. built my own copies of busybox and elinks that give me updated command line utilities and a text-mode web browser on the device. Those are available online at http://drop.io/chumby_utils.

What's next? Get a better text editor than the busybox version of vi onto the device. Make a on-screen clock based on photographs of the MakerBot Watch. Finish getting DOSBox running on the device. Make a Twitter feed reader that lets you put QR Codes on the screen for the links in the messages so you can read the linked page on your smartphone.

I've been playing a lot with the Chumby One I got in December... I like it much more than the original Chumby, and it sits nicely on my desk playing widgets under my monitor. It also played a huge role in helping me and my friend Eric Skiff win first place in the drop.io hackathon -- our project was a widget to show photos and voicemails from a user's "drop".

So, I'm taking all this knowledge and giving it back in the form of a class at NYC Resistor in February. It's called "Hacking the Chumby Device", and it's two hours of hands-on Linux and Flash hacking goodness. If you want, you can sign up at http://hackingthechumby.eventbrite.com and if you use code "BENCHUMBY", you'll get $5 off.

A few people asked about the playlist we used at the wedding reception... I just grabbed the file list off my music player and have posted it under the cut. We had it running on shuffle, so I've got no idea what the order was.

( Read more... )

I've been wanting to make something with the Fennec logo for a while, so after getting some experience with the NYC Resistor laser cutter for another project, I decided to try my hand at making a laser-cut Fennec. This one took about four minutes of Epilog laser time, most of it spent in the etching of the details. I imported the logo from a PDF file into Corel Draw, edited the internal vectors so there were no vectors that would cause cutting, then made a new outline around everything that I marked as a cut line. The material is opaque blue acrylic, but for a final run of these, I'll use a very nice transparent blue that we've got in our stockroom.

Just a reminder to you all that we've got some great classes coming up at NYC Resistor.

First, this Saturday, Raphael is teaching about the wonders of the Joule Thief!  It's a class about how to pull every bit of current possible out of little batteries. If you want to run something for a long time, check this out.  Details at http://joulethief.eventbrite.com/.

On Sunday, Liz and Ryan are leading an Arduino workshop where you get to solder up a Freeduino kit and then make it do amazing things.  If you want to get your hands dirty, this is the class to take.  There are just a few slots left for this one. http://arduino101.eventbrite.com/

On Sunday, November the 8th, Chris is teaching "CPUs 0b1100101: Intro to computer processors".  We've been talking about it here on the list -- it's all about computer architecture and how those chips that power your computers and devices work. http://cpus.eventbrite.com/

I'm very excited about the Build Your Own Retrocomputer class on November 12th.  Vince Briel is coming in from afar to lead a session where you can build one of his kits, including the Replica 1, a clone of the original Apple I.  It's way cooler than having an iPhone. There also will be a bit of an intro on the Parallax Propeller chip that's used in both the PockeTerm and Replica 1 included.  Details at http://retrocomputer.eventbrite.com/.

Finally, I'm teaching my popular Webduino class again on November 22nd, just before Thanksgiving.  Won't time with your family go even faster when you've got an Arduino acting as a webserver in your home? Come to the class and find out how you can make it happen.  It's online at http://webduino.eventbrite.com/.

These classes are fun, and they help keep NYC Resistor alive and in our great space in downtown Brooklyn.  Come down and learn.

(Update: version 1.3.1 is now up due to a nasty bug found over the weekend.  I didn't test as well as I should have.)

I've updated my Webduino web server library to version 1.3.  This was prompted by a discussion over on arduino.cc where a user was having problems communicating with the server from his cell phone.  I looked at the "read a new character from the network" logic and realized that a slow connection could let the Arduino think the client had finished its request when it really was just waiting on a new packet from the sender.

When I fixed that, I ran into a new issue.  Modern HTTP clients will usually make a request in "keep-alive" mode.  This means they don't close the socket when the finish asking the server for data, but instead keep it alive in case they want to send more requests.  So, to determine where I was done reading POST data, I needed to look at the Content-Length header passed with the POST and kill the connection after reading that many bytes.  Before, this wasn't a problem, as I'd just assume the connection was dropped when I didn't have any new data coming in from the client.

These fixes are in v1.3, along with some code you can turn on to debug your server's responses (it does slow things down a bit because the serial output code doesn't run in the background) and a fix for a possible security hole in parsing POST requests.

If you're into it, get the new code from http://webduino.googlecode.com.

Check out http://translationparty.com -- they run phrases through Google's translation service from Japanese to English and back until it gets the same text out of it. Depending on what you start with, it can be quite funny. Here's the translations of Jeff Foxworthy's classic punchline:

1. You might be a redneck.
2. あなたは偏見を持った可能性があります。
3. You may be prejudiced.
4. を害することはできない。
5. Not to harm.
6. 害はない。
7. There is no harm.
8. 害がないです。
9. Is no harm.
10. 何ら問題はない。
11. There is no any problem.
12. 何の問題もないです。
13. I have no problem.
14. 私は問題を抱えている。
15. I have a problem.
16. (then it loops -- we've reached equilibrium)

Other phrases that elicited chuckles from me include "Where would you like to go on our first date?", "Come here and give Grandma some sugar.", and Darth Vader's line "I find your lack of faith disturbing." which ends with "We need to worry".

On the desktop, scrolling a page involves changing the page's scroll position.  This uses OS-widgets like scrollbars -- the OS will copy part of the page to the new position on screen and ask the browser to draw the part that's exposed.

On Fennec, we instead have an off-screen browser instance.  We ask it to render parts of the page into a large canvas element that we reposition as the user drags.  This canvas is larger than the visible area, so usually a pan won't show areas beyond the canvas.  When the pan is over, we reposition things and redraw so the next pan can proceed as normal.

This has been the source of a lot of bugs.  It's been fairly easy through kinetic scrolling and zooming to get the browser into a situation where it didn't fix up the canvas properly or start drawing again, letting the checkerboard or gray background show through.  In severe cases, you can get the whole screen to be checkerboard, which effectively hangs the browser as you can't pan back to any of the controls.

Recently, one of our summer interns, Roy, has been working with Stuart on a new system to deal with these problems called the Tile Cache.  Rather than have one giant canvas, we now have a lot of smaller canvases that we draw into as needed.  Tiles can be moved around by the cache so there's always a cloud of them around the ones visible on screen.  It seems to make panning a lot faster, but it's required a lot of changes to input handling code and user interface code, so it's not yet landed in our main Fennec development trunk.

While this has been happening, I've been working on a patch to support panning of IFRAME and FRAMESET content.  Unfortunately, IFRAME panning is going to be a bit slower than page panning, as we effectively just change the scroll position of the embedded frame, which then causes a lot of the page to be invalidated and redrawn.  There are some more complicated techniques that could be explorer for avoiding the whole-area invalidation, but they probably won't be done for the 1.0 release.

To get IFRAME panning to work, when you start a drag, we have to dig into the page content and see if your finger has touched a frame element on the screen.  If so, we scroll that element based on the finger movement.  If you get to the edge, we then move its parent; this is needed to prevent you getting into a situation where you can't pan over to the controls because you zoomed into a IFRAME's area.  One popular site where the whole page is an IFRAME is Google Mail, so without the overflow movement, it would be easy to get stuck.

With luck and a lot of code reviews, all of this should land in time for the third beta of Fennec for the Maemo platform.  I think it wll be a much better Fennec experience, and with IFRAME scrolling, we'll do something the other mobile browsers like Safari on the iPhone don't support.

This sign was made of five surplus LED boards, each one with shift registers to run the rows and separate driver pins for the columns (I could have that backwards). A small PC handled sending the bitmap data to the Arduino over the USB/serial connection, and it would then push out the data to the shift registers, scanning through all the columns. Multiple columns weren't active at the same time, but it scanned so quickly it looked very solid.

I've been reading a number of articles lately about how to price your iPhone application on the iTunes App Store.  The big issue seems to be how the race to the bottom is hurting developers and conditioning mobile users to pay as little as possible for software.

Right now, Palm is in the middle of desiging their App Catalog for the Palm Pre smartphone and future webOS devices.  We can see some of their ideas from the current "beta" version, but I really hope they make different choices from Apple here in the final product.

First, Apple's store has two main categories for apps: free and paid.  The free area is mostly a bunch of "adware" and "lite" versions of more fully featured programs.  There are some free interfaces to other services there too, like the Kindle and eReader apps that let dowload books you've bought through other web stores.  There's a role for free apps on the Palm App Catalog, and I feel this should be a category.

However, I think paid should be divided up a bit.  I'd look at Amazon's MP3 store as an inspiration.  They have a bargain area (the $4.99 and down page), but they they also break out albums by different price points and have top seller lists for each one.  By creating more lists with natural exclusions, they give the ability for more albums to have "top spot" and get exposure.  On their "hot lists", they don't even list price.

I'd love to see Palm have a "99-Cent Store" section, perhaps with a bit of a downmarket skinning to it.  Set up a social expectation that 99 cents is the price for toy applications, but premium/serious apps are found in a separate part of the store.  Perhaps we wouldn't see as much of a race to the bottom then.  Especially with the smaller market that the Pre will have in its first year compared with Apple's juggernaut, it's important to make sure that the developers can make some money on the device to get a healthy ecosystem going.

As I mentioned on Twitter, I'm one of the lucky developers that are in the Palm webOS developer program. My status as an ex-Palm-employee probably helped my application stand out a little. We recently had our developer agreement amended to allow discussion of the development experience in public forums, so here's my first post on the topic.

First, from watching the homebrew world, I fully expect that lots of obvious niches will be filled very quickly once the app catalog for the Pre opens up. There will be scientific calculators, tip calculators, and shopping list apps. Some one will have a "Drug Wars/Mob Wars" style game, and various dice and puzzle games will quickly appear. The catalog will look a lot like the early Palm OS days.

It will take a little longer for more serious programs to appear, both because of the learning curve of webOS and because developers will want to realize a return on their investments. That means having a larger user pool.

OK, so what are my ideas right now? I've got a few:

1. "Required Reading", a client for a variety of web services that keep track of bookmarks like Read It Later, Delicious, Mozilla Weave, and Newsgator Clippings. This app would let you view your lists, open the bookmarks in the web browser, and have those links marked as read or visited.
2. "Memosa", an application that addresses the problem that you can't easily migrate your Palm OS memos. I envision a web service that lets you upload a Palm OS memo database file and returns a RSS feed of the memo entries. Make this use HTTPS and require a password and you can do one-time conversions. The Pre app could then download and store the memos locally.
3. "Couch to 5K Tracker". I've got an app on my iPod Touch that handles audio cues for the timing of the various C25K runs, but it's biggest limitation is that you've got to start your playlist before you start the app, and if you want to change music, you've got to pause and resume your run. On the Palm Pre, you can just use the multitasking and not have to worry about the timer getting messed up.
4. "Electronics RefCard". This is a simple app to help you figure out the value of resistors and other components by their color markings. I also imagine having some way to store IC pin outs here for quick reference, and maybe having calculators for Ohm's Law and parallel/series circuits.
5. "Photo Puzzle". The standard 4x4 block of sliding tiles with one missing. You get to rearrange them in the right order. The hook: unscramble your own photos instead of a bunch of numbers.
6. "IP Toolkit". Front-end for a web service that lets you ping hosts and do DNS and WHOIS lookups.

Some of these are fairly easy to code, and others will take a bit more work.  I'm currently working on the C25K tracker as my first application; it has an immediate appeal to me because I'm going through that training program right now, and there's some interesting challenges with keeping the device awake to do accurate timing and mixing my alert sounds with the other audio streams.  However, I've also got some code in place for the Electronics application.  I could do a really poor job on that one quickly, but I'd like for it to actually have a nice user interface.

On a whim this afternoon, I set up another Twitter account -- this one is @palmpretips. It's a collection of useful tips for the new Palm Pre smartphone, both ones I've discovered and ones sent to me from friends and contacts. So far, it seems to be catching on a little; we're up to about 20 followers in just a few hours. I'll probably try to publicize it on some of the message boards later tonight, but I think we've already got a critical mass of useful items.

To my followers on @unwiredben, this means that you won't have to see a mass of Pre tips show up there anymore; it's back to being all about me and the weird things I notice.

Yesterday, GM declared bankruptcy. They did it from the 25th floor of the GM Building. Annelies works about ten floors above that. She was told the avoid the 25th floor on Monday.

This story from the Gothamist has a nice picture of the very tall building. It's the only skyscraper in New York that fills up a whole city block.

I wonder if there's a connection with us getting rid of our cars and GM (and Chrysler) going under? I expect that if we'd stayed in a place where we needed cars, we'd probably not be considering any current GM cars. I'm a guy who bought two cars in my life, both Saturns. They gutted that brand and its promise and they failed to deliver better technology and more efficient vehicles. I hope the best for those affected by the collapse of that manufacturing area, but I think I agree with Robert Reich in Salon: "...in many ways, what has been bad for GM has been bad for much of America. The answer is not to bail out GM. It is to smooth the way to a new, post-manufacturing economy."

By the way, the GM Building hasn't been owned by General Motors for a while. According to the Wikipedia article, it was sold back in 1998, and currently is owned by real estate funds primarily financed in Kuwait, Qatar, and Dubai. You still get paper badges with a GM logo on them when you visit.

The latest Picasa now has an easy-to-use text tool that seems perfect for LOLing a picture. Here's my test of it's effectiveness.

A few weeks ago, I sent off the 1.3 version of my RGB LED Shield to get fabbed. It was waiting for me when I returned from the Mozilla All-Hands meeting in California, but when I'd put it all together, it didn't work. I started checking soldering joints and electrical connections and discovered the problem; two rows of pins were swapped in my board layout, so it wasn't connecting the right pins to the Arduino. Because of the way that the TLC5490 pins are connected to special timer outputs, I couldn't fix this in software. I tried to see if I could reroute the signals on the board, but it didn't seem possible, However, I was able to verify that if I connected the board up with wires to the right pins, it did work.

Fast forward a couple of weeks. I'd gotten in a little board called the Stickduino. It's a small Arduino-compatible board that is about the size of a Flash drive. One end is a USB port, although it's not quite thick enough to make good contact in my laptop. I fix that with a couple of pieces of cardboard and a glue stick. I uploaded my arrows sketch to the board, then wired it up to the 1.3 RGB shield. The solid core wire was stiff enough to hold things in place, and it worked when I plugged it into my laptop.

To power this, I got out a $5 USB power supply I'd picked up on my California trip. It's not the most reliable gadget, but it's small, and if you aim the USB port to the ceiling, it will hold up the whole contraption. The picture is from it running in my bathroom. I've also got a YouTube video of it running it's very bright pattern below.

I'd probably not use this as a real nightlight, but as a quick light show at a party, I'm all over it. I also now have something to do with the rest of my v1.3 boards.

Here's one with a color box pattern that I wrote:

This was taken Sunday night over at Eric's place. The patterns you see going up/down from the LEDs are artifacts from the CCD sensor; you don't see them with your eyes. I think I'll do another video of the patterns bouncing off a wall to give a more ambient experience.