I just announced it officially on the team’s Launchpad page, but Entertainer 0.4 is out. Check out the installation instructions on the wiki for the play by play of how to get things going.
Thanks to all the other developers who help make Entertainer possible. You guys rock.
I just finished reading Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic (yes, one of the authors identifies himself/herself as “chromatic,” presumably for privacy concerns). All in all, the book was eye opening in understanding the world of testing in Perl. I develop Perl code at work in a culture that does not focus on unit testing, but, equipped with the things that I learned from this book, I am now even more adamant that I will be creating unit tests for all of my future Perl code.
Unlike Python’s core testing library, unittest, which is focused on objects and test methods, Perl’s core testing libraries, Test::Simple and Test::More, are focused on procedural style testing. As a consequence of being procedural, Perl test code has a style that reads very differently from a Python test case, and it is this style that was so eye opening about the Perl Testing book. The style difference isn’t a bad thing, it just requires some mental adjustment shifting.
Perl Testing is written in a no-nonsense manner that jumps straight to a solution for how to solve some hard problems when testing Perl. Personally, I think that the book’s style makes the material such a useful resource when considering how to test a problem. The Perl community likes to say TIMTOWTDI, which means “There is more than one way to do it,” but sometimes there are too many ways to do something. Langworth and chromatic provide lots of solid examples of how to test things so that you, as a future Perl test code author, will not have to recreate the logic necessary to test some really challenging code.
The book isn’t perfect, but the overall quality of the material, and the incredibly helpful libraries that it introduces, makes Perl Testing: A Developer’s Notebook a valuable resource for any Perl developer who wants to test his code (which should be every Perl developer).
My previous post on installing Entertainer proved to be quite popular. Since quite a bit has changed in Entertainer between 0.1 and 0.3, I’ve decided it would be worth writing the instructions again to prevent confusion. However, for the benefit of people who never see my blog but will visit Entertainer’s Lauchpad page, I have decided to provide the instructions as a FAQ in the team’s Answers section.
Please visit the FAQ for how to install Entertainer 0.3. My apologies for the redirection, but it is for the benefit of many.
This should be educational:
matt@eden:~$ sudo apt-get install perl-doc
matt@eden:~$ perldoc perl
(and all associated sub-parts).
Then maybe I’ll start hunting around on the CPAN for modules or at least figure out which Perl modules Ubuntu bundles by default.
(Possible alternate title: Becoming a Better Perl Developer)
What!? I have a blog!? I guess I should say something. 
I recently worked on improving the translations workflow for Entertainer, and hopefully this work will help make Entertainer rock for i18n (which is short for internationalization in the global community because the word is very long, 18 letters long, to be exact).
In the last Entertainer release (0.2), Joshua Scotton did the trailblazing work of adding gettext support to Entertainer. Gettext is a very common method of making an application translatable. For every string that a user sees in the interface, we wrap that string with the _() method in the code. For example, we might have a line that says:
print _(“Hello”)
Entertainer developers could then run a series of commands that will tell gettext to look for the _() method and extract the contents of all method instances it finds into a file called a po template (pot file for short). We upload this pot file to Launchpad translations, which enables our translators to translate the language into their native tongue.
Launchpad lets translators work through a web interface to see a string from the code so they can provide the translation. Optionally, Launchpad will let a translator download the file that contains the mapping from the reference language to the destination language. This file is called a po file. Once the translator updates the po file, they can upload it back to update the translations in Launchpad.
Josh did a great job adding this initial support for translations, but unfortunately, the team dropped the ball on keeping them up-to-date. Since code continues to change, one can deduce that the strings that a user will see will also change over time. Some strings are deleted. Some strings have wording changes. Other strings are added. For technical reasons not worth enumerating, the developers lacked a super simple way to generate a new pot file and upload that file to launchpad to keep the translators in sync with what is happening in the trunk. Because it was non-trivial to update the pot file, our pot file was out of sync with the code for four months. Four months! On a project that is changing as rapidly as Entertainer, that is a very long time.
My recent translation work provides the simple solution that the developers needed. Now, by simply typing `make translations` in a bzr branch of Entertainer, a new pot file will be generated for a developer to upload to Launchpad. With this change, the development team will be much better equipped to provide steady updates to the translators.
If you’re interested in translating for Entertainer, jump over to our Launchpad translations and give us a hand in making Entertainer useful for whatever language you speak. It’s a great way to contribute, especially if coding is not your thing.
Yeah, yeah, we missed our milestone deadline of 9-26-08, but we’re close to getting 0.2 finished.
For those of you looking for a lot of new flashiness and cool user interface features, I’m afraid 0.2 won’t have a ton to offer. With some contributions from new developers, we have added some features like a photo slideshow capability and a quit screen.
Most of our core developers, however, have been focusing on a lot of code refactoring under the hood. In the long term this refactoring will enable us to get features done more quickly and in a testable way, so we can verify everything we code. About 95% of my work for this release probably falls into this category, so I’m afraid I can’t really boast about anything visible that I’ve done this time around. I did fix some text jaggies on some of the menus (*yawn*, boring, I know).
Before you go away sulking from the lack of new bling, take heart at some of the cool things that we have done:
I’m going to cross my fingers and hope that we release 0.2 this weekend (the 4th and 5th). Keep your eyes on this space or over at our launchpad page for official announcements. I’ll also write a post about how to install 0.2 later which will hopefully include instructions about how to install from a PPA.
Edit: These instructions are really dated and 0.1 is not supported any more. If you came here looking for information on installing Entertainer, please check Installing Entertainer 0.3 or visit Entertainer’s Launchpad site.
Only two bugs that we (the Entertainer developers) targeted for our 0.1 milestone missed the release deadline. Unfortunately, both of these missed bugs (Bug 232365 ‘provide a PPA respository for hardy’ and Bug 236271 ‘Need a simple pdf guide for new users’) have fairly big consequences for people who are trying to get Entertainer up and running for the first time.
Since the whole reason we released early was to get some good testers and users, this is a notable failing on our part. Sorry. We don’t want to leave anyone out, so here are some basic steps to get started.
1. Get all the required dependencies (these are supporting code libraries that help make Entertainer work). You can use the list at our old Google Code page. Please ask us on IRC (irc.freenode.net #entertainer) if you seem to be missing something. This problem will be rectified when we have a package that users can install (so that the dependencies will automatically be grabbed).
2. Get the release and extract the compressed file. You can use graphical tools (e.g., right click the file in Ubuntu and select Extract) or practice your command line foo (e.g., `matt@zion:~/Desktop/$ tar -xvzf entertainer-0.1.tar.gz`)
3. Point to your media with the content management tool. In a terminal window, from within the src directory of the release that you just extracted, execute `./entertainer-content-management.py`.
4. Start the backend, which will index all your selected media directories, from within the src directory by executing `./entertainer-backend.py`.
5. Start the frontend (the whole reason you went through these instructions) by executing `./entertainer-frontend.py`.
6. Report bugs on our Launchpad site (help us make Entertainer better!).
I hope these instructions will help you enjoy Entertainer.
As an Entertainer Developer, I’m very proud to get our first big release out the door! 0.1 is the culmination of a lot of hard work over the past few weeks months.
It’s quite a feat to develop and release software and the effort was only made possible by the hard work of Jamie Bennett, Michael Charclo, Paul Hummer, Joshua Scotton, Lauri Taimila, and myself, our helpful bug reporters and alpha testers, and some great development tools like launchpad, bazaar, and pylint.
Since this is my first release experience as a part of an open source, community driven team, this code will probably be special to me, warts and all. I want to thank all the guys listed above for their help in making me a better developer and answering my (sometimes foolish) questions. I think we have a good community growing here and I’m looking forward to many more releases in the future.
Download the release here.
The Entertainer developers have scheduled our first release for June 14th. As with lots of other open source projects, our .1 release is meant to be a preview release to get the software out to many users and get feedback, testing, questions, and, of course, new bug reports.
As you can see from our bugs list for milestone .1 (found here), we are getting very close to fixing all the things we committed to for this release. There will still be some big known issues (like a black blank screen for some/all 64 bit users), but we think that release early and often is good idea and will help us refine Entertainer to be an even better media center.
Keep your eyes peeled for release information from our launchpad page or from the development mailing list (entertainer-dev (at) lists (dot) ironlionsoftware (dot) com).
Entertainer is at a coding crossroads. Lauri has done a great job of showing Entertainer as a viable (and beautiful) media center software. However, a portion of this code is more like prototype code than production code (probably since Lauri is fairly new to python like myself). Eventually, this code would become a big maintenance issue. We can either continue to build upon some weak design areas or break things down and refactor into something better. We chosen the latter option.
The developers are attacking this issue on two fronts. First, Paul is overhauling the backend to use an ORM (Object-relational Mapping) that will consolidate the SQL code. This ORM will make the backend look more like an object than a database from the frontend code’s perspective. Secondly, we are using a source code analyzer on the frontend to report a gauntlet of possible problems. This analyzer is called pylint.
Pylint analyzes source code using a rules file specifically tailored to the style of the project. Entertainer is trying to adhere to PEP 8 (Python Enhancement Proposal 8 – Style Guide for Python Code) so we use a pylint rules file that attempts to follow that guideline. Pylint is very easy to use and the following is an example of how to run it:
matt@zion:~/branches/transitions-cleanup/src$ pylint —rcfile=pylintrc frontend/gui/transitions/fade_transition.py
In this example, we do three things: Call pylint, set the rules files (pylintrc), and specify the source file (fade_transition.py). I ran this command in the source directory so that pylint could find the modules that are listed in fade_transition.py. If I had run it in the transitions directory, I might have had import errors because some modules would not be seen in the python path. After running the command, pylint will report any errors, refactorings, warnings, or convention problems it can find, and it will generate a score from 0.00 to 10.00. How cool is that!? It takes so much pain out of debugging potentially unknown problems.
In my opinion, pylint has a great feature about its reporting that makes this cleanup fun: It remembers previous runs and shows side by side comparison of run metrics! I can make changes to the file, run the pylint command in another terminal and watch my checklist of problems shrink and the score go up. I continue this iterative process to get the satisfaction of standardizing a file to goals of the project.
Is pylint worth it? You bet it is. People make mistakes when coding. There are no perfect programmers. The difference I see is that smart programmers will take advantage of tools like pylint to make life simpler and code cleaner.
