Pylons Routes, NestedConnector 1 comment
ในไฟล์ routes.py ของโปรเจค Pylons ของผมมันยาวมาก ถ้าหากจะลองนับแล้วก็คงได้ประมาณ 80 routes ที่ทั้งหมดมีการบังคับ POST, GET และ conditions อื่นๆ อยู่อีก ในเรื่องการดูแลมันเลยวุ่นวายพอสมควร
วันนี้พยายาม convert โปรเจคไปเป็น Pylons 0.9.7 ก็เลยตัดสินใจว่ามานั่งเคลียร์เจ้า routes นี่ซักหน่อยดีกว่า ให้สั้นลงและสามารถดูแลได้ง่ายขึ้น จากเดิมที่หน้าตาประมาณนี้
m.connect('/', controller='posts', action='list', conditions=dict(method='GET')) m.connect('/page/{page}', controller='posts', action='list', requirements=dict(page='\d+'), conditions=dict(method='GET')) m.connect('/tag/{tag}', controller='posts', action='list_tags', conditions=dict(method='GET')) m.connect('/tag/{tag}/page/{page}', controller='posts', action='list_tags', requirements=dict(page='\d+'), conditions=dict(method='GET'))
ให้เหลือแค่นี้
with m.controller('posts') as c: with c.action('list') as a: a.GET('/') a.GET('/page/{page}', requirements=dict(page='\d+')) with c.action('list_tags') as a: a.GET('/tag/{tag}') a.GET('/tag/{tag}/page/{page}', requirements=dict(page='\d+'))
Introduction to CouchDB with Pylons 1 comment
สารภาพว่าก่อนหน้านี้ผมไม่เคยคิดที่จะมอง CouchDB อยู่ในสายตาเลยแม้แต่น้อย อาจจะเรียกว่าเป็นคนสาย RDBMS เต็มขั้นจนไม่เห็นความจำเป็นที่จะต้องเปลี่ยนไปใช้ฐานข้อมูลที่สร้างขึ้นด้วยแนวคิดอื่น แต่หลังจากอ่านที่มีคนอธิบายความสามารถของ CouchDB ใน Reddit ทำให้เกิดความสนใจขึ้นมาเล็กน้อยทำให้เริ่มลองศึกษาแนวคิดการทำงานของมัน
คอนเซปของ CouchDB ก็คือไม่มีการใช้ schema เป็นเบื้องหลังฐานข้อมูล และไม่มีคอนเซปที่เรียกว่าตาราง แต่ละแถวในฐานข้อมูลถูกเรียกว่า “document” และแยกออกจากกันชัดเจน โดยไม่จำเป็นต้องมีรูปแบบตายตัว สิ่งที่ได้มาจากการทำแบบนี้คือความยืดหยุ่นของข้อมูลในฐานข้อมูลหนึ่งๆ
ตัวอย่างง่ายๆ ที่สามารถนำคอนเซป document ของ CouchDB ไปใช้ได้คือ node ของ Drupal ที่สามารถเป็นได้หลายอย่าง ในกรณีของการใช้ RDBMS คุณต้องมานั่งปวดหัวกับ schema ของตารางที่จะยุ่งวุ่นวายขึ้นตามความหลากหลายของข้อมูลใน node แต่สำหรับการใช้งาน CouchDB แล้ว มันก็เป็นเพียงแค่ document หนึ่งๆ เท่านั้น
Thai Font in Ubuntu 1 comment
วันนี้ได้มีโอกาสลง Linux อีกรอบหนึ่งหลังจากผ่านไปหลายเดือนจากคราวที่แล้ว ถือโอกาสลงเสร็จใหม่ๆ จัดการกับฟอนท์ให้เรียบร้อย เพราะส่วนตัวแล้วไม่ชอบภาษาไทยที่ใช้เป็นมาตรฐานของ Linux เอามากๆ และในขณะเดียวกันก็ไม่ชอบภาษาอังกฤษที่ใช้ใน Lomaputta เลยแม้แต่นิดเดีย ด้วยเหตุนั้นเลยคิดว่าคงเป็นการดีถ้าหากเอาฟอนท์สองตัวนี้มารวมกันได้…
หลังจากลองขุดคุ้ยใน /etc/fonts/conf.d/ อยู่ซักพักหนึ่ง ก็พบว่าฟอนท์ชื่อ “serif” และ “sans-serif” นั้น จริงๆ แล้วเป็นเพียงแค่ alias ของฟอนท์หลายๆ ตัว ซึ่งถูกตั้งไว้ในไฟล์หลายๆ ไฟล์ และฟอนท์ Bitstream Vera DejaVu ที่เป็นมาตรฐานนั้นถูกเซ็ทไว้ที่ไฟล์ 60-latin.conf เลยคิดว่าถ้าหากเซ็ทให้ Lomaputta เป็น preferred ก่อนหน้านั้นล่ะ?
จัดการสร้างไฟล์ 40-ttf-thai.conf แล้วโยนลงไปใน /etc/fonts/conf.d/ หน้าตาแบบนี้
<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <alias> <family>serif</family> <prefer><family>Lomaputta</family></prefer> </alias> <alias> <family>sans-serif</family> <prefer><family>Lomaputta</family></prefer> </alias> <alias> <family>monospace</family> <prefer><family>TlwgMono</family></prefer> </alias> </fontconfig>
ผลปรากฎเป็นไปตามที่คาด ทั้งฟอนท์ “serif” และ “sans-serif” ต่างก็ใช้ glyph ภาษาไทยจาก Lomaputta ในขณะเดียวกันก็ใช้ภาษาอังกฤษจาก Bitstream Vera DejaVu เท่านี้ก็รู้สึกใช้ Ubuntu ได้อย่างสบายตาขึ้นเยอะ
PostgreSQL Dirty Database Backup no comments
พยายามหาสคริตป์สำหรับแบคอัพฐานข้อมูล PostgreSQL อยู่ซักพักนึง แต่หาตัวที่ทำอย่างที่ต้องการไม่ได้ซะที เลยคิดว่าเขียนเองแบบสกปรกๆ ใช้ไปก่อนดีกว่า เลยได้ออกมาหน้าตาแบบนี้ (เซ็ทรหัสผ่านในไฟล์ ~/.pgpass และ chmod 600 เอา)
#!/usr/bin/env bash # Set user information inside ~/.pgpass and chmod 600 it. # Configurations DATABASE="dbname" USERNAME="username" SAVE_PATH="/backup" DAYS=7 # Generate datetime for file naming DATE_FILE=`date '+%Y-%m-%d-%H-%M-%S'` DB_FILENAME="$DATABASE-$DATE_FILE.dump" DB_FILEPATH="$SAVE_PATH/$DB_FILENAME" SAVE_FILE="$SAVE_PATH/$DATABASE-$DATE_FILE.tar.bz2" # Run /usr/local/bin/pg_dump -U $USERNAME --no-owner $DATABASE > $DB_FILEPATH cd $SAVE_PATH /usr/bin/tar -cjf $SAVE_FILE $DB_FILENAME /bin/rm $DB_FILEPATH # Clean older files /usr/bin/find $SAVE_PATH/* -mtime +$DAYS -name '*.tar.bz2' -exec rm {} \;
คิดว่าบรรทัดสุดท้ายคงใช้เป็น /usr/bin/find $SAVE_PATH/* -mtime +$DAYS -name '*.tar.bz2' -delete ไปเลยจะน่าปลอดภัยขึ้น แต่ตอนนี้ไม่อยากแก้อะไรที่มันทำงานได้อยู่แล้ว ดังนั้นปล่อยมันเป็นงี้ไปก่อนดีกว่า…
ไฟล์ที่ออกมาจะหน้าตาเป็น dbname-2008-12-18-17-30-00.tar.bz2 และจะเก็บไว้เพียงของ 7 วันสุดท้าย ผมตั้ง cron ให้มันรันทุกๆ 6 ชั่วโมง และ rsync ไปยังเซิฟเวอร์สำรองเอา น่าจะสบายใจได้พอสมควร
