Author: Shai Almog

I blogged about Java stream debugging in the past, but I skipped an important method that's worthy of a post of its own: peek. This blog post delves into the practicalities of using peek() to debug Java streams, complete with code samples and common pitfalls.

Understanding Java Streams

Java Streams represent a significant shift in how Java developers work with collections and data processing, introducing a functional approach to handling sequences of elements. Streams facilitate declarative processing of collections, enabling operations such as filter, map, reduce, and more in a fluent style. This not only makes the code more readable but also more concise compared to traditional iterative approaches.

The old engineering adage “Don’t touch it, it works” is terrible. Don’t listen to it. It might be OK at a small scale, but as time goes by, the bit rot spreads through your code and servers polluting everything. Large swaths of your system become “no-man's-land.” As you’re developing a new system, you must always “touch it” and make sure we hire engineers who aren’t afraid to do so.

Yes, I get it. I said that sentence frequently in the past. I understand the motivation. Management doesn’t care about the bit rot in our future. They care about the here and now. Why are you wasting time on this feature?

About six months ago, I wrote a piece about the state of open-source commercialization that garnered some notice. Almost immediately after that, Hacker News featured a problematic piece of prose on the front page. The title is “Fix it, Fork it, F*ck off” (censorship is mine). I think this is a great sample of where OSS is failing commercially and as a movement. A lot of the attention in OSS goes into the code of conduct policies (which are important), but not enough goes into what it takes to build a successful open-source project. It isn’t just the coding. I’d argue that coding is often less important than this.

The Clash of Entitlement

I understand where the author is coming from. He’s writing from frustration. We put a lot of work into our OSS project, and an entitled end user can be difficult. I agree some people go over the line, but in my experience, this is less than 0.1% of complaints. It’s rare to have a truly toxic user.

This is it. The debugging book is now live. I would really appreciate reviews and feedback!

I also finished recording and editing the entire course. There are 50 total videos which total seven hours... I also recorded additional videos for the two other free courses for beginners and for modern Java. So keep an eye on those.

I will run a book giveaway promotion on the Code Ranch on January 17th. Be sure to be there and let your friends know. It would be great to answer your questions about debugging. I'm very excited by this and by the feedback I'm getting for the course and new videos. 

I also launched a free new Java course for complete beginners. No prior knowledge needed. This is probably not the audience for this course. But if you know someone that might be interested I'll appreciate a share. I hope people find it useful and learn a bit about Java. I'm working on a cadence of one video per week in this beginner course.

This has been a spectacularly intensive week. The new YouTube channel carrying the course is exploding with subscriptions, and it's just entering its 3rd week. The course website is now live. You can see the entire course there, although I'm adding videos all the time and did roughly 1/3 of the work. Right now, it has 3 hours and 17 minutes of content. I have another hour of content ready to add, and I'm working on several more. I'm pretty sure the course will be well over 6 hours when completed.

I'm also working on some other interesting videos, such as thing one about protecting yourselves from serialization exploits. I'll write a full blog post covering it in the coming weeks.

I discussed tracepoints quite a bit in my blog and videos. They are wonderful, but I feel the nuance of non-breaking is a bit lost. The true power of this amazing tool is hidden due to our debugging habits and our preconceived notions about debugging. It’s indeed difficult to make the mental shift required for these tools. The payoff for that mental shift is tremendous when dealing with “weird” bugs. Especially in large systems and with concurrency related issues.

Let’s go back to the basics. What’s a non-breaking breakpoint?

In the past year or so, people started writing about the phenomenon of quiet quitting. It isn’t new, but it somehow became trendy as more people are doing this. This isn’t something I care about as much. People often describe me as a workaholic, which is pretty accurate, and I love it. But I totally get the problem that triggers quiet quitting and its root is in a lack of loyalty. A cursory reader might think I’m blaming the employee for lack of loyalty — I am. But loyalty is a two-way street and some employees are merely reflecting something that we’ve been conditioned to accept for the past few decades.

Back in the days when I formed my consulting company and later on Codename One, I read pretty much every business management book I could find. Back in 2014, I read a rare book in that genre where I cringed at every page. I don’t enjoy reading business management books. This isn’t a pleasant read. But here I literally cringed at so much of the sage advice from Mr. Horowitz. Notice I don’t say the advice is wrong or even that it’s bad. I don’t think he’s a bad person for giving it either. I think this advice produces its exact desired intention, fast growth at any cost.

We have shared amnesia. When I speak to younger developers about past technologies, I often get blank stares. To be fair, some of that is because I’m a bit “intense” or “weird” but some of that is because. Huh? Really? Did we have that?

Case in point XA transactions and 2PC (Two Phase Commit). We have a young generation that’s completely ignorant of that capability and the fact that this was “a thing”. Did the requirement for transaction management somehow vanish?

In this series, I cover a lot of magical tools and git bisect is probably the best example of such magic. The hardest part in debugging is knowing the general area of the bug, bisect literally shines a light on the specific commit that caused it! 

Before we begin, let’s make one thing clear: bisect is a tool for debugging regressions. It does nothing for regular bugs. When we have a regression, we typically know that the issue used to work in a specific release, we would typically have a specific revision where the code worked. We would typically know that it doesn’t work in the current version, but which commit along the way causes the failure?

Say you have a new code base to study or picked up an open-source project. You might be a seasoned developer for whom this is another project in a packed resume. Alternatively, you might be a junior engineer for whom this is the first “real” project.

It doesn’t matter!

Tom Granot and I have had the privilege of Vlad Mihalcea’s online company for a while now. As a result,  we decided to do a workshop together talking about a lot of the things we learned in the process. This workshop would be pretty informal ad-hoc, just a bunch of guys chatting and showing off what we can do with tooling. 

In celebration of that, I thought I’d write about some of the tricks we discussed amongst ourselves in the past to give you a sense of what to expect when joining us for the workshop but also a useful tool in its own right.