Time Tracking Web Apps

I work for a tech outsourcing firm, but I’m fully-subcontracted to a Fortune 250. My company recently switched away from their home-brew time tracking tool (which wasn’t completely terrible) to Workday. The transition was rough. You had to click several times to finish the process, and it was easy to miss. They’ve since changed the workflow, and it’s better, but the site is still laggy. Apparently, Workday is taking over the world, and this makes me sad. It’s not a great system.

The Fortune 250 recently wrote their own time tracking tool, and now I have to enter my time in this second system as well. It’s everything I’ve come to expect from an internal application written by #CorporateIT. It’s slow. Like, really slow. Every time you type a number, it does something in the background, so filling in project numbers takes several seconds. Entering a number for time takes just longer than you expect, so it’s constantly tripping you up. Did it take the number? Oh, wait, it did, and now I have 88 hours in the box. Today, it broke the tab key. So, you know that thing where you would hit 8 and then tab, five times in a row, and be done? Not happening. This is something that you get for free in a browser, which people rely on, due to muscle memory, and the way every other table-based UI works, like Excel. You have to purposely disable this behavior. This strikes me as bizarre, but I guess it doesn’t really surprise me.

I wrote attendance-taking software for my church, which we used for a dozen years. It had features we still miss now that we use one of the main church management software sites. And it was fast. Like, millisecond fast.

I wrote my own home-brew time tracking software for a previous company. The first version sucked. It was slow, too. But, after getting it “in the neck” about how bad it was, at one all-hands meeting, I took the initiative, spent a week re-designing the core of it, and made it fast. Really fast. I profiled it at literally 20 times faster. The owners were happy. And then I wrote a page to do two pivot tables for the time period, one by employee (to write paychecks) and one by customer (to write invoices), and the person who did both of those things was happy too. This saved her many hours every week. That was 11 years or so ago, and the last time I asked, they were still using it.

These systems aren’t really that complicated. This is a well-known problem space, which every company needs addressed. Why are they all so terrible? I think it all comes back to the basics. The people who have to deal with it are not the people designing it, or specifying it. Once a company is so big that this disconnect can happen, I don’t know how it ever gets fixed. I fixed my app because the owner said it sucked, and I fixed it. In a Fortune 250, no one who has the authority to say that the time-tracking app sucks will ever have to use it, or even speak to someone who has to.

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 Sublime Text 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 am pretty sure it specifies 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 is 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/interpretation 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. When I encounter speed problems with using Ruby, I do something else. Either I optimize the loops, or push more processing to the database, or write the heavy-duty computation in something else entirely, like R.

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 “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 the actual implementation, over the theoretical concept. While whole teams of “Java” devs are still writing class files in Java (and Javascript), for their object models, 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.

Build Your Own Database Driven Website

I don’t remember what prompted me to remember this book, but it was, perhaps, the biggest influence which has shaped my career. I had already been a programmer since I was a kid, and I had already written a couple of well-received programs on my job by the time I bought it, but I had actively avoided learning about databases, in order to focus on other Windows and Visual Basic, and I hadn’t gotten long-enough arms to break into web programming until then. Thank goodness, too, as it was all cgi-bin Perl stuff leading up to PHP. Yuck!

Reading books on programming is never fun for me. I’ve tried to read a couple on Ruby and Rails, and I just can’t get through them. The problem is that the ratio of stuff I already know to the stuff I don’t is so high, I can’t slog through it. I get too bored while trying to get to something new to me, and put it down. This book, however, hit me right between the eyes. It was the perfect book for me at the time. It was very thin, and there was zero fluff. I rewrote my FrontPage blog site in PHP in a week with the help of this book, and I was off and running. I’ve been doing primarily web app programming ever since.

Anyway, I just am fond of the memory of this book, Kevin Yank, who wrote it, and SitePoint, which was started around these books. This version is old and out of print, of course, and he seems to have retired now. If so, good for him. Thanks, Kevin.

What I wish I had known about single page applications – Stack Overflow Blog

I settled on JHipster, a development platform for building web applications using modern technology: Angular, React or Vue for the client side, and Spring plus Gradle or Maven for the server side. It’s been around for years, is very well documented, and has great community support.

Source: What I wish I had known about single page applications – Stack Overflow Blog

I think the author hit at least one nail squarely on the head: Team size is an important consideration for the tech stack. I would argue that a Java/Angular stack is probably only appropriate for large teams, which wouldn’t need jHipster anyway. I tried it once, and it took FORTY-FIVE minutes to bootstrap a site on my top-of-the-line Dell laptop. There are an astonishing number of moving parts buried inside of it.

I’ve been using Rails for 15 years or so now, and one can argue about its strengths and weaknesses compared to other webdev toolkits, but it works really, really well for one-person “teams” writing highly-focused internal tools. I’ve spent the past month writing a single-page app in VueJS inside of my current tool, and it’s been an interesting experiment. I may have more to say about it later.

CADT Model in Action

JWZ, the arguably-most-infamous developer of Netscape, has a theory called the CADT: Cascade of Attention Deficit Teenagers. I got an email this morning as another example of the model in action.

I posted the problem to serverfault.com and opened the bug report. In my opinion, it was a good example of a fully-documented bug, which was easy to replicate. In their bug system, there were 12 “upvotes” of people saying that the bug was affecting them as well. Today, 6 years and 4 months later, the person the bug was assigned to is asking a rhetorical question to document that it’s going to be closed because the version of PHP it applies to is being sunsetted.

I still have no idea why an unavoidable bug in the stock PHP install in a major distribution didn’t cause more of a fuss, but it clearly wasn’t a show stopper. I don’t remember what I did about it as a workaround, but I guess everyone else did it too. I think I just gave up, and decided that I didn’t need a local dev instance of WordPress for this blog.

My Pre-Ruined Programming Typing

I use a “grip” on the keyboard that’s off-by-one. My right index finger hovers over the K key instead of the J. I can touch type if I concentrate, but this is just how I learned on the Vic-20, when I was 10. I convinced myself a long time ago that this was fine, as it gets me closer to all of the special keys for programming. However, several of the special keys (notably the *, @, and &) were in different places on the Vic-20 and the C64 than on a standard, modern keyboard, and it still occasionally throws me, 40 years later.

Trusty Rusty

I think I lost a programming job because, in the interview, they put me in front of a computer, and I didn’t fly through the editor with nothing but keyboard shortcuts, but it’s my weird typing method that pushes me to just use a mouse for a lot of it.

Software disenchantment @ tonsky.me

Programs can’t work for years without reboots anymore. Sometimes even days are too much to ask. Random stuff happens and nobody knows why.

What’s worse, nobody has time to stop and figure out what happened. Why bother if you can always buy your way out of it. Spin another AWS instance. Restart process. Drop and restore the whole database. Write a watchdog that will restart your broken app every 20 minutes. Include same resources multiple times, zip and ship. Move fast, don’t fix.

That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.

Source: Software disenchantment @ tonsky.me

About 20 years ago, I was working as a Unix sysadmin, and sat in on a meeting about moving an internally-developed application from another data center to mine. It ran on Windows, and died, literally, every day, and required a restart of the whole machine to fix. The manager in the meeting (who, I note, I recommended not be hired, and who was fired for sexual harassment just a few months later) said, “OK, we’ll just schedule it as part of maintenance tasks to preemptively reboot the machine every night.”

I literally snorted. I asked if it were not possible to, you know, actually fix the program? Find the memory leak, or whatever was the problem? I mean, it was written by us; couldn’t we get the programmer to fix their own program? The answer was, of course, no, with the added insinuation that it ridiculous that I suggest that the programmer still had work to do!

About 4 years ago, I wrote a program that helped a lot of people get their jobs done much more easily and efficiently. Per Douglas Adams, “This has made a lot of people very angry and been widely regarded as a bad move.” I was forced to hand the program over to another team, where it has run, with only one tiny patch, for 4 years now. It is not a trivial program, or architecture. To my knowledge, neither the clients nor server ever crash, or need to be restarted. I’m very proud of this.