Хөөе Хабр!
Бид сэдвийг үргэлжлүүлэн судлах болно и үүнд мэдээллийн сангийн түвшинд. Өнөөдөр бид том програмуудыг зохиохдоо Java код биш мэдээллийн сангийн бүтэц яагаад шийдвэрлэх ач холбогдолтой байх ёстой, үүнийг хэрхэн хийдэг, энэ дүрмээс үл хамаарах зүйл юу болох талаар уншихыг санал болгож байна.
Энэ нэлээд хоцрогдсон нийтлэлд би яагаад бараг бүх тохиолдолд програмын өгөгдлийн загварыг "Java-ийн чадвараас" биш "өгөгдлийн сангаас" (эсвэл таны ашигладаг харилцагчийн хэлээр) зохиох ёстой гэж бодож байгаагаа тайлбарлах болно. хамтран ажиллах). Хоёрдахь аргыг сонгосноор таны төсөл хөгжиж эхэлмэгц та өвдөлт, зовлонгийн урт замыг туулах болно.
Нийтлэлийг үндэслэн бичсэн , Stack Overflow дээр өгөгдсөн.
Reddit-ийн талаархи сонирхолтой хэлэлцүүлгүүд и .
Код үүсгэх
JOOQ-тэй танилцсаны дараа jOOQ нь эх код үүсгэхэд нухацтай найдаж байгаад дургүйцдэг ийм цөөн тооны хэрэглэгчдийн давхарга байгаад би хичнээн гайхсан бэ. Хэн ч таныг jOOQ-г таны тохирсон байдлаар ашиглахад саад болохгүй, хэн ч таныг код үүсгэхийг албадаагүй. Гэхдээ анхдагч байдлаар (гарын авлагад тайлбарласны дагуу) jOOQ дараах байдлаар ажилладаг: та (хуучин) өгөгдлийн сангийн схемээс эхэлж, түүнийг jOOQ код үүсгэгчээр урвуу инженерчилж, өөрийн хүснэгтүүдийг төлөөлөх ангиудыг авч, дараа нь төрлийг бичнэ. Эдгээр хүснэгтүүдийн эсрэг аюулгүй асуулга:
for (Record2<String, String> record : DSL.using(configuration)
// ^^^^^^^^^^^^^^^^^^^^^^^ Информация о типах выведена на
// основании сгенерированного кода, на который ссылается приведенное
// ниже условие SELECT
.select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
// vvvvv ^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ сгенерированные имена
.from(ACTOR)
.orderBy(1, 2)) {
// ...
}Код нь угсралтаас гадуур гараар эсвэл бүрдл бүр дээр гараар үүсгэгддэг. Жишээлбэл, ийм нөхөн сэргэлт нь дараа нь шууд гарч болно .
Эх код үүсгэх
Код үүсгэх эдгээр аргуудтай холбоотой янз бүрийн философи, давуу болон сул талууд байдаг - гарын авлага болон автомат - эдгээрийг би энэ нийтлэлд нарийвчлан авч үзэхгүй. Гэхдээ ерөнхийдөө үүсгэсэн кодын гол утга учир нь энэ нь манай систем дотор ч юм уу, гаднаас нь ч бидний хүлээн зөвшөөрдөг "үнэн"-ийг Java хэл дээр хуулбарлах боломжийг олгодог явдал юм. Нэг ёсондоо байт код, машины код эсвэл эх кодоос өөр төрлийн код үүсгэдэг хөрвүүлэгчид ижил зүйлийг хийдэг - бид тодорхой шалтгаанаас үл хамааран өөр хэл дээрх "үнэн"-ийн дүрслэлийг авдаг.
Ийм код үүсгэгч олон байдаг. Жишээлбэл, . Энэ зарчим нь үргэлж ижил байдаг:
- Зарим үнэн (дотоод эсвэл гадаад) байдаг - жишээлбэл, тодорхойлолт, өгөгдлийн загвар гэх мэт.
- Бидэнд энэ үнэнийг програмчлалын хэлээр орон нутгийн төлөөлөл хэрэгтэй.
Түүнээс гадна, илүүдэл үүсэхээс зайлсхийхийн тулд ийм төлөөлөл үүсгэхийг бараг үргэлж зөвлөж байна.
Төрөл үйлчилгээ үзүүлэгчид болон тэмдэглэгээний боловсруулалт
Тайлбар: JOOQ-д зориулсан код үүсгэх өөр, илүү орчин үеийн, өвөрмөц арга бол төрөл үйлчилгээ үзүүлэгчийг ашиглах явдал юм. . Энэ тохиолдолд кодыг хөрвүүлэгч нь, үнэндээ эмхэтгэлийн үе шатанд үүсгэдэг. Зарчмын хувьд ийм код нь эх код хэлбэрээр байдаггүй. Жава хэл дээр тийм ч гоёмсог биш ч гэсэн ижил төстэй хэрэгслүүд байдаг - эдгээр нь тэмдэглэгээний процессорууд, жишээлбэл, .
Тодорхой утгаараа энд эхний тохиолдолтой ижил зүйл тохиолддог, үүнээс бусад нь:
- Та үүсгэсэн кодыг харахгүй байна (магадгүй энэ байдал хэн нэгэнд тийм ч зэвүүн мэт санагдахгүй байна уу?)
- Та төрлүүдийг өгөх боломжтой эсэхийг шалгах ёстой, өөрөөр хэлбэл "үнэн" нь үргэлж бэлэн байх ёстой. "Үнэн" гэж тэмдэглэсэн Ломбокийн хувьд энэ нь хялбар юм. Байнгын боломжтой шууд холболтоос хамаардаг мэдээллийн сангийн загваруудын хувьд энэ нь арай илүү хэцүү байдаг.
Код үүсгэхэд ямар асуудал байна вэ?
Гараар эсвэл автоматаар код үүсгэх нь яаж эхлэх нь дээр вэ гэсэн төвөгтэй асуултаас гадна код үүсгэх шаардлагагүй гэж үздэг хүмүүс байдаг гэдгийг би хэлэх ёстой. Миний хамгийн олон удаа тааралддаг энэ үзэл бодлын үндэслэл бол угсралтын шугамыг бий болгоход хэцүү байдаг. Тийм ээ, үнэхээр хэцүү байна. Дэд бүтцийн нэмэлт зардал бий. Хэрэв та тодорхой нэг бүтээгдэхүүн (jOOQ, JAXB, Hibernate гэх мэт) шинээр эхэлж байгаа бол API-г өөрөө сурахад зарцуулж үнэ цэнийг нь олж авахыг хүсч буй ажлын ширээг тохируулахад цаг хугацаа шаардагдана. .
Хэрэв генераторын төхөөрөмжийг ойлгохтой холбоотой зардал хэтэрхий өндөр байвал API нь код үүсгэгчийн ашиглалтын талаар муу ажилласан (мөн ирээдүйд үүнийг тохируулах нь хэцүү байх болно). Ашиглах чадвар нь ийм API-ийн хувьд хамгийн чухал зүйл байх ёстой. Гэхдээ энэ бол код үүсгэхийн эсрэг зөвхөн нэг аргумент юм. Үгүй бол дотоод эсвэл гадаад үнэний орон нутгийн дүрслэлийг бүхэлд нь гараар бич.
Энэ бүхнийг хийх цаг байхгүй гэж олон хүн хэлэх болно. Тэд супер бүтээгдэхүүнээ авах эцсийн хугацаатай. Хэзээ нэгэн цагт бид угсрах конвейерийг самнаж, завтай байх болно. Би тэдэнд хариулах болно:
,
Гэхдээ Hibernate / JPA горимд "Java" дээр код бичихэд маш хялбар байдаг.
Үнэхээр. Hibernate болон түүний хэрэглэгчдийн хувьд энэ нь сайн ба хараал юм. Hibernate горимд та дараах байдлаар хэд хэдэн объект бичиж болно:
@Entity
class Book {
@Id
int id;
String title;
}Тэгээд бараг бүх зүйл бэлэн болсон. Одоо Hibernate-ийн гол зүйл бол SQL-ийн "аяга"-ны DDL-д энэ нэгжийг яг хэрхэн тодорхойлох талаар нарийн төвөгтэй "дэлгэрэнгүй" мэдээллийг бий болгох явдал юм:
CREATE TABLE book (
id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
title VARCHAR(50),
CONSTRAINT pk_book PRIMARY KEY (id)
);
CREATE INDEX i_book_title ON book (title);... мөн програмыг ажиллуулж эхэлнэ. Хурдан босч, янз бүрийн зүйлийг туршиж үзэх үнэхээр гайхалтай онцлог.
Гэсэн хэдий ч надад зөвшөөрнө үү. Би худлаа ярьж байсан.
- Hibernate нь энэ нэрлэсэн үндсэн түлхүүрийн тодорхойлолтыг хэрэгжүүлэх үү?
- Hibernate нь TITLE дээр индекс үүсгэх үү? Энэ нь бидэнд хэрэгтэй гэдгийг би сайн мэдэж байна.
- Hibernate нь энэ түлхүүрийг Identity Specification-д таних түлхүүр болгох уу?
Тийм биш байх. Хэрэв та төслөө эхнээс нь боловсруулж байгаа бол шаардлагатай тэмдэглэгээг нэмэнгүүт хуучин мэдээллийн санг хаяж, шинээр үүсгэх нь үргэлж тохиромжтой байдаг. Тиймээс Номын байгууллага эцэст нь дараах хэлбэрийг авна.
@Entity
@Table(name = "book", indexes = {
@Index(name = "i_book_title", columnList = "title")
})
class Book {
@Id
@GeneratedValue(strategy = IDENTITY)
int id;
String title;
}
Сайхан байна. Дахин сэргээх. Дахин хэлэхэд, энэ тохиолдолд эхэндээ энэ нь маш хялбар байх болно.
Гэхдээ та дараа нь төлөх ёстой.
Эрт орой хэзээ нэгэн цагт та үйлдвэрлэлд орох хэрэгтэй болно. Тэр үед загвар нь ажиллахаа больдог. Учир нь:
Үйлдвэрлэлд шаардлагатай бол хуучин мэдээллийн санг хаяж, бүх зүйлийг эхнээс нь эхлүүлэх боломжгүй болно. Таны мэдээллийн бааз хуучин мэдээллийн сан болж хувирах болно.
Одооноос эхлээд мөнхөд чи бичих хэрэгтэй болно . Энэ тохиолдолд танай байгууллагууд юу болох вэ? Та тэдгээрийг гараар тохируулах боломжтой (мөн ажлын ачааллаа хоёр дахин нэмэгдүүлэх) эсвэл Hibernate горимд дахин үүсгэх боломжтой (таны хүлээлтийг хангахын тулд ийм байдлаар үүсгэгдсэн байх магадлалтай вэ?) Та аль алинд нь алдаж болно.
Тиймээс үйлдвэрлэлд шилжсэн даруйд танд халуун нөхөөс хэрэгтэй болно. Мөн тэдгээрийг маш хурдан үйлдвэрлэлд оруулах хэрэгтэй. Та үйлдвэрлэлд шилжих шилжилт хөдөлгөөнөө жигдрүүлж, жигдрүүлэх ажлыг зохион байгуулж амжаагүй байгаа тул та маш их засвар хийж байна. Тэгээд бүх зүйлийг зөв хийх цаг байхгүй. Мөн та Hibernate-г зэмлэдэг, учир нь энэ нь үргэлж хэн нэгний буруу, гэхдээ та биш ...
Үүний оронд анхнаасаа бүх зүйлийг шал өөрөөр хийж болох байсан. Жишээлбэл, дугуйн дугуйг дугуй дээр тавь.
Эхлээд мэдээллийн сан
Таны мэдээллийн сангийн схем дэх жинхэнэ "үнэн" ба түүн дээрх "бүрэн эрх" нь мэдээллийн санд оршдог. Схем нь зөвхөн мэдээллийн санд тодорхойлогддог бөгөөд өөр хаана ч байхгүй бөгөөд үйлчлүүлэгч бүр энэ схемийн хуулбартай байдаг тул схемийг дагаж мөрдөх, түүний бүрэн бүтэн байдлыг хангах, мэдээллийн санд үүнийг зөв хийх нь төгс утга учиртай юм. мэдээлэл хадгалагдаж байна.
Энэ бол хуучны мэргэн ухаан юм. Үндсэн болон өвөрмөц түлхүүрүүд сайн. Гадаад түлхүүрүүд зүгээр. Хязгаарлалт шалгах нь сайн. - Сайн байна.
Тэгээд энэ нь бүгд биш юм. Жишээлбэл, Oracle-ийг ашигласнаар та дараахь зүйлийг зааж өгөхийг хүсч магадгүй юм.
- Таны ширээ ямар ширээний зайд байна
- Түүний PCTFREE үнэ цэнэ гэж юу вэ
- Таны дарааллын кэшийн хэмжээ хэд вэ (id-ийн ард)
Энэ бүхэн жижиг системүүдэд хамаагүй байж болох ч "том өгөгдөл"-ийн талбарт шилжих хүртэл хүлээх шаардлагагүй - та дээр дурьдсан гэх мэт худалдагчаас олгосон хадгалах оновчлолын үр шимийг илүү эрт авч эхлэх боломжтой. Миний харсан ORM-уудын аль нь ч (jOOQ-г оруулаад) таны мэдээллийн санд ашиглахыг хүсч болох DDL сонголтуудын бүрэн багцад хандах боломжийг олгодоггүй. ORM нь DDL бичихэд туслах зарим хэрэгслийг санал болгодог.
Гэхдээ эцсийн эцэст сайн боловсруулсан схемийг DDL дээр гараар бичсэн байдаг. Аливаа үүсгэсэн DDL нь зөвхөн түүний ойролцоо тоо юм.
Үйлчлүүлэгчийн загварын талаар юу хэлэх вэ?
Дээр дурдсанчлан, үйлчлүүлэгч дээр та өөрийн мэдээллийн баазын схемийн хуулбар, үйлчлүүлэгчийн харагдац хэрэгтэй болно. Энэ үйлчлүүлэгчийн үзэл бодол нь бодит загвартай синхрончлогдсон байх ёстой гэдгийг хэлэх шаардлагагүй. Үүнд хүрэх хамгийн сайн арга юу вэ? Код үүсгэгчтэй.
Бүх мэдээллийн сан нь мета-мэдээлэлээ SQL-ээр хангадаг. Өөрийн мэдээллийн сангаас өөр өөр SQL хэл дээрх бүх хүснэгтийг хэрхэн авахыг эндээс үзнэ үү.
-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
-- Oracle
SELECT owner, table_name
FROM all_tables
-- SQLite
SELECT name
FROM sqlite_master
-- Teradata
SELECT databasename, tablename
FROM dbc.tables
Эдгээр асуулга (эсвэл үүнтэй төстэй асуулга, та мөн харагдац, материалжуулсан харагдац, хүснэгтээр үнэлэгдсэн функцуудыг авч үзэх шаардлагатай эсэхээс хамаарч) мөн дуудлагаар гүйцэтгэгдэнэ. JDBC-ээс эсвэл jOOQ мета модулийг ашиглан.
Ийм асуулгын үр дүнгээс харахад үйлчлүүлэгч дээр ямар технологи ашиглаж байгаагаас үл хамааран өгөгдлийн сангийн загварынхаа үйлчлүүлэгч талын дүрслэлийг үүсгэхэд харьцангуй хялбар байдаг.
- Хэрэв та JDBC эсвэл Spring ашиглаж байгаа бол мөрийн тогтмолуудын багц үүсгэж болно
- Хэрэв та JPA ашиглаж байгаа бол аж ахуйн нэгжүүдийг өөрсдөө үүсгэж болно
- Хэрэв та jOOQ ашиглаж байгаа бол jOOQ мета загвар үүсгэж болно
Таны үйлчлүүлэгчийн API (жишээ нь jOOQ эсвэл JPA) хэр их хүчийг санал болгож байгаагаас хамааран үүсгэсэн мета загвар нь үнэхээр баялаг бөгөөд бүрэн гүйцэд байж болно. Жишээлбэл, далд холболтын боломжийг авч үзье. , энэ нь таны хүснэгтүүдийн хоорондын гадаад түлхүүр харилцааны тухай үүсгэсэн мета мэдээлэлд тулгуурладаг.
Одоо мэдээллийн сангийн аливаа өсөлт нь үйлчлүүлэгчийн кодыг автоматаар шинэчлэх болно. Жишээ нь төсөөлөөд үз дээ:
ALTER TABLE book RENAME COLUMN title TO book_title;Та энэ ажлыг хоёр удаа хийхийг үнэхээр хүсч байна уу? Ямар ч тохиолдолд. Бид зүгээр л DDL-ийг хүлээн авч, үүнийг таны бүтээх шугамаар ажиллуулж, шинэчилсэн нэгжийг авна:
@Entity
@Table(name = "book", indexes = {
// Вы об этом задумывались?
@Index(name = "i_book_title", columnList = "book_title")
})
class Book {
@Id
@GeneratedValue(strategy = IDENTITY)
int id;
@Column("book_title")
String bookTitle;
}Эсвэл шинэчлэгдсэн jOOQ анги. Ихэнх DDL өөрчлөлтүүд нь зөвхөн синтакс төдийгүй семантикт нөлөөлдөг. Тиймээс, эмхэтгэсэн кодоос таны мэдээллийн баазыг нэмэгдүүлснээр ямар код нөлөөлөхийг (эсвэл) харах нь тохиромжтой байж болно.
Цорын ганц үнэн
Та ямар технологи ашиглаж байгаагаас үл хамааран зарим дэд системд үнэний цорын ганц эх үүсвэр болох нэг загвар үргэлж байдаг - эсвэл ядаж бид үүний төлөө хичээж, "үнэн" хаа сайгүй, хаана ч нэг дор байдаг аж ахуйн нэгжийн төөрөгдлөөс зайлсхийх хэрэгтэй. Бүх зүйл илүү хялбар байж болно. Хэрэв та зүгээр л XML файлуудыг өөр системтэй солилцож байгаа бол XSD ашиглана уу. XML хэлбэрээр jOOQ-ийн INFORMATION_SCHEMA мета загварыг харна уу:
- XSD нь сайн ойлгогддог
- XSD нь XML агуулгыг маш сайн тэмдэглэж, бүх үйлчлүүлэгчийн хэлээр баталгаажуулах боломжийг олгодог
- XSD нь сайн хувилбартай бөгөөд хоцрогдсон нийцтэй
- XSD-г XJC ашиглан Java код руу хөрвүүлэх боломжтой
Сүүлийн цэг нь чухал юм. XML мессежийг ашиглан гадаад системтэй харилцахдаа бидний мессеж хүчинтэй гэдэгт итгэлтэй байхыг хүсч байна. JAXB, XJC болон XSD-ийн тусламжтайгаар үүнийг хийхэд маш хялбар байдаг. Java-н анхны дизайны аргын хувьд бид мессежээ Java объект болгон хийдэг бол тэдгээрийг ямар нэгэн байдлаар XML-д ойлгомжтой байдлаар буулгаж, өөр системд ашиглахаар илгээж болно гэж бодох нь үнэхээр галзуурал болно. Ийм аргаар үүсгэсэн XML нь маш муу чанартай, бичиг баримтгүй, боловсруулахад хэцүү байх болно. Хэрэв ийм интерфэйс дээр үйлчилгээний чанарын түвшний (SLA) тохиролцоо байсан бол бид тэр даруй үүнийг устгах болно.
Үнэнийг хэлэхэд, JSON API-д яг ийм зүйл тохиолддог, гэхдээ энэ бол өөр түүх, би дараагийн удаа маргах болно ...
Мэдээллийн сан: тэдгээр нь адилхан
Өгөгдлийн сантай ажиллахдаа тэдгээр нь үндсэндээ адилхан гэдгийг та ойлгодог. Өгөгдлийн сан нь өөрийн өгөгдлийг эзэмшдэг бөгөөд схемийг удирдах ёстой. Схемд хийсэн аливаа өөрчлөлтийг DDL-д шууд хийх ёстой бөгөөд ингэснээр үнэний цорын ганц эх сурвалж шинэчлэгдэх болно.
Эх сурвалжийн шинэчлэл хийгдэх үед бүх үйлчлүүлэгчид загварынхаа хуулбарыг шинэчлэх ёстой. Зарим үйлчлүүлэгчдийг Java хэл дээр jOOQ болон Hibernate эсвэл JDBC (эсвэл хоёуланг нь) ашиглан бичиж болно. Бусад үйлчлүүлэгчид нь Perl хэл дээр (тэдэнд амжилт хүсье), бусад нь C# хэл дээр бичигдсэн байж болно. Энэ хамаагүй. Үндсэн загвар нь мэдээллийн санд байдаг. ORM-ээр үүсгэгдсэн загварууд нь ихэвчлэн чанар муутай, баримтжуулаагүй, боловсруулахад хэцүү байдаг.
Тиймээс битгий алдаа гарга. Анхнаасаа алдаа бүү хий. Мэдээллийн сангаас ажиллах. Автоматжуулах боломжтой байршуулах дамжуулах хоолойг барих. Өгөгдлийн сангийн загварыг хялбархан хуулж, үйлчлүүлэгчид рүү хаяхын тулд код үүсгэгчийг идэвхжүүл. Мөн код үүсгэгчийн талаар санаа зовохоо боль. Тэд сайн. Тэдгээрийн тусламжтайгаар та илүү бүтээмжтэй болно. Таны хийх ёстой зүйл бол тэдгээрийг анхнаас нь тохируулахад бага зэрэг цаг зарцуулах бөгөөд та төслийнхээ түүхийг бүтээхийн тулд олон жилийн гүйцэтгэлтэй байх болно.
Дараа нь битгий баярлалаа.
Тайлбар
Тодорхой болгохын тулд: Энэ нийтлэл нь бүхэл системийг (жишээ нь, домэйн, бизнесийн логик гэх мэт) таны мэдээллийн баазын загварт нийцүүлэн уян хатан болгох шаардлагатайг ямар ч байдлаар дэмжээгүй болно. Энэ нийтлэлд миний ярьж байгаа зүйл бол өгөгдлийн сантай харилцаж буй үйлчлүүлэгчийн код нь мэдээллийн баазын загвар дээр тулгуурлан ажиллах ёстой бөгөөд ингэснээр өгөгдлийн сангийн загварыг "нэгдүгээр зэрэглэлийн" төлөвт хуулбарлахгүй байх ёстой. Ийм логик нь ихэвчлэн таны үйлчлүүлэгчийн өгөгдөлд нэвтрэх давхаргад байрладаг.
Зарим газарт хадгалагдан үлдсэн хоёр түвшний архитектурт ийм системийн загвар нь цорын ганц боломжтой байж болох юм. Гэсэн хэдий ч ихэнх системд өгөгдөлд нэвтрэх давхарга нь мэдээллийн сангийн загварыг багтаасан "дэд систем" гэж надад санагддаг.
Үл хамаарал
Дүрэм болгонд үл хамаарах зүйлүүд байдаг бөгөөд мэдээллийн сан болон эх код үүсгэх арга нь заримдаа тохиромжгүй байдаг гэж би өмнө нь хэлсэн. Ийм үл хамаарах зүйлүүд энд байна (бусад байж магадгүй):
- Схем нь тодорхойгүй, нээх шаардлагатай үед. Жишээлбэл, та хэрэглэгчдэд ямар ч диаграммыг удирдахад туслах хэрэгслээр хангадаг. Өө. Энд код үүсгэх зүйл байхгүй. Гэхдээ одоо ч гэсэн - хамгийн түрүүнд мэдээллийн сан.
- Зарим асуудлыг шийдэхийн тулд шууд хэлхээ үүсгэх шаардлагатай үед. Энэ жишээ нь хээний бага зэрэг сэвсгэр хувилбар бололтой , өөрөөр хэлбэл, танд үнэхээр сайн тодорхойлсон схем байхгүй байна. Энэ тохиолдолд та RDBMS танд тохирох болно гэдэгт итгэлтэй байж чадахгүй.
Үл хамаарах зүйлүүд нь угаасаа онцгой байдаг. RDBMS-ийг ашиглахтай холбоотой ихэнх тохиолдолд схемийг урьдчилан мэддэг, энэ нь RDBMS дотор байдаг бөгөөд "үнэн"-ийн цорын ганц эх сурвалж болдог бөгөөд бүх үйлчлүүлэгчид үүнээс гаргаж авсан хуулбарыг авах шаардлагатай болдог. Хамгийн тохиромжтой нь энэ нь код үүсгэгчтэй холбоотой байх ёстой.
Эх сурвалж: www.habr.com