Today, I Suck Less.

Yep, productivity not bad at all today. Quality of sleep, general mood, and things like that.

I suck.

Oh yeah. Big time.

Hibernate In-Memory Still Slow

I'm beginning to suspect that Hibernate setup with an in-memory is pretty much as slow as regular database Hibernate. Despite being recommended as a useful alternative for fast automatic testing.

Since I am feeble-minded, I think I shall try to look into it a little, instead of accepting the depressing reality. It's just that it's such a hugely soul-killing drag, despite only chipping away 10-20 seconds of spirit every test. Well, multiplication.

Will be updating here, probably.

Time for a Walk

Tests. Unpredictable OOMs. Slow. How the f* do you debug such things. Why not on every test? Why can't I just run the things I use, why does everything have to be wired in? Why is hibernate startup so f* slow?

Why am I wasting my... right, there is none.

Time for a walk, maybe the emotional turmoil -- I think mostly nervousness, anxiety, probably from a loss-of-control reaction, some anger, some depression -- will settle.

The Tokenizer Tail Wags The Java Syntax Dog

I'd like to register a complaint: the Java rules for package names are stupid.

Why the _ do the folder names, or components, have to be legal Java identifiers? Most probably because the package name is not designed as a syntactical element all by itself. Or even as a lexeme/tokens of its own, but a sequence of tokens. I suppose the Java syntax is designed as a sequence of lexeme/tokens. Probably under the influence of the long tradition of bottom-up syntax grammars, correct me if I am wrong.

And now, with the Java8 designers trying to reclaim some syntactic space from the past mistakes, another keyword is foreshadowed: underscore.

> Warning about single underscore identifier

Already annoyed by Eclipse Luna's (4.4M7) treatment of warning about this (and I haven't found a way to turn it off), I just discovered an even more annoying behavior, which put the annoyance count at two bits, which overflowed into this one post. Unfortunately it's unlikely to leave zero in the annoyance column to the right.

This behavior is that Eclipse won't do the "Move Type to New File..." refactoring as long as this 'warning' is available to make a fuss over. No wait, sorry; apparently now it is an 'error'. This makes no sense at all.

And then for the prize: one can't even rename package names. Presumably because the package name is all retarded, with that un-scannable underscore in it. Maybe it'll be better in the next revision.

A workaround is to comment out any package declaration or import that contains a package name with this terrorist underscore in it. Though that is likely to give other errors, of course...

In fairness, there are probably not many that have discovered the awesome power in naming your packages '_'. But I happen to have it as part of a Brilliant System, so this could get really painful if the Java designers would take this bad idea to completion.

As I started out saying, it makes little sense for packages to have to be 'good' Java names anyway. The requirement could be dropped with no forward compatibility problems at all. Sure, backwards compatibility could be a problem, IOW you may want to be warned when you write code that can't be compiled as Java7 code. OTOH, then why not use a Java(N<8 all="" be="" check="" compiler="" it="" java="" ll="" of="" p="" syntax="" then="" to="" your="">
Do class loaders check class names to not contain keywords, and comply to be identifiers? I don't think it checks resources. And why should it check class names beyond some simple sanity checks? That's only added complexity.

And if no other argument convinces you, how about the fact that there exist other languages, and that the JVM is positioned as and adapted to being multi-lingual, aka polyglot? Why should other languages have to put up with this nonsense?

Java 8, Luna, Subclipse

Yep, going to try Java8 already. I installed the JDK a couple of weeks ago, since I was updating Java7 anyway, and found that it would indeed appear as a JRE in Eclipse; but didn't take it further.

But now I am. Downloaded Eclipse Luna, 4.4M7. Tried to changed Java compiler settings to output version 7 class format, but allow Java 8 source. I had somehow got the idea that that should be allowed. And why would you output legacy 7 code as format 8, anyway? But it isn't allowed. So 8 in, 8 out, then. Seems to work fine.

But with J8 output, I had to install Java8 on a target server; so here's how to do that. You probably don't have to use all of it.

nano /etc/hosts # because sudo complained about not resolving hostname
sudo apt-get install software-properties-common # because 'add-apt-repository' wasn't there

sudo add-apt-repository ppa:webupd8team/java

sudo apt-get update

sudo apt-get install oracle-java8-installer

I also installed Subclipse 1.6. The file/folder status markers were added, but it wouldn't synchronize, "Unable to load default SVN Client", so I tried installing the SvnKit module too. I have the habit to try to install as little as possible, so one thing at a time, although a few restarts are needed. Still no go.

And then I saw the "SVNKit Client Adapter (Not required)", which makes perfect sense; so I installed that, and now these rather old Subclipse modules work inside the latest Eclipse.

So, done and done. Could be easier, but still comparably easy. Java 8 has arrived in my toolchain; to stay, I think. I read that it's very backwards-compatible, source-code wise.

---

Oh, right. Got an OOM during build, so the memory allotment param in eclipse.ini (inside the app) had to be edited too. Changed to "-Xmx1500m" from "-Xmx512m".

---

Ah, trying a lambda expression as first thing, of course. Error: "Lambda expressions are allowed only at source level 1.8 or above". That's nice, it knows about Java8 even at Java7 source setting. There's even a quick tip: "Change project compliance and JRE to 1.8". Well, yes to that, thank you; wow much thoughtful.

And isn't that just cute:

public static void main(String...args) {

   Sam sam = (a, b) -> a + b;

}

interface Sam {

  int bla(int a, int b);

}

---

Trying out what I thought would be the most important feature of Java8, the default (aka defender) methods. Of course, it turns out they don't work as I'd thought.

public class Java8Demo { public static void main(String...args) { Sam sam = (a, b) -> a + b; // SamDefend sd = (a, b) -> a + b; // The target type of this expression must be a functional interface } interface Sam extends SamDefend { int bla(int a, int b); } interface SamDefend { default int bla(int a, int b) { return a + b; } }// Sam sam = new Sam() { // The type new Java8Demo.Sam(){} must implement the inherited abstract method Java8Demo.Sam.bla(int, int)//// @Override//// public int bla(int a, int b) {//// // TODO Auto-generated method stub//// return 0;//// }// };}

Oh #. Blogger/blogspot sucks, especially for blogging software development stuff...why can't I just paste code with formatting intact?

public class Java8Demo {
 public static void main(String...args) {
  Sam sam = (a, b) -> a + b;
  // SamDefend sd = (a, b) -> a + b; // The target type of this expression must be a functional interface
 }
 interface Sam extends SamDefend {
  int bla(int a, int b);
 }
 interface SamDefend {
  default int bla(int a, int b) {
   return a + b;
  }
 }
// Sam sam = new Sam() { // The type new Java8Demo.Sam(){} must implement the inherited abstract method Java8Demo.Sam.bla(int, int)
////  @Override
////  public int bla(int a, int b) {
////   // TODO Auto-generated method stub
////   return 0;
////  }
// };
}

Meh. That's as close as it gets.

Close() But No Cigar

The ByteArrayInputStream.close(), it does nothing! And it thus allows reading bytes from the ByteArrayInputStream object after calling close() on it.

Of course someone like me has to make a mistake, closing the ByteArrayInputStream on creation. I did, by leaving a "try-with-resources" in place during refactoring, returning the 'implicitly' closed stream.

Result: 1-2 hours extra debugging, thinking that my code, using XMLStreamReader, tested with ByteArrayInputStream and string literals, had some error causing it to skip prematurely all the way to the end.

An easy fix is to use your own subclass and override close(). Something like this:

/**

* Otherwise, java input stream might return data even when closed. 

* {@link super#close()} does nothing. 

*/

@Override

public void close() throws IOException {

    this.pos = count + 1; // distinct from the 'real' EOF; might be useful.

    super.close(); // does nothing in super, but whatever. 

}

And why doesn't the standard library do this? There seems to be no performance penalty. Well, maybe there is, maybe it's kind of wrong to return EOF (-1) here, maybe it should throw an exception. But is returning bytes after closing better?

Synoptics

Programming Sucks (post)
programming is terrible (blog)

I won't mind at all if links to other output with the same outlook appear in the comments.

It's Got What Projects Crave: It's Got Resources

I can't help meta-ing, aka thinking about what I do. And so I'm not totally happy with the below post, but what the. I'm thinking maybe I should describe what I think is good, instead of what I think is bad. Though maybe both are ok, maybe the one helps the other. And this text touches on one important facet of complexity, i.e. non-simple-ness, which I have some thoughts on; which thoughts may well materialize as text. Mental note to self: scale-free-ness. But the text is a bit un-simple in itself. Not well structured. Split-brained. Well so what, I'm not a professional writer. The text is at least trying to make a bunch of points. So let it. I can come back later.

---------

Last week I committed with a message like this: "Let's move test data resource files very far from the test source code files: Maven's src/test/resources/". It's an objective description of the change. Though with a small bit of snark. Sometimes, you're morally obliged.

I've been doing software development for a long time. I have, driven by discontentment or frustration, strived to develop at least an idea of what practices make developing easier, even somewhat possible. So my software developer sensibilities have been shaped for a long time. They may certainly need more shaping, but still.

Partaking in a Maven project, these particular sensibilities actually become a liability.

Maybe because the Maven sensibilities, anthropomorphically speaking, have not been shaped by time at all. They were pretty much set a long time ago, perhaps from the start (I'll have to look that up). But the non-existing sensibilities of a stupid tool can and will influence projects and people. Yes, not very difficult to tell Maven to also copy files from /java or whatever, but then half the point of using Maven gets lost, the setting of standards, some standards.

The test/main divide is bad enough, according to my humble sensibilities of course, but the resources/ divide is just sky high on the chart of badness, also according to these humble sensibilities. In fact, you can read 'taste' or something where I say 'sensibilities', it's a bit of a posh word anyway, isn't it.

Why was this layout chosen for Maven from the start? Well, there are some small advantages to it. For instance, you don't have to skip files that are not source-code when compiling. Maybe that was an important performance advantage back in the day, but that's hard to imagine.

Another is that you can have ".java" files be copied verbatim into the jar being built. This could actually be useful.

Polyglot projects could be having java/, scala/ etcetera. On the other hand, that's a bad taste again, it's not really polyglot if you have to have multiple folders, is it? All the source code should go into one source code folder..."src/{main,test}/src/"? "src/{main,test}/tobecompiled/"?

But what about script language source code, e.g. javascript? Well, there you go, it could be either.

This is the old arbitrary code vs. data divide thing living on.

It's also a duplication of structure, a structure that can be twenty folders deep no less.

It also makes it hard to reorganize your code and data together; and such operations AFAIK also are not supported by IDEs, so they can't help you either.

And there's a special wrinkle with Eclipse: it copies files in /java/ as resources, so you will, as I recently and not so recently have, end up with mysterious inconsistencies with tests working on Eclipse, but not in tools correctly following the Maven layout.

It's just so wrong. About 99% wrong.

Black Is The New Productive

This is just such a wonderfully perky headline isn't it; imagine it read by a voice with the intonation of a fifties commercial:

You Thought You Couldn't Be Productive When Feeling Depressed, Just Wait Till You Read This

Imagine somebody depressed sitting in the corner of his own mope, perhaps thinking 'oh no, I can't be productive' (funny already), but then the words of the headline lends a glimmer of hope, and the phrase 'Just Wait' reignites his flame: 'Yes, I can't wait to read This!'. This person obviously has no problem suddenly turning into an optimist. Funny to me, at least. So I may not be clinically depressed.

From my own experience I would theorize that generally, productivity simply drops to a fraction, say, 25%. I am sure you can still be productive, but at a lower level. It might help, though, to take care to remove the kind of obstacles that get you especially hard when you're depressed or unmotivated.

I'd like to maybe write about that. It seems that a big part of being depressed makes it hard to focus. Or, to stay focused once you start thinking. The thoughts wander. So, firstly, keep thoughts from wandering. Or, make it really easy to get back into your work.

Quick feedback is probably a good answer to keep from wandering, and maybe also make it tempting in a gamification sort of way, to keep coming back to just implement one more feature, fix one more bug. E.g. tests must deliver results in seconds. If it takes 20 seconds for setup, thats 20 seconds to wander in.

Allow being consistent, to avoid sliding into long-term thinking. Shouldn't need to be thinking about how to organize code too much.

Need to be learning should be kept to a minimum. For instance, learning a framework. Learning is uphill, and extra steep when depressed.

Need to be debugging is bad, debugging is also mentally straining. Allow only clearly understandable error messages, etcetera.

Things like the above. Actually, kind of makes sense for anybody, not just the depressed. Just being tired is close to being depressed.

How to Put the Tree Back in SourceTree

How do I get the file tree back? - Atlassian Answers

http://downloads.atlassian.com/software/sourcetree/SourceTree_1.8.1.dmg

"Question quality is dropping on Stack Overflow"

> http://meta.stackoverflow.com/questions/252506/question-quality-is-dropping-on-stack-overflow

> Stack Overflow meta

There's an interesting discussion going on on the subject of "Question quality is dropping on Stack Overflow". Choice quotes:

"Folks are entering this field not because they have any real drive, love or talent for the craft, [...]""The question quality will continue to decline as long as we continue to reward the bad questions with answers.""The problem is by no means new, btw, as evidenced by this four year old thread. The number of users who are full of it might be, however, [...]""In my view, SO made the jump and became the zero-cost version of Mechanical Turk aeons ago.""How about a probationary period for Questions"

And one answer is the wiser, IMHO: 

This is how gamification works, right?

The rules of Stack Overflow: The Game are as follows.

Your rep is your score.
You want your score to be the highest, because then you WIN. Winning is good!
Downvoting bad questions does nothing to your score. Who cares?
Voting to close bad questions does nothing to your score. Who cares?
Downvoting bad answers, or answers to bad questions, lowers your score. Avoid at all costs!
Posting a quick answer to a trivial question generally nets you an accept, plus maybe a couple drive-by upvotes. Which makes it the best strategy.
The game isn't designed to increase the SNR.

Dislike the game, not the player. The game at Stack Overflow was well enough set up that it could work pretty well for some time. 

Now for my own thoughts...well, sometime later, some sunny day when I get some return for writing here.

Actually, I do have some thoughtful thoughts on this, and I may very well get back with them. This post feels just about the right size and the right single-subject form to end here.

A. Vayner Dead

Just happened upon a piece of information, that makes me rather sad: Aleksey Vayner apparently died about 15 months ago; at what must be a rather young age. Aleksey Vayner was the man behind the 'Impossible is Nothing' video made for a job application, that inadvertently went viral after October 2006; and, later, inspired the name of this blog.

> Impossible Is Nothing (video résumé) - Wikipedia, the free encyclopedia