Watch "How do SSDs Work? | How does your Smartphone store data? | Insanely Complex Nanoscopic Structures!" on YouTube
https://youtu.be/5Mh3o886qpg

Dasturlash olamiga chuqur kirib ketganingda hamma narsa dasturlashga o'xshab qoladi...

P.S. Oddiy bolalar qo'shig'idagi shuncha falsafani qarang 😁

https://youtu.be/wlRbDg8-QH0

👉 @UzPythonMeetup

Dependency injection prinsipiga amal qilib kod yozish testlash jarayonini ancha osonlashtiradi.
Sinab ko'ring.

#yaxshi_savol

PostgreSQL bilan ishlaganda, deylik siz bir ma'lumotni UPDATE yoki DELETE qildingiz.
Lekin shu vaqtning o'zida eski qiymat ham tabledan o'chib ketmaydi.

Masalan, sizda
id INT, name VARCHAR
columnlaridan iborat persons table bor.
Deylik, unda 1 ta row: (1, 'John') bor.
Keyin siz uni yangiladingiz:
UPDATE persons
SET name = 'Doe'
WHERE id = 1;

Yoki o'chirib yubordingiz:
DELETE FROM persons
WHERE id = 1;

Lekin ikki holda ham eski qiymat, ya'ni (1, 'John') xotiradan o'sha vaqtning o'zida o'chib ketmaydi.

Savol: Eski qiymatlarni xotirada vaqtinchalik saqlab qolish nima uchun kerak va buning qanday negativ natijalari bo'lishi mumkin?

Javoblarni iloji boricha batafsil yozib, discussionda qoldirishingiz mumkin.

#savol
Webhook nima va qanday qulayliklar yaratib beradi?

Telegram botlar qanday ishlashini tushunish uchun polling, webhook nima,
ular nega kerak kabi savollarga javob topsak.

User telegramda botga biror buyruq yuborganda, unga javob qaytishi uchun bu buyruq biz yozgan kodimiz turgan servergacha yetib kelishi kerak va server unga javob qaytarishi kerak. User yuborgan buyruqlar telegramning serveriga borib tushadi. Endi o'sha serverga kelgan buyruqlarni bizning serverimizga yetkazish kerak. Lekin telegram aynan o'sha bot uchun yozilgan bizning kodimiz qayerda turganini qanday biladi?

Telegram botlar uchun HTTP protocolidan foydalanadi. Muammo shundaki, HTTP bir tomonlama ishlaydi(push/promisedan tashqari). Ya'ni faqat bir tomon(client) request yuboradi, ikkinchi taraf(server) uni qabul qilib, response qaytaradi.
Bu degani, server xohlagan paytida clientga response yubora olmaydi. Faqatgina client request yuborgandan keyingina response yuborish mumkin.

Bizning server bilan telegram server orasida ma'lumot almashishning ikki yo'li bor:
1. Bizning server HTTP client, telegram serveri esa HTTP server vazifasini bajaradi.
2. Telegram serveri HTTP client, bizning server esa HTTP server vazifasini bajaradi.


1. Deylik, user telegram botga biror buyruq yubordi. Telegram serveri bu buyruqni to'g'ridan to'g'ri bizning serverga yubora olmaydi. Sababi, yuqorida kelishganimizdek, faqat client birinchi bo'lib ma'lumot yubora oladi. Telegram server esa hozir HTTP server rolini o'ynayapti. Plus, telegram biz qaysi bot haqida so'rayotganimizni ham bilmaydi. Demak, avval client so'rov yuborishi kerak.
Lekin client qachon so'rov yuborish kerakligini(telegramga yangi buyruq kelganini) qanday biladi?
Javob — hech qanday. Shunchaki ma'lum vaqt oraligi bilan telegram serveriga to'xtovsiz request yuborib turadi. Botga yangi buyruq kelsa, telegram keyingi safar bizning serverdan request kelganda uni response qilib yuboradi. Bu taxminan mana bunday bo'ladi:

Client: Falonchi bot uchun yangi buyruq bormi?
Telegram: Yo'q
*ozgina vaqt o'tgach*
C: Bormi?
T: Yo'q
C: Bormi?
T: Ha, mana, ol. *Buyruqni yuboradi*
C: *Buyruqqa javob qaytarib, request shaklida yuboradi*
T: Oldim.
C: Bormi?
T: Yo'q
...

Mana shu usul, ya'ni bizning server ma'lum vaqt oralig'i bilan to'xtovsiz telegramdan so'rab turishi polling deyiladi.


2. Endi bizning server HTTP server vazifasini bajarib, Telegram serveri HTTP client rolini o'ynab beradi. Endi telegram client sifatida buyruqlarni to'g'ridan-to'g'ri bizga yubora oladi. Lekin buning uchun ikkita shart bajarilishi kerak:
1. Telegram bizning serverning manzilini bilishi.
2. Bizning server web server sifatida ishlashi, ya'ni requestlarni qabul qilishi kerak.

Buning uchun boshda Pashka akaning serverlariga "Falonchi botga kelgan buyruqlarning hammasini falonchi adressdagi serverga request qilib yubor" degan ma'noda xabar berib qo'yamiz. O'zimizning serverimizni esa web serverga aylantiramiz.

Endi faqat yangi buyruq kelgandagina telegram bizning serverimizga request yuboradi:

Telegram: Uka, botingga yangi buyruq keldi. Ma, ol.
Bizning server: *qayta ishlab, natijani yuboradi*.
*keyingi safar buyruq kelganda*
Telegram: Yangi buyruq. Ma, ol.
...

Mana bu usul, yani telegram bizning serverga request yuborishi esa webhook deyiladi.

PostgreSQL ma'lumotlarni qanday saqlaydi?

Ko'pchilikning hayolgia keladigan birinchi javob – jadval(table)larda. Lekin shu table o'zi aslida nima va qanday ishlaydi?

Birinchi bilishimiz kerak bo'lgan narsa – PostgreSQLda biz kiritadigan ma'lumotlar tablening o'zida saqlanmaydi. Table bu ma'lumotlarning o'zini saqlaydigan emas, balki o'sha ma'lumot qayerda saqlanganini ko'rsatib turadigan heap nomli ma'lumotlar tuzilmasi (data structure)dan iborat. Bu qaysidir ma'noda frontendga o'xshash: o'zida ma'lumot yo'q, lekin uni qayerdan olishni biladi.

Xo'sh, unda haqiqiy ma'lumotlar qanday saqlanadi?
PostgreSQL haqiqiy ma'lumotlarni heap tuple (yoki shunchaki tuple) nomli alohida tuzilmalarda saqlaydi.
Heap tuple bu (odatda) tabledagi bitta record(row) saqlangan obyekt. Ya'ni bitta rowdagi qiymatlar bitta tuple sifatida, ketma-ket joylashadi. Va har bitta tuplening o'zining IDsi bor. Biz biladigan jadvalda biz qo'shgan ustunlardan tashqari yana bitta ustun – TID(Tuple ID) ham bor va aynan o'sha qiymat shu rowga tegishli ma'lumotlar qaysi tupleda turganini ko'rsatadi.

*qo'shimcha

Demak, ma'lumotlar tupleda saqlanishini bilib oldik. Bir qancha tuplelar birlashib, page yoki blokni tashkil qiladi. Bitta pagening o'lchami odatda, 8 KB bo'ladi va har bitta page fayl sistemasida bitta fayl sifatida saqlanadi. Albatta, bu faylda tuplelardan tashqari bir qancha metadata ham saqlanadi.
Shunday qilib, bitta tabledagi ma'lumotlar bir qancha (kamida bitta) pagelarda saqlanadi.

Yana bir gap, doimiy xotirada RAMga o'xshab istalgan joydagi istalgan baytni to'g'ridan-to'g'ri ololmaymiz. Birinchidan, doimiy xotira RAMga o'xshab, addresslanmagan. Ikkinchidan, har bir baytni asosiy xotiradan alohida-alohida o'qib olish ancha "qimmat"ga tushadi. Shuning uchun doimiy xotiraga bir marta borganda ko'proq ma'lumot olib qaytish kerak. PostgreSQL asosiy xotiradan ma'lumotlarni page bo'yicha ko'chiradi, ya'ni bitta faylni to'liqligicha yuklab oladi.
Bu degani, agar bizga bitta pagedagi faqat 1 ta qiymat kerak bo'lsa ham, butun pageni ko'chirib olishga majburmiz.

Ma'lumotlar to'liq tuplelardan saqlanadimi? Yo'q.
Katta hajmli ma'lumotlarni doimiy xotiradan ko'chirib olish ancha resurs oladi. Shuning uchun ularni faqatgina eng kerakli vaziyatlardagina ko'chirib olish kerak.

Masalan,
SELECT * FROM test_table WHERE id = 3;
mana shu query ishga tushganida agar indeks bo'lmasa id bo'yicha izlash uchun hamma id larni olishimiz kerak. Lekin tepada kelishganimizdek, bizga faqatgina id kerak bo'lsa ham butun boshli tuple va o'sha tuple joylashgan blokni ko'chirib olishimiz kerak.
Agar keyingi ustunda 1 GB hajmli fayl to'g'ridan-to'g'ri saqlansa, shunchaki bitta IDni (aslida faqatgina izlash uchun) olish uchun butun boshli faylni ham yuklab olishga to'g'ri keladi.

Xo'sh, katta hajmli ma'lumotlarni tupleda saqlay olmasak, unda qanday saqlaymiz? Oddiy yechim. Shunchaki ma'lumotni boshqa joyda saqlaymiz va tupleda faqatgina shu ma'lumot turgan joy manzilini saqlaymiz. Tupleni RAMga ko'chirib olayotganda esa 1 GBli ma'lumotni emas, faqatgina uning addressini olamiz. Qarabsizki, six ham kabob ham kuymaydi.
Umuman olganda, PostgreSQL hatto varchar va textni ham tupleda saqlamaydi. Xuddi tepada aytilganidek ularni ham alohida saqlab, tupleda ularga pointer saqlaydi.

Albatta, bu ma'lumotlar juda yuzaki va aslidan biroz o'zgartirilgan(osonroq tushunish uchun). Lekin o'ylaymanki, bu qisqa maqola kim uchundir shu mavzuda izlanib ko'rishga turtki bo'la oladiganlar darajada foydali bo'ladi.

*qo'shimcha

Yangi ma'lumot avvalgisiga nisbatan qayerga qo'shilishiga qarab tablelarni 2 turga bo'lish mumkin:

1. Yangi ma'lumot avvalgisining davomidan qo'shiladi. Masalan, IDsi 1, 3 va 2 bo'lgan rowlarni shu tartibda qo'shsangiz ular xotirada ham xuddi shu tartibda yoziladi.

2. Ma'lumot biror qiymat bo'yicha tartiblab qo'shib boriladi.
Masalan, ID bo'yicha tartiblangan jadvalda 1 va 3 qo'shilganida o'rtada 2 bo'lishi kerakligi hisobga olinib (hali yo'q bo'lsa ham), bitta row uchun joy tashlab, keyin yoziladi. Keyin 2 qo'shilganida esa shu joyga yoziladi.
Natijada bizda bitta ustun bo'yicha doim tartiblangan jadval hosil bo'ladi.

Tupledagi ma'lumotlarni o'zgartirib bo'lmaydi. Biz UPDATE query berganimizda tuple o'zgartirilmasdan, yangi qiymatlar saqlangan yangi tuple yaratilib, tabledagi eski tupleni ko'rsatib turgan TID yangisiga o'zgaradi. Eski tuple esa o'chirilgan deb belgilanadi.

Tepadagi maqola bo'yicha fikrlaringizni so'rab qolgan bo'lardim. Xato va kamchiliklarini aytsangiz, juda xursand bo'lardim.

Inshaalloh, buyog'iga databaselar bo'yicha batafsilroq maqolalar chiqarishni niyat qilib qo'ydim.

#savol

FastAPI nima?
U ham REST APIning bir qismimi?
Ikkalasining farqi nima?

#javob

Tushunarliroq qilishga harakat qilaman:

Bilasiz, API (boshlanishiga, faqat web APIlar haqida gaplashamiz) bizga ikki xil dastur/application orasida ma'lumot almashish uchun kerak. Masalan, frontend backend bilan ma'lumot almashishi uchun API ishlatamiz.

API ishlatish uchun esa ikkala taraf ham tushunadigan usulda ma'lumot almashish kerak. Masalan, siz Xitoy tilini bilmaysiz, u esa O'zbek tilini bilmaydi. Lekin ikkalangiz ham ingliz tilini bilsangiz bir-biringiz bilan gaplasha olasizlar.

Qaysi tilda va qanday usulda, qanday qoidalar asosida "gaplashish"ga qarab API ko'plab turlarga bo'linadi.

Web APIlar orasida eng keng tarqalgan turlaridan biri REST turidagi APIlar. RESTda ma'lumot almashish uchun JSON formatidan foydalaniladi. Va ma'lumotlarni qanday ko'rsatish va hokazo kabi bir qancha qoidalarni o'z ichiga oladi.
E'tibor bering, REST aynan bir dastur emas, balki API turi, aniqrog'i, qoidalar to'plami. Shu qoidalar asosida ishlaydigan APIlar esa REST API deyiladi.

Web uchun ishlatiladigan ko'plab dasturlash tillarida REST APIlar qurish va ulardan foydalana olish uchun texnologiyalar qurilgan. Pythonda ham bu bo'yicha yetarlicha librarylar bor.

Django standart holatda server-side renderingdan foydalanadi, REST API ishlatmaydi. Lekin Django bilan REST API qurish uchun Django REST Framework (DRF) nomni library(balki, framework, anig'ini bilmayman) bor. Qisqasi, u djangoda API qurish uchun "adapter" sifatida ishlaydi.

Boshqa python frameworklar esa standart holatda REST APIlar bilan ishlay oladi. Bulardan eng mashhurlari esa Flask va FastAPI. Ya'ni bular REST qoidalaridan foydalangan holda API qura oladigan frameworklar.

REST yagona web API turi emas. Yana eng mashhurlaridan GraphQL nomli API turi bor.

PostgreSQLning ichki komponentlari haqida yaxshi manbaa topib oldim. Tekin ekan (lekin copyright qismini o'qishni esdan chiqarmang). Ochig'i, bu $100 turadigan kurs bo'lganida ham sotib olardim.
Link: https://www.interdb.jp/pg

P.S. Shunga o'xshash manbaa yoki kurslarni bilsangiz, kommentda yozib qoldiring.

PostgreSQL 9.1 versiyasidan boshlab MySQL, Oracle kabi boshqa ko'plab Relational Database Management Systemlarda, shu qatorda ANSI SQL-92 standartlarida ham yo'q bo'lgan yangi xususiyat qo'shildi. Ya'ni shu versiyadan boshlab PostgreSQLning Multi Version Concurrency Control mexanizmi Repeatable Read izolyatsiya darajasidagi tranzaksiyalarda ANSI SQL-92 standartida ko'rsatilgan Phantom Read anomaliyasi (boshqa tranzaksiya tomonidan yangi row qo'shilishi) sodir bo'lishining to'liqligicha oldini oladi.

P.S. Endi shu gapni dasturlashdan xabari yo'q tanishingizga aytib ko'ring ))

Bu PostgreSQLning "lost updates"ning oldini olish uchun ishlatadigan logikasi.
Tranzaksiya ma'lumotni o'zgartirish vaqtida u ma'lumotni lock qiladi, ya'ni qulflaydi. Agar shu vaqtda boshqa tranzaksiya shu ma'lumotni o'zgartirmoqchi bo'lsa, narigi tranzaksiya ishini tugatib, lockni ochgunicha kutib turadi. Mana bu usul pessimistic concurrency control deyiladi.
Sababi, bu yerda tranzaksiyalar boshqalar ma'lumotni o'zgartirishidan qo'rqib, har doim lock olib yuradi (yomg'irdan qo'rqib, har doim soyabon olib yurgan odamdek). Natijada updatelar sekinlashadi.

Lost updatesning oldini olishning oldini olishning yana bir usuli optimistic concurrency control deyiladi. Bunda hech qanday lock ishlatilmaydi. Bu tranzaksiyalar optimist, hayotning yaxshi tarafiga umid qiladi. Shunchaki tranzaksiya boshida va oxirida ma'lumotlar bir ekanini tekshiradi. Agar bir xil bo'lsa, unda commit qiadi. Mabodo ma'lumot o'zgargan bo'lsa, demak yomg'ir yog'gan, endi tranzaksiya abort qilinadi.

©️ https://www.interdb.jp/pg/pgsql05.html

Databaselardan biroz uzoqlashamiz.
Network engineer bo'yicha quyidagi savollarga javob berib, bu sohadagi boshlang'ich bilimlaringizni sinab ko'ring:

1. Ikkita qurilmada bir xil MAC addressi bo'lishi mumkinmi?

2. OSI va TCP/IP modellarining asosiy vazifasi nima?

3. Nega streaming uchun asosan UDP protokoli ishlatiladi?

4. Qurilmadagi ma'lum portga kelayotgan requestlarni bloklaydigan firewall qurmoqchisiz. Bunda firewall OSI modelining eng kamida qaysi qavatida turishi kerak?

5. HTTP/1.1 protokolida 2 ta qurilma orasida bir vaqtda parallel 6 ta connection ochish mumkin. Lekin HTTP/2 protokolidagi 1 ta connection bu 6 ta connectiondan ko'ra ko'proq ma'lumot tashiy oladi. Qanday qilib?

6. Netmask nima uchun ishlatiladi?

7. ARP poisoning nima?

8. Diffie-Hellman kalit almashish algoritmi qanday ishlaydi?

9. TLS termination nima va qachon ishlatiladi?

10. Reverse proxy request pathga qarab requestni backend servislardan biriga yo'naltirishi uchun u OSI modelining qaysi qavatida ishlashi kerak?

11. UDP holepunching nima va nega TCP bilan bog'liq bunday narsa yo'q?

12. DNS spoofing nima?

13 DDoS xujumlaridan himoyalanishning eng sodda usullari qanday?

14. HTTP request tarkibidagi keep-alive headeri qanday vazifani bajaradi?

15. TCP paketlari hajmini kattalashtirishning qanday yaxshi va yomon taraflari bor?

Bu savollarning nechtasiga javob bera oldingiz?
Agar javobingiz 15 dan kam bo'lsa, tabriklayman, bugun o'rganish uchun mavzu topildi.

P.S. Savollar yoqqan bo'lsa, tanishlarga yuboring.

P.S.2: Shaxsiy kanalingiz bo'lsa, kanalingizda forward qilsangiz, undan ham yaxshi ))

print("Hello world")

Bu kodni biz yaxshi bilamiz.
Lekin bu postni o'qiyotganlarning 99% qismi bu kod aslida qanday ishlashini bilmaydi. Ha, aynan shunday.
To'g'ri, Python interpreter kodni o'qib, execute qiladi deyishingiz mumkin, lekin o'sha execute qilish o'zi nima?
Buni siz yozgan bir qator koddan boshlab CPU, RAMda nima sodir bo'lishi-yu, kompyuteringizdagi har bitta atom qanday harakatlanishigacha tushuntirib bera olasizmi? Katta ehtimol bilan, yo'q.

Endi o'rinli savol: Hatto "Hello world" qanday ishlashini bilmaydigan dasturchi qanday qilib sun'iy intellekt yaratishi mumkin?

Gap shundaki, dasturlashda biz hamma narsani noldan, aniqrog'i nolgacha chuqur o'rgana olmaymiz. Xo'sh, unda o'sha chuqurlikni qanday yopamiz? Axir uy tomdan boshlab emas, asosdan boshlab quriladi-ku. Javob – abstraksiya orqali.
Ya'ni biz ichki ishlash tizimini bilmaydigan (ko'p hollarda bilish zarur bo'lmagan) narsalarni shunchaki ishlaydi deb hisoblaymiz yoki qanday ishlashi haqida aslidan farq qiladigan, sodda tushunchaga ega bo'lamiz (aslida bu ham biroz pastroqdagi abstraksiyalar yig'indisi).

Masalan, eng oddiy backend server yozayapsiz va u request kelganida databasedan ma'lumot olib, response yuboradi.
Buni qilish uchun request o'zi nima, uni qanday olamiz, database qanday qilib ma'lumot beradi va hokazolarni bilishimiz shart emas. Ular "shunchaki" o'z vazifasini bajaradi deb hisoblaymiz.

Natijada bizda tizim qanday ishlashi haqida minimal ma'lumot bilgan holda uni ishlab chiqish imkoniyati paydo bo'ladi. Ya'ni aynan abstraksiya sabab komputerdagi har bitta atom qanday ishlashini bilmay turib ham dastur ishlab chiqa olamiz.

Lekin rivojlanishni xohlasangiz, abstraksiyalarni buzib kirishdan qo'rqmang. Yanada chuqurroqqa tushish sizga ko'proq narsani ko'rish va o'rganish imkonini beradi. Natijada biror texnologiya haqida oldin bilgan narsalaringiz noto'g'ri ekanini va u aslida boshqacha ekanini tushunasiz. Oldingi tushunchalaringiz esa kulguli darajada oddiy tuyulishni boshlaydi.
Yana ozgina pastroqda tushsangiz, o'sha "batafsil" bilganlaringiz ham juda oddiy ko'rinadi.

Lekin abstraksiyalarni buzib, chuqurroqqa tushish bizga o'zi kerakmi?
Bilmadim, bu sizga bog'liq. Shaxsan menga end-user ishlatadigan mahsulot ishlab chiqishdan ko'ra boshqa dasturchilar ishlatadigan toollar ishlab chiqish yoqadi. Menga "chuqurroqda" ishlash yoqadi.

Update: Juda yaxshi misol berilgan komment yozildi, biroz o'zgartirib, postga qo'shib qo'yaman:
Har kuni mashinani o't oldiramiz va haydab, ishga boramiz. Lekin buning uchun mashina qanday ishlashini bilish shart emas.
Agar mashinadan faqat ishga borish uchun foydalansangiz, shu yetarli.
Lekin siz mashina tuzatadigan yoki ishlab chiqaradigan mexanik bo'lsangiz ichki qismlar va ular qanday ishlashini albatta bilishingiz kerak bo'ladi.

RDBMS, umuman DBMSlar haqida 20 ta savol.
Qolganlaridan qiyinroq savollar * bilan belgilangan.


1. ACID xususiyatlaridan biri bo'lgan atomicity nimani bildiradi?

2. RDBMSlarda qaysi holatlarda denormalizatsiya qilish foydali hisoblanadi?

3. Database cursor nima? Server-side cursorning client-side cursordan ustun tomoni qaysi?

4. Database engine nima?

5. Read committed va repeatable read izolyatsiya darajalarining orasidagi asosiy farq nimada?

6. Pessimistic Concurrency control nima? Uning qanday kamchiliklari bor?

7*. Transaction snapshot nima?

8*. Serialization anomaliyalaridan biri bo'lgan rw-conflict qachon sodir bo'ladi?

9. Connection pool haqida ma'lumot bering.

10. Clustered index bilan non-clustered indexning farqi nimada?

11*. B-tree va B+tree orasidagi farq nimada?

12. Master va slave replicalar orasida to'liq consistencyni qanday ta'minlash mumkin?

13. Database sharding nima?

14*. Row-based storage nima? U nima uchun OLAP operatsiyalari uchun yaxshi tanlov emas?

15*. WAL nima?

16. PostgreSQLda vacuuming nima?

17. PostgreSQLda index scan va index-only scan bir-biridan qanday farq qiladi?

18. PostreSQLda view nima?

19. PostgreSQLda ANALYZE buyrug'i nima vazifani bajaradi?

20*. PostgreSQLda SELECT FOR UPDATE komandasi nima vazifani bajaradi?


P.S. Bu savollardan ba'zilari backend developer uchun texnik intervyularda tushishi mumkin.

P.S.2. Agar to'g'ri javoblaringiz soni 20 dan kam bo'lsa tabriklayman, o'rganish uchun sizga yangi mavzu topildi.

Pythonda yozilgan applicationlarda background tasklar uchun Celery ishlatish ancha keng tarqalgan usul. Ochig'ini aytsam, bu softwareni unchalik yoqtirmayman. Ko'p featurelarni implement qilishga harakat qilishadi, lekin u featurelar ning ko'pchiligi native ishlab keta olmaydi.
Eng yomoni, bu "oqsagan" featurelar boshqa, oldin yaxshi ishlayotgan featurelarga ham yomon ta'sir qiladi.
Celeryning umumiy arxitekturasini va ayniqsa, network layerni butunlay qayta ko'rib chiqish kerak deb o'ylayman.

Yetarlicha vaqtingiz bo'lsa, biror tayyor MQdan foydalanib(Redis, RabbitMQ, Kafka), loyihangiz uchun maxsus background task tizimini qurishni tavsiya qilaman. Katta loyihalarda Celery ishlatish unchalik to'g'ri variant emas ekan.

P.S. Yoki sekin EDAga o'ting. Agar shunga arzisa.