Posted on

Upgrading from Webpack 3 to Webpack 4 With Multiple Entry Points, Vendor Bundle, and a Commons Chunk

Upgrading to Webpack 4 can be a bit tricky if you have a legacy project. I had trouble with modules being evaluated twice. Some of these modules being stateful caused the application to only work partially. Different parts of the application got a different instance of the module. This was due to the way vendor bundle was implemented (as an entry) in this project with Webpack 3.

As there was some “assembly required” with the way the vendor bundle was set up, I still needed an entry point for the vendor bundle. This would not work out-of-the-box with Webpack 4.

Below are example webpack.config.js for Webpack 3 and Webpack 4.

“runtimeChunk: ‘single'” is what makes this work. It will make Webpack to emit a single runtime bundle (runtime.bundle.js) that must be included in each page. Another change is that the bundles will be chunks afterwards, e.g. pageA.bundle.js will be pageA.chunk.js from now on.

Even with the vendor bundle, the libraries will end up in the commons chunk (note that I renamed the commons chunk from shared to commons in the configuration). This does not matter in my use case as the need for the vendor bundle is mainly to get custom setup done.

Posted on

Delete an item from an array without a loop in PHP

I recently bumped into a nice way of removing an item from an array without using a loop when you don’t know the key of the item.

We set the item to delete into a new array and take the difference of the actual array using array_diff. The difference is of course the array without the item we want to delete. array_diff leaves a gap in the array indexes if the value we delete is not in the end of the array,  in the example we would have indexes 0, 1, 3 after running array_diff. To reset the indexes, we use array_values to create a new array with the values we want.

I found this to be a nice little trick that will save a loop when you want a simple deletion.

 

Posted on

Ideas in the afterglow of DDD EU 2018

After the conference I had some things that I would want to do or try out in practice. Instead of just recording these ideas in Evernote and never reading the note again I thought about making the note into a blog post instead.

Try Event Sourcing out in a  spike type of side project.

I’ve read on ES on a few occasions and kind of used it when playing around with the Akka toolkit, but I never got around to actually focusing on ES itself with read model projections and all, so there is probably many things I’ve missed completely. It would be interesting to try it out in a small project and perhaps in a language that I don’t usually use.

Learn what monads are.

Monad is a term that is frequently thrown around these days and I’ve never really had a proper description of them so that I would actually know what they are in practice. I thought about reading up on monads and try them out in some functional programming language just to get a concrete feel of what it is about so that I would be more able to follow the conversation when monads are mentioned.

Come up with multiple models for the same domain and then implementing them in code.

There was a lot of discussion of different perspectives , cognitive biases and legacy blindness related to modeling in the conference. It might be a good learning experience to try to find many models for the same domain and then implement them, perhaps with different languages and programming paradigms to get the hands-on feel in how changing the tools and your perspective in the context of same problem affects the resulting solution.

Reread the blue book.

I took my copy of Domain-Driven Design with me to get it signed by Eric Evans. After getting it signed I browsed the table of contents and I was like “Oh, this was discussed here also” and “This seems like something I want to learn about”. I read the book a few years ago when I had no prior understanding of DDD and I was really struggling to understand it. Now after three DDD conferences and in general trying to follow the DDD community the contents of the book seemed much more easy to understand. I got the feeling that rereading the book now would result in a deeper understanding of DDD since it’s not completely new to me anymore.

These are just some actionable ideas that I had right after the conference. There were many more interesting things of course, like the Cynefin framework.  Perhaps I should read up on it as well since it has been mentioned in the previous conferences as well and that’s practically everything I know about it.

Now I’ll just have to see if I’ll ever actually get around to actually doing these things =)

Posted on

JSON Encoding and Decoding in Scala with Play JSON

This is something I’ve had to look up a few times, so I figured it’s time to write up something to ease the next time a bit.

First we need to include the Play JSON library itself to build.sbt

Using case classes seems to be the most used method of holding data to be encoded in JSON. So the next step is to configure out case class InventoryItem for reading and writing (decoding / encoding) into JSON with a companion object.

I’m using an example where we write a list of InventoryItems into JSON. Play JSON knows how to handle Lists automatically so no configuration is needed for that.

List of IntentoryItems would like something like this in JSON.

Reading JSON is from a string is a bit more involved than writing it.

 

Posted on

Clean Code

Clean Code by Robert “Uncle Bob” Martin et al. is all about writing maintainable code. The core tools presented for this goal are refactoring, test automation and paying attention to the clarity of the code. The book has a lot of code examples in Java, which is seems to be the lingua franca of software development books.

The book is organized into chapters that address clean code at different levels like naming in general, functions, classes, modules and even at system level. There is a chapter and an appendix dedicated to dealing with concurrency.  One brief chapter is also dedicated to emergent design. In the end of the book there are case studies of cleaning up open source classes.

The first chapter “Clean Code” lays some foundation on what clean code is why it is necessary to focus on keeping the code clean. The chapter also contains quotes from well-known programmers on what they consider to be clean code. Their answers are a pretty interesting read and a good addition to the chapter.

I think anyone with a few years of professional programming experience knows what it is like to deal with bad code, the dreaded legacy codebases with incomprehensible code and dependencies all around. Change one thing and something completely unrelated breaks and you have no way of finding out except trying to manually test everything, which you obviously cannot do on a project of any meaningful size. So it is left for the users to find the bugs and each release becomes a stressful event of waiting to see what broke and how many users get upset.

But to state the (likely) obvious, bad code will kill your productivity over time. In the beginning it is fast to just get things working as quickly as possible, then the technical debt starts to accumulate and everything gets slow and horrible. Some technical debt always accumulates even if you try to stop it, but not caring about it will likely result in a disaster over time. There is a time place for calculated risks and taking on technical debt, but that shouldn’t be the default mode of development.

To keep the code clean the book offers two key methods Opportunistic Refactoring(The Boy Scout Rule) and cleaning up new code right after it was written (First make it work, then make it right). Getting a good solution to a problem on the first try is very hard so I think it is worth it to go over the code in order to see how to make it cleaner. Needless to say comprehensive tests are required to ensure nothing gets broken while cleaning up.

The different chapters are full of great tips to make your code more clean and maintainable at different levels. Some things that I have focused on more after reading this book:

  • Keeping methods even shorter.
  • Write methods that do only one thing.
  • Ordering methods inside a class so that a method is defined after it is used the first time. This ends up in a structure where high-level functionality is specified before the low-level functionality and it is easier to browse the code.
  • Being critical about comments. I used to use a lot of PHPDoc comments, but with PHP 7.1 type hinting these are mostly just noise.

The first two are nothing new to me, but getting repeated reminders of these seem to always change the way I write code.

One of the things in the book I didn’t like was chapter 16. This was a quite long chapter on refactoring SerialDate. To me it felt like it suffered from it’s implementation pretty badly. Reading the chapter involved constant shuffle between chapter 16,  code smells chapter and the appendix that contained the actual code of SerialDate. Perhaps this would have been better conveyed through some other medium than a book.

In general I think this book would be of the most value for programmers just getting started with professional software development. More experienced programmers will likely learn some new tricks as well. The book is quite easy to read in comparison to Code Complete 2 which covers many of the same topics. I still haven’t managed to finish Code Complete even though I think it has some excellent information.

I would have liked to see something on the domain of the software being written. I think it is an extremely important aspect of producing useful software. It doesn’t really matter how clean your code is if it does the wrong things. But it’s a large topic in itself and understandably a single book can’t give you everything.

Some similar and related books I’d recommend

TL;DR; Highly recommended read if you are a junior developer. More experienced developers should remind themselves of these things periodically, there always something you missed. Maintainable code matters. Some parts are difficult to read due to having to having to back and forth different chapters in the book.

Posted on

Reactive Messaging Patterns with the Actor Model

I recently finished reading Vaughn Vernon’s book Reactive Messaging Patterns with the Actor Model. The book is about how to use the Actor model with Scala and the Akka toolkit.

First three chapters of the book concentrate on giving the reader a quick introduction to Scala, Actor Model and Akka. Personally I enjoyed these three chapters the most in this book. They we’re quick to read and provided so much information for me as I had no previous experience with neither Akka or the Actor Model.

Bulk of the book is the chapters following the first three that are messaging patterns inspired by Enterprise Integration Patterns. Thus the last seven chapters are basically a pattern catalog. This is something I have heard critique from few other people, especially people who have read Enterprise Integration Patterns (I haven’t, yet). I admit pattern catalogs are heavy to read and I too struggled with reading the quite intensive examples. But, these also provided me with the most practical knowledge of Akka and the Actor Model. I made use of some of the things I learned in the catalog almost right away when I did some exercise programs with the Akka toolkit. There is some really good stuff in there.

One thing I found especially interesting was the Transactional Actor pattern in Chapter 9.  This pattern explains how to persist actor state with Event Sourcing and thus gives some insight on how to use actors to implement Aggregates. This is something I am planning to try out in the future. Event Sourcing is a really natural fit for persisting actors so I’m looking forward to playing with this.

It’s a shame that Akka Streams were still in the planning phase when the book was written, this is something I would like to learn more of at some point. The book covers PersistentView very shortly, these can be used to denormalize persisted actor state for use in view logic. This is something I would have liked to have seen a more thorough example of in the book. It is still a bit unclear to me how to denormalize actor the state for view logic in practice, but apparently Akka Streams is the correct way to it now(?)

Even though I do not use Scala at work, I learned new things to consider in other environments as well. Most prominent at this time is the differentiation between types of messages. Consciously separating Command Messages, Event Messages and Document Messages is something I have concentrated on when using JavaScript event/messaging libraries. It’s interesting how learning unrelated technologies always seems to  teach something that’s useful event if you cannot use the technology itself.

TL;DR; I liked the book. Some chapters heavy to read, but provide valuable information. Read if you are interested in Scala and Akka.

Posted on

Updating to Selenium 3 with Firefox

I struggled a bit with updating Selenium from 2.53 to 3.3.1, so I thought about documenting the steps. I’m going to skip any background trivia and get to the point. I’m assuming you are on Windows.

What you’ll need:

Now to run the tests you need to tell Selenium where to find the Firefox driver. To do this we are going to create a bat script, let’s be creative and call it selenium.bat. Insert copy paste the following into the selenium.bat:

java -jar -Dwebdriver.gecko.driver=geckodriver.exe selenium-server-standalone-3.3.1.jar

Obviously the geckodriver.exe, selenium JAR and the bat script need to be in the same folder. Just run the bat file and you’re ready to start updating your tests  🙂

Posted on

Best Before Date of Code

I was listening to the Developer on Fire podcast Episode 197  with Neal Ford today. Nearing the end of the episode around 44:00 Neal mentioned something similar to what I have been thinking about on multiple occasions:

One of the dynamics I have noticed in my career is that, inevitably, if I look back at whatever I created two years ago it looks like it’s the most horrible thing, I’m so embarrassed by it. I can’t believe I did that. […] In fact I’m a little afraid if that stops happening.

I thought of it this way: The price of improving is feeling like an idiot for what you did before. No need to be that hard on yourself, but I sometimes do feel a small sting when I look at old code I wrote.

Discussing this with a former colleague of mine he pointed out that there’s no need to feel bad about old code since it was the best you could do at the time. It wasn’t intentionally bad. If it was, you probably would not feel bad about it.

So to reverse this thinking, the code (or whatever) you produce today has it’s best before date in two years from today if you are improving. When your code from years past still looks like the code you wrote today, it’s time to start thinking what to do about it.