Plans for 2021

1. Move from Chrome based browsers to Firefox. 
2. Build an OpenCore hackintosh
3. Get rid of windows on my laptop
4. Finish AWS training
5. Finish Kubernetes cluster
6. Walk
7. Climb up on Retezat
8. Go to Oravita - Anina
9. Clean the basement
10. Finish the Internet radio on RPi

December

Learning Norwegian. 

Learning Kubernetes

Wondering...

Wandering.

Reading books.

Funny

 

Untitled

Red sun behind

Canon no more...

Fabula

 Orice asemanare cu realitatea nu e neaparat intamplatoare :

 

 

In aceeasi ordine de idei, ginusa i-a  convins pe cativa purcei sa deschida restaurantul.

Treaba mergea bine, erau vanzari si gratarele faceau profit maxim.

Vazand cat de bine merg lucrurile purceii  au pus-o pus pe gainusa sa se implice in CI-ul de la bucatarie –unde se declarase specialista, in paza si protectie (securitate) unde parea competenta, in retetele preparatelor (design si arhitectura) unde a redus cantitatea de oua… 

Pe partea de performanta gainusa a decis ca viteza e invers poportionala cu numarul de bucatarii asa ca a inceput sa gateasca fiecare fel intr-o bucatarie separata.

La un moment dat deoarece se plictisise si cauta “noi incercari”, mai ales dupa ce retetele de clatite (fara oua) au esuat, iar hotii au furat tot ceea ce purceii au agonisit deoarece usile proiectate de gainusa permiteau deschiderea din exterior in orice situatie, gainusa s-a hotarat sa plece.

Asa ca si-a luat tricoul:

Si le-a spus purceilor “Paaaaa!”

Purceii au ramas dezorientati si fara idei. Ce sa faca mai departe?

S-au gandit sa caute niste purcei mai vechi, cu abilitati – dar ei plecasera cand gainusa le-a luat pozitiile, sau chiar devenisera gratar intre timp.

S-au gandit sa promoveze purcei tineri – dar de la cine sa invete, iar sa aduci o alta gainusa de afara s-ar fi ajuns la exact situatia initiala.

Morala: Nu taiati toti purceii. Nu ascultati toate gainusele.

 

 

Architectural Politics

 

I have recently read "Fundamentals of Software Architecture" by Mark Richards and Neal Ford. The book is nicely written, clearly in Neal Ford's style. There are some points that the book rises and I have some comments on

It begins with enumerating the traits of an architect. One of them is called "Understand and navigate politics". The authors discuss how the decisions of an architect are often challenged while the decision of a developer are almost never challenged and express the difference between the stakeholders that these roles work with.

In my opinion the architect has another problem, of a higher magnitude than trying to get its decisions approved. There is a problem of loyalty. To whom should an architect be faithful? Being faithful to the development team will generally help improve the technical aspects of the project. Being faithful to the business will increase the chances of a project that fits the market better. This would be the ideal situation but there is never such of a black-and-white situation. Business might be undecided with features, development team unruly, other parts of the enterprise or other projects start to mingle in. All the decisions taken in these situation will impact the attachment of the stakeholder to the architect as they will be perceived as loyalty oaths to one or other of the stakeholders.

One of the most vivid images that come to my mind is the image of the French diplomat Talleyrand. He has served in successive antagonistic regimes in the same high caliber position. Is that what an architect is supposed to be? Should one change its mind often and accept requests just for career sake? Should one reject everything just to prove its point? Projects are not architecture driven but wrong architecture will influence the project longterm. An architect should be granted a high degree of autonomy and authority in order to keep the balance between acceptance and rejection of requests in the project stable. Still, although autonomous one shall be loyal and steady. In the book these aspects are not covered, the organisations that the authors use as examples are quasi-ideal, streamlined. In reality the most problems are in contorted, ever-changing and reinventing themselves enterprises.

Another aspect that is important, the book doesn't insist on it, is the relation with other projects in the enterprise. There are always parallel projects that have either convergent or divergent stakes and conflicting stakeholders. It would be nice to be able to diplomatically sort things out but it is not possible sometimes. The relation with other architects can be modelled as a "Texas Hold'em Poker". The private cards of a player are connected to the personal goals. It's a good thing to know your peers, to understand their needs and drives and act for a common good.

Collaboration, mutual help and reasonable compromise are beneficial. Those can help several projects advance at once. Steering of several architects is hard and the role of "primus inter pares" should be taken by a respected member of the group, one who has large autonomy and also authority at corporate level. Otherwise hierarchies of architects will just increase tension and brittleness of the organisation.

One should avoid being a secondary architect in a project because this will create two major issues: loss of autonomy for both architects and secondly it will create raptures both inside the team and among stakeholders - parts of development team will favour one or the other and also the stakeholders will prefer one or the other. There will never be consensus and the phenomenon of "pluralistic ignorance" (as the authors name it) will be prevalent thus adding more strain to the project. Help a younger architect if he/she asks for help but never go oversee or accept to be assigned as a shepherd dog because the risk there is to break the younger architect's wings and reduce his/her confidence in the decisions taken. Coaching younger architects is again not covered in the book although coaching developers is pretty well captured.

No technical career path worth dealing too much with politics. In the end inside a corporation we are all small Sisyphus-like beings pushing a rock upwards again and again. Loyalty should be invested in those who deserve it, adherence to principles should be a guiding force for decisions as one cannot have principles and stakes at the same time.

“Hold faithfulness and sincerity as first principles.” (Confucius) - this will compensate any politics failure. If one is right and unbiased, the political failures caused by standing in for principles will probably pay back later. For me, being a Talleyrand, is one of the worst situations an architect can be in.

Blog maintenance

I should probably upkeep my blog because:
- many links and media seem broken
- shbrush syntax highlighter stopped working updated to highlight.js served from cdn
- many unpublished drafts

Chan vs Sama

Created on 2020-05-01 08:42

Published on 2020-05-01 10:03

The way one addresses others is very much culture dependant. This can range from the extremely formal Japanese expressions in the domain of "chan" (dear little) to "sama" (most honorable), to less formal languages as English where addressing is somehow less strict - although British subjects don't use "Dear Queenie/Hi Lizzie" nor Japanese start a letter with "Naruhito-chan".

So what are the limits of politeness/familiarity on LinkedIn? How does one starts an invitation to an unknown person? What about a letter to a known one? I am not a native English speaker so most of the formal English knowledge I have comes from books, but so are many other people that use English for business purposes. I have learnt that every language has several functional styles that are used in diverse situations - science, law, newspapers, literature, business. In my own view LinkedIn is a business environment where business partners meet. They can meet for the first time or they might know each other for long, but still they are in a business environment - therefore a business functional style should be adopted on this kind of communication.

The first action inside the network is the invite. How would you invite another person to join your network? Do you know him/her in person? Does he/she knows you? It's a pity that LinkedIn permits empty invitation messages because they reduce the empathy levels between those who want to connect. Very seldom people bother to write personalised invitation messages and explain their goal for connecting. This is especially true for some headhunters who expect automatic acceptance of their empty invites. To be a little harsh - candidates are expected to send cover letters, wouldn't it be fair to ask the same from recruiters?

On the other hand there are people who write something in their invite messages. This can range from very formal "Dear Sir/Madam" to the "Dear Robert". This is very much country/industry dependent but as a rule it's better to be more formal when you don't know the person you are talking to.

In the meanwhile there are over-friendly invites - I for one received "Querido Danielito" and "Dragă Dani" from persons I have never met. Are those okay? I would hardly think so. There are many LinkedIn etiquette related posts online and most of them are common sense rules that help one find appropriate tone and style. As an exercise of imagination - how would Lincoln start the famous "Bixby Letter"? With "Dear Madam" or "Hi Lydia". Indeed some things changed but some of them not so much and although globalisation relaxed the norms it is still okay to use a business-casual style on written documents. I am coming from a cultural background where people address each-other on their given name only after some mutual agreement (see the last paragraph of this article) and hence I do appreciate an initial degree of formalism. I am not absurd and I understand that "Hi/Dear Daniel" is acceptable but from there to "Dani" (which is not by the way a short name that I use) it's quite a lot of way to go.

So, culturally speaking, it is better to do a small research before starting a letter and choose the apropriate tone, style and expressions. Because: "Utlänning - Främling - Ramen - Varelse"

Easter date differences

Created on 2020-04-12 07:22

Published on 2020-04-12 08:20

Many of my colleagues in Germany, Netherlands and US are surprised by the fact that there are two Easter dates therefore two disjoint sets of vacation days. One for the western, Catholic world, and one for the eastern, Orthodox world. The explanation for this is in fact very interesting and comprises a lot of mathematics and history.

The Catholic Easter is computed as the first Sunday after the first full moon on or after the March Equinox. Seems simple but in fact this is just a little bit more complicated. The synodal moon period is 29.530588 days hence there is not a constant day of month for occurrence, the first full moon Sunday after March 20/21 could be as late as April 18.

The western world started using Gregorian calendar from 1528 but the Orthodox countries kept using the Julian calendar that is 13 days behind. The formula is basically the same but there is the Julian offset to be counted in. Moreover Orthodox Church has a third condition, given by the 1st Ecumenical Council of Nicaea held in 325, that states that the Easter should be after the Jewish Passover (Passover is on Nissan 14th, date computed on a lunar calendar). As Passover is one week long and is computed similarly to the Catholic Easter this can push the Orthodox Easter date to May. The difference between the two can be up to a month. For example if in 2020 the Catholic Easter is on April 12 and Orthodox Easter is on April 19, in 2024 the dates will be be March 31 and May 5. However, sometimes the two dates could be equal, last time in 2017 and next time in 2025.

Now for the geeks, computing Easter date is a very interesting coding kata. Implementations rely on moon phase determination (math) and the Gregorian/Julian conversions (math and history).

Java and .NET provide pretty good mechanisms and there is a plethora of libraries for other languages. The calculation of Easter date was called "Computus" in Latin (https://en.wikipedia.org/wiki/Computus) and might be the etymon for Computer, hence the Computer Science has a very interesting origin. The wiki page offers quite a lot of information and starting points (Gauss algorithm, tabular representations, ...) so during self-isolation boredom one can try something interesting. As a side note, the Julian calendar seems to be related to the works of St. Dionysius Exiguus, a monk born in present-day Romania, so probably the bugs in the Julian calendar are also his fault.

The Minitel Paradox

Created on 2020-03-27 07:06

Published on 2020-03-27 07:47

Minitel was great. It was internet before internet. I was envious on Minitel as a kid and as a teenager because I was able to read about it therefore I was dreaming of using it someday. Minitel was an tightly integrated solution that was sized precisely for its purpose. The terminal, the access network, the services were perfectly matched together. The overall usage experience was great.

In the meanwhile, before web, there was a myriad of BBS solutions, more or less reliable, more or less updated. The experience of using them was ranging from "meh" to awful. But they were not integrated at all, they had no specific access network, terminals and servers could be run on any hardware. It was mostly patchworks but the system worked. Then the "black swan" event happened and, in almost no time, WWW and internet emerged globally. The BBS systems rapidly evolved in browsers and websites, access networks transitioned from dial-up to fast FO or 4G. And everything evolved to what we have today.

The highly integrated Minitel stayed the same in the '90s and after, not being able to keep up with the rapid developments of web. Sadly, it was finally shut down in 2012. Minitel's flaw was that it was too well engineered. That it had perfectly fitted parts. But when everything works as expected there is no drive to change it. It is better to have in some situations sub-optimal parts but clear and open interfaces because this forces evolution. And evolution leads to survivable systems.

This was a long intro. My story today is about very skilled friend that created microservice templates with everything built-in. They were batteries included, as Minitel once was. Everything was inside, whether one was using it or not and integration in the system required that every microservice having the same structure. A perfect match. Almost as good as Minitel. My opinion on his idea was: "Let there be chaos". Create interfaces and let service developers hook into them as necessary because it is hard to control business needs and technology stack evolution. Hence both implementations and interfaces can evolve separately. It would be an evolutionary patchwork as with internet. The only restriction is to keep interfaces open. His templates were fantastic. Out of the box messaging, smart logging and metrics, Kubernetes ready - checked, any nowadays technology was there with a clear scope - current business needs. But, as I remarked to him - current business needs, interfaces and contracts were defined inside template not outside of it, changing an interface required to rebuild all the services or creating many adapters that in the end will require more mapping an translation logic.

Coming back to my debate, on a smaller scale keeping his solution will work flawlessly for a while but it won't evolve. It will freeze the technology stack and it will break "Favor composition over inheritance" dogma - because the system will hardly find spare parts that fit together and can sustain the evolution. Also skill sets evolve from ANSI control codes in BBS to React. It's uncommon to find ANSI gurus in the younger generations.

If we raise the question "How would a Minitel world respond to COVID-19 situation? Home office use cases, collaboration, and so forth?" Would it be even possible? My guess would be: NO. Because the associated costs of changing a tightly integrated solution would be times higher than changing parts of a heterogeneous and open solution (imagine the costs of changing every terminal and link at a global scale).

Engineering systems should find balance between perfect and perfectible and accept perfectible yet incomplete components and as architects we should deal with evolvability as one of the important NFRs.

Interestingly, Minitel started evolving after it's shutdown in 2012 when open innovation was possible: https://opendna.com/blog/2012/06/30/the-end-of-minitel-its-past-and-our-future/

Cloud Servers

Although GCP, AWS and Azure are mainstream and feature packed they are pricy.

For my personal needs I had to chose something that could fit in 10 EUR/month.

I had to choose between Digital Ocean, Scaleway and Hetzner.

Digital ocean sucks - their price/features ratio is awful. 

Hetzner offers the best price/features on their machines. 

On the other hand Scaleway offers more services at PaaS level as ObjectStorage and load balancers.

I went for Scaleway as it's a very balanced offering.

  

PXE Rescue

One of these days I realised that one of the servers I am managing is no longer accessible. The machine was completely unresponsive on every protocol. I had no physical access to it. Fortunately I was able to connect to another machine in the same subnet in the datacenter. From there I was able to connect to the defective machine's BMC using ipmitool.

Having access to ipmi granted me access to serial console and ability to power cycle the machine.
So, I had access to the server but I couldn't use KVM's virtual media as the newer browsers have no support for Java. So the only option I had was to PXE boot the machine. I have followed the instructions from http://www.system-rescue-cd.org/manual/PXE_network_booting/. Subsequently I configured an NginX webserver to serve content on the local subnet.

The first attempts to boot the system failed because IPMI sol is, as expected, a serial console. I adjusted the configuration file to have a serial console at boot time and I was able to boot the machine .

From there rebuilding the disk array and restoring the image from a backup was straightforward.

However one of the most important failures for me was the inability of using iLO's remote console due to Java's deprecation of NPAPI in browsers. Currently there is almost no possibility to substitute this functionality with other tools and vendors do not rush with alternatives even for more modern machines. The basic IPMI/RBMC tools lack many features as virtual media or frame buffer emulation. With Java no longer supported in the browsers I won't be able to access the iLO interface on my home server which is truly a major setback.

The files andmodifications are here: https://github.com/dvoina/pxe_rescue