Oleksandr Poshtaruk

Hey-hey, folks! Creating app for people who likes to do self-reflection (like me) So facebook-diaries.com is making pdf-diaries from facebook posts. It is still in alfa-testing. Feel free to check (guest can grab last month posts only atm)! Promo: youtube.com/watch?v=zUnnkE…

Kubernetes is beautiful. Every Concept Has a Story, you just don't know it yet. In k8s, you run your app as a pod. It runs your container. Then it crashes, and nobody restarts it. It is just gone. So you use a Deployment. One pod dies and another comes back. You want 3 running, it keeps 3 running. Every pod gets a new IP when it restarts. Another service needs to talk to your app but the IPs keep changing. You cannot hardcode them at scale. So you use a Service. One stable IP that always finds your pods using labels, not IPs. Pods die and come back. The Service does not care. But now you have 10 services and 10 load balancers. Your cloud bill does not care that 6 of them handle almost no traffic. So you use Ingress. One load balancer, all services behind it, smart routing. But Ingress is just rules and nobody executes them. So you add an Ingress Controller. Nginx, Traefik, AWS Load Balancer Controller. Now the rules actually work. Your app needs config so you hardcode it inside the container. Wrong database in staging. Wrong API key in production. You rebuild the image every time config changes. So you use a ConfigMap. Config lives outside the container and gets injected at runtime. Same image runs in dev, staging and production with different configs. But your database password is now sitting in a ConfigMap unencrypted. Anyone with basic kubectl access can read it. That is not a mistake. That is a security incident. So you use a Secret. Sensitive data stored separately with its own access controls. Your image never sees it. Some days 100 users, some days 10,000. You manually scale to 8 pods during the spike and watch them sit idle all night. You cannot babysit your cluster forever. So you use HPA. CPU crosses 70 percent and pods are added automatically. Traffic drops and they scale back down. You are not woken up at 2am anymore. But now your nodes are full and new pods sit in Pending state. HPA did its job. Your cluster had nowhere to put the pods. So you use Karpenter. Pods stuck in Pending and a new node appears automatically. Load drops and the node is removed. You only pay for what you actually use. One pod starts consuming 4GB of memory and nobody told Kubernetes it was not supposed to. It starves every other pod on that node and a cascade begins. One rogue pod with no limits takes down everything around it. So you use Resource Requests and Limits. Requests tell Kubernetes the minimum your pod needs to be scheduled. Limits make sure no pod can steal from everything around it. Your cluster runs predictably.

@ManfredSteyer @analogjs @angular @voidzerodev Yes. I have a GitHub repo with 50 routes and 10K total components in a test application. This is from a cold build on my machine. npm run build-ng Angular w/Application Builder takes 47s npm run build Vite 8 Beta w/oxc Angular Plugin takes 1.5s github.com/brandonroberts…

Most people start learning Kubernetes the wrong way. They see Kubernetes as a list of concepts. Pods. Deployments. Services. Ingress. They memorize them without understanding why they exist. >> You start with a Pod. - A pod runs your container. Simple. Clean. Done. - Until it crashes. - Nobody restarts it. It is just gone. In production, that is not acceptable. >> So you use a Deployment. - A Deployment watches your pods. - One dies, and it creates another. - You want 3 running, it keeps 3 running. - You want to scale to 10; one command does it. Pods were too fragile for production. Deployments fixed that. >> But now you have a new problem. - Every pod gets a new IP when it restarts. - You have 3 pods running your app. - Another service needs to talk to them. - Which IP do you use? They keep changing. - You cannot hardcode them. - You cannot track them at scale. >> So you use a Service. - A Service gives your app one stable IP address. - It finds your pods using labels, not IPs. - Pods die and come back with new IPs. - The Service does not care. - It always finds them. - It also load balances. - Traffic coming in gets distributed across all healthy pods automatically. Pods had unstable IPs. Services fixed that. >> But your app still needs to be accessible from the internet. - So you use a LoadBalancer Service. - This creates a real cloud load balancer. - AWS ALB. Azure LB. GCP LB. - Your app gets a public endpoint. - Works perfectly. Until you have 10 services. - Now you have 10 load balancers. - Each one costs money every single month. - Your cloud bill does not care that 6 of them handle almost no traffic. LoadBalancer Services solved external access. But one per service does not scale. >> So you use Ingress. - One load balancer. All your services behind it. - Ingress routes traffic based on rules. - Request comes in for /api, goes to the API service. - Request comes in for /dashboard, goes to the frontend service. -One entry point. Smart routing. One cloud load balancer on your bill. But Ingress is just a set of rules. Something has to execute those rules. >> So you use an Ingress Controller. - Nginx. Traefik. AWS Load Balancer Controller. - These are the actual engines that read your Ingress rules and make the routing happen. - Ingress without a controller is just a config file nobody reads. To summarize it: > Pod ran your app but had no resilience. > Deployment gave it resilience. > Service gave it a stable address and load balancing. > LoadBalancer Service gave it external access. > Ingress replaced 10 load balancers with one. > Ingress Controller made the rules actually work. Each concept exists because the previous one was not enough.

No. CSRF works because browsers automatically send cookies. However, Authorisation: Bearer isn’t automatically attached by the browser. Without automatic credentials, there’s no classic CSRF attack surface. If you’re using cookies, use CSRF protection. If you’re using header tokens, it’s typically not required. Security comes from understanding the threat model, not copying configurations.

Dependency Inversion is a SOLID principle that says depend on abstractions, not concrete classes. Inversion of Control means shifting object creation and lifecycle management to a framework/container. Dependency Injection is the technique used by IoC containers to inject dependencies into classes (via constructor, setter, or field). 1. Dependency Inversion Principle (DIP) Type: Design Principle (SOLID) High-level modules should NOT depend on low-level modules. Both should depend on abstractions. In simple words: Depend on interfaces, not concrete classes. Without DIP class MySQLDatabase { void save(String data) { System.out.println("Saved to MySQL"); } } class UserService { private MySQLDatabase db = new MySQLDatabase(); // Tight coupling void saveUser(String user) { db. save(user); } } Problem: - UserService tightly coupled to MySQL - Cannot switch to MongoDB / PostgreSQL easily With DIP: interface Database { void save(String data); } class MySQLDatabase implements Database { public void save(String data) { System.out.println("Saved to MySQL"); } } class UserService { private Database db; UserService(Database db) { // Depends on abstraction this.db = db; } void saveUser(String user) { db.save(user); } } - Now we can plug any DB implementation. 2. Inversion of Control (IoC) Type: Design Pattern / Architecture Principle Control of object creation & lifecycle is inverted (shifted) from the application code to a container/framework. Instead of YOU creating objects → Framework creates & manages them. Without IoC UserService service = new UserService(new MySQLDatabase()); You control creation. With IoC (Spring Example) @ Service class UserService { private Database db; public UserService(Database db) { this.db = db; } } Spring Container does: - Create Database bean - Create UserService bean - Inject dependency You don’t control creation anymore. 3. Dependency Injection (DI) Type: Implementation Technique of IoC Dependencies are injected into a class rather than created inside it. DI is HOW IoC is achieved. Types of DI 1. Constructor Injection (Recommended) class UserService { private Database db; UserService(Database db) { this.db = db; } } 2. Setter Injection class UserService { private Database db; void setDatabase(Database db) { this.db = db; } } 3. Field Injection (Spring) @ Autowired private Database db;

Jarred reduces JS memory usage by eliminating a closure.

This is how easy & clean date math will be in JavaScript #JavaScript

The new corner-shape CSS property unlocks exciting new UI patterns. corner-shape: bevel round; border-radius: 1em 0 / 3em 0;

Micro Frontends in Angular and React: A Deep Technical Guide for Scalable Front-End Architecture dzone.com/articles/micro… via @DZoneInc

🔍 You're right—they're completely different! C in ACID (Databases): Consistency = Every transaction moves the database from one valid state to another. All data rules (constraints, triggers) are always followed. It's about internal correctness. C in CAP (Distributed Systems): Consistency = Every node in the system sees the same data at the same time. It's about external uniformity across replicas. Simple analogy: · ACID-C: A bank transfer ensures total money is conserved (rule). · CAP-C: All bank branches show your exact balance instantly (sync). Mixing them up leads to bad architectural choices.

@Armandotrue Maybe scope is too wide?

Opus gets so stupid so fast, it has been struggling on a simple thing with all the necessary context for 30 minutes now

@SantoshYadavDev Opus is good in Angular

Stop memorizing every AWS service. You only need these 13 to run production workloads: Networking: VPC - your private cloud network ALB - traffic distribution across servers Route53 - DNS and domain management Compute: EC2 - virtual servers ECS - Docker container orchestration EKS - managed Kubernetes Lambda - serverless functions Storage & Data: S3 - object storage that scales infinitely RDS - managed databases DynamoDB - nosql database Operations: CloudWatch - monitoring, logs, alerts IAM - access control and permissions Event driven: Lambda: server-less, event driven functions SQS - queuing solution AWS has 200+ services. Most DevOps engineers use these 13 daily and touch maybe 3-6 others occasionally. Focus on understanding how these services work together rather than collecting service knowledge like Pokemon cards.

BTW, adding view transitions is this easy in #Angular:

@SantoshYadavDev @coderabbitai @angular @manekinekko Sounds cool! Congrats, Santosh!

Hey friends, I have an important announcement to make, I am joining @coderabbitai I have been passionate about Open Source since I started contributing to @angular and always dreamed of working as developer advocate because I was inspired by so many people like @manekinekko @AnfibiaCreativa @brandontroberts @John_Papa @adityaoberai @HaimantikaM @marktechson @_davideast @aravindputrevu @samjulien @niklas_wortmann and many more people in the community Thanks to @aravindputrevu for a great interview process and @esthor @HKrackDev for a great conversation. Looking forward to building one of the best Code Review AI tool together dev.to/santoshyadavde…

Interesting AbortController usecase (by Pradip Mandal) linkedin.com/feed/update/ur…

@dvassallo Donald Winnikott tells the same of importance of parents presence for babies in his book "Babies And Their Mothers"

I would never let my babies cry it out regardless of what the “science” says. I remember our pediatrician telling us we should leave the baby crying in the crib even if he throws up from all the crying! Behaviorism has corrupted people’s brains. Maybe there is no lasting trauma from “sleep training”, but I wouldn’t risk it. Unattended crying babies is against nature, and the potential consequences are too high.

@angular You forgot eliminating techdebt

👩‍💻👨‍💻 Shoutout to all the developers using this slower period to update dependencies, refactor code, or learn something new! We salute your dedication!

@KritikaSaini23 Merging 👻

I am a Vibe Coder, scare me with one word.😏