Today I started my second run in another team, this time I am going to be there for 3 full days. It’s with the same team as last time but with another one of their developers.
We started the day with him checking some last changes in a big pull request that changed a big part of their application and then pushing this to staging to do some manual testing. While doing that, he explained some of the reasons why this change was so large and told me a bit more of their application’s structure. We then spent some time debugging a migration query that looked like it worked but actually did nothing. After suspecting a failed cast from JSONB to an URI, wrong loading of objects and much more, we realised that it was a simple matter of singular quotes instead of double quotes. Oh well. It’s always a little bit reassuring to see one of the senior devs run into stupid problems like that every once in a while.
Once we were finished with testing this ticket, we moved on to a new one: consuming a new event from another team’s application. We work mostly event-based so we need to publish and consume lots of events between our applications. For a while, we described these public domain events in a Confluence space which isn’t optimal, so now we have a Github repository with json files for all our events, along with a text file that describes the event and its fields in a bit more detail. So far, our team uses this repository mostly in the same way as the Confluence space as a place to copy the json from and put it into our tests. The other team has added the domain events repository as a subrepo into their application and uses its json files as fixtures. I have not completely understood how this works but it looks cool, so I need to look into this further.
We spent the rest of the day writing an event consumer, command and command handler to process the new event which contained a lot of rails code that I did not really understand. My buddy tried to explain some things, but lots of it was “a is basically the same as b which is more or less c” with a, b and c being concepts I had never seen before. But we also talked about some of the reasons behind doing things the way they are done right now and how this is prep work for the two involved applications interacting in a different way soon, in order to better reflect that from a business perspective this is not one process but rather two that are more or less independent from one another.
Tomorrow we will implement the opposite event (today it was something was published, and it can be revoked as well) so I guess we can build on the ideas of today a bit, and we might get to another small ticket that is a consequence of the changes of the last two tickets, so I am hoping that I can use the knowledge that I gained today to actually do a bit more myself. I have already checked out the project and after a few trials and errors with node and things like that I have been able to start the server, so I might even be able to work on my own computer which would definitely be less stressful than working on a foreign project in a foreign language with someone else’s computer.
Oh and there were some little things we talked about, of course: different ways to set up CI and queues, comparing date and time ranges in with range types in PostgreSQL (I think that would make some of our queries easier, as well), and our shared pain of switching from Atom to Visual Studio Code. We both find the tree view irritating without knowing why and miss some of Atom’s shortcuts for doing things inside the tree view. And he told me about user-defined snippets that he uses to auto-complete ‘pry’ to whatever is the Ruby syntax. That’s actually something that really annoyed me last week, because if I type
pry in Atom, I can auto-complete it to
require IEx and
IEX.pry() but it didn’t work in VS Code. Now I at least know the place where to configure this, I only need to find out how exactly to do this.