Musings on IT and programming

  In previous Posts the security context was too simple so I’ve expanded it to represent which principals are involved as handling authentication is outside of the scope of this exercise which is already going too long. I’ve also added the storage, potential backups and encryption keys to the security context. The next step is defining the message formats that will be used by the Owner. Having stated that many items could be stored on a single interaction and copying part of the design of John Crickett the following class diagram represents the request and responses for both Store and Remove operations. A map of DataElements and tokens is used to be able to know which values were successfully processed in both operations. While the internal messages are represented on the following class diagram. So with this now we can start coding which will be on the next Post Part 1 Part 2

  This is part 2 of a series Design in Public, in the prior post I did a drill down on the requirements that are interesting for me. Store Private Data for the Owner Allow Private Data Owner to delete Private Data from the System thus disabling further use in the future. Allow only internal Principals to retrieve it for a particular flow All interactions from internal Principals where Private Data is wanted but not available anymore should be able know that it was deleted, who was the Owner and when it was Deleted To store private data there is normally more than one type of information that is stored, for example Addresses, emails, phone numbers, Full Names, Social Security Numbers, Card number (Primary Account Number), Expiry Date. The number of interactions with the system could be modeled as 1 interaction per Data element or to be able to send multiple data elements on a single interaction. Allowing the client to decide how to implement this is better in this scenario s

A couple of things have changed since the last time I had to be on a job hunt. The most prominent one is the 'Honorary' title that we use as Software Engineers. This might be localized to Mexican software industry though. Seems that I was doing Staff stuff without being aware. When I first started, a senior developer might have been a Terminal role on many places meaning that there was nothing above that a coder could aspire to besides jumping to management side. There were specializations in fields like databases, business analysis or architecture but it felt as we were all on the same spot. Then I landed on a consultancy firm that had a more structured approach but still it was a single ladder that went from trainee, various levels of seniority and then something called Consultant with at least 3 different levels; advisor, full and senior if I remember correctly. Still there were specializations but it was simple enough. Consultant was something of a broad term for so

There are a couple of pet peeves I've acquired while interviewing for a while, the first is about advice given to job seekers while the second is about tools used by recruiters.  Many boards, influencers and head hunters recommend customizing CVs for each application and to do background checks on the prospect companies. This would be good if it wasn't really time consuming and the probability of landing the job was high. On current state of affairs a job seeker will be doing hundredths of applications, I've done this, to even get to a human is probably around 1 in every 50 applications, to pass to the second round it is 1 on every 20 most likely and then depending on role and organization there might be two or three rounds of interviews which means a very low probability per submission. Each tweak to CV or org review will take at minimum 20 minutes and probably longer if done thoroughly. So imagine that a candidate is doing the updates for 100 positions, which

This will probably be a series of posts as it is not as simple as it seems. A topic that has been recurring during my working life is a way to securely store information and make it available to the roles that actually have job requirements to use said information. John Crickett posted this on his coding challenges substack a couple of weeks ago. https://codingchallenges.substack.com/p/coding-challenge-48-data-privacy I quite like his approach and I’ve seen some variations of it being used in production at various places. Although I believe a little bit of context is missing as there might be many use cases for a privacy vault. One of them is storing Personal Identifiable Information (PII) where the User providing that information does not need to know there is a tokenization process in the underlying system as it would be really odd to see a token on the user interface instead of their name. On the other hand, printing a social security number which has regulations in place is a comp

This is a loaded topic. Duplicated code can arise from multiple causes and has different forms that affect in subtle but damaging ways. Though not all duplication is bad per se but it depends in how it affects development processes. Some of these duplication are made by authors trying to cut corners or replicating the same work but on different parts of the system. Copy paste is rampant everywhere and it might be done on any project and technology for multiple reasons, it might be that html tags need to be repeated, SQL queries that have pretty similar structure with different values, CSS definitions on multiple files. The problem here is how to know this is happening and that it is negatively affecting the team. Files can be statically analyzed and have the abstract syntax tree compared with many tools, some of those can be plugged as checks to the CI/CD pipelines, but this will only give you a number that must be evaluated to know if it is on a harmful range or not. For a given langu

Complexity is a topic that causes headaches to all involved.  Teams suffer it daily, managers must take decisions to overcome it, stakeholders tend to look it on a different way than engineering and operators. The main problem is the dimensionality and different perspectives that each group has.  Getting on the same page is also hard as similar projects might have different perception just by having different people involved or being in a different culture.  What might be simple in a contex might be complex and difficult on another one. To be able to assess how complex a project might be and to have a common ground with all other stakeholders a qualitative and a quantitative approach are needed.  The qualitative might be graphic in nature, pictures are very useful visualize where the complexity is coming from.  Normally we tend to focus on component diagrams as the following ones which represent the same system with increasing levels of detail.  But you can keep on going on details and