Continuing my previous post, let’s pick up the Java story where we left off…
Java 15 (Sept 2020)
Sealed Classes
A nice organizational tool. Not very handy for my personal projects but definitely useful across a large org.
Java 16 (March 2021)
Stream.toList()
Not much else in this release besides this minor but more readable improvement.
Java 17 (Sept 2021, LTS)
Nothing really new here just polish and finalizing things. It looks like this might be the dominant stable version in many enterprises and the baseline for open source right now.
Java 18 (March 2022)
Simple Web Server
This might be very useful for my prototypes. It wasn’t hard to do before but if this works with whatever is a good basic HTTP/API framework these days then it’s great that it’s built-in.
@snippet in Javadoc
I do actually comment my personal code fairly well (if I’m submitting it, even to a private repo) so this seems nice.
Java 19 (Sept 2022)
Record Patterns
I’m only reading some examples of this and definitely want to try it but it seems like it could be pretty clean. It’s kind of like Go interfaces, which I’m a fan of (though I wish they had a different name since they’re flipped backwards in some regards to older language’s interfaces).
Virtual Threads
Very interesting. I do tend to do a lot of concurrency in my projects so I’m definitely going to be spending some time with this one.
Java 20 (March 2023)
Scoped Values
ThreadLocals aren’t difficult per se but they are weird and easy to misuse. Streamlining the easiest usages of them seems like a win.
Java 21 (Sept 2023, LTS)
String Templates
This syntax seems like it might be a little too streamlined for readability, especially on review, but that seems solvable with tools so I’ll wait and see if I like these.
Structured Concurrency
I’ve rolled my own versions of this very useful concept many times so it would be great if this could standardize that.
Sequenced Collections
On the one hand this seems like a nice taxonomic update, but it also seems like it could be easily confused with Sorted Collections, but maybe that’s just me.
Java 22 (March 2024)
Statements before super(…) / this(…) in constructors
Ooh, this seems like it’s a bigger change than it appears on the surface. I have vague recollections of some significant class-layout workarounds for this limitation, but I’m also getting a Chesterton’s Fence vibe here in why this limitation existed in the first place.
Stream Gatherers
A few projects in my queue are data/statistics-based so this might come in handy, if third-party libraries don’t already handle this well enough.
Java 23 (Sept 2024)
Implicit classes & instance main
I never really had any issues with this boilerplate because the IDE always wrote it and it never really changed after that, but it’s cool that it got streamlined.
Java 24 (March, 2025)
Key Derivation Function API
Figuring out how to get signed APIs working almost always feels like it’s harder than it should be, so I’m all in favor of standardizing it. I’m not sure what the long-term impact is here because I’m sure the next great crypto approach will have some structural reason you can’t use this…
Java 25 (September 2025?, LTS)
The next LTS, nothing really major on the menu but a number of finalizations which will be nice.
Final Thoughts
I started this mini research project thinking there were going to be more things like lambdas which I thought were going to maybe take the language away from what I always liked about it, but that definitely doesn’t seem to be the case. There are a ton of streamlined features that work well within the same mental model and “spirit” of the language. I’m really looking forward to digging in and using almost all of them.
After a long hiatus, I’ve been increasingly motivated to do a few tech side projects. Working at Google everything there is Google-specific, or at least Google-flavored, and even if I wanted to use the same stuff I mostly couldn’t. My primary language there is Go, which is fine, but I’m going back to Java, at least for the backend/offline stuff, for now. I’m in the process of picking a stack, and starting with the language.
The last real Java project I did was Java 7, which was already aging at that point but we were going for stability and Java 8 was only a few months old when we started. Java 24 just came out, so I’ve missed 17 versions! I could just jump in but I haven’t really followed the language at all aside from some tinkering over the years and I was probably not really taking advantage of anything new. I think it would be fun to roll forward and read up on each version, seeing the highlights of what each version added or changed.
I’m mostly interested in the language aspects and the core libraries. I’m not that concerned with things like GC versions and improvements. Those are very important but for my hackery it’s unlikely I’ll need to get that far into the internals. Also, I’m going to discuss preview features mostly where they first appeared, not the iterations and finalizations in subsequent releases.
Java 8 (March 2014)
Lambdas
Now I remember why we didn’t upgrade, lambdas seemed a bit daunting and I don’t know if the tooling (Eclipse + Lombok at the time) had really caught up yet. I’m still not a huge fan of lambdas in any language, I think they are nice shortcuts but I’d prefer cleaner-delineated blocks. In JS where I use them the most I almost always define a function separately and then reference that, unless it’s just a line or two.
Type Annotations
I love annotations when used judiciously, @NonNull seems cool but I could see it getting out of control so I’ll have to wait and see how it’s used in the real world.
Optional
I’ve used this a lot in C++ and it definitely fits my be-explicit style.
Streams
A companion to lambdas, these will look strange at first but i use this pattern a lot in JS so it will probably feel right eventually.
Java 9 (Sept 2017)
JDK Modularization
This looks like a big deal, but probably more on the enterprise level than personal projects.
Very nice ergonomics, looking forward to that especially for hacky prototype stuff.
Java 10 (March 2018)
Local-variable type inference (var)
Lombok had this but I didn’t use it too much. It’s really dependent on your tooling, as it adds complexity to refactoring which is one of the things I loved most about Java (and hopefully holds up!). I’m curious how this looks in real code.
Unmodifiable collection copies
More ergonomic polish that I’ll likely be using for hacking things up where hardcoding is common.
Java 11 (Sept 2018, LTS)
Looks like this was the first true LTS vesrion? Nothing groundbreaking on a language level, just some ecosystem cleanup.
Java 12 (March 2019)
Improved switch
Kind of cool. Looks like a strictish lambda variant.
Java 13 (Sept 2019)
Text Blocks
Pretty good, basically parity with most other languages at this point.
Java 14 (March 2020)
Records
Interesting. I always preferred a pretty clean “bean” structure and used Lombok for the boilerplate so this probably wouldn’t make my code look that much different but it’s always nice to be able to build on core concepts instead of just conventions.
Pattern Matching for instanceof
Makes sense. I found that needing to introspect/cast (since generics) was almost always a failure of the APIs involved but sometimes they were still unavoidable. I used them when trying to make things more magical and automatic and bury complexity behind a clean interface.
Helpful NullPointerExceptions
OMG how did this take 14 versions to happen.
Thoughts So Far
So that was about 6 years and some pretty decent improvements overall. I don’t want Java to go the way of C++ and just get more and more complex with a never-ending stream of new ways to do things, even if they are probably better. I like my Java to be boring and predictible, very easy to read, very easy to refactor, and very easy to hand off. Not all of these are great for that, notable lambdas and type inference but we’ll see how it goes.
It’s been a long time since my last post about technology, and in the meantime AI happened (again). It’s dominated the conversation, even beyond the tech crowd, since ChatGPT was released. Budgets and strategies at many companies have been massively disrupted echoing earlier booms and bubbles but adding its own unique attributes as well. I’ve got a number of things I’d like to share here and in the future, but I’ll start by saying I’m generally optimistic on this, especially long-term, for a few reasons:
It’s Exciting
I started my career in the “dot com boom”, when the Internet left universities and infiltrated almost every nook and cranny of the economy and people’s lives over the next 10-15 years. There were new developments daily, for years on end, even after the stock market blew up. Disruption and innovation was constant. It felt like a once-in-a-lifetime kind of thing, even in the moment. Nobody expected it to last forever but nobody knew when it would end either.
The AI boom isn’t quite at the same level, but it’s closer than I thought I’d see again. There are new tools and techniques coming out very frequently. There are vast sums of money being invested in many areas. There are new skills to learn, new toys to tinker with, new styles of craft being developed.
One big difference is that during the Internet boom most of the money was going into people. Anyone remotely employable could get a job writing web pages that paid far more than anything else they could do. This time, far more of the money seems to be going into power and compute, in part because that’s an important part but also because there’s a pernicious fixation on automation and displacement rather than the focus on leverage that the Internet fostered. This makes it more of a high-stakes kind of excitement but it’s still excitement.
It’s Important
Since the Internet we’ve seen a number of hype cycles of all sizes offering varying combinations of transformation, enchantment and value. Mobile, social, crypto/blockchain, big data, voice assistants, IoT, VR, 3D printing, smart homes and so on. Most of these are durable but a generation from now they will all be distilled in a few turning points at a cultural level, and the rest will only be remembered as significant within specific industries. I think mobile & social have been truly transformative culturally; they’ve deeply affected politics, friendships, families, and communities. With that one exception I think all of the other trends could be eclipsed by AI’s impact on our lives, economies, and future.
The key vector for that statement is agency. And not in a buzzwordy “agentic” way, but in the sense that vibe coding a TODO app is a tiny taste of the direction things are going. More people are going to be able to do more things, and in a rare violation of deeply held beliefs, they’re going to be able to them better, cheaper and faster. Distributed agency is a massive threat/shift for a global economy that’s been shifting towards services for decades, and it’s going to be a bumpy ride but I think in the end it’s going to be a huge boon. Once more people start to really push boundaries and leave the routine work behind for the robots, we could see an improvement in innovation and new ideas.
This is where the “pernicious fixation on automation and displacement” I mentioned above seems short-sighted and wrong to me. If you have a tool that makes your employees more productive, and you choose to do the same thing with fewer employees, you’re doing it wrong. If you’re running your business properly, your employees should now be making you even more money, so why would you lay them off? I’m not saying this is a trivial change and of course there are lots of details and nuances, but I see far fewer people thinking about growing the metaphorical pie than those who think it’s a fixed size.
It’s Inevitable
This is not the “use AI or become obsolete” pitch that many are making, but more about the fact that it’s here to stay. While the latest and greatest models require billion and trillion dollar companies, the trailing edge of self-hosted/open-source models and systems is keeping up at an impressive pace. Even if OpenAI and Google and Anthropic disappeared tomorrow, we’d still have a large fraction of the capabilities available to us.
“This is the worst it will ever be” is a mantra you might hear from AI fans and I think it’s mostly true. LLMs and RAG and “agents” and whatever FotM we’re excited about now may not be relevant in 10 or 20 years but the thing that will exist will almost certainly be better. We don’t have to use it, and we don’t even have to like it, but we can’t ignore it. If you work with any kind of information and are anywhere but the very end of your career, you should have a plan that addresses, if not includes, AI.
It’s Interesting
Finally, it’s personally relevant to me because it’s just something I think about a lot. Suck.com’s “shiny vs. useful” chart is one I come back to again and again, and AI is both. Not Sun/fire level but still very positive on both of those axes. The fact that it has a huge overlap on my own work in software and tech, and the points I made above, mean this is just too good of a topic to not geek out on. I hope to share more thoughts here in the future on both the positive and negative aspects.
So the side project I mentioned a few posts ago is still just an idea, before I start building it I will need to pick a stack. I’ve been out of the non-big-tech loop for a while (one of the main drivers for this project) so this may take a while, but should be a fun experience.
The last time I picked a fresh stack was late 2013. We were building Mondogoal and needed to get to market very fast on a limited budget. We started in late November 2013 and needed to be in beta by March, and ready to launch (and get a gaming license!) in time for the 2014 World Cup that started in June. With two developers.
Somehow, we made it, and I think that one of the main factors was in how we picked our stack. In short, we kept things as boring as possible. The backend was all stuff I could do in my sleep: Java 7 with MySQL, using Maven and Spring, running on Tomcat in a mix of AWS and Continent 8. The only significant piece that I didn’t know well was Obsidian Scheduler, which is a fairly lightweight job scheduler, and we added Firebase later on. The frontend was backbone with a grunt build, which had been out for a while. This stability and going down well-trod paths let us focus on executing the business and product instead of tinkering and I doubt we would have been able to hit our deadline if we’d opted to explore some of the cool new stuff that was coming out. While the business didn’t succeed long-term, I have no regrets about those choices and can assign no blame to what we built it on.
Luckily, this new project has no deadline! It’s mainly a vehicle of exploration for me. I would definitely like to launch it, but if that takes months (unlikely) or years that’s OK. Let’s recap the “requirements” of this project:
Learn how to build a modern front end.
Give me a reason to explore the Google Cloud offerings (since those products are effectively my customers for my day job).
Get back up to speed on things like analytics.
Scratch an itch I’ve had for a long time (a nerdy economy-based game).
Doesn’t risk any conflict with my day job.
Give me something to blog about!
#2 is going to make some of these decisions easy. As a loyal dogfooder and company man (despite the lack of employee discount…), I will default to Google Cloud where possible. A quick check puts most of the basics on par with Amazon as far as cost goes. If GCP doesn’t offer it, then it’s up for grabs. Let’s start picking!
But wait…what is and isn’t part of The Stack?
I take a broad view of the term, to me The Stack is basically everything in the shop. You could (and I might in a future post) break this down into groups (tech stack, marketing stack, etc.), but to me if it’s a part of making the business run and it’s something you didn’t build yourself that you expect employees to get or be skilled at, then it’s part of The Stack. This includes everything from Java or Python to Salesforce and Gmail.
Domain Hosting
Winner: Google Domains
Cost: $14/year
Status: Up and Running
Initial Thoughts
I’ve got domains hosted at lots of places. GoDaddy, Namecheap, Hover, OpenSRS, I even still have one at Network Solutions. Compared to those, registering on Google was a pretty painless process. The pricing is more transparent than most other places (no first-year rates that go way up later). They also didn’t upsell junk I don’t need too hard. Setting up G Suite was also pretty easy (as you’d hope), I had it all running in like 15 minutes without touching any DNS entries.
To dogfood even deeper, I’m using a .app TLD, which Google owns, and was a few bucks cheaper than the other registrars.
Email Hosting
Winner: G Suite
Cost: $5/user/month
Status: Up and Running
Initial Thoughts
As most of us are, I’m pretty familiar with all of these tools, and I’m pretty sure most surveys would have Gmail at the top of people’s preferred email services. As a bonus, setting this up was super easy since the domain is also with Google.
Compute Servers
Winner: Kubernetes/Compute Engine
Cost: TBD
Status: Exploration
Reasoning
There were two things that came up in virtually every conversation/interview I had during my last job search, React and Kubernetes (AKA K8s). Virtually everyone was using these or trying to move to them. I’ve never touched K8s, so combined with #2 above, I feel like I should play with it.
I have used App Engine, and I assume non-K8s Compute Engine is pretty similar to AWS’s EC2 which I’ve used quite a bit, so I will fall back to those when it makes sense to do so.
Backend Language
Winner: Java
Cost: Free
Status: Defrosting
Reasoning
I am a moderately capable but generally reluctant programming language polyglot. My first employee profile badge at Facebook was “Committed Code in 5 Languages”. But I’ve never bought into “pick the best langauge for the job” and tend to favor the approach of “pick the best language for all the jobs”. This offer does not extend to JavaScript backends.
Java was my primary language from probably 2000 through 2016. Since then I’ve mostly been writing C++. I’ve grown to like the language, it is lightyears better than it was when I started writing Java, but I’ve never worked in it outside of the padded walls of FB/Google’s infrastructure, and to be honest, am not terribly interested in doing so.
While we upgraded our runtimes to Java 8 at Mondogoal after a bit, we never got around to really using any of the features, so I’m effectively only up-to-date through Java 7, and would like to explore the recent additions. There are also some new parts of the Java ecosystem that are worth exploring, like Quarkus and GraalVM.
Also, I just kind of miss working in it.
Runners Up
There are two languages I am interested in tinkering with, once I’ve warmed back up on Java: Kotlin and Rust. They both have had a pretty good reception and have some attractive features. Kotlin as a JVM language should be easy enough to experiment with. If I can find a task that would benefit from Rust I will probably give it a shot.
IDE
Winner: IntelliJ IDEA Ultimate
Cost: $149/$119/$89 for years 1/2/3+
Status: Trial
Reasoning
I initially wrote Java in emacs, then JCreator, then switched to Eclipse c2002 and used it through 2016. I’ve tried IntelliJ a few times over the years but never really got the hang of it or saw a lot of value in it.
However, Google does quite a bit of Java work, and their primary and only fully supported IDE for it is IntelliJ. I’ve also been using CLion (basically IntelliJ for C++) and it’s been OK.
The “Ultimate” edition of IntelliJ includes support for other languages and even React so that’s a strong argument in favor of trying it out. I’m not opposed to ultimately landing on using different tools to work in different languages (e.g. I often used Eclipse for Java and Sublime for JS), but if you can do it all in one, that’s nice.
My Eclipse muscle memory is very strong, so I expect this to be somewhat painful transition, but I will give it as fair a shot as I can manage.
Java Build
Winner: Gradle
Cost: Free
Status: Exploring
Reasoning
There are only two real choices here: Maven and Gradle. And given that Gradle uses Maven-style repositories, they aren’t even that different in many respects.
Maven
I’ve used Maven for many years, since Ant, and like most people had some struggles with it initially. I eventually learned to coexist with it, or at least avoid its sharp edges, and would just copy/paste my pom from one project to next and had minimal issues.
Gradle
Gradle has three main “advantages” over Maven that people seem to crow about.
One is that it’s written in Groovy, and you can therefore script your build and do advanced stuff more easily than writing a Maven plugin. I would put this in the Probably a Bad Idea category, like stored procedures. I bet there are some cases where this is useful, but probably far more where it’s a kludgy workaround to some other problem people don’t want to solve.
The second is that it’s written in Groovy, which is not XML. I always thought XML was nice when used properly, and that config files were one of those proper uses. However, something about it causes a primal aversion in many people and they convince themselves that things that are not XML are inherently better than things that are.
The third is that you can do different build versions more easily, and this one I get, especially in the context of things like Android apps. Given that I might be targetting different JVMs (regular and GraalVM) this might be useful, but probably won’t be.
So I’m not really impressed with Gradle either, but given that there are literally only two choices, I might as well know both. It’s pretty trivial for a small project to switch back or even run both, so this is a pretty low-risk experiment.
Source Control
Winner: Git + Monorepo
Cost: Free (plus hosting)
Status: Up and Running
Reasoning
I think there are only 3 real options these days for version control that don’t fall into the “never heard of it” category for most people.
Git
The dominant force, and the only one that many developers know these days.
Mercurial (hg)
I have grown to prefer Mercurial in a code-review + monorepo environment since starting to use it at Facebook. Implicit branches and easy commit management map very well to the “commits should do one thing” best practices as opposed to the pull request pattern where mainline commits should favor comprehensiveness. For a solo project this isn’t relevant and it’s basically the same thing as Git.
Subversion (svn)
For solo/small teams, SVN is totally fine, it’s basically how you’d be using a DVCS anyways, but if you don’t have a server running already then it’s probably not worth setting one up.
Mono vs. Multi Repo
For large organizations, monorepo is the clear way to go for reasons I can discuss elsewhere. For solo/small teams, it doesn’t really matter, and it *might* be better to split up your repos if you have a *very* clear separation (e.g. front/back end), which is how we did it at Mondogoal, but I would say to start with a monorepo and only split if there is a compelling reason to do so (e.g. regulations, licensing).
I’m going to call this a toss-up between Git and Mercurial and give Git the edge due to the fact that it’s massively more popular and more likely to integrate well with other things like IDEs and deployment tools.
Source Control Host
Winner: Google Cloud Source Repositories
Cost: Free to 5 users & 50GB storage/egress, then $1/user/month and $0.10/GB/month
Status: Exploring
Reasoning
Given that I’ve chosen Git, GitHub is the obvious first choice here, but since Google has a product we’ll invoke requirement #2. This also might integrate better with the other services I’ll be using, though I have barely researched that beyond the marketing.
One of the nice things with Git is that it’s trivial to multi-host, so if I ever find a compelling reason to also use GitHub, I can use both or just switch.
Next Up
There’s a lot left to do here, databases, frontend, and more. Stay tuned!
When starting a new company or project, one of the most daunting phases is selecting a stack. There are lots of things that factor into the decision, and anyone who has done this before will attest that you will make some bad choices, and some of those will be nearly impossible to undo, especially if you’re successful. Some questions to consider:
What do you already know/love/hate?
When considering your options for some piece of the stack, it is totally reasonable to award points to things you know and love, and deduct points from things you know and hate. It is, however, not a good idea for this to be the principal factor. You should be able to defend your favorite choice against the others objectively and quantitatively, not solely on the basis of “it feels better” or “I know it already”.
Are you just trying to execute a business/goal or are you trying to explore and learn something new?
One of my two virtues of engineering is curiosity. Throughout your career, you should always be looking for opportunities to explore new ideas, new tools, new methods. If this is some moonlight or passion project, actively try to weight new and unfamiliar things higher. If this is a major venture with lots of other people’s time and money, there is just as much to be gained from leveraging your experience and going for flawless execution of things you’ve already worked out the kinks on.
If you have teammates, what do they know/love/hate?
This is a case where you should set the hierarchy aside and try to get everyone’s opinion. If you’re a senior engineer or architect you can bring experience to the table but don’t discount the novel approaches and backgrounds of your teammates, regardless of their experience. We so often get stuck in our ways, even after only a few years, and avoid novelty and diversity in the name of risk.
Are you going to need to hire/outsource the work?
If your plan involves getting dozens or hundreds of people on board in the near future, you’re going to want to lean to the more popular/vanilla options. Trying to hire 300 people in the next 12 months to work on your Erlang/Neo4J stack running on an Arduino cluster is going to be much harder than getting people to do Java/MySQL on AWS.
Are you building a prototype, an MVP, or a “real” version.
Deciding, and more importantly understanding what you’re building is a topic worth exploring on it’s own, but roughly speaking you’re building one of three things:
The Prototype
You just need to get something “working” to explain your idea or your solution. Unless you’re doing something truly revolutionary (p99.999 confidence spoiler alert: you aren’t), try to prototype your idea/business/product OR your technology, not both at the same time. Also really commit to throwing this away and starting over with a proper plan if there is promise. I’ve seen/had too many prototypes turn into projects that have a pile of technical debt before they even really start.
The MVP
I feel the MVP is overused, and too often is an excuse for a poor quality product or a starved team/budget. You obviously want to iterate, and if you want to call your first release an MVP for buzzword sake, go ahead, but don’t write throwaway code unless you’re committed to throwing it away (see prototype above). I’ve lost count of the number of companies and projects I’ve talked to that are rewriting their Rails or Django app because those seemed like easier paths to an MVP and “now we just need to scale”. That’s like saying “I’m going to get a job, but then I’m going to go and get a completely different job that actually pays my bills.”
If you are truly building an MVP, then your process for stack selection is no different than building the real version, it’s just prioritized more aggressively.
The “Real” Version
The first step here is to figure out, as best as you and your team can, what the successful (often AKA profitable) version of your app/system looks like. Do you need 100 users to break even? Do you need a million? If you need a million, don’t spend a single minute building something that only works for hundreds. If you need 100, don’t spend any time building it for 1 billion (unless you get that for no additional work, E.G. something like Amazon S3).
What features are truly required to hit that goal? Make sure there is a place for them in your architecture even if you don’t plan to build them right away. Do you need support and sales teams to be successful? Make sure you’re putting hooks in for the tools they will need (E.G. CRM, ticketing, admin consoles).
What can you get “for free”?
Everything has a cost, in terms of time, money, people, etc. but those costs are not always the same across companies and projects. Your team’s experience can discount learning curves, your company may already have investments or licenses for things. Never use something just because it’s free, but make sure that is a part of your decision.
If you’re at a larger organization with a number of teams, consider if there is a team supporting certain aspects of what you might use. If there is a logging system that is in place and ready to go and has its own support, it’s should be a hard sell to build or buy or set up a new one just because of a few features. Often that team will even build what you need!
What are your competitors using?
Competitive analysis can be difficult, most software companies don’t go too deep on what they are using for any given situation, but that information can play a large part in your decision. If you find a conference talk where they talk about what they tried and had good or bad results from, you’ve possibly just saved yourself a lot of pain. You will often just get a lot of good ideas (“I never considered using X to do Y”), or pointers to things you’ve never heard of.
You might also find some competitive advantage. If they are using something you know is difficult to change or won’t scale well, make sure yours can beat them in those aspects. By the time they realize you’re about to pass them it might be too late for them to adjust.
What will fail first?
As you’re building your stack, know where the weak points are, and don’t be shy about circulating that information. If you can’t get to your target latency because some component will use 90% of that budget, try to find a replacement early rather than assuming you can plug something else in later. You should be confident that all of your core components can hit your targets, and if you aren’t sure, validate that now. You’ll find that the interconnected nature of systems will often lead you to replacing more than one piece at a time, which only makes it less like you’ll be able to do it, and more likely to fail.
What else?
Picking a stack is harder, and takes more time, than most people realize. I’m sure there are other things to consider and I’ve love to hear your thoughts on this in the comments.
I’ve spent the last few years sequestered away in “big tech” which has been an interesting and mostly positive experience, but one of the more unexpected side effects, especially as an extreme generalist, has been the specialization on the technical side of things.
From when I first started coding for money in the mid 90s I was always a true “full stack” engineer, even before that was a term. Give me a bare server and a sketch and I could handle the rest, even some basic UI design. As backends became more complex and interesting I gravitated that way, but was still pretty up-to-date on front-end technology for a nearly 20 year stretch.
The front end world got increasingly difficult to keep up with on a casual basis as single page apps became a thing and powerful frameworks took over. At Mondogoal I was entirely back-end from late 2013 onward, although I was also the product owner and oversaw design and branding. At Facebook I worked on maps and geocoding, writing mostly backend C++ code. At Google I’m deeper yet, working on the networking team.
During my last job search I initially still had “full stack” on my resume, but realized that I didn’t think I met that bar any more, namely because I didn’t really know any of the things most people were using these days, like React or Angular. My skills in that area, (e.g. jQuery), are no longer in demand at places I’d want to work for, supplanted by experience with scalability and distributed systems.
And don’t get me wrong, I have no regrets about this, at all. Back-end experience and knowledge decays much slower than the front-end, so now that I’m often the oldest person in the room, that’s a feature, not a bug. Back-end work also tends to pay more and offer more paths to leadership roles. But I think I’m still a full-stack developer at heart, and the deeper I go the more wistful I get for being able to make something you can see and touch.
Enter, the Side Project
I haven’t had a software side project in years. With all that’s been going on, especially becoming a parent, my energies have been allocated elsewhere. But there’s been an increasingly more noticeable hole there that I need to fill.
I brainstormed a few ideas and kicked them around until one of them, a browser-based game, settled out that checked off most of the boxes:
Learn how to build a modern front end.
Give me a reason to explore the Google Cloud offerings (since those products are effectively my customers for my day job).
Get back up to speed on things like analytics.
Scratch an itch I’ve had for a long time (a nerdy economy-based game).
Doesn’t risk any conflict with my day job.
Give me something to blog about!
Now what?
I’m going to talk about this in more detail in a future post but after spending a bit poking around the current front end world, I feel like I’m basically starting over. React, Angular, Vue. Yarn, webpack, JSS. The list goes on and on. Even my JavaScript is out of date, with all of the additions over recent years, and TypeScript being a serious option now (it was still kind of a toy last time I tried to use it back in 2012/2013).
This is a bit intimidating, but more so exciting. There’s so much to learn I haven’t even really started to think about the actual project or how feasible it will be to launch. Stay tuned for updates!
I completely agree with the headline of this blog post, but not with the overall sentiment. Driverless cars are going to change the world, and for the better. I’m not sure how much they will do so in my lifetime, it’s hard to believe that anyone born before 1985 or so is going to completely trust them.
The car insurance industry will cease to exist. These cars aren’t going to crash. Even if there are hold-outs that drive themselves, insurance would be so expensive they couldn’t afford it, as no one else would need it.
These cars will crash. For as long as humans are allowed to drive, they will be causing accidents, hitting other driverless cars and each other. There are also a number of causes of accidents that are still going to happen, such as those involving wildlife or severe weather or mechanical failure. The robocars will handle these situations far better than humans, but they will still happen, and people will still be injured and killed as a result.
If the cars don’t crash, then the auto collision repair / auto body industry goes away. The car industry also shrinks as people don’t have to replace cars as often.
The car industry will likely shrink over time, just as any other technology-driven industry as. They will be forced to evolve to new products. This will happen slowly enough that if they’re properly managed, they should be able to shrink through attrition.
Long-haul truck driving will cease to exist. Think how much money trucking companies will save if they don’t have to pay drivers or collision and liability insurance. That’s about 3 million jobs in the States. Shipping of goods will be much cheaper. On that note, no more bus drivers, taxi drivers, limo drivers.
This is definitely true. I bear no ill will towards professional drivers but I think we can find jobs that are more rewarding for people than driving goods or passengers from point A to point B, and often drive back to A with an empty truck. Trucks also account for the vast majority of road wear, a single tractor trailer can do as much damage to a road as nearly 10,000 normal cars. The main reason we load so much weight onto a truck is so you only need one driver. It will be more efficient to send smaller loads by robotruck, as they can be better targeted (think one truck per state rather than one truck per region), which will result in smaller trucks.
Meter maids. Gone. Why spend $20 on parking when you can just send the car back home? There goes $40 million in parking revenue to the City of Vancouver by the way.
Considering much of that revenue is probably supporting the collection of that revenue (meter maids, infrastructure, towing, courts,etc.) I don’t think this is a net loss. Also, fewer parking spots means more pleasant streets with less traffic problems.
Many in cities will get rid of their cars altogether and simply use RoboTaxis. They will be much cheaper than current taxis due to no need for insurance (taxi insurance costs upwards of $20,000/year), no drivers, and no need for taxi medallions (which can cost half a million in Vancouver). You hit a button on your iPhone, and your car is there in a few minutes. Think how devastating that would be to the car industry. People use their cars less than 10% of the time. Imagine if everyone in your city used a RoboTaxi instead, at say 60% utilization. That’s 84% fewer cars required.
Absolutely!
No more deaths or injuries from drinking and driving. MADD disappears. The judicial system, prisons, and hospital industry shrink due to the lack of car accidents.
Let us hope that we don’t see MADD exhibit the Shirky Principle (“Institutions will try to preserve the problem to which they are the solution”) and simply fades away to an irrelevance we can all agree is a success.
Car sharing companies like Zip, Modo, Car2Go are all gone. Or, one of them morphs into a robo-taxi company.
I think they will definitely be robotaxis, but there will also be a need for specialty cars like pickups. We may even see an increased diversity of car designs available for rental where you can have a special grocery-mobile sent over, or a van with 12 seats, or one with extra entertainment options for your long trips, and so on.
Safety features in cars disappear (as they are no longer needed), and cars will become relatively cheaper.
Very unlikely, as people buy fewer cars and use them less frequently the prices will go up accordingly. We’ll also probably require, through legislation, even more safety features, simply because of an inherent distrust of the technology.
I’m really hoping that robocars are a reality within the next 30-40 years when I will be at the point where I shouldn’t be driving any more, and I’m happy to see that we actually seem on track to do that.
Amazon caught a lot of heat over this past holiday season over some improvements to its shopping app. It made it easier than ever to find out that you probably don’t need to buy that blender at Sears, when you can get it for 30% less on Amazon and don’t even have to carry it home. There were cries that small businesses can’t compete with this and would all be dead soon.
There is nothing at Best Buy or Barnes & Noble that you can’t get on Amazon (or many other online stores). It’s rare that it will not be cheaper online, even during a sale (which typically just brings the price down to a normal online price). Is it sustainable to have a store where I can go and hold something, and then order it from somewhere else? No. Should we feel bad for the big box stores? No. Should we feel bad for the shopkeeper who sells a particular niche at a high markup without adding value? No.
Stores that only sell commodity products are a recent innovation to take advantage of a temporary imbalance. They will eventually go the way of dodos, video rental stores, and record labels. We’re still going to have a few, because there are enough “need it now” purchases to sustain the Targets and Wal-Marts, and we’ll probably still have a few high-end ones where excellent service matters like Nordstrom, but most of the stores out there are turning into showrooms.
What if Amazon bought BJs?
(BJs is a consumer warehouse/bulk goods store, like Costco and others). My Prime membership takes the place of my BJs membership. Instead of walking around with a giant shopping cart and driving home with mass quantities of things, I simply browse the aisles for products I like. When I see one, I scan it with my phone, and it’s on my doorstep the next day. There are a few people on staff that might help, and there’s a hotline to specialists that understand the products and can answer my questions. No need for a massive loading-dock infrastructure, or inventory control, or 50′ tall ceilings to heat, or many of the other overhead expenses that yield the current retail markups.
What about the little guy?
I’d like to see our shops go back to actually making things and/or adding value. Custom products, not “regional dealers”. There will definitely be less of them, but this will make more space and lower rents for the people who just want a spot where they can sell their craft, or for people to provide useful services instead of distribution.
Earlier this year I revisited how I was logging things in Java, and decided I would try a hybrid approach. I’m reporting back to say that it’s been successful. There are basically two ways I do it now:
Use java.util.Logging for libraries
It turns out that there’s nothing actually wrong with JUL aside from its limitations in terms of configuration. It has different names than the Ceki Gülcü loggers (warning() instead of warn(), finest() instead of trace(), etc.) but otherwise works the same. The configuration side of things I can’t even speak do as I haven’t had to configure it, I never use the actual JUL output.
Use Logback for applications
As suspected, Logback is basically just a new version of Log4J. It’s got some niceties like MDCInsertingServletFilter that means I don’t have to write that filter myself anymore, and it’s supposedly faster and more stable, so there’s no reason I can see not to use it. I also like that it has a format for condensing class names without completely losing the package names, so it goes from “com.efsavage.application.servlet.LoginServlet” to “c.e.a.s.LoginServlet” instead of just “LoginServlet”.
Why use two?
I like the fact that my libraries have zero logging dependencies and configuration, so I can always pop them into another app without adding baggage or conflicts or much additional configuration. I can upgrade the logger in one application without having to deal with version conflicts of my other apps and having to do classpath exclusions and that type of nastiness.
Tip
If you do it this way, and you see your JUL logging showing up twice, you can edit the default logging config in your JDK installation, or if you prefer to leave that untouched as I do, try this (via Java Bits):
java.util.logging.Logger rootLogger = LogManager.getLogManager().getLogger("");
Handler[] handlers = rootLogger.getHandlers();
for (int i = 0; i < handlers.length; i++) {
rootLogger.removeHandler(handlers[i]);
}
SLF4JBridgeHandler.install();
This basically yankts out the default logger and let’s SLF4J do it’s thing alone. In a webapp you’ll probably throw this in your context listener or startup servlet where you previously did your log4j config.
A new workstation means it’s time to install lots of stuff, and we’re still a long way from DropSteam. Here’s my log from fresh Windows 7 install in a new VM image to a functional development environment:
Fix the windows service name to something like MYSQL5
Add to windows path
Add a password
JRebel. You’re using this, right? If not, slap yourself and then go get it. Pay for the license out of your own pocket if you need to.
Lombok. I have finally used this on a real project and can say it’s ready for prime-time. It does not work with IntelliJ IDEA but I haven’t really seen any reasons to use IntelliJ that outweigh the benefits of Lombok.
Photoshop Elements because while IrfanView is great for viewing and Paint.NET is great for simple edits, you will at some point need a more powerful editor. Also most designers work in Photoshop so this let’s you open those files directly.
Photoshop Elements+ is basically a $12 unlock of some of Elements’ crippled features. For me it’s worth it for tracking alone.
LastPass is useful even if you don’t store anything sensitive in it, it’s great for testing webapps with multiple users.
I use Git for my own work so we’ll need that. Don’t forget to set your name!
I also make some Windows tweaks:
Set desktop background to black.
Check “Show hidden files, folder and drives”.
Uncheck “Hide extensions for known file types”.
Set %JAVA_HOME to JDK directory.
Add Maven’s bin directory to %PATH
Add C:\bin to %PATH
I will obviously add more over time, but this is the stuff I know I will need. What’s great is that almost all of it is free, and it can all be downloaded (except the original Windows install), so no disks required like the old days
You might think this is an incomplete list, where is my email client, my MS/Open office, my music player? I don’t use those unless I have to. Keep in mind that this is a VM so some of this software is installed on the Host OS, while the rest of it I prefer to use web-based solutions (Meebo, Google docs, webmail) so there’s no issues of having to keep updating settings.
/cdn.vox-cdn.com/uploads/chorus_image/image/55701647/Screen_Shot_2017_07_13_at_1.09.20_PM.0.png)
