K Code Parser (story 5)

Where's story 4? Well, it's coming. Probably in an episode named 'the missing story'. Who knows? :) Half the story is written in mercurial commits, the other half will be written later.

So today, about a new cool thing. Not that new, in fact, but pretty new to me.

I was always baffled by the need to iterate through collections. I always loved the idea of foreach statements, and this morning I found the 'foreach' of Java. It's 'for', and it looks like this:

 for (String s: myArrayList)
  doSomething (s);

compare this with:

 int i;
 for (i=0; i< myArrayList.size(); i++)
  doSomething (myArrayList.get(i));

While the difference might not be too big, it definitely feels big to me. Because, for example, every time you do a get(i) you might get something that's checked for bounds, maybe not O(1) complexity (if you change the data structure for myArrayList without notice) etc. And the point is that all you want to do is do something for every element of your collection. No need to extract data from an iterator (as you get data directly from the source, from a hidden iterator that probably is more optimal than anything externalized) - and it feels a lot better than the indexed code.

So I like this feature very much, thank you; I wonder, however, how readable I will find this at 3AM in the morning. I'll have to set my clock and wake myself at that hour, just to have a look at that piece of code.

K Code Parser (story 3)

Delivering code that you can't compile.

It's Java, therefore it's possible. How, you ask me? Simple. Watch this simple error:

Exception in thread "main" java.lang.Error: Unresolved compilation problem:
    The method setVar(String, int) from the type VariableStorage is not visible

Yes, this is precisely what it means. Unresolved compilation problem. This means that the code shouldn't have compiled in the first place; but heck, people can deliver it anyway.

I don't know if I should call this silly or not. I am just thinking about that corner case that happens once in a million years (let's say, when you fix your clock for the daylight savings time). What can I say, tester's hell.

K Code Parser (story 2)

So the first day passed, and it was kind of lazy. Actually, after hitting that SVN frustration I stopped doing that and started doing other things. Unrelated to the project. But this morning was a bit more productive, and I managed to implement the first part of Mr. Crenshaw's tutorial. In Java. As I said, the code can be found on the mercurial repository from Google Code.

One nice touch. Eclipse is really cool when it wants to be (it proves to be really helpful when it wants, and writes tones of stuff that I don't want to for me). Second: Java + Exceptions. I truly hate exceptions, but they seem to suit this type of implementation (that I'm trying to do). So I will roll with exception. It's a nice way to abort something, and they can be helpful too.

One thing I hate about Java. Why the heck did they name the bool 'boolean'. It's toooooooooooooooooooooooooooo daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaamn looooooooooooooong. And I always write bool. So eclipse, unhelpful in this case, doesn't try to correct me by writing stuff for me. So long with the helpfulness of Eclipse :(

Now onwards to the second page of the tutorial.

K Code Parser (story 1) (continued)

So what the heck should this error mean?

 Missing requirement: SVNKit 1.2.2 Implementation (Optional) 2.2.2.I20101203-1700 (org.polarion.eclipse.team.svn.connector.svnkit15.feature.group 2.2.2.I20101203-1700) requires 'org.eclipse.team.svn.feature.group [0.7.9.I20101001-1700,1.0.0)' but it could not be found

[Retorts taken out. Really, really upset dude at keyboard]

Mental note. For the fun of the game, add "error 0.7.9.I20101001-1700,1.0.0 detected" message in my project.

So I cannot use SVN from Eclipse. In case you were wondering if it works, it doesn't, no matter what the official docs say.

PS: I know it's a 64 bit issue. I don't care. Why should I, the user, care? It's an IDE, it doesn't work, the feature is disqualified. Now if I could only change my code.google.com source versioning to mercurial :( *sigh*

K Code Parser (story 1)

I'm gonna update the blog about the advance in my project in stories. I don't know how many stories I will have, nor will I bother to name them (unless they are tremendously interesting, like this one is not).

So first story is how difficult is to have SVN on eclipse, and make it work. It's not that I cannot find my way without Eclipse. It's that I want to learn how to use the damned thing from Eclipse - after all, it IS an Integrated Development Environment.

So we want to install some plugin for SVN. Easy. We go in Help->Install new software (always loved to do that) and we search for SVN. Wait for about 1 minute before deciding not to use the task manager to close eclipse, select first Subversive SVN connectors. Amaze yourself with the fact that it doesn't work. Try again, selecting from the window stuff that might work. Try again, again and once again. When you have a 'Next button' on the second page (no errors, then) press it. Don't think twice. Don't mind what's installing. I don't know, and you don't know. Eclipse knows. Restart Eclipse. Notice that it doesn't work. Try again. Don't succeede. Write an angry post on how it's friggin' incredible this piece of sh**.

Then relax, and try again

File->New Project

Ok, so it's that time of the year. It's 7:27 in that crazy wintery Monday morning that you know you ain't going to work. You are bored, and you feel like doing something useless.

And you remember that some time ago you have bookmarked a 300 hundred pages tutorial. It's about parsing code. And dumping assembly code. Which sounds like fun.

So five minutes later you finish writing the blog post in which you announce the URL of your new project, you're committed to writing it in Java although it's the silliest thing to do in Java and then you open your Eclipse.

So here it is, guys... http://code.google.com/p/k-code-parser/source/checkout . Don't rush, there's nothing there yet.

But there will be :)

Buzzword of the year - the cloud

Now everyone does programming for 'the cloud'. That is the ultimate place to be with your 'app' (another buzzword) - go visit the cloud. I was once lucky enough to assist to a salesman praise of the cloud. It's horrific - I love it. The cloud has magic properties - you can do anything, achieve everything, f*** up nothing. Because, well, it's the cloud.

Now let's get things straight. The cloud doesn't exist. It's a bunch of computers put together. Google does that, Microsoft does that, Amazon does that, everyone does that. No magic - a bunch of computers put together. No superpowers granted - no super-technology. This was done since a lot of time. Now it's only a bit more 'public'. Around 1940s some dudes were talking about providing 'computer power' to everyone around an entire city and, why not, the world. 1940, no clouds, only dreamers. Now cloud, yet no computing power for everyone, just bullshit. Just some means to collect your data.

And while your information runs away from you  (because, well, it's in the cloud, why should I be more than an ignorant moron when I have 'the cloud') we sit back, relax and enjoy the new buzzword. Because everyone will take some more time from themselves, and the cloud will know them better than anyone. How does that feel? a bunch of machines know you better than you know yourself? But enough cyberpunk.

Anyway, fear the salesmen that throw the cloud at you. It's not a new concept - it's merely a name for the same things that happened since a lot of time.

PS: This post is now 'in the cloud'. It was once in social media. once, it was web 2.0. Once it was HTML. Once it was AJAX. Once it was on the net. Once it was online. My blog just can't settle, you know?

Happy programmer's day!

This year, 13th of september is Programmer's Day!. Let's rejoice!

Something worth taking your time for

Since I complained for the non-Agile Agile methods, some thoughts that I feel correspond quite well with what I feel on this can be read here. Also, I want to point out this incredibly nice video I seen from that link (and btw, link was received from the unfoundable-on-the-net bolthead).

In the next episode, hopefully I'll get back to technical stuff.

The world of scribblers and slaves

I was always in opposition of software development processes, because I always felt that the processes are meant to diminish the skill of individuals creating software, adding an overhead that creates no value.

Seems, I was right. Indeed, I always preferred ad-hoc organization, direct responsibility for code and for the results of what you do. I overlooked intentionally the politics involved in software development - all the managerial chess-playing that makes the product go live and live instead of being a simple storage issue in the code repository. It might seem like a huge thing, but it's really not - it's people doing their job. The software processes were meant to make the people that usually don't get along to get along. Unfortunately, software writing people are not the ones that have a say in this, so software processes are fitting better the managerial people rather than the people actually doing the work, the software people. Ad-hoc processes usually mean that the software writing guys doing things as they know best. Established processes is software writing guys doing things the marketing way. And it doesn't work.


The current disappointment I have regarding the processes concerns SCRUM, but I'm pretty sure that it's not just SCRUM... it's all of them. All the software processes are meant to transform the programmers into working bees, working bees that produce the same quantity of honey month after month, even if it's winter time and no flowers are around. Useful, predictable slaves, that, like in the fourth grade math problems, 'dig 20 meters of trench in 2 day, therefore 100 meters in 10 days'. Everything is measured, the creativity is measured. But there's a catch.

Imagine SCRUM in poetry. People gathering around, looking at how many verses you finished today, which one will you write tomorrow, what impediments you have in writing your poetry. But you can't really calculate how much poetic spirit is in a poem, can you? So there's a solution from the managerial team. What we used to call 'self-critic' - something that reminds me so badly of the communist time - but now it's called "inspect and adapt" or, even better, "retrospective". We do it, because that gives us freedom. The freedom to continue with this world of scribblers and slaves. The scribblers accounting for how many poetry points you scored today, why your score wasn't good enough, and how can you improve. How fast can you make old ladies cry, why didn't you do it faster or in better shape.

And all this time, you'll wonder why your poetry lacks soul, biting from a tasteless tomato, in a sucky country, preparing to leave to the place of scribblers and their slaves.

C guideline: Extern declarations

One thought, as I was browsing through tons of bad code I have here at hand:

The C programming language allows you to write extern declarations quite everywhere. In the C file, in the function, even inside your 'for in for in for'. This usually tends to show the lack of structure and understanding of what should stay where. Externals, like globals, are bad code, so you might want to rethink the whole code you're working on.

If you still want to use it, probably the only place where you should be allowed to use them is in header files. Adding extern declarations in code may add unforeseeable linking problems, since the declaration of the original item might lie in a different module. Logically, the extern declaration is part of the interface of a module, thus it should lie in the header file that you include to access the module functionality.

If you want to get rid of this, you can simply add for the globals that you want to access setters and getters, depending on what you need. It would be the cleaner version anyway, and it will help you refactor things very fast and easy.

So as a guideline: don't use extern declarations in your C file. Move it in the header file or remove the need of the extern declaration altogether.

The boy scout rule

When you leave the camp, leave it a bit better than you found it . From this presentation (which I found interesting, but very annoying at times, and the beginning is simply too silly)(via Victor Hurdugaci). Which applied to code is:

Leave the code you fix a bit better than you found it. Fix one small thing or two. Rearrange some code. make it work a bit better.

I think it's an incredibly good piece of advice - bugs usually creep in badly written code - and by fixing badly written code whenever you see it you might fix a bug before it appears.

TDD stupid question

Ok, repost, too many mistakes.

I was watching a video with a guy very excited about TDD (a big mdeah from my side) - but mostly by the most inane part of it, which is 'pair programming'.

Why is that a good idea? Doesn't it sound like a "two stupid people put together might make as much as a good programmer, hopefully" thing?

Pair programming sucks big time - two people cannot write the same line of code, get the heck over it.

C# for C programmers. Episode 1: Delegates

I was browsing the net looking for cute stuff, and reached this place. And I think that for the first time I understood what the buzz word "Delegate" means.

It's a pointer to a function, only in a nicer shell.

So instead of having:
typedef void (*pFunc) (const char *param1);
We will have a much nicer:
delegate void pFunc (string param1);

A cool thing that totally justifies the update from native code to almost native (but interpreted) code.

So next time someone bothers you with cool features that should make you swarm to .NET, you can find out what (at least one) of those buzz words mean.

For the real documentation of the delegate thingie, see MSDN. (via Bolthead)

Python: my first 2 days

Let's start with what I really don't like: Invisible syntax sucks. Big time.

When your application complains about some spaces in your indentation, you know that you've done something wrong. So you load the source back in the editor, but you don't get it. It looks perfect. But it's not. This is because tabs are different from spaces, and spaces and tabs are a very very very different thing. So Python says.

There is nothing cool about this particular feature, except the enforcing of 'good looking code', and I find it very very confusing.


On the plus side, throwing together pieces of code that would simply be run is quite cool, not to mention the ease with which you get to do certain operations when compared with C/C++. On the other hand, the ease of use is actually reflected in the run times and probably beginner users like me will always make sluggish applications.

Another thing that I don't like so much is the fact that you don't have error checking on the run trails that you don't get to touch. So for example if you write a function and you have somewhere a misspelling, the error might pop up to you only in the rare case you might hit that line/trail. This is where a compilation stage becomes really really helpful, in my opinion, because quite some time is wasted on getting your code tested for the basic requirements (like not mistaking setGeometry for setgeometry).

The second part of my explorations with PyQt is the Qt4 framework(s), quite different conceptually from what I used to know from the Qt3 that I used so much some time ago. Better? Arguable, but my instincts were trained to use the Qt3 way of thinking, so I am not drawing any conclusions.

In the mean time I am really happy to say that it's pretty fun to use so far. If performance is not necessarily your goal, Python might be the language of choice.