เดา iWatch

Submitted by ezybzy on Mon, 2013-07-01 - 13:02

ข่าวลือ iWatch เยอะเหลือเกิน ผมแค่รู้สึกว่ามันคงเป็น Watch ที่เหมาะจะคู่กับ iPhone/iPod touch/iPad มากกว่า

ตามความคิดของผม iWatch จะเป็นนาฬิกาที่สามารถแสดงผลข้อมูลในกลุ่ม Push Notification รวมถึง Widget App บางตัว (เช่น Weather, Stock) หรืออาจจะทำได้ถึงขั้นล้วงดูข้อมูลของ Built-in App อย่างเช่น Message, Contact, Music และอาจจะมี Siri อยู่ในตัว

ลักษณะการใช้งาน เราต้อง Pair มันเข้ากับ iP device (เฉพาะรุ่นใหม่ นั่นก็คือ iPod touch 5, iPhone 4S, iPad 4 ขึ้นไป) อาจจะผ่าน Wifi หรือ Bluetooth ก็ได้ อาจจะมีปุ่มเพียงแค่หนึ่งปุ่ม เพื่อปลุก/ปิด ที่เหลือก็เป็นการใช้งาน Multitouch แบบที่ iPod nano เคยมี เมื่อมีการแจ้งเตือนใดเข้ามา มันจะปรากฏบน iWatch ซึ่งถ้าเป็น App เช่น Message เราอาจจะใช้ Dictation พูดสั่งให้ตอบข้อความได้ทันที หรือสั่ง Siri ให้ค้นหาข้อมูลให้เราได้คร่าว ๆ ก่อนที่อาจจะส่ง Url ไปยัง iP device เพื่อเปิดผ่าน Safari เมื่อเราปลุก iP device ขึ้นมาก็ได้ พูดง่าย ๆ มันจะช่วยให้เราหยิบ iP device ออกมาจากกระเป๋าให้น้อยลงนั่นเอง

สรุปในแง่ Specification มันน่าจะมีจอสัมผัส, มีไมโครโฟน, มี Bluetooth 4 หรือ Wifi อาจจะมี Lightning หรือใช้ที่ชาร์ตร่วมกับ iPod shuffle ไปเลย (แต่มันคงสร้างความสับสนนะ?) ส่วนของ OS คงจะพัฒนาต่อมาจาก iPod nano เป็น OS ที่ไม่ซับซ้อน เน้นรับค่ามาจาก iP device กับส่งค่าต่อกลับไปยัง iP device ไม่มีการประมวลผลที่ซับซ้อน

ฟีเจอร์ประมาณนี้ ราคาซักหมื่นก็น่าจะพอไหวนะ

Blog Tags

การแก้ปัญหาเมื่อ SharePoint ไม่รู้จะใช้ Managed Metadata Service ตัวไหน

Submitted by ezybzy on Tue, 2013-06-25 - 14:30

ใน SharePoint Farm ปัจจุบันมี Managed Metadata Service อยู่ 1 ตัว มีความต้องการว่าเราจะสร้าง Managed Metadata Service สำหรับ Web Application ที่เราต้องการจะศึกษา Cross-site publishing ผมก็เลยทำการสร้าง MMS ขึ้นมาอีกตัว ทำการ Web Application อันใหม่แล้วผูก MMS ตัวนี้เข้ากับ Web Application นั้นโดยไม่ใช้ MMS ตัวเดิม

ปัญหามาเกิดเมื่อเราทำการสร้างไซต์ที่เป็น Product Catalog เมื่อเปิดใน Term Store เราพบว่า ไม่มีการสร้าง Term พิเศษให้โดยอัตโนมัติ ใน Event Log ไม่ได้แจ้งอะไรเป็นพิเศษ แต่ใน ULS เราพบ Event น่าสนใจอันหนึ่ง ซึ่งเกิดขึ้นในกระบวนการสร้าง Site Collection นี้ (ใช้ ULS Viewer ดักค่าตั้งแต่กดปุ่มสร้างไซต์จนถึงหน้าจอที่รายงานผลการสร้างไซต์)

{DATE/TIME} w3wp.exe (0x099C)   0x17E0  Web Content Management  Publishing Provisioning aaub3   High    Failed to add term set Product Hierarchy. Unable to fetch the Term Store of the Site Collection {GUID}

ก็ค่อนข้างชัดเจนว่ามันไม่รู้จัก Term Store แต่จะทำอย่างไรให้มันรู้จักล่ะ? ไปพบบทความของ Jason Lee ซึ่งพบอาการเดียวกันเป๊ะ ก็เลยจัดการตั้งค่าตาม แล้วสร้าง Site Collection ใหม่ ผลลัพธ์ก็ออกมาเป็นดังที่ควรจะเป็น

บทเรียนสำหรับวันนี้คือ นอกจากจะตั้งให้ Permission แก่ Term Store แล้ว เรายังต้องตั้ง Properties ของ Service Application Proxy ด้วย เผื่อเกิดข้อผิดพลาดที่ไม่คาดคิดเช่นนี้

Blog Tags

ปัญหา Farm Solution Deployment ใน SharePoint 2013 เมื่อแยก Role

Submitted by ezybzy on Fri, 2013-06-21 - 16:53

ช่วงนี้ได้มีเวลาพัฒนา Declarative Workflow Action ตามวิธีของ SharePoint 2013

ผมแบ่งผู้ใช้สำหรับติดตั้ง SP_Inst, ผู้ใช้สำหรับต่อฐานข้อมูลหลัก SP_Farm, ผู้ใช้สำหรับ AppPool, WebPool, และผู้ใช้ที่เป็นนักพัฒนา แล้วก็ได้มีการให้สิทธิ์ SPShellAdmin ลงใน Content Database ของ Site Collection รวมถึง Admin Content Database และ SharePoint Configuration Database ด้วย

ไม่แน่ใจว่าเป็นผลจากการแบ่ง Role อย่างเคร่งครัดหรือไม่ที่ทำให้พบเรื่องน่าปวดตับอยู่ได้หลายเรื่องดังนี้

  1. Deploy ไม่สำเร็จ อันนี้ต้องเพิ่ม SPShellAdmin ให้กับฐานข้อมูล AppManagement เพิ่มไปด้วย
  2. Retract Solution ไม่สำเร็จ อันนี้ต้องเพิ่มสิทธิ์บน Admin Content Database นะ
  3. ทำไมมันไม่ยอมติดตั้ง Solution Package อันใหม่ให้เลย! อันนี้ไม่แน่ใจว่าเป็นบั้กหรืออย่างไร แต่มันทำให้เสียเวลามากในการทดสอบ เพราะสิ่งที่ได้ทำแก้ไขไปมันกลับไม่แสดงผลออกมา มาทราบภายหลัง (จากการสังเกต) ว่า อาจจะเป็นบั้กของ Visual Studio วิธีที่ผมแก้คือ สั่ง Deactivate Feature, Retract Solution, Remove Solution เอง (ผ่าน Central Administration, PowerShell แล้วแต่สะดวก) ปิด Visual Studio แล้วเปิดใหม่ ทำการ Build ทุกอย่างใหม่แล้วสั่ง Deploy แล้วก็พบว่าจะได้ Solution Package ตัวใหม่

รู้สึกว่าการยึดตาม Practice ของ Microsoft นี่จะสร้างความวุ่นวายให้กับชีวิตอีกครั้งหนึ่งแล้ว

Blog Tags

ตั้ง eDiscovery บน SharePoint และ Exchange 2013

Submitted by ezybzy on Wed, 2013-06-19 - 11:44

eDiscovery เป็นฟีเจอร์ที่ใช้ค้นหาหลักฐานในองค์กร หลักฐานเช่นไฟล์เอกสาร รวมถึงอีเมล์ที่ใช้สนทนาไปมา เป็นการนำความสามารถของ Search มาใช้งานในอีกขั้น

การตั้งไซต์ eDiscovery นั้นค่อนข้างง่าย แต่การเตรียมตัวก่อนที่จะเกิดไซต์ดังกล่าว ให้พูดตรง ๆ คือก็ลากเลือดพอสมควร หากเชื่อตาม Test Lab Guide: Configure eDiscovery for SharePoint Server 2013 ก็จะพบปัญหาบางประการ เนื่องจาก Step 2 และ 3 เขียนเหมือนกันเป๊ะ แถมหากแยก Account ในการสั่งงานตามข้อปฏิบัติ (แยก Install Account ออกจาก Farm Account) ก็จะพบปัญหาในขั้นตอนการสั่ง Get-SPAppPrincipal เนื่องจากไม่มีสิทธิ์เข้าถึง Database ของ Site Collection ที่ต้องใช้งาน (แน่นอนว่า Error Message ที่แสดงบน PowerShell ไม่ได้บ่งบอกเรื่องนี้ ต้องเปิดดูใน Event Viewers หรือ ULS เอาเอง)

สรุปบทเรียน คือ การตั้งไซต์สามารถทำไปล่วงหน้าได้ทันที ส่วนคำสั่ง PowerShell ที่เหลือทั้งบน SharePoint และ Exchange สามารถทำในภายหลังได้ ในส่วนของ Url ที่ต้องกรอกในช่วง PowerShell นั้น สำหรับทางฝั่ง Exchange ดูจะไม่มีประเด็นให้ต้องเป็นห่วง แต่บน SharePoint ผมก็ยังไม่แน่ใจว่า Site ที่อ้างถึง หากมีหลาย WebApplication เราต้องจัดการกับมันเช่นไร ผมเลยสั่งคำสั่งหลาย ๆ ครั้ง ให้ครอบคลุมกับจำนวน WebApplication ที่เกี่ยวข้องกับเรา แต่ก็ยังพบปัญหาว่าผมสามารถสร้าง Source ได้แค่เพียง Site Colleciton เดียวเท่านั้น

ส่วนฝั่ง Exchange ที่พบปัญหา เจออาการ UPN ของ Account ที่ใช้สร้าง Source ไม่ตรงกับค่า UPN ที่ควรจะเป็นเนื่องจากระบบของเราได้มีการเปลี่ยนชื่อโดเมนไปด้วย ทำให้ต้องไปปรับ UPN ของ Account ให้ถูกต้องเสียก่อนแล้วก็รอรอบการตรวจสอบ Claims ซักพักใหญ่ (รอไป 1 คืน จริง ๆ อาจจะแค่ชั่วโมงสองชั่วโมงก็พอ) หลังจากนั้นก็จะสามารถเพิ่ม Mailbox ที่ต้องการค้นหาลงไปได้

Blog Tags

ทำไมวรรณยุกต์ลอย? แล้วจะแก้อย่างไร?

Submitted by ezybzy on Thu, 2013-06-13 - 19:44

ถามผม ผมก็ตอบไม่ได้หรอกนะ :) แต่ถ้าดูตามวิธีที่ระบบคิด น่าจะได้ตามนี้

โดยปรกติข้อมูลที่เราพิมพ์บันทึกไว้ในระบบมันจะถูกเก็บเป็นรหัสอักษร ซึ่งมีหลายมาตรฐานทั้งแบบ ASCII เดิม จนปัจจุบันก็คือ Unicode สมมติ เราพิมพ์ข้อความ "ใช้ตั้งโต๊ะ" ตัวระบบก็จะบันทึก "ใ ช ้ ต ั ้ ง โ ต ๊ ะ" ไปดื้อ ๆ เลย (ระบบไม่ได้บันทึกข้อความตัวอย่างโดยคำนึงถึงระดับความสูงของวรรณยุกต์) เมื่อต้องนำข้อความมาแสดงผลบนหน้าจอ ระบบปฏิบัติการผ่านทางระบบแสดงผลข้อความจะทำการเลือกอักขระมาจากแบบอักษรเพื่อแสดงผล ณ จุดนี้ ข้อความ "ใช้ตั้งโต๊ะ" นี้อาจจะถูกแสดงผลในรูปแบบที่ไม้โทและไม้ตรีของคำว่า "ใช้" และ "โต๊ะ" ลอยอยู่ในระดับสูงระดับเดียวกับคำว่า "ตั้ง"

แน่นอนเห็นอย่างนี้แล้ว เราก็ย่อมรู้สึกว่า มันไม่เหมือนที่เราเขียนนะ เพราะปรกติเวลาเราเขียน เราจะพยายามวางไม้โทและไม้ตรีไว้แค่เหนือระดับตัวอักษรหรือสระบนเท่านั้น เราคงไม่ได้วางลอย ๆ ไว้แบบนั้น ตรงนี้เกิดเพราะอักขระปริยายของวรรณยุกต์เหล่านี้ เป็นอักขระที่อยู่ในระดับเหนือสระบน (นึกถึงเครื่องพิมพ์ดีดโบราณ) เพื่อที่อย่างน้อยหากไม่มีตัวช่วยอะไรเลย วรรณยุกต์จะไม่ถูกสระบนบัง

ระบบแสดงผลข้อความบางระบบ อาจจะมีความสามารถในการตรวจสอบเงื่อนไขอย่างง่าย เช่น เมื่อทราบว่าตัวอักขระหน้าวรรณยุกต์นั้นไม่ได้เป็นสระบน ระบบจะเลือกอักขระของวรรณยุกต์ที่อยู่ในระดับเหนือตัวอักษรมาใช้แทนที่จะเลือกอักขระของวรรณยุกต์ที่อยู่ระดับเหนือสระบน

แต่เมื่อมันเป็นแค่บางระบบ เมื่อแบบอักษรต้องรองรับระบบอื่น ๆ ก็จำเป็นต้องพัฒนา "อะไรบางอย่าง" ในแบบอักษรให้สนับสนุนวิธีการของระบบที่แตกต่างไปด้วย อย่างเช่นบางระบบความสามารถที่จะตรวจสอบเงื่อนไขเมื่อเจออักขระต่อไปนี้ (a) ตามด้วยอักขระตัวต่อไปนี้ (b) ให้เปลี่ยนการแสดงผลอักษระตัวต่อไปนี้ (b) เป็นอีกตัว (c) แทน

ทีนี้แล้วอะไรคือ "อะไรบางอย่าง"? ในแบบอักษรยุคใหม่ มันไม่ได้มีแค่อักขระอย่างเดียวแล้ว แต่มันยังมีความสามารถพิเศษที่สามารถเขียนสั่งแนบไปได้ เพื่อช่วย "ระบบแสดงผลข้อความ" ให้สามารถแสดงผลออกมาได้อย่างเหมาะสม อย่างของ OS X มีสิ่งที่เรียกว่า AAT (Apple Advanced Typography) เป็นส่วนเสริม หรืออย่างระบบอื่น ๆ ที่สนับสนุน OpenType เต็มรูปแบบก็ใช้งานความสามารถตามข้อกำหนดของ OpenType ได้เลย (รู้สึกจะเรียกว่า Ligatures นะ)

ทีนี้คงจะเป็นมุมมองที่ว่า เราจะยึดระบบ หรือจะให้ระบบหมุนรอบแบบอักษรแทน ถ้าไม่อยากให้วรรณยุกต์ลอย เราจะแก้ระบบให้มันสอดคล้องกับแบบอักษร หรือเราจะแก้แบบอักษรให้มันเข้ากับกระบวนการวิธีคิดของระบบล่ะ?

ส่วนกรณีบางแบบอักษร เช่น Thonburi บน OS X มีปัญหากับไม้ตรีระดับเหนือสระบน อันนั้นเป็นความชุ่ยของคนทำอักขระไม้ตรีระดับเหนือสระบน เนื่องจากได้กำหนดระดับความสูงของอักขระดังกล่าวต่ำเกินไป ซึ่งใช้เวลาอยู่หลายปีกว่า Apple จะปล่อยแบบอักษรที่ได้แก้ไขเรื่องนี้ออกมาให้เราใช้งาน ซึ่งจะว่าไปก็ไม่ได้เกี่ยวกับเรื่องด้านบนเท่าไร เพราะแบบอักษร Thonburi มี "อะไรบางอย่าง" ที่ทำให้สามารถแสดงวรรณยุกต์ไทยในข้อความภาษาไทยได้อย่างถูกต้องอยู่แล้ว

เมื่อก่อน Apple ใช้วิธีแก้ปัญหา Thonburi ด้วยการ "ดึงวรรณยุกต์" ผ่านโปรแกรมจัดการสิ่งพิมพ์ ซึ่งก็นับถือเลยว่าทนทำมาได้อย่างไรเป็นปี ๆ แทนที่จะแก้แบบอักษรให้ถูกต้องทีเดียวเรื่องก็จบแล้ว :)

Blog Tags

จับ SharePoint Workflow 2013 มาชนกับ User Profile

Submitted by ezybzy on Mon, 2013-06-10 - 20:57

ได้รับความต้องการสนุก ๆ มาข้อหนึ่งในการทำ SharePoint Workflow 2013 นั่นคือ มันต้องหา Manager ของ User ที่เป็นคนสร้างเอกสารให้ได้ เพื่อขออนุญาตทำกิจกรรมบางอย่าง (สร้าง Task ให้ Manager นั่นเอง)

ตอนแรกก็คิดว่าถึงคราวที่จะต้องขุด REST API ของ SharePoint ขึ้นมาผสมกับ Call Web Service ซึ่งเป็น Action ใหม่ใน SharePoint Workflow 2013 แล้วก็เป็นเช่นนั้น แต่หนทางมันกลับไม่ได้ง่ายอย่างที่คาด

จากบทความ Work with user profiles in SharePoint 2013 มองดูรอบ ๆ มีตัวอย่างหนึ่งที่เราใช้ได้เลยนั่นก็คือ

REST: GET http://<siteUri>/_api/SP.UserProfiles.PeopleManager/GetUserProfilePropertyFor([email protected],propertyName='PreferredName')[email protected]='domain\user'

ทำการแก้ไขนิดหน่อยเปลี่ยนจาก PreferredName เป็น Manager แทน แต่ทีนี้ปัญหาที่พบก็คือ url ด้านบนนี้ โดยค่าปริยายผลลัพธ์ที่ SharePoint จะตอบกลับมาจะเป็น XML ซึ่งไม่สามารถนำมาใช้ต่อบน SharePoint Designer Workflow ได้

เราจำเป็นต้องปรับเปลี่ยนนิดหน่อยโดยการปั้น Request Header เพิ่มเข้าไปเพื่อบังคับให้ผลลัพธ์ที่ตอบกลับมาเป็น json ตามแบบที่ Action ตัวนี้คาดหวังไว้ วิธีการตามที่ Serge Luca ได้อธิบายไว้ใน Calling the SharePoint 2013 Rest API from a SharePoint Designer Workflow นั่นคือ ใช้ Action ชื่อ Build Dictionary สร้าง Dictionary ที่มีคีย์และค่าดังนี้

Accept : application/json;odata=verbose
Content-Type : application/json;odata=verbose

พรุ่งนี้มาดูผลว่า จะได้ตามที่ Luca แนะนำไว้หรือไม่ ยังไม่พอครับ ต้องมี header พิเศษอีกตัวนั่นคือ Authorization (ดู Kevin.Talbot) แล้วก็จะมีประเด็นอีกเรื่องคือ Login Name ที่ได้มามันไม่ใช่ full domain แต่กลายเป็น claim แทนซึ่งมีปัญหาตรง # ซึ่งอาจจะต้องแก้ให้เป็น %23 แทน

เมื่อเราใช้ Action ชื่อ Get Item from Dictionary ดึง Manager ออกมาแล้วจากผลลัพธ์ของ Call HTTP Service จะพบว่ามันอยู่ในสภาพ domain\username ทำให้ต้องใช้ Replace String เปลี่ยน \\ เป็น \ แล้วเมื่อจะนำไปใช้ในการสร้าง Task หรือแม้แต่การตรวจสอบ User จำเป็นต้อง Cast ค่าให้กลับมาเป็น Login Name อีกหน มิเช่นนั้น Workflow อาจจะถูก Suspended ได้

ออ นอกจากนี้ยังมีตัวอย่างการทำ POST เข้าหา REST เช่นกัน ดูตัวอย่างของ Borislav Grgić ก็สามารถนำไปทำกิจกรรมบางอย่างได้ แต่ทั้งนี้ก็ขึ้นกับสิทธิ์ของคนสั่ง Workflow นั่นเองว่าจะสามารถทำได้หรือไม่

Blog Tags