Pylons Routes, NestedConnector no comments
ในไฟล์ 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 no comments
สารภาพว่าก่อนหน้านี้ผมไม่เคยคิดที่จะมอง CouchDB อยู่ในสายตาเลยแม้แต่น้อย อาจจะเรียกว่าเป็นคนสาย RDBMS เต็มขั้นจนไม่เห็นความจำเป็นที่จะต้องเปลี่ยนไปใช้ฐานข้อมูลที่สร้างขึ้นด้วยแนวคิดอื่น แต่หลังจากอ่านที่มีคนอธิบายความสามารถของ CouchDB ใน Reddit ทำให้เกิดความสนใจขึ้นมาเล็กน้อยทำให้เริ่มลองศึกษาแนวคิดการทำงานของมัน
คอนเซปของ CouchDB ก็คือไม่มีการใช้ schema เป็นเบื้องหลังฐานข้อมูล และไม่มีคอนเซปที่เรียกว่าตาราง แต่ละแถวในฐานข้อมูลถูกเรียกว่า “document” และแยกออกจากกันชัดเจน โดยไม่จำเป็นต้องมีรูปแบบตายตัว สิ่งที่ได้มาจากการทำแบบนี้คือความยืดหยุ่นของข้อมูลในฐานข้อมูลหนึ่งๆ
ตัวอย่างง่ายๆ ที่สามารถนำคอนเซป document ของ CouchDB ไปใช้ได้คือ node ของ Drupal ที่สามารถเป็นได้หลายอย่าง ในกรณีของการใช้ RDBMS คุณต้องมานั่งปวดหัวกับ schema ของตารางที่จะยุ่งวุ่นวายขึ้นตามความหลากหลายของข้อมูลใน node แต่สำหรับการใช้งาน CouchDB แล้ว มันก็เป็นเพียงแค่ document หนึ่งๆ เท่านั้น
Thai Font in Ubuntu no comments
วันนี้ได้มีโอกาสลง 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 ไปยังเซิฟเวอร์สำรองเอา น่าจะสบายใจได้พอสมควร
