Bookie Status Report: Aug 1st 2011

Phew, with PyOhio out of the way and my tutorial done, I can get back to Bookie. Sorry that I missed the last couple of weekly status reports. Honestly, there wasn't a ton, but there was some work going on.

So first, let's go over what's been going on.

Mobile View

I put in a bunch of work redoing the mobile view. It's still using jQuery Mobile, but I redid the javascript that ran it, I implemented an HTML5 history api to doing the tracking as you go from "page" to "page". I put that in quotes because pages are driven by just json api calls. There's no real new html page load after it gets started.

Of course, it's not totally released yet. There's a bug using it with Android. It works in Google Chrome and it seems to work on iOS. The most current version is live on the htp://bmark.us site.


There's been a lot of work to help prepare the docs for the 0.3 release coming. Craig did some great work helping going through parts of it and finding things I had missed.


Ok, here's the one that's going to hurt. I fleshed out most of the rest of the api to get the mobile site updated and such. There's still one view left out there, but the api is going to get reworked. Issac Kelly's talk at PyOhio reminded me that an api is all about resources, not just implementing what your app does via json. So I really need to rethink things. Of course, since the web site, the mobile site, and the extensions all use the api, there will be some work there to get everything updated. This means 0.3 is going to be delayed form where I wanted.

The docs are also pitiful when it comes to the api. Once things are updated I really want to get them really solid. A good api I think will be a big boost to Bookie going forward. So this is another heads up that 0.3 will be a bit delayed, but hopefully this will all pay off.

PyOhio Sprints

The sprints went awesome. While I was hoping to get a lot of coding myself, that was a poor expectation. I spent most of my time working on the mobile site updates and the documentation. We had some six or so people that managed to get it install. It really proved that there's some work to get for easing the installation process.

What was really cool was that once people got it installed, there was work getting done. Dave Brondsema added the urls to the main ui so you can see the url. He also added a branch flag for the bootstap.py script which should help enable bootstrapping both dev and stable versions easily.

I want to really thank everyone for taking part in the sprints and I really hope there are some people that find the project interesting and want to take part going forward.


Next up on the todo list:

  • redo the api and docs
  • fix this android mobile issue
  • keep working on the install docs. The bootstrap vs the long way was really confusing to users.

Taking Part

If you care to help or follow along make sure to follow the project on github: http://github.com/mitechie/Bookie

  • Current Chrome Extension: 0.3.8
  • Most recent code updates: develop branch
  • Current working branch: feature/api

Bookie Status Report: July 6th 2011

A slow plodding week in Bookie progress this week. Thanks to Greg and Craig for some help in cleaning up a feature.

  • New version of the Chrome extension that will do a much better job of error checking on the options page. Make sure to get the updated extension.
  • The Account page has been cleaned up. You can now view your Api Key, change your password, and update your base account information such as name and email. I also did some ui cleanup so things should start to be a bit prettier. Let me know if you have any suggestions to the account ui.
  • I fixed the Google fonts used so things might look a bit different. I'm using the Cabin font for the body. I think I want to change it for the readable version body though. It's not great for large bodies of text. What do you think?
  • I also updated the mobile view to the jQuery Mobile beta release. I finally found the cause of a nasty bug and things should work ok. I still need to write my own history api wrapper. So navigating back and such is pretty broken still.
  • Per request of Greg and Craig, when the bookmark isn't for the current year we now add the '10 or whatever to the calendar graphic. You can see an example over here.

Next up on the todo list:

  • We need a password reset feature for those that have forgotten their passwords. There's some database side start to this, but no ui for it yet.
  • I want to start on a page in accounts for viewing your readable results such as displaying 404 counts and such. See ticket #47

If you care to help or follow along make sure to follow the project on github: http://github.com/mitechie/Bookie

  • Current Chrome Extension: 0.3.4
  • Most recent code updates: develop branch
  • Current working branch: feature/auth

YUI, how dare you make me rethink

So I've been spending time working on moving ahead with my project using YUI. So it's been a lot of trying to port over old jQuery code into YUI, going through docs on the various widgets and plugins, and just trying to figure out how to rearrange how I think with this stuff.

The hard part is that YUI3 enforces something we all consider good practice. Don't pollute the global namespace. What's the bad in that? Well, it presents some challenges with the way I used to do things.

[sourcecode lang="javascript"] MyApp = {};

MyApp.home_page = {

'init': function () { // do some stuff here // like load some social content or crap MyApp.home_page.bind_stuff(); },

'bind_stuff': function () { // hey, we have fancy events we bind/catch // woooo } };

// and then in the page onReady I just MyApp.home_page.init(); [/sourcecode]

So that's how I have been doing things. Parts get abstracted out, shared, but basically each page tends to have an object for each page and any extra handling of events or whatever that requires.

However, YUI3 does this cool thing that breaks that. When you use YUI3 you have a YUI().use() and everything gets encapsulated within that bit of code. So if I were to just move the MyApp code into the YUI block I'm no longer able to access it from the page of content I want to run JS on. So this is good, no JS globals, but it's bad...not the way I've been doing things.

So I've had to figure out how to adjust my old code to the new YUI3 way, and I came across this great video on structuring your code a bit better. It makes some sense, but it seemed to just scratch the surface. Unfortunately, his example is a single page application so it's a bit simpler than what I needed, but it got the point across for me.

So what's the new stuff look like? It looks like YUI3 modules

[sourcecode lang="javascript"] YUI.add('myapp', function (Y) { var MyApp,

MyApp = function (config) { MyApp.superclass.constructor.apply(this, arguments); };

/** Static **/ MyApp.NAME = 'MyApp'; MyApp.ATTRS = {


Y.extend(MyApp, Y.Base, { initializer : function (config) { },

destructor : function () {},

/** Public Methods **/ 'some_page': function () { var that = {};

that.init = function () { // do some stuff that.bind_stuff();


that.bind_stuff = function () { // and we're doing stuff };

// return the page object with all the controls/method return that;



Y.namespace('MyApp'); Y.MyApp.Window = MyApp;

}, '0.1', { requires: ['base', 'node', 'my-ui', 'yui2-datatable', 'yui2-button'] });

// and then I use it from my page with YUI({ }).use('myapp', function (Y) { win = new Y.MyApp.Window(); my_page = win.qcontent_admin() my_page.init(); });


So this has me creating a module for my application code. It allows me to specify versions, requirements, etc. It keeps the YUI3 way of not polluting any global namespace for the application, and while a bit more verbose, seems to be working out. I like this since it's getting to what I was talking about back before when I was looking at moving to YUI from jQuery. This feels more like treating the JS code like application code.

I could split up the code into different modules based on different logical sections of the application and I might be able to reuse bits of this down the road. For instance, we use a common base bit of application code for our authentication across apps. I could break out the JS code for the auth pages into their own module, version it, and reuse it much easier.

What do you think? Am I heading in the right direction or am I just making life more complicated than it's supposed to be?

Howdy YUI, looking fine...ish

I subscribe to some RSS feeds and I've seen some cool videos/posts about YUI3 and it looked kind of interesting. I've always felt like I should be using/checking out YUI more. Everything seems very well thought out, tested, and I love that they have a whole package. Everything from DOM tools, Ajax, CSS Grids all the way to ui widgets. I've always thought they had the best autocomplete widget around from the demo. Tab should complete the current selection, it just should. So I picked up a copy of YUI2.8 Learning the Library and while it's not YUI3, it's a good view into the minds of things and how they fit together. So I decided to port over a work project I'm working on to YUI. It's kind of CMS-y so I want to setup grids just to help flexibility as things go on. (Although...I'm a grid hater for the record) I also want to take advantage of the UI collection for auto complete, progress bar, text editor, treeview and possibly datagrid.

Today was day one and so far so good. It takes a bit of work to get your head moved over from jQuery. I've been using it for a while and really the thought process in jQuery is different. Go find about any tutorial and you'll see things like:

[sourcecode lang="javascript"] // find all the instance of class="important" // and then make sure they're marked with a bolder font $('.important').css('font-weight', 'bold'); [/sourcecode]

This view is kind of against the ideas of mixing logic and template, in a way. I mean this is all view information here. Instead I think I should have things more like:

[sourcecode lang="javascript"] var highlight_important = function (identifier) { var default_id, id;

default_id = '.important';

if (identifier !== undefined) { id = identifier; } else { id = default_id; }

$(id).css('font-weight', 'bold'); }; [/sourcecode]

Now, ideally this would take more config options for just what class property to set and what value to set, all optional of course. And you have this reusable component with a sensible function name you can reuse throughout the app.

This is probably a bad example, but the point is that jQuery comes across as 'find the html and do stuff' where frameworks that come across more verbose/complex, like Dojo and YUI, seem to present things as 'write JS logic' instead.

For instance, I love the idea of the modules in YUI3. I used to just have a custom namespace object like:

[sourcecode lang="javascript"] mystuff = {

'ui': { 'zebra': function () { ... }, },

'form': { 'init': function () { ... },

} [/sourcecode]

This is fine, but I like the idea of the modules you can treat like other YUI modules. For instance my form code turns into something like:

[sourcecode lang="javascript"] YUI.add('myform', function (Y) {

Y.myform = function () { // private property to track the forms we've processed forms_formatted = {};

var that = {};

that.init = function () { Y.myform.maxlabels(); },

that.dosomething = function () { ... }

return that; }(); }, '0.0.1', { requires: ['node'] });

// and use it like var login_page = function () { YUI().use("node", "yui2-button", 'myform', function(Y) {

var Y2 = Y.YUI2;

//YUI 2 implementation code var button = new Y2.widget.Button("submit");

// init the form ui tweaks Y.myform.init(); }); }; [/sourcecode]

This also shows off how I can do things like include the YUI2 widgets.

So people are asking "Why use YUI over jQuery" and it really comes down to 'total package' with the overall completeness of things, 'well thought outness' of the library. In reading things I'm always hitting points like "man, that's a really good way to do/handle that". Finally, I want to try out and seem to like how it makes you 'think' when writing the code.

Will it stick, who knows, but I've learned enough JS to want to try out something a bit higher up. I consider it a bit like going from webob to Pylons. They're both JS underneath and all, but one includes a lot more bits than the other at the cost of some framework complexity.