Around Thanksgiving of this year my company, BitMethod, released an iPhone App into the iTunes Store that takes a completely different approach to weight loss tracking and logging than any other tool I’ve used. I stumbled onto this idea completely by accident and I wanted to outline the history of how it happened since I find it interesting and I figure others might as well. Lite Weight is the child of a lot of different ideas and philosophies that I’ve enjoyed learning about over the course of my weight loss journey.

My first discovery, as I remember it, was The Hacker’s Diet. Though I now believe that the idea of nutrition as a “Rubber Bag” is a limited view of nutrition, I really enjoyed the authors insights into weight tracking. To quickly summarize: even if you enter your weight in wearing the same clothes, at the same time every day, your weight can change a substantial amount. Dehydration and exercise can cause weight to fall, a big meal can leave extra weight in your belly, and both salt and carbohydrate intake can cause water retention. The author proposes that weight should be tracked using a moving average so that your actual weight can be approximated amid all those changes in the amount of water in your body. Many approaches are proposed in the book to do this weight charting, but I used the excellent site, Physics Diet, to use as my weight loss journal.

Quite a while after this, I stumbled over the book, The Overfed Head, though I’m going to skip over this for now, since it didn’t play a part in Lite Weight until near the very end of development.

But the idea that really led to Lite Weight was gleaned from an article on how the web and weblog have changed writing. A professor of electrical engineering and computer science at MIT proposed that all one needs to do to lose weight is to draw a line from your current weight to a goal weight and plot your weight each day. If your weight is over the line, eat less and if your weight is under the line, eat as normal. This professor’s name is Steve Ward and his diet is known as The Steve Ward Diet or The Bang-Bang Diet (bang-bang because of a type of controller that is either on or off based on some input)

Lite Weight didn’t immediately pop into my head as soon as I had learned all of these ideas. Really, I don’t know what ultimately led to the idea. It was probably while walking around downtown Des Moines or raking leaves in my yard. But I think the thought at the time was along the lines of “why can’t I write a program that tells me how I should behave based on my weight loss history”.

My early attempts at putting together some tool didn’t make me very happy. I was still buying into the view of Steve Ward that some goal weight should be set to be reached at some goal date. It was great in terms of development because the math is really easy, but it sucked in a few ways:

• Trying to set a goal is depressing
• Getting off track of your goal is depressing
• Having to push away your goal date is depressing

Realizing this caused the solution to emerge somewhat organically. The math would be much more complicated, but I decided that I can safely assume that if a user chose to use this tool that he or she wanted to lose weight. Without the goal weights, the App struck a chord in its simplicity. I was able to develop a tool that had a single input and could suggest a clear course of action.

You might be thinking that suggesting a clear course of action is just guesswork. When I started out, I had felt the same way. But my earlier decision to assume the user is trying to lose weight allows for some math that creates some very clear separation between the four states that I eventually adopted: Relax, Over, Under, and Gaining.

In terms of programming, the rest of the story is pretty boring. I decided to add a maintenance mode and came up with some more fun math for that, I made it pretty, I tweaked the code so that it acted as you would expect after Thanksgiving weekend, for example, and any other situations that can lead to odd weight fluctuations.

But back to The Overfed Head. One of the central ideas of the book is expressed in the term thintuition, coined by the author to explain the behavior that naturally thin people exhibit. Basically, some people stop and listen to their body to determine whether they’re full or hungry, and lots of us don’t. At this point, the application was almost done and running on my iPhone. I had been using it regularly and was beginning to notice how it was affecting me. By having a simple, clear explanation of what my body was doing, I couldn’t make excuses for the decisions I had made. If I got feedback explaining that my weight was above what was expected, I usually knew why and it was typically related to my behavior the day before. Almost without thinking, I would eat less, giving myself a smaller serving of something, or not finishing food I wasn’t hungry for. It wasn’t until I was helping to write the text for the iTunes Store that I realized that the application was giving me that thintuition I had read about in The Overfed Head.

I’m really happy with the final product, which is available for the iPhone and iPod Touch in the iTunes Store for 99 cents. The ideas and contributions of a collection of people helped me hone my product and actually simplify it the more of them I used. Stop by the Lite Weight App Site to check out videos of our iPhone weight loss tracking app.

Just finished up the app site for my iPhone weight loss App!

John Resig:

“One thing has always annoyed me about the script tag. Script tags that reference external resources (via the src attribute) are no longer able to execute script embedded within the tag itself.”

This has always bugged me, but I’ve never been able to come up with a good solution. I think John is really creating some good mojo with this post, and I’m fascinated to see whether we, as a community, can come up with a good pattern to make this type of script tag use work, and make it work well.

Chris Eidhof:

“Arrows are a concept from functional programming, and we’ll see how they can make our life in Javascript a lot easier. Our code uses the excellent Arrowlets library. It’s still alpha code, but it’s already quite useful.”

What an odd title. It seems like the entire idea of this method is to use callbacks. I wish I knew what the author meant by his title.

Anyway, an interesting look into a different way of doing functional programming with JavaScript.

Eric Wendelin:

“Chances are that if you’ve done any significant Javascript work, you’ve run into a situation where part of the debugging process could be much improved if you just had the function call stack.

“I’m going to give you some ways of doing this with and without the popular Firebug extension and have some examples of their uses.”

This seems to work, and I’d like for the community to take ahold of it. It would be fancy to be able to have a valid console.trace(); in Firebug Lite.

Karl Tiedt:

“Have you ever found a widget that does almost *everything* you need, yet you still manage to find some small thing that needs to be done differently? Ever cringe at the thought of having to extend a widget to add 5 or 10 lines of code to it? In the past, thats what you had to do… well unless you were really gung-ho and wanted to write your own from scratch.”

It’s meant to be a cookie, so it’s meant to be short and sweet, but I might as well use this as an opportunity to build on that.

First of all, this will work with any class-type object that can accept a property and a node as its two parameters and not barf. Overall, the point of DojoML has always been prototyping. Being able to prototype a change to the way a widget (or any object) works inline is really nice.

Secondly, and as much as I say this, it doesn’t seem to get understood, this whole pattern is functionally equivalent to creating a function that:

• Creates a new instance of a widget
• Uses dojo.connect, or a direct override to change its functionalitty
• Returns that instance

In JavaScript, a constructor function can return whatever it wants, so you can use it as an adapter, which is totally possible here.

Mark Hayes:

“However, we took a different approach to dispatching events: instead of using synthetic events, we used the cross-browser and cross-platform Java applet technology to place real events on the native event queue, as if a real person performed the action. This means that when you use doh.robot to execute your unit tests, browsers will trust the events doh.robot creates from your commands and will handle any and all contingent events for you. So when you tell doh.robot to send a Tab keypress, you can fully expect the Tab to move focus to the next element in the Tab order, as if a real user pressed Tab. And when you tell doh.robot to click an element, you can fully expect to get the onmouseover before the onmousedown, as well as all of those hundreds of onmousemoves a real user would generate in between. When you use the DOH test runner in conjunction with doh.robot, you can easily automate and report the results of numerous accessibility and UI unit tests that would otherwise require manual, visual inspection by a real person.”

Looks pretty sweet, I’ve always been skeptical of (and had trouble with) the UI testers that synthesized events. I think the API needs a little help, but I expect this to be huge over the next few months. Dojo is really offering a lot of well engineered features.

south tutorial:

“With South, you install it and then give one or more of your apps some migrations (either writing them by hand, or autogenerating them from your model definitions). When you syncdb, you’ll only sync apps that don’t have migrations (things like django.contrib.auth, for example, which have a fixed schema), and then when you run ./manage.py migrate, South kicks in and does the migrations. Intelligently.”

The first database migration tool for Django that I think has a future, I plan to start messing around with this in my personal projects.

Alex Russell:

“On this point the essay also contains a rhetorical bait-and-switch which I find distasteful: it dismisses variables because they don’t inherently do anything to reduce the lengths of pages (true!) and then argues against macros and inheritance because they create levels of indirection which can be confusing. Inheritance and macro definitions can play a key role in drastically reducing the length of style sheets. In this way, they promote understanding through exactly the same ‘memory effect’ mechanism that is cited as a liability when discussing variables.”

I love the way that Alex has so calmly ripped apart the half-hearted arguments that have been a more an more frequent occurrence from members of standards bodies.

Lately, I’ve been amazed by some of the attitudes arising from people that aren’t “in the trenches” of web development, but still feel like they have something of a valid opinion to offer. I appreciate that we have people like David Flannagan have reached out to the community, acknowledging that although they have a deep technical knowledge of a subject, they can be out of touch with its actual use. There needs to be more of this.

While reading about search engine optimization, I found out that Google factors this site in when doing ranking. I then found the JavaScript developers personal pages category. Lots of good names on there, I encourage you to add yours as well!