Wednesday, November 29, 2006

Calling [adultswim] Fans

Adult Swim fan? Thought to myself "would be nice to converse with fellow fans during the block". Especially during Sunday nights. Interested? Join ##adultswim over at irc.freenode.net, the next time you're watching [as].

PS - The double #'s is due to an oft-critisized policy at freenode for "non-official" channels to be moved to such a name, signifying it as an "about channel", and allocating the single # channels as "official".

Sunday, November 19, 2006

Bad Blogging Weekend?

Is it just me or does it seem like a bad weekend for blogging? I don't want to say I expect huge traffic, but I'm definately seeing a huge decrease in hits since friday night. Massive, even. Is a two-console launch weekend too much drain on the blogosphere to make much blogging worth it?

Saturday, November 18, 2006

Forums, Feeds, and Foundations for Answers

The web forum. Mailing lists. Newsgroups. They all boil down to the same thing: digital forums of discussion. We have relied on these mediums to carry the Internet from prototype to fad to craze to necessary base of our culture. The discussions we enable through the web (and its friends) drive everything we do in the digital world. How can we pay tribute to this with an upgrade?

We have migrated from discussing to just broadcasting our opinions. Maybe we'll tune in to some other opinions on similar topics. Maybe some of them will have read ours, who knows. We are deviating from the formula that has driven us to everything we think models the technology we desire. We need to move back to real discussions, bringing what we've learned from feeds, blogging, and content subscriptions.

Forums, beloved as they are, have lost their way. Unfortunately the number of Internet users has risen so high that no forum can carry nearly the percentage of knowledgeable users they once could. This leaves all forums at a loss for intelligent information and leads to a loss for anyone using them. Either we must spend eternity locating the perfect forum for each exact question, or we cross post dozens of forums and monitor them all for updates. This simply does not cut it.

Everyone has at least one feed these days, and what we feed the world with is still pretty limited. We write little posts, usually barely enough to call an article. We can post anything. We can feed the Internet our pictures, voices, or our minds. We can send out our questions, formatted for consumption, and allow everyone subscribing to our feed or receiving the questions through aggregation and search engines to get a full range of questions from the curious and in need. Instead of browsing to a forum page, we can find those in need through the same feed readers we already enjoy.

For the responses to the questions, the same feeds can be used to broadcast responses with meta-data attaching them to the right questions from the current feeds. The questions can even be posed with information on HTTP requests the responder can make to inform the original poster of a feed with a response.

No, this isn't even a draft of any idea for a technical spec. It is just a few ideas, and maybe even just enough for a micro-format. It would not be a lot to put together, would be less to pose the questions like this, and most of the work would be in informing those asking of the answers, but not much work.

Tuesday, November 14, 2006

Help JMRI

I don't even use the software from the JMRI project, but I had to donate a little to help their potentially important case. The violators are claimer that by being free (as in beer), all copyright is waived and thus any GPL restrictions are not even the project's own to claim. Wow, that is an evil claim.

Do what you can, even ajust five or ten bucks.

Self Promotion

I am trying to improve and promote my media (reviews and such) and arts (writing and painting) blogs, so here is a bit of shameless self promotion.

Spilt Mind has some ramblings about my attempts at rejuvenating my creative side.

Mental Outlash just got a review to the amazing Stranger Than Fiction.

Interested? Check them out. Otherwise, sorry to bother you. I want to keep these minimum. I should probably append some cross references to the end of the next post I write here.

Asyncronous Database Records

Through persistance systems, notably Divmod's Axiom project, i have been experimenting with the idea of asyncronous request of items which may or may not exist for some time. The idea is an abstraction of a terrible first idea for "persistant deferreds," which my very suggestion of lead to horrible responses over in #twisted, but well deserved, I now believe.

The concept is similar but perhaps simplified for the limitations and complications involved. Operations may return an "asyncronous item," which in my implementation is done by an Item implementing the IAsyncronousOperation ("operation" may be replaced with "Item") interface. This is akin to returning a deferred. The item allows the caller to control the response to the availability of the item, but in a way that can survive server crashes and reboots, and is otherwise a persistant record, and not an emphemeral object.

Borrowing additionally from Twisted, the asyncronous results can support both positive and negative handlers, set for managing the result as success or error. The creation of these handlers constitutes an additional asyncronous result, which can be used to chain handlers, akin to the callback chains of Twisted. In the event that the requested item is ready, which is either immediately or in the future, the appropriate handler is called and the asyncronous result handlers are cleaned up.

I will release the code soon, when the rest of the unittests are complete and an example usecase can demonstrate the usefulness. I have gotten some negative reaction from this one, and I really hope it can be attributed to misconceptions of my intent and failure to consider the right usecases. Hopefully I can remedy this.

Wednesday, November 08, 2006

Design for Testing

Good testing influences your design. Too many developers (and managers) are stuck in the waterfall mentality of design, code, test, and deploy. Forces across the industry are pushing to move the testing phase to the beginning of this line, and many just don't understand how that works. Testing should be the first consideration, and thus is influential to all other aspects of the development process.

The problem with testing as a secondary consideration is the design and architecture of the software never lends itself to proper testing when you don't plan way ahead. The consideration of testing can drive your design to be easier to test, but also can encourage generally good programming practices and well-made designs in the architecture. We can use a persisted class as a good example, because this is a use-case where testing is very important, but we have to consider the burden of a full database tied into the class we are testing.

When we develop our database item class before any testing is considered, we create it fairly in a straight-forward manner. After everything is coded, we decide to do some testing but we have a couple problems to face. The first thing to concern us is that our class inherits some ItemSchema super-class, and instances of it must exist in context to some database, which creates a large dependency on the test and thus leads to the test being unreliable. Secondly, we have many functions not easily testable (perhaps they can only be confirmed by locals within the function, which we can not access). We need to redesign everything to solve these issues, but we could have avoided this by using a more testable design in the first place.

To solve the first problem, we have to consider what we are actually testing. We are not testing the persistence framework our application utilizes, but just one ItemSchema sub-class we had to write. Obviously, separation is key. We only care about the functionality we wrote into the type, and we can extract all this into a mixin class, which our original ItemSchema can inherit. However, in our tests, a special TestItem class may also inherit it and perform the testing we need, without bringing a database into the picture.

Tackling the second problem of individual functions, the solutions can vary. If any internal data is important, perhaps it is too internal, and the code generating it could be extracted into its own method, which we can test independently. If our method does not return anything, perhaps this is something it could return and thus we could test for it. However, don't return things you do not need in production, as this bloats the interface and inevitably some code will come to depend on this contract that was only intended as a testing mechanism. It can even be acceptable to wrap a returning method with a public API non-returning version, simply to push a more stable API (it is easier to add returns than remove them) to the consumers of the API.

We have to stop looking at the testing as a second, or third class citizen in the steps we take in development. Our design, development time-lines, and architecture should all be done with testing and quality assurance first in mind. We must focus on how to ensure the stability and accuracy of our code before we can ever trust it, and if we can not trust it, all time developing it is a waste. It is this fact that offsets all arguments by opponents of proper testing (yes, they exist) who are afraid of the time wasted by testing. Wasted time is illusionary, as we only see the time it takes but we don't see the time it save us. However, isn't that the point?
I write here about programming, how to program better, things I think are neat and are related to programming. I might write other things at my personal website.

I am happily employed by the excellent Caktus Group, located in beautiful and friendly Carrboro, NC, where I work with Python, Django, and Javascript.

Blog Archive