Unit Integration

For this phase we work on profile persistence (storing profile attributes to disk) and web connectivity (transfering the profile .plist to the website via ftp).

Feature freeze is end of day wednessday.

Here's what bugs me. Engineer 1.  was supposed to get the property list in order (persistence), and has since posted 3 broken commits in which the system crashes every time it tries to save to file.
This is because he didn't actually add the .plist to the repository, so naturally it can't save anything.
Instead of fixing the problem, we have spent the last 2 days arguing about whether it exists.

I just don't understand this mentality. What's to argue about? the file is not in the project tree, and it's not anywhere on disk. done deal, it doesn't exist, and it doesn't get created. Accept it and figure out why.

Maybe he's trying to write to a location he has no permission to write to? maybe he's expecting a directory that isn't there to be there?

who knows.. one thing for sure, you're not going to fix it if you don't acknowledge there's a problem.

Why do I have to waste 2 days in which i could have been adding features and integrating my own changes. just download your own damn commit and figure it out yourself the moment someone raises a complaint. What a stupid attitude.

the sad thing is i had already designed a working persistence scheme, and the only reason i'm not using it is because he announced on monday that his version "works perfectly".

that and the fact that if i completely take over the design stage the other members would be discouraged to contibute, and i can't do everything myself.

As is typically the case in this group, personal ego takes precendence over the project.

I still don't understand how is it that 4th/5th year engineers don't know about static function and when to use them, the evils of magic numbers and hardcoding, and not only do i have to teach them, i have to swim upstream while doing it because both these morons have actually worked in the industry, so who am i to teach them.

It's not saying much for SFU engineering, or the company that hired them.

If you hard-code a save path in different functions in your code, instead of using a savePath variable or getting it from a property file, e.g.

void functionA {
   doSomething("/folder1/folder2/file.ext");
}

void functionB  {
   doSomethingElse("/folder1/folder2/file.ext");
}

you'll be having lots of fun later changing all the path strings if you have to change the path.
if you then port the app from the simulator to the iphone device, chances are the save path will change, especially if you used a ~ to refer to the home directory that i don't think exists on the iphone.
in a 2000 lines project it's annoying, in a real world 50,000 lines project it's a good reason to have you fired, unles you can explain to your boss why all your programmers are hunting easter eggs instead of working on new features.

i thought this was basic, but i guess it isn't.
something to think about.