Alexander Mikhailian

A businesswoman once proudly shown me a dumbphone and said that she does not have a personal email, only a corporate one. That persuaded me for a while, until I learned that her husband was prosecuted for money laundering around the same time. So yes, not everyone has email, but those who don't are few and they have very good reasons.

Aside from spam and automated emails, pretty much all email typed interactively in an email client is encrypted between the sender and the receiver.

We could have a long technical discussion here about the opportunistic encryption of STARTTLS or about the market share of Google, Microsoft and Apple, but the reality is that is is protected for all practical purposes that matter to ordinary people. That is, it is impossible to view and modify in transit emails that are written by individuals.

Long gone are the days when you could send a mail from gates@microsoft.com from your personal computer. To start with, port 25 is probably blocked for sending at your ISP. Then, even if you managed to send an email, it will be probably rejected as coming from a residential range of IP addresses. But even if you send a mail from Amazon SES, then the receiving SMTP server will use SPF and DMARC to check if Amazon SES can send emails on behalf of @microsoft.com and it won't.

One thing PHP got right is its 'PHP must die' mode of operation where every request spawns a new process (ok, not a process anymore but still an isolated execution environment that lasts until the response is served.

Java, Ruby, C#, etc are mostly used for application servers and this massively complicates everything.

For an engineer, it feels like one-process-per-request model, even with php-fpm and other optimizations should be much harder to scale than Java applications servers, but the reality is different.

I've spent many years doing PHP and Java-based development. Often times in parallel, having PHP projects on the side and earning money in Java development.

At some point, I had a stint of several years doing exclusively PHP-based work.

Every single time, PHP projects I worked on were serving orders of magnitude more people orders of magnitude cheaper than Java-based projects.

And when I say "orders of magnitude", it is not an exaggeration but sad truth.

I am now in the Java land again, because pay is better. My current project has already burnt several millions serving 20 secretaries that handle 1000 individual cases each year.

My mind is with the PHP project I sold several years ago when it was serving 120,000 people at the cost of a few hundred euros per year + my labor, which was essentially free, but if I could slap my usual daily rate on it, it would still be somewhere between 20,000 and 30,000€/year.

Even this blog is written using Drupal 7, a 14-years old PHP software that still works perfectly well and needs little maintenance. Go find a similar Java piece of software.

Ever since I worked on mailing lists, newsletters and transactional mails I have a habit of looking at mail server logs.

So did I today after sending a mail to the Belgian Foreign Ministry.

Turns out, my mail first passes through the servers of an US-based conglomerate that owns RSA Security, a company that has been publicly caught implementing backdoors for NSA.

Here's the exim mainlog:

diplobel.fed.be R=dnslookup T=remote_smtp H=primary.emea.email.fireeyecloud.com [3.123.5.10]
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="C=US,ST=California,O=Musarubra US LLC,CN=mx.emea.email.fireeyecloud.com" C="250 2.0.0 3yW4eTU-47539-06g0D5C1032540783A662d84a39 mail accepted for delivery"

Yes, 3.123.5.10 is hosted in Germany, but so what?

After 25 years of my career I came to understand that one particular type of programmers is the source of many problems in our industry. Here is the story of a project that was nearly destroyed by two such programmers. One of them was leading frontend development, the other – backend. While the rest of the team was slacking off because business requirements were in the works, these two chaps were working hard.

The frontend lead bootstrapped an Angular mono-repository with NX, Rx and other trendy technologies of the moment. The corporate environment did not lend itself easily to NX, but he pushed hard to solve or circumvent infrastructure problems by working with the domain expert. He set up a workflow that, while having Angular as the base framework, bore little resemblance to the official Angular tutorials.

The backend lead was no less motivated to bootstrap the Spring Boot project according to the corporate guidelines while adding a bit of a personal touch in the form of the Vavr library and a highly sophisticated hierarchy of JPA entities with multiple levels of inheritance, discriminators and generators. He then sprinkled it over with a hierarchy of validators based on both Spring Bean Validation and a third-party validation framework and polished with a trendy testing framework.

The rest of the team observed them in admiration.

I was once hired for a core team job. Between my hire and the first day, the core team manager resigned and I was reassigned, so I did not have much chance to work with him.

Instead, I landed in a middle of a drama. The previous core team manager was a servant leader, delivering bare minimum and helping on administrative and organizational matters. He was the loosing party, preparing to quit and passing affairs. By virtue of being hired by this guy, I was considered his protégé by the new core team manager.

That new manager was operating by decrees, and his first decrees were naturally targeted at everyone who could have undermined his authority, including me. Instead of helping he was setting standards and mandating bills of materials. Older product teams mostly ignored him, but new ones were suffering. By the time I left, the guy had a promotion.

Lesson learnt? Core teams win by imposing, not helping.