I was moving the location of the mysql databases on my Ubuntu EC2 instance to an EBS volume. I had a little trouble. Small problem, but eventually found the solution. Did the normal things:

1. Shutdown mysql
2. copied the data files
3. Double checked and fixed as needed the permissions
4. edited the my.cnf to point at the new data location
5. edited the apparmour mysql cnf
6. (the part I forgot) restart apparmour
7. then start up mysql server

I had edited all the proper files. Poured over the permissions. Read the syslog a million times wondering why mysql couldn’t write the file. Finally restarted the apparmour service and voila! Mysql started up without a hitch.

Updated hellaphone. Finally fixed the download button bug. Also a few styling improvements.

The new hellaphone at github can now monitor the queue and updates the progress. More to come soon.

What’s on the immediate horizon:

• Look and feel updates
• Slimming down the code for less to download
• Ability to reorder, pause, and delete from the queue

New release of hellaphone. I scrapped the old code, got rid of cakephp, rolled a lighter, custom framework. Got rid of the installation troublesome mod_rewrite dependancy that cakephp required. I may even end up with a super light MVC after it’s all done. Grab a copy at Github here.

I was getting a new install of hellanzb up and running and noticed that it wouldn’t download the nzb’s from newzbin. I found that the problem was an old uri path in the python scripts. My file was located at /usr/share/python-support/hellanzb/Hellanzb/NewzbinDownloader.py.

Right after the class definition “url” is defined. Just search for v3.newzbin.com/dnzb. Change http://v3.newzbin.com/dnzb to http://v3.newzbin.com/api/dnzb and save. 

I hope this helps out others until hellanzb gets a fix up. I haven’t checked, but this may already be in HEAD.

Can a coder have too high of standards?

I overheard someone say they dislike someone with too high of coding standards. As if this is a major problem!

The reasoning behind this thought process was this: They usually aren’t pragmatic enough to be goal oriented to meet deadlines and are more concerned with technology.

I say, “Bullshit”! These are not mutually exclusive.

• Well written code can help meet deadlines.
• Code that is easier to read always takes less time to add features to.
• Code that is well designed saves time modifying and/or adding features
• Fixing bugs is always easier in well designed code

I’ll concede that the first time something is developed, writing it to be modular and not one off takes a good programmer a little longer. The second time around though that time is made up and then some. Of course this is not an issue if you never have any changes, scope creep, or a boss/client that knows exactly what he wants and specs it out perfectly the first time.

I’ve been in many projects that are rushed and shortcuts were taken. The code is unbearable by all but the original coder. Even he takes awhile to get things done. Not that it’s ever my job, but I always spend the time rewriting reusable, elegant code then documenting it. I always spend more time than I would have if I had just patched it, but I save time for me next time and anyone who must maintain it.

Sometimes the rewriting is pieces at a time. This means making everything backward compatible with what is currently written and being used at the time of being written. As I replace parts of the code, I go back and remove the code that was made backward compatible for the pieces being replaced. Eventually the old unmaintainable code is replaced by lean, easy to read, documented code.

Gotta love this.

Don’t like the php namespace? Here is your solution, especially those of you who don’t have a backslash easily accessible.

Almost as soon as I announce that I was going to stop working on Hellaphone, I start using newsgroups again and start on the project. Partly because I keep getting emailed how to set it up. I didn’t spend any time creating an installer when I released it. In fact I hacked it up real quick to be a single user system.

I always planned on releasing it as a service, but became dis-interested and open sourced it. So now I’m concentrating on bringing the service up again. The project is still open and located at http://code.google.com/p/hellaphone . Check it out, contribute, or just use it.

(Update) There is a newer git repository at http://github.com/buck2769/hellaphone/. This is being actively developed.

Most clients and employers only think about 1-2 days ahead of the project. They want it done now.

“Take shortcuts”, “Fix it later” seem to be their war cry. They fail to remember that they change their minds at least 10 times during the development process. Those shortcuts they made us take, the ones they insisted we take to save a half a days work, they just added 2 – 3 days work of going through dirty code that wasn’t cleaned up or refactored. Let’s go ahead and multiply the time it adds if another developer must be the one to work on it.

Is this the Client’s fault? Partially. We should take some blame here too. We should have an answer or rebuttal why they should not take these shortcuts. We need to be able to convincingly give an argument that supports proper code architecture and design. Why taking the time to create something right is beneficial in the long run.

This is easier said than done. A lot of programmers just aren’t confrontational people, especially with their boss. A lot of bosses are. The boss generally mows them down with phrases like, “it needs to be done yesterday”, and, “We’re losing money by not having this right now”. Unknowingly, they probably put the project behind by not having a plan and enforcing a rush from step to step in the project.

Should you stand up for yourself?

I say, “Absolutely!”. If the man (or woman) in charge is any kind of reasonable, then they will respect your opinions. After all, this is what they hired and continue to pay you for. You will have to sell the reason why you do something, especially when at first glance it seems to take longer than rushing through the project. If you don’t and the project takes too long from you caving in to the pressure of your client, they will only blame you. You will not have any excuses, because theirs will be, “I thought you knew what you were doing”, or, “Why didn’t you tell me that was the wrong way”.

How to avoid being misinterpreted and being looked at like a person who just thrives on arguments.

I don’t know if I can be much help here. I’m always being misinterpreted as I shoot from the hip, rather crudely sometimes. In my old age I’m starting to be a little more manipulative considerate and helping others understand me better. I’m starting to reflect more on what I can do to ultimately get the job done. This means being able to identify the feature and benefits of proper development procedures. Identify how it will either make life easier or make the person more money. This can be by cutting future development costs (future can be within the same project when the client changes his mind) or by creating a better product due to the extra time you’ll have not sorting through the undocumented spaghetti code you wrote just 3 weeks ago.

Unfortunately, sometimes standing up for yourself or telling the client no will ultimately lead to a dismissal of your services. Whether it be an employer or a client, these things can happen. You need to decide what your limit is, and whether it’s for the best. I’ve always felt that most clients must be saved from their ignorance.

HellaNZB.com linked me up on their home page and I’ve started to receive a lot of interest in HellaPhone. I’ve decided to make some time to further complete HellaPhone and add functionality that I wanted. Since I created HellaPhone a few things have changed. The most important one is the introduction of iui. This will help greatly in bringing some interface improvements that I wanted to do the first time around.

I plan on adding live monitoring for the downloads and queues of HellaNZB. That is my primary goal. At some point in the future I would like to be able to support all mobile devices, but I don’t have the time nor the equipment to test with at the moment.

If anyone has any suggestions or features they would like to see, please drop me a line and let me know.