Isn't it ironic? No, it's ironing. Ah yes. I have often found that my work life and home life can follow similar patterns. For instance, if I clear my desk at work, I'll come home and clear my desk at home. Given that, on Monday night, I destroyed the last nice desk I owned (from my Newcastle house), I'm feeling a bit tender on the whole desk subject, so let's drop that one for a moment.
Today had a much closer home/work connection, since I ditched the office at 11am and, after an early lunch in which I bought a casual blazer, came home to do a day's work. In fact, for some reason, I did more than just the working day's work. I kept going until much later than planned. I got into it.
A reshuffle of the evening's activities ended up occurring to cancel the painting and dig deeply into the laundry pile to discover all those garments I thought I'd lost, and which turned out to be simply hibernating in the big basket I'd wondered what I'd put in.
I ironed for a long time. In the end, I took on some ironing tasks I never take on. I ploughed through some bed linen. This is nice bed linen, which I've only recently bought, so why not make it look nice - it will, hopefully, go on the bed very well next time. But it was unnecessary. But it was a nice-to-have.
Perhaps nice-to-haves are best described by the term unnecessary ironing. You can see why a nice-to-have is nice-to-have. That's how it got its name, but is it absolutely essential? Is it worth the time?
It occurs to me, as I weigh up what I made on my computer today, that the end result was ok, but not much more than just that. Ok. I made something that I didn't think I could get anywhere else, and which I reckoned would save a bunch of time to have. Thing is, there's a reason why people haven't made it, and there's also a question in my mind over whether we'll ever "earn back" the time I've theoretically saved by making this thing.
From my position right now, I can see how the method I was going to use for another thing, which seemed to justify the "need" for this particular tool, might be better off changed to something else, which I know doesn't need it at all.
D'oh!
Still, I got to flex my muscles as a programmer and I like being a programmer. I've said it before and I'll say it again. It's what I do. In particular, the use of unit tests (not enough of them, mind) and TDD was a very useful way to solve this particular problem.
I have "hero" tendencies. This means that I want it to be my line of code which saves the day. I also have blustering as a character trait. I was more determined to do this particular thing because it was suggested that it wouldn't work. Again, in the cold light of day (or in this case, the soporific miasma of late night contemplation) maybe there are reasons why it's not all that good, but it's also pretty good. Do you care what it is? Oh well, if you don't, then ignore the next bit and stop reading.
Imagine an XML file:
It's a simple configuration file. There is a property of the configuration called "name", which is a string, another called "point", which is some sort of tuple of "x" and "y", then there is a list called pets, of which there is a Dog and a Cat. Sometimes properties are expressed in attributes, sometimes they're in sub-elements. It's an anything-goes kind of a file.
You could write a mapping from this to some appropriate class structure, along with schema validation. You could. Or, you could create some classes:
Then you could use the code-generation facility of most IDEs to generate the getters and setters for all of these values, giving you a series of POJOs/DTOs/VOs, whatever you want to call them. My code will just let you point your XML at the starting class. It can tell that the xml element "point" has a counterpart in the "Configuration" class and can, therefore, infer what object to create to go in there, and, thus, how to populate its Xs and Ys. For the list, it creates a simple list and guesses at where to find the classes (same package as the owning class) that are mentioned in the xml.
It's mapping-free XML to object mapping - it's unnecessary ironing:
I called it HlxParser, which is short for "handy little xml parser" or, more likely "hateful little xml parser". It's sure to piss people off. It works, though... as far as it goes! It'll be a bitch to debug!
Today had a much closer home/work connection, since I ditched the office at 11am and, after an early lunch in which I bought a casual blazer, came home to do a day's work. In fact, for some reason, I did more than just the working day's work. I kept going until much later than planned. I got into it.
A reshuffle of the evening's activities ended up occurring to cancel the painting and dig deeply into the laundry pile to discover all those garments I thought I'd lost, and which turned out to be simply hibernating in the big basket I'd wondered what I'd put in.
I ironed for a long time. In the end, I took on some ironing tasks I never take on. I ploughed through some bed linen. This is nice bed linen, which I've only recently bought, so why not make it look nice - it will, hopefully, go on the bed very well next time. But it was unnecessary. But it was a nice-to-have.
Perhaps nice-to-haves are best described by the term unnecessary ironing. You can see why a nice-to-have is nice-to-have. That's how it got its name, but is it absolutely essential? Is it worth the time?
It occurs to me, as I weigh up what I made on my computer today, that the end result was ok, but not much more than just that. Ok. I made something that I didn't think I could get anywhere else, and which I reckoned would save a bunch of time to have. Thing is, there's a reason why people haven't made it, and there's also a question in my mind over whether we'll ever "earn back" the time I've theoretically saved by making this thing.
From my position right now, I can see how the method I was going to use for another thing, which seemed to justify the "need" for this particular tool, might be better off changed to something else, which I know doesn't need it at all.
D'oh!
Still, I got to flex my muscles as a programmer and I like being a programmer. I've said it before and I'll say it again. It's what I do. In particular, the use of unit tests (not enough of them, mind) and TDD was a very useful way to solve this particular problem.
I have "hero" tendencies. This means that I want it to be my line of code which saves the day. I also have blustering as a character trait. I was more determined to do this particular thing because it was suggested that it wouldn't work. Again, in the cold light of day (or in this case, the soporific miasma of late night contemplation) maybe there are reasons why it's not all that good, but it's also pretty good. Do you care what it is? Oh well, if you don't, then ignore the next bit and stop reading.
Imagine an XML file:
<Configuration>
<name>Ashley</name>
<point><x>12</x><y>34</y></point>
<pets>
<Dog name="rover" />
<Cat livesRemaining="8" />
</pets>
</Configuration>
It's a simple configuration file. There is a property of the configuration called "name", which is a string, another called "point", which is some sort of tuple of "x" and "y", then there is a list called pets, of which there is a Dog and a Cat. Sometimes properties are expressed in attributes, sometimes they're in sub-elements. It's an anything-goes kind of a file.
You could write a mapping from this to some appropriate class structure, along with schema validation. You could. Or, you could create some classes:
class Configuration
{
String name;
Point point;
List pets;
}
class Point
{
int x;
int y;
}
class Dog
{
String name;
}
class Cat
{
int livesRemaining;
}
Then you could use the code-generation facility of most IDEs to generate the getters and setters for all of these values, giving you a series of POJOs/DTOs/VOs, whatever you want to call them. My code will just let you point your XML at the starting class. It can tell that the xml element "point" has a counterpart in the "Configuration" class and can, therefore, infer what object to create to go in there, and, thus, how to populate its Xs and Ys. For the list, it creates a simple list and guesses at where to find the classes (same package as the owning class) that are mentioned in the xml.
It's mapping-free XML to object mapping - it's unnecessary ironing:
// load the object from the file
Configuration config = (Configuration)HlxUnmarshaller.loadFrom(file, Configuration.class);
I called it HlxParser, which is short for "handy little xml parser" or, more likely "hateful little xml parser". It's sure to piss people off. It works, though... as far as it goes! It'll be a bitch to debug!
0 Comments:
Post a Comment
<< Home