A blog about stuff I find interesting as a developer
This blog is meant as kind of running insight into the things I learn and create as
a developer. This way I you can find out if my interests in coding are aligned with yours and if it
might interesting to collaborate or useful te ask for input. My focus is primarily on frontend
and reactive programming frameworks (Vue, React, Angular), but I am also focusing on creating a
strong foundation in more server side object oriented programming through a Java & App developer
Certification from the Open University. I also have a lot of experience in UX design and customizing
interfaces of existing projects or frameworks in order to enhance the user's efficiency and
experience. These questions are often strongly geared towards JS and SCSS, but I find good use of
basic HTML is often overlooked.
I hope you find an interesting read 🤓
- Take your app for a test-drive -
Now that I have gotten properly stuck into Java and enjoyed making multiple code challenges for the University, I’m really happy to share what I have learned about test-driven development.
It’s funny that even though Java is the strictest language I’ve ever used, our goal is now to it even stricter by also enforcing semantic logic through tests. This practice has been a complete eye-opener and I really think it has to be a part of any solid code project.
Just to give a bit of background: test driven development sets out to first define and write tests for all the things you do not want to happen in your app. You write these seemingly simple tests that control for code that is perfectly valid on a syntax level a.k.a. the compiler gobbles it up no problem, but that that does insane things on semantic a.k.a. on a real-world level does strange stuff.
A nice example is when I was modelling a simple bank transaction and I had built in a test to make sure that if a customer did not have funds greater than 0 after transaction, the transaction would not go through.
Funnily enough I had placed the test to high up in the transaction process which had the nasty side-effect of also apply to incoming transfers. This meant that a customer with say €20 could not receive €2000 because 20 - 2000 < 0.
Building in tests that check for things as simple as this constantly helps not only yourself as your application grows and you lose sight of the details you were focussed on weeks or months ago. It also offers an amazing support to developers who may come in years later and write code that could undermine the goals you set out to solve.
Keeping State Up To Date in React
- The Christmas Holiday Catch up -
Now for all the praise I like to foster on the benefits of properly splitting up, encapsulating and managing state in an OO fashion, there is a huge trend online now to put it down. On the one hand this is just the kind of typical echo chamber of condescension you always get when something becomes so mainstream that being against it is the hip thing to be, but on the other hand there a a lot of legitimate drawbacks to OO that I do think have merit to mention.
In one youtube video that has become quite infamous - https://youtu.be/QM1iUe6IofM - Brian Will explains that the foundations of OO sound good, but only hold up to the basic degree that you can explain a class as a metaphor (warning: wildly simplifying his view here). Watch the whole video to get a way better explanation, but in short he is saying that we humans like OO because our minds are OO, we see the world and interact with it in this way. But actually computers have no such conception and what we are doing is forcing our perspective on them in a way that stops being useful when the concepts we are modelling surpass the complexity of the visual physical world around us. The solution he proposes is a kind of combination between OO and functional, which is kind of obvious considering the ubiquity of OO and the (currently) niche needs for the functional paradigm. I feel the need is most apparent in data science and machine learning, but none the less it set me to thinking about OO in React.
Half way into the video - https://youtu.be/QM1iUe6IofM?t=1269 - he brings up his serious gripes with “encapsulation” and how state is managed in OO. He goes about explaining really well how a system that starts of simply enough soon evolves to a point where objects are starting to have send parameters or references along with their requests, so that in turn the system is actually working not as a set of individual and independent nodes, but in a kind of hot mess of interdependence.
The funny part I think is that when he addresses the solution, he basically explains exactly how React works. The solution is obviously to “lift the state” up the hierarchy to the point at which both objects (or components) can get an instruction from a common ancestor as to what the state of the system is.
In React this happens very beautifully because you can define components either as a class or as a function. When I make this setup I just pass the call back to managing the state to the respective components as a prop and when one of them is called on by a user to change something, they are actually calling the root function.
Anyway, I thought it was an interesting example of how things never really change when it comes to programming. Even when they do.
Thanks for reading 🤓
Agile Use Cases
- Modelling much? -
After getting into the groove of modeling everything as attribute-only classes in domain models, we are now looking at extracting methods from use cases and creating sequence diagrams to model the communication between objects in a system.
Just to recap the impressive speed of the stuff we are learning: in two sessions we have passed from the basic concept of objects instantiated from classes, to seeing how we can model the classes in a domain models and class diagrams along with object diagrams and sequence models.
What I found a particularly interesting exercise was defining proper use cases and thendeducting methods from these use cases. It's surprisingly tricky to succinctly describe the functionality of a system without becoming too specific for a use case. The exercise is particularly good though, because often you will find yourself developing in a diverse team with different skillsets. Being able to clearly define use cases, is already helping me better agree with the instructional designers on the requirements and functionality that I need to develop.
As for the UML notation, it's pretty tedious and I wonder how often I will encounter it in the wild, but I think for enterprises it's definitely a good tool to track, coordinate and document development. UML can definitely help to do this comprehensively and without too much overhead. It would be great to see a UML diagram for something like the Django framework just to get a quick overview of how the application is setup.
In summary, I'm really impressed with the amount of tools and techniques there are to model systems. I think they take quite a bit of legwork up front, but are definitely a good way to save a lot of headaches down the road.
Everything is an object
- Why we are surrounded by objects (for now)... -
In this first week of self study for the Java Certification the material has focussed on some basic tools and practices to map the world our us in the Unified Modelling Language. This is a very perspective to think about as you start getting really philosophical really quick.
In Object Oriented Programming every Object is instantiated or constructed from a Class. This Class is like the essential idea of an Object. Sounds pretty vague at first but anyone who has had a 101 in Philosophy in high school will quickly recognise Plato's cave. Take for instance the chair you are sitting on right now. You know it's a chair because it has four legs and a flat bit you can sit on, maybe it even has upholstery but it doesn't have to. It Could also be a chair if it had one leg or 10, as long as you could sit on it it would be a chair. This idea of kind of pealing away the Attributes from an Object until you get to a Class is what I've been getting to grips with this week.
An important key for this process (and your sanity) is to keep a keen eye on the system you are trying to model so you don't start tying to exhaustively trying to Model every single Attribute of the world around us in a system.
An interesting thing I have also come across lately online is a sense of cynicism on the future of Object Oriented Programming and how it's going to be replaced by Functional Programming. Having just started the study these aren't exactly the headlines that cause you to jump up and down clapping, but after having read in to it a bit I got quite excited.
Functional programming seems to complement Object Oriented in that it can offer better concurrency and multi threading when dealing with heavy data processing. This has lead to a myriad of languages springing up to offer a sound basis for these concepts. Some like Scala build on Java other like Haskell take a fully functional approach.
Obviously nothing is going to replace anything, there are just more and more techniques and tools being developed to solve different challenges. As a student I'm obviously eager to learn and in the future I will surely turn my attention to FP but for now it's fine to focus on the paradigm that has lead the last 30 years of computer programming and rests at the core of pretty much every electronic device in the world today.
One thing is for sure; I've still got a little ways to go until I master OOP to such a degree that I need the benefits of FP for multi-threading my heavy data processing 🤓
Java Dev: Day One
- An exciting challenge and a great place to start a blog -
So last Thursday the time had finally come to start a new challenge and take the train to Utrecht for the introduction session of the Java Certified Developer course of the Open University. After months of weighing the pro's and con's of committing to a study that would require 1,5 years, significant study hours and a tidy sum of money, the moment was finally there to see if it was all going to be worthwhile. I'm glad to say it definitely is.
There is of course quite little to say about a whole course just based on the first session, but as the instructor sketched his fields of interest (encryption, privacy and eHealth amongst others) and laid out the structure, I knew this was going to be a really cool challenge. After the first session I decided to start a blog on my experiences to keep track of all the things I learn from UML modelling to advanced object oriented programming - through data structures and algorithms - to the app lab with colleagues who specialise in everything from network architecture on trains to banking apps.
Anyway, for now we are still on getting to grips with the concepts of class, object, encapsulation and inheritance so no need to worry about all that just yet.
Thanks for reading this - I'm back to the books 🤓