scratchin the surface

Микросервис гэдэг нь програм хангамж хөгжүүлэх техник, аргачлал бөгөөд хоорондоо холбогдох бие даасан дэд системүүдийн нэгдлээс бүрдэх програм хангамжийн бүтэц, зохион байгуулалт юм. SOA буюу сервис-хандлагат архитекторийн нэгэн хэлбэр гэж үзэж болно.

Яагаад MSA (микросервис архитектур) гэж?
Ердөө л 100 хүн амьдрадаг газар байна гэж төсөөлье. Бүгд худгаас усаа аваад, айл бүр гэртээ галаа түлж дулаацаад, ариун цэврийн асуудлаа дор бүрнээ шийдээд амьдраад байх боломжтой. Харин 1000000 хүн амьдардаг газар байна гэж төсөөлье. Ус, дулааны шугам сүлжээнээс авхуулаад хотжилтийн өндөр зохион байгуулалттай дэд бүтэц хэрэг болно.
Товчхондоо яг л үүнтэй адил програм хангамж өргөжин тэлэх үед илүү нарийн зохион байгуулалт хэрэгтэй болно. Иймд тэлэлтийн асуудлыг шийдэх нэгэн шийдэл нь MSA юм.

Программйн тэлэлт гэж тухайн программийн хэрэглэгчдийн тоо болоод түүнээс хамаарах ачаалал, бизнес процесс, техник хангамж ба програм хангамжийн нөөц нэмэгдэх үйл явцийг хэлнэ. Scalability буюу чадлийн цараа гэж системийн тэлэх боломж, потенциалийг хэлдэг. Scalability нь MSA -д зайлшгүй байх ёстой хамгийн эхний чанар(feature). Scalability -г хэрхэн шийдхээс хамаарч програм хангамжийн хөгжүүлэлт, хяналт, арчилгаатай холбоотой маш олон чанрыг MSA агуулах хэрэгтэй болдог.

Миний судлаж, мэдсэнээр одоо байгаа хамгийн хүчтэй MSA -г хэрэгжүүлж байгаа нээлттэй технологиуд нь Kubernetes болон Spring Cloud Netflix. Иймд хоёуланг нь сайтар ойлгохийг хичээж, мөн туршиж ажиллуулж үзсэн. Ийм боломжийг олгосон ITZONE компани болон төслийн багийнхандаа баярлалаа :p

MSA хувьд систем нь сервис буюу дэд системүүдээс тогтох бөгөөд тэлэлтийн асуудлыг  шинээр сервис үүсгэх замаар шийддэг. Ингэснээр сервисүүд тус тусдаа тархмал байдлаар байрших боломжтой болж систем маань өрөө физик-сервер компьютерийн хязгаарлалтаас мултарна. Ачаалал өндөртэй сервисийн хувьд тухайн сервисийг олон хувьлаж ачааллыг багасгадаг. Энэ нь бусад сервисийн хувьд нэг сервис шиг харагдах боловч угтаа нэг сервисийн нэрийн доор параллел сервисүүд ачаалаа хувааж байдаг гэсэн үг. Энэ бол load balancing(ачаалал тэнцвэржүүлэлт). Сервисүүдийн хооронд гинжин хэлхээ маягийн холболт үүсэх ба холболт бүрийн дунд load balancing хийгдэх шаардлагатай.
Олон тусдаа бие даасан сервисүүд гэхээр програм хангамж хөгжүүлэлт болоод арчилгаа, хяналт, тохиргоо гээд бүгд төвлөрсөн бус болж хувирна. Энэ нь MSA -г хэрэгжүүлэхэд тулгарах нэг том асуудал. Төвлөрсөн бус(decentralized) байдлыг төвлөрүүлэхийн(centralized) тулд нэмэлт шийдлүүд хэрэгтэй.
Сервисүүдийг зохион байгуулахдаа аль болох бие даасан буюу модулар(modular) байдлыг дээшлүүлж, ерөнхий тохиолдолд ашиглагдахаар царааг нь бодолцож зохиох нь зүйтэй болов уу.

Мэдээж ерөнхий програм хангамжийн архитехтур учраас заавал Kubernetes ч юм уу Spring Cloud ашиглаж байж MSA болно гэсэн үг биш. Хүсвэл өөрийнхөө шаардлагад тааруулж MSA -г хөгжүүлж болно.

Харин MSA нь доорхи чанруудыг агуулсан байх ёстой.

• Scheduling & Deployment (Тархалт болоод суурьлуулалтын хуваарь)
• Auto Scaling & Self Healing (Автоматжуулсан тэлэлт, Автоматжуулсан эмчилгээ)
• Config Management (Тохиргооны менежмент)
• Service Discovery & LB (Сервисийн бүртгэл, түгээлт ба Ачаалал тэнцвэржүүлэлт)
• Resilience & Fault Tolerance (Алдаанд тэсвэртэй болоод уян хатан байх)
• API Management (API менежмент)
• Service Security (Сервисийн аюулгүй байдал)
• Centralized Logging (Төвлөрсөн лог, бүртгэл)
• Centralized Metrics (Төвлөрсөн үзүүлэлтүүд)
• Distributed Tracing (Тархсан хяналт)

Энэ бүгдийг сайтар зохион байгуулна гэдэг зөвхөн програм хангамжийн инженер эсвэл системийн архитехтурийн мэдлэг дангаар хийхэд хэцүү ба програмчлал, сүлжээ, аюулгүй байдал, devops зэрэг олон төрлийн туршлага, мэдлэг оролцох хэрэгтэй болдог.
Магадгүй ийм болоод ч тэрүү Netflix -н хувьд бүх хөгжүүлэгчидээ full stack биш full-cycle хөгжүүлэгч болгохоор шахдаг байх.

Container тухай сонсож байгаагүй бол: What is a Container?
Virtual Machine үүд үеээ өнгөрөөж бүгдийн контейнарт л чихдэг болж дээ :p

Kubernetes буюу K8s

Google -н арав гарам жил програм хөгжүүлэлтэндээ ашиглаж, сайжруулж ирсэн аргачлал. Google -д Borg гэж ашиглагддаг, kubernetes -г Borg -н нэгэн branch гэж ойлгож болно.

Kubernetes өөрийгөө container orchestrator гэж танилцуулдаг. Тэр ч утгаараа container үүдийг зохион байгуулж ажиллагааг нь нэгтгэж өгдөг.
Kubernetes маш олон ойлголтуудыг агуулсан том технологи байсан учраас хаанаас нь эхлэж яаж ойлгох гээд нэлээдгүй хүндрэлүүдтэй тулгарсан. Янз бүрийн блог уншина, бүгд өөр өөр юм бичсэн ч юм шиг. Тэгсэн хэрнээ их ерөнхий юм ойлгоод байгаа болхоор тэр хэрээрээ хүссэнээрээ хэрэгжүүлж чадахгүй бүдэг бадаг. Нарийн ойлгоё гэхээр мэдэхгүй зүйлстэй тулгараад. Ажиллуулж үзсэн ч цэгцтэй биш алаг цог энд тэндээс мэдээд байгаа болхоор бас л болж өгөхгүй. Энэ маягаараа бүтэхгүйн гээд шууд udemy -с хичээл авч үзсэн.
Үүний дараа бүх юм хамаагүй цэгцтэй болж хувирсан.
Хөгжүүлэгчид гэхээсээ илүү систем админ, devops ийнхонд зориулагдсан юм байна лэ.

Сервисүүд буюу container -үүд нь kubernetes -н хувьд pod, node, service, cluster гэх нэгжүүдэд шаталсан байдлаар ангилагдана. Kubernetes нь дангаараа бүгдийг хийх боломжгүй бөгөөд гол ажиллагаа нь сервисүүдийг зохион байгуулахад л төвлөрнө. Харин бусад зүйлсэд зориулж API үүд гаргасан байх ба үүнтэй нь гуравдагч/дэмжиж ажиллах програмууд add-on хэлбэрээр сууж хамтарч ажилладаг. Бүх ажиллагаа descriptor файлуудаар зохицуулагдах боломжтой байдаг.

Жишээ нь: kubernetes дотроо сервисүүдийнхаа хооронд дэд сүлжээний бүтэц байгуулах хэрэгтэй болно. Мөн тэдгээрийн хооронд load balancing хийх, хяналт хийх зэрэг дээр дурьдагдсан чанруудыг хэрэгжүүлэх хэрэгтэй. Тэр бүгдэд нэмэлт add-on ууд хэрэглэнэ. Харин сервисийн аюулгүй байдлыг хувьд нэгдсэн шийдэл байдаггүй. Учир нь container дотор ямар ч програмчлалын хэлээр, яаж хөгжүүлсэн нь сервисийн өөрийн асуудал болно. Энэ нь нөгөө талаасаа Spring Cloud тай харьцуулвал програмчлалын хэл болоод дурийн санг ашиглах эрх чөлөөг олгодог.

Мэдэж хэд хэдэн kubernetes cluster -ууд хоорондоо нийлж холбогдон ажиллах боломжтой.

Kubernetes дотор тухайн сервис ажиллах боломжгүй болж хариу өгөхгүй байх эсвэл алдааны улмаас унтарсан тохиолдолд тухайн сервисийг автоматаар устгаад сервисийг анх суулгасан deployment descriptor ийн тусламжтайгаар шинээр үүсгэдэг. Мөн сервисүүдийг хүссэнээрээ хувьлан тоог ихэсгэж, багасгах боломжтой. Нөгөө талаас ачаалал ихсэх үед өөрөө автоматаар сервисүүдийг хувьладаг. Хувьлаж сервисүүдийн тоог нэмэгдүүлэх явцийг kubernetes -т тэлэх (scale) хийх гэдэг. Мөн тухайн нэг сервис унтарсан ч хуулбарууд нь ажиллаж байх боломжийг бүрдүүлнэ. Энэ маягаар шинэ хувилбар байршуулах зэрэг программийн шинэчлэл нь одоо ажиллаж байгаа системийг доголдуулахгүйгээр нэвтэрдэг. (Солиотой юм байна лээ)

Kubernetes container үүдийг descriptor -н тусламжтайгаар шинээр үүсгэдэг гэдгийг анзаарсан байх. Мөн шууд устгах боломжтой. Энэ нь тухайн container -т ямар ч файл, кеш зэргийг хадгалж болохгүй гэсэн үг. Тэгэхээр бүх сервис маань ямар ч төлөв хадгалдаггүй stateless байх ёстой болно. Иймд энэ асуудлыг шийдэж сервисүүдийг stateful болгохын тулд volume гэх нэгжийг оруулж ирдэг. Volume нь kubernetes -г ямар нэг файл системтэй холбож өгдөг нэгж бөгөөд тухайн volume устаж, шинээр үүссэн ч файл системтэй холбоотой хэвээр байдаг. Ихнэхдээ өгөдлийн санг volume байдлаар байршуулахад зориулагдсан.

Тохиогоо болоод нэвтрэх эрх зэргийг нэгдсэн байдлаар хадгалаж ,түгээхдээ kubernetes secret гэх хувьсагчуудыг хадгалах ба secret -үүдээ тухайн сервисрүү environment variable эсвэл file system -д оруулах замаар түгээх боломжтой.

Харин  ingress controller(gateway сервисийн үүрэг гүйцэтгэгч гэж ойлгож болно) болон load balancer -ууд нь зөвхөн Amazon Web Service, Google Cloud Engine, Microsoft Azure зэрэг cloud provider ууд дээр суулгаж байж ажиллах боломжтой байсан учраас цаашид физик-сервер (bare-metal server) дээр ажиллах боломжгүйг ойлгоод kubernetes -ээс татгалзсан.

Spring Cloud Netflix

Spring Framework суурьлаж Netflix OSS -н хөгжүүлсэн Spring Cloud Netflix шийдэл.

Spring Cloud Netflix тухай бичихээс өмнө Java -г сайтар мэдэх хэрэгтэй. Зөвхөн Java -г ашигласнаар веб технологи хөгжүүлэх, програмчлахад бусад технологиудтай харьцуулахад хамаагүй олон давуу талыг эдлэнэ. JavaSE, JavaEE -н хүчтэй API уудаар хангагдаж Central Maven Repository -д байх баялаг сангууд болон технологийн интеграцууд, нэмээд Spring өөрийнх аюулгүй байдал, тохиргооны суурь бүтэц, эмбэддэд веб сервер зэргийг үүнд дурьдаж болно.

Spring Cloud шийдэл нь Spring framework -ийг суурь бүтцээ болгож ашигласан олон төрлийн бүтээгдэхүүн байх бөгөөд бүгд MSA -г хэрэгжүүлэх тус тусын үүрэгтэй оролцоно. Мөн өөр хоорондоо хоршиж ажиллах зориулалттай.

Сервисүүд нь Eureka гэх сервис дээр зангилагдах бөгөөд энэ нь сервисийн бүртгэл болоод бусад сервисүүдийг хооронд нь холбох үүргийг гүйцэтгэнэ. Харин бусад сервис үүд нь Eureka client болж холбогддог. Spring Cloud хувьд сервисүүд нь бүгд нэг програмчлалын хэл, нэг платформ ашиглаж байгаа учраас үүнийг дагаад kubernetes -тэй харьцуулахад хэд хэдэн давуу талууд бий болдог.

Үүнд баталгаажуулалт(auth) -н сервистэй Zuul гэж нэрлэгдэх gateway сервис нь нэгдэж ажилласнаар аюулгүй байдал болон баталгаажуулалтыг MSA хувьд бүхэлд хангах нь хангах боломжтой. Мэдээж хэрхэн яаж хэрэгжүүлэхээсээ хамаараад өөр өөр байж болно. Миний хувьд auth сервис маань токен шинээр үүсгэх ажил л хийнэ. Харин токен шалгалтийг gateway сервис дээрээ филтерлэж шалгана. Gateway сервисээр дамжиж бүх хүсэлт орж ирэх болхоор ингээд лонхны хүзүүн дээр нэг удаа боогоод өгчихөж байгаа санаа. Мөн нэгдсэн log, хяналт болон алдаанд тэсвэртэй байх, уян хатан ажиллаагааг Turbine, Hystrix, Atlas зэрэг Spring дээр суурьласан бусад технологиуд нь шийдэж өгдөг.

Харин автоматаар алдаа гарсан сервисийг kubernetes тэй ижил зарчмаар эмчлэх боложмгүй, байдаг яагаад гэвэл сервис бие даасан байх ба тухайн сервист гаднаас нь нөлөөлөх механизм байхгүй. Иймд мөн автоматаар сервисүүдийг хувьлаж тэлэх боломжгүй. Сервисүүдийг хувьлах болон өөрөө өөрийгөө эмчлэх үйлдэл нь механик байдаг. Энэ тохиолдолд Eureka сервистэй холбогдож мэдээлэл авч. Шинээр сервис хувьлах асаах зэрэг үйлдүүдийг зохицуулдаг програм хөгжүүлэх боломжтой.

Энэ сул талаа нөхөхийн тулд сервисүүдийн хяналт, алдаанд тэсч үлдэх байдал зэргийг маш сайн бэлдэж өгсөн. Зөвхөн Spring @Service @Controller функц(метод) дээр нөөцийн хуваарлалт хийж, тухайн функц дээр сервисийн хувьд хэр их ачаалал өгч байгааг хянах боломжтой. Үүнийг Turbine болон Hystrix тусламжтайгаар хялбар хэрэгжүүлнэ.

Ачаалал тэнцвэржүүлэгчийн хувьд Eureka сервис эсвэл gateway дээр биш, client сервисүүд дээрээ зүгээр л annotation тавьж хэрэгжүүлж байгаа нь маш таалагдсан.

Миний хувьд бусад програмчлалын хэлийг бодвол java  -г илүү эзэмсэн JavaEE болон Spring дээр туршлагатай байсан, мөн түрүүлж kubernetes -г судлаад MSA -н ойлголтуудыг авсан байсан болхоор Spring Cloud хэрэгжүүлэхэд тийм ч их хүндрэлтэй тулгараагүй. Мөн элдэв янзийн тохиргоо, tool гэхээсээ илүү бусад технологиудаа кодчилж, кодон дотроо хийж байгаа нь илүү ойр санагдсан.




Spring дээр ELK, Sleuth, Zipkin энэ тэр гээд туршиж үзээгүй ба мэдэхгүй зүйлс байнөө байна. Харин kubernetes -н хувьд ойлгоогүй үлдсэн зүйлс нэлээдгүй байгаа болов уу.

Дуу хоолой, хөгжим, авиа зэрэг дуулдаж болох бүх зүйлс дууны долгионоор орчинд тархаж, чихэнд хүрсэнээр бид сонсдог. Харин дууны долгионы давтамж болон далайц нь духайн хоолой, дуу ингэж сонсдоно гэдгийг тодорхойлдог. 
Энэхүү блогт хэрхэн дууны долгионыг үүсгэх, түүнийг удирдах болон програмчлах аргийг энгийнээр тайлбарлахыг зорилоо.

Хэрхэн дууны долгион үүсгэх вэ?

Математитик тэгшитгэлүүдийн тусламжтайгаар бид дараахи энгийн долгионуудыг хялбар аргаар үүсгэж болно. 


Sine буюу синусоид функцээр үүсгэх долгионы тэгшитгэл нь дараах хэлбэртэй байна.
A нь далайц (amplitude)
f нь давтамж (frequency) 
t нь хугацаа. Энэхүү хугацаа нь синусоид функцийг дискрет хугацаанд үүсгэхийн тулд sampling хийж буй хэрэг юм. Хугацааны утга нь дискрет өсөлттэй байх бөгөөд энэ нь делта t байна. dt гэж тэмдэглэе. dt нь sampling хийх үеийн нэгж хугацааны давтамжийн утга болно. Энэ нь t ийн утга нэгж хугацааны дараа dt-р нэмэгдэнэ гэсэн үг. 

Харин хөрөө(sawtooth) хэлбэрийн долгион үүсгэх тэгшитгэл нь.

Мөн A, f, t нь дээрхи синусиод функцтэй адил байна.
Цэнхэр нь синус, улаан нь хөрөө хэлбэртэй үргэлжилсэн утга үүсэж байгааг харж болно. Харин одоо хоёр функцээ нэгтгэе. Шууд тэгшитгэлийнхээ утгуудыг хооронд нь нэмнэ.

 

Долгионыг хэрхэн хөгжмийн нот болгох вэ?

.00

NPath complexity нь кодны үнэлгээ хийхэд ашиглагддаг арга юм. NPath complexity -г функц/метод бүрийн хувьд тусад нь тооцох бөгөөд тухайн функцийн циклгүй гүйцэтгэх үйлдлийн тоо юм.
NPath complexity стандарт хязгаар нь нэг функцийн хувьд 200 байвал зохино гэж үзнэ.
Хэрэв 200 -с хэтэрсэн бол кодчилолын комплекс байдлыг багасгах ёстой. Энэ нь тухайн функцийн алгоритмыг өөрчлөх тухай ойлголт огт биш бөгөөд функциональ чадамжийг сайжруулж комплекс үйлдүүдийг нэг болон түүнээс дээш функц болгон хуваах хэрэгтэй гэсэн үг.

Жишээ 1: 
Доорхи жава класс файлын boostrapGrid() методийн хувьд NPath complexity нь 3456 хүрсэн байгаа :p 
https://github.com/lupino22/kronometer/blob/fefeba2eccf5e0c922c53f93f285100e12939084/src/java/mn/scio/processor/HyperTextBuilder.java 

Методын эхэнд байгаа гараар бичсэн bubble sort ийг Java.util.Comparator -ийн sort үйлдэлээр солиход



NPath complexity нь 200 -аас бага болсон байгаа.

Bubble sort O(n^2) хугацаанд маш удаан эрэмбэлдэг бол Java.utilComparator -ийн sort нь timsort гэх алгоритм ашигладаг. Энэ нь merge sort болон insertion sort ийг хослуулж сайжруулсан алгоритм юм. Хугацааны үнэлгээ нь O(nlogn)байна. Эндээс харахад методын хурд эрс сайжирсан ба замбраагүй мэт харагдах давталтууд ганц мөр код болсон байгаа. Тэгхээр бүгдийг гараар бичхээс илүүтэйгээр тухайн асуудлыг аль хэдийн шийдсэн методуудыг ашиглах нь бүтээмжийг дээшлүүлнэ.

Жишээ 2:
Доорхи жава класст тоог монгол хэлний хэллэгээр нь тескт болгон хувиргадаг методууд бий. 
https://gist.github.com/lupino22/44cff28c1db9d3a49697b9d19eb65671

Монголчууд бид тоог дуудахдаа зуутын орноор нь тасалж дууддаг, иймд зуутын орон болон аравтын орныг тоог текст болгох хэсгүүдийг тус тусад нь метод болгож бичсэн. Ингэснээр кодын NPath complexity багасч илүү ойлгомжтой цэгцтэй байдал нь нэмэгдсэн. Мөн javadoc стандартаар коммент бичсэн байгаа. Энэ хэдий  NPath complexity -д нөлөөлөхгүй ч кодыг улам ойлгомжтой болгоно.

/*
 Иляагийн блогоос уншсан зүйлээ өөрийн ойлгосоноор орчуулан мөн өөрт байгаа ажлын тушлагаас нэмж бичлээ. Би өөрөө ч эхлэн суралцагчдийн нэг. Хэрэг болох нэгэнд нь хэрэг болсон гэж найдья.
*/

Хувь хүнээс хамаарах хүчин зүйл

Bug буюу алдаа
Програм хангамжид bug гарах нь зайлшгүй тохиолддог зүйл. Үүнийг хүлээн зөвшөөрөх хэрэгтэй. Хөгжүүлэлтийн үйл явцад маш олон төрлийн bug тохиолдоно. Энэ асуудлыг шийдэх хамгийн сайн шийдэл нь зөв хөгжүүлэлтийн процесс юм. Тэрхүү процесс нь доорхи зүйлсийг багтаасан байх шаардлагатай.

• Автоматжуулсан тест - Програм хангамж бүтээгдэхүүн болох үед bug гарах боломжийг багасгадаг. Хөгжүүлэлтийн явцад тестэнд өртөөгүй bug байж болох  бөгөөд бүтээгдэхүүний үе шат нь тестийн үе шатаас нэлээдгүй ялгаатай байдаг. Энэ нь зарим алдаа бүтээгдэхүүн болсон үед урган гарч ирдэг ба үүнийг зайлшгүй хянаж байх хэрэгтэй гэсэн үг юм. Автоматжуулсан тест нь доорхи асуудлуутай тэмцэхэд туслана
• Тестүүдийг гараар оруулж, гараар үр дүнг шалгадагтайгаас болж хөгжүүлэлт удаашрах
• Гар аргаар тестлээд их хэмжээний алдаа гарч ирэх
• Муу кодчилол, бараг шинээр эхлэх нь хамаагүй дээр болсон тохиолдлыг эрт илрүүлдэг
• Аажмаар шинэ хувилбар байршуулах (gradual deployment) - Дэлгэрэнгүйг эндээс
• Хяналт - Ажиллаж буй программын алдааг илрүүлэх. Программын үзүүлэлтүүд, сүлжээний ачаалал, нөөцийн хэрэглээ гэх мэт шаардлагай үзүүлэлтүүдийг хянах хийх. Энэ нь аажмаар хувилбар үүсгэх (gradual deployment)-тэй сайн хослодог.
• Гүйцэтгэлийн саатал болон алдааг ажиллаж буй кодноос илрүүлэх, debug хийх. Дэлгэнэгүйг эндээс. (Ялангуяа Metrics гэсэн гарчигийг сайн хараарай)
• Автоматжуулсан эмчилгээ буюу rollback - Бага зэрэг зальхай, найдвар муутай арга. Бас болгоомжтой ашиглах хэрэгтэй. Жишээ нь: Системд  хамгийн сүүлд суурльлуулсан хувилбар алдаатай эсвэл хэт их ачаалладаг, удаан ажиллагаатай байвал автоматаар алдаагүй өмнөх хувилбарыг сэргээн суурьлуулна гэсэн үг юм. 

Зөв хөгжүүлэлтййн процессруу чиглэх нь бүтээгдэхүүнийг бэлэн болохоос өмнө bug-ийг багасгаж bug засахад зарцуулах хугацааг хэмнэх давуу талтай.

Аль хэдийн шийдсэн боловч ...
А гэх асуудалыг зөвхөн М гэсэн шийдлээр шийдэх ёстой гэж үү? А асуудлыг К тооны шийдлээр шийдэх боломжтой боловч тэдгээр K тооны шийдлээс М нь хамгийн оновчтой байсан учраас сонгогдсон байж болох юм. Гэвч А асуудлын нөхцөл өөрчлөгдөх үед М оновчтой шийдэл хэвээр үлдэж чадах уу? Нөхцөлөөс хамаарч Б шийдэл илүү оновчтой байж болно.
Иймд асуудлыг нэг тогтсон арга барилаар шийдэхээс өмнө өөр шийдэл таний нөхцөлд илүү оновчтой байж болох тухай ахин бодож үзэхэд илүүдэхгүй.

Хялбарчилсан V.S. Хөнгөвчилсөн
Хялбарчилсан: Маш богинохон товч бөгөөд тодорхой ганц мөр код
Хөнгөвчилсөн: Фреймворкоос зуу зуун функц дуудаж ажиллуулах ганц мөр код

Эрч хүч, мотиваци (hype) 
Мэдээллийн технологийн үйлдвэрлэлд эрч хүч, мотиваци үнэхээр чухал байр суурь эзэлдэг. Компаниуд ашиг олохын тулд бүтээгдэхүүн хөгжүүлдэг. Мэдээж ашиг гэхээс илүүтэйгээр бүтээгдэхүүнээсээ эрч хүч авах нь илүү чухал. Бүтээгдэхүүнээс маш олон янзаар эрч хүч, мотиваци авч болно. Энэ тухайн бүтээгдэхүүнийг та юу гэж харж байгаагаас хамаарна. 

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

• Энэ ажил миний төлөвлөснөөс илүү чармайлт, цаг хугацаа шаардах болно
• Үр дүнд нь гарах код системийг илүү ойлгоход бэрх болгоно. Мөн арчилгаа, засвар хийх үед хар дарсан зүүд л гэсэн үг
• Энэ хэсэг нь бараг л хэрэгцээгүй, ер нь хэзээ ч ашиглагдахгүй

Мэргэжилтнүүд nice-to-have буюу програмд байхад дажгүй зүйлээс аль болох зайлс хийдэг. Мэдээж зайлшгүй оруулах албагүй үед.




Код

Кодын давхардалт (duplicate)
Өөрийн бичсэн кодыг олон дахин битгий хуул. Copy+paste хийхээс зайлс хийх хэрэгтэй.

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

Кодын дахин хэрэглээ
Харин үүнийг аль болох хэрэгжүүлэх хэрэгтэй. Энэ нь фреймворк, сан, класс, функц зэргүүд орно. Эдгээрийг зөв боловсруулж, сайн хэрэглэх нь бүтээмжийг эрс дээшлүүлдэг. Гэхдээ хэрэглэхээсээ өмнө заавал documentation -ийг нь унших цаг гаргах хэрэгтэй. Ингэх нь архитектур, функциональ байдал, чадамж, хязгаар зэргийг ойлгуулдаг. Уншихгүйгээр функцуудын ажиллагааг махчилан ойлгох эсвэл тодорхой код харж ойлгоно гэдэг хэтэрхий хүчир бөгөөд цаг алдсан ажил. Үүний оронд унших нь цаг хэмнэхээс гадна өөртөө оруулах маш сайн хөрөнгө оруулалт болох юм.
Хэрэв үүнийг өөрөө хөгжүүлж байгаа бол кодны documentation -ийг маш сайн хийж өгөх хэрэгтэй.  Програмчлалын хэлүүдэд стандарт documentation хөгжүүлэх загварууд байдаг жишээ нь.

• Java: Javadoc
• C/C++: DOC++/Doxygen
• Python: Pydoc гэх мэт

Мэдээж заавал эдгээрийг дагаж мөрдөх албагүй. 

Кодчилох хэв маяг
Өөрийн гэсэн нэг хэв маягийг сонгоод түүндээ туушдаа байх хэрэгтэй. Зарим тохиолдолд олон программисттуудтай хамтарч ажиллах үед баримтлах дундын стандарт нь таний кодчилох хэв маягт нөлөөлж болох ч энэ нь үндсэн хэв маягт төдийлөн нөлөөлөхгүй ба дасан цохицож болохоор жижиг зүйл.
Маш ховор тохиолдолд зарим программистууд уламжлалт keyboard -ний QWERTY байршилийг бус DVORAK байршилийг ашигладаг. Учир нь QWERTY байршил нь 10 хуруугаар өгүүлбэр, эх бичихэд зориулагдсан байдаг ба код бичихэд зохимжтой бус гэж үздэг. Кодчилолд өргөн ашигладдаг тэмдэгтүүд болох " ' [ ( { < ; зэрэгүүд нь бүгд баруун гар талд бас нэг доор шавж байршсан байдаг.

Систем болон кодын комплекс үнэлгээ
Аль болох энгийн хялбар кодчилохыг эрмэлзэх хэрэгтэй. Замбраагүй, ойлгомж муутай кодчилсон систем нь доорхи сөрөг нөлөөтэй.

• Арчилгаа хийхэд төвөгтэй
• Нэмж кодчилоход хэцүү
• Алдаа их гардаг
• Алдааг хайж илрүүлэхэд хэцүү

Нарийн төвөгтэй байх, ойлгомжгүй замбраагүй байх хоёр ялгаатай зүйл. Зарим үед асуудлыг шийдвэрлэхийг тулд зайлшгүй нарийн төвөгтэй (комплекс) код бичих шаардлагтай үе бий. Харин кодчилох үед будилаантай, ойлгомжгүй, замбраагүй байна гэдэг муу програм хангамжийн архитектур, муу зохиомж эсвэл муу хөгжүүлэлттийн үр дагавар. Мэргэжлийг программистуудыг аль болох энгийнээр бичиж, илүү цэгцтэй код гаргаж авдаг.


Мэдлэг ур чадвар

Доорхи мэдлэгүүдийг эзэмшсэн байх хэрэгтэй.

Онолын мэдлэг:

• O тэмдэгэлгээ (математик функц, алгоритмын хязгаарыг дүрслэх)
• Нийтлэг өгөгдлийн бүтцүүд. Хэрхэн хэрэгжүүлдэг тухай
• Нийтлэг алгоритмууд, мөн тэдгээрийн хугацаа болоод санах ойн үнэлгээ
• Асуудал шийдэх(Бодлого бодох) парадигм
• CPU юу хийдэг. Хэрэглэж буй CPU чинь ямар opcode -той эсэх.
• Compiler болон compilation гэж юу болох
• Interpreter гэж юу болох
• Кернел гэж юу болох. Үйлдлийн системийн үйл ажиллагаа  

Онолыг мэдлэгүүдүүд нь хугацаа өнгөрөх тусам өгөөжөө өгдөг. Хурдацтайгаар шинэ технологид суралцаж, сайжруулахад маш хэрэгтэй ба цаашлаад амжилттай мэргэжилтэн/эксперт болоход түлхэц болно.

Практик мэдлэг:

• Хоорондоо ялгаатай, тэс ондоо ядаж гурван програмчлалын хэл сурсан байх. C/Java, python, lisp гэсэн гурван хэлийг санал болгож байна. Хэдийгээр lisp хэл дээр ажил олдохгүй ч чамайг илүү сайн программист болгох болно. Яагаад гэдгийг эндээс ушаарай
• Компьютерийн сүлжээ, интернет, протоколууд хэрхэн ажилладаг болхыг мэддэг байх
• Үүлэн тооцооллын тухай ойлголтууд 

Практик мэдлэг бол гүйцэтгэлийн хэмжүүр. Таний гүйцэтгэл хэр өндөр түвшинд байна энэ нь танийг тийм түвшиний практик мэдлэгтэйг харуулдаг.

Багаж, хэрэгслүүд
Мэргэжилтэн болхыг хүсэж байвал багажтайгаа ажиллах туршлагатай байх хэрэгтэй. Төсөөл дөө: Ажлынхаа нэлээдгүй цагийг зүгээр л текст(ер нь бол код) засварлахыг тулд өнгөрөөж байна гэж. Үүний оронд хөгжүүлэлтийн орчны хэрэгцээт коммандуудыг сурсан бол ажлын бүтээмжийг 10-20 хувь дээшлүүлнэ. Ухаалаг байдлаар ажиллахын тулд багжаа сайн эзэмших хэрэгтэй.

Эцэст нь хэзээ ч суралцахаа зогсоож болохгүй. Өөрийн суралцах чадвараа маш сайн хөгжүүлэх хэрэгтэй. Энэ нь ажил дээр гарахад хамгийн чухал чадваруудын нэг юм шүү. 

PS: Нөгөө FB хаяг маань хаалттай байгаа учир тэр хаяг дээр байсан нийтлэлийг блогтоо хууллаа.

Копьютерийн ухаан, мэдээллийн технологийн чиглэлээр суралцдаг найз нөхөддөө доорхи 3-н баримтат киног заавал үзээрэй гэж зөвлөе.
1. "Citizenfour (2014)". Дөрөвдөгч иргэн буюу энэхүү кинонд Edward Snowden гэх залуугийн тухай өгүүлнэ. Хэрэв анзаарсан бол нэг хэсэгтээ л энэ хүний тухай гадаад мэдээ, энд тэндхийн сонин сэтгүүлээр бичиж байсан. 21-р зууны мэдээллийн технологийн хурдацтай хөгжил бидний өдөр тутмын амьдралын салшгүй нэг хэсэг болсон ба тэр хэрээр бид бүхэн өөрсдийн хувийн нууц, эрх чөлөөт байдлаа эрсдэлд оруулж байна. Бид нэг товчлуур дараад л тухайн хүний тухай бүх мэдээллийг хардаг тийм өгөгдөл бүхий програм хангамжийг уран зөгнөлт кинон дээрээс л харах боломжтой гэж боддог байсан бол тэр үе аль хэдийн ард хоцорчээ. Ихэнх томоохон компани, корпрациуд бүгд засгийн газарт худалдагдсан ба засгийн газартай нийлж олон нийтийн өмнө, шүүхийн өмнө худал хэлсээр байна. "Та бүхний хувийн мэдээллийг бид аюулгүй хадгаладаг" гэж. АНУ засгийн газар ямар аймшигтай зэвсгүүд/хэрэгслүүд бүтээсэн болох, бид яг үнэндээ хичнээн адчилсан бус нөхцөлд амьдарч байна вэ гэдгийг энэхүү баримтат кинон дээрээс үзэх боломжтой. Дашрамд дурьдахад энэхүү кино 2014 онд Academy Awards -д 'Шилдэг баримтат кино' төрөлд нэр дэвшиж, Оскарийн шагнал хүртсэн юм.
2. "The Internet's Own Boy: The Story of Aaron Swartz (2014)". Интернетийг өөрчилсөн хүү: Aaron Swartz -ийн түүх. Тэрээр 13-н насандаа ArsDigita-н шагнал хүртсэн. Энэхүү шагналыг жилд нэг удаа "хэрэгцээт, боловсролын, хамтын ажиллагааны" гэсэн чиглэлээр ашгийн бус веб хөгжүүлсэн хүнд олгодог. 14-н насандаа RSS(Really Simple Syndicate/Маш энгийн синдикат) 1.0 хөгжүүлэх багийн албан ёсны гишүүн. RSS нь текст болон метадатаг агуулсан web/news feed стандарт. 15-н насандаа Creative Commons үйл ажиллагаанд идэвхитэй оролцон интернетд үнэгүй, эрх чөлөөт мэдээ, мэдээлэл түгээх ажлын төлөө тэмцэж байсан. Тэрээр ердөө 26 насандаа 2013 онд таалал төгссөн юм. Амьдралынхаа сүүлийн жилүүдэд PIPA/SOPA буюу интернет дахь зохиогчийн эрхийн хоригийн тухай актын эсрэг хүчтэй тэмцэл өрнүүлсэн юм. Тэрээр хувийн нууцийг хамгаалах тал дээр мөн чамгүй ажиллсан байдаг. Бид өнөөдөр интернетд видео, мэдээлэл, зураг, хөгжим зэргийг үнэ төлбөргүй ашиглаж байгаад энэ залуугийн хувь нэмэр чамгүй их билээ. Мөн интернетийн удиртгал хуудас гэж нэрлэгддэг reddit.com -ийг үндэслэгч юм. Түүний амьдрал, хийж бүтээсэн зүйлсийн тухай маш дэлгэрэнгүйг энэ кинон дээрээс үзэх боломжтой.
3. "We Steal Secrets: The Story of WikiLeaks (2013)". Edward Snowden -ий тухай шуугихаас өмнө бас нэг томоохон шуугиан тарьсан явдал бол WikiLeaks АНУ-н нисгэгчгүй онгоц буюу дронууд хэрхэн гэмгүй иргэдийг хөнөөж байгаа бичлэгүүд олон нийтэд ил болгосон явдал байсан юм. Julian Assange нь Австрали гаралтай программист хүн. Тэрээр WikiLeaks -г үүсгэн байгуулагч юм. Энэхүү кинонд Julian Assange болон WikiLeaks нь АНУ түүхэн дэх хамгийн том аюулгүй байдлын нууц уруу нэвтрэсэн хэргийн тухай өгүүлнэ. (Магадгүй Snowden -ий хэрэг үүнээс ч том байх л даа хэхэ)

Яагаад заавал баримтат кино вэ?
Жишээ нь Mark Zukerberg -н тухай The Social Network, Julian Assange -н тухай The Fifth Estate зэрэг УСК нууд хийгдсэн байдаг. Гэхдээ УСК дээр гарсан бүхэн хэтрүүлэгтэй, худал гэдгийг дээрхи хүмүүс өөсдөө хэлсэн байдаг. УСКиног нь баримтат кинотой харьцуулж шүүмжилсэн юм биш шүү. Угаасаа ч тэгэх боломжгүй. Үнэхээр тэдгээр хүмүүсийн тухай арай бодитой зүйлсийг мэдмээр байвал баримтат киног нь үзсэн нь дээр.

Хэрэв дээрхи 3 таалагдвал
TPB AFK: The Pirate Bay Away from Keyboard (2013)
Terms and Conditions May Apply (2013)
гэсэн 2 баримтат киног үзээрэй.

[log]
Миний бичсэн анхны судалгааны өгүүлэл. Алдсан юм их байгаа цаашдаа улам сайн, чанартай өгүүлэл бичихийг хичээнээ. Судалгааны ажлыг маань удирдсан Хүдэр багш болон программын үр дүнг шалгах өгөгдөл цуглуулахад тусалсан Пүүжээ (Пүрэвбаатар), зөвлөгөө өгсөн дискрет математикын Лутбат багш нарт маш баярлалаа.
Мэдээж энэ судалгааны ажил маань ямар ч амжилт гаргаагүй хэхэ. Сургуулийн эрдэм шинэжилгээний хуралд хоцорсон учраас оролцож чадалгүй зөвхөн presentation л тавьсан. Сая Голомт банкны эрдэм шинэжилээний хуралд оролцохоор материалаа явуулсан ч 1-н даваанд нь бүдэрчээ хөөрхий. 

Голомт банкных аль дээр заргалдсан байсан ч орох хүсэлгүй байснаа гэнэт 4, 5 хоног дутуу байхад ормоор санагдаад. Тэгээд л нойр хоолгүй суусан даа. Сургууль дээр оо сойзтойгоо 3 хонож эн тэр. Пүүжээ сүүлд хоолтой, хар кофетой, мөнгөтэй ирдэг бас л ... хаха.

Судалгааны явцад python хэл дээр бас л овоо юм хийж сурлаа. Их олон янзын програм хөгжүүлсэн ч ажилладаг нь ганцхан байсан тул тэрийгээ л ашигласан. Миний хийж байгаа ажилтай холбогдох монгол хэл дээрх материалууд надад олдоогүй учраас англи хэл дээрх материалуудыг уншиж судалахаас өөр сонголтгүй болсон. Заримыг нь буруу зөрүү ойлгоод бантанг нь их хутгасан. Дискрет математикийн хичээлийг англи хэл дээрх сурах бичгээс үзэж байсан болхоор дискретийн багшаас холбогдох зарим ойлгомжгүй зүйлүүдээ сайн лавласан. Бие даалтын цаг дээр багш ихэнхдээ ганцаараа л сууж байдаг юм дөө. Асуухад их амар. Сүүлийн өдөр 18 цагаас өмнө өгөх ёстой гээд бичсээр байгаад, удирдаж байсан Хүдэр багшдаа ч шалгуулж амжилгүй аваачаад өгчихсөн. Ер нь бол манай салбарын эрдэм шинэжилгээний өгүүлэл ихдээ л 8,9 хуудас маш товч тодорхой байх ёстой байдаг юм байна лээ. Би ч 17 хуудас бичсэн л дээ хаха. Яагаад вэ гэвэл Голомт банкных доод тал нь 20 хуудас дээд тал нь 50 гэсэн байсан. Хуудасны тоонд нь хүргэх гээд элдэв бусын юм хамж бичсээр байгаад 17 болгосон нь тэр. 
Ингээд судалгааныхаа ажлын зарим оршил хэсгээс нь хуваалцая. (Судагааны ажлаа өгсөнийхөө дараа алдаа эн тэрийг нь засаагүй)



Хураангуй:
Интернет дэх мэдээллийн веб сайтууд болон олон нийтийн сүлжээнд хүмүүс нээлттэй харилцаж, үзэл бодлоо илэрхийлэхдээ сэтгэгдлийг түгээмэл ашигладаг. Сэтгэгдлүүд утга агуулгын хувьд янз бүр байж болно. Тухайн мэдээлэл, сэдэв хүмүүст хүрэхийн хэрээр сэтгэгдлийн тоо ихсэдэг. Иймд их хэмжээний сэтгэгдэлтэй мэдээллийн бүх сэтгэгдлийг уншиж уншигчдын хандлагыг тодорхойлоно гэдэг хүнд хүчир ажил. Харин сэтгэгдэлүүдийг тодорхой ангилалын хүрээнд программын тусламжтайгаар ялгаж чадвал дээрхи ажлийг хөнгөвчлөхөөс гадна сэтгэгдлүүдээс хамааралтай байж болох өгөгдлийн олонлогийг гарган авах боломжтой. Энэ эрдэм шинжилгээний өгүүллээр сэтгэгдлүүдийг ангилах алгоритмын шийдэл, программыг хэрхэн хөгжүүлж болох тухай өгүүлэх болно.

Түлхүүр үг: хиймэл оюун ухаан, машин суралцах алгоритм, компьютерийн ухаан, мэдээллийг ангилах, магадлал, статистик, их өгөгдөл

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

1. Сэтгэгдэл
Интернет орчинд форумын сэдэв, олон нийтийн сүлжээн дэх нийтлэл, мэдээллийн веб сайтууд дээрхи нийтлэл текст байдлаар хэрэглэгчид сэтгэгдэлээ хуваалцдаг. [...]

2. Алгоритм
Их хэмжээний өгөгдөл боловсруулах, ангилах програм хангамж хөгжүүлэхэд алгоритмын шийдэл маш чухал нөлөөтэй. Текст баримт, бичиг ангилахад ашиглагддаг “Нуугдмал Марковийн загвар”, “Неюрал сүлжээ”, “Гэнэн Байес”, “Хамгийн ойр орших к хөрш”, “Шийдвэрийн мод” гэх мэт олон алгоритмууд байдаг. Мөн эдгээр алгоритмууд нь бүгд машин суралцах төрөлд хамаарагдана. Машин суралцах гэдэг нь компьютерийн ухааны хиймэл оюуны ойлголт бөгөөд машинийг тухайн нөхцөлд тодорхой програмчлахгүйгээр суралцах чадвар эзэмшүүлэх тухай судалдаг ухагдахуун юм. [...]

Компьютерийн ухаан / Копьютер график / Өгүүлэл (хураангуй, богино хувилбар)

График тооцоолох байгууламж (Graphic processing unit / GPU), мөн визуал тооцоолох байгууламж(Visual processing unit / VPU) ч гэж нэрлэдэг. GPU нь дүрсийн буферт дүрсийг санах ойгоос бүтээж, шуурхай зохион байгуулан илгээх үүрэгтэй тооцоолох байгууламж юм. GPU нь энгийн CPU -г бодвол өндөр хурдтайгаар параллел тооцоолол хийх бүтэцтэй байдаг. Энэ нь нэг бүхэл тооцоллыг олон жижиг хэсэгт хувааж болох алгоритмуудыг ажиллуулахад илүү үр дүнтэй. Гэвч энэ нь тооцоололын хурдаар СPU -с хурдан гэсэн үг биш юм. Жишээ татвал : Бүлэг шоргоолж нийлээд том ачааг зөөхөд бэрх, том ачааг том цох хорхой ядах юмгүй зөөж чадна. Бүлэг шоргоолжинд өөрсдийн дийлэх жижиг ачаануудыг тус тусдаа өргөх нь ашигтай, харин цох хорхой жижиг ачаануудыг олон дахин зөөх нь ашиггүй. График дүрс тооцоолох үед өндөр давтамжтайгаар дэлгэцэнд гарах дүрсүүдийг цаг алдалгүй бэлэн болгох хэрэгтэй байдаг тул тооцооллыг олон жижиг хэсэгт хуваан гүйцэтгэдэг.

    CPU GPU хоёрыг харьцуулсан харьцуулалтыг авч үзье. Харьцуулалтыг хийхдээ гурван хэмжээст орчинг рендер хийжээ. CPU нь 3.4 GHz бүхий 8 цөмтэй Intel Xeon тооцоолуур. GPU нь 2688 CUDA цөмтэй өндөр хүчин чадал бүхий nvidia тооцоолуур. Рендер хийх үед GPU -н рендерлэж буй зураг эхэндээ авиа(noise) их байсан ба хугацаа өнгөрөх хэрээр авиа нь буурч тогтворжиж байсан. Авиа ихтэй зураг нь хурц хурц өнгөний шилжилтүүдтэй, “барзгар” мэт харагддаг. Авиа ихтэй байх тусам зурагны чанар мууддаг. Харьцуулалт дууссаны дараа CPU GPU хоёрын харьцуулсан зургуудыг шалгахад зургийн чанар(IQ) нь хоёул адил 11.35 гарсан байна. Гэвч CPU нийт 19 минут 11 секундэд бүрэн рендер хийж дууссан бол GPU 3 минут 4 секундэд зурагаа дуусгасан. Дээрхи харьцуулалтаас GPU нь өөрийн үндсэн үүргээ зохих ёсоор биелүүлсэнийг харж болно.
  
    Дээрхи жишээн дээр GPU 2688 CUDA цөмтэй гэж дурьдсан байна. CUDA гэдэг нь nvidia корпрациас гаргасан параллел тооцооллын платформ юм. Энэ нь C, C++, fortrain гэх програмчлалын хэлнүүдийг шууд GPU рүү хандах боломжийг олгодог. Ингэснээрээ техник хангамжтайгаа шууд харьцаж визуал-параллел програмчлал хийхэд давуу талыг олгож байгаа юм. Мөн үүнийг өөрөөр CPU -тэйгээ GPU -ээ хослуулан кластер(cluster) болгон ашиглаж болох юм. Гэхдээ кластер болгох ашиглах гэж байгаа бол зөвхөн GPU дээр ажиллуулах тооцоололоо визуал-тооцололтой адил хэмжээнд буюу маш олон жижиг хэсэгт хувааж параллелаар ажиллуулах алгоритм ашиглах нь GPU-г ашигтай байлгаж чадна.

    Орчин үеийн GPU нь Simultaneous multithreading (SMT) буюу Hyper-Threading гэх нэршилээр нь хүмүүс сайн мэддэг аргачлалыг түгээмэл ашиглах болсон. Энэ нь superscalar CPU болон техник хангамжийн давхар тооцолох боломжийг нэгтгэж бүхэлд нь үр дүнтэйгээр сайжруулсан арга юм. SMT нь бие даасан thread-үүдийг ачааллахдаа процессорын архитехтурын өгч чадах нөөцийн хэмжээг хамгийн ашигтай байдлаар ашигладаг.
  
    GPU оролт нь олон тооны жагсаалт бүхий гёометрын дүрсүүд байдаг. Ерөнхийдөө 3D ертөнцийн координатад байрших гурвалжнууд юм. Олон шат дамжлагийг дамжсаны эцэст дүрс shade, mapping хийгдэж дэлгэцэнд гардаг.
1. Оройн цэгийн үйлдэл : Энэ нь оройн цэгүүдийг хооронд нь холбож дүрсийн үндсэн араг ясыг бүтээж, дэлгэцэнд тодорхой зай эзлэх үйл явц юм. Дүрс бүр хоорондоо оройн цэгүүдээрээ холбогдох ёстой ба нэгэн зэрэг мянга мянган цэгүүд хоорондоо холбогдох учир энэ бүгд зэрэг праллел байдлаар хийгдэнэ.
2. Анхдагч нэгтгэл : Холбогдсон оройн цэгүүдийг дүрс болгон нэгтгэх үйл явц.
3. Растержуулалт : Пикселийн хэмжээнд нэг дүрс нөгөөгөө хааж байрлах зэргийг тооцоолж. Дүрсүүдийг өнгөөр ялгаж өгдөг.
4. Задлах үйлдэл : Өнгөний мэдээллийг ашиглан боломжит дүрсүүдүүдэд санах ойгоос текстуруудыг авчирч дүрсийн гадаргуутай хамт нэгтгэдэг. Энэ үйлдэл мөн праллел байна.
5. Хослуулалт : Бүх үйлдүүдийг нэгтгэж эцсийн дүрсийг үүсгэн пиксел бүр дээр тохирох өнгийг онооно.

    Одоогийн байдлаар хамгийн хүчтэй GPU бүхий комьютеруудыг анимейшн болон кино студиуд ашиглаж байна. Бидний сайн мэдэх DreamWorks студи Rise of the Guardians киног хийхдээ 32 GB RAM, 160 GB SSD boot drive, 500 GB өгөгдөл хадгалах drive болон nvidia Quardo 5000 GPU(Энэ GPU нь 352 цөмтэй) гэсэн тоноглол бүхий комьютер ашиглаж байсан. Харин аниматоруудын хувьд 92GB RAM тай компьютерууд ашиглаж байсан. Ойролцоогоор тэдний гаргасан нэг анимейшнд 270 тэрбум пиксел агуулагдаж байдаг байна. Киноны  файлууд нь 250 TB хэмжээ эзэлнэ.

Ашигласан материал / Эх сурвалжууд :

• https://en.wikipedia.org/wiki/Graphics_processing_unit 
• https://en.wikipedia.org/wiki/Parallel_computing 
• https://en.wikibooks.org/wiki/Microprocessor_Design/GPU 
• http://blog.boxxtech.com/2014/10/02/gpu-rendering-vs-cpu-rendering-a-method-to-compare-render-times-with-empirical-benchmarks/ 
• http://www.nvidia.com/object/cuda_home_new.html 
• http://www.techradar.com/news/world-of-tech/inside-dreamworks-how-animated-movies-are-rendered-1127122

Компьютерийн ухаан / Копьютер график / Өгүүлэл (хураангуй, богино хувилбар)

Тоглоомын хөдөлгүүр гэдэг нь видер тоглоом хөгжүүлэхэд зориулсан програм хангамжийн фреймворк юм. Тоглоомын хөдөлгүүрийг ашигласнаар тоглоом бүтээх үйл явцийг хурдан, хялбар, уян хатан болгож өгдөг. Ихэнхдээ видео тоглоомын зах зээлд ноёрхогч стиуд, компаниуд өөрсдийн гэсэн тоглоомын хөдөлгүүрүүдийг хөгжүүлсэн байдаг. Эсвэл тусгайлан хөдөлгүүрүүдийг худалдаж авсан байна. Том хэмжээний видео тоглоом хөгжүүлнэ гэдэг нь програм хангамжийн үйлдвэрлэлтэй харьцуулвал харьцангүй нүсэр бүрэлдхүүнтэй, урт хугацааны төсөл байдаг. Тоглоом хөгжүүлэлтийг кино бүтээхтэй харьцуулж болох юм.

Дэлхийн зах зээлд тоглоомууд өрсөлдөхийн хэрээр хөдөлгүүрүүд ч гэсэн хоорондоо өрсөлдөж байдаг. Тоглоомын механик, моделуудын хөдөлгөөн, гэрэл, сүүдэр, нарийвчлал, тоглолт зэрэг бүх зүйл нь тухайн тоглоомын хөгжүүлэгдсэн хөдөлгүүрээс хамаарна. Хүчтэй хөдөлгүүртэй бол тоглоомыг хөгжүүлэх потенциал нь тэр хэрээр нэмэгдэнэ гэсэн үг юм. Өнөө үеийн хамгийн хүчтэйд тооцогдож буй тоглоомын хөдөлгүүрүүдэд Snowdrop, Unreal, Frostbite, CryEngine, AnvilNext, Disrupt, Unity зэргийг дурьдаж болох юм. Дээр дурьдагдсан хөдөлгүүрүүдээс олон нийтэд зориулсан үнэгүй хувилбартай хөдөлгүүр нь Unreal болон Unity хоёр юм.

Тоглоомын хөдөлгүүр дээр тухайн хөдөлгүүрт мэргэшсэн тоглоом хөгжүүлэгч нар ажиллана. Хөдөлгүүрийн удирдах самбараас тоглоом руу шууд бодит цагийн (real-time) байдлаар хандах боломжтой мөн тоглоомон дахь обьектууд руу гёометр дүрсийн координатаар хандах, ар талд хийгдэх логик тооцоололуудыг кодчилох зэрэг тоглоомонд агуулагдах бүх зүйлс тоглоом хөгжүүлэгчийн гараар хөдөлгүүрт хийгдэнэ. Тоглоомын хөдөлгүүр нь дотроо хэд хэдэн бүрэлдхүүн хэсэгт хуваагдана. Үүнд :

• Үндсэн тоглоомын програм :

• Алгоритмоор хөгжүүлж, баяжуулсан үндсэн тоглоомын логик. Энэ нь рендерлэх болон дуу, хөгжим эсвэл оролт гаралтаас тусдаа ойлголт юм.

• Рендерлэх хөдөлгүүр

• Тоглоомын хөдөлгүүр өөрийн гэсэн рендерлэх арга барил, модуль байдаггүй. Харин GPU эсвэл CPU дээр тулгуурласан өөр програм хангамжийн API(Application programming interface) ашиглан рендер хийдэг. Жишээ нь Direct3D, OpenGL гэх мэт.

• DirectX, Simple DirectMedia Layer, OpenGL гэх доод түвшиний сангууд хамгийн өргөн ашиглагддаг.

• Тоглоомын хөдөлгүүрүүд нь C++,C эсвэл Java гэх мэт ямар програмчлалын хэлэн дээр хөгжүүлэгдсэнээс хамааран ялгаатай түвшинд хандалт хийдэг

• Аудио хөдөлгүүр

• Энэ нь ямар ч дуутай ажиллаж чадах алгоритмын ашиглах боломжтой байх ба CPU дээр тооцооолол хийдэг. Мөн OpenAL, SDL audio, Xaudio 2, Web Audio гэх програмуудын API дамжин ажилладаг.

• Физик хөдөлгүүр

• Тоглоомыг илүү бодит мэт болгохын тулд физикийн хуулиудыг ашиглаж тоглоомонд хэрэгжүүлждэг

• Хиймэл оюун ухаан

• Хиймэл оюун ухаан нь ихэнхдээ програм хангамжийн инженерүүдийн зохиосон тусгай модулиуд бүхий програм байдаг

Ашигласан материал / Эх сурвалжууд :

• https://en.wikipedia.org/wiki/Game_engine

• http://venturebeat.com/2014/08/20/the-top-10-engines-that-can-help-you-make-your-game/

• https://en.wikipedia.org/wiki/Video_game_development

МХТС -ын Програмчлалын Олимпиадын баг (Цахиурт клуб) -ийн гишүүн Т.Билгүүний бичсэн доорхи нийтлэл ихэд таалагдсан тул блогтоо орууллаа.

"Өрсөлдөөнт програмчлалд, Яагаад одоо болтол Мастер/Улаан кодор/ төрөхгүй байна вэ ?

УИХ гишүүн Дэмбэрэлийн чуулганы хуралын өмнө өгсөн ярилцлага ...

PS: Энэхүү эсээг бичихэд хянаж, засварласан Анар ахад баярлалаа