I was delighted to check the school of computing online marks system late yesterday and discover that my project in Python had gained me a first (78%) in the module. It’s certainly inspired me to continue the development of TIM just as soon as I have time, and to bring it up to release candidate standard 🙂

I have been looking at the number of bugs submitted for TIM and there is plenty to be cracking on with, so once again thanks to all who have been testing and enjoying using the application. I was speaking with Niall on MSN last night and there was a hint of interest in assistance with the development of TIM so we may well have more people on the team soon, and so be able to make it a lot better.

I have allocated some time to more TIM development and bug fixing in a week or so’s time (when it won’t ruin my ability to code in Java), and will try to get a second alpha release out a few days after. Beta shouldn’t be far after that, assuming of course I don’t decide to make the application more feature right and thus plunge it firmly back into dev status. I hope to at least get a release candidate version out for those who want a bug free version of what they have already before adding more features though.

Watch this space 🙂

Well, the se12 python project officially ended today with the completion of the final report, fulfilling the last requirement of the project (apart from this, the “final” blog that is). Before I reflect on how the project has gone, I would like to reassure all those who have been testing TIM that development *will* continue! This is just an official end to the project as far as my course is concerned, but TIM will live on 🙂

One requirement of the project was to make a reflection on pair programming as well as the project as a whole. Always being one to break with convention, I did this near the start of the project, and it is here: https://www.kieranoshea.com/2006/01/29/pair-programming/

In terms of project reflection then, well so much to say! First off, like many other projects I have taken part in to develop something, I enjoyed it. Seeing something go from an idea into a working application is always an enjoyable experience, as is recieving feedback and being able to make further improvements. Far from simply enjoying it though, or successes with respect to the application compared with the project spec, there is the issue of using a brand new (to me) programming language.

The Python programming language is one I had only “heard” of before I embraked on this project, but on those occasions I had been told of it, all reviews pointed to it being a language very suitable for rapid development and creating portable applications. Before I could even attempt to test these reviews however, I needed to see if Python was as rapid to learn as it was to use. Not wishing to invest in expensive texts, I studied existing applications and online python documentation, immediately started to press into service core programming methods that I discovered; trying them out using the python interpreter and small python executable text files. This approach worked well, and within a few days I was actually remembering that curly brackets and semi-colons didn’t belong in python and that nicely indented code was no longer something that was done for ease of reading and fault-finding, but was an actual run-time requirement of the language.

If I had any problems with the language, it would have to be its differences compared with other languages. I will cite java and php here as those are the two languages that I am most familiar with. Curly brakets are nice; they help me see loops, see clearly where you jump out of them and where they are nested. Indentation is good, but I like to use both. Python not having these caused me some issues, but emacs came to my aid with its syntax highlighting and various python related tools for the unwary newbie to the language. I quickly got used to not using semi-colons. So used to it in fact that when I returned to java for some other work I had to do, I was annoyed I had to put them in. Other interesting syntax issues included the “elif” difference and the colon at the start of methods, if statements and loops.

Syntax aside though I like python. Quite a bit more than java in fact, mainly because I hate bloat, and python didn’t have any (or hardly any). I loved not having to declare the types on new variables, I liked being able to store most anything in arrays and the like. Object orientation is a whole different matter though. Java = Nice+Complete, Python = NASTY. I’m not saying that object orientation wasn’t possible, and I did implement it into the application, but the way some things are done makes you cringe after using java. The requirement to use “self.” is a notable example. In java you can use it or not and it makes little difference in an ordinary method. While I quickly realiased how python liked to work with respect to these things it didn’t stop it from being annoying 😉

So, back to if Python is a good language for rapid development…. yes it is! The speed with which I could write and test methods to do things was astounding. While this was purely down to less bloated syntax, it held speed improvements both in the time taken to write and the time taken to debug if there were problems. With less lines to look through, debugging is simply easier. The language was especially rapid for the GUI development in wxPython. Windows could be made to appear in a few lines, and getting them to contain what you wanted and appear when needed was just a few lines more. While some things in Python are a little complex and abstract, overall for speed its a great language to work with.

Something that is often asked about things in general is “Would you do it again?”, so in Python, would I code in in it again? Well, I have already answered that question at the start of this posting. I will indeed code in python again as I am going to continue the development of TIM. The application has real potential to be very useful as a complementary tool to all who listen to music on their computer systems, and so with a demand from users and the developer’s will to make it better, TIM will be taken forward (hopefully to an RC stage) in the near future 🙂

Its in progress and coming along nicely. Dan and I have agreed on all of the things to discuss, and had a productive session on it this morning/early afternoon. Hopefully we should be able to make everything gel well, cover all the points and be long enough, although there is plenty to say in the evaluation which we have yet to start.

A number of issues have already been reported with TIM, and as a result we have opened a “bug tracker” to display all currently reported bugs so that we don’t get duplicate submissions. Feedback on current and desirable features is being considered, but most importantly we are accepting ALL bug reports and are in the process of squashing them – if you find a bug and it’s not on the list, please report it as it will greatly help the development of TIM.

Thanks to all those who have tried TIM and have been providing valuable feedback. If you have already reported a bug you have been credited on the development page. If you find anymore please keep sending them to us and be sure to tell any techies you know about TIM Alpha and get them to help test it!

Well, we finally made it 🙂

An alpha version of TIM (Tagger and Indexer for MP3s) – a project for my computing course, has been released. Please feel free to download, test and evaluate this version of the program and submit feedback and bug reports back to us for improvements to be made before the beta and eventually final releases of the program.

You can grab a copy from our development page here

Its the little things that really make an application look good and perform at its best (especially when you have the back-end stuff working to a good standard), which is why getting the “First Run” wizard working made me really rather happy. When you run the application, a check is made to see if the database (with mp3 info and application variables in it) exists, and if it doesn’t it is created and initialised with the variables the user has selected in the wizard. Furthermore the application won’t start if you don’t complete the wizard once, so it means it never starts without its variables. Once again for those that like the eye candy….

There has been a long-standing bug with TIM in that the Re-Index function would re-build the index of files and so the database (and show a nice progress bar as blogged about all those weeks ago), but the problem was, it wouldn’t actually purge the list shown on the screen and re-populate it with said revised data. Any attempt to do so resulted in nasty errors that simply impeeded progress on other fronts.

Well, its been fixed so HA! WHOOP! I know it doesn’t make for a professional development blog, but what the heck, it felt great to see something that had been broken for so long working as intended 😀

…but now that I have been at home for a while its straight back in at the deep end with the Python seeing as I’m back in Leeds 🙂

Its all laid out, a lot of code is complete, its just a case of wrapping it all up together nicely and getting it looking good. There is also the report to think of; so much to say, I must say its going to be one of those reports where I have to think carefully about what to leave out rather than put in!

With a nice progress bar! The number of files that TIM has to chomp through is quickly calculated (a second or so of time), and then this number combined with a piece of code to increment a second value by one every time a file is indexed provides all that is needed for wxPython to produce a progress bar. As screen shots look nice I have posted another one below, illustrating TIM’s progress bar. This is very useful for large numbers of MP3s as the user is given both a physical indication of how much has been done and has left to go (the bar) as well as an accurate “time left to wait” figure. This is dynamically calculated depending on the average time between each operation, and is kept up to date and gets very accurate within a couple of seconds.