Restructuring the database

Since Sunday, I’m restructuring the database. The problem that appear Sunday is a position with a longer FEN than what the database could accept. About a year and half, and I analyzed the database to look at the longer FEN, it was 57 characters long. In a goal to reduce the size of the database, I reduce the length of the column to 60 characters long. Sunday, a position with a FEN of 61 characters long appear, causing a lot problems.

Right now I’m changing the length of the column, and but it takes much longer time than what I thought. Neca had prove me that even in the suicide variant it’s possible to reach the longest length for a FEN (71 characters).

The process will produce a bigger database, and I wonder if the current hard drive will be big enough. If not I will buy a new one. Currently it’s a 500 Gb.

I hope to solve the issue as soon as possible, don’t be afraid to ask for news by email or chat or twitter.

*I’m not counting the color in the FEN length, it’s keep in a separate column in the database.

Happy new year!

Happy new year all!

I’ll like to take this time, to thanks all of us, who helps me a lot with this project. Many things, features, ideas came from you to make this project a better one.

And hopefully, to make you a better player.

How Unit test have been useful for me

In college, I learn nothing about Unit test. JUnit was just a strange IDE feature for me. Few years later, I started read about it. My first thought about unit test was that will be usefulness for me, since I was working only on a personal project, not in enterprise. I didn’t want to add complexity and developing time to my project.

Last year, while optimizing some part of my code, I did a little mistake : I forgot a single ‘!’. Oops. This new bug wasn’t a big one, but occur a spare time. It took me a day of debugging to finally find it.

A day lost just by a single mistake…

The day after, I decided to start learning about Unit test. I chose to use TestNG over JUnit, simply because it seem to be easier to use. I’m not a expert about this so I let other blogs to debate about it.

In conjuncture with unit test, I start to use a code coverage plug-in, the Eclemma. The purpose is to know what part of my code is covered by unit test. Now I know some advantage of TDD, but since my project way before I learn all this , only some part of my code is covered. I’m still working to increase the coverage each time I code. Before refactoring any part of my code, now I prefer to add some unit test. This way it reduce my chance to introduce new bug. It’s just a safety net, not a bullet-proof , I still need to concentrate.

Unit testing and code coverage, is probably more useful in a team project, to be sure that you didn’t broke anything of others developers. I believe that in a open-source project is a good idea, to give people a safety net if they want to modify the code.

Another important point about unit testing, is that it most be run every time at some code is added or modify. If not, when you’ll run it, I find that you broke something, it’ll be hard to find where you had added a bug. There’s several way to do it: by hand or with a continuous integration server. The main advantage of doing it by hand is that you don’t need to setup a continuous integration server, so it could be a good way for a solo developer. With a continuous integration server, unit test can be done automatically, so you don’t need to remember to run these unit tests but you need to setup the server. When a developers team grow, a continuous integration server, is the best way, since you can’t be sure that all developers have run these tests.

I still don’t know what is the best way to do it, but at least it work for me. On the long run, unit test take a little more time at start, but you will save a lot of time later.
Some people claim that you need a 100% code coverage, some don’t. Like any flamewar, read about it, and find what is the best for you and your project.

For any new developer who want to learn some new skill, I suggest to read this blog post. I discover this recently, I wish to found it way before, like when I was in college.

Monthly backup

Today, it’s the backup day.

Each 1st of the month, I start a backup of the project. It’s kind long, but it’s necessary. The first thing I do, it’s dump the database. After that I compress it, and sending via Internet to a off-site storage.
During this period, any request to the database can be a bit slower than usual. A lot of CPU are use by the backup process.

I’ll check today to be sure that everything will stay up and running.

Java or: How I learned to stop worrying and love the code

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-Martin Fowler

In college I learn Java, I like the idea of « code once , run everywhere ». After college when I start to program in Java some personal project, I knew that my code was awful / smelly. Bad design, not optimize, near zero comments, and with a lot of duplicate code. My first thought was who care, nobody else will see my code. One big problem, my code base start to grow larger and larger, so a lot of time, I screw up my own productivity because bad design.

I started to look online to learn good practice, started to code in respect Sun Java convention (about indentation, method/class naming, etc). I did a lot of refactoring, creating new class, to improving general quality of my code. But at that time I was not yet fully proud of my code. In some open-source API ( like Trident and ICTK), the code is very clear, it wasn’t always the case in my code.

Nobody can write a « perfect » code, but all programmers can at least try to write better code. In enterprise environment, a good way to increase code quality can be done with code review session and with pair programming. In a solo programming environment like I do for SuicideChess project is quite more difficult.

How to increase code quality in a solo project?

Here, few idea:
First, release your code as open-source, even if nobody look at your code, knowing that people can do it, you’ll try write better code.

Second, be sure that your code contain any error or warning message.

Third, find some tools to help you. I’m using Eclipse to develop all java code of SuicideChess. With Eclipse ( and probably most of IDE ), you can add plug-in. Some plug-in can give you a direct feedback on your code quality. Just to name few that I use : FindBug , Eclipse Metric and UCDetector.

Fourth, read a lot about it. There’s many website about best-practice , design, etc.

To push this even farther, I will release soon, a web-page to see the progress, on monthly base. Why may you ask? Because when you solo-program, sometimes it’s hard to motivate itself, so by publishing these kind of info, I’ll be able to see progress over time.

In computer science, you can always learn new things, and there’s always some limit to break. So let’s go push farther !
When I start the opening book , my first goal was to create a good opening book for nessegrev. I was dreaming about the day that the opening book will reach the size of the nilatac’s one. Now I look at it, and I said : » wow in February, the opening book will be 10 time bigger than nilatac’s one ».

Few month ago, I read a good article : Party of one: Surviving the solo open source project. This article was the reason I started this blog.

when I started to code SuicideChess project, I didn’t have a lot of experience, so I code a lot before think about design. Adding new features was fun, so at the time, I was push debugging time to later. Humm.. a very bad idea. That’s why recently (since about 2 month) I start to refactoring my code, debug, rename Methods/Class, etc. With all those refactoring, the number of line of code (LOC) start to drop. This can seem stranger for new programmer, but senior programmer know this: Less LOC = less bug. To quote Richard Pattis:
« When debugging, novices insert corrective code; experts remove defective code. »

That explain why you see less new features recently, even I still work a lot on this project. I know that I still have a lot to do, but working with a better code will make my life easier

I’m not a java expert, at least I don’t think so, when I compare myself to others Java Blogger like ( Kirillcool and Jonathan Giles). I wish I could blog like them, but I know that new programmer still need a lot, because in school, they never learn know about code quality, debug, etc.
Telling them my experience, I hope that they’ll learn something.

I most tell that one of the hardest part of solo-programming a project is to have enough motivation. Just a quick look on Sourceforge or on Kenai, you’ll see a lot of abandoned (dead) project. That’s kind of sad, because many of them are great idea. There’s many things that will de-motivated any solo-programmer: Lack of user feedback, debugging to do, lack of time, and a lot of learning to do. If you can manage those facts, and still able to continue your project: good and go ahead!

Programming is a art, maybe a technical art, but you must like your code! My code isn’t perfect but I love it

What happen in 2009

The end of the year arrive, so it’s time to look what happen in 2009 about the suicide variant and in SuicideChess project.

When 2009 started, Azor was still in version 10, and now it’s the version 16.8 that’s currently running. Many things have improved between these versions : en-passant rule, auto-update, speed increase, better connexion’s stability and EGTB capacities. I’m impress how much azor improve this year.

About the website, end game section have appear, to help players with suicide end game. That’s not the only section being created, the blog and forum too! In the opening book section, it’s now possible to add comments about a position. And since few, it’s now possible to register / login on the website.

About the opening book, it increase a lot this year. At the start of the year, there was about 8.5 millions calculated positions in the database; at the end of the year, it will be about 37.5 millions. So 29 millions positions have been compute this year. Thanks to everyone who ran/run an azor. To give you a idea, to compute 29 millions positions on some cloud computing program like Amazon EC2, that would cost me more about 6000$.

At the begin of the year, I have complete the transfer the hosting of the website from my home computer on a real web server, host by SliceHost.

All my Java source code for my project have been release open-source this year too.

About Suicide variant in general, you have seen new computers accounts on FICS like nakshatra. And StayAlive have now a way better opening book, than before, he almost reach the 2600+ rating in suicide. The Cyanide Sandwiches tourney have been moved from Tuesday to Wednesday.

This is what I remember so far… oh what a year ! 🙂
Hoping to see what will happen in 2010.

Happy New Year all!