Working lad, day three.
Sep. 7th, 2011 07:02 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jangSo I signed the contract of engagement (I'm not employed by them, with all that entails) with the University. The work's nothing like what I was doing (infrastructure architect / devops / geek without portfolio) and is actually letting me flex my coding muscles.
Today was much more about some planning (a bit of up-front stuff is good, I think), sorting out some vocabulary for the problem we're dealing with, and so on.
More Django
I also spent a bit of time asking questions on #django; hopefully, interesting ones. Persisting an object graph that uses inheritance back into a database in a way that maintains integrity, that kind of thing. I was told (it may have been a tongue-in-cheek pejorative phrase) "you sound like a Java programmer." The O in Django's ORM is very light, they went on to say, and the R is very heavy. Don't think about objects, just do it the easy way - think about the relational tables you'd use to solve your problem.
Aaaaaagh.
The easy way is to think about the rich structure of the problem domain! If I was doing this in anything else, I wouldn't be using an RDBMS (at least, not like this) in the first place; the fit isn't great. I have read, several times, that Django's less about reflecting an existing schema into objects and more about: here's my object model (entity model, perhaps), just let me persist it into an RDBMS. Apparently you sound like a Java programmer if your problem is marginally more sophisticated than, "first you create your concrete Blog table, then you create your concrete Entry table, then you create your concrete Comment table, then you're done."
I may, also, malign in a slightly tongue-in-cheek fashion. My heart (re-)sank when the advice was "don't try to use inheritance; that way lies a world of hurt." Really?? Anyone spare a nickel for a real ORM?
However, on the whole the denizens of the channel are relatively friendly and can answer questions with at least a pointer or two to a package that does the business (or persuades me that the six lines we stubbed out to solve a problem are already sufficient). There was more of a meeting of minds on the thorny issue of managing i18n/l10n for user-supplied content: break out to a stringtable, or store a complex subtype of TextField that does the right thing?
There's no one right answer, but it seems that an approach might be to subclass TextField and provide switchable behaviour to perform one or the other function. That lets us hide our implementation behind a cosy abstraction and worry about the performance tradeoffs later. Just like a Java programmer might, I guess.
My code might not be hugely pythonic (I interCap method names) but it seems to do the job, and it's less hairy to read.
The bashing-out-code part of the day
We took the existing system's metadata definitions and slapped a first pass into some Django models. I think tomorrow will be writing migration scripts for those; these scripts'll get more sophisticated as we carry on with the problem. Plus, this'll mean we have some concrete data so that Kieren, my colleague, can start bashing away at various views whilst I carry on sorting out some of the thornier backend & API issues.
Being serviced
My account got turned back on. There was some dithering over this because, lacking any kind of sophisticated account management, they had no idea what it might actually have the rights to. Like I'd have the time or inclination to go poking around anyway; the longer people don't realise I'm here the longer it'll be before I have to say "I'm not being employed to do that." Which, thankfully, I have not had to do at all thus far.
It only happened today because I phoned the help desk to ask; recognised Neil's voice and got him to punt the ticket I'd raised in the right direction. Apparently there's a bit of a backlog problem due to a combination of absence and the fact that this is the first time we've tried to shove everything through a single service desk; they're struggling to cope at the moment. The nice thing is that tickets sit there turning red until people hire more staff; it's a lovely feedback system.
I also nearly accidentally got given a master key by someone who was new, but trying to be helpful. I applaud helpfulness; but it goes to show, really, that if I did want to cause trouble, I wouldn't need a working account to do it.
Saw the hot IT support girl in Pret; bought her a coffee. She took me out to lunch again. I think she likes me.
Today was much more about some planning (a bit of up-front stuff is good, I think), sorting out some vocabulary for the problem we're dealing with, and so on.
More Django
I also spent a bit of time asking questions on #django; hopefully, interesting ones. Persisting an object graph that uses inheritance back into a database in a way that maintains integrity, that kind of thing. I was told (it may have been a tongue-in-cheek pejorative phrase) "you sound like a Java programmer." The O in Django's ORM is very light, they went on to say, and the R is very heavy. Don't think about objects, just do it the easy way - think about the relational tables you'd use to solve your problem.
Aaaaaagh.
The easy way is to think about the rich structure of the problem domain! If I was doing this in anything else, I wouldn't be using an RDBMS (at least, not like this) in the first place; the fit isn't great. I have read, several times, that Django's less about reflecting an existing schema into objects and more about: here's my object model (entity model, perhaps), just let me persist it into an RDBMS. Apparently you sound like a Java programmer if your problem is marginally more sophisticated than, "first you create your concrete Blog table, then you create your concrete Entry table, then you create your concrete Comment table, then you're done."
I may, also, malign in a slightly tongue-in-cheek fashion. My heart (re-)sank when the advice was "don't try to use inheritance; that way lies a world of hurt." Really?? Anyone spare a nickel for a real ORM?
However, on the whole the denizens of the channel are relatively friendly and can answer questions with at least a pointer or two to a package that does the business (or persuades me that the six lines we stubbed out to solve a problem are already sufficient). There was more of a meeting of minds on the thorny issue of managing i18n/l10n for user-supplied content: break out to a stringtable, or store a complex subtype of TextField that does the right thing?
There's no one right answer, but it seems that an approach might be to subclass TextField and provide switchable behaviour to perform one or the other function. That lets us hide our implementation behind a cosy abstraction and worry about the performance tradeoffs later. Just like a Java programmer might, I guess.
My code might not be hugely pythonic (I interCap method names) but it seems to do the job, and it's less hairy to read.
The bashing-out-code part of the day
We took the existing system's metadata definitions and slapped a first pass into some Django models. I think tomorrow will be writing migration scripts for those; these scripts'll get more sophisticated as we carry on with the problem. Plus, this'll mean we have some concrete data so that Kieren, my colleague, can start bashing away at various views whilst I carry on sorting out some of the thornier backend & API issues.
Being serviced
My account got turned back on. There was some dithering over this because, lacking any kind of sophisticated account management, they had no idea what it might actually have the rights to. Like I'd have the time or inclination to go poking around anyway; the longer people don't realise I'm here the longer it'll be before I have to say "I'm not being employed to do that." Which, thankfully, I have not had to do at all thus far.
It only happened today because I phoned the help desk to ask; recognised Neil's voice and got him to punt the ticket I'd raised in the right direction. Apparently there's a bit of a backlog problem due to a combination of absence and the fact that this is the first time we've tried to shove everything through a single service desk; they're struggling to cope at the moment. The nice thing is that tickets sit there turning red until people hire more staff; it's a lovely feedback system.
I also nearly accidentally got given a master key by someone who was new, but trying to be helpful. I applaud helpfulness; but it goes to show, really, that if I did want to cause trouble, I wouldn't need a working account to do it.
Saw the hot IT support girl in Pret; bought her a coffee. She took me out to lunch again. I think she likes me.
