script.js

Engineers vs. Lawyers⚡️ https://www.youtube.com/watch?v=6RQLMULQndg

Mas’uliyat va mazmun O'zgalar ta'limi mas'uliyatini olar ekan, u ustoz bo'ladi. O'zgalar salomatligi mas'uliyatini olar ekan, u shifokor bo'ladi. Mas'uliyat bilan esa mazmun keladi va mas'uliyatsiz mazmun yo'q. Mazmunli kasb egalari esa ko'p yashaydi. Eng yaxshi inson kim deb Nabiyimiz s.a.v dan so'ralganida - uzoq yashagan va ko'p yaxshiliklar qilgan kishi deb aytganlar. Eng uzoq umr ko'radigan kasb egalari esa ustozlar ekan. Umringiz yanada ziyoda bo'lsin, aziz ustozlar.

Xiaomi cooked this time, for real🔥 https://www.youtube.com/watch?v=0jHtyF_rCqU

Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world, and all there ever will be to know and understand.

- Albert Einstein Ya'ni tasavvur bilimdan muhimroq. Bu nega ko'pchilik backendchilar "dizayni bormi?" deb so'rashlariga javob bo'ladi. Ya'ni siz visual ko'rgan yoki tasavvur qila olgan narsangizni logikasini yaratishda qiynalmaysiz. Agar ko'rmasangiz yoki tasavvur qila olmasangiz logika yo xato bo'ladi yoki tugallanmagan va kamchiliklarga boy bo'ladi. Shuning uchun ham dizaynga shunchaki chizma emas, struktura/logika/qonun/reja sifatida qarash kerak. Komentariyada TZ muhim deb aytib o'tishdi, lekin TZ ham mukammal bo'lmaydi ko'pchilik vaziyatlarda, va buning ham sababi inson biror chizma yoki diagrammasiz kuchli tasavvur qila olmasligida. Va qiziq tarafi, siz bitta misol uchun oddiy formani TZda tushuntirib berishingiz uchun kamida esse yozishingiz kerak, dizayn bilan esa faqat shu formaning o'zi, va balki bir nechta corner case'lar uchun dizaynlar va bo'ldi (U corner case'lar "polyubomu" chiziladi frontendchi uchun). Xullas, men TZ yozish kerakmas demayman, lekin TZ o'zi yetarli bo'lmaydi ko'p holatlarda. Dizayn bizga productni his qilishga imkon beradi. Qilayotgan ishimiz kutuvlarga qanchalik mos borayotganini o'lchashimizga ham juda zarur. Men dizayn birinchi qilinishi tarafdoriman. Va backendchilar dizaynni so'rab olishlarini ham qo'llab-quvvatlayman.

Maqola yozmoqchiman. Lekin oldin boshqalarni fikrini bilishni xohladim. Savol: yangi proyekt boshlayabsiz, birinchi bo'lib dizayn chizdirish to'g'rimi yoki backend yozgan ma'qulmi? Bu xuddi backend dizaynga qarab yoziladimi yoki dizayn backend logikasiga qarab chiziladimi deganday gap🙂

Crypto ishlatmaydigan og'alar: we are safe🙂 https://www.youtube.com/watch?v=QVqIx-Y8s-s

Dear Linux users, Don't drink wine. Use Wine! Sincerely yours.

I still use you...

Hey, look what I've cooked :)

Apple taqdimotiga yaqin shu videoni ko'rgim kelaveradi🥲

In a recent interview I was asked: "How would you migrate a live platform from Postgres to MySQL without downtime or data loss?" At that moment, I didn't give a strong enough answer. But after the interview, I dug deeper and here's what I found: the core challenge is that the database is constantly serving reads and writes. You can't just export/import and call it a day. The solution comes down to two steps: 1. Backfill the data: Take a consistent snapshot of Postgres and load it into MySQL. 2. Stream ongoing changes: use Change Data Capture (CDC) from Postgres WAL to MySQL so the replica stays in sync. Once MySQL is nearly caught up, you can cut over by: ● Using dual-writes in the application for a short period ● Switching reads to MySQL gradually behind a feature flag ● Validating data consistency with counts, checksums, or shadow reads After confidence builds, Postgres can be retired. Key lessons I learned while researching: 1) Migration isn't just about moving data, it's about handling constraints, indexes, and type differences. 2) You always need a rollback strategy if things go wrong. 3) Feature flags and dual-writes are powerful tools to reduce risk. I didn't answer this well in the interview, but I walked away with a much clearer understanding. Sometimes the best lessons come after the hard questions. ©️ LinkedIn

Sam Altman Has Lost Touch With Reality And it's happening in plain sight (Disclaimer: This is not personal. It’s business, economics, and finance. Sanity versus delusion. We are living through a modern update to Charles Mackay’s Extraordinary Popular Delusions and the Madness of Crowds (1841). “You should expect OpenAI to spend trillions of dollars... Economists will wring their hands and say, ‘This is crazy, reckless.’ And we’ll just be like, ‘You know what? Let us do our thing.’” — Sam Altman¹ OpenAI lost $5B last year on $3.7B in revenue¹⁰. Now Altman wants to spend $7 trillion on AI servers. The insane math: More than Germany’s entire GDP³ 13x the global semiconductor industry’s total revenue⁴ Enough to fund U.S. universal healthcare for 2+ years⁵ Meanwhile, reality: 58% of Gen Z graduates can’t find work⁶ U.S. youth unemployment jumped 2.8% in one year⁷ 4.3 million young people are NEETs (Not in Employment, Education, or Training)⁸ In China, youth unemployment hit 46.5% before data suppression⁹ That’s the world Sam Altman thinks needs trillions of GPUs, not jobs. What $7T could actually build: Clean water access for every human being Universal healthcare for multiple countries World-class education systems globally Comprehensive youth employment programs Instead? More servers to make chatbots marginally better. And the kicker: GPT-5, released last week, was widely criticized as merely “incremental improvements”—not revolutionary breakthroughs¹¹. If hundreds of millions produce minor upgrades, what will trillions do beyond enriching hardware manufacturers? "And this time it's not different". It never is. ©️ LinkedIn

The real serverless compute to database connection problem, solved - Vercel https://vercel.com/blog/the-real-serverless-compute-to-database-connection-problem-solved

What is a Type Guard? A type guard is how TypeScript narrows a union type or unknown type to something more specific. Example:

function printLength(value: string | string[]) {
  if (typeof value === "string") {
    // Here TypeScript knows: value is string
    console.log(value.length);
  } else {
    // Here: value is string[]
    console.log(value.length); // array length
  }
}

2. Built-in Type Guards a) typeof (works for primitive types):

function logValue(x: number | string) {
  if (typeof x === "string") {
    console.log(x.toUpperCase()); // string methods OK
  } else {
    console.log(x.toFixed(2)); // number methods OK
  }
}

b) instanceof (checks if a value is an instance of a class/constructor):

class Dog { bark() {} }
class Cat { meow() {} }

function makeSound(animal: Dog | Cat) {
  if (animal instanceof Dog) {
    animal.bark();
  } else {
    animal.meow();
  }
}

c) Property check: "prop" in obj

type Car = { wheels: number };
type Boat = { sails: number };

function move(vehicle: Car | Boat) {
  if ("wheels" in vehicle) {
    console.log(`Car with ${vehicle.wheels} wheels`);
  } else {
    console.log(`Boat with ${vehicle.sails} sails`);
  }
}

d) Equality checks (when comparing with literals, TS narrows types):

type Direction = "up" | "down";
function move(dir: Direction) {
  if (dir === "up") {
    // dir is "up" here
  } else {
    // dir is "down" here
  }
}

3. Custom Type Guards (val is Type)

function isString(value: unknown): value is string {
  return typeof value === "string";
}

function printUpperCase(value: unknown) {
  if (isString(value)) {
    // value is now string here
    console.log(value.toUpperCase());
  }
}

Complex example:

interface User {
  id: number;
  name: string;
}

function isUser(obj: any): obj is User {
  return typeof obj?.id === "number" && typeof obj?.name === "string";
}

function greet(data: unknown) {
  if (isUser(data)) {
    console.log(`Hello ${data.name}`);
  } else {
    console.log("Not a valid user");
  }
}

4. Real-world Use Cases a) Parsing JSON

type Product = { id: string; price: number };

function isProduct(obj: any): obj is Product {
  return typeof obj.id === "string" && typeof obj.price === "number";
}

const raw = '{"id": "A1", "price": 99}';
const parsed: unknown = JSON.parse(raw);

if (isProduct(parsed)) {
  console.log(parsed.price * 2);
} else {
  console.error("Invalid product data");
}

b) Working with APIs

async function fetchUser(id: number): Promise<User | { error: string }> {
  const res = await fetch(`/users/${id}`);
  return res.json();
}

function isErrorResponse(obj: any): obj is { error: string } {
  return typeof obj?.error === "string";
}

async function showUser(id: number) {
  const data = await fetchUser(id);
  if (isErrorResponse(data)) {
    console.error(data.error);
  } else {
    console.log(`User: ${data.name}`);
  }
}

If you’re designing a database for something small today but expect it to grow, think beyond just "what works now". Start with clear naming conventions so new developers can understand it instantly. Normalize where it makes sense, but don’t overcomplicate - some duplication can save you pain at scale. Use UUIDs or other non-sequential IDs if you anticipate sharding or merging data later. Plan indexes early, but don’t add too many - they speed up reads but slow down writes. Think about how you’ll handle archiving old data, because tables that just keep growing will eventually hurt performance. And always leave room for optional fields or relations you might not need today, but will probably need tomorrow. ©️ LinkedIn

©️ LinkedIn

https://arktype.io/ ishlatib ko'ryapman, menga yoqyapti🙂