I've migrated this blog to http://blog.coolaj86.com/.

The landing page isn't as pretty, but the content layout is better.

How to migrate from blogspot to jekyll.

My question: how do you organize JavaScript code? How do you add OOP

features to JavaScript? How do you separate DOM-manipulation from

business logic in JavaScript?

Object Oriented, Event and Message Driven, Asynchronous Non-Blocking Programming

First, I recommend reading this article by google How to Think About OO [1]

I believe the reason that JavaScript code is less "intuitive" to organize is because, well, we've been trained to program in ways that are less intuitive. Like a Windows user switching to a *nix (Mac or Linux) - the simplicity and elegance of the paradigms of solutions can be hard to wrap your head around at first, even intimidating.

JavaScript provides a valuable learning opportunity. It thrusts a different (perhaps more elegant) paradigm on us - that of asynchronous (or event driven) programming as opposed to procedural programming (which we tell ourselves is object-oriented, but if you contrast any OO code you've written with the paradigm discussed in How to Think About OO, you may well find that you're not actually using your objects as objects).

Normally we want to write procedurally:

friends = Friends.getAll();

doStuff(friends);

In some other language, such as ruby or python, Friends.getAll() would likely be asynchronous blocking call to a database which should complete in some matter of fractions of a second. In past generations of programming we accepted this waste of processor time and such because it wasn't very noticeable and we have had the liberty of scaling out - buying more systems to make up for the loss of availability that we don't even realize we could have.

However, in JavaScript we don't have the luxury of procedural programming, nor of scaling up. We have to use the one machine that we have to the maximum value that we can. We don't use synchronous blocking calls because a call to a web service (such as Amazon with which you must perform several iterative queries to get the data you're looking for) could take several seconds - perhaps 10 or more - before you have the data you want.

jQuery comes along and makes AJAX and AJAJ (JSON) easy. But then, if you're like me, you find yourself in this tangled web of callbacks. It becomes less clear how to organize code.

So now you have something like this:

// Get all Friends <-- Note that you've lost the ability to create self-documenting code here

$.get('http://webservice.com/friends' + '?callback=?', function(){

    // do stuff <-- and here as well

    ...

})

The problem here is that there's more than one type of doStuff() that you might want to do with your friends. You don't want to make a call to the webservice each time so you might store friends in an html5 datastore or a friends variable in memory. You might choose to halt some execution of your program until you get friends back. But then you're synchronous blocking again!

How do you know when you've already gotten friends? How to you update friends reliably?

It would be nice if we could have a hybrid of the two (such as Ruby's Fibers) [2] such that calling an asynchronous function would pause execution of the current code (and thus allow other events to take place during the non-blocking wait) and then continue with the execution of the code.

friends = $.get('http://webservice.com/friends')

But that's just not possible in javascript as of today.

The solution I see is to treat each object as an application until itself, with it's own MVC and "pass messages" rather than "call functions" (something I've learned from ruby).

Scenario:

I have button in a facebook app which will display the 10 friends with the closest upcoming birthdays.

I'm allowed to cache the urls of pictures of friends as well as profile data for 24 hours.

I must initially get the data from facebook, but I cache it in an html5 data store.

Friends.send( { "message" : "with_birthdays", "conditions" : { "quantity" : "10" }, "present_as" : "#friends_with_birthdays")

or perhaps more practically:

Friends.extend({"presenter_class_name" : "Template", "message_map" : { "with_birthdays" : "friends_with_birthdays" } })

Friends.with_birthdays({"quantity":10})

This way the data lives with the object as described in How to think about OO [1]. The callbacks all take place within the Friends object and the Friends object will send a message to use the "#friends_with_birthdays" template on some hash object - probably with a timestamp as to when the message was received.

And perhaps by the time that the data is retrieved the user has chosen to view something else. The Presenter (template class) may have some logic to help it decide how to ignore stale messages or the Friends class may be able to be modified such that at each callback step it checks to see if the action has been cancelled. If it has, it doesn't send the message to the template class at all.

Do you find this to be helpful? I'd appreciate your feedback and ideas, as I'm still trying to figure this out for myself.

AJ ONeal

Recommended Reading / Viewing:

[1] How to think about OO: http://googletesting.blogspot.com/2009/07/how-to-think-about-oo.html

[2] Scalable Ruby Processing with EventMachine: http://www.mikeperham.com/2010/01/27/scalable-ruby-processing-with-eventmachine/

[3] Best Ideas in JavaScript Development: http://cdn.javascriptmvc.com/videos/2_0/2_0_demo.htm

[4] SproutCore: http://screencasts.sproutcore.com/

I'm in search of a web API framework.

I'm not interested in building web clients on the server. Why should the client logic reside on the server? That makes no sense.

FRAPI II
http://getfrapi.com/

FRAPI is many steps in the right direction, but too limited.

I want something like PURE for the API where I can define a directive which maps to a data structure.

One benefit to this is I can provide the developer with a structure quite a bit flatter than the database model (and for that matter, perhaps SQL isn't the premier option for web mashups).

Another benefit is I can define what's public very easily.

The solution would be implemented on both the I and the O of I/O. Perhaps some values are not publicly visible, but they are publicly writable (and more commonly the reverse). A directive also provides validation. The hash could map a value's name to the function which validates it.

LDS General Conference on PodCast

Open iTunes
Advanced > Subscribe to Podcast
http://feeds.lds.org/LDSGCComplete_eng
Ok

No, really, XML is retarded.

http://developer.apple.com/macosx/launchd.html

This way is better because... ???

That said, I don't think that every single program should have it's own psuedo-YAML config syntax. I like YAML, but would prefer that we all standardized on JSON.

The simplest solution is the best

key => "string"

value => "string" | {} | []

dict | map | hash => {}

array | collection => []

ASSIGN => :

This is what I don't like about XML:

It's ambiguous.

Which of the following is most "correct"?

<key>KeyName</key>
<value>Some value</value<
<keyname>Some value</keyname>
<keyname><value>Some value</value></keyname>
<keyname value="Some value"></keyname>
<keyname value="Some value"></keyname>

It encourages error.

It's just more likely that you'll get it wrong in a way that's not apparent at-a-glance.

<keyname>Some value<keyname><

It's ugly. Just look at it. It looks complicated.

It's verbose. Why do you repeat the names of every single key thing

Consider a JSON representation:

{ "key_name" : "Some value" }

Clear.

Concise.

Correct.

Cute.

Google is our friend.

Take a look here:

Notice that Word is at the bottom of the list.

It could have been 'DOC', 'DOCX', 'Microsoft Word', or anything other than 'XPS' and it would have landed closer to the top.

I am disappointed that they refer to OpenDocument as OpenOffice though.
I'm a fan of OpenDocument, but I'm not a particular fan of OpenOffice.
It's slow and ugly.

Back in the days of MS Office 2000 I was a fan of OpenOffice because the menu system - and most especially the help system - I found to be much more intuitive. I still think that their help system is wonderfully easy to use (most of the time), but in light of the ribbon interface of MSO 2007, OOo just doesn't measure up.

I primarily use google docs, however, so I don't bother with either.

In the case that I want to make a flier or handout, or anything with graphics, I always use OpenOffice Draw. Both Writer and Word give me far to much trouble when I insert pictures.

The textbook conspiracy.


First of all, textbooks are difficult to read. They usually use a glossy paper which is difficult to read in any sort of light due to the glare.

Second of all, they have 2 inch margins, just for the sake of increasing the size and weight of the book.

Third of all, they're hard cover and meant to be laid flat on a desk. You can't easily hold them in your hands and read them. This induces excess strain on the neck and makes the glare worse.

Forth of all, they're too heavy. That's due to problems 2 and 3.

Fifth of all, they're mistaken. Most textbooks are riddled with anomalies and errors. I think this is done on purpose so that instead of a simple Errata, they can justify the next release. It's also likely that they write them to be outdated as quickly as possible.

Worst of all, they aren't geared towards students or teachers. The adhere to nearly no principles of technical writing, teaching, nor well understood psychological practices.

Seventh of all, the numbering systems don't match up. Why is it that the homework for section 3.6 is at the end of the chapter? Why is diagram 3.43 is section 3.7?


Here's a challenge for you: Take any text book you have to a copy shop. Have them chop the margins off the book and replace the binding with a spiral binding. You've just lost 5 pounds. So much easier to carry, turn pages, use.



And while I'm on the subject of education: Isn't it interesting that you have to have a teaching certificate to teach in elementary school, yet the majority of college professors don't have formal training in teaching, psychology, or communication? And I'd say about a quarter to a half of them are downright terrible teachers. Only a few are actually qualified to teach.


It's much easier for a real teacher to teach something that he doesn't know than for an expert to teach something he knows all too well. The wonderful thing about a real teacher is that a teacher can learn anything and teach anything. It's not about being an expert, it's about acquiring information and communicating it in a fluid manner.



Just get home schooled, fall in love with something, get good at it, and do it.



[Edit & Addition] The worst worst is actually that they're by and large "text" books. "Text" is one of if not the least effective medium of communication.

And it's not fair to make a complaint without suggesting a solution. How about small picture books with matte pages that focus on narrow topics.

Although book machines are a new invention and I think BYU is one of the first (and only) places in the world to have one, I can see them becoming coupled with the internet and mix'n'match blog posts becoming a better form of text book.

Imagine if you could blog on a subject and get $0.50 every time someone printed it as part of their curriculum?

P.S. This is why I tend to stay away from blogging. I feel rather strongly about a rather large number of things and once I start a rant, I'm going to finish it...

I recently discovered that my driving time becomes more enjoyable (and productive) if I listen to Google Tech Talks.

I was rather fascinated by Go. The idea that the first argument to a function definition should be the object receiving the message just makes sense. Duck typing makes sense. It's a great paradigm.

Tonight I starting looking at the Getting Started guides on Erlang for the first time. I've been meaning to do it for a while, but I just hadn't. I feel that having had my eyes opened by Python, then Ruby, and then Go have prepared more to more readily understand so many new concepts.



I see that Yukihiro Matsumoto was definitely right that the way you approach solutions to problems has much to do with your natural language. Certain constructs of human language and grammar are more conducive to certain thinking patterns. Background and culture play a huge part too. I can see that Erlang was written from the perspective of a certain mind-culture.

Computer science is so awesome...


The more I get into this stuff, the more I believe that it is a truly creative and expressive medium - an art more than a science.

I'm still putting together a toolkit for myself to be using on web development. I've been missing a good MVC framework for javascript. Just recently I stumbled upon several interesting projects in development.


I discovered Jaxer a long while ago (perhaps even during the beta stages). Although I'd prefer to use that than PHP, I think that the number of libraries available for Ruby make Ruby a better choice.

More importantly, mixing client logic and server logic is something that just doesn't sit well with me. I'm of the opinion that clients and servers should be separate. I just don't see how you could adequately follow the data-service paradigm while mixing client/server logic. I'd rather use my own public api and know that it works for everything a customer would need (including a working demonstration - the application itself) than have the convenience of coding things just once.

http://activerecordjs.org/view.html

http://code.quirkey.com/sammy/

http://code.google.com/p/jquery-jstore/

http://benalman.com/projects/jquery-bbq-plugin/

http://helma.org/wiki/Helma+NG/

I still want to do more research into CouchDB before I settle on which frameworks to mix and match from.



I also want to look into Sinatra and DataMapper.

http://datamapper.org/why.html

There are a bunch of websites that BYU's IT college likes to pretend are private for some sort of reason.

I'm here to dispel that myth and make it so that next time I google BYU XXX I either hit the site itself or this blog post...


A lot of the IT sites... under ET... wth?
http://www.et.byu.edu/groups/

IT347
http://www.et.byu.edu/groups/it347/IT347Root.htm
http://www.et.byu.edu/groups/it347/Schedule.htm

IT355
http://www.et.byu.edu/groups/it355/

IT210
http://www.et.byu.edu/groups/it210web/


because it when you're trying to google to find a class because you can't remember the URL, but it's not there.

P.S. frames suck too, don't use them.