Saturngod » Knowledgebase http://www.saturngod.net What's on my mind Fri, 10 Feb 2012 16:00:31 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Bootstrap http://www.saturngod.net/knowledgebase/bootstrap?utm_source=rss&utm_medium=rss&utm_campaign=bootstrap http://www.saturngod.net/knowledgebase/bootstrap#comments Fri, 10 Feb 2012 15:59:41 +0000 saturngod http://www.saturngod.net/?p=4994 Continue reading →]]>

Twitter bootstrap ကို သိတာတော့ တော်တော်လေးကို ကြာလှပါပြီ။ Twitter မှာ bootstrap ကို တစ်ယောက်က tweet လိုက်ကတည်းက သဘောကျခဲ့တာ အမှန်ပဲ။ MMWebFonts ကိုတောင် Bootstrap က 1.1 ပဲ ရှိပါသေးတယ်။ အခု အချိန်မှာတော့ version 2 တောင် ရောက်နေပါပြီ။

Twitter bootstrap ဆိုတာကတော့ သူကတော့ ဒီလို ဆိုထားပါတယ်။

Simple and flexible HTML, CSS, and Javascript for popular user interface components and interactions.

user interface နဲ့ interactions တွေအတွက် လူသုံးများတဲ့ HTML , CSS , Javascript တွေ စုစည်းထားတာလို့ ဆိုလို့ရပါလိမ့်မယ်။ ကျွန်တော် ကတော့ နောက်ပိုင်း UI အပိုင်း စဉ်းစားဖို့ အချိန်မရှိတော့ဘူးဆိုရင် bootsrap ကို ပဲ လွယ်လင့် တကူ အသုံးပြုလိုက်ပါတယ်။

အရင်တုန်းကတော့ 960.gs ကို အသုံးပြုပါတယ်။ Bootstrap ပေါ်လာပြီးတဲ့ နောက်ပိုင်းမှာတော့ အဆင်ပြေရင် bootstrap ကိုပဲ လွယ်လင့် တကူသုံးလိုက်တော့တယ်။ Responsive design ကို အရန်သင့် support လုပ်ပေးထားတော့ iphone , iPad design ကို သီးသန့် ပြန်ရေးပေးနေဖို့ မလိုတော့တာကြောင့်လည်း ပါပါတယ်။

bootstrap မှာ CSS grid ပါ သလို အခြား CSS တွေကလည်း တော်တော် အသုံးဝင်လှပါတယ်။ Table , Form တွေ အပြင် button တွေက အစ အရန်သင့်ရှိထားတဲ့အတွက် အသုံးဝင် လှပါတယ်။ ဒါ့အပြင် glyph icons တွေလည်း အရန်သင့်ပါဝင်ပါတယ်။

version 2.0 မှာ javscript တွေ ထည့်သွင်းပေးထားတယ်။ Responsive design ကို အသုံးပြုမယ်ဆိုရင် bootstrap.js ကို အသုံးပြုဖို့လိုပါတယ်။ ဒါမှသာ navigation ရဲ့ menu တွေ ပါလာမှာပါ။

Bootstrap ကတော့ ကျွန်တော့် အတွက် အရန်သင့် အသုံးပြုတာ ဖြစ်သလို coding တွေကို လေ့လာရာမှာလည်း အများကြီး အသုံးဝင်ပါတယ်။

Github မှာ code ကို fork လုပ်လိုက် merge လုပ်လိုက်နဲ့ တော်တော်လေးကို Impact ကြီးပါတယ်။

နောက်ထပ် သဘောကျတာကတော့ LESS နဲ့ ပါ အသုံးပြုလို့ရတာပါပဲ။ ပြောရင်တော့ အများကြီးပါပဲဗျာ။ Web Development စိတ်ဝင်စားတဲ့သူတွေ အနေနဲ့ bootstrap ကို အနည်းအကျဉ်းလောက်တော့ သိထားသင့်ပါတယ်။

]]> http://www.saturngod.net/knowledgebase/bootstrap/feed 0 New MMEpub http://www.saturngod.net/knowledgebase/new-mmepub?utm_source=rss&utm_medium=rss&utm_campaign=new-mmepub http://www.saturngod.net/knowledgebase/new-mmepub#comments Tue, 07 Feb 2012 16:26:23 +0000 saturngod http://www.saturngod.net/?p=4992 Continue reading →]]>

MMEpub ကို ဒီနေ့ ထပ်ပြင်လိုက်ပါတယ်။

အခု version အသစ်မှာ

  • Cover တွေထည့်လို့ရလာပါတယ်။
  • ကြိုက်တဲ့ font သုံးလို့ရလာပါတယ်။

ဝင်းအင်းဝ font ကို သုံးမယ့်သူတွေ အနေနဲ့ သတိထားစေချင်တာက mmepub နဲ့ ပြောင်းလိုက်ရင် လက်ရှိ english စာတွေ မြင်ရတော့မှာ မဟုတ်ပါဘူး။ အဲဒီ ပြဿနာရှိပါတယ်။

Custom font ကို support လိုက်တာကြောင့် unicode နဲ့ ရိုက်ထားတဲ့ စာတွေကိုတော့ လွယ်လွယ်ပြောင်းလို့ရပါပြီ။

သုံးပုံသုံးနည်းကတော့

Custom Font

$python convert.py [font family] [font file]

[font family] : ပြောင်းချင်တဲ့ font family

[font file] : font family ရဲ့ font file

font fmaily သို့မဟုတ် font file နှစ်ခု လုံး သို့မဟုတ် ၁ ခု တည်းသာ ပါရှိခဲ့ရင် zawgyi-one ကို သာ အသုံးပြုသွားမှာပါ။ font-family ကော font file ကိုပဲ convert.py မှာ ထည့်ပေးမှ ပေးထားတဲ့ font-family ကို အလုပ်လုပ်မှာပါ။

ဥပမာ ။

$python convert.py Yunghkio Yunghkio.ttf

Yunghkio.ttf ဆိုတဲ့ file ကို data folder အောက်မှာ သွားထည့်ထားပေးရပါမယ်။

Cover

.png file ကို .epub file နဲ့ နာမည် အတူတူ ပေးထားလိုက်ပါ။

ဥပမာ။။ sample.epub နဲ့ sample.png ပေါ့။ sample.epub cover အတွက် sample.png ကို ယူသုံးသွားပါမယ်။

cover အတွက် recommend လုပ်တဲ့ အရွယ်အစားကတော့ 420 × 599 ပါ။

.epub file တွေ အားလုံးနဲ့ cover အတွက် .png file အားလုံးကို convert.py အောက်မှာထားပြီးတော့ terminal (command) ကတော့

$python convert.py

ဆိုပြီး ခေါ်ပြီး ပြောင်းလို့ရပါပြီ။

]]> http://www.saturngod.net/knowledgebase/new-mmepub/feed 5 MMWebFonts http://www.saturngod.net/knowledgebase/mmwebfonts?utm_source=rss&utm_medium=rss&utm_campaign=mmwebfonts http://www.saturngod.net/knowledgebase/mmwebfonts#comments Sat, 04 Feb 2012 14:39:06 +0000 saturngod http://www.saturngod.net/?p=4990 Continue reading →]]>

MyWebFont က bandwidth ပြည့်လို့ ၁ ရက်လောက် သုံးမရတာ တွေ အခု တလော ခဏခဏ ဖြစ်နေပါတယ်။ ဒါနဲ့ ကျွန်တော့် ဆီ mail ပို့ပြီး သူတို့ရဲ့ server မှာ host တင်ပြီး run မယ်လို့ စာတွေ ပို့ကြတယ်။ သို့သော်လည်းပဲ MyWebFont က Google App Engine အတွက် ရေးထားတာဖြစ်ပြီးတော့ လက်ရှိ Linux server တွေမှာ run လို့မရပါဘူး။

MMWebFonts ဆိုပြီးတော့ mywebfont code အတိုင်းကို PHP နဲ့ ပြန်ပြင်ရေးထားပါတယ်။ hosting ပေါ်မှာ မ run ချင်သူတွေ အနေနဲ့ကတော့ http://mmwebfonts.comquas.com/ ကနေ MyWebFont သုံးသလိုမျိုး external style sheet အနေနဲ့ သုံးလို့ရပါတယ်။ ကိုယ့် hosting မှာ တင်သုံးချင်တယ်ဆိုသူတွေကတော့ source code ကို github မှာ ရယူနိုင်ပါတယ်။

]]> http://www.saturngod.net/knowledgebase/mmwebfonts/feed 0 ကျောင်းတွင်း ဒီမိုကရေစီ http://www.saturngod.net/knowledgebase/%e1%80%80%e1%80%bb%e1%80%b1%e1%80%ac%e1%80%84%e1%80%ba%e1%80%b8%e1%80%90%e1%80%bd%e1%80%84%e1%80%ba%e1%80%b8-%e1%80%92%e1%80%ae%e1%80%99%e1%80%ad%e1%80%af%e1%80%80%e1%80%9b%e1%80%b1%e1%80%85%e1%80%ae?utm_source=rss&utm_medium=rss&utm_campaign=%25e1%2580%2580%25e1%2580%25bb%25e1%2580%25b1%25e1%2580%25ac%25e1%2580%2584%25e1%2580%25ba%25e1%2580%25b8%25e1%2580%2590%25e1%2580%25bd%25e1%2580%2584%25e1%2580%25ba%25e1%2580%25b8-%25e1%2580%2592%25e1%2580%25ae%25e1%2580%2599%25e1%2580%25ad%25e1%2580%25af%25e1%2580%2580%25e1%2580%259b%25e1%2580%25b1%25e1%2580%2585%25e1%2580%25ae http://www.saturngod.net/knowledgebase/%e1%80%80%e1%80%bb%e1%80%b1%e1%80%ac%e1%80%84%e1%80%ba%e1%80%b8%e1%80%90%e1%80%bd%e1%80%84%e1%80%ba%e1%80%b8-%e1%80%92%e1%80%ae%e1%80%99%e1%80%ad%e1%80%af%e1%80%80%e1%80%9b%e1%80%b1%e1%80%85%e1%80%ae#comments Thu, 02 Feb 2012 13:14:20 +0000 saturngod http://www.saturngod.net/?p=4987 Continue reading →]]>

Facebook မှာ ခင်မြတ် က ဦးသန့်ရဲ့ ကျောင်းတွင်း ဒီမိုကရေစီ စာအုပ်ကို ပြန်ရိုက်ပြီး တင်ထားပေးပါတယ်။ ပြီးတော့ PDF နဲ့ share ထားတယ်။ message ပို့ပြီးတော့ epub file လုပ်ဖို့အတွက် တောင်းတော့ မူရင်း doc file ကိုပို့ပေးပါတယ်။ ဒါနဲ့ ကိုယ့်ဘာသာကိုယ် online က နေ ပုံတွေ ပြန်ရှာပြီးတော့ cover လုပ်လိုက်တယ်။ epub ပြောင်း ။ mmepub နဲ့ font epub ထည့်။ cover ထည့် လိုက်ပါတယ်။

cover

epub version ကိုတော့ ဒီမှာ download ချနိုင်ပါတယ်။

PDF ကိုတော့ ဒီမှာ ဖတ်ပြီး download original ကို နှိပ်ပြီးတော့ download လည်း ချလို့ရပါတယ်။

]]> http://www.saturngod.net/knowledgebase/%e1%80%80%e1%80%bb%e1%80%b1%e1%80%ac%e1%80%84%e1%80%ba%e1%80%b8%e1%80%90%e1%80%bd%e1%80%84%e1%80%ba%e1%80%b8-%e1%80%92%e1%80%ae%e1%80%99%e1%80%ad%e1%80%af%e1%80%80%e1%80%9b%e1%80%b1%e1%80%85%e1%80%ae/feed 4 Working with git http://www.saturngod.net/knowledgebase/working-with-git?utm_source=rss&utm_medium=rss&utm_campaign=working-with-git http://www.saturngod.net/knowledgebase/working-with-git#comments Fri, 06 Jan 2012 15:04:32 +0000 saturngod http://www.saturngod.net/?p=4957 Continue reading →]]>

Git ကို အရင်ရုံး point-star မှာ စသုံးဖူးတာပါ။ git ဆိုတာကို အရင်တုန်းကတော့ opensource တွေကို download ဆွဲချပြီး သုံးဖို့လောက်ပဲ သုံးဖြစ်တယ်။ point-star မှာ github သုံးရမယ်ဆိုတာနဲ့ github ကို လေ့လာဖြစ်တာပဲ။ github နဲ့ git အစတုန်းက လုံးဝ ကို မကွဲတာ။ github သုံးရင်းနဲ့ git နဲ့ github မတူဘူးဆိုတာ သိလာတာ။ git သုံးတတ်ပြီးနောက်ပိုင်းမှာ github မှာ opensource project တွေ တင်ဖြစ်တယ်။ သို့ပေမယ့် တစ်ယောက်တည်းပဲ ဖြစ်တဲ့အတွက် git အကြောင်းကို ကောင်းကောင်း မသိခဲ့ဘူး။ အရင်ရုံးတုန်းကလည်း တစ်ယောက်တည်းလိုလို ဖြစ်နေတဲ့အတွက် မထူးခြားလှဘူး။ backup သာသာ ရှိပါတယ်။

ဒီရုံးရောက်တော့ repo သုံးမယ် ဆိုတော့ ကျွန်တော်က bitbucket ကို recommend လုပ်ခဲ့တယ်။ သို့ပေမယ့် bitbucket က hg ပဲ support လုပ်တယ်။ ဒါကြောင့် git ထက်စာရင် hg ကို အသုံးပြုဖြစ်ခဲ့တယ်။ အခုနောက်ပိုင်း bitbucket က git support လုပ်တော့ ကျွန်တော်တို့တွေ git ကို ပြောင်းသုံးခဲ့တယ်။ hg နဲ့ git က အတူတူပဲ လို့ ဆိုလို့ရပါတယ်။ သို့ပေမယ့် ကျွန်တော်က git ကို ပိုကြိုက်တယ်။ git က data တွေကို compress လုပ်ပြီး သိမ်းထားတဲ့အတွက်ကြောင့် နေရာ သိပ်မယူဘူးလို့ ဆိုရမလိုပဲ။ Git ကို စသုံးတဲ့အချိန်မှာ ကျွန်တော်တို့ ရုံးက ၂ ယောက်တည်း မဟုတ်တော့တာအတွက်ကြောင့် hg ထက်စာရင် git အကြောင်းကို ပိုသိပါတယ်။

ရုံးမှာ နေ့စဉ် အိန္ဒိယက တင်ထားတဲ့ commit တွေကို pull လုပ်ပြီးတော့ ဘာတွေ ပြင်လိုက်လဲ။ မနေ့က သူတို့တွေ ဘာတွေ ပြီးသွားလဲဆိုတာကို ပြန်စစ်ပါတယ်။ ပြီးရင် code တွေ ကို ပြန်ပြင် push လုပ်။ တစ်ခါတစ်လေ မှာ နှစ်ယောက်လုံးရေးထားတာတွေကို merge လုပ်ရတဲ့ အခါတွေလည်းရှိတယ်။

Git ကို သုံးတဲ့ အခါမှာ Branch , Tag စတာတွေက အရေးပါပါတယ်။ Git ကို ဘယ်လို သုံးသင့်သလဲဆိုတာကို A successful Git branching model ကို ဖတ်ကြည့်သင့်ပါတယ်။

git branching

 ကျွန်တော်တို့ git branch တွေကို အပေါ်က ပုံ အတိုင်း မဟုတ်ပေမယ့် အနီးစပ်ဆုံး အသုံးပြုတယ်လို့ဆိုရမယ်။ master branch မှာ stable ကို ထားပြီး development ကို branch သီးသန့် ခွဲထုတ်ထားပါတယ်။ UI Design အသစ်ပြောင်းတဲ့အခါမှာ branch အသစ် ခွဲထုတ်ပြီးတော့ ရေးပါတယ်။ ပြီးမှ အရင် branch ကို ပြန်ပြီး merge လုပ်ပါတယ်။ UI Develop အသစ်လုပ်လိုက်တဲ့အတွက်ကြောင့် code အဟောင်းတွေ သုံးမရတော့ဘူးဆိုတာ မဖြစ်တော့ဘူးပေါ့။

Project ကို Release လုပ်ပြီးတဲ့ အခါမှာတော့ Tag ထားခဲ့ပါတယ်။ Git ကို အသုံးပြုတဲ့အခါမှာ အဓိက ကောင်းတဲ့ အချက်က developer တွေ ၂ ယောက် သို့မဟုတ် ၂ ယောက်ထက် မက project မှာ ပါဝင်လာပြီဆိုရင် တော်တော်လေးကို အသုံးဝင်လှပါတယ်။ ကျွန်တော်ပြီးခဲ့ project က ရေးခဲ့တဲ့ git branch က အောက်က ပုံမှာ တစ်ပိုင်းလေး ပြထားပါတယ်။

git branch

Git ကို ကျွန်တော်တို့တွေ အရေးကြီးတာ တစ်ခုခု ပြင်လိုက်တိုင်း push လုပ်ပါတယ်။ ဘာလို့လည်း ဆိုတော့ ဘာတွေကို ပြောင်းလိုက်လဲဆိုတာကို သိနိုင်အောင်ပါ။ နောက်ပြီး git ကို commit လုပ်တိုင်း အဓိပ္ပာယ်ရှိတဲ့ comment တွေနဲ့ပဲ commit လုပ်ပါတယ်။ ဒါမှ အခြား developer က သူဘာတွေ ပြင်လိုက်တာလဲဆိုတာကို စာဖတ်လိုက်တာနဲ့ သိနိုင်မှာပါ။ Git ကို သုံးတဲ့ ကောင်းတဲ့ အချက်တစ်ခုကတော့ တစ်ခုခု မှားသွားရင် ပြန်ပြီး အရင် commit ကို Rebase ပြန်လုပ်လို့ရတာပါပဲ။ ဒါ့အပြင် ကျွန်တော်တို့တွေ commit ၂ ခု ၃ ခုလောက်ကို ပြောင်းပြီးတော့ commit တစ်ခု အနေနဲ့ ပြန်ပြောင်းလို့ရသလို commit ၁ ကိုလည်း commit ၂ ခုဖြစ်ပါတယ်ဆိုပြီး ခွဲထုတ်နိုင်ပါတယ်။ commit ကို ခွဲထုတ်တာနဲ့ merge လုပ်တာကိုတော့ မစမ်းဘူးသေးပါဘူး။

Git ကို သုံးတဲ့အခါမှာ နောက်ထပ် သဘောကျတဲ့ အပိုင်းကတော့ submodule ပါပဲ။ Submodule ဆိုတာကိုတော့ အခြား git repo ကို ဒီ git repo မှာ ယူသုံးထားတာပါပဲ။ သူက ယူသုံးထားတဲ့ git repo ကို push တွေလုပ်မနေနဲ့တော့ဘူး။

ဥပမာ။ ကျွန်တော် MKNetworkKit ကို ကျွန်တော့် project မှာ သုံးတယ်ဆိုရင်

git submodule add git://github.com/MugunthKumar/MKNetworkKit.git OtherLibrary/MKNetworkKit

push လုပ်တဲ့ အခါမှာ​တော့ OtherLibrary/MKNetworkKit ကို push လုပ်မနေတော့ပါဘူး။ ကျွန်တော်တို့တွေ အခြား computer တစ်ခုကနေ clone လုပ်တာပဲ ဖြစ်ဖြစ် pull လုပ်တာပဲ ဖြစ်ဖြစ် submodule တွေကို ပြန်ပြီးတော့ pull လုပ်ပေးရပါတယ်။

git submodule update –init

ဆိုတာနဲ့ submodule တွေ အကုန် ဆွဲချပါတယ်။ တစ်ခါတစ်လေ MKNetworkKit က update လုပ်လိုက်တာဖြစ်ဖြစ် အခြား submodule က update လုပ်တာဖြစ်ဖြစ် git ကို update လုပ်ချင်တယ်ဆိုရင်

git submodule foreach git pull

ဆိုပြီး ခေါ်သုံးပါတယ်။ ဒါဆိုရင် submodule တွေ အားလုံးကို pull လုပ်ပြီး update လုပ်သွားမှာပါ။ ဒါဟာ အရမ်းကောင်းပါတယ်။ ကျွန်တော်တို့တွေ library တစ်ခု update လုပ်တိုင်း သွားပြီးတော့ zip file ကို ဆွဲချ။ replace လုပ်။ စတာတွေ သက်သာသွားပါတယ်။

နောက်ဆုံး ပြောချင်တာကတော့

Git ဆိုတာက backup တစ်ခုတည်း အတွက်မဟုတ်ပါဘူး။

]]> http://www.saturngod.net/knowledgebase/working-with-git/feed 1 Making Rest API – Part 1 http://www.saturngod.net/knowledgebase/making-rest-api-part-1?utm_source=rss&utm_medium=rss&utm_campaign=making-rest-api-part-1 http://www.saturngod.net/knowledgebase/making-rest-api-part-1#comments Thu, 01 Dec 2011 15:25:23 +0000 saturngod http://www.saturngod.net/?p=4926 Continue reading →]]>

ကျွန်တော် PHP နဲ့ REST API အကြောင်းကို တစ်ခေါက်ရေးဖူးပါတယ်။ အဲဒီမှာ CodeIgniter ပြဿနာကို ရေးခဲ့ဖူးပါတယ်။ Slim Framework အကြောင်းကိုလည်း ပြောခဲ့ပါတယ်။ သို့ပေမယ့် Slim Framework ပြဿနာက ကျွန်တော်တို့ routing ပတ်လမ်းကြောင်းတွေ အများကြီး ရေးနေရမှာပဲ။ file တွေ အများကြီးကို ခေါ်ပြီးတော့ run ရမှာဖြစ်တဲ့အတွက်ကြောင့် သဘောမကျလှဘူး။

ဒါနဲ့ CodeIgniter routing နဲ့ Sinatrarb routing ပေါင်းပြီးတော့ Ava framework မှာ ထည့်သွင်းလိုက်ပါတယ်။ ကျွန်တော်တို့ Rest API တစ်ခုကို ရေးကြည့်ရအောင်။ Example အနေနဲ့ blog API တစ်ခု တည်ဆောက်ပါမယ်။ GET , POST , PUT , DELETE တွေကို ကျွန်တော်တို့ အသုံးပြုပါမယ်။

GET ကတော့ ရဖို့အတွက်ပါ။ POST ကတော့ add လုပ်တဲ့ ကိစ္စတွေမှာ သုံးပါမယ်။ PUT ကိုတော့ edit လုပ်ဖို့မှာ အသုံးပြုပါမယ်။ DELETE ကိုတော့ ဖျက်တဲ့ နေရာမှာ အသုံးပြုပါမယ်။

GET /posts

လက်ရှိ ရှိတဲ့ posts တွေ အားလုံးကို ပြပါမယ်။

POST /posts

post အသစ် တစ်ခုကို ဖြည့်ဖို့အတွက်ပါ။

POST အတွက် parameter ကတော့ title နဲ့ content ပါ။

GET /posts/:id

Post တစ်ခုတည်းအတွက်ပါ။

PUT /posts/:id

PUT ကို edit လုပ်ဖို့အတွက်။

PUT အတွက် parameter ကတော့ title နဲ့ content ပါ။

DELETE /posts/:id

POST ကို ဖျက်ဖို့အတွက်ပါ။

အခု ကျွန်တော် database အသစ်တစ်ခုမှာ အောက်ကလို table ကို အောက်ကလို ဆောက်လိုက်ပါတယ်။

အခု Ava framework ကို download ချပြီးတော့ Rest API တစ်ခု စဖန်တီးပါတော့မယ်။

]]> http://www.saturngod.net/knowledgebase/making-rest-api-part-1/feed 2 Infrastructure http://www.saturngod.net/knowledgebase/infrastructure?utm_source=rss&utm_medium=rss&utm_campaign=infrastructure http://www.saturngod.net/knowledgebase/infrastructure#comments Fri, 25 Nov 2011 18:35:54 +0000 saturngod http://www.saturngod.net/?p=4905 Continue reading →]]>

ဒီနေ့ ရုံးမှာ လက်ရှိလုပ်နေတဲ့ project တစ်ခုအတွက် server ပိုင်း infrastructure တွေကို လိုက်ဖတ်ဖြစ်တယ်။ အဓိက ဖတ်ဖြစ်တဲ့ infrastructure တွေက facebook, foursquare , instagran , digg စတဲ့ လူသုံးများတဲ့ website တွေပါပဲ။

Facebook

လက်ရှိ facebook ကို XHP နဲ့ ရေးပြီးတော့ Hip Hop PHP နဲ့ run ထားပါတယ်။ website ကိုတော့ javascript တွေပဲ သုံးထားတယ်။ C , C++ , Java တွေကို back end မှာ သုံးထားတယ်။ နောက်ပြီးတော့ boost ကိုလည်း သုံးထားပါတယ်။ နောက်ပြီးတော့ အချို့ internal tool တွေကိုတော့ python ကိုသုံးထားပါတယ်။ Chat ပိုင်းကိုတော့ Erlang နဲ့ ရေးထားပါတယ်။ backend service နဲ့ front end web server ကိုတော့ Apache Thrift ကို အသုံးပြုထားပါတယ်။1

Facebook က 690 billion page views each month ရှိပါတယ်။ လက်ရှိ Internet Traffic 9.5 percent က facebook ကို အသုံးပြုနေတာပါ။ 100 million photo upload နေ့စဉ် ရှိနေပြီးတော့ လစဉ် 30 billion pieces of content ရှိပါတယ်။ 1 million web sites and 550,000 applications က facebook connect ကို အသုံးပြုထားပါတယ်။ လက်ရှိ facebook data center ကိုတော့ Prineville, Oregon မှာ ထားရှိပါတယ်။2 North Carolina data center ကို တည်ဆောက်ဖို့အတွက် facebook က ပြင်ဆင်နေပါတယ်။3

လက်ရှိ data center မှာ အနည်းဆုံး 60,000 servers အသုံးပြုလျက်ရှိပါတယ်။ နောက်ပြီးတော့ MySQL , Memcached, Haystack for photo retrieval, Cassandra, Hadoop and Hive , Scribe for high-speed distributed logging4 , Apache HBase for Messaging5 တို့ကို အသုံးပြုထားပါတယ်။

Facebook ရဲ့ infrastructure အတိအကျကိုတော့ မသိရပေမယ့် server နဲ့ traffic ကို ကြည့်လိုက်တာနဲ့ အခုတော့ အဲလောက်ထိတော့ မလိုသေးပါဘူး။

Twitter

Twitter ကို စရေးခဲ့တုန်းက ROR နဲ့ mysql + memcache တို့ကို အသုံးပြုခဲ့ပါတယ်။ နောက်ပိုင်းမှာ Scala ကို ပြောင်းခဲ့တယ်6 ။ Database ကိုတော့ cassandra ကို ပြောင်းခဲ့ပါတယ်။ tweet တဲ့ နှုန်းက နေ့စဉ် 50 million ကနေ 140 million ရှိပါတယ်။ လက်ရှိ twitter က ကိုယ်ပိုင် data center ကို အသုံးပြုထားပါတယ်။ မှန်းခြေ server ပေါင်း 2,000 ကနေ 4,000 အတွင်း ရှိပါတယ်။7 ။

Twitter က server ခဏခဏ down တဲ့ ပြဿနာတွေ ကြုံခဲ့ရဖူးပါတယ်။ Twitter က ၃ ရက်လောက် down သွားခဲ့ဖူးတယ်8 ။ ဒါကြောင့် နောက်ပိုင်းမှာ ROR ကနေ scala ကို ပြောင်းခဲ့ပါတယ်။ နောက်ပြီး mysql+memcache ကနေ Cassandra ကို ပြောင်းခဲ့ပါတယ်။

Instagram

Instagram ကို ပထမဆုံး Django နဲ့ PostgreSQL နဲ့ စခဲ့ပါတယ်9 ။ ပထမဆုံး managed data center တစ်ခုကို အသုံးပြုထားခဲ့ပါတယ်။ နောက်ပိုင်းမှာတော့ Amazon EC 2 ကို ပြောင်းခဲ့တယ်။ 10 ။ Instagram ကို သဘောကျတဲ့ အချက်က popular ဖြစ်လာပေမယ့် ချက်ခြင်း server ကို upgrade လုပ်နိုင်တာပဲ။ iPhone app နဲ့ web app ကွာတဲ့ အချက်က iphone app က popular ဖြစ်လာလို့ server ကို upgrade လုပ်တာဖြစ်ဖြစ် API အသစ် ပြောင်းတာ ဖြစ်ဖြစ် သတိထားရပါတယ်။ App တစ်ခုကို apple approve လုပ်ဖို့ အမြန်ဆုံး ၂ ရက် အကြာဆုံး ၇ ရက် ရှိပါတယ်။ ဒါကြောင့် IP အသစ်ပြောင်းလိုက်တာနဲ့ လက်ရှိသုံးနေတာတွေ အကုန် down သွားနိုင်တယ်။ နောက်တချက်က server တစ်ခုကနေ တစ်ခု ရွေ့တဲ့ အခါမှာ data တွေ မပျောက်ပျက်သွားအောင် service ကို ခဏလေး down လိုက်ပြီး backup လုပ်။ ပြီးရင် server အသစ်ကို ရွှေ့ စတာတွေ လုပ်ရတယ်။ Instagram က အဲဒီ အဆင့်တွေကို လွယ်လွယ်ကူကူ ဖြတ်ကျော်နိုင်ခဲ့ပါတယ်။

Instagram က အခုနောက်ပိုင်းမှာ database ကို Redis ကို ပြောင်းလိုက်တယ်။11 ။ Instagram က server side code တွေကို Burbn ကနေ ယူခဲ့ပါတယ်။ Server side မှာတော့ လပေါင်းများစွာ ပေးခဲ့ရတယ်။ App ကိုတော့ ၈ ပတ် ကြာအောင် ရေးခဲ့ရပါတယ်။12 Instagram က release မလုပ်ခင်ကတည်းက infrastructure ကို ခိုင်ခံအောင် တည်ဆောက်ထားပုံ ပေါ်တယ်။

Flipboard က popular လည်း ဖြစ်တဲ့ အခါမှာ facebook , twitter service တွေ down သွားခဲ့တယ်။ Zite လည်း ထိုနည်းလည်းကောင်းပဲ။ release တကယ်လုပ်ပြီး ရက်အနည်းငယ်မှာ server down သွားခဲ့တယ်။ နောက်ထပ် version အသစ်မှ သာ တော်တော် လေးကို အဆင်ပြေသွားတာပါ။ သို့ပေမယ့် instagram က ပြဿနာ ကြီးကြီးမားမား တစ်ခုမှ မရှိခဲ့တာကတော့ လေးစားဖို့ ကောင်းတယ်။

Foursquare

Foursquare မှာတော့ လက်ရှိ အသုံးပြုထားတာတွေကတော့

  • 15 app servers
  • 4 PostgreSQL servers (being phased out)
  • 2 memcached servers (being phased ou)
  • 10 MongoDB servers
  • 1 frontend (nginx)
  • 1 search server (solr)

Amazone EC2 ကိုပဲ အသုံးပြုထားပါတယ်။ User image တွေကိုတော့ Amazon S3 မှာ သိမ်းထားပါတယ်13 ။

လက်ရှိ user 10 million ရှိပါတယ်။ တနေ့ကို billion check-ins ရှိပါတယ်။ 500,000 က Merchant Platform ကို အသုံးပြုနေပါတယ်။14 ။ foursquare website ကို scala နဲ့ ရေးထားပြီးတော့ JVM ပေါ်မှာ run နေပါတယ်။ Life web framework ကို အသုံးပြုထားတယ်။ PostgreSQL နဲ့ စခဲ့ပြီး နောက်ပိုင်းမှာ Mongodb ကို ပြောင်းခဲ့ပါတယ်။15

ဒီ အချက်အလက်တွေကို ကြည့်ရင် grow မဖြစ်ခင်သုံးက PostgreSQL ကို အသုံးပြုကြတာ များပါတယ်။ သို့ပေမယ့် နောက်ပိုင်းမှာတော့ Mongodb သို့မဟုတ် Redis ကို ပြောင်းကြတယ်။ ဒါမှမဟုတ် တစ်ခြား NoSQL တစ်ခုခုကိုပေါ့။ NoSQL နဲ့ ချက်ခြင်း စလိုက်လို့ မရဘူးလားဆိုတဲ့ မေးခွန်း ကျွန်တော် ကိုယ့်ဘာသာကိုယ် မေးဖူးတယ်။ Mongodb နဲ့ စလိုက်ရင် ရပေမယ့် မကျွမ်းကျင်တဲ့အတွက် product ထွက်ဖို့ ကြာမယ်။ အချိန်ကြာမယ်ဆိုရင် ကြားထဲမှာ project က ပျက်သွားဖို့ အကြောင်းတွေ အများကြီး ရှိပါတယ်။ ဒါကြောင့် တော်တော်များများက မြန်မြန် ပြီးအောင် ကျွမ်းကျင်တဲ့ Relational Database ကို အသုံးပြုကြပါတယ်။ NoSQL က RDB နဲ့ ယှဉ်လိုက်ရင် သက်တမ်း အရမ်းနုပါသေးတယ်။

အသုံးများတဲ့ language တွေက PHP , scala , python , ruby စတဲ့ langauge တွေကို အသုံးများတယ်။ လက်ရှိ popular ဖြစ်နေတဲ့ service တွေ အကုန် စကာစ က အကြီးကြီးနဲ့ စခဲ့တာ မဟုတ်ပါဘူး။ သေးသေးလေးလည်း မဟုတ်ပါဘူး။ သဘောအကျဆုံးကတော့ instagram ပဲ။ foursquare တောင် Mongodb ကို ပြောင်းဖို့ အချိန် တော်တော်ကြီးကို ယူပြီး ဖြည်းဖြည်းခြင်းဆီ ပြောင်းခဲ့ရတယ်။

သူတို့ရဲ့ infrastructure အကြောင်းကို detail မသိရပေမယ့် အနည်းငယ် ရိပ်ဖမ်းသံဖမ်း သိလိုက်ရတာ တော်တော်လေးကို အဆင်ပြေသွားတယ်။ သူတို့ လုပ်ထားတဲ့ ပုံစံနဲ့ ကျွန်တော် လက်ရှိ လုပ်နေတဲ့ ပုံစံနဲ့ ယှဉ်လိုက်ရင် တော်တော်လေးကို ကွာခြားတယ်။ လက်ရှိ project မှာ ပြဿနာ အများကြီး တက်လာနိုင်တယ်ဆိုတာကို မဖြစ်ခင် တော်တော်များများ ကြိုတွေ့သွားတယ်။ ဘာပဲ ပြောပြော ၂ ရက်လောက် အချိန်ပေးပြီး ရှာပြီး ဖတ်လိုက်ရတာ တန်တယ်လို့ ဆိုရမယ်။

  1. http://www.quora.com/What-programming-languages-are-used-at-Facebook?q=programming+language+in+facebook
  2. http://www.datacenterknowledge.com/the-facebook-data-center-faq/
  3. https://www.facebook.com/rutherfordDataCenter
  4. http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
  5. https://www.facebook.com/notes/facebook-engineering/the-underlying-technology-of-messages/454991608919
  6. http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/
  7. http://www.quora.com/How-many-servers-does-Twitter-have?q=servers+in+twitter
  8. http://techcrunch.com/2008/04/22/twitter-may-not-have-to-care-about-uptime-any-longer/
  9. http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram
  10. http://www.quora.com/What-servers-would-Instagram-have-used-in-their-early-stage-and-what-servers-do-they-use-now
  11. http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value-pairs
  12. http://www.quora.com/Instagram/How-long-was-Instagram-in-development-for-before-launch?q=how+long+to+make+instagram
  13. http://www.quora.com/How-many-servers-does-a-site-like-Yelp-or-foursquare-require-with-their-level-of-traffic?q=foursquare+infrastructure
  14. https://foursquare.com/about
  15. https://docs.google.com/present/view?id=dhkkqm6q_13gm6jq5fv
]]> http://www.saturngod.net/knowledgebase/infrastructure/feed 0 Test Flight SDK http://www.saturngod.net/knowledgebase/test-flight-sdk?utm_source=rss&utm_medium=rss&utm_campaign=test-flight-sdk http://www.saturngod.net/knowledgebase/test-flight-sdk#comments Fri, 18 Nov 2011 15:24:59 +0000 saturngod http://www.saturngod.net/?p=4894 Continue reading →]]>

Testflight ကိုတော့ iOS developer တော်တော်များများ သိကြပါလိမ့်မယ်။ iOS app development လုပ်တဲ့ အခါမှာ daily build တွေကို testing လုပ်ဖို့အတွက် testflight က အရေးပါလှပါတယ်။ အရင်တုန်းကတော့ SDK မထုတ်သေးပေမယ့် လွန်ခဲ့တဲ့ လအနည်းက SDK ထုတ်ပေးခဲ့ပါတယ်။ SDK က ဘာတွေ လုပ်လို့ရသလဲဆိုရင်တော့

၁။ Application ကို ဘယ်လောက်ကြာကြာသုံးသလဲဆိုတာကို သိနိုင်တယ်။်
၂။ NSLog နဲ့ ရေးထားတာတွေကို ပြန်ကြည့်လို့ရတယ်။ တနည်းပြောရင် ဘယ် line တွေက အလုပ်လုပ်သွားသလဲ မလုပ်သွားဘူးလဲဆိုတာကို သိနိုင်တယ်။
၃။ App က Crash ဖြစ်သွားခဲ့ရင် crash report ကို သူ့အလိုလို testflight ပေါ် တင်ထားပေးတယ်။ ဒါကြောင့် ဘယ်နေရာမှာ ဘာကြောင့် crash ဖြစ်သွားသလဲဆိုတာကို လွယ်လင့်တကူ သိနိုင်တယ်။
၄။ Check Point တွေထားခဲ့လို့ရတယ်။ ဥပမာ။။ Add friend လုပ်မလုပ် သိရအောင် check point ထားခဲ့တာမျိုးပေါ့။
၅။ In App Update လုပ်နိုင်တယ်။ version အသစ်ကို တင်လိုက်တာနဲ့ tester တွေက update မလုပ်ရသေးပဲ အဟောင်းကို ဖွင့်လိုက်တာနဲ့ update လုပ်လို့ရတယ်ဆိုပြီး notification တက်လာတယ်။
၆။ In-App Question ထည့်လို့ရတယ်။

တနည်းပြောရင် ဒီ ၆ ချက်ပါလာတာက testing ပိုင်းအတွက်ကော development ပိုင်းအတွက်ပါ တော်တော်လေးကို ကောင်းမွန်လာတယ်လို့ ဆိုရပါမယ်။ SDK မသုံးရင်တော့ ဒီ ၆ ချက်ကို မရနိုင်ဘူးပေါ့။

SDK ကို download ချဖို့က ဒီမှာ ယူနိုင်ပါတယ်။

SDK ကို အသုံးပြုပုံကလည်း အလွန်ပဲ လွယ်ကူပါတယ်။

#import “TestFlight.h”

ကို prefix မှာ ထည့်ပေးလိုက်ရုံပါပဲ။ အသေးစိတ်ကိုတော့ ဒီမှာ ဖတ်ကြည့်နိုင်ပါတယ်။

အရင်တုန်းက နေ့စဉ် daily build တွေမှာ နဂိုမူရင်း testflight ကို အသုံးပြုပေမယ့် နောက်ပိုင်း SDK ထွက်လာတော့ SDK ပါ ပူးတွဲ ထည့်လာတယ်။ ဒါကြောင့် crash ဖြစ်သွားတယ်ဆိုရင် crash log လေးကို လွယ်လင့်တကူ သွားကြည့်ပြီး ဘာကြောင့် crash ဖြစ်တာလဲ။ ဘာတွေ နှိပ်သွားသလဲ စတာတွေကို trace ကောင်းကောင်း လုပ်လို့ရပါတယ်။

]]> http://www.saturngod.net/knowledgebase/test-flight-sdk/feed 0 Restful API and php framework http://www.saturngod.net/knowledgebase/restful-api-and-php-framework?utm_source=rss&utm_medium=rss&utm_campaign=restful-api-and-php-framework http://www.saturngod.net/knowledgebase/restful-api-and-php-framework#comments Wed, 09 Nov 2011 15:11:26 +0000 saturngod http://www.saturngod.net/?p=4886 Continue reading →]]>

အခုတလော ရုံးမှာ Restful API server ပိုင်းကို ရေးနေရတယ်။ အဲဒီမှာ CodeIgniter Routing Structure နဲ့ အဆင်မပြေတာကို တွေ့လာရတယ်။ Restful API တွေက Controller နဲ့ Model ပဲရှိတယ်။ view ဆိုတာက JSON သို့မဟုတ် XML return ပြန်တဲ့ page ပဲ ရှိတယ်။ အဲဒီတော့ API server ပိုင်းရေးတဲ့ အခါမှာ MVC pattern ဆိုတာက သိပ်အရေးပါတာမဟုတ်ဘူးဆိုတာကို သတိထားမိတယ်။

CodeIgniter ရဲ့ structure က

http://www.domain.com/controller/action/parameter/parameter

controller ကတော့ ရှင်းတယ်။ file တစ်ခု နဲ့ ရေးရလို့။ အဲလိုပဲ action ကလည်း function တစ်ခုနဲ့ ရေးရတော့ တော်တော်လေးကို ရှင်းတယ်။ code ကို ပြန်ဖတ်ရတာလည်း နားလည်တာပေါ့။ သို့ပေမယ့် API တွေ ရေးရတော့ အခုလို ဖြစ်သွားတတ်တယ်။

http://www.domain.com/users/:username/

http://www.domain.com/users/:username/blogs/

http://www.domain.com/users/:username/blogs/:id/

http://www.domain.com/users/:username/blogs/:id/coments/

http://www.domain.com/users/:username/blogs/:id/coments/:id

/:username ဆိုရင် သက်ဆိုင်ရာ user ရဲ့ data တွေ ထွက်လာမယ်။
/:username/blogs ဆိုရင် သူ့ ရဲ့ blog list ထွက်လာမယ်။
/blogs/:id ဆိုရင် blog တွေထဲကမှ id တစ်ခုအတွက် data ထွက်လာမယ်။
/blogs/:id/comments ဆိုရင် comments အကုန်ပေါ့။
/blogs/:id/comments/:id ဆိုရင်တော့ comments တစ်ခုအတွက် id ပေါ့။

အဲဒီမှာ စပြီး ပြဿနာ ဖြစ်တာကတော့ controller က dynamic ဖြစ်နေတာပဲ။ /users/name ဆိုပြီး သုံးပါလားလို့ ဆိုလို့ရပေမယ့် link လမ်းကြောင်းက developers အချို့အတွက် complain တက်စရာ ဖြစ်သွားမှာ အမှန်ပဲ။ ကျွန်တော့် အနေနဲ့လည်း /users/:username ကို /users/name/:username ထက် ပိုသဘောကျတယ်။ တိုသလို လွယ်တယ်။ /name ထည့်လိုက်တဲ့အတွက် /id ကော မရှိဘူးလားဆိုပြီး မေးခွန်းက ရှိလာပြန်တယ်။ Controller ကို သတ်မှတ်လို့ မရတဲ့အတွက် စကတည်းက index မှာပဲ စရမှာပဲပေါ့။ index မှာ username ကို စစ်ပြီးတော့ ရှိခဲ့ရင် သက်ဆိုင်ရာ user ရဲ့ data ကို ပြန်ခေါ်ပြပေးရုံပဲ။

ဒီအထိ ရှင်းပါသေးတယ်။ /blogs ဆိုတာကို ထပ်ထည့်လိုက်တော့ သက်ဆိုရင် user information ကို မပြပေးရတော့ပဲ /blogs လာပြီဆိုရင် blog အားလုံးရဲ့ list ကို ပြဖို့ condition ထပ်ရေးရပါတယ်။

/blogs/:id ဆိုရင် blogs id ကို ရှိမရှိ ထပ်စစ်ရပါမယ်။ အဲဒီ blog id ကလည်း လက်ရှိ username ရဲ့ blog id ဟုတ်မဟုတ် ထပ်စစ်ရပါမယ်။ နောက်ဆုံး /blogs/:id/comments/:id အထိ ကို ရေးတဲ့အခါမှာ condition တွေ အများကြီး သုံးရပါမယ်။ အကုန်လုံးက index() function ထဲမှာ စစ်ထားရပါမယ်။ တနည်းပြောရင် controller/action အပြင်

controller/controller/action ဖြစ်သွားတဲ့အခါရှိသလို /controller/controller/controller/action ဆိုပြီး ရှိသွားတဲ့အခါလည်း ရှိပြန်ကော။ တနည်းပြောရင် url က ရှည်သွားတဲ့အခါမှာ CodeIgniter framework ပုံစံက အရမ်းကို ရှုပ်ထွေးကုန်တာ အမှန်ပဲ။

အဲလိုပဲ CodeIgniter ကို အခြေခံထားတဲ့ Ava framework ပုံစံက လည်း ရှုပ်ထွေးကုန်တယ်။ အစက Restful အတွက် ဆိုပြီး သီးသန့် RestController ထည့်ထားပေမယ့် တကယ်တန်း link တွေက အရမ်းကို ရှည်လာတဲ့ အခါမှာ အဆင်မပြေတော့ပါဘူး။

ဒီနေ့ ဘာကို သွားတွေ့မိသလဲဆိုတော့ Sinatra ပုံစံကို ယူထားတဲ့ Slimframework ဆိုတာကိုပါ။ တော်တော်များများကတော့ slim အစား limonade ကို recommend လုပ်ကြတယ်။ Documentation ကို ကြည့်ကြည့်တာကတော့ limonade က ပိုပြည့်ပြည့်စုံစုံ ရေးထားပေမယ့် limo လို အစိမ်းရောင်ကြီး သုံးထားတော့ documentation ကို ကျွန်တော့် မျက်လုံးက ကြာကြာမဖတ်နိုင်ဘူး။ limonade မှာ သုံးထားတဲ့ structure ကို သိပ်သဘောမကျလှဘူး။ ကျွန်တော်ကတော့ Slimframework မှာ သုံးထားတဲ့ structure ကို သဘောကျမိတယ်။

Slim နဲ့ hello world ကို ဒီလိုရေးရပါတယ်။ GET , POST , PUT , DELETE method တွေကို သတ်မှတ်ပြီးသားပါ။ ဒါကြောင့် GET ဖြစ်လား POST ဖြစ်လား PUT ဖြစ်လား DELETE ဖြစ်လား စစ်ရတဲ့ အလုပ်တော့ သက်သာသွားတယ်။

Sinatra ရဲ့ routing ပုံစံကို express ,node web framework ကို လေ့လာခဲ့တုန်းက သိခဲ့တယ်။ အဲဒီကတည်းက တော်တော်သဘောကျမိခဲ့တာ။ အဓိက သဘောကျတဲ့ အချက်ကတော့ routing ပုံစံပဲ။ router ကို မိမိသဘောကျ သတ်မှတ်ထားပြီး ဒါလာရင် ဒီ function သွားဆိုပြီး ရေးလို့ရလို့ပါပဲ။ လက်ရှိ ကျွန်တော် CodeIgniter Router မှာ ကြုံနေရဲ့ ပြဿနာတွေကို Sinatra ပုံစံအတိုင်းဆိုရင် လွယ်လွယ်လေးနဲ့ ဖြေရှင်းလို့ရပါလိမ့်မယ်။ အဆင်ပြေတယ်ဆိုရင် Slimframework လေးကို လေ့လာပြီး နောက် လုပ်မယ့် projects ရောက်ရင် ပြောင်းသုံးမယ်လို့ စဉ်းစားထားတယ်။ အခု projects တွေကတော့ နောက်ဆုတ်ဖို့ အချိန်မရှိတော့ဘူး။ code တွေက ရှုပ်ထွေးနေပေမယ့် ကောင်းကောင်း အလုပ်လုပ်နေတယ်။ သို့ပေမယ့် slimframework ထက် node က express framework ကို ပိုသဘောကျနေမိတာ အမှန်ပဲ။ သို့ပေမယ့် node.js က mysql နဲ့ တွဲသုံးရတာ အချို့ကိစ္စတွေ တော်တော်လက်ပေါက်ကပ်တာတော့ အမှန်ပါပဲ။

]]> http://www.saturngod.net/knowledgebase/restful-api-and-php-framework/feed 3 RestKit Framework http://www.saturngod.net/knowledgebase/restkit-framework?utm_source=rss&utm_medium=rss&utm_campaign=restkit-framework http://www.saturngod.net/knowledgebase/restkit-framework#comments Tue, 08 Nov 2011 14:12:40 +0000 saturngod http://www.saturngod.net/?p=4881 Continue reading →]]>

RestKit ဆိုတာကတော့ Objective-C အတွက် framework တစ်ခုပါ။ အထိက RestFul API တွေအတွက် ဖန်တီးထားတဲ့ framework တစ်ခုပါ။ ပုံမှန် NSURLRequest နဲ့ အသုံးပြုတဲ့အခါမှာတော့ ရောက်လာတဲ့ JSON file ကို JSON framework ကနေ တဆင့် NSDictionary ပြောင်းရတယ်။ ရတဲ့ NSDictionary တွေက တစ်ခါတစ်လေမှာ Array ဖြစ်နေတာတွေလည်း ဖြစ်တတ်တယ်။ NSDictionary က data တွေကို objectForKey နဲ့ ပြန်ခေါ်ရတယ်။

ဥပမာ။။

ဆိုတဲ့ အထဲမှာ user က ထပ်ပြီးတော့ ပါနေပြန်တယ်။ အဲဒီလိုမျိုး ကိစ္စတွေမှာ NSURLRequest နဲ့ NSDictionary ကို သုံးရတာ တော်တော်လေးကို အဆင့်ဆင့်လုပ်နေရပါတယ်။ RestKit သုံးလိုက်တဲ့ အခါမှာ အလိုအလျောက် ဆောက်ရွက်ပေးသွားတယ်။ ဘယ်လို ဆောက်ရွက်သွားလဲဆိုတာကတော့ Object Mapping ပါ။

Object Relational Mapper ကို PHP မှာ Doctrine နဲ့ တွဲသုံးဖူးတဲ့သူတွေ သိပါလိမ့်မယ်။ နောက်ပြီးတော့ Symfony Framework ကို သုံးခဲ့တဲ့သူတွေ ကောင်းကောင်းနားလည်ပါလိမ့်မယ်။ RestKit က ရောက်လာတဲ့ JSON တွေကို Object အနေနဲ့ ပြောင်းပြီးတော့ ကျွန်တော်တို့ အနေနဲ့ object ကို ပြန်ခေါ်ရုံပါပဲ။

ဆိုတဲ့ JSON format နဲ့ တွဲသုံးဖို့အတွက် NSObject ကို အောက်ကလို ဆောက်ပါတယ်။

ပြီးတဲ့ အခါမှာ mapping ကို အောက်ကလို ချိတ်လိုက်ပါတယ်။

loading ပြန်ခေါ်တဲ့အခါမှာတော့

ဆိုပြီး ပြန်ခေါ်လိုက်တဲ့ အခါမှာ Objects NSArray ထဲမှာ article objects တွေ ဝင်သွားပါပြီ။ ဒါကြောင့် Articles တွေကို လွယ်လွယ်နဲ့ ခေါ်လို့ရသွားပါတယ်။

တကယ်လို့ iOS app တွေမှာ API တွေ နဲ့ ချိတ်ပြီး ရေးမယ်ဆိုရင်တော့ RestKit ကို အရင်လေ့လာစေချင်တယ်။ RestKit ကို လေ့လာရတာ ၂ ရက်လောက်တော့ အချိန်ပေးရမယ်။ နားလည်သွားတဲ့အခါမှာတော့ တော်တော်လေးကို လွယ်လွယ်ကူကူ ရေးလို့ရသွားပါတယ်။

ဘာကြောင့် RestKit ကို သုံးသင့်သလဲဆိုတော့

၁။ Object Mapping System
၂။ High Level Framework System
၃။ Core Data Support
၄။ JSON Support

စတဲ့အချက်တွေကြောင့်ပါ။ Offline support ကိုရေးတဲ့အခါမှာ core data ထဲကို request က ပြန်လာတဲ့ respond တွေ သီးသန့် သွားသွားဖြည့်နေဖို့ မလိုအပ်ပါဘူး။ RestKit ကို Core Data နဲ့ ချိတ်လိုက်တဲ့အခါ သူ့အလိုအလျောက် သွားထည့်ပေးတဲ့ အတွက် Offline support ပိုင်းတွေ ရေးရတဲ့ အခါမှာ တော်တော်လေးကို အဆင်ပြေသွားပါတယ်။

RestKit နဲ့ ပတ်သက်ပြီးလေ့လာဖို့အတွက် RestKit wiki page မှာ သွားဖတ်နိုင်ပါတယ်။ Installation လုပ်ပုံ အစ သေသေချာချာ ရေးထားပေးပါတယ်။ ဘာမှ မလုပ်ခင် သူပေးထားတဲ့ presentation file လေးကို အရင်ဖတ်လိုက်တဲ့ အခါမှာ RestKit framework ကို အကြမ်းနားလည်သွားပါလိမ့်မယ်။

]]> http://www.saturngod.net/knowledgebase/restkit-framework/feed 0