Month: April 2018

Bounded design

Szymon Kulec 'Scooletz' Architecture, Design ,

If you wake up a Domain Driven Design fan and scream the word “Bounded” the answer will be immediate and always the same: “Context”. It’s funny that this word is having so much trouble in leaving DDD context. I’d like to encourage you for broadening it a little bit, to a design, architecture space.

Reality strikes back

It’s quite interesting that often, when we hit a limitation of a service of any kind, the first reaction is negative. Probably you heard statements similar to these:

  • Why did they set the value at this level?
  • I want to be able to put a transaction on top of anything
  • I don’t need to change my design. It’s their fault that the created a service that sucks

I’m not writing about malicious providers claiming, that they do something when they don’t. I’m talking about a well described limitations that you can find in a documentation of a tool that you’re using. You can try to kick the wall, but still, the limitation will be  there. The better question to ask is why?

Limit to profit

Every limitation that you put in your service provides more space for designing it. Let’s take into consideration a supported type of data for a custom database. If all values and keys could be only of type int (4 bytes), then I would not need to care about variable lengths of buffers used for storing them! Every pair of a key and a value would be written on 8 bytes! And this is memory aligned as well! And this and that. Let’s see another example.

Often, when using cloud databases there’s a notion of a partition or a shard. You are promised to have some kind of transactionality within one partition, but you can’t use one transaction across partitions. Again, you may raise all the blaming questions, or think about partition as a unit of a scalability. Imagine that you’d have to store all the data of a single database on one machine. That’s at least highly inefficient. Now think. You create partitions from the very beginning. They can be moved to other machines, as all the data of one partition resides on one machine (this is implication, so multiple partitions can reside on the same machine). This could be a game changer, especially, if you’re writing a cloud service like Azure Storage Tables.

Summary

You can see the pattern now. Behind majority of these limitations, are some design decisions. They were made to make a service work. Of course there are probably some sloppy ones, but still, whenever you see a limitation like this, think about it. Then, design your solution accordingly.

On getting things done

Szymon Kulec 'Scooletz' Personal , ,

It’s the 6th month of me using one of the tasks management tools. I must say, that even if I raised several cases how the tool could be improved, the methodology of putting things in the inbox, grooming them and then executing already proved itself. Sure, from time to time a ball is being dropped, but it’s so much better than it was in the past. Let me share how I approach it.

Inbox

I use an inbox. Sometimes it’s easier to put a task in there rather than think where it belongs. These will be clarified later.

Projects

Different projects for different parts of my activities. There’s a “Life” project (I hope that this one will last for some time), which covers my personal things. There’s a “House” project that holds all the items that should be done in-da-house. There are different initiatives, like DotNetos, that are projects on their own. There’s a list of movies to watch and a list of presentations/courses to take. For books, I use my trustworthy goodreads account.

On grooming and setting dates

I try not to spend a lot of time on selecting things to do. My preferred approach is to put a date on it (if I know it). On a given day, it will magically appear in my things that need to be done. Once a week I review the lists and select what to do next. Sometimes, because of setting dates, there’s not that much to do – things are assigned for the forthcoming day/week.

Burning tasks

Of course there are still task that are not closed fast enough. I spent over 30 years of my life practicing getting things done without this system, so the change won’t happen in one day 🙂 Still, the fact that number of dropped balls is getting lower and lower (with the new approach, they are not forgotten, but sometimes might be dragging).

Tooling

It looks that there’s no perfect tool for my needs and every single one requires some bending. I might consider writing an extension to the public API, if I truly need it, but for sure, I won’t be spending time on trying “all these other apps”.

Future

The future is bright 🙂 I’m doing more, I’m forgetting less and there’s a still room for some improvement! Let me just check the tasks for today… Oh yes, there’s one about improving the process itself 😉