Multi-touch? Gesture? how about this???

作者： -
會不會每天接觸電腦，透過開發工具撰寫程式的我們，反而讓電腦世界制約(抑制扼殺)了我們的想像力? 或許，這一切真的有不同的可能性?

留言

承佑表示…
董老師您好
這真是太棒的一場秀，感謝你提供的影片分享，獲益良多，也希望未來能持續多多提供類似的影片。謝謝。
2009年12月29日 晚上11:00
張貼留言

這個網誌中的熱門文章

GitHub Copilot SDK：當你的程式碼有了自己的靈魂

作者： -
圖片
上個月協助客戶做技術評估時，他們的 CTO 會後跟我聊了個問題。 「你知道我們團隊最近在研究把 AI 整合進現有的系統與開發流程…」他闔上記事本(實體，有紙張的那種)，帶著思索的表情說到「你知道的，其實就自動化一些日常任務，像是程式碼掃描、Code Review、各種文件生成、自動化測試、應用程式部署、以及運行狀況檢查…這些。我們一開始看了 OpenAI API、後來也研究過 GitHub Copilot CLI、但最近又出了 GitHub Copilot SDK，老實說，不太確定該選哪個?」 他頓了一下，「還有，開發人員是不是常用一個 GitHub Copilot Agent? 它和 GitHub Copilot CLI 是什麼關係? 我們的開發主管說他每天都在用 GitHub Copilot, 但我不確定這幾個東西到底是不是在做同一件事…」 我打開投影片準備跟他慢慢解釋，心裡想「呵呵，你不是第一個問的…最近有太多人對這些新工具"們"感到困惑。很正常，你沒搞混我才覺得奇怪…」 GitHub Copilot SDK 是啥？ 最近我發現，只要聊到 Copilot，幾乎一定會卡在這個地方。 先講結論：GitHub Copilot SDK 是 GitHub 提供的一套 “開發套件” ，讓開發人員可以在自己的程式裡面整合 GitHub Copilot 的能力。 注意，是 整合 GitHub Copilot 的能力 ，而非在程式碼裡面整合 LLM(大語言模型) 的能力，兩者完全不同。 要在程式碼裡面整合 LLM(大語言模型) 的能力，三年前的 OpenAI API 就可以做到了。 GitHub Copilot SDK 是讓開發人員可以直接利用 GitHub Copilot 的 AI 能力來執行特定任務、調用工具，甚至讓 AI 自己進入一個工作循環，持續執行任務，並且持續改進，直到該任務真正完成。 你應該曾經在 VS Code 裡面用 GitHub Copilot Agent Mode 來產程式碼。那個嚴格來說叫做 Copilot Extension，是安裝在 VS Code、Visual Studio 裡面，自動幫你補全(或生成)程式碼的幫手，也就是現在大部分開發人員已經在用的那個 AI輔助開發工具。(也就是坊間所謂的 AI ...
Read more »

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

雖然可恥但很有用的技術 - ADO Pipeline 客製報表呈現頁面

作者： -
圖片
上禮拜在改 Azure DevOps 的 Pipeline，因為客戶遇到一個很實際的問題。 用戶抱怨，每次 Pipeline 跑完，他們團隊的 PM 和相關人等都跑來問：「這次測試過了幾個？Coverage 多少？部署有沒有成功？Sonar 掃描的報表結果如何?」 苦主耐心地一一回答：「這些資訊都在 Pipeline 的 tasks 裡面啊，你們自己點進去看就好。」 但是，這些大爺們從來不想自己去一個一個 tasks 去點，他們希望有個「一目了然」的整合頁面，能直接看到他們想要的重點數字就好。 『就算我說服了他們，他們也真的自己去看，但沒多久又在 LINE 上問我：那個 Log 到底是什麼意思？這個掃描報告要在哪裡找?』 就這樣『來來回回，他們累了，我也累了。』 苦主無奈地說。 需求很簡單：給我一個摘要頁面就好 大爺們最後跟苦主說：「你能不能幫我們在 pipeline 裡面弄一個 Summary 頁面？我們只要打開就能看到重點數字，不用再去翻那些 log?」 恩恩，我被問到的就是這個… Pipeline 跑完之後，能不能有個漂亮的摘要頁面，一進來就看到重點： 測試通過幾個、失敗幾個、Coverage 趨勢 部署到哪個環境、- 有沒有什麼重要的警告 源碼掃描報告的摘要是如何? 自動化測試結果? 能不能上正式機? … 就這樣。 說的很簡單，要蒐集到需要的資訊似乎也還算容易。 但問題是，要怎麼把這些資訊「塞」進 Azure DevOps 的 Pipeline Summary 頁面？ 然後我發現了個神奇的東西 在翻 Azure DevOps 的文件時，我發現一個很有趣的機制。 你知道那些客製化的 Extensions 是怎麼樣讓你在 Pipeline 的 Summary 頁面看到額外的資訊(例如掃描報告、測試報告)的嗎? 類似底下這樣： 答案可能會讓你傻眼，不是呼叫什麼 REST API、不用設定什麼 Token、也不用安裝套件。 ADO 用的方法超級簡單： 監聽你在 Build Agent 裡面的 console 輸出 。 對，就是 stdout。 你只要在 Pipeline 運行的 script 裡面 echo 一行特定格式的字串： echo "##vso[task.uploadsummary]...
Read more »

你想做什麼?

作者： -
圖片
下課後，有個學員帶著問題走了過來， 戴著一幅黑框眼鏡，看起來就是那種勤奮型的人。 「老師，想請教你個問題」他說，「不知道你怎麼安排時間學習新的技術的? 現在 AI 發展這麼快，每天都有新東西出來。今天這個模型紅了，明天那個工具又說是必學。我根本不知道該從什麼地方開始，感覺永遠追不完…」 我點了點頭，收拾著背包。 這問題，我打從 AI 還沒出現的年代，就被問到現在。 說實在的，這年頭當開發者，挺累。 你打開社群網站，滿滿都是「不學這個你就落伍了」的暗示、 「202x 必學的 10 個技術」讓大家一窩蜂地膜拜新功能，那怕根本不知道那是幹嘛用的。 焦慮感一波一波襲來，搞得你晚上睡覺都不安穩。 但我想告訴大家一個事實： 其實，你永遠學不完的。 真的，別再想了。接受這個事實，你會輕鬆很多。 問題不在「學什麼」，而在「為什麼學」 我反問他：「你為什麼想學？」 他愣了一下，「因為…大家都在學啊。」 (我心想：又來了，面對熊來了，大家都只是想跑得比身邊的人快一些，是吧? 🤔) 大部分人學東西，是因為害怕。怕跟不上，怕被市場淘汰，怕面試被問倒。 所以瘋狂囤課、狂買書、把教學平台的購物車塞得滿滿的。結果呢？買了一堆課，上了5分鐘就放著長灰塵。 其實這不是學習，這是焦慮的發洩出口而已。 教育訓練從販賣知識變成販賣焦慮，我想作者本人應該也不願意吧。 其實，真正有效的學習，永遠從 解決問題 開始。 你現在手上有什麼專案？遇到什麼問題讓你卡關？你想做出怎樣的東西？從這裡出發，你才知道該學什麼。 不是「我要學完 Vue才能開始做專案」，而是「我要做這個功能，所以我得搞懂 Vue 的這個部分」。 差別在哪？前者你可能永遠學不完，後者你今天就能做出東西。 AI時代更要會「選擇」 如今，AI都會能自己程式了，直接 Vibe Coding 就好，還要學什麼？ 不，不是的! AI 越厲害，你越需要知道「該問什麼問題」。你得知道要做什麼、怎麼拆解問題、如何判斷 AI 給的答案對不對。 這些能力，從來都不是靠狂學一堆技術就能培養的。而是靠你真正去 做 、去 踩坑 、去 修bug 累積出來的。 (注意到關鍵字 修bug 了沒，這句是寫給想 Vibe Coding 的同學看的) 我常跟學員說，與其花三個月把一門課從頭到尾看完，不如花十天先做出一個爛爛...
Read more »