def fac(i): return reduce(int.__mul__, xrange(1, i+1), 1)

Distributed revision control เป็นเครื่องมือที่ Developer สมัยนี้จะต้องหามาใส่หัวให้ได้ Mercurial ก็เป็น DVCS ชนิดหนึ่งที่เป็นที่นิยมในตลาด ( หมายถึงตลาดโลก ในเมืองไทยหายากหน่อยนึง ) แต่หลายคนที่พยายามจะเปลี่ยนจาก Subversion มาเป๋น DVCS ก็ยังสับสน ว่าไอ้ที่มีอยู่หลายเจ้านั้น มีดียังไง ผมจะสรุปคร่าวๆโดยที่พยายามพูดถึงเจ้าอื่นให้น้อยที่สุด เพื่อไม่ให้เกิดดราม่า

• Mercurial สามารถทำงานได้ดี ในทีมที่มีหลายๆคน เพราะว่าแต่ละคนก็มี repo ของตัวเอง
• เนื่องด้วยแต่ละคนมี repo ของตัวเอง อิสระในการทำงานก็สูงกว่า ไม่ต้องกังวลว่าจะไปพังของใคร แล้วทำให้ทั้งระบบต้องหยุด
• สามารถทำงานแบบ Stand Alone แค่เพียง Check Out มา จะ Commit ก็ครั้งก็ได้ พอต่อเน็ตได้ค่อย Push ทีเดียว
• แต่ละ Rev. มีเลขกำกับ เหมือน SVN ต่างจาก Git ที่เป็น Hash ยาวๆ จำยากๆ แต่ก็มีข้อเสียที่หมายเลข Rev เดียวกันนี้ จะแตกต่างไปจากคนอื่นๆ สร้างความสับสนพอสมควร เอาให้ชัวร์เวลา Merge ก็อ้างจาก Hash นั่นแหละ
• ลงง่าย ใช้เร็ว มีเกือบทุก Platform
• Guido ใช้ ( อันนี้ไม่รู้เป็นข้อดีหรือเปล่า อารมณ์ประมาณเหมือนใช้กระเป๋า ใช้มือถือตามดาราที่ชอบ )
• มี Web Server build-in อันนี้ชอบมาก เหมาะกับคนที่ไม่ได้ใช้ผ่าน GUI สามารถสั่ง hg serve ไปเปิดไปที่ http://localhost:8000 เลย
• ฟรี!!!

นึกต่อไม่ออกแฮะ ตัดจบเลยแล้วกัน

Django มีสุดยอดแห่ง unit testing ที่ build in มาในตัว framework เรียบร้อยแล้ว, คนมักจะไม่ค่อยใส่ใจกับมันเท่าไรนักเพราะว่ามันมาแบบ “out of the box” แต่นั่นไม่ได้หมายความว่าเราจะละเลยส่วนั้นได้ เมื่อเราสร้าง Application ของเราเองขึ้นมา เพราะว่าเทสต์นั้นทำให้เรา “คิดออก” ว่าอะไรที่ควรจะทำให้เสร็จ เพราะฉะนั้นเราจะมาพูดเรื่องทำอย่างไรให้ Application สามรถทำงานได้เป็นอย่างดี

เมื่อมาถึงตรงนี้แล้วผมจะพยายามแสดงให้เห็นว่า ทำยังไงจะใช้ TDD ใน Django Application เราจะสร้าง Project เล็กๆ และมี Application เพียงตัวเดียว และใช้ Unit testing เป็นตัวกำหนด ว่าจะออกแบบ algorithm และจะ implement class อย่างไร

ทำไมต้องเทสต์ตลอด?

หลายๆ คนพูดถึงเรื่อง Test Driven Development แล้วยังมีโปรแกรมเมอร์ที่มีประสบการณ์หลายๆ คน ที่ไม่ต้องการจะทำ TDD เพราะว่าคนเหล่านั้น ไม่ยอมเปิดรับการเปลี่ยนแปลงใหม่ๆและไม่ยอมที่จะเรียนรู้  คนกลุ่มนี้สร้างระบบและจัดการในเรื่องการ maintain code เขาอาจจะเขียน code เป็นเดือน หรือแม้แต่เป็นปี code ที่เขียนนั้นได้รับการทดสอบเต็มรูปแบบจึงมั่นใจในความแข็งแกร่ง ทำไมยังจะต้องเขียน unit test?

โปรแกรมเมอร์รุ่นใหม่ไม่รู้ว่าจะเริ่มต้นกับเทสต์อย่างไร พวกเขาเขียน code แล้วจึงเขียนเทสต์ แล้วจึงพบกับความท้อแท้ เพราะว่าต้องเขียน code วนซ้ำไปซ้ำมาถึงสองครั้ง เพื่อที่จะพบกับผลลัพท์ที่แทบจะเอาตัวไม่รอด

เรื่องทั้งคู่เป็นเรื่องน่าเศร้าที่เราจะพบเห็นได้บ่อยๆ เพราะมีบางสิ่งที่ TDD ได้มอบให้โปรแกรมเมอร์และองค์กรนั้นคือ :

• การรับประกันคุณภาพที่มีประสิทธิภาพมากขึ้น เพราะว่า QA Engineer และ Tester ไม่ต้องมานั่งตรวจสอบฟังชั่นการทำงาน, แล้วมันให้ code ที่ดีกว่าเหรอ? หมายความว่ายังไงกันแน่? หมายความว่าต่างคนก็ต่างทำงานใขขอบเขตของตน นั่นสร้างประโยชน์โดยรวมแก่บริษัททั้งหมด ถ้าโค้ดพื้นฐานและฟังชั่นทั้งหมด สามารถเทสต์ได้โดยอัตโนมัต QA ก็สามารถที่จะใช้เวลาเพิ่มขึ้นในการค้นหาบักที่ไม่ชัดเจน และแก้ไขมันเสีย ก่อนที่มันจะทำลายโปรแกรมทั้งหมด.
• การประสานงานในองค์กรดีขึ้น TDD สร้างความไว้เนื้อเชื่อใจในองค์กรทั้งหมด โปรแกรมเมอร์ต้องการความเชื่อใจในความสามารถและทักษะ เมื่อทุกคนในองค์กรใช้ TDD นั่นหมายความว่าโค้ดที่มากจากคนอื่นๆในองค์กรจะต้องทำงานได้ถูกต้อง นั่นไม่ได้เพียงแค่สร้างความเชื่อใจระหว่างโปรแกรมเมอร์ แต่ยังรวมถึงส่วนอื่นๆในองค์กร เช่นฝ่ายการตลาด Business resource รวมไปถึง QA
• ความเป็นมืออาชีพ คำว่าโปร ไม่ได้หมายความเพียงแค่เขียนโค้ดนับพันบรรทัดในวันเดียว แต่หมายถึงการเขียนโค้ดที่มีประสิทธิภาพ ง่ายต่อการบำรุงรักษา ง่ายต่อการ config หมายถึงโค้ดที่ “ทำงานได้” ตลอดเวลา ไม่ใช้แค่ทำงานได้ แต่ต้องผ่านการเทสต์และมีเอกสารที่ดีด้วย
• สร้างแรงกดดันเพื่อน “ทำสิ่งที่ถูกต้อง” เมื่อสมาชิกในทีมรวมไปถึงหัวหน้าทีมใช้งาน TDD ดูแลโค้ดของตัวเองให้มีประสิทธิภาพ มันจะสร้างแรงกระตุ้นต่อองค์กรโดยรวม ให้เกิดสภาพแวดล้อมที่ดีต่อการฝึกฝน

Test Driven Development ภายไต้ unit test จะสร้างซอฟต์แวร์ที่มีประสิทธิภาพ และสามารถทำงานได้อย่างดี บทความอันนี้จะอธิบายถึงวิธีการพัฒนาโปรแกรมที่ซับซ้อนอย่าง Bank Routing Number (ABN) validation class

Create the Project and Application

อย่างแรกที่จะทำคือสร้าง Application ชื่อ

valid_lib

โดยกำหนดให้เป็น Service platform ที่อนุญาติให้ข้อมูลทางการเงินอันสลับซับซ้อนสามารถ validate ผ่าน ReSTful interface. ในตอนนี้เรายังไม่ต้องกังวลเกี่ยวกับ Service หรือ Business model เพียงแค่คิดเรื่องเกี่ยวกับการคำรวนและ validation algorithm ก็พอ ตอนนี้เริ่มจากสร้างแอปก่อน

./manage.py startapp finvs

และเพิ่ม finvs ลงไปบน INSTALL_APP ในไฟล์ settings.py สร้างโฟลเดอร์ชื่อ util ลงในโฟลเดอร์ finvs อีกทีนึงอย่างในรูป

ลองดูที่ไฟล์ test.py ในโฟลเดอร์ชื่อ finvs เราจะเริ่มจากตรงนั้น Django ได้สร้าง unit test ไฟล์ไว้ให้เราแล้ว

ABN Validation

ABA (American Banker’s Association) routing numbers (ABNs) ใช้สำหรับระบุสถาบันการเงินตอนที่สร้าง transaction ตัวเลขนี้จำเป็นต้องใช้เวลาที่จะโอนเงินผ่านธนาคารโดยตรง บริการจ่ายเงินอัตโนมัต หรือเมื่อเราต้องการจะจ่ายเงินเผ่านโทรศัพท์ ระบบออนไลน์เป็นต้น

เลขเหล่านี้มีความหมายต่างๆดันไป และยังรวมถึง checksum digit เพื่อที่จะสามารถตรวจสอบได้ว่าเลขที่ให้มานั้นถูกต้องหรือไม่

Algorithm จะตรวจสอบดังนี้ 3(d1+d4+d7)+7(d2+d5+d8)+(d3+d6+d9) mod 10 = 0 แบบนี้

import unittest
#from django.test import TestCase

#Here are some bank numbers that we can run tests against...
SHORT_BAD_ABN_NUM = 1000012
LONG_BAD_ABN_NUM = 255073345999
BAD_ABN_NUM = 255073545
GOOD_ABN_NUM = 255073345

class ValidatorsTestCase(unittest.TestCase):

    def setUp(self):
        self.value = GOOD_ABN_NUM

    def testAbnAlgorythm(self):
        """Tests the algorythm with a known good bank number.
           This test is here to create the algorythm to be used
             in the validator implementation.  When it's right,
             cut and paste it into the validator class.

           The algorithm checks the first second and third number
            and adds them together, then iterates through every
            three numbers (total of 9) to return a value.

           If the resulting sum is an even multiple of ten
            (but not zero), the ABA routing number is good.
           """
        n=0
        bank_str = str(GOOD_ABN_NUM)
        num_length = len(bank_str)
        if (num_length ==9):
            for j in range(0,num_length,3):
                t = int(bank_str[j])
                ti = int(bank_str[j + 1])
                tii = int(bank_str[j + 2])
                n += (t * 3)+ (ti * 7)+ tii
            self.assertTrue((n != 0) & ((n % 10) == 0))

หลังจากนั้นก็รันเทสต์

python manage.py test finvs.ValidatorsTestCase

น่าจะได้ผลลัพท์อย่างนี้

$ python manage.py test finvs.ValidatorsTestCase
Creating test database...
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Installing index for auth.Permission model
Installing index for auth.Message model
True
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
Destroying test database...

ระหว่างที่กำลังรันเทสต์นั้น Django จะสร้างและลบ Test Database ให้โดยอัตโนมัต แจ่มใหม? แต่จริงๆแล้วเราจะยังไม่ได้ใช้โค้ดชุดนี้ เราจะสร้าง Production code ต่างหาก แต่เมื่อดูตัวเทสต์ จะพบว่านี่คือพื้นฐานของการ implement ระบบจริงๆ

ครั้งหน้าเราจะมาต่อที่การ implement จริงๆกัน

เกี่ยวกับเอกสารนี้

เอกสารนี้อธิบายรายละเอียดเกี่ยวกับไวยากรณ์ของ Django Template . หรือมีข้อสงสัยหรือปัญหาการใช้งาน โปรดอ่าน The Django template language: For Python programmers.

Django template นั้นออกแบบมาอย่างสมดุลระหว่างความสามารถและความง่ายดาย. มันถูกออกแบบมาให้สามารถทำงานกับ HTML ได้สะดวก นั่นรวมถึง Text-Based อื่นๆด้วย.

หลักการ

ถ้าคุณเคยมีพื้นฐานการเขียนโปรแกรมที่ฝังโค้ดใน HTML แล้ว คุณจะรู้สึกเหมือนได้กลับบ้านอีกครั้ง การใช้ Django template จะเป็นอะไรที่ง่ายดาย แต่ถ้าหากคุณหวังว่าจะเห็นโค้ด Python ใน Django template แล้ว ต้องขอแสดงความเสียใจที่ทำให้ผิดหวัง
The Django template มีฟังชั่นเหมือนกับภาษาโปรแกรมทั่วไป มี if tags เพื่อตรวจสอบเงื่อนไข มี for loop เอาไว้วนให้ปวดหัวเล่น Django template จะรันเพียง template tag และจะไม่รัน Python code โดยเด็ดขาด

Templates

Template เป็นเพียงไฟล์ text  สามารถสร้างในรูปแบบใดก็ได้ (HTML, XML, CSV, etc.).
มันจะประกอปด้วย ตัวแปร, ที่จะถูกแทนที่เมื่อ template ถูกสร้างขึ้นมา และยังมี tags ที่ทำหน้าที่ควบคุม.
ข้างล่างนี่คือตัวอย่างง่ายๆ

{% extends "base_generic.html" %}
{% block title %}{{ section.title }}{% endblock %}
{% block content %}
<h1>{{ section.title }}</h1>
{% for story in story_list %}
<h2>
<a href="{{ story.get_absolute_url }}">
{{ story.headline|upper }}
</a>
</h2>
<p>{{ story.tease|truncatewords:"100" }}</p>
{% endfor %}
{% endblock %}

Variables

ตัวแปรจะมีหน้าตาประมาณนี้: {{ variable }}. เมื่อ template เจอตัวแปรนี้ จะแทนที่ตัวแปรด้วยค่าที่ได้รับมา ใช้จุดคั่นตัวแปร (.) เพื่อเข้าถึงแอททริบิวต์ในตัวแปร ยกตัวอย่างเช่น, {{ section.title }} จะถูกแทนที่ด้วยค่า title ซึ่งเป็นแอททริบิวต์ของออปเจ็กต์ section.
ถ้าไม่ได้กำหนดค่าให้ หรือไม่พบตัวแปร มันจะถูกแทนที่ด้วย EMPLATE_STRING_IF_INVALID ซึ่งโดยปกติจะเป็น ” (สตริงว่าง) โดยปริยาย.

Filters

คุณสามารถแก้ไขตัวแปรสำหรับการแสดงผลโดยการใช้ ตัวกรอง. Filters จะมีหน้าตาแบบนี้: {{ name|lower }} จะแสดงค่าของ name เป็นตัวอักษรแบบพิมพ์เล็ก ฟิลเตอร์สามารถรวมกันหลายๆอันได้แบบนี้. {{ text|escape|linebreaks }} ฟิลเตอร์นี้จะแปลง text เป็น escape character แล้วค่อยใส่ <p> tags เข้าไปภายหลัง. ฟิลเตอร์บางตัวจะมีอาร์กิวเมนต์

เช่น : {{ bio|truncatewords:30 }}. อันนี้จะแสดง 30 ตัวอักษรแรกของ bio เป็นต้น

ฟิลเตอร์ที่ถายในมีช่องว่างต้องเติมลูกน้ำ(”); ตัวอย่างเช่น {{ list|join:”, ” }}.
default
ฟิลเตอร์นี้จะแสดงค่าปริยายที่เรากำหนด หากตัวแปรไม่มีค่า
เช่น:
{{ value|default:”nothing” }}
ถ้า value ไม่มีค่าอะไรจะแสดง “nothing”.
length
จะแสดงความยาวของตัวแปร ใช้ได้ทั้ง list และ string ;
เช่น:
{{ value|length }}
ถ้า value เป็น ['a', 'b', 'c', 'd'], output จะเป็น 4.

Tags

Tags จะหน้าตาแบบนี้: {% tag %}. Tags จะซับซ้อนกว่าตัวแปรนิดนึง: tag บางอย่างจะสร้าง text outpu. Tag บางอย่างให้ควบคุมโปรแกรม tag ส่วนมากต้องมีจุดเริ่มต้นและจุดจบ (i.e. {% tag %} … tag contents … {% endtag %}).
for
tag นี้เอาไว้สร้าง loop ซึงแปลว่าloop ก็คือ loop ไม่รู้จะอธิบายยังไง – -” ดูตัวอย่างอาจจะหายงง
athlete_list:
<ul>
{% for athlete in athlete_list %}
<li>{{ athlete.name }}</li>
{% endfor %}
</ul>
if and else
อันนี้คือ if else ธรรมดามาก มีทุกภาษา แต่ Django จะทะลึ่งนิดนึง คือจะไม่เปรียบเทียบกับอะไรเลย จะตรวจที่ตัวแปรเลยว่ามีค่า “True” หรือเปล่า ถ้าไม่มีก็ข้ามไป **ระวัง ถ้า value มีอะไรอยู่ข้างใน tag  นี้จะมองเป็น “True” เสมอ ยกเว้นมันมีค่า “False” **
{% if athlete_list %}
Number of athletes: {{ athlete_list|length }}
{% else %}
No athletes.
{% endif %}
จากตัวอย่างข้างบน , ถ้า athlete_list ไม่ว่างหรือไม่ใช่ “False ” จะแสดง {{ athlete_list|length }}.
ifequal และ ifnotequal
แสดงบางอย่างถ้าอากิวเมนต์ทั้งสองตัวเท่ากัน.
ลองดูตัวอย่าง:
{% ifequal athlete.name coach.name %}
…
{% endifequal %}
หรือ:
{% ifnotequal athlete.name “Joe” %}
…
{% endifnotequal %}
block และ extends
สร้าง template inheritance (อ่านด้านล่าง), ช่วยให้งานง่ายขึ้นเยอะ เราสามารถแบ่ง template เป็นชิ้นย่อยๆได้.

Comments

คอมเม้นในโปรแกรม คงไม่ต้องอธิบายกันให้มากความ: {# #}.
ตัวอย่าง, template  นี้จะแสดง ‘hello’:
{# greeting #}hello
น่าเสียดายว่ามันใช้ได้บรรทัดเดียว หากขี้เกียจกดหลายทีให้ใช้ {% comment %} และ {% endcomment %}

Template inheritance

ไม่ต้องประหลาดใจว่า “เทมเพลตมรดก” (ลองดู google translate แล้วจะพบว่ามีฮากว่านี้) คืออะไร มันคือการสืบทอดคุณสมบัติของเทมเพลต มันสามารถช่วยจัดการสร้างโครงสร้างของหน้าเว็บ ด้วยการใช้ tag {%block name%}…{%endblock%} คุณมาสามารถเพิ่มเติมอะไรก็ได้ตรงกลางระหว่าง block
เพื่อให้ง่ายต่อการเข้าใจเทมเพลทมรดกโดยเริ่มต้นด้วยตัวอย่าง:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en” lang=”en”>
<head>
<link rel=”stylesheet” href=”style.css” />
<title>{% block title %}My amazing site{% endblock %}</title>
</head>
<body>
<div id=”sidebar”>
{% block sidebar %}
<ul>
<li><a href=”/”>Home</a></li>
<li><a href=”/blog/”>Blog</a></li>
</ul>
{% endblock %}
</div>
<div id=”content”>
{% block content %}{% endblock %}
</div>
</body>
</html>
เราสร้าง template นี้โดยใช้ชื่อว่า base.html, เป็นโครงร่าง HTML ง่ายๆ แล้วเราค่อยสร้าง template’s ต่อมาโดยการสืบทอด template’s นี้
ในตัวอย่างนี้, {% block %} กำหนด block ของ child template’s ไว้สามอัน เราสามารถเพิ่มเติมได้โดยยังคงโครงสร้างของ template เดิมไว้
child template อาจจะหน้าตาแบบนี้:
{% extends “base.html” %}
{% block title %}My amazing blog{% endblock %}
{% block content %}
{% for entry in blog_entries %}
<h2>{{ entry.title }}</h2>
<p>{{ entry.body }}</p>
{% endfor %}
{% endblock %}
{% extends %} tag คือกุญแจไปสู้ห้องแห่งความลับ. แฮรี่ พอตเตอร์บอกว่าเราสารถใช้ {% extends %} เพื่อสืบทอดทุก template ได้ มหัศจรรย์จริงๆ!! เคราเมอร์ลินเป็นพยาน
สังเกต {% block %} tags ใน base.html and ให้ดีๆ มันจะถูกแทนที่ด้วยข้อมูลใน child template. output ออกมาหน้าตาประมาณนี้:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en” lang=”en”>
<head>
<link rel=”stylesheet” href=”style.css” />
<title>My amazing blog</title>
</head>
<body>
<div id=”sidebar”>
<ul>
<li><a href=”/”>Home</a></li>
<li><a href=”/blog/”>Blog</a></li>
</ul>
</div>
<div id=”content”>
<h2>Entry one</h2>
<p>This is my first entry.</p>
<h2>Entry two</h2>
<p>This is my second entry.</p>
</div>
</body>
</html>
เราไม่ได้กำหนด sidebar block ใน child template ,ข้อมูลใน {% block %} tag จะใช้ค่าเดิมใน base.html
เราสามารถสืบทอด template’s หลายๆชั้นเท่าที่ต้องการเช่น :
สร้าง base.html เป็น templat  ที่เป็นหน้าตาหลักของ site
สร้าง base_SECTIONNAME.html สำหรับทุกๆส่วนย่อย. เช่น, base_news.html, base_sports.html. โดยสืบทอดมาจาก base.html นั่นรวมถึง styles/design.
สร้าง template’s ตามมาอย่างใจต้องการ news blog ect.
สะดวกและง่ายดาย ประหยัดโค้ด.
นี่เป็นเคล็ดลับเล็กๆน้อยๆในการสืบทอด template’s :
ถ้าคุณใช้ {% extends %} มันจะต้องเป็น tag แรกใน template’s นั้น
เราสามารใส่ {% block %} tags ใน base template เท่าไรก็ได้ และเรายังสามารถเพิ่มเติมมันใน child template’s ภายหลัง
ถ้าเจอเนื้อหาซ้ำๆกัน, เป็นไปได้ว่าคุณย้ายมันไปไว้ใน parent template หรือเปล่า.
เพื่อให้อ่านง่าย กำหนดชื่อใน {% endblock %} tag. เช่น:
{% block content %}
…
{% endblock content %}
ด้วยเทคนิคนี้ ทำให้มั่นใจได้ว่า {% block %} tags ถูกปิดเรียบร้อยแล้ว.
สุดท้ายนี้, คุณไม่สามารถกำหนด {% block %} tags ที่มีชื่อเหมือนกันใน template’s เดียวกันได้เพราะนอกจากคุณจะงงแล้ว โปรแกรมก็จะงงด้วย.

Automatic HTML escaping

เวลาที่สร้าง HTML จาก templates, มันมีความเสียงที่จะพบตัวอักษรที่ส่งผลให้การแสดงผล HTML ผิดพลาด. ลองดูตัวอยางจากโค้ดด้านล่างนี้:
Hello, {{ name }}.
ดูเหมือนจะปลอดภัย แต่จะเกิดอะไรขึ้นถ้า user กรอกข้อมูลต่อไปนี้:
<script>alert(‘hello’)</script>
ด้วย username นี้ มันจะถูกเรนเดอร์เป็น:
Hello, <script>alert(‘hello’)</script>
…งานเข้า!! pop-up a JavaScript alert box!
ต่อมา จะเป็นอย่างไรถ้า user ใช้ตัวอักษร ‘<’ อย่างนี้?
<b>username
template’s ก็จะออกมาแบบนี้ :
Hello, <b>username
…งานเข้าอีกแล้ว!! ซวยแล้ว ตัวหนาทั้งเว็บ!
ไม่ดีแน่อย่างนี้ เพราะว่าผู้ไม่ประสงค์ดีบางคนอาจจะให้ช่องโหว่นี้ทำอันตรายต่อระบบได้. นี่เป็นช่องโหว่ของระบบรักษาความปลอดภัยที่เรียกว่าการโจมตีแบบ  Cross Site Scripting (XSS) .
เพื่อแก้ปัญหานี้ เรามีอยู่สองทางเลือก:
อย่างแรก คุณสามารถมั่นใจว่าจะมาสารถแสดงผลข้อมูลเหล่านี้ด้วย escape filter (อ่านด้านล่าง), ด้วยวิธีนี้ คุณสามารถมั่นใจว่าข้อมูลทุกอย่างที่แสดงผล ถูกแปลงไปเป็นข้อมูลที่ปลอดภัย
หรืออีกวิธี, ใช้ความสามารถของ Django ให้เป็นประโยชน์ เราสามารถทำ auto-escaping
โดยทั่วไปแล้ในDjango, ในทุกๆ template จะเปี่ยนให้โดยอัตโนมัติ เช่น:
< เปลี่ยนเป็น &lt;
> เปลี่ยนเป็น &gt;
‘ (single quote) เปลี่ยนเป็น &#39;
” (double quote) เปลี่ยนเป็น &quot;
& เปลี่ยนเป็น &amp;
ย้ำอีกครั้ง, auto-escaping เป็นไปโดยอัตโนมัติ เมื่อคุณเลือก Django คุณจะได้รับการปกป้อง.

แล้วจะปิดยังไง

ถ้าคุณไม่ต้องการใช้งาน  auto-escaped ทั้ง site บาง template หรือตัวแปรบางตัว คุณมาสามารถเลือกปิดได้ตามใจ
ทำไมถึงอยากจะปิดล่ะ? เพราะบางบางที คุณอาจจะต้องการเรนเดอร์ HTML โค้ด,ในกรณีนี้ คุณคงไม่ต้องการ escaped charector. ยกตัวอย่างเช่น บางทีคุณเก็น blob ของ HTML ในฐานข้อมูล และต้องการแสดงผลข้อูลนั้นลงบน template’s  โดยตรง. หรือบางทีคุณอาจจะใช้ Django’s template จัดการ text ที่ไม่ใช่ HTML – อย่างเชน e-mail
สำหรับตัวแปรเป็นตัวๆไป
เพื่อยกเลิก auto-escaping สำหรับตัวแปรแต่ละตัวโดยใช้ safe filter:
อันนี้จะแปลงตัวอักษร: {{ data }}
อันนี้จะไม่แปลงตัวอักษร: {{ data|safe }}
ลองดูตัวอย่างง่ายๆ data มีค่าเป็น’<b>’:
อันนี้จะแปลงตัวอักษร: &lt;b&gt;
อันนี้จะไม่แปลงตัวอักษร: <b>
สำหรับ template blocks
เพื่อจะควบคุม auto-escaping สำหรับ template, หมายถึงทั้ง template’s ใช้  autoescape tag, อย่างนี้:
{% autoescape off %}
Hello {{ name }}
{% endautoescape %}
autoescape tag สามารถเปลี่ยนแปลงได้โดยการเปลี่ยนค่า on หรือ off ในอาร์กิวเมนต์. ลองดูตัวอย่างนี้จะทำความเข้าใจได้ง่ายขึ้น:
โดยปกติแล้ว Auto-escaping จะถูกตั้งค่าเป็น on. Hello {{ name }}
{% autoescape off %}
This will not be auto-escaped: {{ data }}.
Nor this: {{ other_data }}
{% autoescape on %}
Auto-escaping applies again: {{ name }}
{% endautoescape %}
{% endautoescape %}
auto-escaping tag จะทำงานทั้งหน้า รวมไปถึงส่วน include tag,ตัวอย่างเช่น:
# base.html
{% autoescape off %}
<h1>{% block title %}{% endblock %}</h1>
{% block content %}
{% endblock %}
{% endautoescape %}
# child.html
{% extends “base.html” %}
{% block title %}This & that{% endblock %}
{% block content %}{{ greeting }}{% endblock %}
เพราะว่า auto-escaping ถูกปิดอยู่ในbase template, เพราะฉะนั้นมันจึงถูกปิดใน child template ด้วยเช่นเดียวกัน, ผลการรันHTML เมื่อตัวแปรgreeting เป็นอย่างนี้
<b>Hello!</b>:
<h1>This & that</h1>
<b>Hello!</b>

Notes

โดยปกติแล้ว Designer ไม่ต้องสนใจส่วนนี้มากเท่าใดนัก ปล่อยให้เป็นงานของ Developer (ไอ้คนที่เขียนโค้ดบน Pythion นั่นแหละ)เป็นคนคิดว่าอะไรควรจัดการดีกว่า.

String literals and automatic escaping

บ่อยครั้งที่เราใช้อาร์กิวเมนต์ที่เป็น string ในฟิลเตอร์:
{{ data|default:”This is a string literal.” }}
ข้อมูลตรงนี้จะไม่ถูก autoescape.
หมายความว่าควรเขียนอย่างนี้
{{ data|default:”3 &lt; 2″ }}
…ไม่ใช่
{{ data|default:”3 < 2″ }}  <– บัดซบ อย่าเขียนอย่างนี้เด็ดขาด.

เรียบเรียงจาก

The Django template language

แหล่งข้อมูลเพิ่มเติม
Django66
PyThai google groups

This document is licensed under a Creative Commons Attribution-Non-Commercial-Share Alike 3.0 Unported License.

ไปอ่านเจอมา เขียนไว้กันลืม

def primes(n):
"""
primes(n) --> primes

Return list of primes from 2 up to but not including n.
Uses Sieve of Erasth.
"""

    if n < 2:
        return []

    nums = range(2,int(n))
    p = []

    while nums:
        new_prime = nums[0]
        p.append(new_prime)

        for i in nums[1:]:
            if i % new_prime == 0:
                nums.remove(i)
        nums.remove(nums[0])

    return p

หลังจากติดโรคเลื่อน ในที่สุด Django 1.1 หลังจากติดโรคเลื่อนจนผมถอดใจ ในที่สุด Django ก้ได้ปล่อย stable version ออกมาเสียทีเมื่อเช้านี้

โดยรวมๆแล้วมีการเปลี่ยนแปลงที่ชัดเจนคือหน้าตาของ AdminSite โดยเฉพาะ slugField ที่เพิ่มข้อมูลให้อัตโนมัติ ไม่ต้อมานั่งกรอกเองให้เมื่อยตุ้ม

Aggregate ที่เมื่อก่อนทำไม่ได้ ในเวอร์ชั่นนี้สามารถทำได้แล้ว สามารถใช้อะไรอย่าง

>>> from django.db.models import Avg
>>> Book.objects.all().aggregate(Avg('price'))
{'price__avg': 34.35}

หล่อขึ้นเยอะมากเลยทีเดียว

และอีกหลายๆอย่างที่ขี้เกียจเขียน อยากรู้ไปอ่านเองดีกว่าครับ

ส่วนเรื่องภาษาไทยนั้น ผมได้ส่งฉบับล่าสุด โดยมีพี่เทพช่วยตรวจสอบให้ โดยพยายามให้เป็นไปในแนวทางเดียวกันกับ tl10n หลายๆจุดปรับปรุงให้ดีขึ้น ลดความกำกวมไปเยอะ โดยทาง Django ได้ปล่อย stable version หลังจากที่เพิ่มภาษาไทยเพียงสี่ชั่วโมง ฉิวเฉียด หวาดเสียวกันจนหยดสุดท้ายจริงๆ

ยังไงก็ขอให้สนุกกับการพัฒนาโปรแกรมนะครับ

Django 1.1RC ออกมาแล้วเมื่อวันที่ 21 กรกฏาคม ที่ผ่านมา แต่พึงระลึกว่ายังไม่ใช่ตัวหลัก แนะนำว่าอย่าเพิ่งรีบร้อนเอามาใช้ในงานจริง เพราะว่าหากโชคดี คงจะได้เห็นตัวหลักในเวลาอันไกล้

ตอนนี้จะไม่มีการแก้ไขข้อความอะไรเพิ่มตาม หากต้องการจะแปล นี่เป็นโอกาสอันดีแล้วครับ ลุยกันเลย

หากต้องการจะลอง สามารถ DOwnload ได้ที่นี่

เขียนเว็บก็ที่ก็ต้องมานั่งเขียน validate email address ทุกที รำคาญมาก จดไว้ในนี้เสีย จะได้ไม่ต้องเสียเวลาไปค้นอีก

อย่างแรกคือกฎ วุ่นวายสับสนมากมาย ไปอ่านเพิ่มเติมกันเอาเองที่นี่ IETF แต่ถ้าเอาคร่าวๆก็ตามนี้

• Alpha Characters a-z and A-Z (ASCII 97-122 and 65-90)
• Numeric Characters (ASCII 48-57)
• Exclamation Point ‘!’ (ASCII 33)
• Number Sign ‘#’ (ASCII 35)
• Dollar Sign ‘$’ (ASCII 36)
• Percent Sign ‘%’ (ASCII 37)
• Ampersand ‘&’ (ASCII 38)
• Single Quote ”’ (ASCII 39)
• Asterisk ‘*’ (ASCII 42)
• Plus Sign ‘+’ (ASCII 43)
• Minus Sign/Dash/Hyphen ‘-’ (ASCII 45)
• Forward Slash ‘/’ (ASCII 47)
• Equals Sign ‘=’ (ASCII 61)
• Question Mark ‘?’ (ASCII 63)
• Caret ‘^’ (ASCII 94)
• Underscore ‘_’ (ASCII 95)
• Left Opening Brace ‘{‘ (ASCII 123)
• Right Opening Brace ‘}’ (ASCII 125)
• Tilde ‘~’ (ASCII 126)

หลังจากนั้นก็ได้ Pattern ตามนี้

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

ปล. เพิ่งรู้ว่าตัวอักษรประหลาดๆหลายตัวใช้ใน email Address ได้ด้วย

def fact(x): return (1 if x<1 else x * fact(x-1))