ปัจจัยในการเลือกผู้ว่า กทม

ใกล้เลือกตั้งผู้ว่าฯ กทม. เข้ามาทุกที ก็เลยเขียนไว้ว่าเราจะมีหลักในการเลือกผู้ว่าอย่างไรบ้าง
  • นโยบายของแต่ละคน อันนี้สำคัญที่สุด ผมไม่ได้เลือกเพราะชอบคนนี้ หรือพรรคนี้ หรือปากคนนี้ สำคัญที่นโยบาย ต้องตรงตามกับความต้องการมากที่สุด
  • ขอบเขตและอำนาจผู้ว่าฯ เท่าาที่รู้มาคือผู้ว่าฯ กทม. ก็ไม่ค่อยมีอำนาจเท่าไหร่ เช่นถนนบางสายเป็นของกรมทางหลวง(วิภาวดี,สุขุมวิท,เพชรเกษม) ส่วนใหญ่ก็เป็นของกระทรวงคมนาคม และส่วนนอกเหนืออีกเช่น ตำรวยหัวขวด, BTS, MRT, แม้กระทั่ง ขสมก มันเลยไปกำหนด ข้อที่3
  • Intersect between นโยบายกับขอบเขตอำนาจ ผลลัพธ์ที่ได้คือ สิ่งที่ทำได้จริง
  • ลักษณะการดำเนินนโยบาย พูดง่ายคือ action กับสิ่งที่พูดมายังไง อย่างพวกรับปากพล่อยๆ รถไฟเลียบคลอง (สมัยนั้นพ่อก็ไปลงให้) พอทำไม่ได้ก็โยนไปนู่นโยนไปนี่ ผมอยากได้ไม่ใช่คนรับผิดชอบ ผมอยากได้วิธีการแก้ปัญหา
  • ดูจากผลงานที่ผ่านมา ถ้าใครไม่มีให้ดูประสพการณ์ชีวิต มีบางคนเคยเป็นผู้ว่ามาลงซ้ำ ก็ให้ดูผลงาน แต่ต้องแยกแยะว่าบางอย่างที่เขาอ้างก็ไม่ได้อยู่ในขอบเขตอำนาจของเขา มันเพียงแค่อยู่ใน กทม เท่านั้น ส่วนคนอื่นๆก็ลองดูชีวิตต้องต่อสู้ยังไง ประสพความสำเร็จยังไง แนวทางการดำเนินชีวิตเป็นยัง ปรัชญาในการทำงานเป็นอย่างไร แล้วทั้งหมดนี่ใช้สมองกรองออกมามันตรงตามความต้องการไหม
  • ตัด poll ออกจากหัว ตัดการโฆษณาออกจากหัว ตัดอคติออกจากหัว และที่สำคัญ อย่างเอาการเมืองระดับชาติ มาเป็นองค์ประกอบในการเลือกตั้งการเมืองท้องถิ่น
สิ่งที่สำคัญกว่าการหาตัวคนผิด คือการรับมือกับปัญหาที่มันเกิดขึ้น ผมมีความเชื่อว่าเราไม่สามารถบังคับไม่ให้เกิดปัญหาได้ (cannot avoid problem) แต่เราสามารถรับมือกับปัญหาได้ (handle a problem) ทุกปัญหามันมีทางแก้ (solved problem) เพราะฉะนั้นรู้จักอยู่กับปัญหา (live with problem) แล้วปัญหามันจะไม่น่ากลัว
Published on Tue, 16 Sep 2008 14:01
0 comments

resize + unsharp-mask little by little

พี่แสนเคยบอกไว้มานานแล้วว่า เวลาย่อรูปเนี่ยเราไม่ควรย่อลงไปให้ได้ขนาดในทันที เช่น จาก 100% ไปเป็น 50% เราคววรจะแบ่งการย่อทีละนิดๆจาก 100% ไปเป็น 75% แล้วค่อยย่อจาก 75% ให้ได้ 50% หลังการย่อแต่ละครั้งให้ทำ unsharp-mask ด้วยจะทำให้ภาพคมขึ้นและดูสวยงาม
My brother SAN told me long time, when I have to resize, I should not resize to aspect ratio immediately such as 100% to 50%. I have to resize little by little from 100% to 75% then resize from 75% to 50 . Then after each resize process, it should be applied unsharp-mask filter. I will make more sharpen.
ผมก็เลยเขียนเพิ่มให้มันเป็นการแบ่งครั้งที่จะทำการ resize ได้ดังนี้
SHARPEN.times do nphoto = photo.resize(NEWSIZE**(1.0/SHARPEN)) photo = nphoto.unsharp_mask end
ดูได้จากภาพตัวอย่าง ได้ที่ multiply
Published on Wed, 10 Sep 2008 16:01
0 comments

Ruby Fork

จากครั้งที่แล้วผมอยากจะเขียน ruby สักอันไว้ทำการ stamp ลายเซ็นพร้อมค่า exif ลงในรูป จากการลองเขียนเป็น thread แล้วปรากฏว่าไม่ค่อยมีประโยชน์เท่าไหร่กลับกลายเป็นว่ามี overhead ขึ้นมาเพียบและก็ทำงานไม่ครบได้ทุก core ที่มี งานส่วนใหญ่ในการทำงานเกี่ยวกับภาพนี่จะเป็นในด้านคำนวนซะเยอะ เลยเขียนเป็นลักษณะ fork ออกมาจะดีกว่า
พอลองได้เขียนก็ได้แนวคิดมา 2 แบบ คือ
  • ทำงานแบบเป็น lot คือทำพร้อมกันที่ละเท่าๆกัน แล้วรอให้เสร็จหมด ค่อยเริ่ม lot ต่อไป แบบนี้ถ้ามี process ใน lot เสร็จก่อนเพื่อนก็ต้องรอ
  • แบบที่สองคือเริ่มทำงานให้เต็มตามที่เรากำหนด ถ้า process ไหนเสร็จก่อนก็เอา process ใหม่มา run ได้เลย แบบนี้จะทำให้การทำงานต่อเนื่อง
แบบนี้คือการทำงานแบบเป็น Lot NUMFORK = 2 getImg = Dir['*.jpg','*.JPG','*.Jpg','*.jpeg'].sort.reverse Dir.mkdir("stamped") if !File.exist?("stamped") numFork = 0 while !getImg.empty? numFork = numFork + 1 photo = getImg.pop Process.fork{stampit(photo)} if numFork == NUMFORK Process.waitall numFork = 0 end end Process.waitall ส่วนแบบนี้คือการทำงานแบบต่อเนื่อง NUMFORK = 2 getImg = Dir['*.jpg','*.JPG','*.Jpg','*.jpeg'].sort.reverse Dir.mkdir("stamped") if !File.exist?("stamped") numFork = 0 while !getImg.empty? numFork = numFork + 1 photo = getImg.pop Process.fork{stampit(photo)} if numFork >= NUMFORK Process.wait numFork = numFork - 1 end end Process.waitall อย่างนี้ก็สบายใช้งานคุ้มทุก core
Published on Thu, 04 Sep 2008 16:29
0 comments

My Failure with Ruby Multi-Thread

คือว่าผมใช้ debian + ruby + rmagick เขียน script เพื่อที่จะทำการ stamp รูป แต่มาได้ความคิดว่า อย่าง convert เนี่ย ถ้าเราเรียก $ convert -resize 1600 *.jpg มันจะใช้ cpu 1 core เต็มๆ แต่อีก core จะชิวๆ หรือไม่ทำงานยุ่งเกี่ยวกับ convert เลย ก็เลยลองให้มันทำ $ convert -resize 1600 *[02468].jpg & $ convert -resize 1600 *[13579].jpg & ผลลัพท์ที่ได้คือมันใช้ 2 core ทำงาน เป็นเพราะ shell เรียก convert นี่เป็น native ซึ่งมันจะไปทำงานแบบ fork จึงได้ผลลัพทธ์ดังกล่าว จากที่อ่านมา Fork คือ Heavy Weight Process ที่แยก resource กันชัดเจน ส่วน Thread คือ Light Weight Process ที่แบ่งปัน resource ซึ่งกันและกัน แต่ปัญหาอยู่ที่ว่าคือผมเขียน ruby คิดว่าถ้ามันเป็น thread ก็จะน่าได้ผลลัพธ์เช่นเดียวกับการ fork 2 ครั้ง แต่ผลลัพธ์ที่ได้กลับกลายเป็นว่า การทำงานนั้นไม่เต็ม 2 core คือใช้เพียงแค่ 1 core เท่านั้น จากการศึกษาเพิ่มเติมได้ผลออกมาว่า thread นั้นมี 2 แบบคือ user space และ kernel space
  • Kernel space จะเป็น thread แบบ native คือ kernel จะเป็นผู้จัดสรรและสับเปลี่ยน ก็จะได้ประสิทธิภาพตามคุณภาพของ kermel + cpu
  • User space หรือเรียกอีกอย่างว่า Green thread คือ thread ที่ทำงานแบบ time slice โดยผู้รับผิดชอบคือ VM (Virtual Machine) ในกรณีของผมคือ ruby นั่งเอง VM จะทำหน้าที่จัดสรรและสับเปลี่ยน เสหมือนเป็นการจำลอง thread อีกที ผลที่ได้คือ kernel เห็นเป็นเพีบง singel thread จึงทำงานได้เต็มที่แค่ 1 core
สรุปได้ว่า thread บน ruby นั้นป็น green thread จึงได้ผลลัพธ์ดังกล่าว ทางแก้ตอนนี้คือเขียนให้ ruby นั้น fork อีก process ไม่ใช่ว่า ruby thread จะไม่มีประโยชน์ ไว้จะลองเขียน ประโยชน์ของ ruby thread ดู
Published on Wed, 03 Sep 2008 16:57
0 comments

RSS