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.

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/11/24/giving-back/ http://www.ifisgeek.com/2008/11/24/giving-back/#comments Mon, 24 Nov 2008 14:32:56 +0000 Jeffery Read http://www.ifisgeek.com/2008/11/24/giving-back/ I have been a long time fan of open source software. Over the years I have utilized countless open source projects to accomplish large tasks with ease for both my day job and my consulting work. Using these projects has always saved me a lot of reinventing the wheel and has made work on projects much easier.

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.

Anyway, back to my first taste of VendAsta. I arrived there shortly after 3pm to find the offices apparently deserted. I wandered around a little and found everyone in the back meeting room watching a video. The video in question was the second Spokesmonster promo for the StepRep application. The first Spokesmonster video is embedded below. For me the fact that such creative and fun things are not only applauded internally, but also released for public consumption, is amazing. Coming from a place like Cover-All, where one of the graphic designers creates hilarious mock advertisements all of the time and the public face of the company remains a stark beige yawn, this is a brave new world.

Equally interesting / frightening was another presentation that was made involving a Finite State Machine. Actual computer science is being performed at this company. This represents a quantum leap from the seat-of-the-pants type of environment I have been working in for the past three and a half years. I have to admit, it is a little daunting. There will definitely be an element of culture shock for me as I move into a real, honest to goodness, software development environment. Very, very exciting.

Friday was my last day at Cover-All. It turned out to be a very good day as well. I actually did a decent amount of work, surprising even myself. Got Dustin up and running as the new master of all things Wizard and finished off a couple of tasks for myself. I spent a good deal of time saying goodbye to people and reminiscing.

I was very pleased when the CFO (my boss’ boss) asked me to come to his office for a chat. Part of me was a little disappointed that he didn’t want to discuss why I was leaving – Cover-All is a great company with the potential to be even greater and I would have really liked it if my departure could open some eyes which could make it even better. Nevertheless, we had a very nice discussion about what I accomplished while I was there and a little about where I am going. He expressed his appreciation for my hard work and that made me feel really good – Cover-All’s CFO is a man that I have really enjoyed working with, a man I both respect and like.

For lunch I went out to Boston Pizza with about ten of the people who I have really built some bonds with. People that were more of friends than co-workers. Even though the service at Boston Pizza is absolute shit, it did have the side effect of giving us a little more time to sit and talk.

In the afternoon, there was cake. A lot of cake. There were not as many people invited to join in the cake as there should have been – my boss set things up but he sits with the downstairs IT people and my group sat upstairs. I think he underestimated the number of people upstairs that I actually worked with on a regular basis. Without a doubt the highlight of the whole cake event was the picture I was given – put together by Ian in Marketing with help from Dustin and a few others. It was a picture of some of the cast from the original Star Trek but they had replaced Kirk’s head with mine. Below it was a quote, “Prepare to leave orbit – those men can’t be saved.” — Evil Kirk. Priceless! I’ll scan it one of these days and add it up here for all to see.

The rest of the day passed quickly – lots of hands to shake and such. I had thought that I was not going to hear anything at all from the CEO but then, when I got home and checked my personal email, there was a very nice thank you message (and a “come back to us when you’re sick of the new guys” poke) he had sent in reply to the farewell message I sent to everyone I liked there. It was a very nice end to my day, and a nice way to close that chapter of my professional life.

I have had a pretty good run at Cover-All and my desire to move on is the result of many things. The biggest reason, however, is that I feel my skills as a programmer have begun to atrophy. Working at Cover-All there is no one I can learn from and, especially with the amount of management I have been doing lately, I have been writing very little code. My passion is for writing code and this move is going to get me back to that.

Even better, this move is going to get me back to working with Python – a language I haven’t spent much time with since my glory days back at Pic’n'Del. I’ll get to work with the framework Django and, from the reading I have done on it so far, it seems very sweet to work with. In fact, I am working on rebuilding this blog with Django to get the cobwebs off of my Python skills and get myself up to speed with the framework. I am not sure yet whether or not I’ll take that little project all of the way to completion, but if I do I’ll be sure to mention it here. In fact, I’ll likely be mentioning a lot more here in the future. A lot of people at VendAsta are big into blogging and, with a little luck, being surrounded by people like that will help inspire me to devote a little more time to it myself.

More to come…

I am a huge fan of the productivity blog Lifehacker. I try my best to check out the site on a daily basis and am usually rewarded with a little tidbit or tool that helps to make my life much easier – it’s not all about Getting Things Done either. Recently, I read something on Lifehacker about Jerry Seinfeld’s Productivity Secret. The basic idea is that that way to get good at something is to do it every day. To that end, Jerry has a big full-year calendar on his wall and he crosses off every day in which he does his desired task – in his case, writing comedy. The key to success, Seinfeld says, is in not breaking the chain. With a big reminder like that in front of you, you will work really hard to challenge yourself to make as long a chain of days as possible.

Scoreboards

Figure 1: Tasks

When I read this I was encouraged to share the system I use which is really quite similar. I use my system, however, to work on creating more than one productive habit. I call them Scoreboards because, well, that’s what they are. I start by making myself a new spreadsheet – I use Excel but OpenOffice or another spreadsheet app would work perfectly fine. Down the first column I list the tasks I want to make into habits, leaving the first two rows empty for the month and day information. I then add a “Totals” entry to the bottom of the list. See Figure 1.

In the first row I place the name of the month and in the second row I place the days of the month. I like to highlight the weekends to set them apart but your mileage may vary. Figure 2 shows this header but only for the month of August, subsequent months would follow to the right up until the page break is reached. With the number of tasks I am currently working on I find that I can fit two scoreboards on a piece of 8.5×11 paper printed in landscape orientation and the one I am currently using has the end of August, all of September and most of October on it.

Figure 2: Date Header

This layout leaves a nice grid pattern in between the tasks and the dates. When you complete a task on a particular day, just fill in the box at the intersection of the task and the date. Personally, I like to print the sheets out and fill in the blocks but there is no reason why you couldn’t just change the background color in the spreadsheet and keep the whole thing online, in a Google Spreadsheet, for example. At the end of each day, put the number of tasks done that day in the Totals row. With the number of tasks that I am working on, I try to aim for 4 per day or better.

Why Do I Like This Better?

Figure 3: The board

Instead of using the number in the Totals row, I use different colors. I use green for making my target or better and then down through yellow, orange, red and black representing no tasks for that day. The scoreboard works on the same principle as the chaining used by Seinfeld, but with an added dimension. For tasks such as workouts which may follow a pattern other than every day, you can work to maintain the pattern for that task. Additionally, I find that the use of the colors in the Totals row provides some extra encouragement to get things done. If I am looking at my chart and am about to fill in a yellow when I have a chain of greens preceding it, that can often be the motivation I need to spend 20 minutes on a task that I would have ordinarily put off for another day.

Perhaps the thing I like best about this method is my ability to quickly tell how I am doing with my goals for a specific task or in general at a glance. In effect, this works for me like a Seinfeldian chain with a single goal: Be More Productive. As much as I wish I could leave things at a high level like that, I need more fine-grained control and motivation and by using Scoreboards, I have found a method that works exceedingly well for me. Hopefully it’ll work for some of you as well.

So, with SolidWorks basically bringing nothing to the table we realized we’d need to keep using AutoCAD to generate the drawings. Considering that DriveWorks automates SolidWorks this effectively removed all benefit from using DriveWorks. Also, we were having massive scalability problems with the web interface to the program, DriveWorks Live. So, the decision was made to build our own custom front and back end systems.

That was three months ago. That was 16,700 lines of code (not counting *anything* for the db) ago. That was untold hours of overtime ago. That was seemingly a lifetime ago.

So, now that we have that out of the way, life can begin to return to normal. At least as normal as it can be when expecting a baby and building a new house. Speaking of which, I have pictures of the house and pictures from the 3D ultrasound of the baby that I will be adding to the galleries in the near future. Lindsay is almost done her Computer Science class (C++ for a first year class?!?!!) and after that we just might start playing World of Warcraft again…if we can pry ourselves away from the Wii, that is.

So, expect to see more content here in the near future. I know I say that a lot and never come through but I am going to make a real effort this time. I have lots to talk about…it’s all been brewing up inside me and must be released. Later.