Show/Hide Obsidian, something like Ctrl+Shift+O for example\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2022/4ebaa5fc9f.png\")
Show Package ContentsLSUIElement key, Xcode should auto suggesttrue\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2022/99e28fa7b0.png\")
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.
\n\nTo 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.\nObsidian itself does not support this unfortunately, and there is no plugin that provides us with all of this either.
\n\nHowever, 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.
\n\nBe ware! Because this involves changing files in the Obsidian application itself, do so at your own risk!
\n\nSo, here are the steps to get it working:
\n\nShow/Hide Obsidian, something like Ctrl+Shift+O for example\nShow Package ContentsLSUIElement key, Xcode should auto suggesttrue\nThere are 2 downsides to this approach I’ve noticed so far:
\n\nI 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!
\n", "date_published": "2022-06-04T16:19:30+01:00", "url": "https://www.pascaldevink.nl/2022/06/04/quake-style-opener.html" }, { "id": "http://pascaldevink.micro.blog/2022/05/15/publish-from-obsidian.html", "title": "Publish from Obsidian to MicroBlog", "content_html": "It seems feasible to write a javascript plugin to directly publish a note to MicroBlog, with metadata being written in the front matter.
\n\nTo 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.
\n\nThe first iteration could be relatively straightforward, storing an app token in the settings, and using the front matter to store:\n- publication state (draft, published)\n- url\n- preview
\n\nThen, a command palette actions could also be used to publish, like Fleeting Notes does it.
\n\nUpdating, and photo/video upload support should come in a next iteration.
\n", "date_published": "2022-05-15T20:54:28+01:00", "url": "https://www.pascaldevink.nl/2022/05/15/publish-from-obsidian.html" }, { "id": "http://pascaldevink.micro.blog/2022/01/21/rediscovering-our-domain.html", "title": "Rediscovering our domain, part 3: Connecting and organising", "content_html": "\n\nFor 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.\nVery 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.
\n\nWith 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.\nThe 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.\nA 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.\nWe ended up with something incredibly incomplete, but useful and usable.
\n\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2022/2edc6cbb3b.png\")
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.
\n\nWe 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.
\n\n\n\n\nThe 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.
\n
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).
\n\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2022/1760c2384e.png\")
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.
\n\nAt 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.
\n\nWhen 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.\nHowever, 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.
\n\nThanks 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!
\n\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2022/82e6c4c7c8.png\")
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).
\n\nAnd with that, this journey came to an end, at least for now.
\n\n
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.
\n\nVery 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.\nRead the first post if you haven’t already.
\n\nAfter 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).
\n\nSo out came the yellow tape and markers! (metaphorically at least, as a lot of these sessions were online due to the corona measures)
\n\nIt 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.
\n\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2021/48541aef52.jpg\")
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.\nAnother 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.
\n\nDuring 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.\nWhere 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.
\n\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2021/2a7fb77bdd.jpg\")
Same thing, or just similar?\nBy Bruce Worden
\n\nThis 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.\nFor now, and until we discover more about it, this is good enough.
\n\nNext time, we’re diving deeper into the relationships between the bounded contexts, and will see if our decision holds.
\n", "date_published": "2021-10-05T08:10:22+01:00", "url": "https://www.pascaldevink.nl/2021/09/15/rediscovering-our-domain.html", "tags": ["Software Engineering"] }, { "id": "http://pascaldevink.micro.blog/2021/08/27/rediscovering-our-domain.html", "title": "Rediscovering our domain - DDD central", "content_html": "\n\nFor 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.
\n\nVery 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.\nThis is not a journey for a single post, so this is the first in the series.
\n\nIn 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.
\n\n![\"\"](\"https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/ddd-starter-modelling-process.jpg\")
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.
\n\nDuring 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.
\n\nSo, 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.
\n\nEven 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.\nProbably 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.
\n", "date_published": "2021-08-27T11:59:00+01:00", "url": "https://www.pascaldevink.nl/2021/08/27/rediscovering-our-domain.html", "tags": ["Software Engineering"] }, { "id": "http://pascaldevink.micro.blog/2021/03/02/forgot-to-update.html", "content_html": "Forgot to update on the innovation price Bolster was nominated for: we didn’t win đĽ But fortunately we did have a lot of interesting talks with possible clients since then, so glass half-full I guess đ
\n", "date_published": "2021-03-02T13:21:50+01:00", "url": "https://www.pascaldevink.nl/2021/03/02/forgot-to-update.html" }, { "id": "http://pascaldevink.micro.blog/2021/02/23/super-excited-about.html", "content_html": "Super excited about the finals of the wij.land innovation price this afternoon. Bolster is one of the contenders to the grand prize đ¤
\n", "date_published": "2021-02-23T12:17:54+01:00", "url": "https://www.pascaldevink.nl/2021/02/23/super-excited-about.html" }, { "id": "http://pascaldevink.micro.blog/2021/02/23/late-to-update.html", "content_html": "Late to update my own website and micro.blog, but last month I announced the start of a new adventure: Bolster. It’s a startup I’ve founded together with my partner-in-green Elsbeth. Read more about it all on my LinkedIn announcement, or just visit the website
\n", "date_published": "2021-02-23T11:53:49+01:00", "url": "https://www.pascaldevink.nl/2021/02/23/late-to-update.html" }, { "id": "http://pascaldevink.micro.blog/2020/08/29/walking-with-dogs.html", "content_html": "Walking with dogs can be very mindful. But since we donât have any, we kidnapped @rdohmsâ and went to the sea with her đĽ°
\n\n![\"\"](\"https://cdn.uploads.micro.blog/27237/2020/3430fc74c2.jpg\")
![\"\"](\"https://cdn.uploads.micro.blog/27237/2020/3ae46eeb6f.jpg\")
| I sometimes find myself walking from one meeting where Iâm coaching someone on their career goals, straight into a second meeting where I struggle to string together words to articulate my own.
\n\nLast Friday I had some throat ache. Nothing major, but in these times you need to be careful. So, I took a coronatest and just got the result: I’m negative! I can finally go outside again
\n", "date_published": "2020-08-23T18:56:12+01:00", "url": "https://www.pascaldevink.nl/2020/08/23/last-friday-i.html" }, { "id": "http://pascaldevink.micro.blog/2020/08/21/i-was-having.html", "title": "A film crew as the perfect metaphor for a scrum team", "content_html": "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.
\nPretty 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 đ
\nInterested 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.
\nI 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.Â
\n![\"the](\"https://cdn.uploads.micro.blog/27237/2020/e1572909d2.jpg\" "\\"d4372760-3e75-48c4-ac13-eb67839d5fc0.jpeg\\"")
.
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:
\nThey 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.
\nEveryone 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.
\nNo 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.
\nNot 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.
\nThat 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.
\n", "date_published": "2020-08-21T19:33:48+01:00", "url": "https://www.pascaldevink.nl/2020/08/21/i-was-having.html", "tags": ["Software Engineering"] }, { "id": "http://pascaldevink.micro.blog/2020/08/21/currently-reading-an.html", "content_html": "Currently reading: An Elegant Puzzle: Systems Of Engineering Management by Will Larson đ
\n", "date_published": "2020-08-21T13:43:59+01:00", "url": "https://www.pascaldevink.nl/2020/08/21/currently-reading-an.html" }, { "id": "http://pascaldevink.micro.blog/2020/08/21/fundamentals-of-software.html", "title": "Fundamentals Of Software Architecture: An Engineering Approach", "content_html": "Finished reading: Fundamentals Of Software Architecture: An Engineering Approach by Mark Richards đ
\n\nThis 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.
\n\nOne 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.
\n\nAnother 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.
\n", "date_published": "2020-08-21T13:38:56+01:00", "url": "https://www.pascaldevink.nl/2020/08/21/fundamentals-of-software.html" } ] }