Putting together the Index
I wrote an index for the book a little over a month ago and submitted it to Persons. I got comments back, made a few changes, but otherwise it was approved. But its not fully set yet..
Part of the reason I asked Andrew and Jon to co-Author this book with me is because when you only have your view on how to put together code (and the index to best build that code) you only get 1 solution. Tonight’s meeting provided plenty of examples where “that’s interesting, but I would have done it this way”. As we talked about various ways to write a client, that started to influence the current order of the index. We did not change the current index (which we still need to share out to the public) but I have a feeling that as we start working on the first 3 sections, things are going to change… and that’s exactly what I was hoping for.
Today we had our first meeting on the API, the index, timing and general approach to the book. As we went over the code from twittFilter.com (TF) and the current Index, a few key questions came up:
Should we use Classes?
I only have two Classes in TF and thought it would alright to leave then in there. However, it was agreed that using Classes one just one more thing that we were assuming the reader understood and was comfortable with. So we will not use Classes.
Should we use other frameworks like J-Query? Others?
Similar to the question about Classes, we were concerned about the readability and ease of getting the concept of the API. So again, no non standard tool with exception to J-Query. Although not an official standard, the added efficiency and improvement in code readability makes J-Query worth including. We may add a section were other PHP tools are brought up. Or perhaps on the website.
Should we use the existing code from twittFilter or start fresh with a new product idea?
Part of the problem of using a stripped down verson of twittFilter as an example is that the amount of work required to strip it down and simply the code could actually be more work when just starting from scratch. Now short of the basics, we are not sure what we will make yet, but we will aim for creating a basic client first and then add fun features if time allows.
jonwu Said,
September 2, 2009 @ 1:32 pm
One of the big reasons we decided on jQuery was that it's really popular. <a href="http://www.google.com/trends?q=jquery%2C+mootools%2C+%28yahoo+ui|yui%29%2C+dojo+%28toolkit|||framework%29%2C+prototype+%28toolkit|||Google Trends shows just how much it has taken off compared to some of the other frameworks out there.
Now don't get me wrong, popular != good. But, it just so happens that jQuery is a really good choice for novices and experts alike. We've chosen it because it has simple syntax that's easy to use and read, well documented examples, and a strong community. Its sheer popularity means you'll have no problem taking jQuery to the next step if you like it and its simple syntax ensures that you'll know enough about what's going on to rewrite some of our examples in pure or using another framework. When I have some more time I'll get a blog post up about what makes a framework a good thing and more about why we chose jQuery even though none of us have used it before extensively.
Personally, I've played with Dojo, Prototype, and mootools and while each of them has had its strengths, each of them has left me wondering why I wasn't using a framework earlier.