Febuntoo News Generator

I’ve been working on this project for a little while now, as it required a little more work. This time I created a set of icons for an upcoming program called Magic Book Reader. This piece of software is a “GTK+ cross platform application for reading FictionBook e-books”, released under the GPL.

I created a total of 12 icons, which you can see here:

If there is anybody is interested in these or other (including new) icons for their project, website or themselves, please contact me.

Filed under: Tango, Uncategorized

Después de mucho probar creo haber encontrado la aplicación para media center en Fedora, que más se amolda a mis necesidades. XBMC. Para instalar XBMC en Fedora 12, es necesario añadir un repositorio, para esto ejecutamos:

cd /etc/yum.repos.d/

su -c 'wget -c http://hansvon.homelinux.org/hansvon.repo'

Ahora solo tenemos que instalarlo como cualquier aplicación:

su -c 'yum install XBMC'

Listo, ya podemos ejecutarlo desde “Aplicaciones->Sonido y Video->XBMC Media Center”

Aquí les dejo unas capturas de XBMC corriendo en mi laptop:

I came across this remarkable article and photograph in todays online edition of the TheAustralian.

http://www.theaustralian.com.au/news/nation/joy-as-computer-power-comes-to-yirrkala/story-e6frg6nf-1225848236378

It appears OLPC Australia has been successful in persuading Telstra, News Corp and the Commonwealth Bank to support a mass deployment of the OLPC laptops in remote Australia. Apparently up to 400,000 of them!

Australians are normally very cynical about big corporations and especially Telstra, News Corp so the achievement of OLPC Australia is a wonderful triumph of vision.

A big congratulations to everyone concerned for this! From a personal point of view I'm especially pleased to have made a contribution to the software inside these :-)

Every day I walk the dog a couple of miles to get her and me some fresh air and exercise.. it is usually the same route, meeting the same people, etc etc.. so I come up with things to keep my head busy. Sometimes its remembering as many elements and their isotopes, other times working out factors of numbers. Last week I started on the series (n^2+1) to see what their factors were. The first thing I realized was that while half of the numbers would be divisible by 2, around 40% would be divisible by 5 (because any number ending in 2,3,7,8 would square to a number that adding 1 would make it divisible by 5 (eg 13^2+1 = 169+1 = 170). Then after a lot of ticking off things I also realized that none of the numbers I could do (which isn't a lot .. I do this because math and me have a long bad history) were not divisible by 3.

Coming home I whipped up a python scriplet that basically did that for the first million digits and found that none of them were divisible by 3 (they weren't divisible by 7 either but I figured I would stick with 3 first). Now we know that n^2 is sometimes divisible by 3 (9, 36, 81 all being examples) and we know that a series that is always divisible by 3 is 3m (two series never divisible by three are 3m+1 and 3m+2). So from this I infer that the series n^2+1 only falls inside of the series 3m+1 and 3m+2 and never on 3m... and n^2 falls on 3m or 3m+1 (since if it fell on 3m+2 then n^2+1 would push those values to 3m). Ok but why?

Looking over the series I came up with the following:

n            1   2   3   4   5   6   7   8   9  10
n^2          1   4   9  16  25  36  49  64  81 100
m{3m+1/3m}   0   1   3   5   8  12  16  21  27  33
diff between m  1   2   2   3   4   4   5   6   6

Ok now I just have more silly numbers and probably a wild goose chase but it is interesting that the series of 3m/3m+1 growth grows in a regular pattern. Anyway, just an odd thing non-fedora related (i hope).

Managing Software Projects - A Software Engineers Perspective.
Contrary to popular belief, many aspects of a software project could be proactively controlled and managed by an ordinary software engineer to make his/her life easier. Instead of whining about frequent requirement changes, looming deadlines ..etc, there are many things you can do to help yourself retire with enough hair left. The “Managing Software Projects” series is an attempt at exploring these aspects.

Be In A Position Of Strength When Changes Occur (By Maintaining Code In A Ready-To-Ship State).
Rarely does anything in life work according to plan and software projects are no exception. Simply put, changes are bound to happen and how you deal with them will determine how successful the project is. Most of these changes will be involuntary and unexpected and the programmers and testers are usually at the receiving end. With deadlines whizzing past you the pressure mounts and the vicious cycle continues. This is where a solid foundation is useful as explained here. If you have a solid foundation, then it becomes less of a burden to maintain code in a ready-to-ship state at all times. Without that you may not have the ability to respond to changes in a timely manner. Lets look at a few scenarios.

• Sudden requests for demos or alpha/beta builds by influential customers. If you have a continuous build system and you keep your builds reasonably green, then you could literally provide the last successful build. If not you would need to drop everything you are doing and try to figure out a way to get a stable build. If you have many test failures, you will probably need to fix them first as well.
• A team member resigns, or falls ill. Unless the project culture had insisted in tested, reviewed and documented code right from the get go, the person who have to take over will need to spend a significant amount of time in getting it going.
• And our favourite, the customer and/or marketing folks change their mind for the umpteenth time. Again if you have ready-to-ship code backed by an armada of tests (unit, integration, performance, interoprability ..etc) then you are in much better position to make the required changes with confidence. The tests will provide you instant feedback about the impact. The most important thing is to be able to give an accurate picture of the impact of such a change. If you have evidence to backup your claims then managers, marketing folks and the customer are more likely to listen to you

Have A Well Defined Process To Manage Change (No, I am not talking about the process that your organization already has)
Most organizations have a formal process for handling RFE’s and bug fixes etc. (There are also organizations that are completely at sea when it comes to this). Irrespective of whether there is such a process or not at the organizational level, the engineering team should have it’s own. Some points to consider from an engineering perspective (as alluded to in my previous post).

• If your organization doesn’t have a proper process already in place or does not follow the process, then the first thing to do is to work on getting that done. It’s sad to see that some organizations doesn’t have such a process, while others did have a process but was frequently ignored for short term convenience. The consequences were disastrous, especially for the poor engineering team, and not to mention that the ability to respond effectively decreases dramatically over time. How such a process should look like and what’s involved is a separate discussion that I hope to tackle later on.
• Branching policies for handling releases, hotfixes (these are notorious for making your life dreadful). In my humble experience, having this discussion right at the beginning (and on an ongoing basis) vs later in the project cycle (especially when everybody is under the gun) is whole lot more productive.
• Handling RFE’s/critical bug fixes for existing releases. - same as above. Do it when your head is relatively free.
• Figuring out how to evaluate change requests & who is responsible for what area to make that call While the team leader/manager is ultimately responsible for making a call, they are always not in a good position to make a good decision without input from others. Therefore it want hurt to have folks informally appointed (known within and outside the team) as subject experts in certain areas. Radical changes to the code base, taking on new functionality that directly/indirectly affects a particular area should not be decided without the input from these area experts. All though Apache Qpid is an open source project, most committers will discuss with the area expert (on the dev-list/JIRA) if the commit falls outside the committers core area of expertise. Not only it’s courteous and reduces friction/disagreements it also ensures things are done correct the first time which minimizes the impact it has on schedule etc..

Deal With RFE’s/Requirement Changes Methodically (instead of being emotional and kicking up a storm).
No matter how swamped your team is and/or how ridiculous the request/requirement is, emotional outbursts or rejecting them with “not enough time” ..etc is not going to help.
It’s in your best interest (and the interest of the customer) to listen, understand, analyse the impact and then compile your response backed with evidence.

• If you make an effort to listen & understand the change request,
  • You may find the real underlying requirement is something else. Which maybe easier to implement after all.
  • Provide an acceptable alternative
  • Provide an acceptable workaround until you fix it properly in the next release.
• If you provide a proper response backed by evidence
  • First of all people are likely to listen to you as you are presenting facts backed by evidence and not mere conjeture .
  • It helps people to understand the impact and the consequences (Ex half the functionality will not work and would need n extra days).
  • Even if your opinion is ignored and the change is forced upon, atleast for your own/teams benefit you know how much of an impact you have to deal with.

Your Credibility Is Important.
This could go a long way in ensuring your opinion is heard, hence being able to negotiate changes successfully!

• If you have provided sound judgement in the past, the managers are likely to listen to your opinion.
• If you have built credibility with the customers, then they are likely to listen to your opinion, accept your workaround or alternative solution.

Ability To Improvise
Sometimes it takes a bit of improvisation to deal with the changes and still beat the clock. Instead of complaining and whining about the changes, use them as an opportunity to show your worth.
And here are some stories..

• Once we had to deal with a customer who asked for frequent GUI changes on an application that ran in an embedded device. Suffice to say it was a real pain. At the time one of my colleagues was toying with the idea of expressing the screens in XML. We promptly adopted it and taught the customer how to customize the screens to their hearts content. My colleague eventually went on to lead the team.
• We needed an automated build system to run our test suites in different OS’s and aggregate results. As the project progressed the permutations grew. We looked around and didn’t find anything that fit our needs. Then a colleague of ours used our own product to create a distributed automated-build-system.
• While working on an application that ran on an embedded device (same as item 1), the QA team had a tough time testing due to the restricted nature of the embedded device. The long test cycle ate into our dev cycle and impacted our turnaround time. I finally wrote a simulation program during my free time that simplified a lot of the testing. I scored some brownie points there, which came handy during the next performance review

In summary, a software engineering team can do a lot to mitigate the risks posed by changes that happen throughout the project. How well you negotiate those changes will have a huge impact on the final outcome.