2015

Сан Франциско .vs Токио

Сан Францискод ирээд 8 сар болчихлоо. 8 жил амьдарсан Японтойгоо хальт харьцуулж юм бичмээр санагдлаа.
Ер нь бол нэлээн таалагдаж байгаа. Өөрийнхөө мэргэжлийн хүмүүсийн талаас хараад харьцуулж бичье.

Цалин
Дундаж цалин Токиогоос 2-4 их. Хэрвээ үнэхээр чадвартай бол дээд хязгаар бараг байхгүй. Тэгэхдээ өртөг бас адил 2-4 дахин их. Тэгэхээр, цалингаас зардлаа хасаад үлдэх мөнгө(saving) чинь бас 2-4 дахин их гэсэн үг.
Зардлын хамгийн их хэсгийг нь байр эзлэнэ. Токиод бол 1000$ гаран байранд төлдөг байсан бол, энд 4000$ орчим. Хэрвээ гэр бүлтэй бол, suburb-уудад л амьдарсан нь дээр.

Ажиллах орчин
10, 11 гэж ирээд 6, 7 гээд тарна. Токиод бол бараг 9-өөс орой 10, 11 хүртэл ажиллах бол энгийн үзэгдэл байлаа.
Бас эндхийн компаниуд эхнээсээ хязгааргүй цалинтай амралттай болж эхэлж байгаа. Манай эндэх оффис бас хязгааргүй. Менежертэйгээ ярьж тохироод, ажил цалгардхааргүй бол амралтаа дуртайгаараа авна.
Бас гэрээсээ ажиллаж болно. Цаг нь flex time болохоор, ажлаа хийж байвал, дуртай үедээ ирээд дуртай үедээ харьж болно. Тэгэхдээ, мэдээж хурал нтр-дээ суух хэрэгтэй. Япончууд шиг flex time гэчихээд, өглөө 10-т, орой 6-д хурал оруулж новшрохгүй. Ер нь бол life balance сайн.
Хамт ажиллаж байгаа хүмүүс нь үнэн дажгүй. Чадахгүй гарууд нь, эсвэл ядаргаатай зантай гаруудыг халчихдаг болохоор, дандаа гайгүйнүүд нь шигшигдээд үлдчихдэг юм шиг байгаан. Токиод нээх ядаргаатай хүмүүстэй хамт ажиллаж байгаагүй ч, өөр багийн 2, 3 хүнтэй хэрүүл хийж байсан удаа бол байгаа. Тэд нар бол энд 7 хонохгүй халагдана.
Бас ажил дээрээ зүгээр найз нтр ээ дагуулаад ороод ирж болно. Нэг залуу ямар ч байсан, интернетээр танилцсан гээд нэг залууг ажил дээр өдрөөс орой хүртэл байлгасан нь, үнэхээр сонин санагдсанаа нуух юун. Зарим компани, амьтад бас зөвшөөрдөг тул нохой муур нтрээ аваад ирж болно.
Ер нь ажлаа хийж чадаад, мал зан гаргахгүй явж байвал асуудалгүй, эрх чөлөөтэй.
Бас миний мэдэх ихэнх компаниуд хоол нь цаанаасаа болохоор, ажлын өдрүүдэд бараг мөнгө үрэхгүй.

Боломж
Хэрвээ өөрөө ямар нэгэн startup байгуулмаар бол, хөрөнгө оруулагч нар энд хөрөнгө оруулъя гээд сууж байна. Бараг өдөр болгон хөрөнгө оруулагч болон, шинийг санаачлагч нарыг холбох event болно. Мэдээж, хүн болгонд шинээ санаа байгаа болохоор өрсөлдөөн их.
Бас мэргэжил нэгт хүмүүс их болохоор, бүх төрлийн мэдлэгээ солилцох уулзалт болно. Ажлаа солимоор бол, компаниуд чадвартай инженер авах гээд очерлоод байж байна.
Байнга, LinkedIn-ээр чинь, энд тэндхийн компаниудын recruiter-ээс mail ирнэ.
Үе үе, зарим компаниуд, зөвхөн инженерүүдэд зориулсан party зохион байгуулж, LinkedIn-ээр иниженерүүд лүү party-нийхаа урилгыг явуулж, ажилд авахыг оролдоно.
Ер нь юу хиймээр байна, тэр чигэлэлээр чинь ажиллаж байгаа компани бол заалттай байна.

Виз
Виз бол бараг дэлхийд хамгийн хэцүү нь байх. Энэтхэг, Хятадын шилдэг сургуулиудыг төгссөн инженерүүд, энд ирэх гээд очер үүсгэчихсэн байгаа байх. Ажиллахын тулд, H1B гэдэг виз хэрэгтэй.
Тэрийг нь авхын тулд, 4 сараас өмнө offer авах ёстой. Тэгээд, offer авсан компани чинь 4 сараас чиний өмнөөс apply хийнэ. жил бүр 200 мянга гаран хүн apply хийгээд 65 мянган хүн тэнцэнэ. Өөрөөр хэлбэл, чинийн гарал угсаа, чадвар, offer өгсөн компаниас чинь үл хамааран, чиний Америкт ажиллах эрх авах магадлал чинь 30% гэсэн үг. Хэрвээ чи азтай 30%-ын нэг бол, 10сараас эхлэн ажиллах эрхтэй болно.
Харин нэгэнт H1B визтэй бол зүгээр шилжүүлчихэж болно. Тэгэхээр H1B-гүй бол, сонголт бол хэдхээн том компаниуд, эсвэл энд ирж master degree хийхээс өөр аргагүй болно гэсэн үг.
Ямар ч байсан, аймар чадвартай байж, зүгээр л виз авхын тулд, master degree-ээр Америкт ирсэн хүмүүстэй зөндөө таарч байсан.

Аюулгүй байдал
За энэ талаар юу ч харьцуулахав. Бараг өдөр болгон л хүн буудуулж үхдэг юм шиг байгаан, энд.
Тэгэхдээ Токиог бодвол хамаагүй жижигхэн хот, дээрээс нь taxi-ний үйлчилгээ хямд болохоор, хаалган дээрээс машин дуудаад, хаалган дээр буугаад байхад гайгүй.

Эмхэтгээд хэлэхэд, хэрвээ гэр бүл нтргүй бол, энд ирсэн нь л дээр юм шиг санагдсан. Мэдээж хүн хүний бодол, эрхэмлэх зүйл өөр.

DNA ба бидний амьдрал 2

2 жил гарангийн өмнө блог дээрээ DNA ба бидний амьдрал гэдэг post бичиж байсан юм. Тэрнийхээ үргэлжлэлийг бичье гэж бодлоо.

Яагаад computer science-ээр төгсчихөөд DNA сонирхоод байгаагаа эхлээд жаахан тайлбарлая. Миний бодлоор эрүүл мэндийн шинжлэх ухаан нь, бусад шинжлэх ухаануудаас хоцролттой явагдаж байгаа юм шиг санагддаг. Бидэнд одоо болтол эдгээж чадахгүй өвчнүүд, шалтгааныг нь олоогүй шинж тэмдэгүүд(symptoms) байна. Харин сүүлийн жилүүдэд, хүний DNA-г хямд зардлаар бүгдийг нь тайлж унших боломжтой болж, мөн судалгаа хийхэд хангалттай их хэмжээний сан үүсгэгдэж байна. Компьютерийн шинжлэх ухааны хүмүүс ихэнхдээ тоон өгөгдөл дээр ажилладаг. Харин биологичид маань, хүний эсийг тоон хэлбэрт шилжүүлж чадсанаар, бид нарт ч гэсэн түүн дээр ажиллах боломж үүсч байгаа юм. Мөн, компьютерийн шинжлэх ухааны хиймэл оюун гэх мэт ухагдхуунуудыг ашиглавал, DNA судалгааг хүчтэй түрж өгөх юм шиг санагдаад байгаа юм. Миний хувьд учиргүй хувь нэмрээ оруулдаггүй юмаа гэхэд, ядаж хүний хийсэн судалгааны ажлыг уншиж ойлгоод, тэрэнд нь таарсан алгоритм бичих чадвартай болохыг зорьж байгаа болно.

Би мэргэжлийн хүн биш тул, миний бичсэн зүйлүүдэд алдаа байхыг үгүйсгэхгүй. Тиймээс ямар нэгэн зүйлийн эх сурвалж болгож битгий ашиглаарай.
Мөн, алдаатай хэсгийг залруулж өгвөл баярлана.

За гол зүйлдээ оръё. Тэгэхээр DNA-ын талаар бүх хүмүүс бага зэрэг мэдлэгтэй байх. Хүн 23 хос chromosome-той ба, эдгээрийн 22 нь autosomal буюу хүйсээс үл хамааран бүх хүнд байна.
Харин үлдсэн 1 хос нь X болон Y chromosome-оос бүрдэх ба, эмэгтэй хүнд XX, харин эрэгтэй хүнд XY гэж хослон байна. Эдгээр chromosome-ууд нь олон хэмжээний gene агуулна. Gene гэдэг нь, DNA-ын бяцхан хэсэг буюу, олон хэмжээний base pair-үүдийн цуглуулга юм.
Chromosome тус бүрийн gene, болон base pair-ийн тоог эндээс харж болно.

SNP(Single Nucleotide Polymorphism)
Хэрвээ тодорхой байрлалд хүн амын 1-ээс дээш хувь нь ижил утгатай биш байх юм бол, тэдгээрийн утгуудын олонлогийг SNP гэнэ.
Жишээ нь: 1000 хүний мэдээлэлтэй сан байлаа гэж үзье. 900 хүний, 1 дугаарын chromosome-ын 6546 гэсэн байрлалд A гэсэн утга, харин үлдсэн хүмүүсийнх нь G гэсэн утга байвал, энэ нь SNP болно. Харин 999 хүн нь A, үлдсэн нэг нь л G байх юм бол, SNP биш гэсэн үг.
SNP нь эрүүл мэндтэй холбоотой судалгаа шинжилгээ хийхэд маш хэрэгтэй зүйл юм. Харин нэг анхаарах ёстой зүйл бол 1% гэсэн шалгуур байгаа эсэхийг мартаж болохгүй. Тиймээс нэн ховор генетикийн өөрчлөлтүүд дээр SNP ашиглан судалгаа хийх боломжгүй гэсэн үг юм.
Яагаад SNP ашиглах шаардлагатай гэж? бодож магад. Миний ойлгосноор, бүтэн DNA нь хэт том хэмжээтэй тул, тэр их өгөгдлийг тодорхой хэмжээнд багасгахыг зорьсон. Мөн, хүний бүтэн DNA-г гаргаж авсанаас, SNP microarray ашиглан зөвхөн SNP байгаа байрлалуудын утгыг гаргаж авах нь зардлын хувьд хамаагүй хямд юм. Бүтэн DNA гаргаж авахыг DNA sequencing, харин тодорхой байрлал руу чиглэсэн тандалтыг DNA genotyping гэнэ.

MAF(Minor Allele Frequency) болон minor allele
Ихэнх SNP-үүд нь biallelic буюу, 2-хон төрлийн утга авна. Өөрөөр хэлбэл, A, T, C, G-ын аль нэг 2 нь гэсэн үг. Мэдээж энэ нь одоог хүртэл бүрдүүлсэн сан дээр үндэслэж байгаа тул, ирээдүйд triallelic-ууд олноор гарч ирэхийг үгүйсгэхгүй.
Minor allele(эсвэл risk allele) нь, 2 утгын аль бага давтамжтай нь юм. Өөрөөр хэлбэл, зөвхөн A болон G гэсэн утга авдаг SNP байлаа гэж үзье. 100 хүний 90 нь A, 10 нь G бол, G нь minor allele болно. Зарим тохиолдолд minor allele байсан ч эсрдэлтэй байх албагүй юм. Эсрэгээрээ сайн байх тохиолдлууд мөн байна.
Мөн MAF нь, хүний race болон, гарал угсаанаас хамааран бүлэг тус бүрт өөр байх боломжтой болно.

dbSNP
dbSNP нь NCBI(National Center for Biotechnology Information) гээд АНУ-ын биотехнологийн хүрээлэнгийн сан юм. Эндээс хүссэн SNP-ын мэдээллийг авах боломжтой. Жишээ нь rs16942 буюу хөхний хорт хавдар үүсгэдэг BRCA1 гэдэг gene-ы нэг SNP-ыг харвал доорх байдлаар харагдана.
rs16942
RefSNP Alleles гэдэг хэсгийг харвал A болон G гэдэг утга агуулдаг, өөрөөр хэлбэл biallelic гэдгийг харж болно. MAF гэдэг хэсгийг харвал, G-нь minor allele(хүн амын 35% нь G) гэдгийг мэдэж болно. Мөн Ancestral Allele гэдгийг харвал, хүн болж хувьсан өөрчлөгдхөөс өмнө ямар байсныг харж болно. Ancestral Allele нь chimpanzee-ын DNA дээр үндсэлсэн байдаг.

Raw DNA Data
23andme болон AncestryDNA гэх мэт компаниуд нь DNA genotyping аргаар, боломжийн үнээр таны SNP-г тодорхойлж өгдөг юм. Таны DNA өгөгдөл дараа байдлаар харагдах болно.

rsID         chromosome    position    allele1      allele2
rs4477212             1       72017          A            A
rs3094315             1      742429          A            A
rs3131972             1      742584          G            G
rs12124819            1      766409          G            G

Эхний багана нь SNP-ын дугаар, 2 дахь нь chromosome-ын дугаар, 3 дахь нь байрлал, харин 4 болон 5 дахь таны 2 хос chromosome дахь 2 allele болно.

Өнөөдрийн хувьд, энэ хүртэл бичье. Дараа завтай болхоороо үргэлжлүүлнэ ээ.

Монгол хүн гэдгийг яаж тодорхойлох вэ?

Нэлээн дээх нь төмөр замтай холбоотой нэвтрүүлгээр нэг нэгнээ Монгол биш Хятад гаралтай гэж дайрцгааж байх үед, энэ талаар бичмээр санагдсан ч залхуу хүрээд бичээгүй юм. Харин, өчигдөрхөн Карим Абдул гэдэг хүн нэгэн дуудлага худалдаагаар Улаанбаатарт газар авсаныг олон хүн Монгол биш хүнд газар худалдлаа гэж шүүмжилсэн болохоор бичмээр санагдлаа.
Миний хувьд, Карим Абдул-д газар худалдсаныг зөв эсвэл буруу-г, үнэхээр засгийн газрын ордонд ойрхон байрлалтай газрыг худалдахын зөв бурууг шүүхгүй.
Харин энэ дуудлага худалдаа хууль ёсных уу, мөн Монгол хүн гэдгийг яаж тодорхойлох вэ гэдэг талаар бичмээр санагдлаа.

Хүмүүс Монгол цус гэж ярих дуртай. Харин хүнийг цусаар нь Монгол гэж тодорхойлох боломж бий юу? Та бүхэн мэдэж байгаа бол, цус нь 4-хөн бүлэгтэй. Тиймээс цусны бүлгээр тодорхойлох ямар ч боломжгүй гэдэг нь ойлгомжтой. Харин DNA маш өргөн хүрээний мэдээлэл агуулдаг тул, тэр хүний гарал угсааг тодруулж болно.
Ямар аргаар тодруулах вэ гэхээр, эхлээд Монгол хүмүүсийн DNA-уудыг цуглуулаад, нийтлэг шинжэд нь тулгуурлан, Монгол хүн гэдгийн шийдэх алгоритм зохионо. Тэгээд тэр алгоритмоороо, Монгол гаралтай эсэхийг шийдэж болно.
Тэгэхдээ энэ аргад асуудлууд их байгаа. Хэрвээ DNA цуглуулсан хүмүүс маань, хэдэн мянган жил Монголын газар нутагт амьдарсан хүмүүс биш, 500 жилийн өмнө нь ч юмуу өөр газраас ирсэн хүмүүс бол яах вэ? Тэгвэл бидний зохиосон алгоритм алдаатай ажиллана. Мэдээж хангалттай их sample цуглуулж чадвал, мэдээж Монгол хүний DNA-ын онцлогийг гаргаж чадна.
За гаргаж авлаа гэж үзье. Бараг гаргаад авчихсан байгаа байх.
Тэгвэл тэр шалгуураараа, одоо Монголд байгаа 3 сая иргэнийг шүүж үзвэл, хэдэн хувь нь Монгол гэж гарах бол? Харин шалгуурт тэнцээгүй хүмүүсээ яах вэ? Монголчуудын ихэнх нь 3, 4 үеэсээ дээш сайн мэдэхгүй. 3, 4 үеэрээ Монголд амьдраад, өөрийгөө цэвэр Монгол гэдэгт итгэдэг хэрнээ шалгуурт тэнцээгүй байвал яах вэ? Тэдгээр хүмүүс Монгол хүн мөн үү?
Бас өөрөөр ингэж үзье. Хятадын бүх иргэдийг, Монгол DNA-ын шалгалтанд оруулбал хэдэн хувь нь тэнцэх бол? 1.3 тэрбум хүний маш бага хувь нь тэнцэхэд л хэдэн сая хүн болох байх. Тэдгээрийг Монгол цустай, Монгол хүн гэж үзэх үү?

Тэгэхээр, хүний цусыг шинжэлж Монгол эсэхийг тодорхойлох асуудал бол ер нь боломжгүй зүйл юм. Харин, иргэншсэн нийгэмд, хүний иргэншлийг хуулиар шийддэг. Ихэнх улсад, тэр улсдаа төрсөн бол автоматаар иргэн нь болно. Мөн, иргэн болох хүсэлтээ гаргаад иргэн болох боломжтой. Монгол улсын хувьд, дараах 3 шалгуурт тэнцвэл иргэн болох хүсэлтээ гаргаж болно.

1. Амжиргааны зохих чадвар, эх үүсвэртэй байх
2. Монголын ард түмний ёс заншил, төрийн албан ёсны хэл, Монгол Улсын Үндсэн хуулийн талаар зохих мэдлэг эзэмшсэн байх
3. Монгол Улсын нутаг дэвсгэр дээр таваас доошгүй жил байнга оршин суусан байх

Эх сурвалж: http://immigration.gov.mn/new/?p=436

Тэгэхээр Карим Абдул гэдэг хүн 30 гаруй жил Монголд амьдарсан бол, энэ шалгуурт тэнцэх нь бараг ойлгомжтой. Хэрвээ нэгэнт Монгол улсын иргэн болсон бол, үндсэн хуулийн дагуу шашин шүтлэг, гарал угсаа үл хамааран тэгш эрхийг эдлэнэ.
Хэрвээ дуудлага худалдаад орохыг нь түтгэлзүүлбэл, үндсэн хууль зөрчсөн хэрэг болно. Ардчилсан улсад, үндсэн хуулийг хүнд нь тааруулж өөрчлөх асуудал бол байж боломгүй зүйл.

Харин ирээдүйд ийм зүйл болохоос хэрхэн сэргийлэх вэ? Монгол улсад хэрэгжиж буй хуулиар, гадаадын иргэн газар өмчлөх эрхгүй, зөвхөн тодорхой хугацаатайгаар ашиглах боломжтой. Өөрөөр хэлбэл газар өмчлөхийн тулд, заавал Монгол улсын иргэн болох ёстой. Тэгэхээр Монгол улсын иргэн болох шалгуурыг өндөрсгөхөөс өөр арга байхгүй л гэж бодож байна.
Дашрамд дурдахад иргэн нь болоход хамгийн хэцүү 5 улсын тухай доорх линкээс уншаарай.
http://www.investopedia.com/articles/personal-finance/121114/5-hardest-countries-getting-citizenship.asp

A/B Testing

A/B Testing-ын талаар ярья. Энэ удаад, технологийн талаас нь биш, яг юу болох, яагаад хэрэгтэй вэ гэдэг талаас нь ярья.
Нэг жишээ авья. Counter Strike тоглоом анх эхлэхдээ 800$-тай эхэлдгийг бараг бүгд мэдэж байгаа байх. Мөн, нийт мөнгөний хэмжээ 16.000$-оос хэтэрдэггүй.
Тэгвэл эдгээр тоог яаж шийдэх вэ? Counter Strike-ыг бүтээгчид, A/B testing ашигласан үгүйг мэдэхгүй, тэгэхдээ ямар ч байсан нэг нөхөр дуртай тоогоо хэлээд 800$, 16.000$ гэсэн 2 тоог шийдээгүй нь ойлгомжтой. Тэгвэл яаж шийдэх вэ?
Мэдээж судалгаа хийнэ. Тоглоомоо release хийснийхээ дараа, хэрэглэгчдээ хэсэг бүлэг болгож хуваагаад, 400$, 500$, 600$, 700$, 800$, 900$ гэх мэт мөнгийг анх өгнө. Бас бүлэг тус бүрт 14.000$, 15.000$, 16.000$, 17.000$ гэх мөнгүүдийг дээд хязгаар болгон тогтоож өгнө.
Дараа нь тоглогчид 1 удаа тоглохдоо хэр удаан тоглож байна, өдөрт хэдэн удаа тоглож байна, амьдралынхаа турш хэр их тоглож байна, хэр их мөнгө энэ тоглоомонд зарцуулж байна, гээд янз бүрийн үзүүлэлтийг харна.
Үр дүн дээр нь үндэслэн эдгээр тоонуудыг шийднэ. Зөвхөн шинэ бүтээл гэлтгүй, шинэ feature-үүд дээр ч адил өргөн ашиглана.
Ер нь бол ийм л зүйл. Яаж хэрэгжүүлэх нь хөгжүүлэгчдийн сонголт. Жишээ нь user id-ын сүүлийн 2 орон 00-17 бол бүлэг 1, үлдсэн нь бүлэг 2 ч гэх юмуу ангилна гэсэн үг.
Авсан жишээ жаахан авцалдахгүй байсан бол, уучлаарай.
Have a good weekend!

DynamoDB-ын талаар, зах зухаас

AWS(Amazon Web Services) гэж мэдээж сонссон байх. Тэрний нэг үйлчилгээ нь DynamDB юм. NoSQL төрлийн database. Яагаад энэ талаар ярих болсон бэ гэхээр, миний ажиллаж байгаа тоглоом, infrastructure-аа аль болох AWS-руу шилжүүлэхээр ажиллаж байгаа юм. Яагаад гэхээр, өөрсдөө зөвхөн тоглоом хөгжүүлэх тал дээрээ төвлөрч ажиллаад, сервер талын асуудлуудаа автоматжуулах үүднээс. Мэдээж AWS ашигласанаар зардал гарах ч, dev ops-уудыг ажлуулах зардал болон, өөрсдөө бас хариуцаж байгаа серверүүдийн зардал багасах юм. Тэгэхдээ хамгийн гол зорилго нь найдвартай, high scaling болгох явдал юм.

DynamoDB
NoSQL database гэж дурьдсан. Маш энгийнээр хэлбэл, advanced KVS(Key/Value Store) юм.
Давуу талууд гэвэл
– Ямар ч их хэмжээний өгөгдөл байсан хамаагүй, auto-scaling.
– 10ms-ын дотор өгөгдлийг чинь буцаана. (Scan болон Query ашиглаагүй тохиолдолд)
– Document-тэй ажиллана. Өөрөөр хэлбэл MongoDB шиг JSON өгөгдлийг хадгалаад, тэрнийхээ нэг хэсгийг дуудах, эсвэл нэг хэсгийг өөрчлөх гэсэн үйлдлүүдийг хийх боломжтой.
– Ямар ч их хүсэлт ирсэн хүлээж авах боломжтой. Хүснэгтэндээ read/write throughput тохируулж өгнө. Мэдээж их тохируулах тусам ихийг төлнө. Тэгэхээр илүү уян хатан болж байгаа юм. Хэрвээ site руу чинь секунданд 10 хэрэглэгч ханддаг бол, throughput-ээ багаар тохируулаад, хэрвээ 10,000 хэрэглэгч ханддаг бол, 1000 дахин ихэсгэхэд л хангалттай.

Сул талууд
– MySQL гэх мэт RDBMS-үүд ACID(Atomicity, Consistency, Isolation, and Durability) гэсэн зүйлийг танд амлаж чаддаг. Харин DynamDB-ын хувьд зөвхөн CD(Consistency and Durability) амлаж чадна.
– DynamoDB-ын consistency нь тэгэхдээ eventually consistency юм. Тэр нь юу гэсэн үг вэ гэвэл, нэг өгөгдлийг database-рүү бичих үед, тэр өгөгдөл чинь яг тэр дороо database-д бичигдсэн гэсэн баталгаа байхгүй. Тэгэхдээ хэзээ нэгэн цагт бичигдэнэ гэсэн үг. Тэр нь тэгэхдээ сайндаа л хэдэн ms болохоор, санаа зовох зүйлгүй ч, тэрийг бодолцож системээ хөгжүүлэх хэрэгтэй. Бас eventually consistency ч гэсэн, өгөгдөл унших үед, consistent унших боломжтой, тэр нь inconsistent уншсанаас 2 дахин үнэтэй тул, аль болох шаардлагатай үед л consistent read-ыг ашиглавал зүгээр юм.
– Atomicity болон isolation байхгүй тул, transaction бичих боломжгүй. Системээ, transaction байхгүйгээр зохион байгуулах, эсвэл тэрийг орлох зүйл бодож олох хэрэгтэй.

DynamoDB-рүү хөрвүүлэх гэж байгаа тоглоом
Тоглоомын хувьд гар утасны тоглоом бөгөөд, тоглогч ихсэх тусам, шинээр нэг ертөнц(world) үүсгэн, тэрэн дээрээ шинэ тоглогчидоо хүлээж авдаг юм. Өөрөөр хэлбэл horizontal scaling.
Ертөнц бүр өөрийн world server(GoLang дээр бичигдсэн), тэрний failover, мөн хэд хэдэн ертөнцүүд дундаа 2-3 MySQL server-тэй.
Тэгэхээр 50 ертөнц байлаа гэхэд 50(master world server) + 50(standby world server) + 10(master MySQL server) + 10(standby MySQL server) = 120 орчим server юмуудаа. Эдгээрийг цөөхөн хүнтэй баг өөрсдөө арчлана гэдэг жаахан ядаргаатай юм. Энэ тоо нь зөвхөн нэг тоглоомны server-ын тоо бөгөөд, компаний хэмжээнд яривал 10,000-аад server юм. Өдөр болгон аль нэг серверийн hard disk шатна, ямар нэгэн юм болохоо болино. Тэгэхээр миний хувьд, үнэхээр л том компани биш бол, өөрсдөө арчлах гэж байхаар AWS-ыг ашиглавал их зүгээр санагдсан.
Энэ тоглоомын хувьд болохоор, MySQL server-тэй ерөөсөө харьцдаггүй, зөвхөн world server-тэйгээ харьцдаг. World server нь in-memory болохоор, асар хурдан хариу өгдөг. Бараг хүссэн өгөгдөл чинь 1ms-ээс бага хугацаанд ирнэ. Харин world server нь тогтмол давталттай, өөр дээрх өөрчлөлтөө, MySQL рүү бичнэ. In-memory тул ямар нэгэн асуудал гарвал, бүх өгөгдлөө алдах тул, MySQL-руу бичиж байгаа юм.
Аз болж, тоглоомын бүх код, world server-тэйгээ харьцахдаа, зөвхөн нэг гарцаар дамждаг байсан юм.
Тэгэхээр миний хувьд, тэр гарцийг world server-тэй биш DynamoDB-тэй харьцдаг болгож өөрчлөхөд л хангалттай.
Гарсан асуудлууд
– World server нь зөвхөн өгөгдөл хадгалахаас гадна, өөр дээрээ логик агуулдаг тул тэдгээр логикуудыг application layer-рүү зөөх
– DynamoDB-ын Query болон Scan нь 10ms-ээс бага хугацуунд ирнэ гэсэн баталгаа байхгүй тул бүх өгөгдлийг GetItem, болон BatchGetItem-аар авч болдог байхаар өгөгдлийн бүтцүүдээ өөрчлөх
– Consistent read гэж байгаа ч, зардал хэмнэх үүднээс ямар үед consistent read, ямар үед inconsistent read ашиглахыг шийдэх
– Манайх зарим хэсэг дээрээ, transaction(world server нь бас transaction-тай) ашигладаг тул тэдгээр хэсгийг DynamoDB дээр асуудалгүй ажилладаг болгох
Transaction-ын хувьд, яг одоогоор шийдээгүй байгаа бөгөөд, application layer дээр кодын логикийг өөрчлөх, эсвэл Redis ашиглан өөрчлөх гэж байгаа өгөгдлүүдээ lock хийж байгаад бичих гэсэн 2 санал дээр ярилцаж байгаа.
Бараг Redis л ашиглаж lock бичих аргаар л хийх байх.

Have a nice weekend!

Vagrant болон Docker-ын тухай хальт

Бараг бүх startup компаниуд энэ 2 tool-ыг ашигладаг байх. Startup гэлтгүй томууд нь ч бас ашигладаг байх л даа.
Ямар тохиолдолд ашиглавал зүгээр вэ гэдгийг хальт тайлбарлах гэж оролдъё.
Ямар нэгэн систем хөгжүүлээд дууссаныхаа дараа, бид нар серверрүүгээ кодоо deploy хийдэг. Тэр үед янз бүрийн л асуудалтай тулгарч байсан байлгүй.
Яагаад хөгжүүлж байхад асуудал гараагүй хэрнээ, яг production сервер рүүгээ deploy хийх үед асуудал гарав?
Яагаад гэвэл, хөгжүүлж байгаа орчин(development environment) чинь бүтээгдхүүн болж ажиллах орчин(production environment)-оос чинь өөр байгаа болохоор.
Ихэнх тохиолдолд, Vagrant болон Docker-ыг ашиглахгүйгээр, production-тай яг адилхан орчин үүсгэхэд хэцүү. Ихэнх сервер-үүд Linux based, харин хөгжүүлэгчид ихэвчлэн Mac OS X эсвэл Windows ашигладаг. Mac OS X-ын хувьд UNIX based болохоор, Windows-ыг бодвол арай дээр ч гэсэн, 100% ижилхэн орчин үүсгэхэд бас л хүндрэл гарна.
Ижилхэн орчин гэдгээр би, яг адилхан OS version, яг адилхан PHP version, яг адилхан Ruby version, яг адилхан MySQL version тэй байхыг илэрхийлж байгаа шүү.
MySQL-ын жижиг version-ын өөрчлөлт хүртэл, системээс чинь хамаараад, өөр ажиллах тохиолдол үүсч болно.

Vagrant
Веб хуудас: https://www.vagrantup.com/
Энэ tool нь VirtualBox ашиглан, virtual machine үүсгэн, тэрэн дээр өөрийн чинь хүссэн орчинг бүрдүүлдэг tool юм.
Ашиглахад их энгийн. Vagrantfile дотор, ямар virtual machine үүсгэмээр байгаа, ямар OS ашигламаар байгаа, OS-ээ initialize хийсний дараа юу юу суулгамаар байгаагаа бичиж өгөөд л болоо. Vagrantfile-аа үүсгэсэнийхээ дараа дараах 2 мөр коммандыг бичихэд л хангалттай.

vagrant up // Virtual Machine-ийг initialize хийх
vagrant ssh // SSH-ээр Virtual Machine-рүүгээ орох

Vagrant-ын веб хуудас руу нь ороод харвал, Vagrantfile хэрхэн үүсгэх талаар, их дэлгэрэнгүй тайлбарласан байгаа.
TIP: Synced Folders үүсгэхдээ NFS ашиглавал, мэдэгдэхүйцээр хурдан ажиллана.

Docker
Веб хуудас: https://www.docker.com/
Зорилгын хувьд бол Vagrant-тай бараг төстэй. Тэгэхдээ Docker нь олон Linux based VM үүсгэх үед kernel-ээ share хийдэг юм. Хэрвээ чи Linux ашигладаг бол, чиний ашиглаж байгаа Linux-ын kernel-ийг шинээр үүсгэх OS-ынхээ kernel-ын оронд ашиглана гэсэн үг. Mac OS X болон, Windows-ын хувьд kernel share хийх боломжгүй тул, эхлээд VirtualBox-оор Linux OS-тэй virtual machine үүсгээд, тэрэн дээрээ container үүсгээд явна. Kernel-ээ share хийж байгаа болохоор, Vagrant-ыг бодвол арай хөнгөхөн ажиллана. Тэгэхдээ Mac OS X болон Windows дээр ашиглах гэж байгаа бол, Vagrant-аас ямар ч ялгаагүй. Харин олон container үүсгэх гэж байгаа бол, Docker-нь хамаагүй илүү байх.

Эцэст нь
2-уулаа сурахад нээх хүнд зүйл биш болохоор, завтай үедээ 2-ууланг нь туршиж үзэж байгаад сурсан нь дээр. Манай компаний хувьд, Vagrant-уудаа Dockerize хийж байгаа. Тэгэхдээ “No Silver Bullet”. 2-ууланг нь сурч байгаад, хэрэгцээндээ тохируулж алийг нь ашиглахаа шийдвэл зүгээр.

Cocos 2d-x Demo

Энийг Cocos 2d-x сурч байхдаа хийсэн юм. 1 сарын турш, өдөр бүр 8-16 цаг ажилласан. Clash of Clans-ыг хальт хуулбарлаж хийх гэж оролдсон. Clash of Clans, 1 өдрийн 1,5 сая долларын орлоготой тоглоом гэж бараг бүгд мэдэж байгаа байх. Уг нь үнэхээр хичээвэл боломж бол байгаа л юм шиг санагдсан.

OpenGL / C++

Сүүлийн хэд хоног сурсан зүйлээ хуваалцъя.
Хэлтсээ солисон гэж хэлсэн билүү, үгүй билүү. Front-end engineer болсон. Өмнө нь front-end байсан л даа, хэсэг back-end байж байгаад эргээд front-end болж байгаа санаатай.
Шинэ хэлтэс native тоглоом хийдэг хэлтэс болохоор, OpenGL, болон C++ хэрэглэдэг юм. Аль алинийг нь хийж байсан, тэгэхдээ олон жилийн өмнө. Тэгээд сая хэд хоног сэргээнгээ шинэ зүйл сурч авлаа.

Эхлээд энгийн зүйлээс эхлье. Тоглоомонд, FPS(frames per second) гэж үг бий. Жишээ нь 60fps. Энэ нь секундад 60 удаа зурна гэсэн үг. Өөрөөр хэлбэл 16 миллисекундад чиний бүх тооцоо, бодолт нтр чинь дуусаад зурах зүйлүүд чинь бэлэн байх ёстой гэсэн үг юм. Тэгэхээр performance тал дээр сайн ажиллах ёстой. Ямар нэгэн data-руу хандалт хийх үед loop ерөөсөө хэрэглэж болохгүй, дандаа O(1)-ээр хандах ёстой. Үүний тулд, vector, hash, set гэх мэт өгөгдлийн бүтцүүдийг ашиглана. STL дээр бүгд бэлэн байгаа.

Тэгээд дээрээс нь, сүүлийн үеийн PC-үүд дандаа multi-core болсон. Тоглоомны OpenGL боловсруулах хэсэг(тоглоом гэлтгүй, app-ын core animation хэсэг), ерөнхийдөө main thread дээр боловсруулалт хийгддэг юм. Бүх default event-үүд, update method-ууд main thread дээр дуудагдана. Тэгэхээр тэр дотор шууд бодолт эсвэл data боловсруулалт хийвэл, main thread чинь улам л хоцрох буюу нөгөө 16 миллисекундээс чинь хорогдоод явна л гэсэн үг. Тэгэхээр multi-core оо ашиглаад өөр thread дээр боловсруулалт хийвэл, толгоомын дотоод боловсруулалт чинь, OpenGL тэйгээ зэрэгцэж ажиллана, мөн тооцоо дуусч амжаагүй байсан ч, frame-ээ зураад байх боломж үүсч байгаа юм.
Зүгээр шууд thread ашигласан ч болно, эсвэл GCD(Grand Central Dispatch <– my fav one) гэх мэт library ашигласан ч болно.
Тэгэхдээ thread үүсгэх нь бодсон шиг бас амар эд биш. Memory management-ээ сайн хийх хэрэгтэй. 2 зэрэг ажиллаж байгаа thread 2-уулаа нэг object руу зэрэг хандах үед янз бүрийн асуудал үүснэ.
Жишээ нь, Cocos2d-x гээд engine-ий хувьд, auto releasing pool memory management-тэй. Тэр нь main thread дээр ажиллана. Тэгэхээр жишээ нь, нэг auto-releasing object үүсгээд main thread биш тусдаа thread дээр ашиглаад явж байлаа гэж бодъё. Ашиглаж байх хугацаанд чинь, main thread дээр ажиллаж байгаа main loop нэг бүтэн тойроод, auto releasing object-уудаа memory-оос устгалаа гэж бодъё. Тэгвэл нөгөө thread дээр чинь memory access алдаа үүсээд, тоглоом чинь шууд зогсоно.

Уг нь GCD, Objective-C ын дээд level-ийн framework-ууд гоё ажилладаг юм. Өөрөө автоматаар retain нтр хийгээд. Харин C++ дээр тийм юм байхгүй болохоор, тиймэрхүү зүйлсийг бүгдийг өөрөө хийнэ.

Хэлэх гээд байгаа зүйлс ердөө л 3
1. Thread сайн ашигла
2. Auto-releasing object ийг thread руу дамжуулахад retain хий, хэрэглэж дуусаад release хий
3. OpenGL тэй холбоотой process-ууд main thread дээр

Иймэрхүү жижиг зүйлсээ мэдэхгүйгээс болоод, хэд хоног нойргүй, ямар алдаа гараад байгаагийн учрыг олохгүй эргүүтсэн бодит жишээ байгаа тул, та бүгдийг бас битгий тэгж цагаа үрээсэй гэж бодсондоо бичлээ.