DEV Community: Jan Wedel

Delete All The Codes

Jan Wedel — Tue, 08 Aug 2023 09:15:32 +0000

This article is about is not about writing code, it's about deleting code. Ok, maybe not all the code. But hear me out.

When I was in fifth grade and starting to program, I was fascinated by big programs. .EXE files that had megabytes in file size whereas my programs only had a few kilobytes. Professional programmers are able to write huge programs and that's a cool thing, I thought.

But, there reality is that code is a liability. As soon as you write it, is your team's legacy. A legacy in reality can be something good like a house but it can also be something bad like debts. In software development, it is quite often the latter, unfortunately.

Feed Your Code

One might think that code once written can just stay there for free. It doesn't do harm, right...right?

Code needs to be maintained. It needs love and care to stay healthy otherwise it might break and take your beloved app with it.

There are all kinds of things need to be considered:

Upgrading to a new version of a library or framework that requires code changes
Updating to a new version of the language you use
Fixing security vulnerabilities in your code base
Keeping builds green (timing changes might break things)
Changing requirements might require changes in code that you thought you'd never have to touch again
Changing infrastructure (e.g. new data base) might require changes (especially if the code is not decoupled)

The Best Code Is No Code

Where my younger me had a deep admiration for big program, my older me has learned that code that does not exist is actually the best code. It doesn't need any of the things discussed in the previous section.

I don't have any personal relationship to my code anymore (which is actually not my code by our team's code anyways) and so you shouldn't.

I actually feel happy and relieved deleting code.

Tidy Up

To delete code, I actually follow a couple of practices:

Boy-Scout-Rule

The Boy-Scout-Rule is a general practice of continuous improvement. It basically says: Leave the fire place cleaner than you found it. Or in more technical terms: If you are working on a part of code, try to improve things in the area that you are working on even if it is not strictly necessary for your current task.

That includes cleaning and deleting code. Most often, your editor or IDE will tell you about unused code. Delete it. No excuses. There should be tests covering it, if the code is actually necessary.

Refactoring

Sometimes you start with a new bigger feature and implement it in the most basic way (TDD, wink wink). But as soon as you add new features around that code, it might need some refactoring.

If you did it right, most of the time you should be able to actually delete a significant amount of code. For me, this is like the reward I get when I we did a good refactoring. It let's me delete code. I love it.

Zombie Code

This is a tricky one. You might have code that is used (by tests) but actually not in production anymore. So it looks like it is used but it is actually some undead code disturbing your neighborhood. This is the case e.g. when you have APIs that are covered by unit tests or even integration test but which are not used, neither by a UI nor by customer.

This needs a check from time to time. Could be done as a regular item in a team meeting or task in a maintenance sprint etc. Obviously, you could also explicitly deprecate APIs which are used by customers and mark them for removal.

Time Travel

You might say "But I might need that code!". You might also know the answer. Use your version control system of choice to get the code back. Yes, it might not immediately work but the effort to keep code alive is most often higher. Also, in 99% of the cases, no don't need that code ever.

Conclusion

Keep you code clean and tidy. Delete as much code as you can. Thank me later :)

Cover image by Ujesh Krishnan on Unsplash

Going Fullstack

Jan Wedel — Sat, 11 Mar 2023 22:15:37 +0000

I came from "uhh, I will never touch that frontend thing" to being a passionate full-stack developer.

I'd like to explain why I love it and to encourage other devs to try it. No matter if you are currently frontend or backend-only.

But let's have a quick look on where I came from to give you a change to understand my reasoning behind this. I worked with all kinds of languages but I started my professional career in 2007 as a Java developer, writing software for both embedded and backend systems.

And this is what I did basically until roughly 2017. At that time, I was working in a team consisting of only backend engineers. When there was the need for some frontend work, we had to basically plan this so that one guy from another team would do the work at some time in the future.

Avoiding Bottlenecks

But UI got more an more important and that got more and more of a bottleneck. Actually, nobody really wanted to do it but one member of our team finally volunteered to get her hands dirty and get into frontend after all. Frontend was viewed as both too trivial as as well as too dirty in terms of code quality.

But there we were. We had one frontend dev in the team. And it was quite a success as we didn't have to rely on someone from outside the team. However, also that person turned into a bottle neck in our team pretty quickly when we worked on more than one feature at a time that required UI.

So we knew that something has to change. So whenever we hired someone new, we made sure that person would be already full-stack or at least interested in learning it.

We were working on a product that allowed storing, monitoring and analyzing a lot of data in an industrial domain with a high degree of inter- and reactivity in the web application. In 2017, the existing frontend tech-stack was AngularJS. The code quality was actually pretty bad (as we assumed), the code was neither readable not maintainable. But after some time, Angular with TypeScript was introduced. For me, this looked very much like Java and Spring Boot so I felt at home immediately and were interested in learning it to help achieving our team goal to go fullstack. Also, now beeing more involved, we tried to apply clean code principles and boy-scout-rule every time we touched existing code.

As a result, it was a lot easier for our product owner to prioritize user stories by just business value and not having to think about if the UI and backend devs are available at the same time or even split user stories in non-sensible frontend and backend pieces.

It just worked out pretty well.

Piece of Cake

So remember, I thought frontend development was piece of cake but boy, was I wrong. Building a complex web application with lots of interactive charts, live data and much more was actually a lot more complicated and tough to get into. The abstractions for reactivity in the UI (e.g. rxjs) were hard to comprehend (I still think, that it is not the best abstraction as it is a domain specific language on top of the actual language that you have to learn and understand which is bad IMO). Also styling was tough, tougher than it should be. I always wonder why this is so unnecessarily complicated if you know how you want it too look like and you cannot simply express this with a few understandable steps. We had common components but we needed to build a lot of custom components and thus custom styling was needed.

But let's not get into the specifics here. I guess the web was just not build for applications, I guess. Bottom line is, it took me way longer to get half-way decent. I would still not consider myself as a UI expert but I can get stuff done.

Why it's fun

Now, if you are currently backend-only, you might ask yourself: "Why the fuss?".

My honest answer is: Because it's fun. It is fun in a couple of ways.

First, it is really great to see stuff getting alive that you just built. To interact with your code. You add that button, click it and something happens. As trivial as that might sound, it's just a lot different than what you experience when doing backend only.

Second, it's just great when you implement a feature and you can jump back and forth between front- and backend code. Need to change the model? Just do it! Want to add a field here that makes building the UI easier? Just add it. Boom. No need to ask someone else. No need to discuss APIs, data formats with "the frontend dev", write it down somewhere and then annoying that persone when you need one or two changes. You can also decide, whether it's easier to compute something in the backend or do it in the frontend, depending on the use-case. This is even easier when working with a monorepo containing both backend and frontend.

As full-stack usually also includes operations (or if you like buzzwords: "DevOps"), it is also great if you can just connect to the cluster, because, lets say the dev environement is not working. You look at the logs, fix that DB migration issue quickly to eventually get your new UI feature online and test it. No more waiting for someone to fix it and being blocked.

I think all the arguments are equally valid if you are a frontend dev. It will help a lot if you understand where data comes from, how the data is stored, why there are things that are easier in the backend or vice-versa.

I believe that you end up in writing better software with less compromises.

Jack-of-all-Trades

One downside of going fullstack is that you probably will not be able to have all the knowledge in both width (knowing different technologies) and depth (knowing all details). But, that is not a big issue as you are not the only one in the team. There will we usually be people that like to focus more on frontend, some will have knowledge in the backend, data bases or operations. In our team, we usually work in pairs or a mob, so there is always someone you could ask if you or StackOverflow doesn't know. Having a couple of different T-shaped developers (known a broad number of technologies with one or two focus areas of expert knowledge) in the team works pretty well as for 80% to 90% of the tasks, you don't need expert knowledge.

Also, not everyone in the team might be willing to invest team in expanding their knowledge and go fullstack. That is something that the team need to respect. No one should be forced to do it. One way to get them on board is to regularly pair/mob with them working on stories that require both backend and frontend. That might change their mind.

Tech Stack

As a former Java backend developer, I was used to pretty solid tooling (IDEs, compilers, build tools, debuggers, testing etc.). That changed when learning frontend coding. As web frontend is a much younger profession, slow and fragmented tooling, completely broken dependency management, unstable test frameworks is the result.

Since starting with frontend, I went from JavaScript, npm, AngularJS, Karma, Protractor to TypeScript, yarn, Angular, Jest and Cypress in just one or two years. The backend Java tooling landscape is just a lot more mature and stable.

It's a bit annoying but things are slowly evolving for the better.

Sorry, TDD

If you know my other articles, I am a big fan of testing and Test-Driven-Development. In frontend development, I had to pull-back here a lot more than I want.

I would not say it's impossible but highly impractical to use TDD for all unit and e2e tests. In my experience, there is usually a lot of exploration necessary to get something working in the UI. You have to understand browser behavior, understand how 3rd-party components are working and behaving. So you basically need to build kind of a prototype first. So I end up using TDD for logic code like mapping, services etc but less for component code. Also, I usually write e2e tests (e.g. with Cypress) after getting thing working as the structure and behavior of the UI will usually change drastically during implementation that writing e2e tests upfront is mostly a waste of time. That also means, I need to intentionally break assertions to see if the tests actually turns red if the code doesn't work. And I feel a bit dirty ^^ afterwards.

Conclusion

If you and/or your team mates are willing to try this experiment, you will benefit as you grow your knowledge (and if you think it's important, it might boost you career), the team including a product owner will benefit as unnecessary bottlenecks are removed and the software you work on will have better quality with less compromises.

A Win-win-win situation.

What do you think? Let me know in the comments if you do consider going fullstack. If not, why? Did you already tried it and doesn't like it? If yes, let me know why!

Photo by Karsten Winegeart on Unsplash

Remote Coding Dojos

Jan Wedel — Wed, 07 Apr 2021 21:35:12 +0000

If you are new to this topic, please read my article about Why You Should Do Coding Dojos. That article will cover the whys and hows for conventional face-to-face Coding Dojos.

This article here will just deal with the differences.

Motivation

During the pandemic, it is obviously necessary to shift a lot of activities to remote-only. In agile teams, this holds for Dailys, Retrospectives but also for Coding Dojos.

We had a pretty stable team for years but now we got 4 new developers which created the necessity to start a regular Coding Dojo again. As the new developers were not at the same location anyway, it was clear that we needed to do this remotely.

Challenges & Solutions

Decreased Social Interaction

Coding Dojos are more about social interaction and team building than they are about practicing to code. Everyone who attended one or two online workshops knows, that a large percentage usually keeps mostly quiet, more then in a face-to-face situation. Sometimes you cannot even see them because camera is switched off.

This needs to be addressed in a remote situation.

First, by having the camera always on. I had the video screen on the right of my wide-screen display and the IDE on the left.

Second, by good moderation. It is important that one team member focuses only on moderation without joining the codingt. That moderator should actively try to get all team members involved by asking them, especially the introvert ones to create a more balanced distribution of speaking time.

Use hand-raise function of the collaboration tool (if available) to ask simple yes/no question to the whole team to prevent awkward "everyone/no one talks" situations.

Tooling

For a remote Coding Dojo, you obviously need more than a Laptop, keyboard and mouse to get successful.

We used MS Teams for voice and video call, chat as well as screen sharing and remote control. Especially the latter is crucial for a successful Dojo.

The idea should still be to have a single computer that the whole team works on. We tried IntelliJs "Code With Me" plugin (similar to VSCode Live Share) but it was lacking basic functionalities like "Create Files", typing was extremely laggy (3-5s latency) for most attendees and auto-completion did not work for some reasons. This might get better in the future.

So we quickly moved to using the "Request Access" feature in Teams which supports multiple cursors and was generally snappy/low latency.

As an alternative, you could try git hand-over with shifting the screen sharing session. But that wastes a lot of time every 5 minutes and distracts the others with different resolutions, color schemes and maybe even different IDEs/editors. I would not recommend that.

Keyboard Layout

If you have people with different keyboard layouts in the team that control your computer, you should install and switch the layout accordingly to allow them to work as they normally do. This is usually also true for F2F Dojos but since people might have different keyboards at home it is worth to think about that beforehand.

Preparation

You should test the setup first with one team member. E.g. MS Teams eats a lot of CPU resources which can create lag on its own when running the application or tests in parallel. You have to test that everything works as expected in a screen sharing + video situation.

TL;DR

Some short advices based on the sections above:

Camera always on
Good & focused moderation
Tested and well-prepared tool set-up

It worked pretty well for us and was a lot of fun. I would think that remote Coding Dojos are not less effective in a remote situation, they are just different.

You should try it!

Did you already try it? Leave a comment how it went and if you have suggestions!

How it Feels to be a DEV Father

Jan Wedel — Mon, 16 Nov 2020 21:06:44 +0000

Usually, as a DEV, when we talk about parents and children it's about a tree data structure. But this not about programming. It's about life and the balancing act of being a father and a developer.

I am a proud father of two gorgeous little girls (1 + 5 yrs). And I am a DEV, too.

I did not become a developer because I thought it was a good idea but because I genuinely love developing software. In fact, I started programming in 5th grade and it soon became one of my hobbies that turned into a well-payed job as a side effect.

But with the wonder of getting children, you need to adjust your priorities a bit. And you're going to spend your time for different things.

But at some point, late at night in the quiet of the evening, I sometimes think about the things I'd love to do and I have no time for:

Learning a new programming language (each year)
Writing more blog posts (I have so many ideas in my head)
Reading more blog posts
Reading books (especially tech books)
Trying out new technologies
Starting a podcast

Don't get me wrong, I am not complaining and I would never even hesitate to get kids if I get a second chance. And luckily I have a great job that allows me to learn new stuff along the way and work from home. But there are times where I just wish to have some additional 24h appended to each day.

How do other DEV parents handle that?

How do developers without kids think about that matter? Are you looking forward to getting children or is it something you fear?

What is a Good Code-to-Team Ratio?

Jan Wedel — Tue, 11 Aug 2020 11:45:13 +0000

We have recently had a discussion about the increasing complexity of the system we are building and the decreasing productivity.

We've counted 19 domain-specific microservices + 21 UI npm modules that we have developed with two teams (5 + 7 devs) over the course of the last 5 years. Although we've automated a lot of stuff and it allows us to run different technologies (vert.x, Spring Boot, AngularJS, Angular), this has become more of a distributed monolith than a true miroservice-based system from an organizational and deployment perspective and the maintenance costs and feature development costs increase.

In your experience and opinion, what has been a good size of a system (or part of a system) that can be handled by one team? Do you also operate and support? How to you tackle increasing complexity

It think doesn't make sense to have a fixes metric like LOC/person or so, so please share your views on that topic.

It's "Just UI", Isn't It?

Jan Wedel — Sat, 16 May 2020 11:03:49 +0000

I was working for years as a backend developer when we decided to go "full-stack" as a team. We were all Java backend developers before but the growing need for web UIs in the product we were working on and the lack of frontend developers made us decide as a team that we want to expand our tech skills. We didn't want to depend on other teams.

First, one of our team members volunteered to self-train on AngularJS which was the way to go at that time. She was doing an excellent job for quite some time. Then, one by one, we started also learning that tech stack.

I was one of the last that started learning when we already migrating a huge code base for our single page application consisting of a dozen UI repositories gradually from AngularJS to Angular.

In the middle of that, I was working on a little existing master/detail that needed to be migrated from AngularJS to Angular. It had a couple of input fields, nothing too complex, I thought. But I was wrong.

I was actually hearing the phrase "it's just UI" from product owners a couple of times in the past and I knew what they though because I thought the same. How difficult can it be to build the UI when the "real" work is done in the backend? Especially when you already got a component library like Material and we got company styles ready to use. It should be just sticking together the existing stuff and you'll be done.

Here is how wrong I was:

First, in the past years, we moved a lot of logic into the front-end. For a couple of use cases, the backend was degraded to a better data base. Then, we had a hybrid stack of Angular and AngularJS stiched together like Frankenstein's monster with some own libraries and cli which made things really hard and slow. JavaScript code that was existing in the AngularJS part, needed to be rewritten in TypeScript and Angular.

It turned out, that we didn't have any existing code that fetches users from the backend which we needed to auto-complete in the input fields of the form. In some fields, multiple entries were allowed. Some required a static list of possible options, some required backend filtering as you type because the data set was simply to large to fetch all at once. Some required to also enter free-text along pre-populated entries and some required a custom client-side validation. So we needed an auto-completable backend-filterable validatable chip list component for this use case which - suprise, surprise - wasn't there yet. So we needed to write that. We already used existing Angular Material components but it was still a lot of code and even more tests necessary to cover all the egde cases. While building and testing, we saw that the styles did not work properly. We needed to build custom styles to make the resulting component look properly within the given company guidelines.
Then we had some input fields where one of them must be filled out, they were mutual exclusive. This also required code and testing. And this was only unit testing. Once this is working, we will need to write Cypress end-to-end test as well.

By the time writing, we are working with three developers on that for weeks. Obviously, due to home office, reduced working hours and home child care we are not as productive as before Corona.

Two things I want to mention:

Keep in mind that this is huge single page web application for industrial use cases. I would probably not use Anguar for that little web-site with that one form where HTML and CSS without any JS might be a good fit.
This is not a criticism of Angular/TypeScript. I think it is a well designed framefork/laguage targed for large web applications and if you are used to work with SpringBoot in the backend, you will feel pretty much at home with Angular and TS.

With that little article, I just wanted to explain how complex doing "Just UI" can be. I'm not sure that it "should be" that complex but after building it myself I honestly do not know how that this could be done in a much simpler way.

Remote Mob Programming

Jan Wedel — Tue, 17 Mar 2020 06:02:58 +0000

My team was practicing mob programming for some time and since we are now forced to work from home, we have to do it remotely.

For anyone who wants to try mob programming or wants to know how, I wanted to share this great resource:

https://www.remotemobprogramming.org/

They have assembled a list of best practices and tools that work well remotely.

Stay healthy! 🦄

Why You Should Do Coding Dojos

Jan Wedel — Wed, 15 Jan 2020 22:19:14 +0000

What Is a Coding Dojo?

So in case you don't know what a Coding Dojo is, here is a short introduction.

I view it basically as a coding gym or training camp where you practice coding in and as a team. "Dojo" is Japanese and means "...a hall or space for immersive learning...". Within that Dojo, you work on coding "Katas" meaning "a detailed choreographed pattern of movements made to be practiced alone, and also within groups and in unison when training".

How Does it Work?

As always, what works for you is fine. This how we do it and have good results with it.

Preparation

Pick a Kata
- e.g. from here
- Don't use prod code! (see "No Prod Code" rule below)
- Usually, you don't want to build a full-fledged application with UI, server etc.
Prepare the development environment in advance
- git repository is set up
- Project is open in IDE
- Test are running (as in "no errors" although you have none)
Choose a room that can comfortably carry your team and has a large display or projector
Bring one computer, one mouse, one keyboard (or more keyboards, if you need other layouts)
Block 1,5 hours of time
Repeat that every iteration (e.g. 2-3 weeks)
Choose a moderator that will not code (e.g. Scrum Master or any random team member)
Choose a programming language if multiple options exist (you can e.g. shuffle through every Kata)

Action

At the beginning of each new Kata, first discuss a basic approach (top down, bottom up etc). Max 10 minutes.
First random member gets keyboard and mouse for a maximum of 5 minutes (active member)
The moderator will check the time box
The active member will explain all of her/his thoughts while approaching the problem and starts writing a test and then implementation in a TDD fashion.
The active member may ask for help when stuck.
The rest of the team must not interrupt or help even if they see a bug, typo or whatever. The moderator must take care of that. Apparent bugs can be fixed in the next slot.
When the time is up, the keyboard is handed over to the next member in a circle.
The moderator should check that the code is checked into git as often as possible with sensible message (yes, also that needs practice!)
When the moderator feels that the team is stuck, another 10 minutes team discussion slot is possible.

Important Constraints

It's Not About Puzzles

One important aspect is that it's not about writing algorithms or solving puzzles. It's not even about finishing the Kata!

It's about what happens in between.

It's about team building. It's about the knowledge exchange. It's about the discussions that might happen. It's about learning how people approach problems differently. It's about giving the time to think.

The "No Prod Code" Rule

Someone (maybe managers, maybe even team members) will come up with the idea to just work on a problem in your prod code. But the Coding Dojo must remain a safe space. This is why Katas are used. When the team would work on prod code, you will work under pressure. You will make compromises. You will skip tests.

Why you should probably already do it

So, now let's talk about why you should probably do it.

Team Norming

The first and most important reason is: To build a sustainable and well-performing team. Every team goes through four phases: Forming, Storming, Norming, Performing.

You want to be the "Performing" phase, obviously. However, after a new team has been formed or after a new member joins, you will very likely come the "Storming" phase again.

Storming happens, when a team is not normed. E.g. when some members writes tests, some not. Some writes code comments, some not. Some like tabs, the others spaces. You get the idea. When there is no explicit agreement, you will get in troubles sooner or later. So even though you need a common understanding in a team upfront, practicing that in a team during Coding Dojo is really important.

Norming is not always easy, it's about finding the sweet spot between individual talent and team work that should lead to less discussions and arguments.

Team Responsibility

A special type of "norming" is team responsibility. It means that all members feel responsible for all of the team code. There should not be something like "Hey, you introduced that bug the customer reported, you need to fix it!".

Because of the fact that the whole team works on the same code, team responsibility is trained and will benefit the prod code as well.

Craftsmanship

Coding Dojos helps to learn coding as a craft. It's important to repeatedly train your skills.

When you as a team decide to follow Clean Code rules and Test Driven Design (and you should) or you want to start learning it and are afraid or unsure to practice it on prod code, Code Dojos will help.

Knowledge Sharing

During a Coding Dojo, every team member - no matter how much experience - will learn something new. Apart from learning general coding styles, team members will learn new design patterns, refactorings, IDE short cuts and tools.

We used it to learn TypeScripts. We had only Java backend developers that wanted to learn TypeScript to work on front-end code as well. So we did a Kata in TypeScript.

Social Skills

Because of the fact that the team needs to solve a problem together and each non-active member needs to take him/herself back a bit, Coding Dojos train social skills in team communication, openness and self-control.

Most developers know situations where other team members do have their own idea how to develop software which conflicts with team decisions. Coding Dojos help to make that behavior transparent and work on it. It will slow down very confident developers and give more room for inexperienced ones.

Get a Glimpse Mob Programming

Actually, mob programming is currently hyped and a Coding Dojo works similar (but not exactly the same): You work as a team (mob) on one code base with time boxing.

The difference is, that the "rest of the mob" is not driving the active member.

When to stop?

Now, here comes my confession: My team doesn't do it at the moment. Why not? We have reached Norming and Performing phases. Each team member writes code that the others value and would probably have written in a similar way. We do most coding in pair and even mob sometimes. There are very few discussions or disputes and we feel a strong team responsibility. So we as a team decided to stop it but we will start again no later than when a new member joins.

So, while you can obviously continue as long as you like, you can stop if the team has formed.

Originally posted on my blog.

Java is Dead - Long Live Java

Jan Wedel — Mon, 18 Nov 2019 21:57:08 +0000

Java is dead. Leave the sinking ship, Kotlin, golang, whatever it is, learn another language!

Is that really true?

History

Let's look at the history first. I've been doing Java development since about 2005, starting with embedded devices programmed in J2ME. Java SE (or J2SE) was already at version 1.5 but in J2ME, the language was compatible with Java 1.3 and only a subset of the JDK was supported. E.g., it didn't even had any Map implementations.

At the time of writing, Java 13 has already been released and it's been a hell of a journey. Since Java 1.3 over the past 17 years we've had features like those being added:

Java Version	Selected Features
1.4	Regular Expressions, Non-blocking I/O
5.0	Generics, Annotations
6	JAX-WS, JWM + Compiler extensions
7	Dynamic languages support
8	Lambdas, streams, optionals
9	Module system, JShell
10	`var` keyword, Graal
11	Running Java files like scripts
12	Switch expressions
13	Text blocks, Class data sharing

NIO is still the base of non-blocking and reactive web frameworks. Without annotations, aspect-oriented programming that e.g. the Spring framework leverages would have not been possible. Extensions of the compiler made Lombok possible. Lambdas, streams and optionals moved Java closer to a functional programming style (although it's still not a functional language) and allowed to reduce the amount of boilerplate. Switch expressions are a little step on the road to pattern matching (see section below). And dynamic language support made it possible or at least easier to bring dynamically typed languages like Ruby and Python to the JVM.

Sources:

Java = JVM + Language

When we talk about "Java", we should actually talk about the Java Virtual Machine (JVM) and the Java language.

When you run a Java application, the Java source code (*.java) first has to be compiled to Java byte code (*.class) which is the same on all platforms, hence the slogan "Write once, run everywhere". The byte code is optimized to be interpreted and run fast instead of directly interpreting the Java source code as it is done with JavaScript e.g.

The JVM itself is a platform specific implementation (e.g. Linux, Windows, Mac) of a Java runtime. It basically takes the previously generated byte code and runs it on the target environment. In the early versions of Java, the byte code has been interpreted which was relatively slow. From Java 1.3 on, the HotSpot VM which is a Just-In-Time (JIT) compiler has become default. It identifies high-frequently run code (i.e. the "hot spot" within the code) and compiles the byte code to native machine code which is much faster.

Since then, a lot of smart people at Sun / Oracle have improved the the JVM to be extremely fast. And by "extremely fast" I mean comparable or even faster than an equivalent C++ implementation because the JIT can generate more optimized machine code based on the known CPU and knowledge about the actual code and data flow at runtime.

Don't Follow the Hype

That is the reason why the JVM ecosystem is flourishing, setting the stage for a whole set of new language that compile to Java byte code:

Groovy
Clojure
Jython
Scala
Kotlin

There is a long and growing list of others.

Recently, I found this in my twitter timeline:

// Detect dark theme var iframe = document.getElementById('tweet-1173504123133726720-139'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1173504123133726720&theme=dark" }

This looks amazing right? First, let's have a look at what it is. It's the percentage of questions asked about that language that month. So, Kotlin is a relatively new and also popular language, no doubt about it. So, naturally, a lot of people are asking questions.

But wait... one language is missing! What about Java?

So, Java has still about 10 times as much questions as Kotlin which has passed Scala. What about popularity?

Source: TIOBE Index

Although the graph is declining, Java is still #1 (I know, I know, TIOBE results are debatable). Let's see where Kotlin and Scala are... Rank 30 and 35, respectively.

Ok, what about job opportunities? As a Java programmer, you don't have to search very long to find a decently paid job offer in the industry. There might be languages that will provide a higher salary but they are harder to find.

So don't get me wrong: I love new languages, especially when they bring new concepts that expand your horizon a bit and push other languages to adapt faster. Go and learn them!

I've learned and used a lot of different language, starting from BASIC, Pascal, Assembler, C, C++ over Erlang, Scala and Python and most recently TypeScript.

A few years ago, Scala for example has been hyped a lot. People were saying that it is going to replace Java. Although Scala has some very appealing features, eventually it didn't.

Currently, Kotlin is hyped a lot as well. It has some strategic advantages compared to Scala as it is pushed by both JetBrains (the makers of IntelliJ) and Google (Kotlin is the language to-go for Android development) which allowed it to quickly gain traction. And it's a great language for sure. But similar to Scala, I don't believe that it will replace Java.

When switching from Java to another language, there are always issues. Some things are just not working as they do with Java, some things are not compatible, some tools are not available. Whatever it is, this results in less people either want to or succeed at switching.

So the next time you'll hear news like "Mega Corp. uses the new XYZ language" doesn't mean the whole company does. Maybe it's just one or two teams of a 100.000 employees. When a new language has "that great new feature" that Java doesn't have, it doesn't mean it can easily replace Java, the JVM, the community and Java's tooling.

So why is Java so successful?

In my opinion, it is the result of a couple of different factors:

The language is relatively easy to learn and has a similar Syntax as C and C++
The language is relatively stable, backwards compatible (Java 9, oh, Java 9)
It is still able to adapt to new paradigms and technologies
The JVM is a pretty damn fast runtime (see above)
A lot of large companies are running their business on it which simply means: Job opportunities (see above)
You'll virtually find any problem already solved as an open source library with licenses that allow commercial use
The tooling is pretty great

The Future

So after looking at the status quo, let's have a look at the future. There are a lot of promising projects that are planned to be included in one of the next releases.

There are already a couple of in depth articles, so I will just briefly mention them here.

Loom

In my opinion, Project Loom is one of the most game-changing additions to the JVM and the language. It might appear to be rather uninteresting at first glance: Loom will bring "Fibers" aka. light-weight threads to the JVM. So why bother?

Unlike threads, you can run millions of Fibers, which have a low memory footprint, on a single core. Using Fibers, you can build continuations and tail-call optimizations which in turn allow to build non-blocking code that looks synchronous but does not block a thread. That means no code cluttered with chained callbacks or observables as it is common in e.g. vert.x or RxJava. I've written about it here:

https://dev.to/stealthmusic/dont-drink-too-much-reactive-cool-aid-20lk

Graal

Graal is another candidate for a game changer, in my opinion. Graal is actually not a single "thing". There is the GraalVm compiler that implements the new compiler extension API of the JVM to replace the existing JIT compiler with a JIT compiler written in plain Java. Then there is GraalVM Native Image that allows to compile Java code to a native binary which can drastically reduce memory usage and increase startup time of an application from seconds to milliseconds.

Although this sounds amazing and you can already try it, it is still in an early phase. I tried it myself and it was far from being production-ready or even just easy to use. It doesn't play well with frameworks or library that use reflection a lot (Spring, Hibernate). Without further insight, Graal will compile Spring Boot application with JPA to a native image with a fall-back work-around that simply bundles and runs the JVM and JDK within the image which doesn't give you the above advantages.

There are frameworks like Micronaut and Quarkus popping up that allow to leverage the full potential of native image though and I know that the Spring team is also working hard to get it working with Graal.

This might allow to use Java applications in areas where golang currently shines and fast a start-up and low memory usages is a must.

Amber

Project Amber brings data classes and sealed types to Java. It is a language feature and attempts to reduce the boilerplate code that is needed when created a POJO: Some fields, getters, setters. It will allow you to write something like record Point(int x, int y) { }.

The features that Amber brings will also make it easier to implement pattern-matching.

There are a couple of ideas to pattern-matching. The first was switch expressions which has been released as a preview with Java 12 that allowed to directly assign the switch expression result to variable e.g.

Pattern matching in instanceOf will make it easier to work with unknown types and render type casting ofter an instanceOf obsolete.

Then there is object deconstruction that allow to extract parts of an object or list into into its components:

int eval(Node n) {
    return switch(n) {
        case IntNode(int i) -> i;
        case NegNode(Node n) -> -eval(n);
        case AddNode(Node left, Node right) -> eval(left) + eval(right);
        case MulNode(Node left, Node right) -> eval(left) * eval(right);
    };
}

This replaces a lot of code clutter that would be necessary to implement the above.

And what would be really cool is pattern matching in methods (not sure if this planned):

    int multiply(0, int b) { return 0}
    int multiply(int a, 0) { return 0}
    int multiply(int a, int b) { return a * b}

Valhalla

Project Valhalla attempts to allow immutable (great for concurrency) reference-free objects. An array e.g. is currently a list of references to its values instead of a list of the values itself. It will also allow to use primitive types (such as int e.g.) as generic types. E.g. List<int> instead of List<Integer>.

Conclusion

So, to conclude, I honestly don't think that Java is dead. It has an active community, a rich ecosystem including tooling, a ton of libraries and frameworks, it is able to adapt and evolve while being backwards compatible (mostly) and it is still widely used in the industry.

Cover Photo by Shoot N' Design on Unsplash

Boost your Productiveness with RegEx (a little)

Jan Wedel — Tue, 09 Jul 2019 17:52:58 +0000

I love RegEx, I use it every day and I will show you how to use it to easily get some smaller and larger tasks done.

But...

Don’t use it in production

Ok, first things first: Be very careful using RegEx for anything in production code if you're not absolutely certain it's actually necessary.

// Detect dark theme var iframe = document.getElementById('tweet-1146168236393807872-175'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1146168236393807872&theme=dark" }

This is an example of what could happen. In 95% of the cases, it's much safer and easier to comprehend to use simple loops to go over data, using something like String.contains() or String.split(delimiter) to search and break strings up in a simple and readable way.

[EDIT] To be very clear: I mean what I said above. Don’t use anything I show you here in production. I personally only use that on log files, test data and manual data creation.

Tools

There is actually no special tool I use. Every more or less sophisticated text editor or IDE supports RegEx in search an replace. Most of the work I personally do in Sublime Text, sometimes in IntelliJ.

Useful RegEx

This is how I most often use RegEx in my day-to-day life.

Replace start end of line

Consider you have the following text

Flour
Eggs
Milk
Salt
Maple sirup

And you want to make a bulleted list. You could obviously enter a * in front of every line manually. But, you can use RegEx, of course.

Search	Replace by
`^`	`*`

This will result in:

* Flour
* Eggs
* Milk
* Salt
* Maple sirup

The ^ is a special character that matches the beginning of a line. Replacing this with one or more characters will prefix each line.

The same goes for end of a line. Let's say you need to add a comma at the end of each line.

"Foo"
"Bar"
"Baz"

Search	Replace by
`$`	`,`

"Foo",
"Bar",
"Baz",

The last comma might be unnecessary and thus must be removed manually. There is a more sophisticated search to fix this but most of the time it's not worth the effort. It's always good to let RegEx do the heavy lifting and fix the resulting 2% manually.

Swapping Columns

Assume we got the following data

"foo":8,
"bar":42,
"baz":13,

Search	Replace by
`"(\w+)":(\d+),`	`"$2":"$1",`

"8":"foo",
"42":"bar",
"13":"baz",

What's happening here? We are using groups. A group is delimited by parentheses. So we have (group1)(group2)(group3). The cool thing about groups is to use them later on. In Sublime, $n is used where n is the group index starting with 1. Notice that we did not include the , and " inside the groups. Inside each group, I am using \d which matches a single digit and \w matching a word character like a-z, A-Z, 0-9 and _, but no - e.g. + matches one ore more characters of the kind.

Convert CSV to JSON

Let's assume we have the following CSV:

1,35,"Bob"
2,42,"Eric"
3,27,"Jimi"

Search	Replace by
`(\d+),(\d+),"(\w+)"`	`{"id":$1,"age":$2,"name":"$3"},`

Result:

{"id":1,"age":35,"name":"Bob"},
{"id":2,"age":42,"name":"Eric"},
{"id":3,"age":27,"name":"Jimi"},

Again, we're using groups and digit or word matchers.

The transformed result could easily turned into valid JSON by adding a wrapper object and arrays as well as removing the last comma. But the heavy lifting is done by RegEx.

Create Test Data

Sometimes I need test data, a lot.

What I usually do, is to create a sequence of numbers using...Excel. Yep, Excel. Excel is pretty smart when it comes to sequences. E.g. you can enter something like:

#
10
20

Then select both an drag on the right bottom corner to fill the cells below. Excel is able to determine that the next number is 30. So based on that that, copy the rows in to Sublime:

Then I apply the same strategy as before:

Search	Replace by
`(\d+)`	`{"id":$1,"username":"user$1"},`

{"id":10,"username":"user10"},
{"id":20,"username":"user20"},
{"id":30,"username":"user30"},
{"id":40,"username":"user40"},

Learning

RegEx101

There is RegEx101 where you can test if RegEx matches. Modern editors like Sublime and IntelliJ will dynamically highlight matches in your current window. However, this page is also great to find errors and to learn what actually matches and why by using hover and the explanation section.

RegEx Golf

Then, you can use RegEx Golf as a fun way to learn RegEx.

And of course, here on dev.to

A regex cheatsheet for all those regex haters (and lovers) 👀

catherine ・ Jan 10 '19

#javascript #beginners #programming #computerscience

Summary

As you can see there are plenty of use cases for RegEx to help you with small and larger tasks that would manually take hours, especially with large data sets.

The Fear of Effectiveness

Jan Wedel — Thu, 27 Jun 2019 20:44:51 +0000

I started my first internship as a software developer at a huge German industrial company in 2003. I was ready to rule the world or least code something with great value. It was a big thing and I was exited.

That suddenly stopped when I learned that I had to program in VBA (Visual Basic for Applications) to automate large Excel sheets. To make it even worse, my main task was to type out large piles of paper into Excel. And when I say "large piles of paper", I meant that literally. We were applying for public tenderings and got thousands of pages of a printed specification. Each page contained a table with items that needed quotation. So two interns and me were hired to type out every item into Excel which would usually take 2-3 weeks and then hand it over to the project managers.

VBA was actually only used to calculate intermediate sums for each sections.

So after one or two of these specifications, I was wondering what this little floppy disk are, that most boxes contained together with the paper.

I asked the other interns but they did not know. I asked the project manager and they told me it's some special file format they cannot read with Excel and they don't have any other program that could read it. But it may contain the specification.

So it appeared that they hired three interns for years instead of buying the application that could actually the the file.

I decided that I would not waste my time anymore. Instead, I reverse-engineered the format and implemented a parser in Excel that would directly create a well-formatted Excel sheet in a few minutes instead of weeks.

I was quite happy to demo that to the other interns. The reaction was not what I had anticipated. They told me to not use it because it would kill our jobs.

I did not listen and went to the project manager. He had a look at the resulting Excel sheet and found a couple of encoding errors (German umlauts have not been decoded correctly) and decided that my program was not correct and I must do this by hand because it's more accurate.

Obviously, I did not listen again. For the rest of my time there, I used my program, fixed the umlauts and other issues manually and reading stuff online the rest of the time. When one of the project manager came around, I opened an Excel sheet I had always prepared in background and pretended I was working.

Eventually, I couldn't take the boredom anymore and applied for another internship internally.

What was your first internship or maybe first job like?

dev.to Proofreading Community

Jan Wedel — Sun, 02 Jun 2019 10:54:42 +0000

When writing an article, proofreading is one important step before publishing. But even with thorough proofreading by the author, problems of any kind will slip through. It could be small typos, structural issues or things that the author assumed the readers to know.
Luckily, this great inclusive community does not make fun of authors. But I would assume, that most authors strives to write a good article, no matter how indulgent the readers are.

As I am not a native speaker, I appreciate someone proofreading my articles, moreover I would value any feedback regarding content and structure. And don’t know why, but I don’t want my colleagues to proofread (for no specific reason).

Long story short: What do you think about building up a proofreading community?

I’m thinking about something that could be backed by technology on dev.to:

Authors can join the proofreading community
the can provide tags they are familiar with
once an article is done by the author, the status can change to “proofreading”
authors with matching tags will get it in their inbox
you could even get some credits

I’m sure this will only work with mutual help but this awesome community could make it work.

What do you think?