Pascal de Vink

Goal

Do you remember that fantastic 90s game Quake? Do you also remember the terminal window it featured if you pressed ~ for commands (well, cheats 😬)? Or maybe you only know this feature from the many, many different terminal emulators for both linux and macOS that have the same feature. Whatever your reference point, I wanted to have the same kind of fast access to my notes as that, which would hopefully make note-taking more accessible for me, which in turn would promote it as a habit.

After some trial and error, I figured out how to (mostly) get there on macOS.

How it works

To make it really seamless, the Obsidian window should not be visible in the dock or when alt-tabbing. I should be able to make Obsidian show and hide upon pressing a certain hotkey, whatever other application I’m using at that moment. Obsidian itself does not support this unfortunately, and there is no plugin that provides us with all of this either.

However, a community plugin called Global Hotkeys can take care of some of this, but only if Obsidian is already running, and it still always shows it in the dock. With some smart adjustments to the Info.plist file and automatic startup, we can get really far though. I got the inspiration from this blog.

Be ware! Because this involves changing files in the Obsidian application itself, do so at your own risk!

So, here are the steps to get it working:

1. Install the Global Hotkeys community plugin in Obsidian
2. Set up a hotkey for Show/Hide Obsidian, something like Ctrl+Shift+O for example
3. Go to System Preferences -> Users & Groups > Login Items and add Obsidian to the list. Make it hidden on startup
4. Open finder and go to Obsidian in the Applications folder
5. Right click it, and select Show Package Contents
6. Open the Info.plist file with Xcode
7. Add the LSUIElement key, Xcode should auto suggest
8. Set the value to true
9. Restart Obsidian
10. Done!

There are 2 downsides to this approach I’ve noticed so far:

1. If you close Obsidian by accident, the shortcut doesn’t work anymore. So be sure to stay away from that CMD+Q shortcut
2. The Obsidian menubar becomes unavailable, although it doesn’t feature the most useful links, it can be very helpful if you’re a plugin developer

I hope this helps somebody else that also struggles with fast access to their notes and note-taking. If you’ve found a better way to do this, please let me know!

It seems feasible to write a javascript plugin to directly publish a note to MicroBlog, with metadata being written in the front matter.

To do this, I believe I can combine the How to create your own Obsidian Plugin tutorial with an existing plugin and the micro.blog posting API documentation.

The first iteration could be relatively straightforward, storing an app token in the settings, and using the front matter to store: - publication state (draft, published) - url - preview

Then, a command palette actions could also be used to publish, like Fleeting Notes does it.

Updating, and photo/video upload support should come in a next iteration.

For a while now, we have been using Domain Driven Design (DDD) at TicketSwap to help us guide the design of our software systems. This is a messy journey, and certainly not one that is over yet… not by a longshot. Throughout our journey we’ve revisited various believes we’ve held about our domain and business rules multiple times, and we are continuing to discover new and different things every time we do so. This is especially interesting when new people join our sessions that come with interesting questions and insights. Very recently we’ve had a new business development that again questioned our mental models, and specifically how this new business idea would fit in there. So, we thought it was time to revisit past believes and rediscover. This recounting of our journey is not one for a single post, so this is the second in the series. Read the first and second post if you haven’t already.

Connecting

With a map of subdomains in hand, we were still only at the stage where we had gotten more insights into the overall picture, but it was a thousand mile overview, and the bounded contexts didn’t have any connection to each other yet. The first step we took was putting up all the bounded contexts as separate stickies on a big wall. We then tried to draw relationships where we saw them, ie. do some context mapping.)If you remember from the last post, we decided to consider the SecureSwap™️ and new business development (I can now actually mention the name: Sealed Tickets™) as two separate things, and thus put them up the wall as such. A context map tries to describe the contact between bounded contexts and teams with a collection of pattens. There are multiple connections patterns that each describe a different perspective, which enables a more holistic overview of the relationships. We ended up with something incredibly incomplete, but useful and usable.

Having this map of how the bounded contexts connected to each other gave us a better overview of the landscape. Which helped to put things in perspective in the next step.

Diving deeper into bounded contexts

We did all of these exercises to answer the original question: how does the new business development fit into the rest of the system? In order to get a real deep sense of what we’re talking about, we dove deeper into the related contexts using a bounded context canvas.

The canvas guides you through the process of designing a bounded context by requiring you to consider and make choices about the key elements of its design, from naming to responsibilities, to its public interface and dependencies.

By not just looking at a bounded context from a higher abstract level, but really diving into it, and being specific on it’s in- and outbound communication, language, business decisions, etc, the discussions don’t stay vague but are directly tied to what happens (or should happen) in a system. Constantly looking at the previous models, like the context map, made sure we did not suddenly forget something in a next session (and checked if we maybe had it all wrong previously).

We decided on focussing mostly on the bounded contexts that were closest related to the problem at hand, since filling these canvasses already takes some time, and that is where we would get most of the value.

At the time, the bounded context canvas did not have much documentation beyond what was written on the canvas template. Thanks to Maxime Sanglan-Charlier we now have some good usage examples documented which should help future teams in future sessions a lot.

Shocking conclusion

When we started out we initially operated under the notion that SecureSwap™ and Sealed Tickets™ were two closely related, but still different things and should therefor be considered differently in both the problem and solution space. However, as we progressed through connecting the contexts and dove even deeper into the details, we figured that there was so much overlap between the two contexts in the problem space that it didn’t feel like different things anymore in the solution space either.

Thanks to Nick Tune and his insightful post about Mapper Contexts & Supercontexts we came to the insight that since these were not the same thing, but not completely separated either, an encompassing super context could be thought of that fit very well!

The end (for now)

This is the mental model we settled on for now. There are still open questions (the red stickies), but the answers to these questions will evolve from here. With this mental model in our minds, it “clicked”. We knew better where the boundaries would lie of Sealed Tickets™, and we knew better how to make sure we weren’t doing the same work twice (ie. The ticket provider integration).

And with that, this journey came to an end, at least for now.

For a while now, we have been using Domain Driven Design (DDD) at TicketSwap to help us guide the design of our software systems. This is a messy journey, and certainly not one that is over yet… not by a longshot. Throughout our journey we’ve revisited various believes we’ve held about our domain and business rules multiple times, and we are continuing to discover new and different things every time we do so. This is especially interesting when new people join our sessions that come with interesting questions and insights.

Very recently we’ve had a new business development that again questioned our mental models, and specifically how this new business idea would fit in there. So, we thought it was time to revisit past believes and rediscover. This recounting of our journey is not one for a single post, so this is the second in the series. Read the first post if you haven’t already.

Decomposition

After our initial big-picture event storming sessions were mostly done, we decided to move towards decomposing our domain into subdomains and bounded contexts (remember, we are following along with the process outline by the DDD crew).

So out came the yellow tape and markers! (metaphorically at least, as a lot of these sessions were online due to the corona measures)

It was interesting to see how we were very fast to spot the most pivotal events and system boundaries, but just like before, most discussions centered around only a small number of boundaries, because those were the least clear to most people. A ha! Those are exactly the kind of discussions we should be having to joinedly discover more about them.

One interesting point of conversation was around the “Private listing created” event. TicketSwap allows sellers that have already found a buyer, to create a private listing for this buyer. That means the listing is still sold through TicketSwap (with all our safety promises), but is reserved for that buyer specifically. This of course has some interesting implications after listing creation for other system processes we do for “regular” listings, like sending out ticket alerts. Another discussion evolved around draft listings; right now a new draft listing is created when an event is selected, followed by uploading a ticket. However, we’re rolling out an update for mobile clients, which allows sellers to upload a ticket via the share sheet, and select an event after that. So which event should be the pivotal event? Should both be? For our current mental model, either choice had no real impact, so we decided to leave it. But these are the kind of discoveries that can turn all assumptions upside down.

Context repetition

During the decomposition of the big-picture event storm, we also noticed some areas that were very similar. For example, TicketSwap offers a secure connection with ticket providers for a system we call SecureSwap™. This connection is used during listing creation to make sure the ticket is valid. But it is also used during order fulfilment to actual “swap” the orginal ticket for a new one. Even though this is used in two different contexts, it still belongs together. Where it became troublesome was with the new business development mentioned at the beginning, which kicked off our entire (re)discovery journey; we were unsure whether this new development was part of the SecureSwap bounded context, or if it was its own thing. In other words: is it the same, or is it similar? Although it was reusing some of the same events and business rules, it also added some of it’s own and ignored some others.

Same thing, or just similar? By Bruce Worden

This is where we finally got to the core of the problem. This entire discussion would decide how we would view the new business development, and how we would eventually represent it in code. After a lot of back-and-forth, we decided to consider it two separate bounded contexts that might have a connection, but are not the same. For now, and until we discover more about it, this is good enough.

Next time, we’re diving deeper into the relationships between the bounded contexts, and will see if our decision holds.

For a while now, we have been using Domain Driven Design (DDD) at TicketSwap to help us guide the design of our software systems. This is a messy journey, and certainly not one that is over yet… not by a longshot. Throughout our journey we’ve revisited different believes we’ve held about our domain and business rules multiple times, and we are continuing to discover new and different things every time we revisit our mental models. Specially when new people join our sessions that come with interesting questions and insights.

Very recently we’ve had a new business development that again questioned our mental models, and specifically how this new business idea would fit in there. So, we thought it was time to revisit and rediscover. This is a recounting of our journey. This is not a journey for a single post, so this is the first in the series.

Starting out

In the past we’ve always leaned on the experience and expertise of a handful of people within our organization to guide us through our journeys. That worked well, and gave us lots of insights and learnings already. But this time, since we were talking about big picture stuff, we decided to follow along with the starter modelling process that is outlined by the DDD crew. This starter gives all the resources you need to go from high-level discovery, towards lower-level designing, and has been a very natural guide for us.

As with so many things in life, when starting with a new and unknown process for the first time (for example, neither of us ever worked with a Bounded Context Canvas before), it was hard and at some times awkward. But we persevered and consistently we felt a sense of accomplishment and renewed insights, which sparked all kinds of new energy and avenues to explore further.

Understanding

During one of our previous Discovery Days (something for another post, or feel free to message me personally to ask about it) we had already gotten a company-wide understanding of the new business idea, which helped us understand things like the value proposition, revenue streams, partners, customers, etc. Next to that, we’ve also already created an MVP.

So, we started out by doing a big picture event storming sessions, so see where this new business idea would fit in. The team was already somewhat experienced with event storming on a more detailed level, but thinking more abstractly, on a higher level, is something you need to get the hang of a bit. We started out modelling a small piece all together, which set the example of how high the level should be. Then, we stormed the events that we thought were relevant on that level of abstractness. As the discovery team consisted of people from multiple different teams, it was interesting to see people sharing their insights and expertises about certain subdomains. It also showed us exactly where we were missing some expertise and it already lead to some knowledge sharing.

On eagerness

Even though we all had a mental model about what events are important to our platform, gathering it into a single model still took quite some time. Discussions were had, discoveries were made, and already we started seeing that some assumptions we made about this new business idea and how it fitted into our little world might not’ve been entirely true. Probably because we were eager to learn more, and had some experience, the team was able to swiftly identify sub domains and bounded contexts. Later on, it turned out we jumped ahead too far too quick though, and had to reexamine and decompose again. A good learning for myself at least, to not want to go too fast. This is a big trap, and it can be tough to see when you’re going too fast, or if it’s possible to speed up. But that’s all part of the discovery journey.

I was having lunch on my balcony last week, while all of a sudden 2 small trucks parked on the small square in front of my apartment building. My first thought was that it was probably some of my neighbours moving out, or new ones arriving, as happens all the time around here. But to my surprise, the people from one of the trucks started opening it up, and pull stuff out which seemed like a couple of picknick tables and benches, and put on some snacks and a coffeemaker. The open door on the same truck revealed a lot of light and mirrors, but not a lot of boxes, chairs, tables, bags, and other random stuff piled on to each other, which one would expected if this was a moving truck.

Pretty soon after, the other truck also got unloaded, and cameras, big microphones, a computer set, and some other unspecified equipment came out. It was clear to me: this was a film crew. It wasn’t the first one in my area either, although I’m always surprised to see them. I think I just can’t see the artistic appeal of this part of the neighbourhood 😄

Interested as I am in what happens in my neighbourhood (and with nothing else happening at the moment), I watched what they were doing for a while. I was in awe to see how the 8 or so people below me seemed to move as like a single organism; from the caterer to the actors to the director, everybody knew their time and place. They all knew their part in what was to come and made sure they were prepared to fulfil it.

I watched how the actors were prepped by the dresser and the sound person, how the camera people set everything up, how the director was talking to somebody else (must be a manager, cause I never saw that person doing much of anything), and how they knew when their focus was required and when they were able to slack off a little bit. It was interesting to see that the dresser and caterer weren’t always needed and seemed fine with that. Equally interesting to see was while the director went over the footage that had just been shot to see where it needed to maybe improve, the camera people were doing some small maintenance on the camera, like cleaning the lens and the viewfinder so the next shot was crystal clear again. 

.

Watching them for a while, it struck me how close this is to how I see a successful, well-oiled software engineering team working together:

They all progressed towards the teams mission of shooting this scene. Everyone was aware of the scene, and every action was aimed towards filming it in the best way possible. Through their knowledge of the mission, they were able to work together all the time, to take breaks and to help each other where needed. Scrum teams need that same feel of direction, to be able to own the way towards it.

Everyone was needed. The entire crew brought skills that were needed to reach that mission. From the actors to the director, from the camera people to the dresser, they all played a vital role in this project. Of course, the director might have some experience operating a camera, and we know some world famous actors who also direct the movies they play in. But most of the time, and specially in the case of this crew, they needed each other. Just like backend, frontend, and mobile engineers need each other. And just as they need product owners and designers and business analysts and stakeholders to work with them.

No one person could finish the job, because it’s simply impossible to hold a camera, hold a microphone, watch the recording,  _and_ play the part all at the same time. Thus there is no room for heroes in this crew who hijack all the work (even though they really shouldn’t). There’s also no room to just withdraw yourself with your work and emerge once it’s done: the entire crew had to communicate about their status and their expectations to each other the entire time, so they knew when their work was becoming important again.

Not everyone was needed all of the time. Which made room for individuals to rest up, talk to others and do some small cleanup and maintenance. For example, while the filming happened, the caterer was cleaning up and preparing the next meal. The dresser was cleaning up and preparing for the next shot. While the director was assessing the newly shot material, the camera people were cleaning their camera’s, and the actors were rehearsing their lines. They were doing maintenance and honing their skills in the downtime, that was available for everybody. I sometimes feel a lot of engineers don’t want or don’t feel they can take the time to hone their skills, or do some small maintenance. Even though they are not always needed for a project, they seem to already focus on the next project, instead of standing still a bit and improve themselves and the tools they work with for what’s to come.

That realisation, in that moment, made me perfectly happy: this is an analogy I can use with my team when we are discussing the topic of working together, parallel vs serial working, team alignment, slacking, and maintenance.

Finished reading: Fundamentals Of Software Architecture: An Engineering Approach by Mark Richards 📚

This was a great read! Mark and Neal did an excellent job capturing a good definition (the definition?) of the Software Architect job and responsibilities. This book will guide me through the next couple of years while I’m refining my own work.

One of the stengths, for me, lies in the context they provide: not just bragging away about how many microservices your next project should have, but looking back a little bit to the history of different architectures and how that evolved into the architectural styles that we currently know. It provides context for how to choose a certain style with clear pros and cons for all of them.

Another strong part is the talk about “soft skills”. Being a software architect is usually regarded as just being the most technically skilled person in the team, but it is so much more than that. From being able to coach and mentor, to negotiation, to requirements engineering, to presenting. It acknoledges all of the skills that are required of a software architect beyond the technical are discussed openly, which is refreshing to read about.