The only real difficulty you are likely to encounter in creating a JSLint target for your build scripts is that JSLint is, itself, written in JavaScript. Other helpful libraries such as JSMin or the YUICompressor from Yahoo are distributed as jar files and can be executed easily with an exec block with the executable set to java. With JSLint, however, you are going to need a JavaScript engine which you can execute from the command line in order to run the JSLint script to validate your JavaScript code. THis actually sounds harder than it is.

For our implementation, I chose to use the Rhino engine since there is documented support for JSLint on it, and even a handy helper file to include in your system: rhino.js. Grab a copy of Rhino (the actual file you’ll want to include is js.jar), the Rhino helper script I just mentioned and JSLint itself. Place them all together into some sort of tools directory in your project. Ours is located in /tools/ant.

Now comes the fun part, writing the actual target in ANT. For our purposes, we want to process all .js files contained in a particular location, as defined in a build property called jsdir. We also want to ignore any files that are contained in a vendor subdirectory of jsdir, as we should not need to worry about third-party scripts that don’t pass JSLint. Let’s get things started with our basic, empty target:

1
2
3
4
5
6

<!-- 
jslint - Runs lint checks on js files
-->
<target name="jslint">
 
</target>

Listing 1: The basic, empty jslint target

Within the target there are two things we are going to need. First a way to reference all of the files we want to operate over and second, the actual call to run JSLint on those files. For the first requirement we’ll use a pathconvert tag with a nested fileset. The pathconvert will allow us to generate a space-separated list of files and stuff that into a property which we’ll call jsfiles. The fileset block will do the actual work of finding the files in question. It will operate over ${jsdir} including all .js files and excluding all .js files in the vendor subdirectory. Listing 2 shows the pathconvert block added to our empty target.

1
2
3
4
5
6
7
8
9
10
11

<!-- 
jslint - Runs lint checks on js files
-->
<target name="jslint">
    <pathconvert pathsep=" " property="jsfiles">
        <fileset dir="${jsdir}">
            <include name="**/*.js"/>
            <exclude name="vendor/**/*.js"/>
        </fileset>
    </pathconvert>
</target>

Listing 2: The pathconvert block added to our target.

Finally, it is time to add the actual call to JSLint. To allow our build scripts to work for multiple projects, we have pushed as much information into properties that get defined in project-specific files as possible. The location of the Rhino jar (js.jar) is placed into the property js.jar and the location of the JSLint script (jslint.js) is placed into the property jslint.js. With those properties suitably defined elsewhere, we have the final piece of our puzzle: the exec block. We have the executable set to java and failonerror set to true, so that our target will appropriately fail when JSLint fails to give our code a passing grade. The final target, including the exec block can be seen in listing 3.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<!-- 
jslint - Runs lint checks on js files
-->
<target name="jslint">
    <pathconvert pathsep=" " property="jsfiles">
        <fileset dir="${jsdir}">
            <include name="**/*.js"/>
            <exclude name="vendor/**/*.js"/>
        </fileset>
    </pathconvert>
    <exec dir="${jsdir}" executable="java" failonerror="true">
        <arg line="-jar ${js.jar} ${jslint.js} ${jsfiles}"/>
    </exec>
</target>

Listing 3: The final target.

Put all together, the pathconvert block stuffs the list of files to work on into the property ${jsfiles} which is then passed as an argument to the jslint.js file. The jslint.js file is itself the first argument passed to the Rhino JavaScript engine (js.jar) which is run directly by java. Running your ant jslint target should give you some nice feedback on the syntax of your JavaScript code.

Excellent work Michael and Nicole!! I think it could have used a little more of Dave’s vocal stylings though

Whereas the side of the project I work on is focused on dealing with home owners, StepRep is a tool for Online Reputation Management, primarily targeted at the service providers that our system will help you recommend to your friends. Of course, it isn’t just people in the home improvement or real estate industries that have online reputations they need to manage. In fact, software developers and hardcore geeks have online reputations! I have an online reputation! That’s why I signed up for the beta at http://steprep.myfrontsteps.com. I know that I am a little biased by the fact that I work with the people that developed all of this, but I am very impressed with what they have done. From a technical standpoint there is a lot going on that even I find overwhelming and a little “magical”.

The main purpose of StepRep is to allow you to see what people are saying about you and your business on the Internet. This includes anywhere and everywhere that someone might be talking about you. StepRep presents you with this information and allows you to categorize the items as good or bad. The good ones are things that you can use to convince new people that you are the right choice for the work they need done. You can even place these items into a widget that can be slapped on your company website, your personal blog – anywhere you want to trumpet your achievements and build your reputation. As for the items you think reflect poorly on you, well, obviously you wouldn’t want to put them in your widget, but you can see where past customers might not have been completely satisfied and do something to change their mind. Flip them to a positive and then slap them in your widget for all to see.

I won’t even try to discuss anything about how StepRep does what it does so well. Honestly, this is because I don’t understand a lot of it. The team working on it are very smart and very skilled at what they do. Starting with the next development sprint my team is going to be working closely with that team as we bring the two systems together to help service providers reach a wider audience through the friends of their customers and to help home owners find the best service providers through people they trust. It’s going to be very exciting and I am hoping that I’ll be able to learn a few things about how StepRep works.

One last thing I want to mention is how much I love the design work that was done for the StepRep site. I got to see some preliminary designs for the MyFrontSteps site today as well and they blew me away. Marie-Louise has really done an awesome job. This is something I really love about working at VendAsta. I work with people who are very skilled at designing for the web and for maximum usability. The wireframing, mockups and designs that I have seen done in my short time there have amazed me. I came to VendAsta from a company that had plenty of graphic designers in the Marketing department. They were all firmly rooted in the world of print advertising. There were some definite growing pains going on as they started to embrace the new world of web design. Now I am working with people who understand the web and the best practices for developing rich, engaging applications for the web. It’s freaking awesome!

I first started using Django when I started at VendAsta and this issue didn’t creep up there because we are use Google App Engine and its DataStore on the backend instead of a traditional database. With no database there was no issue with creating/dropping anything. It was only when I started using Django on my own that I came across that problem. There was one more issue with Django that I came across only when I started doing things outside of work: Django expects all of your models to be in a single file called models.py. I hate that. A lot.

I did some googling about the problem and found that there were a bunch of other people who didn’t like it much either. There were a few solutions but they all involved manually mucking about with the __all__ attribute in the __init__.py file of your models directory. Sure, it works, but I don’t like having to define a model in two places to use it. Oddly enough it was in some test code at work that I found the answer.

For our project at VendAsta we are using the Django App Engine Helper to provide a nice easy interface to the DataStore on the backend. A part of this is a small __init__.py file which allows you to spread your tests out in multiple files. Django likes its tests to be in a single tests.py file just like it likes its models to be in models.py. The wee bit of Google code is shown in Listing 1.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

#!/usr/bin/python2.4
#
# Copyright 2008 Google Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
 
 
 
 
"""Loads all the _test.py files into the top level of the package.
 
This file is a hack around the fact that Django expects the tests "module" to
be a single tests.py file and cannot handle a tests package inside an
application.
 
All _test.py files inside this package are imported and any classes derived
from unittest.TestCase are then referenced from this file itself so that they
appear at the top level of the tests "module" that Django will import.
"""
 
import os
import re
import types
import unittest
 
PACKAGE = 'appname.tests'
TEST_RE = r"^.*_test.py$"
 
# Search through every file inside this package.
test_names = []
test_dir = os.path.dirname( __file__)
for filename in os.listdir(test_dir):
  if not re.match(TEST_RE, filename):
    continue
  # Import the test file and find all TestClass clases inside it.
  test_module = __import__('%s.%s' % (PACKAGE, filename[:-3]), 
                           {}, {},
                           filename[:-3])
  for name in dir(test_module):
    item = getattr(test_module, name)
    if not (isinstance(item, (type, types.ClassType)) and
            issubclass(item, unittest.TestCase)):
      continue
    # Found a test, bring into the module namespace.
    exec "%s = item" % name
    test_names.append(name)
 
# Hide everything other than the test cases from other modules.
__all__ = test_names

Listing 1: __init__.py file from Google for a tests module

Essentially what this file does is loop through all files in the same directory and for each on that matches the pattern listed on line 40 (in this case, files that end in ‘_test.py’) and import all of the Classes from those files that are subclasses of the TestCase class. Finally, the code on line 62 does the magic with __all__ that I wanted to avoid doing manually for my models. It was this line that caught my attention and started me wondering if this code could be used for spreading models across multiple files.

In order for this to work for models there are a few things that need to be changed. First of all, on line 40, the pattern should be changed to match on *.py to grab all of the python files in the directory. Then, on line 46, add

or filename == “__init__.py”

to ensure that we don’t try to import the file we are in. Finally, remove the subclass requirement from line 55, as we are just concerned with importing classes here not what they inherit from. Putting it all together results in Listing 2. Place that in the __init__.py of a directory called models and you’ll not have to manually manage the __all__ list for your models in separate files.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/usr/bin/python2.4
 
import os
import re
import types
import unittest
 
PACKAGE = 'my_app.models'
MODEL_RE = r"^.*.py$"
 
# Search through every file inside this package.
model_names = []
model_dir = os.path.dirname( __file__)
for filename in os.listdir(model_dir):
  if not re.match(MODEL_RE, filename) or filename == "__init__.py":
    continue
  # Import the model file and find all clases inside it.
  model_module = __import__('%s.%s' % (PACKAGE, filename[:-3]),
                           {}, {},
                           filename[:-3])
  for name in dir(model_module):
    item = getattr(model_module, name)
    if not isinstance(item, (type, types.ClassType)):
      continue
    # Found a model, bring into the module namespace.
    exec "%s = item" % name
    model_names.append(name)
 
# Hide everything other than the classes from other modules.
__all__ = model_names

Listing 2: __init__.py file modified for a models module

Now, there is one last thing that you are going to need to do in order for everything to run properly in Django. It is a very simple addition to the end of each of your classes. I have seem some people complaining about the need to do this in various forums, but honestly, if you are using any form of modern text editing application, it should only take you about 2 minutes to create a new template for a model that has the little piece of code shown in Listing 3 at the bottom of the class (replace your_app_name with your actual app name).

1
2
3

class Meta:
        """Meta Class for your model."""
        app_label = 'your_app_name'

Listing 3: Meta class required at the end of each model for proper functioning.

First and foremost, I absolutely love the amount of planning and forethought that goes into each 30-day development sprint. My past two jobs had nothing that even remotely compares to this. One was an online grocery store (which just recently discontinued operations) which meant that most development was done within the demands of an operating e-business and as a result needed to be very seat-of-the-pants. The other was a manufacturing company which meant that development processes were heavily driven by the demands of sales and manufacturing departments and those demands could and would change in the blink of an eye. Needless to say, I have found the change to be very liberating.

That is not to say that we couldn’t do more planning. One of the things that we found working through our first sprint was that while we felt we had done a great deal of planning up front, there was actually a lot of granularity that we were lacking. This is something we are endeavoring to overcome in the planning for Sprint 2. As much as I love the planning sessions we are having and as exciting as I find the whole process, it is a very tiring and draining experience. Well worth it, but wearying nonetheless.

A second major thing that struck me was how well we worked as a team. Considering the fact that five people were placed on a development team, given a couple of weeks to do some research and get to know each other and then thrust into the middle of a very ambitious project, we somehow managed to work very well together. Coupling this with the fact that we are working with a large number of cutting edge technologies, I would have expected at least a little friction to develop somewhere in the team over the course of 30 days, but none did. I believe that this is largely due to the environment at VendAsta and their hiring process. Everyone who gets hired there has to go through a lunch with other developers whom they will be working with. If those devs don’t think that you are a good fit for the team and the company, you don’t get hired. I don’t know why more companies don’t operate this way. People from HR departments should use VendAsta as a case study in how to build a whole company that just “gels”.

Finally, in the past two days I have been very impressed with the manner in which some of the trouble spots from Sprint 1 have been discussed. Previously, I have experienced project post mortems that are nothing more than a gathering of people around a table to point fingers at each other. In our post mortem yesterday we were encouraged to be completely honest and frank about what we did and didn’t like about how Sprint 1 went. At no point was there any finger pointing and the blame game just didn’t happen. The maturity of my team mates and our “chickens” impressed me to no end.

So, that is about it for my impressions on Sprint 1. We’re neck deep in planning Sprint 2 right now so I am afraid that Episode 4 of Roger’s Wars will still be a couple of days away. I’ve had a few people contact me asking when the rest of the saga was going to unfold but with the holidays and now our sprint planning, I’m having trouble finding the time to do it when my head is not either a) jell-o or b) utterly focused on work. Tomorrow or the next day I hope to sit myself down with a pot of Earl Grey and hammer out the fourth installment. Thanks for your patience

This morning, however, was nearly intolerable for the whole team. Here we are struggling to get our application tested thoroughly and polished up for the end of sprint when Facebook starts pulling all kinds of crazy shit on us. Random logouts. Messages about account maintenance. Warnings about trying to set FBML for inactive accounts. We ended up with a decent number of new bugs filed that weren’t bugs at all. It was just Facebook having a seizure! Of course, once we figured out that there were some issues on the Facebook side of things we relaxed a bit. Still, it made for a rather exhausting day!

Owing to this exhaustion, Episode 3 of Roger’s Wars will not be hitting the ether this evening. It’ll be here soon enough, though!
]]> http://www.ifisgeek.com/2008/12/23/facebook-delivers-a-painful-end-to-the-mfs-sprint-1/feed/ 0 http://www.ifisgeek.com/2008/12/21/spokesmonster-iii-connecting-to-your-customers-and-their-friendswith-steprep/ http://www.ifisgeek.com/2008/12/21/spokesmonster-iii-connecting-to-your-customers-and-their-friendswith-steprep/#comments Mon, 22 Dec 2008 04:36:30 +0000 Jeffery Read http://www.ifisgeek.com/?p=118 The third Spokesmonster video has been posted to YouTube! With an ever-expanding cast of characters, the saga of the often misunderstood Spokesmonster and his quest to enhance his reputation continues! More excellent work from Michael and his team of talented voice actors: Dave, Nicole and Rachel! Check it out!

For the past three and a half years, I have been working in a very heavy Microsoft shop. As a result, it was always difficult to get acceptance for open source projects at Cover-All. The more work I started doing on web projects the easier it became to bring some open source into the fold but there certainly wasn’t any interest in giving anything back to those projects we benefited from and, even if there was interest, there wouldn’t have been time to do so anyway.

At VendAsta, things are a lot different. Here is a company that not only embraces the use of open source projects but actually encourages everyone to give back to those projects if they make any improvements / changes to them. I absolutely love that! This has given me the opportunity to give back to my first open source project!

I have been doing some work on developing Facebook applications over the past few weeks. Specifically, I have been using the awesome pyFacebook library. This is a Python library which gives the same functionality as the Facebook-supplied PHP client library, except with the goodness of Python. A total bonus for us is the fact that the library includes functionality to work with Google App Engine, another new technology we are using. There was a small gap in this functionality and that is where I found my opportunity. While everything was setup to work with retrieving information from Facebook in GAE (Google has disabled socket access in the version of Python available through GAE, so you need to use their urlfetch method instead of calls to httplib), the Photos.upload() method was not setup in the same manner. I needed to upload files to Facebook, so I modified the library to work the way I needed.

Once my mods were complete I sent them to the maintainer of the pyFacebook project and, after a few helpful suggestions from him, I had a version that he was willing to commit to the project’s svn repository: http://code.google.com/p/pyfacebook/source/detail?r=166. After that I was able to track down and fix an actual bug involving some infinite redirects: http://code.google.com/p/pyfacebook/source/detail?r=168.

Two very small contributions to a single project, but I am hopeful that this is only the beginning!

Perhaps the thing I was most impressed with today, was the amount of thought and planning that has gone into their process and systems. From Google Apps for mail and documents, to JIRA for bug / feature tracking, Subversion for revision control and a couple of other technologies, the level of integration is astounding. Using Subversion commit hooks there are automated syntax checking and unit testing routines, integrated code review facilities and a whole pile of other stuff that I was briefly introduced to today. I know that I am missing a lot of details here, but everything I have seen has really impressed me. I am really working in a professional software development environment now. It’s great! I am sure I’ll be posting more details as I come to understand things better in the coming weeks.