You may have noticed the new KnitML Issues Tracker link on the sidebar. Matt, our fearless web admin, has installed Bugzilla, which is a vast improvement from what SourceForge was offering. Bugzilla will be KnitML's central repository for issues.
Some of you may not care for Bugzilla, so I have to let you know that it was not my first choice. Ideally I wanted JIRA, but our hosting service here at knitml.com doesn't support Java. We tried out Mantis, which is PHP-based. The interface was nicer than Bugzilla, but we could not get it to integrate with Mylyn, a task-based plugin for Eclipse which is an integration point I think is necessary. Since the Mylyn project grew up using Bugzilla, and integration with it was incredibly simple, it seemed like a no-brainer.
That said, Matt has done everything easy he can to make the web interface a bit more bearable. He removed the picture of a nasty-looking microscopic bug which comes with the default screens. He also installed the Flat Green skin, which makes Bugzilla look a lot more Google-esque than the traditional I-was-clearly-developed-by-hardcore-computer-science-geeks skin (though I think they just call it the "default" skin).
If you still object to the web interface, I would highly encourage you to try out Mylyn 2.0. It comes with the newest Eclipse Europa package. You can interact with Bugzilla completely within the confines of Mylyn and Eclipse without ever having to go the website. It's quite slick.
You do need to create an account to report bugs. This is mostly so that you can be informed of the progress of bugs through e-mail if you prefer. Your information will be completely private. I promise I won't sell your e-mail address to anyone and I won't use it to communicate with you directly without your permission.
Now... bring on the bugs!
[ add comment ] ( 6 views ) | [ 0 trackbacks ] | permalink
In perusing the web recently, I stumbled across MusicXML's successful attempt to standardize an interchange format for many different music softwares. They have several recommendations to make regarding incubating standards for a niche market. Read the full article here, or just the highlights from the article below:
- Apply usability techniques to language design in the same way that you would to GUI design. Use terms that domain experts understand. Where possible, avoid introducing concepts that are specific to applications in the domain, rather than to the domain itself.
- Develop the format together with software that reads and writes the format. Use evolutionary delivery to deliver early versions of both the format and the software, with frequent iterations to get both working well together. This particularly helps for meeting the twin goals of completeness and usability.
- Make sure that the format can exchange data in both directions with at least one market leader in your application area. Do this as early as possible in your development process. Do not expect the market leaders to do this for you.
- Market to other developers who would get a business benefit from using your format. This will be difficult until your format can exchange data with a market leader.
- Give format developers good support. Involve the development community in the design of the format. Be responsive to developers who are using early versions of your format and translation software.
- Avoid overhead. In a small market like music notation software, organizations like ISO and OASIS can be too costly in both time and money for even the largest industry players. Following the model of Adobe's PDF format - an open format under single company control - can be more effective in these situations.
In short, I think our instincts for what to do and how to do it have been right, or at least have been justified. I definitely see their point about standards organizations. Besides, they don't seem to want to talk to me anyways. :)
[ add comment ] ( 2 views ) | [ 0 trackbacks ] | permalink
If you are looking for ways to help (and I know that many of you are), here are some things that you could do:
- Get familiar with XML, XML Schema, and what I have done so far with KnitML. You certainly won't need the nitty-gritty details of XML Schema, but at least enough to understand which options are available.
- Take your favorite patterns and attempt to convert them to KnitML (as I have done with the sock pattern). If there are things that are missing from the XML Schema that you need, add a feature request on the SourceForge tracker. This will help us fill out the spec to emcompass all types of knitting. If it works and validates, I'll publish the pattern on the website.
- If you are a code geek, install a Java JRE and try to run the validator. Get familiar with the code base and make recommendations for improvement.
- If you are multi-lingual, translate the instructions.properties file into your favorite language using the conventions of that language. See if you can get the renderer to make the pattern look like what a normal pattern in that language would look like. If something doesn't work, submit a bug or feature request.
- Start building your own software that does something cool.
The possibilities really are endless. If there is anything else you'd like to do, including helping me refine the pattern renderer or expand the validator, please let me know.
Thanks for everyone's support!
[ 7 comments ] ( 141 views ) | [ 0 trackbacks ] | permalink
After poring over the KnitML Pattern Renderer code base for awhile, I decided that it is finally time to check the project in to SVN. Run com.knitml.renderer.driver.Driver and see what happens!
Right now, the driver program renders much of the pattern, with some quirks and omissions (and a stack trace to boot!). Also, I feel a bit guilty about this, but there are absolutely no unit tests for the pattern renderer. I know that they should be there (and I hope to get them there soon). It's just a bit more of a pain to run the XML-based tests, and I haven't really established the framework code necessary to do that just yet.
Here's the architecture in 500 words or less (and no pictures). The Pattern Renderer project uses the visitor pattern (just like the Validation project) to walk through the XML and send rendering events to the provided renderer. The file it uses (validated-pattern.xml in the com.knitml.renderer.driver package) The rendering implementation I am using, BasicTextRenderer (in the com.knitml.renderer.impl package), is largely driven from Java resource bundles, making it easy for messages to be locale-specific. Currently, all instructions are in the instruction.properties file in the base Java directory (next to the Spring applicationContext.xml file). If you don't like the way some of the messages are written, it's easy to change them to the verbiage you prefer. I'm not suggesting that end users will ultimately be opening text editors and changing property files, but you have to start somewhere! I currently have some indenting problems that need taking care of.
I had to alter the way the "turn the heel" instructions were organized. Instead of embedding an <instruction> tag inside of a row, it was much easier from a rendering perspective to provide the ability to render a "row" that may not actually start at the beginning of the row (i.e. has unworked stitches before the starting point on the needle). So <row at-beginning="false"> now indicates that the row (which still gets a new number) starts with unworked stitches on the right-hand needle. This is mostly a directive for the validator to prevent freak-out under these circumstances.
I've realized that it is relatively difficult to write algorithms for processes that most of us don't even give a second thought to. This time around, it was the idea that the instruction such as this one:
<row number="1">
<repeat to-end="true">
<knit/>
</repeat>
</row>
should be rendered like:
Row 1: Knit
rather than:
Row 1: k to end
I had to write a recursive algorithm that, through process of elimination, had to "deduce" that it could render a simple statement. Much easier said than done. I spent a few hours on the plane working out the algorithm, showed my wife, and she replied, "You just spent the last 2 hours doing only that??" So it goes.
There are some ugly things about this code, and I am fully aware of this. There needs to be some refactoring and documenting to bring the project up to snuff. However, I felt that it was important to get something out the door and working, because I think a lot of folks are waiting for something to work with before they get involved.
Additionally, I found out today that KnitML got linked to from BoingBoing. The blog had about 6000 hits yesterday (up from an average of 20 per day). So the word is spreading, which is really exciting! I will make another post soon as to some things that you can do to help out immediately with the KnitML effort.
[ 1 comment ] ( 29 views ) | [ 0 trackbacks ] | permalink
So the KnitML subversion repository is now being monitored by FishEye. Thanks so much to Atlassian for free software licensing for open source projects, and to Cenqua for free hosting. Check out the URL on the Links navbar to see what's been happening to the code base.
Right now, it's just me as committer. You can see all of the changes I have made and how the various KnitML artifacts are shaping up. I've been sinking most of my time in the Pattern Renderer, which I haven't checked in yet. It's almost at a good check-in point, and hope to do that by the end of the week (before the real holiday madness starts). Full internationalization support is being considered every step of the way, so if you are bilingual and want to help translate the instructions into a different language, please let me know!
One of the neat things about loose coupling is the ability to swap out different implementations of various interfaces. I know that there is a decent amount of Python experts out there, so if someone wants to write some Jython-compatible Python modules, we can swap them in and out of the Java core without even blinking an eye.
Thoughts? Please leave comments! I'd love to hear from you.
[ 3 comments ] ( 28 views ) | [ 0 trackbacks ] | permalink
Archives
