I’ve also seen some of the completely awesome progress made with Free Software Flash players. I’ve seen both gnash and swfdec, and both of them seem rather good. We watched Tickle-Me Elmo on Fire on YouTube on Gnash, and I’ve seen Tonio_ watch some videos with swfdec. It all looks really cool and it seems like a rather high priority. We really need Free Software Flash players, so this is a really nice development.

I’ve been busy as well working on some stuff as well. The two things I’ll likely be doing for 7.10/Gutsy are some improvements to Adept (possibly looking at merging in version 2.1), and a KDE4 port of kde-systemsettings. This is all very cool stuff.

For those of you reading this from Illinois, I would just like to remind you that all of this, and more, will be discussed at manchicken’s house of hack on May 19th. Don’t forget to email ubuntu-illinois-rsvpATnotsosoftDOTnet to get the address and phone number. I hope to see you all there.

On December 9th of 2006 I went into #kubuntu-devel on freenode and told them I was bored and asked them to give me something to do. Since then I’ve submitted several patches–many of which are in feisty fawn–and had more fun than you can shake a stick at. All of you aspiring hackers and UI designers and artists, I encourage you strongly to consider contributing to this project. It’s a blast, and it has results.

For those of you who intend to go to kubuntu.org or ubuntu.org to download the latest version, you will notice that things are running a bit slowly. Please be patient as quite a few people from around the world have also eagerly anticipated this release, and are very excited about it as well.

So, it is my delight to call this first meeting of the Ubuntu Illinois LoCo team. On Saturday the 19th I invite folks to join me at my house in Champaign, IL–manchicken’s house of hack–for pizza, beer, and Ubuntu from 12:00 until 17:00.

During this meeting I would like to pass on information from the Ubuntu Developers’ Summit, and I would like to discuss how we could coordinate some local development efforts.

If you will be attending, please RSVP (ubuntu-illinois-rsvp *AT* notsosoft *DOT* net) so that I know how much pizza to pick up. If you have special dietary needs let me know and I can see if I can accommodate you within reason (sorry, but I can’t afford the caviar and champagne diet). As soon as you RSVP I will reply with the address and contact information.

This event is open to all Ubuntu users and developers. I’m a big Kubuntu guy, it’d be nice if a GNOME Ubuntu person and an Xubuntu person wanted to come and help lead some development discussions for this as well. If any other UDS attendees are interested in showing up let me know and I’d love to have you join me in presenting some of the ideas.

Anyway, my rambling aside, I hope to see you all at manchicken’s house of hack on Saturday the 19th of May at noon.

Also, if you join irc.ubuntu.com and join #ubuntu-illinois (which forwards to #ubuntu-chicago) we can discuss the possibility of a hackathon.  If you’d be interested in such a thing make sure you mention that in your RSVP.

There’s been a lot of difference of opinion on what unit testing is supposed to be. I think this is a good discussion, but I don’t think it goes anywhere near addressing this point. Therefore, I shall define what unit testing is in my words, and that is the definition that we’ll use for this explanation. Unit testing, in my view, is testing at the simplest level–or unit–of an application code. This will be at the function level, at the class/object level, at the instruction-set level, etc. The unit test is a test that cannot be made any more atomic without being redundant on a dependency’s own testing.

In this scenario…

int add_two(int a, int b) {
  fprintf(stdout,"Adding %d and %d\n",a,b);
  return (a + b);
}

int add_three(int a, int b, int c) {
  return add_two(add_two(a,b),c);
}

with unit-level testing you would create a unit test for both add_two() and add_three() individually, and not for fprintf(). (yeah, I know that is making it very obvious, but some folks may need the verbosity)

Okay, so now that we understand unit testing, the question remains… why Perl? What an excellent question! So many people know how Perl is used for web applications and also for various other programs and scripts, but one thing you may not have known is that Perl also has an outstanding set of modules that make up an awesome testing framework. Check this out:

Perl Testing Reference Card

This is a reference card put out by the Perl QA folks, and it’s been passed around a lot. I like it. Clearly there has been a lot of emphasis put on automated testing in Perl (one of the reasons why it’ll work).

Perl is portable. There is a stable and usable Perl for every operating system I’ve used, and most that I’ve heard of, and most Perl scripts seem to be mostly portable. The only time one seems to be non-portable is when the use of an external library (via XS or other means) is found.

Perl can make use of other non-Perl languages. Anybody here program anything in JavaScript? Well, there’s Test::JavaScript for your testing needs. There’s even JavaScript modules if you want to directly interact with JavaScript through SpiderMonkey. What about Java? Inline::Java will take care of those folks. Python? There are Python libraries. C? Inline::C. Ruby? Inline::Ruby. Anything win32 could make use of the Win32::API module.

Perl focuses a lot of time and energy on testing. I think we could all make use of this effort. I also think most of us (all of us if we’re being honest with ourselves) could agree that we all could use more automated tests.

Will you be able to shoot holes in my argument? Sure. Is the word “ideal” for all of those situations a bit of a stretch? You caught me. But if this gets you thinking about automated testing, and gets you thinking about Perl, then my job here is done. See you tomorrow folks, when we’ll talk about integration and functional testing.

This will be a four-part series on manchicken’s automated testing theory, using Perl. This first installment defines what automated testing should and should not be. Next we will break down into three different posts on how Perl is ideal for unit-level testing, then integration-level testing, finishing up with user-interface-level testing. As always, feel free to link, comment, complain, etc. Try to stay on topic though. Thanks.

What is automated testing?Quick rant on automated testing

Okay, so a lot of you know that I like automated testing. I just wanted to get a few things across before I start making points beyond this. Here are my stances on automated testing:

• Automated testing should be done before code is written, and updated during the whole life of the code.
• Automated testing should run quickly, and be safe to run on both development and production environments.
• Automated testing should not require human interaction beyond the preparation for a run and then firing off test run… until it is done of course.
• Automated testing does not eliminate quality assurance personnel or the job they do. It merely changes them to finding new problems and designing tests rather than spending oodles of time regression-testing.
• Automated testing should be controlled experiments. This means it should be done the same way every time. No random data patterns, no assumptions, no pulling from external databases. Fixtures help here.
• Automated testing should be at various levels: code-unit (object or function level), library functionality integration level, and user-interface level.
• Automated testing should make the developer’s life easier as well as the QA engineer’s life.
• When reading automated tests, the test plan should be obvious.
• In automated testing, hard-coding data is not a bad thing.

Price: I can currently put up $20 for this. If anybody is interested in helping fund this bounty, please contact me at manchicken (at) members.fsf.org.

Synopsis: This is a bounty for a program that will convert videos from YouTube and other popular flash video sites to a non-encrypted video codec with a Free software implementation. Check the specifications below for more information.

Specifications:

• The program must integrate seemlessly with at least one major GUI web browser distributed with a Free software license (preferably Konqueror or Firefox/IceWeasel)
• The program must be turned in licensed under the GPL version 2 or later (the or later is required)
• The program must come with a stand-alone executable as well as the browser integration, so that further integration may be possible
• The program must depend on absolutely no proprietary software
• From inside the browser, the integration layer must provide an intuitive interface that will convert a selected flash object into an AVI or other non-encrypted video with a Free software codec that is legal to install in the United States
• The program must be compatible with flash version 7 or higer (higher is better) without requiring any proprietary software
• The program must be reasonably stable, as determined by all representatives of all funding parties
• The program must be programmed in a language with that has GPLv2+ compatible runtimes and build environments
• The program would hopefully function on multiple Free software operating systems, but must function on a GNU operating system running a Linux kernel
• The stand-alone program must take two arguments: the URL and the output file

A Free software license in this specification refers to a software license recognized as a Free license by the Free Software Foundation. You may find this list by clicking here.

Terms of Acceptance:

• The program must be subjected to no fewer than 2 review processes where all interested funding parties are present or represented
• The program must be subjected to at least one comprehensive code review where all interested funding parties are present or represented
• The program must be documented to the satisfaction of the funding parties
• There is no expiration date for this bounty, but the bounty must be claimed within 60 days of the initial release of the program.
• This bounty does expire when a program implementing more than half of the functional specifications has been released for 60 days
• This bounty shall be paid in United States Dollars, and the recipient is liable taxes, etc.

To claim this bounty, email manchicken (at) members.fsf.org.

Click here to watch the video

Those machines look like they took forever to put together.

Just look how useful they are. Here’s how you can install some codecs…

Just visit http://wiki.ubuntu.com and search. I am always amazed at how simple it is to find information there.

Well, he has recorded a song about freedom in software and how it benefits hackers, and society in general. The GNU project is actually hosting a copy of this song on their site, and I thought you all might enjoy it if you hadn’t heard it yet.

Here’s the link.

So, let’s begin. The adept manager (to the right here) allows you to do a few things that I really like. Most importantly, it allows you to manage all software packages currently installed on your computer. Secondly, it lets you search and filter software–both installed and yet to be installed–in a variety of extremely useful ways. The third major thing it does is allow you to install, upgrade, reinstall and purge packages. Lastly, it lets you see some very important details about the packages you have installed and wish to install.

Let us walk through some scenarios. Okay, so you if you’re like me, you love quick games that occupy short bursts of time. So you want to find the world’s greatest quick Free Software games. So let’s just search for game programs. We accomplish this by simply typing the word “game” into the “Search” field. Adept will automagically start filtering, so there’s no further work necessary to fire off this search.

Now, I don’t know about you, but I’m not a huge GNOME fan–sorry GNOME guys, no disrespect–but I prefer KDE applications. Therefore, let us filter out the GTK and GNOME stuff. I look under “Available Tags” and see a “[gtk] GTK” tag. I’ll just drag that over to the “Tags I Do Not Want” box. Now, I do want KDE games, so I’ll drag the “[kde] KDE” tag over to the “Tags I Want” box. Your window should look something like what I’ve got to the left after that.

So right off the bat, I see a game that I know I’m going to love. kbattleship sounds like a game I used to play when I was a kid. How awesome. Let’s take a deeper look at the package by clicking on the blue arrow to the left of the package. It should expand a little bit with some details about the package. I would like to see more details though. I can accomplish this with a click of the “Details” button.

Well, this certainly is more detail, eh? With this view you can see several key details about the package. The section tells you what category or section the package is listed as. This display tells you how much disk space it will take up when installed. It also gives you a description of the package, who the maintainer(s) is(are), what the version is eligable for install, and if it is already installed, what version is currently installed. But boy oh boy, that isn’t the end to this fount-o-wisdom. If you look in the tabs below you’ll see three different groups of information: “Package Relationships,” “Installed Files,” and “Additional Information.”

In the “Package Relationships” tab you can see what packages are required, which packages are in conflict, and which packages may be relevent (there may be others, but they’re escaping me now). In the “Installed Files” tab, if the selected package is installed, you’ll see all of the files that are installed with quite a bit of detail about each file. Finally, if you look in “Additional Information,” you’ll see your list of tags again, but also the source package (the package where source is available from), the architecture, the filename in the repository, and the MD5 sum (which helps you verify the integrity of the package, and also helps if you’ve got two different versions you’re comparing to see if they’re identical, but that’s another story).

So let’s request to install the package. Click the “Request Install” button and notice that the “Requested change” field now shows “install.” Now let’s look at all of the operations that have been queued up. To get there click on the “Preview Changes” button up at the top of the main window. So now we can see the two packages that will be installed to put kbattleship on your machine. So now if you hit “Apply Changes” you will see the familiar install screens, and then it will take you back to the main display again.

Now, say you play kbattleship and you don’t like it. You may then–in the main display–remove it. Just right-click the package in question and click “Request Removal” and then click the “Apply Changes” button again to remove it.

I understand that this is a pretty light-weight tutorial on adept manager. I will get into the sources selector tomorrow. Have a good night, and thanks for reading the blog. I really hope this is helping you learn how to use one of my favorite programs.