fmt & lint

data/keyboards.json

@@ -60,6 +60,6 @@
       "image": "https://i.rtings.com/assets/products/MSgrVKR1/keychron-k3-version-2/design-medium.jpg",
       "url": "https://www.keychron.com/products/keychron-k3-wireless-mechanical-keyboard",
       "key": "65%"
-    },
+    }
   ]
 }

posts/mysql-va-olib-borayotgan-mariadb.md

@@ -26,13 +26,9 @@ Hamjamiyat: MySQLdan farqli o‘laroq MariaDB Oracleʼdan ko‘ra ko‘proq hamj
 **Texnik farqlar:**
 
 1.  Tezlik: MariaDBʼning MySQLʼga nisbatan eng muhim afzalligi uning tezligi va ishlashidir. Replikatsiya va so‘rovlarni bajarish haqida gap ketganda, MariaDB MySQLʼga qaraganda tezroq. Bundan tashqari MariaDB bir vaqtda juda ko‘plab ulanishlarni qo‘llay oladi.
-
 2.  Xavfsizlik: MySQL parol xavfsizligini tekshirish va oshirish uchun ishlatiladigan validate_password komponenti bilan birga keladi. MariaDB, o‘z navbatida, foydalanuvchilarga maʼlumotlar bazasini boshqarishda ko‘proq xavfsizlikni taʼminlaydigan turli xil parolni tekshirish plaginlarini taklif qiladi.
-
 3.  Shifrlash: MySQL vaqtinchalik jadvallarni va ikkilik sanoq tizimiga asoslangan loglarni shifrlamaydi. Boshqa tomondan, MariaDB ikkilik loglarni shifrlash va vaqtinchalik jadval shifrlashni qo‘llab-quvvatlaydi.
-
 4.  Maʼlumotlarni saqlash mexanizmlari: MariaDB Blackhole, CSV, XtraDB, Aria, InnoDB, Archive, MariaDB ColumnStore, Connect, Cassandra Storage Engine va boshqalar ko‘plab mexanizmlarni qo‘llab-quvvatlaydi. MySQLʼda qo‘llab-quvvatlanadigan saqlash mexanizmlari esa MyISAM, Merge, Federated, InnoDB, Archive, Memory, CSV, Blackhole va Example hisoblanadi.
-
 
 Ochiq mabalar: MariaDB to‘liq paketni taqdim etadi, MySQL esa maʼlum cheklovlar bilan birga keladi.
 
@@ -48,4 +44,4 @@ MariaDB ayni damda o‘zgarish qila oladigan moliyaga ega emas. Ular hattoki 7 o
 
 Yo‘qotishlar: MariaDBning yo‘qotilishi kompaniya investorlari tortib olgan sarmoyadan ko‘ra kattaroq zarar keltiradi. Maʼlumotlar markazi (DC), Hostinglar, ochiq manbalar, millionlab veb saytlar va turli dasturlar uchun o‘z taʼsirni o‘tkazadi.
 
-_Qachonlardir Apple ( 1984 - 1997 ) va Nokia ham shu tarzda kasod bo‘lgan edi…_
+_Qachonlardir Apple ( 1984 - 1997 ) va Nokia ham shu tarzda kasod bo‘lgan edi…_

posts/mysqlga-juniorcha-va-seniorcha-sorovlar.md

@@ -83,9 +83,9 @@ Tasavvurimizni yana bir ishga tushirsakda sotilgan mahsulotlarni foizlardagi nis
 
 ```sql
 SELECT id, COUNT(*) AS count, 100 * COUNT(*)/s.total_sum AS percentage
-FROM sales 
+FROM sales
 CROSS JOIN (
-	SELECT COUNT(*) AS total_sum 
+	SELECT COUNT(*) AS total_sum
     FROM sales
 ) AS s
 GROUP BY id;
@@ -126,4 +126,4 @@ id 	month		date 	count	percentage
 
 ## Xulosa
 
-Albatta bu birgina so'rovlar orqali amalga oshirish mumkin bo'lgan ishlar uchun kichik misol xolos, ammo sizning optimizatsiya masalasidagi qarashlaringizga oz bo'lsada tasir ko'rsata oladi degan umiddaman.
+Albatta bu birgina so'rovlar orqali amalga oshirish mumkin bo'lgan ishlar uchun kichik misol xolos, ammo sizning optimizatsiya masalasidagi qarashlaringizga oz bo'lsada tasir ko'rsata oladi degan umiddaman.

posts/nginxda-ichki-redireksiya-yoxud-katta-stream-servisda-havolalarni-tekshirish-qanday-amalga-oshirilgan-edi.md

@@ -1,5 +1,5 @@
 ---
-title: "Nginxda ichki redireksiya yoxud katta stream servisda havolalarni tekshirish qanday amalga oshirilgan edi?"
+title: 'Nginxda ichki redireksiya yoxud katta stream servisda havolalarni tekshirish qanday amalga oshirilgan edi?'
 description: "Odatda statik fayllarni uzatish uchun nginx server ko'targanda indeksatsiyadan himoyalash ancha muammoga aylanadi..."
 slug: nginxda-ichki-redireksiya-yoxud-katta-stream-servisda-havolalarni-tekshirish-qanday-amalga-oshirilgan-edi
 date: July 27, 2023
@@ -18,26 +18,28 @@ Aynan shu sababli nginx ham yangi versiyalardan luani qo'llab quvvatlashni to'xt
 Menimcha barcha dasturchilar http 301 redireksiyasidan xabardor bo'lsalar kerak.
 
 ```http
-HTTP/1.1 301 Moved Permanently 
+HTTP/1.1 301 Moved Permanently
 Location: http://www.example.org/another_page
 ```
+
 Bu metod odatda foydalanuvchi brauzerini bir sahifadan boshqasiga yo'naltirish uchun ishlatiladi. Lekin biz buni tashqi redireksiya deb ataymiz. Chunki foydalanuvchi o'zgargan sahifadan xabardor bo'ladi.
 
 Xuddi shu tartibda ishlaydigan ichki redireksiya ham mavjud, unda foydalanuvchi http://www.example.org/mypage sahifasiga murojaat qilsa redireksiya backend qismni o'zida amalga oshiriladi va foydalanuvchiga u murojaat qilgan havolani o'zidayoq ma'lumotlarni olib qolish imkoni mavjud bo'ladi.
 
 Ho'sh bu qanday imkoniyatlar beradi?
 
-Tasavvur qiling sizda ikkita server mavjud, birida sizning asosiy saytingiz, ikkinchisida esa yuklash uchun beriladigan statik fayllar joylashgan. Lekin siz static faylni yuklash ruxsatini faqatgina ro'yxatdan o'tgan foydalanuvchigagina berishingiz kerak. Yoki yana bir holatda sizda /download.php fali bor deylik unga siz ?file_id=123 so'rovini berganingizda 123 idenfikatorga asoslanib fayl joylashuvini topadi va  binary faylni uzatishi kerak. 
+Tasavvur qiling sizda ikkita server mavjud, birida sizning asosiy saytingiz, ikkinchisida esa yuklash uchun beriladigan statik fayllar joylashgan. Lekin siz static faylni yuklash ruxsatini faqatgina ro'yxatdan o'tgan foydalanuvchigagina berishingiz kerak. Yoki yana bir holatda sizda /download.php fali bor deylik unga siz ?file_id=123 so'rovini berganingizda 123 idenfikatorga asoslanib fayl joylashuvini topadi va binary faylni uzatishi kerak.
 
 Odatda ko'pchilik o'zi foydalanadigan backend texnologiyada header orqali transfer qilish metodini qiladi. Masalan phpda:
 
 ```php
 $file_url = '/home/user/file.exe';
 header('Content-Type: application/octet-stream');
-header("Content-Transfer-Encoding: Binary"); 
-header("Content-disposition: attachment; filename=\"" . basename($file_url) . "\""); 
-readfile($file_url); 
+header("Content-Transfer-Encoding: Binary");
+header("Content-disposition: attachment; filename=\"" . basename($file_url) . "\"");
+readfile($file_url);
 ```
+
 Ammo bu metodda siz ishlatayotgan texnologiya reader va proxy vazifasini bajarib serverdagi butun resursni band qilishga urinadi. Ya'ni oddiyroq aytganda download.php fayli 10Mb hajmga ega faylni uzatish uchun operativ xotiradan yana 10Mb joy egallashga majbur bo'ladi. Katta fayllar haqidaku bunday metodda o'ylamagan ham maqul.
 
 Ichki redireksiyada barchasi boshqacha ishlaydi. Siz avvalo kerakli texnologiyangiz bilan (menda php) foydalanuvchi barcha shartlarni bajarayonganini tekshirasiz, keyin esa xuddi 301 kabi uni boshqa ichki locationga yo'naltirasiz.
@@ -96,7 +98,7 @@ server {
 
 Yuqoridagi misoldan tushunishingiz mumkinki "X-Accel-Redirect" orqali phpdan ichki redireksiya berilmoqda, nginxda esa internel seksiyasi orqali ichki redireksiya qabul qilib olinyapti. Bu usulning yana bir yaxshi tomoni borki foydalanuvchi internal blokga (Mendagi misolda: internal_download) murojaat qilgan vaqtda server uchun 404 xatoligini qaytaraveradi, ya'ni bu blok faqatgina server ichki qismidan ishlaydi xolos.
 
-Shuningdek php fayl o'z ishini bajarib bo'lgach nginx fpm protsesdan murojaat qilingan php faylni o'chiradi, bu esa foydalanuvchi yuklab olguncha fpm protsess kuzatib turmasligini ta'minlab beradi. 
+Shuningdek php fayl o'z ishini bajarib bo'lgach nginx fpm protsesdan murojaat qilingan php faylni o'chiradi, bu esa foydalanuvchi yuklab olguncha fpm protsess kuzatib turmasligini ta'minlab beradi.
 
 Nginx orqali katta hajmdagi fayllarni uzatishni ko'zda tutganlar uchun qo'shimcha bonus ham qilishni maqul ko'rdim va quyidagi konfiguratsiyalarni /etc/nginx/nginx.conf fayliga qo'shishni yoki ularni quyidagicha o'zgartirishni unutmang.
 
@@ -112,7 +114,6 @@ Agarda sizda fayllar hajmi 100Mbdan oshsa:
 - tcp_nopush uzatilgan ma'lumotlar miqdorini optimallashtiradi
 - keepalive_timeout bo'sh qolgan aloqa yopilish vaqti, ya'ni foydalanuvchi o'z ishini bajarib bo'lsa uni odatdagidek 75 soniya kutilmaydi. Balkim aloqa o'z o'rnida uziladi.
 
-
 ```
 worker_rlimit_nofile 65535;
 events {
@@ -124,4 +125,4 @@ http{
 	tcp_nodelay on;
 	keepalive_timeout 0;
 }
-```
+```