Last time I wrote about the general design of the Ports and Adapters architecture. I have also described how I plan to use this approach in the Commutee app with the focus on the primary ports, that is the entry points to the application. This time I’ll focus on the secondary ports, the ports that domain requires.
Another week has come to a pass and unfortunately, I did not manage to work on a project at all – again. But I have some ideas that may push the progress a bit forward. As I have been on conference week ago I heard some new buzzwords, saw few interesting technologies and architecture patterns so it would be good to test them out. I’m thinking about using Consumer-Driven Contracts for designing REST API for Commutee, but it is still far from that stage of the project. For now, let’s try Hexagonal architecture! The ports and adapters approach. I will probably overengineer it, but hell, better here than in production 🙂
The 2017 4Developers Festival has come to a pass and it was awesome! For me, this is the obligatory conference that I plan to attend every year from now on. I have been on total o 7 hours of lectures and 2 hours of discussion. All of this time was worth it. Only one lecture of these was a bit weaker, but it still was really informative!
Oh, and you can get cool cups there too 😉
Here’s a quick summary of the most interesting things for me.
Tomorrow in Warsaw there will be the 4Developers festival – a conference for all kinds of software developers. It looks really interesting, and the best part of it is that I will be there, this will be fun!
It is the fourth week of work on Commutee project. Well, technically it is the fifth week, but I didn’t have much time for work on this project, so let’s pretend that it is week number four 😉
I have started thinking about the neo4j data model for all this public transport data that I have been parsing lately, and I have a big problem here…
What is Neo4j? Well, it is a database, but a different type of database, it is a graph database to be exact! And that is a really cool thing.
But what is this "graph database"? Let’s dig into it.
Another week came to pass and I have managed to do some work on my project. Unfortunately I didn’t work on it as much as I would like to, but nonetheless, I have finished writing the parser for timetables and routes data. And that counts as a success.
RxJava and Retrofit. Two really good java libraries that I recently started playing with. RxJava is a java implementation of Reactive Streams standard. It is a specification of API for processing asynchronous processing of streams. RxJava, now in version 2, is a pretty mature implementation of standard and offers a wide array of tools for use with streams. It supports basic operations like map, reduce, filtering, grouping, joining, sorting, time operations like delay, timeout, interval, window, error handling with retrying and many more. Its API is just huge, it probably has everything you may need.
Retrofit is something different and much more simple. It’s just a HTTP client library, a typed HTTP client library! It lets you easily define a java interface for remote Rest service with just a few annotations. Thanks to this, you can use your rest service like plain, local, java service, just invoke a method, pass parameters and get the results, simple as that. Oh, and it has support for RxJava, so these two play with each other really nice.
It’s one week into a competition and I already have a delay 🙁 I have planned to have the parsing of timetables done by now, but unfortunately I didn’t manage to get as much free time for this as I would like. Also, I had to make some refactorings, as my initial design had flaws.
Documentation is important, everybody knows this, especially when you are the one who needs to use some third party service or library. Without good documentation it’s often a living hell, it’s like walking through a minefield. You carefully take step after step, praying that things won’t blow up. That’s why you HAVE to create documentation, especially for your libraries and REST services. Another important thing about documentation is that you have to update it whenever code changes because the only worse thing than no documentation is wrong documentation, a documentation that is not valid for the current code base.
So if everybody knows about this, it should be ok, right? Wrong. Developers hate creating documentation and they do not do it unless it is really necessary or someone makes them do it – and unfortunately that statement is also true for me. Creating documentation is not bad, but maintaining it, may be hard, especially when you have a critical bug after bug to fix, and deadlines closing in – you just don’t have time to do it.
But there is hope… you can generate it!