(http://i.imgur.com/Q4t9W.jpg)
I swear to god, today is a good day that I don't operate heavy machinery...
I am having a rather awful Monday of everyone giving me BAD news, deadlines missed, forgot to inform me of vacation time, once again supposed "experts" telling me something two seconds of goggling can contradict... etc
Being a tech and being a manager kinda sucks, since you know when others are wrong, but you don't have enough time to do it all our self.
Ugh that really sucks.
I actually spread the fun to another team member who is trying to cache data objects because we don't want to commit them to the database until the user clicks save across several pages.
He was going to use the IDs as the keys for caching
Until I pointed out that we won't have IDs until we commit.
:-C
Well I have been given to go ahead to add a team member however the process of doing such is rather long. So the work to to it will take me away from current tasks and the current tasks all have deadlines so it sucks all around.
Ah, the mythical man-month or the idea that if one woman can have a baby in nine months then nine woman can have that baby in one month...
Maybe it's time to start managing expectations about tasks and deadlines, Lazy?
If everything is a number one priority, then listen to which one they emphasize (talk about) the most. That's the true priority. It's not what we talk about that matters, it's what we emphasize.
Mr A, that's kinda funny about the IDs not existing until you commit :) Hope you guys figure out what to use as a key for your cache. I'm guessing session id, user id, timestamp, something like that.
My day's actually the opposite, I overcame a bit of coder's block and then had a decent couple of ringette practices, and am now going back to code because I've got it all in my head and am ready to commit it to source control.
I suggested user id and have us only ever maintain one copy of the object(s) based on that key, that way when they press "new" we blow away the cached copy and start fresh.
I wanted to do things the easy way: i.e. commit the changes to the database with an "in edit" flag/mode enabled.
That way we could do the same thing but with referential integrity.
BUT NOOOOOOOOOOOOO
that's too easy, that's too... obvious!
Umm, tell your teammate to give their head a shake - your idea is perfect.
Oh wait, I know where you work. I'll probably have to decipher the data that ends up coming out of that. And I'll be told to "remove the complexity so the customer can slice and dice it any way they want".
I had some fun yesterday too. I ended up starting at 11 or so on sunday "morning", and working (mostly) through monday 3pm or so. I /really/ REALLY wanted to get these changes in for today, but it wasn't meant to be.
I'm now fighting with some annoying sqlite issues.
Quote from: Thorin on October 02, 2012, 12:19:56 AM
Umm, tell your teammate to give their head a shake - your idea is perfect.
Oh wait, I know where you work. I'll probably have to decipher the data that ends up coming out of that. And I'll be told to "remove the complexity so the customer can slice and dice it any way they want".
[suspicious]In this case it's data we won't be sending anywhere outside our app, it's actually metadata for loading assessments.[/suspicious]
But still what a headache!