The Transporter
-
In Java, you can just implement Serializable and declare a local static long serialVersionUID=12345L, and Java will automatically de/serialize all non-transient common members of your object (assuming all nested objects also implement Serializable), even across different compilation units. Simple. Automatic. Completely built in.
Our developers felt that we needed this:
public class Transporter implements Externalizable { private static Map map = new HashMap();public static void put(Object key, Object value) {
map.put(key,value);
}public static Object get(Object key) {
return map.get(key);
}public static void writeExternal(ObjectOutput out) throws IOException {
// write some header control info, and iterate over map and write all objects to: out
}public static void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
// read header control info, use it to read all objects from: in and populate local map
}...
}
Why? Because this way we can send arbitrarily complex objects (no matter how many members they contain) between classes/programs!
Mind you, Java will do this automatically, without any effort on your part.
-
I wonder if someday, someone will develop a cure for the Not Invented Here Syndrom.
-
@Renan said:
I wonder if someday, someone will develop a cure for the Not Invented Here Syndrom.
Doesn't matter. No one else will use it.
-
@Renan said:
I wonder if someday, someone will develop a cure for the Not Invented Here Syndrom.
It already exists, but it's not good enough, so I invented my own cure.
-
Not even a powerful NIH cure can combat the unfortunate effects of DKIWIE Syndrome ("Didn't Know It Was Invented Elsewhere").
There is much contention in the field of evolutionary pathology as to which disease first originated and which was the mutation, or even if was just convergent evolution...
-
@Daid said:
@Renan said:
I wonder if someday, someone will develop a cure for the Not Invented Here Syndrom.
It already exists, but it's not good enough, so I invented my own cure.Beat me to it.
-
@Master Chief said:
@Daid said:
@Renan said:
I wonder if someday, someone will develop a cure for the Not Invented Here Syndrom.
It already exists, but it's not good enough, so I invented my own cure.Beat me to it.
His joke wasn't good enough. You could do better.
-
@Renan said:
I wonder if someday, someone will develop a cure for the Not Invented Here Syndrom.
Yes- Write Once Read Never languages, like assembler or Perl, where you invent everything yourself! NIH will persist for as long as companies will insist on hiring developers who enjoy coding more than reading documentation. Or learning to competently use features of their language beyond the switch-if statement.
-
Aw! Stupid! But, wait, did they also invent their own un/marshaling algorithm? Based on XML but not exactly well formed XML? Do they even know what "serialize" means?
-
I have to reinvent the wheel all the time where I work. Though it usually goes like this:
Manager: Hey, can we make our product do this?
Me: Yeah, of course! There's <random class here> in the library we use, I'll just reference that and it'll be done soon.
One hour of coding and testing later:
Me: Here it is, check it out.
Manager: Sweet! Looks good, but can we make it do <seemingly minor, trivial addition> as well?
Then I dive in and without exception find that <random class here> is sealed and has very few events or properties and can't do <seemingly minor, trivial addition>. Asking the library's vendor to change it is out of the question since we need this now, not in two years. So I spend a couple days to a week reverse-engineering the class and creating a similar class with identical behavior so we can add <seemingly minor, trivial addition>. Eventually I learned to just write everything from scratch at the start rather than depend on that library, except where absolutely necessary.
-
@mott555 said:
Then I dive in and without exception find that <random class here> is sealed and has very few events or properties and can't do <seemingly minor, trivial addition>. Asking the library's vendor to change it is out of the question since we need this now, not in two years. So I spend a couple days to a week reverse-engineering the class and creating a similar class with identical behavior so we can add <seemingly minor, trivial addition>. Eventually I learned to just write everything from scratch at the start rather than depend on that library, except where absolutely necessary.
This is basically the non-WTF reason why NIH will never die. Because requirements are never quite compatible.
Still, it would be nice to eliminate as much of the braindead stuff like snoofle found. Of course, the trick is distinguishing between the two cases. This often takes some creative thinking, which is pretty difficult. It can be really difficult to see ways around the obvious, especially when the status quo (or obvious solution) gets stuck in your mind.
-
@Xyro said:
DKIWIE Syndrome ("Didn't Know It Was Invented Elsewhere").
Your acronym wasn't good enough, so I made my own called DIKWIED
-
@Xyro said:
Not even a powerful NIH cure can combat the unfortunate effects of DKIWIE Syndrome ("Didn't Know It Was Invented Elsewhere").
Surely far worse is not even bothering to perform some basic googling to determine whether someone might not have encountered the same problem before.
Perhaps we should call that...
Pedantic DKIWIE Syndrome.
-
@mott555 said:
I have to reinvent the wheel all the time where I work. Though it usually goes like this:
Manager: Hey, can we make our product do this?
Me: Yeah, of course! There's <random class here> in the library we use, I'll just reference that and it'll be done soon.
One hour of coding and testing later:
Me: Here it is, check it out.
Manager: Sweet! Looks good, but can we make it do <seemingly minor, trivial addition> as well?
Then I dive in and without exception find that <random class here> is sealed and has very few events or properties and can't do <seemingly minor, trivial addition>. Asking the library's vendor to change it is out of the question since we need this now, not in two years. So I spend a couple days to a week reverse-engineering the class and creating a similar class with identical behavior so we can add <seemingly minor, trivial addition>. Eventually I learned to just write everything from scratch at the start rather than depend on that library, except where absolutely necessary.
Ugh! Sealed classes are TRWTF, for precisely that reason.
-
You know how sometimes you need to warn other drivers when you're about to make a turn? Well I came up with this awesome system using lights to alert the guy behind me. I drilled two holes at the back of the car and installed a LED in each one (sealed with a glue gun to keep it watertight). Then I ran wires through the car frame (major pain in the ass) which ended up at two switches on the dashboard. I also added a little plastic cup thing to hold the 9V battery for the lights. Then every time I wanted to turn I'd just flip the appropriate switch to turn on a light.
After a while though this became kinda of a problem cause I needed the light at the back to blink for greater visibility and flipping the switch on and off while turning was a major pain. So what I did was add a pad at each side of the driver seat and placed a pressure pad on each one (all you need is tinfoil and paper!) to control each of the light. Then when I had to turn I'd just lean to the side and then rock back and forth to make the light blink.
I'm currently thinking of patenting my system.
-
@orange_robot said:
NIH will persist for as long as companies will insist on hiring developers who enjoy coding more than reading documentation.
There exist developers who would read documentation more (and enjoy it more) if so much documentation wasn't rubbish to begin with. A vast swathe of autogenerated boilerplate that does little more than list method signatures is not documentation. A wiki peppered with a random assortment of notes about particular aspects is not documentation.
But crappy documentation will probably exist for as long as it continues to be written by developers who enjoy coding more than writing documentation (and feel free to insert a comma after "developers", there).
-
@Kittemon said:
@Xyro said:
Far worse is googling for the problem and copying the exact same solution someone else provided, no matter how bad or unsuited is is for your environment.Not even a powerful NIH cure can combat the unfortunate effects of DKIWIE Syndrome ("Didn't Know It Was Invented Elsewhere").
Surely far worse is not even bothering to perform some basic googling to determine whether someone might not have encountered the same problem before.
-
@dhromed said:
I larfed.@Xyro said:
DKIWIE Syndrome ("Didn't Know It Was Invented Elsewhere").
Your acronym wasn't good enough, so I made my own called DIKWIED
-
Behold the glory of android.os.Parcelable:
public class MyParcelable implements Parcelable {
private int mData;
public int describeContents() {
return 0;
}
public void writeToParcel(Parcel out, int flags) {
out.writeInt(mData);
}
public static final Parcelable.Creator<MyParcelable> CREATOR
= new Parcelable.Creator<MyParcelable>() {
public MyParcelable createFromParcel(Parcel in) {
return new MyParcelable(in);
}
public MyParcelable[] newArray(int size) {
return new MyParcelable[size];
}
};
private MyParcelable(Parcel in) {
mData = in.readInt();
}
}
-
I prefer the Externalizable interface, because the Serializable interface is possibly one of the dumbest and most inconsistant things about Java. It does nothing but mark the object (a practice discouraged by Joshua Bloch). If they did it all over, they would probably use annotations to do the same thing more elegantly.
Notice, I said it was inelegant: I did not say it was not useful. I just wish that this usefulness had been defined in a more elegant fashion.
-
I invented something great once, but I was somewhere else at the time, so i never use it. [NIH to the extreme!]
-
@TheCPUWizard said:
I invented something great once, but I was somewhere else at the time, so i never use it. [NIH to the extreme!]
Sadly, pretty much every law-abiding innovative contractor in the US can say that, because of the way IP laws plus standard contracting contracts work. I have mostly been spared, because the places where I contracted before my current employer either used proprietary environments so different from standard practice that reuse of the inventions requires parts of that environment, or they followed what I would call 'worst practices', such that all of the improvements I came up with were kludges to work around horrible things I would post here, except for that quiet voice in the back of my head that says, "nobody else could do something that bad and have it still work, thus they would be identifiable even through anonymization." No, they probably weren't really that bad, but that's what the voice says.
Parcelable | Android Developers
