No.

Taken from Subversion FAQ (How does Subversion handle binary files?) :

For storage and transmission purposes, Subversion uses a diffing method that works equally well on binary and text files;

From what I read, it does reverse delta on the files being commit

For a design process to produce an extraordinary product, two conditions must be met: stakeholders and participants must unequivocally accept that they aren’t designers, and trust the real designers’ abilities.

I’m using jquery’s contextmenu. There’s a code needed to be changed.

Search for (which is probably at line 141)

$(el).add('UL.contextMenu').bind('contextmenu', function() { return false; });

Replace it with

$(el).add($('UL.contextMenu')).bind('contextmenu', function() { return false; });

Reference
jQuery Contextmenu DOESN’T WORK IN JQUERY 1.4 CHROME & SAFARI

What is needed is just to set the bin directory in the windows path.

If that does not work, check this steps out, MySQL Error 1067.

Pondering is what I do when I read before going to sleep, sometimes the pondering puts me to sleep, other times it gives me the urge to write something in my notebook or do some google search and more reading on the subject matter.

Anyway, its nice to ponder.

The state of the practice in software development is pretty dismal. Some groups do a great job, but most do not. As I tell the students in my software engineering course, if you manage requirements, make sure the developers talk to each other, release working code regularly, have some sort of a systematic testing process, use build and version control tools, and periodically stop and see how you are doing and how you can improve, you will be better than 90% of the groups out there. Of course, I could be exaggerating. Maybe it is only better than 75%.

Sounds simple enough. The human factor makes it difficult.

A colleague of mine requested a function to validate the time format (10:00, etc). I quickly posted something on pastebin which looked like this.

sub valid_time{
    my ($time) = @_;

    # format kena betul. 10:00 ataupun 23:00
    if(!($time =~ m/([0-9]{2})\:([0-9]{2})/))
    {
        return 0;
    }

    my ($hour, $min) = split(/\:/, $time);
    if ($hour eq "" or $min eq "")
    {
        return 0;
    }

    if($hour > 23 or $hour < 0)
    {
        return 0;
    }

    if($min > 59 or $min < 0)
    {
        return 0;
    }

    return 1;
}

It was not as good as I expected. So I changed it a bit.

sub valid_time{
    my ($time) = @_;

    # format kena betul. 10:00 ataupun 23:00
    if(($time =~ m/([0-9]{2})\:([0-9]{2})/))
    {
        my ($hour, $min) = split(/\:/, $time);
        if (($hour eq "" or $min eq "")
            or ($hour > 24 or $hour < 0)
            or $min > 60 or $min < 0)
        {
            return 0;
        }
    }
    else
    {
        return 0;

    }

    return 1;
}

By using the Guard Clause, hopefully it is more readable.

sub valid_time{
    my ($time) = @_;

    # format kena betul. 10:00 ataupun 23:00
    if(!($time =~ m/([0-9]{2})\:([0-9]{2})/)){ return 0; }

    my ($hour, $min) = split(/\:/, $time);
    if($hour eq "" or $min eq ""){ return 0; }
    if($hour > 23 or $hour < 0){ return 0; }
    if($min > 59 or $min < 0){ return 0; }

    return 1;
}

I remembered that I read somewhere sometime ago, there should be only one exit point in a function, at first I thought it was a rule or something, apparently it is not.

One entry point is enforced by modern languages, and one exit point is really not a useful rule. Clarity is the key principle: if the method is clearer with one exit point, use one exit point; otherwise don't.

Changing jobs. Never ever, change a job in 24 hours. Especially for an unknown company whose office you have never seen. You could think that they’re being lenient and all for meeting at a restaurant for a chat (which actually is an interview), but there’s always “udang disebalik mee”.

Think for a while (in my case I didn’t), if you had an office that you’re proud of, why the hell wouldn’t you invite a potential employee to come over for an interview? This should raise a flag (+5 suspicion).

One of my other mistake is asking a developer who is a good friend of the technical manager for an opinion on the working environment. Obviously it will be biased. Should have waited for a whole month before jumping the ship to investigate further.

There’s also other bunch of mistakes that I made:

• I did not ask about the environment in detail
• I did not ask about developer level documentation
• I did not ask about version control in detail (they used it, but there’s no comments in the commits, you’d have to diff the file to see what have been done)
• I did not ask if there’s any code review being done
• I agreed on the odd working hours (there’s no amount of money that could substitute for this, ok maybe RM10,000. You’d miss a lot in socializing with friends, cats and other stuffs). Burning out by spending too much time on work is certainly not worth it
• I got sucked into a promise of a ‘family environment’ when in reality every company is govern by a market norm (no exceptions, unless you’re one of the founders of the company, then yes it is like a family)
• I was promised that the transition will be fully paid by the company from the old one when in reality their policy only allows them to pay half.

Well that certainly was depressing to think about. Always take your time to dig deeper for more understanding on the environment and work being done at the company that you’re going to.

A well thought out solution for a problem that could drive an engineer insane (or maybe just bald) trying to fix the quirks on these browsers (IE6, IE7, IE8), but is wrapped around words that doesn’t offend anyone.

Good thinking.
Google Wave in Internet Explorer

There was one time, where theres an ISO document for the development process, after it has been reviewed by the ISO department it was kept and never to be seen again (that’s what usually happens when its too formal and nobody wants anything to do with it, oh yeah, and no enforcement).

I agree that, having a clear development process is on of the aspects to deliver great software (short-term and long-term), but how?

It shouldn’t be long, one or two page of text explaining with simple yet casual language. It all depends on the environment that you’re on and incrementally improve on it.

An example from my observation,
- make changes based on the current task and project (duh)
- compare the changes that I made with the one on the server
- merge it
- overwrite it
- inform everyone involved in the project of the changes made using the developer mailing list
- at the end of the week, present what I have done to the management (heh)

If you noticed, the process is full of pitfalls. To understand why it is the way it is, you’d have to understand its context (which I wouldn’t explain it here). Even though the process is flawed, it is still good to have it clearly for everyone to see instead of passing it through word of mouth.

So, if you or anyone else go to a company and the process is still passed with word of mouth, write it down and see if it makes sense (or just pry it out of your colleague’s/boss brain, ref cartoon).