My Professor is an idiot

I've had the dubious distinction of running freenode's ##java IRC channel almost 10 years now.  (Yes, i'm "that jerk" to some people. :D )  As such, I've seen a lot of beginners come and go.  One common complaint we tend to see in the channel is university (usually) students coming in and complaining about their "stupid" homework and their "stupid" teachers.  It's a depressingly common refrain that I've tried to address in channel when it comes up but I'd like to expand on it here.

Let me start by acknowledging that there are some professors teaching that probably shouldn't be.  It can happen.  Hiring mistakes are made all the time.  Call it blind optimism, hopeless naiveté, whatever, but I have to believe that this is a far rarer occurrence than these indignant students would like to believe.  As a new student, as a beginner in anything, we're functionally too ignorant to gauge our instructor's competence with any meaningful value.

Many students focus on how dumb an assignment is based only on face value without stopping to consider any deeper or longer term questions.  When I was in high school, my computer science teacher gave us a problem.  It was a little something like this:

You have an army on two different hills separated by a valley controlled by the enemy.  One side can not directly communicate with the other but has to send a runner from one side to the other.  Devise a protocol for sending messages which can guarantee delivery with no message loss.

That's not exactly it but that's the basic gist of it.  As we hammered away on all our brilliant solutions, our teacher kept pointing out flaws.  "They can't signal each other."  "That requires a direct communication with each other."  etc.  As time wore on we were increasingly frustrated by the impossibility of it.  We would have felt justified considering this assignment stupid.  But the point of the exercise wasn't to design a communications protocol.  It was to realize the inherent hostility of networks and the difficulty of building robust networks.

Teachers often assign such tasks to drive home points other than the obvious.  Another example is when teachers give assignments with restrictions that a professional would consider not only absurd but outright destructive.  Oftentimes, these assignments aren't about learning that particular approach but learning how truly stupid it is.  By forcefully highlighting such shortcomings, the "correct" solutions then become much clearer.  

More commonly,  students are forbidden to use existing libraries and are forced to implement things like linked lists from scratch.  Professionally, no intelligent boss will require this of anyone.  But as a student, it's the only way to really learn how such structures work.  It may be "dumb."  It's certainly tedious.  But it's fundamental.

Another example:  when I went through CS in university, the degree program was pretty new.  By the time I got around to taking discrete math, they had moved it from a senior level course to a freshman level course.  So I was in the course with a fellow senior and dozens of self-important freshmen who were utterly convinced that they would "never need to know" topics such as algorithmic complexity analysis.  Having already been through the bulk of the courses they had yet to take, we laughed at their ignorant bleating.  We tried to tell them otherwise but they wouldn't be convinced.  They knew better, you see.

My advice to beginners, then, is this:  always keep in mind that those who have been selected to teach you might actually know more than you.  Pay attention.  Withhold judgment until you have the full story.  Learning takes many forms but almost all of them start with you acknowledging that you don't know everything you think you do.  

Ophelia

​I've been using mongo pretty heavily the last year or so.  Consequently, I've spent a lot of time in the mongo shell and this has served me well enough for quite a while.  But the biggest drawback to using the shell is the scrollback.  For large result sets, the firehose of results can be hard to wade through.  I've tried this or that tool but they all seemed buggy or incomplete.  So I decided to write my own.

The ​result is Ophelia.  Based on the play framework and twitter bootstrap, and hosted on github, this represents my attempt to fill this tool gap.  What I have ready now isn't 100% of what I want but I'm to the point now that I feel like I should get more eyeballs on it to help validate the direction I'm going and working out the issues I know are there.  There are a number of known issues and limitations but the more relevant one is that, for now, this needs to be run on the same host as your mongo database.   This will probably be the next thing I tackle but for now, that's how it is.  I'll also be adding things like online help and user guides so you can learn things like clicking on a collection name will populate the query field with a basic find query.

I'm planning on adding loads more features now that the base is done.  If there's something you'd like to see or if you find a bug, please file an issue and we'll see where it goes.​

​Update: Added some screenshots below.

Autogenerating META-INF/services

​If you've ever tried to use SPI, you're familiar with the hassle of maintaining the meta files necessary for the system to work.  Especially early on when a system is under heavy flux, keeping everything in sync can be a frustrating, error-fraught experience.  Many just plow through it.  Others turn to automated solutions and here is where the trouble begins.​

If you're smart you look for a library and if you're lucky you find one that fits your needs.​  For one reason or another, some choose to write their own library.  I know I've written one.  Kohsuke of hudson fame has written one.  If i were to use one today, I'd probably end up using this one.  I don't see it on the home page, but I seem to remember Reinier Zwitserloot suggesting that lombok had one in the works.  There are probably a dozen more out if one cared to dig deep enough (I don't).  But it shouldn't be this way.

So we have a situation where using a built-in feature to the java runtime is so awkward that we have all these competing, divergent solutions.  It's time for the JDK team to provide a native apt plugin to handle this natively.  Any feature that drives so many to build work arounds for it clearly is missing something.  In my opinion, this should be done by the JDK team and included in Java 8 at the latest.  If it takes filing a JSR to get it into Java 8, great.  I'd even lead​ ​it if necessary.  Build an amalgam of the solutions out.  Bundle an existing implement.  Build one from scratch.  Anything.  But please, give us something native so we can stop inventing the wheel over and over again.

To take it even a step further, I'd push for building a type database by default when building a jar.  Fantom has very nice way to tell the system, "Give me everything of type X."  This kind of "database" would be trivial to build during either the compilation or jar bundling phase.  But to be able to ask the JVM, give me references to all the classes implementing the interface FooBar​ would be an amazingly useful facility to have.  It would eliminate the need for jar/classpath scanning at start up for everything from simple plugin systems to full blown EE stacks.

So what do you think?  Is it too late for something like this in Java 8?  Or Java 7 update mumblemuble?  It'd be an amazing addition.