你大概已經知道微軟準備釋出Mango了,前天微軟開了記者會,昨天連台灣的新聞播報了不短的時間(不過不少新聞是做成芒果挑戰蘋果之類的詭異比較...)。
微軟說芒果這個新版的Windows Phone 7作業系統有超過500項新的功能,上千個API可以讓開發人員使用,那到底有那些東西呢? 我們在發表會後立刻下載了新版(7.1 beta)的 SDK+模擬器(對,正式的芒果恐怕要秋天才能吃到)進行了 firs look test...
初步的嘗試,測試了模擬器的重要更新,錄成了底下的影片,沒有聲音,大家慢慢安靜欣賞...
http://MediaServer1.studyhost.com/Video/WP7/Mango7.1/MangoFirstLook.wmv
我寫了三個測試App, 主要是,你會看到底下功能:
1.原生的中文輸入(手寫尚未出現)
2.模擬器支援accelerometer,可以模擬手機的傾斜度狀況
3.模擬器支援GPS,可以模擬手機的移動(這個有趣)
4.支援多工可以在手機上切換多個App(多工的部分模擬器還沒有100%支援,UI有點小醜)
模擬器的新功能讓開發人員可以更方便的測試你的App, 整個方便不少, 晚一些再介紹一些重要的API...
7.1 beta版的SDK在這裡...
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=77586864-ab15-40e1-bc38-713a95a56a05&displaylang=en
enjoy it...
分享
2011年5月26日 星期四
2011年5月12日 星期四
在IIS上設定WCF Services VS 不讓小問題搞死你
前陣子,委外的廠商開發了一個.svc的WCF Services,佈署到我們的新機器上之後,怎麼也跑不起來,直接瀏覽時會出現錯誤訊息,廠商先前都沒有用過WCF Services技術開發過.svc服務,在開發環境VS2010當中確實都可以運行沒有問題,因此這個Issue又觸礁無法解決...
我們接洽的這位同事很可愛的在網路上找了這篇:
http://technet.microsoft.com/en-us/library/dd632554.aspx
然後也設定了MIME,結果服務終於在瀏覽器上不會出錯,但卻根本沒法呼叫,只會出現blank text page, 因此我重新看了一下IIS的環境,最後執行底下指令:
"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" /i
就這樣,搞定!
原因當然是Windows Communication Foundation並沒有在IIS當中正確的建立 Metabase, 使得服務無法透過IIS給叫起來。
過去我們的合作廠商和同事(都是developer background),都在Hosting(或是Windows Azure)上架設網站,那些環境都是別人已經準備好的,所以當然不會有問題。然而卻從來沒有自己從頭到尾架設一個Windows Server,因此在最基本的問題上觸礁,且花了不少時間,直到客戶直接問我,為什麼環境架設那麼久,一直架設不好,回頭找員工討論,才知道卡在這個問題上。
員工知道這一定是一個可以解決的問題(不然其他Server怎麼可以run?),因此想自己解決,也不問身邊其他同事(怕被笑?),但又因為身上還有其他工作,所以這個問題就懸了快一周,一周的時間就這樣過去不打緊,對客戶來說他反映出來的是服務品質和效率,當我知道了之後覺得很遺憾,因為短短一行指令就可以解決的問題,卻讓客戶等了好幾天...
檢討這個狀況,發現基礎常識的不足,和資訊的不透通是最主要的原因,IT產業常常碰到很多的問題,每一個開發人員和IT技術人員每天都在處裡各式各樣的問題,一個問題處理完畢之後,能夠有log是最理想的狀況,但往往這些經驗是很難留在公司裏面(問題解決了很爽,寫Log卻很煩,先喝杯咖啡去,Log...再說吧),而一個問題呈現出來的現象和狀況可能有多種面向,有時候也不那麼好歸類。
但最最最糟的狀況是,某一個關鍵問題卡在一個人身上,在開會、Review進度時都沒有提出(或提的很模糊,沒人聽得懂,提的人也希望趕快跳過,不想被challenge),然後卡在某個人身上一直無法解決(他也不是懶惰,而是一直找不到方法),結果變成整個專案的瓶頸,這很冤枉,也很划不來...,明明是一個可以被處裡甚至被防範的簡單小問題,卻造成進度的落後。
後來,針對這個現象,我們訂出了工作準則,並且透過資訊系統,要求員工在手上的待處理問題,如果超過一定時間沒解決(或是根本不知道該怎麼解決),必須登入在員工每日工作的系統(EIP Portal)上, 讓這個問題公開,讓其他有經驗的同仁或他的主管,可以出手介入或施予援助。(管理單位也可以從這些Issue List上,推敲出目前專案的狀況)
每一個人都不是全能的,資訊領域那麼大,大家各自有擅長的技術,彼此幫忙解決問題,才是我們想看到的結果,因為特定領域不熟悉,甚至羞於尋求幫助,並不是我們想鼓勵的文化,我們沒有讓每一位員工很忙,也是因為希望能夠多一些時間彼此幫忙。另一個有趣的現象,你會慢慢地發現,團隊中最有人緣或最有領導力的,常常是那個對其他人施予幫助的,而非技術能力最強的人。
分享
我們接洽的這位同事很可愛的在網路上找了這篇:
http://technet.microsoft.com/en-us/library/dd632554.aspx
然後也設定了MIME,結果服務終於在瀏覽器上不會出錯,但卻根本沒法呼叫,只會出現blank text page, 因此我重新看了一下IIS的環境,最後執行底下指令:
"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" /i
就這樣,搞定!
原因當然是Windows Communication Foundation並沒有在IIS當中正確的建立 Metabase, 使得服務無法透過IIS給叫起來。
過去我們的合作廠商和同事(都是developer background),都在Hosting(或是Windows Azure)上架設網站,那些環境都是別人已經準備好的,所以當然不會有問題。然而卻從來沒有自己從頭到尾架設一個Windows Server,因此在最基本的問題上觸礁,且花了不少時間,直到客戶直接問我,為什麼環境架設那麼久,一直架設不好,回頭找員工討論,才知道卡在這個問題上。
員工知道這一定是一個可以解決的問題(不然其他Server怎麼可以run?),因此想自己解決,也不問身邊其他同事(怕被笑?),但又因為身上還有其他工作,所以這個問題就懸了快一周,一周的時間就這樣過去不打緊,對客戶來說他反映出來的是服務品質和效率,當我知道了之後覺得很遺憾,因為短短一行指令就可以解決的問題,卻讓客戶等了好幾天...
檢討這個狀況,發現基礎常識的不足,和資訊的不透通是最主要的原因,IT產業常常碰到很多的問題,每一個開發人員和IT技術人員每天都在處裡各式各樣的問題,一個問題處理完畢之後,能夠有log是最理想的狀況,但往往這些經驗是很難留在公司裏面(問題解決了很爽,寫Log卻很煩,先喝杯咖啡去,Log...再說吧),而一個問題呈現出來的現象和狀況可能有多種面向,有時候也不那麼好歸類。
但最最最糟的狀況是,某一個關鍵問題卡在一個人身上,在開會、Review進度時都沒有提出(或提的很模糊,沒人聽得懂,提的人也希望趕快跳過,不想被challenge),然後卡在某個人身上一直無法解決(他也不是懶惰,而是一直找不到方法),結果變成整個專案的瓶頸,這很冤枉,也很划不來...,明明是一個可以被處裡甚至被防範的簡單小問題,卻造成進度的落後。
後來,針對這個現象,我們訂出了工作準則,並且透過資訊系統,要求員工在手上的待處理問題,如果超過一定時間沒解決(或是根本不知道該怎麼解決),必須登入在員工每日工作的系統(EIP Portal)上, 讓這個問題公開,讓其他有經驗的同仁或他的主管,可以出手介入或施予援助。(管理單位也可以從這些Issue List上,推敲出目前專案的狀況)
每一個人都不是全能的,資訊領域那麼大,大家各自有擅長的技術,彼此幫忙解決問題,才是我們想看到的結果,因為特定領域不熟悉,甚至羞於尋求幫助,並不是我們想鼓勵的文化,我們沒有讓每一位員工很忙,也是因為希望能夠多一些時間彼此幫忙。另一個有趣的現象,你會慢慢地發現,團隊中最有人緣或最有領導力的,常常是那個對其他人施予幫助的,而非技術能力最強的人。
分享
訂閱:
文章 (Atom)
熱門文章
-
關於 .net core的登入與身分驗證方式 前情提要… 前幾天,我們示範了如何在 .net core 環境下,使用 cookie-based authentication 來實現登入與身分驗證功能。這個做法是從 .net framework以來就有的,也是延續到 .net...
-
前面 我們討論到了很多跟Line Bot有關的機制,但有朋友提了一個問題,如果我單單只是要透過程式碼發訊息給用戶,一定要申請並建立一個Line Bot嗎? 其實不用。 一直以來,有一個比較不被重視的機制,叫做LINE Notify,其實它已經誕生很久, IFTTT 的Line...
-
LINE Bot這一系列,從2016年五月開始,寫著寫著也快30篇了,差不多剛好一個月一篇,如果資訊雜誌還在的話,應該可以是一個專欄。 很久沒有整理索引了,2019年初,再次將這一系列相關連結整理如後: 使用C#開發LineBot (1) - 用c#建立一個LineBot...
-
Windows 8, 一幅蓄勢待發的姿態。 在最近一兩個月,微軟全省跑透透,辦了多場介紹Windows 8的研討會,也陸續的在網路上大方的提供了Windows 8先前的Developer Preview以及最近的Consumer Preview版本讓大家免費下載。 過去段...
-
新版的Line Messaging API,要主動發送訊息給用戶不是很困難,主要是透過Push API,可以參考底下的官方說明 : https://devdocs.line.me/en/#push-message 另外,如果你想申請一個Line Bot,可參考: 關於LineB...
-
當許多用戶開始使用 LINE Notify 之後,就會發現它真是一個方便好用的機制。 他的推播速度不亞於使用Messaging API的Push Command,甚至我覺得在群發上有更高的彈性與控制自由度。我們只需要得到用戶的Token,就可以輕易的透過HTTP POST發訊息給...
-
最近的 Line Notify 、 Line Login ,以及前一陣子的 Microsoft Graph API ,全都使用到了OAuth作為用戶身分驗證以及資源存取的基礎。但很多讀者會卡在OAuth的運作流程上,根本的原因是不理解OAuth到底是幹嘛的?其存在的目的為何?以及...
-
注意,本篇部分內容已過時,新版Line bot申請流程,請參考 這篇 。 前面 說過,不知道發生了什麼事情,全球幾個大廠幾乎在同一個時間announce各家的機器人技術或介面,包含Microsoft 的bot API,還有FB、Line…到最近的Google,總之突然間,原本封...
-
其實我們在好幾年前,就已經談過DI(Dependency Injection)這個主題。當時這類議題被視為進階的開發概念,但如果你最近開始使用 .net core,大概已經發現DI如今已變成.net core中的基本要求。 事實上,從事教育訓練這麼多年的觀察下來,不難發現其實還是...
-
如果你申請好了新版的Line Messaging API帳號。(申請位置位於 https://business.line.me/zh-hant/services/bot ),就可以建立一個Line對談機器人了,你要讓你的Line機器人能夠透過程式來回覆用戶的訊息,那關鍵當然是底下...
