The good news is that I’ve made considerable progress over the last six weeks overhauling the back-end to make it easier to maintain and expand. I’ve also learned a lot more about relational databases in the process, which is good for me if not the plugin users.

The bad news is that this process isn’t finished yet, so it’ll be a little while longer before there is a new version available. I hope that anyone out there who is waiting for a new release isn’t too disappointed.

In terms of functionality, I’ve updated the API requests to grab all the tickets for a project, instead of just the first ‘page’:

Still, not to worry. To avoid confusion and general awkwardness, I’m going to change the name of the app to Limelight. I’m pretty sure that there are no existing apps in the same domain with that name. Pretty sure. Not 100%. So if there are any app developers out there developing a Lighthouse app called Limelight… I’m sorry in advance. Hopefully I’ll be ok this time though.

I’m going to release a new version of the app with the changed name in the next couple of days.

Lighthouse is a lightweight hosted bug-tracker produced by entp. It’s advertised as “Beautifully Simple Issue Tracking”.

Lighthouse Keeper is a small AIR app produced by me. It allows you to export Lighthouse ticket info to a csv file.

Background

I learned about the existence of Lighthouse earlier this week at a job interview. I’ve used a couple of bug-trackers before, but Lighthouse had never appeared on my radar. The two guys interviewing me got into a spirited conversation with each other about the various pros and cons of different bug tracking solutions, but Lighthouse in particular. One of their comments was

I wish there was a way to export my tickets as a csv file.

Maybe someone will come up with something using the API.

That’s a challenge if I’ve ever heard one.

Implementation

I’m a big fan of Flash/Flex, so I set to work that evening on a small app that would grab Lighthouse projects for a given domain then allow you to perform searches on the tickets in an individual project and export the results. Fortunately, flex is designed around tasks just like this.

Lighthouse has a fairly comprehensive REST API available for developers. Using either your regular login info or a generated API key, you have access to (as far as I can tell) all of the functionality you get from the regular web interface.

Thanks to this, retrieving data from the API was achieved in less than an hour, and then the rest of the time (about 6 more hours) was spent wrangling it and tweaking the interface.

The current incarnation is still very much an experimental product, but I want to release it to let people (and prospective employers) test it out and see what they think.

Download

So, without further ado, here it is:

Lighthouse Keeper version 0.1

As always: Questions, comments, suggestions and criticism are welcomed and encouraged.

It seems though that there is still interest in the plugin, so over the next few weeks I’m going to give it an overhaul. It’s been a long time coming, and since I first wrote the original code I’ve learned a lot about the ‘correct’ way to program web apps.

The current code is not very flexible: In order to implement the new features that are in the roadmap, I’m going to have to start again from scratch. This time I’m going to give the plugin a proper DB back-end, so that reaction text can be updated without resetting the count, and so that posts in different categories can have different reaction options (and a lot of other things, too!). This should also make it a lot easier to maintain and add further features to.

So, if you use wp-reactions, or are holding off until some of the features you want are available, rejoice! I expect to have a new version available by the end of the year.

I recently started playing Dungeons & Dragons (4th Edition) after listening to the podcasts Penny Arcade did at Wizards of the Coast (who publish D&D). I’m DMing the Keep on the Shadowfell campaign for a bunch of other new players. We’re all thoroughly enjoying it. And yes, that makes us all thoroughly nerdy.

I don’t have very many miniatures, which is a problem because 4th Edition relies heavily on moving characters and monsters around on a grid during combat. There are many alternatives (such as Lego men, dice, or other small objects), but I wanted something a little slicker. I wanted my game pieces to have a uniform look and feel, and not break the immersion by forcing the players to think too much about what each item represented:

“Ok, so the quarter is a goblin, and the dime is an orc. No wait, the dime is the goblin, and the quarter is the orc. Got that? Oh, and 3 more goblins appear from around the corner. Does anyone have any change?

I had a look round online for ideas for replacements, and found several people had made their own tokens using images found around the web. To be honest I was disappointed by these, as they were usually mismatched and of dubious quality. I needed a better solution.

This is how I came to design my own tokens to use in place of miniatures for D&D. I spent some time learning how to use Inkscape (which is an excellent piece of software, btw) and came up with some generic token designs that can be adapted to represent many different monsters. Here are some samples:

The basic design is this: The monster’s name is printed round the edge of the token, their race is represented by the upper icon, and the monster’s role is the lower icon. The roles in the sample are (clockwise from top left) Soldier, Swarm, Minion and Artillery.

Interestingly, some experienced players I’ve recieved feedback from already have said that I’m providing too much information to players by putting the monster names and roles on the tokens. I would definitely like to hear from anyone who plays D&D or other role playing games what they think about this.

Once I have finished running my current campaign, I plan on putting together a pdf with all the tokens in and releasing it under a Creative Commons license. This would just be a first stage, however. Eventually, I want to have an online generation wizard that allows people to create their own tokens from the templates, put them in a pdf and print them for their own use. This may take some time, as I have no idea how to programatically create/edit svg files. Cross your fingers, and maybe a few months down the line you’ll see something along these lines appear.

A quick Google search revealed this: Marquee Component. Fantastic! One of my favourite things about working with flex is that there’s a huge community out there who have already written the component you need in 90% of cases.

Still, I needed to adapt the component to fit my needs. The ‘secret project’ involves a media player, and the marquee was for the song title. I wanted it to display the artist and title at a fixed width, but scroll back and forth if the text was too long. I call it a ‘bounce’ marquee. Here’s the demo.

The first modification I made was to change the way in which the component defined the movement. The original marquee had a property defining the duration of the scrolling. This was unsuitable because it meant that longer text scrolled faster. Make the string long enough, and the text would scroll past too fast to read. Instead, the bouncing marquee has a scrollSpeed property that defines the speed in pixels per second. The length of the string (in pixels) is divided by this number to produce the duration of the scroll, which is then passed to the Move effect.

Secondly I changed the effects to match my desired behaviour. I simply defined to Move effects with Pause effects between inside a Sequence. The first move takes the text from it’s initial position to and scrolls it until the end of the string can be seen. The second move takes it back. The length of the pauses can be changed by overriding the pauseDuration property on the component.

This was all well and good, but there was still a problem. Updating the properties of an Effect whilst it’s playing does not take effect until the effect is stopped and restarted. Therefore I needed a public update() method to be called that would reset the effects and allow the changes to take place.

All in all I’m pretty pleased with how the component turned out. The hardest part was figuring out why the effects weren’t updating properly when I changed the text. It seems there was a timing issue that judicious application of the validateNow() method fixed. For the curious, here’s the code for both the component and the demo:

• Bounce Marquee version 1
• Bounce Marquee Demo version 1

Current Features (version 0.6.6)

Features that are working in the current version:

• Add reactions to new posts. 100% complete
• Manage reaction descriptions for future posts. 100% complete
• Ability to apply reaction updates to all existing posts (not just new ones). 100% complete
• Add CSS classes to the generated markup to allow authors to style the form as they see fit. 100% complete
• Include an option to add ‘question’ text before the reaction form. 100% complete

Upcoming Features

Features that I am currently working on:

• Have different sets of reactions for posts in different categories. 0% complete
• Add a cookie/IP based filter to prevent users from posting the same reaction multiple times. 0% complete

Future Features

These are features that I want to include in the plugin at some point, but do not have a concrete plan for yet:

• Stats Tracking. 0% complete
• Give authors the option of making the reactions mutually exclusive (i.e. Users can only check one reaction per post). 0% complete
• Internationalize plugin. 0% complete
  

It is by no means complete, but the functionality that is there works 100%. At least it does now. There was a bit of a panic when it first went up because I was stupid and left out some important test cases. Oops! Oh well, live and learn. The most current version (which should work) is 0.5.2. Download wp-reactions here. With any luck you should be able to see it in action on this very post!

The plugin itself is still not ready for public release. If you look at the demo, you’ll see that you can un-check a box after checking it and the counter will still go up. There’s a whole bunch of other stuff that needs changing too:

• The reaction text is hard coded. I need to write an admin page that allows the user to specify the reactions they want to display and some extra php to actually display the correct text on the page.
• As mentioned above, the UI needs some work. Specifically, the check boxes need to be grayed-out after being clicked to to prevent users spamming the system.
• It would be nice to have some sort of check performed to see whether a given user has already rated a post and correctly display this information on return visits.
• I would eventually like to have an admin tracking page that can be used to display the highest ranked posts for each response. I would also like to implement a widget that can be used to display this information to visitors if desired.

The last two points probably won’t make it into the first public release, as they aren’t essential to the functionality of the feature. The first two are essential though, and hopefully I’ll get a chance to work on them sometime this week.