In 2017 I started working on an Android app, at some point a custom graph was needed that could be changed by the user. Drawing the different parts on the screens gives the most flexibility. The Canvas is used for drawing, the custom component where the drawing will happen is a class which inherits from View.
After Techorama the next conference I attended was Joy of Coding, something completely different and a more alternative conference.
I've been building iOS applications for 2 years now. Although I'm not a big fan of the development environment, Xcode has its quirks, I do love the iOS platform. The biggest drawback is that you can only target iOS devices. I heard a lot of things, some good, some bad about Xamarin and React Native and was intrigued by both hybrid app development platforms. I'm a little familiar with Xamarin but have no experience with React or React Native. Motivated with the learning goals I've set out for myself I decided to give React Native a test drive in one of the Aaltra company hackathons. It's a half day every week that we use to test out new technologies and learn new things.
Last time we made a Fake build script for an ASP.Net MVC project. I wanted to bring this to the next level and set up continuous integration for the project. I've used TeamCity in the past and it was ok, it did its thing but there was a lot of configuration involved to get a project up and running and the performance was sometimes slower than I expected. So looking for alternatives the first thing I tried was Bitbucket Pipelines but it can apparently only be used for .Net Core projects. I don't think it can run Windows tasks at the moment.
Each year I try to set some goals for myself to keep improving my skills. At the end of the year it's fun to reflect on the goals I've reached and at the same time confronting because of the goals I didn't complete. This year, although it's already April, I want to do it a little different. To be able to better evaluate what I want to learn this year I decided to write it all down so I could evaluate my progress better. And by making it public there'll be a bit more pressure to actually completing the goals I set.
Creating a build script, always a hassle to do and one of the things that gets the lowest priority in the backlog. Certainly on small projects. On one of my previous work places MSBuild was used to automate the builds. I had such a bad experience with it that I just plain ignored it for several years. It was hard to use and maintain. I heard of Fake, a build automation system written in F# which gets its inspiration from rake and make, and gave it a try!
Sometimes you need to send some data to the server before the user leaves your web application. A good example of this is saving data. Instead of giving the user a save button to save the changes he made, the application saves all data if the user navigates away from the page or closes the browser.
At the Aaltra hackathons we get the chance to test out new technologies and broaden our horizon, one of the many things that makes it awesome to work for them. In one of the Belgian Internet of Things community meetups I attended, Pedro Dias gave a demo about the IOT stuff he had built to water his plants. He collected all sorts of data from different hardware sensors and sent them to Azure Table Storage. I gave it a test drive on the latest company hackathon.
Integration testing, it must've been several years ago that I first got to know the concept. Like unit testing, the benefits were and still are quite obvious. When developing I've found a good set of tools to do unit testing, but finding a set of tools to do integration testing has been a constant struggle. I tried using Selenium and WatiN. Creating the little tests with the recorder was pretty neat, but reality struck pretty fast when I experienced first hand how brittle UI integration tests really are. Change something in the UI? You can practically throw away your existing tests and start over. Because the tests were so brittle, the result was hardly usable and very time consuming. Tests were constantly failing just because something changed in the UI, not because there was a bug in the application. Maintaining a suite of UI integration tests was not an option.
