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

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.

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. 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).

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"

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