Team velocity
Velocity and story points are underrated. We assign story points during a team meeting where most stakeholders, PMs/POs, and developers are available. Of course, one could argue that prioritization is the sole responsibility of the PM or PO. Depending on your needs, you can always limit who can decide the value of those store points. But as the number of people decreases, then it introduces some arbitrariness. Alternatively, you can let the team vote, and PM has the final saying. At least this way team can bias the PM for being more objective.
Read more...
The snapshot of a memory snapshot for Chrome & Edge
While the web apps slowly replacing desktop apps, they are growing more and more complex which in turn they are becoming more memory intensive.
Perhaps a decade ago a front-end developer wouldn’t much be concerned about possible memory leaks but considering growing the complexity of our applications, analyzing memory leaks is becoming
a necessary skill. For apps that run inside the browser, in particular, Chrome/Edge, your first line of defense (and perhaps the last unless you attempt to debug v8 engine itself)
is the memory snapshot tool. And it is rather surprisingly easy to use. You open your developer tools go to the memory tab and take a snapshot.
The tail of a recursion
When I was younger I used to be scared of recursion. Trying to read some recursive funtion was fine, but writing a recursive algorithm from scratch was rather complicated for me as I’d always fall back to the impertive counter-parts. But after sharpening my skills a bit and doing some reading, now I have the opposite impression. Now recursion is rather easy and imperative ones look more difficult. So if you are challenged by the recursive algorithms like me, read on. I might change your idea.
Demystifying the volatile keyword
After reading Albahar’s excellent free chapter for his book on Threading I have decided to dig the concept of out of order execution further.
Please take a look at the below code and try to guess the output:
Read more...
What the F#!
In a previous post I have explained my motivations for functional programming. It’s no secret I love F# because F# makes me sleep better. In this post, I would like to discuss some different aspects of F#.
F# is gaining independence from .NET
Does Your Code Pass The Turkey Test? (JS Edition)
The credit for the title goes to Jeff Moser and his excellent post which he authored in 2008. He basically discussed the dangers of improper localization and took a clever approach, stating «“The Turkey Test.” It’s very simple: will your code work properly on a person’s machine in or around the country of Turkey?”». The Turkish alphabet is based on Latin letters but there are few interesting properties of the Turkish alphabet such that Jeff proposes if your code works fine in Turkish culture, then chances are good it is resilient to possible localization problems in other cultures using the Latin alphabet. Perhaps this is a bit overstatement as there are too many different languages and alphabets. However, unless we have a specific focus in a particular language or have dedicated people working on each language, in practice it’s next to impossible to have bug-free localization in our applications. In that aspect, I believe the Turkey test is a low effort way to do basic smoke test on localization for your development process.
DDD with Akka Actors
Let’s say you are writing a to-do list application, where users of a company would create tasks where each task has a title and a description. One of the requirements for your application is that the task titles should be unique among all the tasks created regardless of who created them. Also, let’s assume the application is being used by a very large company and there is a lot of concurrent traffic going on.
How would you design your app to fulfill such a constraint? Before reading on I would like you to think about it for a moment.
If you store the data within an ACID-compliant database, you could add a unique constraint to the title column. But aren’t you feeling uncomfortable that we have to rely on an infrastructural entity like a database to fulfill our business need?
Perhaps it is the best solution you can get with the CRUD mentality. The very problem is actually the source of truth, being the database as if the entire application behaves like a dummy mock just to satisfy the database itself, the development becomes database driven. Can we move the source of truth from the database to our application?
In order to move the source of truth to our code perhaps, you would suggest using ORMS. But then I’d say, Objects in OOP won’t help you either. Because what we call an object is just a data structure living on a pile of allocated memory along with a virtual method table for its methods. Such objects are fixed and bound to some physical memory location. Indeed, the objects in OOP are quite low-level constructs and are not good candidates to represent rich domain entities. And we developers deceive ourselves by using ORMs, hydrating the objects, and throwing them out when the request is done. When you have multiple requests targeting the same entities you end up with multiple instances of the same entity and rely on overriding their equality to trick the runtime. The only unique data is within the database rows. I don’t know you, but I feel like it’s just not the real thing. Those objects we hydrate are not truly “alive”. What I would like to have instead “objects” that are alive.
That’s where the actors come into play. By definition, an object in OOP is something that encapsulates state and behavior. Objects expose their behaviors via their methods. Similarly, actors also encapsulate state and behavior. But rather than using methods, you send messages to them to invoke their behaviors.
CRUD Is Not The Answer: Concurrency
We tend to think typical CRUD applications are relatively simple, however, they have one major important caveat, especially if they are web applications. They involve concurrency! Suppose that we have a banking application that allows us to transfer some amount of money from one account to another. The API takes two accounts and the amount of money to be transferred.
Assuming we use a 3 layered conventional approach, at the top, we have a presentation layer but it could also be some sort of web service interface which receives a transfer request. Once the flow lands to our business layer, we do:
1- Go to the database and check if Acount1 has enough balance, to prevent overdrafts.
2- If it is so, decrement the transferred amount from Account1
3- Add the same amount to Acount2
Functional programming: Enemy of the state
A quick google search on “Why functional programming” or “why functional programming matters” will yield insightful results. Having that said, there is still more to add to this topic. And what would be my answer to these questions? One word: purity (or Statelessness). Before delving into purity, let’s dissect the function in the functional programming paradigm.
Read more...
Your domain driven project : Lean software development
In the previous post we have seen how to kick-start the project by discovering our domain. Once we have established our main stories and the relevant acceptance criterias, the next step would be splitting our features/stories to their respective bounded contexts. The concept of bounded context is heavily discussed in any domain driven book, usually typical examples given as a customer concept in one domain meaning one thing, such as an actor buying something, whereas in another context it may refer to an owner of an or target of a delivery. I myself, have a bit more technical and perhaps more vague interpretation of the bounded contexts:
How to start your domain driven project
So you have received your 100 pages of the requirements doc and a presentation has been made about your new project. Now as a developer your job is to translate the business requirements to your code. But where do we start? Architecture you say? System diagrams? Project structure? How about starting from discovering and translating the domain? I assume you are familiar or at least or the term Domain Driven Design.
Domain driven design is not about the layers, is not about your architecture, not about your objects or entities (although entity is fundamental concept in DDD). Domain driven design is about deriving your design from the business domain. We try to build such an aligment between the source code and the other stakeholders, we invent our domain language, that is Ubiquitous Language.
Ubiquitous Language
Domain driven design is rolled around the concept called ubiquitous language. Ubiquitous language is the common language we share, we we talk among other stakeholders.
Common misconceptions about diagnosing memory and CPU problems
As a developer, diagnosing problems is an important skill, almost as important as our developer skills. But misdiagnosing things can lead to more problems. Let’s address some common misconceptions about diagnostics:
Mistake #1: I use task manager processes tab on Windows to find out memory usage for a process
Typically on the windows platform when we are asked how much memory is consumed by a process, what we do is to fire up task manager and look at:
How to diagnose a .net process running inside Kubernetes/docker
Let’s say we have deployed our .net application into a pod that runs in Kubernetes (or a docker container) and somehow our users report some sort of slowness in that application. How do we find out the problem? Let’s find out, step by step!
Read more...
Fable Web Components
Web components allow us to create custom HTML elements with custom behavior. HTML was originally designed primarily for documentation purposes with some form controls. Then by using CSS, we developers attempted to style the page and give the looks that we wanted. With HTML 5, new “web components” came up such as dialog and progress. But they are somewhat limited and due to that HTML language is almost transformed into the assembly language of the web developer. We tend to abstract and stay away from HTML and treat it as a second class citizen where we hook into our shiny SPA web frameworks. We look at the job ads, no one is searching for an HTML developer anymore but they look for React devs, Angular devs, Vue devs. 10 years ago, it was hard to land a job if you didn’t know jQuery, 5 years ago it was Angular that recruiters wanted and the developers have been turned into hamsters running in a circle. Perhaps it is time to revisit the fundamentals, give HTML some respect and treat it as a first-class citizen. Web components are an attempt to give that respect back to it.
In this post, we are going to develop a Modal Window web component.
You can also find the full source here. Although web components are meant to be written via JavaScript, there is no reason not to do it from Fable. This post will also demonstrate some more capabilities (and limitations) of Fable in terms of JavaScript interop.
Read more...