WhatsApp, freaking WhatsApp.
How did this thing become such a standard. How? Why does everyone EXPECT you to have it. They assume that you have it installed on your phone.

'Why don't you respond to my messages? '

'Which messages? '

'The ones I sent you'

'I didn't get any messages. Wait, how did you send them to me? '

'WhatsApp'

'Ah, yeah I don't use that. Wait, where did you even get my phone number from? '

'What? You don't have WhatsApp? Freaking weirdo. '

'bye'

How did an app(lication) become such a standard and why does everyone automatically assume that you have it? And whenever I explain them why I don't use it (Facebook = bad), they just react with 'install it again' (most ridiculous answer) or 'what is wrong with you' or they just give me a confused look and walk away.

A lot of them also act like there were no alternatives (some even better than whatsapp). One of them and probably also the best one is signal. It has all the necessary features a messaging app needs and is also very secure.

Luckily a few of my friends have installed signal and I am currently trying my best at my parents. They have threatened to 'take my phone away if I don't install WhatsApp again' or 'if you don't use WhatsApp then you also don't need a phone'.

Okay finale:

Fuck whatsapp, fuck facebook, fuck ignorance

"secure" messaging apps which aren't open source.

Isn't it common sense that, when you can't check an app for anything because it's closed source (backdoors, vulnerabilities etc), you technically can't be sure whether it's actually secure or not?

And no, I'm not going to trust an app dev on his/her blue fucking eyes on this one.

I love how the Keybase Linux client installs itself straight into /keybase. Unix directory structure guidelines? Oh no, those don't apply to us. And after uninstalling the application they don't even remove the directory. Leaving dirt and not even having the courtesy to clean it up. Their engineers sure are one of a kind.

Also, remember that EFAIL case? I received an email from them at the time, stating some stuff that was about as consistent as their respect for Unix directory structure guidelines. Overtyping straight from said email here:

[…] and our filesystem all do not use PGP.
> whatever that means.

The only time you'll ever use PGP encryption in Keybase is when you're sitting there thinking "Oh, I really want to use legacy PGP encryption."
> Legacy encryption.. yeah right. Just as legacy as Vim is, isn't it?

You have PGP as part of your cryptographic identity.
> OH REALLY?! NO SHIT!!! I ACTIVELY USED 3 OS'S AND FAILED ON 2 BECAUSE OF YOUR SHITTY CLIENT, JUST TO UPLOAD MY FUCKING PUBLIC KEY!!!

You'll want to remove your PGP key from your Keybase identity.
> Hmm, yeah you might want to do so. Not because EFAIL or anything, just because Keybase clearly is a total failure on all levels.

Written quickly,
the Keybase team
> Well that's fucking clear. Could've taken some time to think before hitting "Send" though.

Don't get me wrong, I love the initiatives like this with all my heart, and greatly encourage secure messaging that leverages PGP. But when the implementation sucks this much, I start to ask myself questions about whether I should really trust this thing with my private conversations. Luckily I refrained from uploading my private key to their servers, otherwise I would've been really fucked.

For all the hate that Java gets, this *not rant* is to appreciate the Spring Boot/Cloud & Netty for without them I would not be half as productive as I am at my job.

Just to highlight a few of these life savers:
- Spring security: many features but I will just mention robust authorization out of the box
- Netflix Feign & Hystrix: easy circuit breaking & fallback pattern.
- Spring Data: consistent data access patterns & out of the box functionality regardless of the data source: eg relational & document dbs, redis etc with managed offerings integrations as well. The abstraction here is something to marvel at.
- Spring Boot Actuator: Out of the box health checks that check all integrations: Db, Redis, Mail,Disk, RabbitMQ etc which are crucial for Kubernetes readiness/liveness health checks.
- Spring Cloud Stream: Another abstraction for the messaging layer that decouples application logic from the binder ie could be kafka, rabbitmq etc
- SpringFox Swagger - Fantastic swagger documentation integration that allows always up to date API docs via annotations that can be converted to a swagger.yml if need be.
- Last but not least - Netty: Implementing secure non-blocking network applications is not trivial. This framework has made it easier for us to implement a protocol server on top of UDP using Java & all the support that comes with Spring.

For these & many more am grateful for Java & the big big community of devs that love & support it.

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

Creating most secure messaging tool

My answer to their survey -->

What, if anything, do you most _dislike_ about Firebase In-App Messaging?

Come on, have you sit a normal dev, completely new to this push notification thing and ask him to make run a simple app like the flutter firebase_messaging plugin example? For sure you did not oh dear brain dead moron that found his college degree in a Linux magazine 'Ruby special edition'.

Every-f**kin thing about that Firebase is loose end. I read all Medium articles, your utterly soporific documentation that never ends, I am actually running the flutter plugin example firebase_messaging. Nothing works or is referenced correctly: nothing. You really go blind eyes in life... you guys; right? Oh, there is a flimsy workaround in the 100th post under the Github issue number 10 thousand... lets close the crash report. If I did not change 50 meaningless lines in gradle-what-not files to make your brick-of-puke to work, I did not changed a single one.

I dream of you, looking at all those nonsense config files, with cross side eyes and some small but constant sweat, sweat that stinks piss btw, leaving your eyes because you see the end, the absolute total fuckup coming. The day where all that thick stinky shit will become beyond salvation; blurred by infinite uncontrolled and skewed complexity; your creation, your pathetic brain exposed for us all.

For sure I am not the first one to complain... your whole thing, from the first to last quark that constitute it, is irrelevant; a never ending pile of non sense. Someone with all the world contained sabotage determination would not have done lower. Thank you for making me loose hours down deep your shit show. So appreciated.

The setup is: servers, your crap-as-a-service and some mobile devices. For Christ sake, sending 100 bytes as a little [ beep beep + 'hello kitty' ] is not fucking rocket science. Yet you fuckin push it to be a grinding task ... for eternity!!!

You know what, you should invent and require another, new, useless key-value called 'Registration API Key Plugin ID Service' that we have to generate and sync on two machines, everyday, using something obscure shit like a 'Gradle terminal'. Maybe also you could deprecate another key, rename another one to make things worst and I propose to choose a new hash function that we have to compile ourselves. A good candidate would be a C buggy source code from some random Github hacker... who has injected some platform dependent SIMD code (he works on PowerPC and have not test on x64); you know, the guy you admire because he is so much more lowlife that you and has all the Pokemon on his desk. Well that guy just finished a really really rapid hash function... over GPU in a server less fashion... we have an API for it. Every new user will gain 3ms for every new key. WOW, Imagine the gain over millions of users!!! Push that in the official pipe fucktard!.. What are you waiting for? Wait, no, change the whole service name and infrastructure. Move everything to CLSG (cloud lambda service ... by Google); that is it, brilliant!

And Oh, yeah, to secure the whole void, bury the doc for the new hash under 3000 words, lost between v2, v1 and some other deprecated doc that also have 3000 and are still first result on Google. Finally I think about it, let go the doc, fuck it... a tutorial, for 'weak ass' right.
One last thing, rewrite all your tech in the latest new in house language, split everything in 'femto services' => ( one assembly operation by OS process ) and finally cramp all those in containers... Agile, for sure it has to be Agile. Users will really appreciate the improvements of your mandatory service.

Does anybody here use Keybase.io? I'm looking for a more secure messaging platform for a startup I'm helping build.

EY and ConsenSys announced the formation of the Baseline Protocol with Microsoft which is an open source initiative that combines cryptography, messaging and blockchain to deliver secure and private business processes at low cost via the public Ethereum Mainnet. The protocol will enable confidential and complex collaboration between enterprises without leaving any sensitive data on-chain. The work will be governed by the Ethereum-Oasis Project.

Past approaches to blockchain technology have had difficulty meeting the highest standards of privacy, security and performance required by corporate IT departments. Overcoming these issues is the goal of the Baseline Protocol.

John Wolpert, ConsenSys’ Group Executive for Enterprise Mainnet added, “A lot of people think of blockchains as the place to record transactions. But what if we thought of the Mainnet as middleware? This approach takes advantage of what the Mainnet is good at while avoiding what it’s not good at.”

Source : ConsenSys

Android 13 will Unlock Certain Device Controls even when Locked
Android 13 is the newest operating system that will be available soon. The OS comes with a range of new features, one of which is unlocking certain device controls even when the device is locked. This is a game-changer that will significantly enhance the user experience.

Introduction
The Android operating system has undergone numerous changes since its inception. With every new release, users are treated to new features that enhance the overall user experience. Android 13 is no different, and it promises to revolutionize the way we interact with our devices. One of the most exciting features of Android 13 is unlocking certain device controls even when the device is locked. In this article, we'll take a closer look at this feature and explore its implications for users.

What is Android 13?
Before we delve into the details of Android 13, let's take a moment to understand what it is. Android is an operating system designed primarily for mobile devices such as smartphones and tablets. It was developed by Google and is currently the most widely used mobile operating system in the world. Android 13 is the latest version of this operating system, and it comes with a range of new features that will make it even more user-friendly.

Device Control Access
One of the most exciting features of Android 13 is the ability to access certain device controls even when the device is locked. This means that users will be able to control various functions of their device without having to unlock it. Some of the controls that will be accessible include the flashlight, camera, and voice assistant.

How will it work?
The process of accessing device controls when the device is locked will be straightforward. Users will only need to swipe left on the lock screen to access a new panel that will display the controls. The controls will be easy to use, and users will be able to activate or deactivate them with a single tap. This feature will make it easier for users to perform certain tasks without having to unlock their device.

Implications for Users
The ability to access certain device controls when the device is locked will have several implications for users. Firstly, it will make it easier for users to perform certain tasks quickly. For example, if you need to use the flashlight, you won't have to go through the process of unlocking your device and navigating to the flashlight app. Instead, you can simply access the flashlight control from the lock screen.

Secondly, this feature will enhance the security of the device. By limiting access to certain controls, users can ensure that their device remains secure even when it is locked. For example, the camera control will only be accessible when the device is unlocked, which will prevent unauthorized users from taking pictures or videos.

Other Features of Android 13
Apart from the device control access feature, Android 13 comes with several other exciting features. These include:

Improved Privacy Controls
Android 13 comes with improved privacy controls that give users more control over their data. Users will be able to decide which apps have access to their location, contacts, and other sensitive data.

Enhanced Multitasking
Multitasking has always been a key feature of Android, and Android 13 takes it to the next level. Users will be able to view multiple apps at the same time, making it easier to switch between them.

New Messaging Features
Android 13 comes with new messaging features that will make it easier for users to communicate with their friends and family. These include the ability to react to messages with emojis and the ability to schedule messages.