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.
All about Commutee app
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 🙂
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…
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.
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.
It’s the first of march and this means, that Get Noticed! 2017 competition has officially begun! That also means that now there are only 3 months left to finish Commutee. I’m really curious of what will I achieve in this short time. There is a lot of work to be done. So, let’s get down to the code.
When you want to create an application, first, you have to know what this app will do. That’s a pretty important thing to know. You may know technology, know how to use it, how the user interface will look like, how data will be stored, but if you don’t know what this app have to do, you won’t be able to make it. An application must have some use cases so that users would use it for something. But wait, we know what will Commutee do, it will find me a route from here to where I want to get to, right? Yes and no. That is a general idea, but we need more than that to even start thinking about the implementation.
I did not manage to get an idea for another, third, project, so I have to choose from those two that I described before. The choice wasn’t easy because both of these projects would be fun to do. Some of you advised me already on which one of these two do, even though I’m sure that you guys would not use it ;). And I have my own preferences in terms of which app I would use daily. But let’s look at this from another perspective.