Dev Blog

A blog about stuff I find interesting as a developer

Innovation Management

- Rotterdam School of Management -

👨‍🏫 Excited for my first Innovation Management lecture in two weeks by Jan van den Ende... Thanks to all the supportive feedback from colleagues, clients and cool hands on experience at Q42 I decided to take the plunge back into academia and get to grips with the theory and research behind Innovation (Management). The course Rotterdam School of Management, Erasmus University lasts a couple of months, deals with tons of cool subjects like #designthinking and #strategy. Interested? It comes at a discount if you are also an Erasmus University Rotterdam alumnus...

Rotterdam School of Management

Delightful Design

- For millions of people -

So it's Christmas and finally there is some time for a bit of reflection. So many cool things have happened in the meantime, but the single most exciting would have to be working at Q42. This company is a little miracle behind a lot of big names. Apple Classical, Hema, PostNL... the list goes on and on and Q42 is technical expert behind all of them. Since a few months I have been lucky enough to have my dream of being a Native iOS Developer come to fruition whilst serving 3 million daily users through the PostNL app. The size and sophistication of the code base is truly astounding. The app brings together the best of native UX and web flexibility through the power of Server Driven UI (SDUI). As you can imagine it can be pretty daunting to add your own two cents to a piece of crucial infrastructure that has been in the App Store for near to a decade. That's why I was extra proud and honored to have been given the task of creating the Christmas Easter Egg. Using the native game engine of iOS I made a fun canvas of snow, trees and a car careening back and forth to deliver the deluge of presents. Eagle eyed users could discover it by clicking on the packages bouncing in the top left corner. I hope it brightened the day of many people waiting for the Christmas presents, it definitely brightened my day to make it.

For millions of people

Boijmans Depot

- Webby Winner 🍵 -

From a challenging stage 8 years ago, to building their award winning app. Who'd have thought all those years ago when moving to Rotterdam as a novice digital creative that I'd be anywhere near making the app for the world's first public art Depot and the biggest architectural feat since the Erasmus bridge. The Depot and it's style of architecture really inspired me and I took the same amount of care to craft the app as was being put into curating this vast art temple. Of course I was not alone in making this. It was a huge team effort from an (insanely) knowledgeable product owner to a great UX'ers, designers, backenders, the list continues... Much like the best creative endeavours, the app flourished from it's constraints. Because of the tight deadlines and high standards we had to be pragmatic and precise, without losing the feeling for the app we wanted to gift the user. I've learned so much along the way and am grateful for this awesome experience. Rotterdam can be a tough city, but when you get it, magic like this can happen.

Webby Winner 🍵

Honored and Excited

- Another app. Another Royal visit. -

It's a bit ridiculous, but I'd be lying if I said I didn't feel a little smug that both of the major apps I worked on this year received a royal seal of approval. The craziest thing with the Boijmans Depot app though is that the regal attention was actually the least of the excitement. The best part was seeing the app you've been sweating over for a year, with talented designers and tenacious producers, being mentioned in newspapers from Rotterdam to New York. The Depot app was quite a challenge to get ready within the short time scoped for it. The app, much like the building, houses over 150.000 artworks. All of them filled to the brim with high res images and mega amounts of meta-data. The development was very rapid and iterative(some call it agile), but we made it with flying colors. Keeping the crash rates under 1% for both platforms and seeing a whopping 12K user's pick it up in a the first three weeks. Again I feel like setting out a good set of typed API endpoints was the factor that made the rapid changes and possible, keeping the uses away from pesky errors and bringing the magic of art in the world's largest public art Depot as close as possible.

Another app. Another Royal visit.

The New Fotomuseum App

- King of the Hill -

Yesterday, after months of development and then months of waiting for the pandemic, we successfully launched the new Fotomuseum Eregalerij app and display. A new and improved version of the original app, with way more content, loads more polish and even smoother animations. Building the new app was a cool experience on a professional as well as personal level. It was cool from a technical standpoint because we used TypeScript and built on top of a solidly documented backend and personally it was awesome because I discovered a lot of amazing stories in photography. It felt really unique to have my two passions merge into one. Writing a nicely designed and well thought out app, whilst flicking through all the awesome stories about the history of photography. One of the photographers I discovered turned out to be a world famous neighbour of mine @staciisamidin, whom I ended up attending a workshop of which opened my eyes to a whole other side of people and photography. To top it all off the Eregalerij was one of the first expo's to open after the pandemic and was attended by none other than the literal king of Holland 😄

King of the Hill

Reading - Writing - Running

- 2020 in reflection -

As 2020 draws to a close and the winter months bring the evenings ever closer to the mornings, I thought it would be good to reflect on the good things this pretty unusual year has afforded me in the way of insights. It was pretty much to the day the app development study was done, that the first lockdown started. This was a surreal cultural shift that, even according to my grandma of 92 years, never happend before. All of a sudden even the most outgoing of us were set to sit down, stay inside and stare at the walls. Without too much exageration I think everyone found one of the most confronting parts of 2020, the fact that they had to come to terms with doing nothing. Of course doing nothing is totally impossible. There is a great Seinfeld episode where Elaine's boyfriend Putty is relaxing on the couch doing literally nothing, sitting upright, staring at the wall, with a smug grin on his face. The ridiculousness is immediately evident and Elaine is outraged to no end. "What are you doing? Nothing. Well stop it! Stop what? Nothing!" Reading - writing - runnning, for me these three hobbies are the best new features of 2020. Reading books, writing fiction and running around. It's not too different than my work, reading documentation, writing code, running programs - but it's definitely more relaxing. Reading - There is something supremely comforting in being drawn into a seemingly endless and gripping book. I think books force you to switch your mind over to their narrative they can whisk you away from a dreary grey december afternoon in a way that streaming services or games can't really. My guess is it has to do with the fatch the with books you have to paint the picture in you mind's eye yourself. Writing - Next to the reading I am glad I picked up writing again, like I am doing now. There is a certain satisfaction that you get from writing the surpasses most other hobbies I now how to go about. Obviously every hobby needs to start with an endless internet search, hundreds of euro's of equipment and then book ended by no idea of what to do with all the new gear you just had to get. This time however the small investment in a a mechanical keyboard actually paid off as it gives that satisfying ClacK when I type. There is a certainty to that sound that makes the effort far more gratifying and I find myself writing for fun way more often. Running - If anyone ever asks me how I get my mind off things, it's invariably running. There is within all of us about 300.000 years of legacy code geared towards us panting and plodding over the savanna's and prairies, running up right, spear in hand, tracking down a our latest lunch. After 3KM the body goes over into a sort of auto-pilot mode and your mind seems only to interupt if there is an interesting thought of an eventful memory. So with this year drawing to a close and the new year lying in wait, I wanted to set down these thoughts with a clack and pick up next year with new energy and hopefully by the end of it some good stories to share.

2020 in reflection

Finally done with all the fun

- Unix really ties the room together -

We're done! Handed in the Android App with the team and we got an 8. It was a really fun to bring all the Java and React-Native experience together, combine the design patterns and quickly make a quite complex Android app. The best part was the teamwork though. I'm really convinced that the most important part of making great software is having a good vibe with your team. I'm not the only one though who thinks this, so does Brian Kernighan. In an epic 1980's video at Bell Labs he explains the foundation's of UNIX (on which your probably reading this) and it's pipe operator. He explains that because the programs had to be so miniscule at the time, the operating was setup with strong focus on multi user support and sharing a good vibe between everyone who's working on the system. So our little Android app built on this long tradition of UNIX, not only literally as Android is a *NIX system, but also figuratively as the team really got into the (git)flow and put down features from push notifications to firebase and fragments to location services. It was a blast playing with Android, so now it's time to check out the neighbors and polish up my Swift apps.

Unix really ties the room together

Going One-Sixty Swiftly

- The pro's and con's of (fully) native apps -

As always it's been a while since my last post. In the meantime we've released another app and have two more in the works. I've gotten to know React-native more in-depth and it's latest version has really ironed out a lot of issues, especially thanks to the auto-linking of packages. That being said, the Java certification is also in the final stretch and has made me excited to build a fully native Swift app in addition to the Java one we are creating for the certification. I was surprised to find that Swift has far more features and complexity to it than Java. Not only do you have far more control over variable declaration, with options like weak, guard, get and set, built in. But also the protocol and delegation pattern was at first a bit steep to understand. This is also due to the fact that Swift seems to throw terms I know in a blender, a let is a const and an interface is a protocol for instance. There's always I big discussion about hybrid vs native, in terms of speed. Hybrid is faster to develop but harder to maintain, Native runs faster but is slower to develop. Why I'm interested in building fully native apps though is simply the tooling that comes with it. Both Apple and Google invest millions in creating a highly optimized eco-system for there app developers and I would like to be able to benefit fully from all these new features directly and as soon as they come out. With hybrid you will always have to wait for it to trickle down and then hope that the person who made the package keeps maintaining it. By going fully native you have the newest features as soon as the come out and you can count on Apple and Google for timely updates. Anyway that's all for now, lots to do and very excited about being done with the certification, making some Swift and Kotlin apps and getting some sunshine. 😎

The pro's and con's of (fully) native apps

Hooked on Hooks

- useSubtitle() -

It's a few months on again and I've really grown to enjoy React a lot. The addition of hooks in the latest update (16.8) of React is one of the few times a hype in the JS world turned out actually to be well founded. After watching Dan Abramov's slick presentation, where he refactored a chunky old class into on of the svelte functional components, it was clear these things were winners simply based on the amount of code they clean up. But the genius of these hooks goes much further I think because they nudge you into thinking more functionally about your components in general. After understanding how these things 'think' you kind of want to think in the same way. For instance instead of having one big state in a component with a but of setState functions attacking it from all sides, I now like to have a bunch of mini state hooks, each managing their own little bit of state. When I want to update one of these from inside the functional component I simply call their set function. If I want them to be updated from outside (say Redux) then I hook up a useEffect to a useSelector. So now you have a nicely split up circular loop. Redux updates so the useSelector changes -> React notices so the useEffect -> so my component does some logic and I set my state with the useState. It's really impressive to see the React team introduce something that seemingly goes against the grain of the core of the framework, that turns out to be exactly what it needed without breaking a thing. (Here is the video in case you missed it


MVC is the Real MVP

- Divide and conquer -

And... We're back! This time I'm really relieved as the last few months were a super intensive cocktail of excitement and exhaustion. Now that it's done though I'm relieved to have passed the block on Advanced Object Oriented Programming as well as have a really cool Augemented Reality app built, tested and ready to ship to the app stores. This finally gives me some time to leave the Java for a bit and try Swift. I found this really neat series of lectures from Stanford on iTunes U and now finally I've got the time to check them out. Aside from wanting to get deeper into the native developing (statically typed and compiled), I was drawn to the big portion of the course devoted to the Model View Controller architecture. This structure really helped us develop the augmented reality app rapidly whilst keeping things clear and scalable. For the View we used React-Native, for the Model Redux and for the Controllers we made classes with static functions. Because these functions are static we make sure the Controllers only deal with logic and all updates are dispatched to the Redux store. By doing this we keep the app neat and tidy whilst keeping state neatly in one place. When a View receives an event that needs dealing with outside a simple component we can just call the Controller and continue business as usual until the Model updates and React re-renders the view. It's a very nice architecture and I'm excited to see how they use it at Stanford in the world of Swift. 🤓

Divide and conquer

Exciting times and interesting endeavours

- Pick your own pieces puzzle -

Things are going really well and I’m really happy. It’s good to remember once in a while that the main (if not only reason) to code is probably because it’s just super fun and rewarding to stick at something until it works. Be it an Arduino, an app or a data pipeline, it's like doing a puzzle where you get to pick your own pieces. I’m particularly chipper however because as of last week I also started working at Rotterdam’s premiere Creative Digital Agency: IN10. It’s pretty astounding to see the perfect match between their cultural and creative projects, technology stack and my passions and ambitions. Asides from this there is the spot of good luck that they let me get cracking on a React-native app they are building for the Kinderdijk windmills. This is great as I’ve spent the last few months exclusively studying on Object Orientation structures and doing a React & Redux course on the side. Now I get to combine the studies in practice whilst tinkering with this amazing app that even incorporates augmented reality and will be enjoyed by people from Korea to Copenhagen. Amazingly this app is built for the two concurrent app platforms using their respective native codes - Java and Swift - and all from one code base written solely in JS. It’s not as easy as copy-pasting what you learned on the web, but with a bit of React or Vue experience, React-native really does let you get you apps deployed in record time. You can check out the app right now by looking for Kinderdijk in the App-store. Again thanks for reading and talk to you soon 🤓

Pick your own pieces puzzle

Test-Driven Development

- 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.

Take your app for a test-drive

Keeping State Up To Date in React

- The Christmas Holiday Catch up -

So the first block is done and I've learned a lot of interesting insights into modularity in software design. So as a small holiday break I thought it would be nice to learn more about the React JavaScript library and how it uses components and classes to manage state. A lot of the basics that have been laid down by Java 25 years ago are still in use today and have been adapted to different languages such as JavaScript for use in frameworks like React and Vue. However, there is also a big push now for languages such as Haskell that completely abandon the OO setup and opt for a functional style. In this post I thought I would share some insights into my research of OO, Functional and the React library I have been toying with. Even though JavaScript is not a strictly OO language the current release of ES6 added the “syntactic sugar” that makes class based definitions and import and export statements really easy, especially on the backend. Along with the new spec you saw an even sharper rise the popularity of the frameworks as React, Vue and Angular (even though Angular builds on TypeScript). I think this is at least partially because the maintainers of the language showed that they were incorporating the direction that the developers where pushing for: a more modular, backend capable, OO version of JS. 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 - - 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 - - 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 🤓

The Christmas Holiday Catch up

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.

Modelling much?

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 🤓

Why we are surrounded by objects (for now)...

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. So in short this blog is the first instalment of a series in which I will try to some up and condense the interesting stuff I learn along the way to becoming a certified Java developer. In doing so I will try to give some insights into the why's and how's of Java and how the new knowledge fits in with the skills I have already built up while focussing mainly on the front-end and JavaScript. For one (and if you got this far I'm guessing you already knew this) but Java and JavaScript are not the same thing. That doesn't mean they don't share similarities, ECMAScript 2015 introduced a form of Class into JavaScript, but in essence the languages a constructed very differently. One thing is for sure: Java is way more verbose as everything is statically typed. This make the code seem more daunting to a novice developer (me). I'm still getting used to the thicker syntax but I do see the advantages and even necessity for enterprise stacks. In dynamically typed languages like JavaScript and Python you let the interpreter figure out what kind of variable you a declaring. I can imagine this becoming increasingly confusing when a return function gives back a 0 or undefined the JavaScript interpreter inferring this as a False. 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 🤓

An exciting challenge and a great place to start a blog