TECH | Stop using JPA/Hibernate · Blog de Laurent Stemmer

Here an example of a JPA entity (using Lombok for “simplicity”): <sarcasm quotes mine>

@Entity
@Table("offer")
@EqualsAndHashcode
@NoArgsConstructor // for Hibernate
@Setter // for Hibernate
@Getter
public class BankAccount {
    @Id
    @Column("id")
    private String id;
    @Column("opened")
    private boolean opened;
    @OneToMany(fetch = LAZY) // ...simplified
    private Set ownerIds;
}

Source: TECH | Stop using JPA/Hibernate · Blog de Laurent Stemmer

Through a very long series of unfortunate circumstances, I was backed into using Java/Spring/Hibernate/Angular in a doomed project. This page had me nodding my head in agreement, and this code reminded me of the Lombock portion, which was its own special nightmare. I just went looking for what I had written for that project, and it would appear that I’ve totally deleted it. I normally keep everything, so I can go back and refresh my mind when I recall some particular technique I’ve used in the past, so this should tell you something about the brain damage using this stack will incur.

I’m going to digress to setup a point. I used gvim for many years, with a complicated setup, using NerdTree and several other plugins, to give me a UI with my project’s directory on the left side, and tabs of open files on the right. At some point, I got tired of fiddling with the configuration, and finally started using someone’s massive-but-well-integrated ~/.vim configuration from a GitHub repo. Finally, I realized that I was spending all this time and effort on making gvim work just like ST did out of the box, and I could just start with that. So I did. While I’ve flirted with other editors (notably, Visual Studio Code, and the excellent IntelliJ, while working on Java), I’ve basically stuck with it for about 7 years now.

Here’s the parallel. The thing that fans of the Java ecosystem can’t admit to themselves is that this whole stack: Java, Spring, Hibernate, Lombock, Javascript, AngularJS, etc., et. al., ad naseum… is all just a terrible pile of Jenga blocks which putatively exist to give you a functional environment like… wait for it… Ruby on Rails! Lock, stock, and out of the box. It seems to me that the motivation of people who still like to use gvim when Sublime Text and Visual Studio Code exist is the same sort of motivation of people who like to use a Java stack over something like Rails. Maybe they’ve done it so long, they can bang out the boilerplate with their eyes closed. Maybe they like the way you have to do everything explicitly. Maybe it makes them feel like a hacker.

All of the code above reduces to this in Rails:

class BankAccount < ApplicationRecord
    self.table_name = 'offer'
    belongs_to :owner
end

In an absolutely brilliant display of one of the biggest problems with using this Java stack, I went to remind myself what the @Table("offer") directive does. I think it might specify the actual SQL database table name storing the instances of this object, but I literally can’t find any references to this pattern in the Lombok documentation. It is only through inferring it from a StackOverflow question that I am reasonably confident that this is, in fact, what it’s doing. And if it weren’t for Spring and Hibernate and Lombok, there’d be about a hundred more lines of boilerplate code in that single class file.

The top comment thread on the HN discussion about this blog post points out just how bad of an ORM Hibernate actually is. With 15 years of experience with Rails under my belt, I can assure you that almost none of those issues apply to ActiveRecord. Of course, I’ve seen people complain about AR, but I think their arguments are always exaggerated, and probably come from a place of general discontent with having to use Rails at all. People like to complain that Ruby is “slow” because it is interpreted, but it’s precisely that on-the-fly reflection that allows ActiveRecord to be so good at being an easily-programmed and powerful ORM. It’s trading machine time for ease of development and readability, and I have yet to see a situation where that was a bad tradeoff.

While I’m on the subject of ORM’s, I find EntityFramework just as bad as Hibernate. I suppose it’s just the nature of an ORM in the context of a compiled language. After giving it a real college try, I gave up on it. I wrote a serious application in Visual Basic and C# which accessed the database through a library of functions wrapping raw SQL, and called them from the WinForms side, and it worked out very well. I’m glad I didn’t try to force EF to work.

So, sure, rag on Rails. Call it slow. And, yes, compiled Java will always be technically faster than interpreted Ruby, but all the Java web sites I have to interact with are noticeably laggy and sluggish, compared to my apps, so there’s something to be said about implementation. And, while a whole team of Java devs are still writing class files, in both Java and Javascript, for their object model, I’m done with my app, and moving on to the next one.

So, yes, by all means, please stop using JPA/Hibernate, but, I would go one step further, and advise people to just stop using Java for web apps entirely. That horse got passed 15 years ago. Even if you don’t like Rails, there are at least a few other stacks that would be far more productive than Java for web apps these days. Heck, I’d try to do Javascript on the frontend and backend before I’d try doing Java again. <shiver>

And that’s my “2 minutes of hate” for today.

IMHO: The Mythical Fullstack Engineer – Stack Overflow Blog

It’s my experience that the above MVFE is pretty uncommon. The profile describes a person with skills requiring thousands of hours to master, but who doesn’t take part in the holistic decision making process. By nature, the value of a fullstack engineer stems from their ability to make competent unilateral decisions (decisions without asking anyone for permission). I’m sure there are people who mostly fit the MVFE, but I wager that they are few and far between. You could probably summarize my view about the MVFE as:

It’s very impractical to become a fullstack engineer without understanding the big picture.

In my mind, a fullstack engineer’s value is mostly derived from their ability to single-handedly design, architect, execute, and operate an entire end-to-end system. Assuming this is possible, it almost completely eliminates integration overhead.

Source: IMHO: The Mythical Fullstack Engineer – Stack Overflow Blog

There’s a lot of subjectivity in this article, but I think it covers the topic pretty well. I consider myself a full-stack engineer, and that self-identification hinges on both emphasized points above. First, I’ve spent the time to learn all the pieces. Other people don’t see all the late nights, banging away on my home lab, or my church’s setup, forcing things to work when they didn’t want to, integrating pieces all over the stack, setting up solutions to help people get things done, or just to scratch an inquisitive itch.

For instance, I’ve run my own web server on a public address. This will cause you realize how hairy the raw, unfiltered internet is, and will force you to learn about the basics of hardening a server and firewalling a network connection in a New York minute. I’ve run my own email server. That will teach you about spam, attachments, white and blacklists, abuse addresses, and lots of stuff about making your server look legit to other servers. I’ve run a Windows domain for my whole family’s computers, with roaming profiles and everything. (Side note: do NOT use roaming profiles.) I’ve run my own personal cloud. My own mobile sync server. Media servers. TV recorders. The list goes on.

In my professional career, I’ve gotten to work on some of the biggest, baddest tech ever made. I’ve setup a Sun E10000 from scratch. When I took the official Sun training on the kit, I fixed the lab’s setup when it broke. I’ve configured a 384-tape robotic backup system. I’ve commissioned $15M of EMC disk cabinetry. I’ve trained extensively on Oracle, and setup a North-American-spanning network of 20 instances. These technological implementations are fading, now, but the concepts haven’t. We just answer the same questions with different hardware and software these days.

When I encounter a new technology, at this point, it usually doesn’t take long to slot it into the larger context of computing services. For instance, I recently tried to use Elasticsearch for a project at work. While I eventually found an easier way to do what I needed to do, through several weeks of experimentation, I now know what that technology is about, what problems it solves, how it works, and what it takes to implement it. Now I have this tool in my toolbox, and it’s very possible that I will yet use it for a different project. I’m incredibly grateful that I have a job where I can occasionally do a little “R&D” like this, to learn something new, but it takes substantially less time to divert my attention like this, than other people might spend, because of the experience I already have.

Second, I understand the field I write software to support, because I studied it. I think the modern incarnation of the programmer, toiling away in the bowels of a big company — which is most developers, by simple numbers — is the total inverse of this ideal. I have a degree in mechanical engineering. I’m a good engineer, for the same reason I consider myself a “full-stack” guy. I see the big picture, and how everything underneath it contributes to making it look the way it does.

Even more than studying the math and physics, I was drawn to engineering, because that’s how my mind works. When I look at an engine, I notice the systems that are interoperating: the mechanical masses, the fluid flows, the thermals, the electrical connections, the air flow. I feel these things in my gut and see them in my mind’s eye. I understand how all of these subsystems work to produce power and torque, the difference between those two things, and when it’s appropriate to focus on one over the other. To me, it’s the same thing with an IT solution. I can picture the large subsystems working together to make up the final system in my head, and see the servers, the services, the networks, the databases, the networking, and the automation that will be needed to implement it.

In a lot of ways, the training in how to think about a problem in engineering school is perfectly suited to creating full-stack solutions. Start with restating the problem. Get to the heart of the business problem you’re trying to solve. Where’s the friction? State the givens. What do we know already? What pieces of data do we have? How do we get that into the system? Finally, specify what you’re solving for. What are we missing? How are we going to transform what we have into what we want? How will the people who will use the system need the program to work, and the data to be shown?

Most people working in software in my industry have been trained in how to write some code, and that’s about the end of it. They might understand how to write a loop in Java, but they don’t understand how to setup a Java application server, or a load balancer, or a firewall, to say nothing about the database. They also don’t understand how our products work, how they’re designed, or what the engineers working on them need to help them in that endeavor. I find myself in the rather rare position of understanding both halves of this equation. In my 25-year career, I’ve met only a handful of people who can straddle the fence between the physical, engineering problem domain, and the IT implementation like this. In the manufacturing world, we are indeed few and far between.

There’s one other thing I want to talk about, and that this article’s presumption that Javascript is the piece for the front-end, in the jigsaw puzzle that is a full-stack web application these days. I still like Rails’ templates, and, of course, Microsoft is pushing Razor. Javascript enhances both of these things. However, the article hints at how a lot of people are doing the entire front-end in Javascript now, and I find that disappointing. In an aborted effort, I tried writing an application in Java with an Angular2 front end. The amount of duplication astounded me. When you combine this duplication with the fact that Java and typed Javascript are two of the most verbose languages to work with, well, you get a mess.

Using an API back-end and a pure Javascript front-end is, perhaps, the single greatest argument against full-stack development you can make. Given the sheer amount of work involved in separating the front-end, completely, from the back-end, it almost requires two different people or teams. If you sat down, and wrote out the most terrible theoretical idea you could come up with for software development, it would probably look like “write a single application, broken right down the middle, in 2 different languages.” Unfortunately, that’s the nature of web development right now. I lament that this is where we’re at in our technological evolution, but until network bandwidth takes another leap forward, this is what we’re stuck with.

Web Development Framework Trends

Back in April of 2014, I was vacillating between using Ruby on Rails, and Entity Framework on ASP.NET, for a new project. All other things being equal in programming or system administration, I like to sit on the intersection of functionality, for actual productivity, and popularity, for availability of reference material. To check on the relative amount of helpful documentation I could expect to find, I ran a comparison on Google Trends.

April, 2014

Disappointingly, Rails seemed to be losing ground to EF.NET, at least in terms of Google searches. I tried to console myself by saying that Rails was mature by that time, and EF was still struggling to find its niche, which both reflected in the results. Five years later, I stand by that interpretation.

For comparison, I wanted to see what the situation looked like today. Both technologies were trending down since the last snapshot. I took one guess as to why, and this is what I saw.

July, 2019

For the fun of it, I threw in another couple of terms…

July, 2019, with Frameworks

Yikes. The popularity of React and Angular has stomped the axis of the graph. Clearly, Javascript-based front-end technologies have taken over web development mindshare.

I find this state of affairs to be morose. Some time ago, through a series of inescapable constraints, I was backed into a corner to write a new web application in Java/Javascript. Through other, defaulting logic gates, I wound up trying to use Spring Boot and Angular 2, in particular. I found them both to be tedious, laborious, and almost utterly devoid of helpful documentation on the internet. The only consolation I can take from the graph, above, is that React seems to be winning against Angular. I haven’t tried it yet, but it gives me hope that it’s better.

In the end, after literally weeks of reading and searching, I found exactly one, non-trivial example of how to use this stack, and that was only because I sent an email to the guy who seemed to be the chief evangelist of Java/JS on the internet. While that was great, his example was so out of date, I couldn’t reconcile how to translate his approach into modern idioms. Coming from the Oracle/Java world, this stack is intended to be all things to all people, and it shows. There is no commonly-accepted way of doing things with it that people seem to agree on.

If you’re creating some sort of enterprise-y, company-wide system, containing highly-important data, I could see breaking the backend and the frontend apart along language/framework lines, to facilitate having different teams coding them. (Even though the strict typing of a JS frontend is going to drive both sides crazy.) But for a tiny, departmental web app? Containing no sensitive data? That just tracks dates? Which might be used by a handful of people? Using a Java/JS solution for this is like using a nuke to get rid of a gopher in your back yard.

Rails shines the brightest when making small, line-of-business apps like this. Fifteen years after the first release of Rails, there is still nothing in the web development world that can touch it for productivity. Ruby’s interpreted nature — while prone to being slower, compared to typed, compiled languages — is precisely what makes it so easy to use, and so flexible in the role of a database ORM.

It seems that Entity Framework never really got off the ground. Most people writing about it recommend using something else, like Dapper or nHibernate. Dapper does so little for you that you might as well just write text-substituted SQL yourself, and nHibernate is really out of date, so I’d rather just put up with EF’s limitations. And, again, I’m sad, because I’m pretty sure I’m going to get backed into a corner of using ASP.NET for another project. I’ll do my best to make sure it’s .NET Core, for future-proofing, but, for the same reason, EF Core isn’t any better.