tech « Seth May

Archive for category tech

ResponseHound project update

ResponseHound has been an incredibly useful tool in my most recent work project. My team is building an application that uses a GWT (JavaScript) client-side app connecting to a PHP server. They communicate using JSON. As usual, some of the more stringent testing (unit) has been pushed to the side. ResponseHound gives us a way to validate that the entire server system is doing what it’s supposed to be doing for each incoming request.

I’ve been continually adding new features here and there as I find that I need them. I have not been pushing these out the git repository since I have not documented them well or fully tested them. I’ve also been throwing around some alternatives for writing tests. This might include a more OOP based approach. I’m also eyeballing an possibility of XML tests. That seems a bit trickier.

Some of the features that I’ve added that need testing are:

  • Request options
    • Show the full request URL
    • Show all response data formatted
    • Show raw response data
  • Conditional tests
    • Test will only execute if another piece of data matches the condition
    • Match against null/notNull, a single value, or a set of values
  • Direct JSON request emulation
    • Allows passing JSON directly in for a request
    • For complex requests, this is very useful

Hopefully, I’ll be able to get these tested and ready for release soon. I also plan on putting together a full demo soon, complete with testing-rig controller.

I’m always open to suggestions or recommendations. Send me your comments.

You can find more info on ResponseHound in the wiki:

, , , ,

No Comments

The Story of Spaz: How To Give Away Everything, Make No Money, & Still Win

ZendCon 2010 – Tuesday Morning, 10am UnCon Session Summary.

Presented by Ed Finkler  – @funkatron (

Ed Finkler has been on Spaz since 2007. Spaz is an open source micro-blogging client. He joined the twitter dev mailing list, became a moderator, back in the days when Twitter had 6 employees. Initially, Spaz was writen in Real Basic. There ended up being a lot of issues with this language (such as theming, and inline linking).

Ed had a strong working knowledge of CSS & HTML really well (JavaScript, not so much). That lead him to Apollo (which later became adobe Air).  There was a lot to learn about JavaScript such as ajax and event handling. So he rebuilt the app. There was some initial interest in the app, especially since it was one of only two desktop apps for twitter. He ended up winning some contests with Spaz, such as a computer and a chair. Plublicity was welcome and abundant in the early days.

From there, things got a bit more complicated. Soon, Ed  started to take some flak for the name, as it was a bit offensive in the U.K. (spaz is a derogatory name for someone with cerebral palsy). Feature requests could be a bid downer as well. Big comparisons started to come up between his app and other twitter apps. People like shinny thing, it gets tem excited. Most end users don’t care if something is open source or not. They care if it’s free or not. When people work with developers, they tend to treat them as nameless, faceless entities, not real people. It’s can be really hard not to get offended by the comments and feedback. People are unaware of your motivations, or they just don’t care.

Eventually, twitter changed their authentication to OAuth, most the other free systems didn’t change their systems. Spaz did and so the user base tripled over a couple of days.

Adding new features like image uploaders became hot spit. Comparisons and feature requests to match other apps started coming in fast and furious. Since this was open source, all development was happening in Ed’s free time. It became impossible to keep up with the demands.

He was then approached by Palm to discuss using the twitter app on their platform. He agreed and signed an NDA. This became very difficult since sharing code is an intrinsic part of who he is. Even though he was told that he could open source the code, they still attempted to stop him the weekend before launch. They really just didn’t get it (today, they have done a much better job of embracing open development on their platform).

After this experience, Ed had to redefine what his definition of success was. He ended writing a declaration of purpose to specifically define what the project was about and the goals it was meant to achieve But he really needed to help. Continued development couldn’t be done by just him. Two platforms, building a community, and the decision not to charge for it where all major factors in the need to bring in more people. Ed wasn’t even testing on a device, emulators only. Getting a device really helped increase motivation. “Eating your own dog food on a consistent basis really helps motivate you”. Using your own apps helps you focus on improvements.

Ed then spent most of 2010 cultivating a community. Originally, Spaz was hosted entirely on Google Code and Google Groups. It was then moved to GitHub which allowed for a better social environment. Go where the community goes.  A lot of developers, especially JavaScript developers, where already on GitHub. This made things the project higher profile and easier to interact with. He also started to use TenderApp and Lighthouse for much better for issue tracking. It made things easier and simpler for people.
Road-maps and milestones also became important tools for the Spaz project. It really helped the community to see what was going on and focus them. Hack-a-thons also really helped bring people together, even when people weren’t working on it. If you want people to work on your project, you need to give it to them in small, bit-size segments, that they can sink their teeth into. If you say “work on what-ever”, people will quickly get overwhelmed and back off, and no one will help.

Take away:

  • “Eating your own dog food on a consistent basis really helps motivate you”
  • Cultivating a community – Go where the community goes. Make it easy for the community to contribute and buy in.
  • Make good things in the right way.
  • Keep it pure: do it because you love doing it.

, ,

1 Comment

Cydia repo and rebuilding apt on iOS4

It took me quite a bit of work to locate the cydia repo so that I could manually download packages. So here it is for future reference (for the most current version):

or to the repo root:

Installing apt7 took the following packages:

  • apt7_0.7.25.3-6_iphoneos-arm.deb
  • apt7-key_0.7.25.3-3_iphoneos-arm.deb
  • apt7-lib_0.7.25.3-9_iphoneos-arm.deb
  • apt7-ssl_0.7.25.3-3_iphoneos-arm.deb
  • berkeleydb_4.6.21-4_iphoneos-arm.deb
  • curl_7.19.4-6_iphoneos-arm.deb

Word of advice: don’t hose apt on your iPhone. It makes things suck.

, ,


An AllTest Workaround For PHPUnit

PHP + Unit Testing = Pain in the rear!

I have a fairly large library of PHP code that I maintain. It’s been one of my goals over the last year to implement unit testing for as much of this code as I can. The process has gone fairly well, but one BIG issue always seems to come up: when I attempt to group my tests into suites, class conflicts occur.

This is due to the fact that I have stubbed out many of the classes that are dependencies. These classes, obviously, have the exact same name as the classes they are replacing. If you include a test for object X and then include a test for object Y which requires X (which has been thoughtfully stubbed out), you get this fine error:

Fatal error: Cannot redeclare class X in Y on line N

I know there are various ways around this, many of which require a fair amount of refactoring. I just don’t have the time or energy to undertake that task right now. BUT I still want an AllTests suite that will allow me to run all my unit tests for my project at one time! Manually running hundreds of test is no good. Manually running dozens of small suites is no good. Here is my work around.


Go from hand executing a ton of tests/suites to executing all of them in a single call. It would also be nice if we end up with some nice output from the entire things. Say, something like this:

1. We need an install of PHPUnit

Install PHPUnit from PEAR. You can find the instructions here:

I’m currently using v3.5. It won’t work with the PHPUnit that comes with Zend Studio. You also have the added bonus of using the most recent version, which can be very helpful, indeed.

2. Setup you suites as XML files

Let’s assume the following directory structure for this example:


Our next step is to use the XML configuration system for setting up PHPUnit test suites. I typically put my xml files in the same directory as the tests. Here is an example of one of my files:

library/Project/Class1Test.php library/Project/Class2Test.php ...

I use /tests/unit as my root directory for all things unit test. The bootstrap.php is located here and all my tests are referenced from that directory. You will notice that the bootstrap is referenced from the location of the AllTest.xml file.

3. The bootstrap.php file

The bootstrap.php file is used to setup anything that is needed commonly for your testing environment that can’t be done from your tests. This includes things like PHP INI directives and environmental variables.

<?php set_include_path(implode(PATH_SEPARATOR, array(realpath(dirname(__FILE__)), get_include_path(),))); $newPath = "../../"; set_include_path(implode(PATH_SEPARATOR, array(realpath(dirname(__FILE__) ."/". $newPath), get_include_path(),)));

My file sets the unit test path and my project root path in the php include_path. Place this file in /tests/unit.

4. AllTest.bat file

Yes. I’m in a windows environment. WISP to be specific, and all the joy and happy butterfly flowers that it brings. That said, batch files seemed to be a decent way to go to accomplish what I needed. PowerShell might have worked too, but I have no experience with it. So enter batch hell.

Rather than write out the entire file here, I’ll just summarize the basic functionality:

  1. Set environmental variables: working directory, timestamp, program root directory, config file location
  2. Read in the config file (unit.ini)
  3. Scan all the directories in the unit test folders looking for files named AllTest*.xml
  4. Execute phpunit on each XML file, using the –log-junit switch to generate an xml log file for each test.
  5. Execute my merge.php script to take the individual XML log files and merge them into a single XML file. The script also executes an XSL transformation on the log file to generate an HTML output file.
  6. Open the HTML output file in firefox for viewing.

You will notice several files that I listed in there. Here’s what they are:

  1. unit.ini: a basic configuration file. This was an attempt to handle as much configuration as possible outside the batch file. Moderately successful.
  2. merge.php: a php script that reads in all the phpunit generated log files, merges them together into a single XML log file and executes and XSL transformation on the final log file.
  3. plain.xsl: a modified version of the JUnit stylesheet. Used to transform the log.xml file into a log.html file for easy viewing
  4. log-x.xml: the various xml file output by PHPUnit. One for each AllTest*.xml file that it encounters
  5. log.xml: the merged version of the individual xml files.
  6. log.html: an easy to view version summary of the phpunit output

You can take a look at each of these files. Once everything is said and done, I end up with a very useful summary of my phpunit tests. It’s actually more useful than the output that is shown in Zend Studio (v8 beta2).

It might also be a good idea to create a customized version of your PHP.ini file that has at least the php_xsl extension turned on as well as any other settings required for your environment.

Everything is pretty rough, but it works well enough. The same technique could easily be ported over to a shell script. It’s now saving me a lot of time and helps me quickly validate my entire library in a single execution.

Get the project files here:


, , , , , ,