Faryne的程式設計館

你就直接把 Assistant 當成你在 ChatGPT 看到的那些 GPT 玩具吧（？）， 只是你可以透過 Assistant API 透過程式化來建立你的 GPT 並與你的網站功能結合。 雖然前面說了「用 Assistant API 」，但實際上其實需要以下三個類型的 API 相互結合才能生出一個 Assistant： Assistants API ：設定給助手（？）的指示內容、要使用的模型等資訊。在絕大部分場合下，你通常只需要呼叫一次 Assistant 的 Create 方法一次，此後就可以把回傳的 id 記錄下來後用在其他地方。 Threads API ： 建立對話串，這個對話串會與前述的 Assistant 相互結合，讓 Assistant 知道要在這個 Thread 開始監聽訊息，並針對指示做出相應的回覆。 Messages API ：將使用者輸入的訊息送到 Thread Runs API ：使用者送出訊息後，就要呼叫 Create Run ，讓後端知道有工作要做了 以下是其流程： 先呼叫 Assistant API 的 Create ，記得要拿到回傳中最重要的 id ，這會在接下來的步驟中使用到。如果沒什麼特殊狀況的話你可以把這個 id 持久化保存，之後就不用再重做一次這個步驟。 接著 建立一個新的 Thread ，並取回其中回傳的 id。這個步驟你可能會因應不同的使用的而需要頻繁產生。 以上兩個步驟完成後，接著就可以： 建立一條新的 Message ，並將使用者輸入的內容發送至剛才建立的 Thread 中（透過之前建立 Thread 成功所得到的 id） 接著 呼叫 Run API 的 Create ，將建立 Assistant 與 Thread 成功時所取得的 id 帶入後，就會開始根據使用者輸入的內容開始做分析處理。若是忘記呼叫這個 API 你會發現怎麼內容輸入了但卻沒有任何回應。 然後就可以定期去 呼叫取得 Run 資訊的 API ，看看是不是已經處理完畢。只有在 status 是 completed 時，才代表執行完畢。 執行完畢後，就可以 透過 Message API 取得訊息 。 看吧，很簡單吧？ ㄍㄋㄋ，官網沒寫詳細用法只有提供 endpoint 資訊。害我先按照自己的想法寫出一個雛形發覺怎麼跑不起來一邊確認一邊問 ChatGPT...

前篇提到 Stable Diffusion WebUI， 這次要利用 Google Colab 服務來跑這玩意。 主要流程其實很簡單： 如果還沒有下載模型檔的話， 請先打開主要作業的區塊執行開啟 Google Drive 的權限， 然後再到第三個大區塊中的下載輸入模型檔下載路徑， 下載完成後就可以開始下載 Stable Diffusion WebUI 並準備執行。 如果已經執行過下載模型的話， 可以直接按下主要作業那個大區塊中的執行即可。 當不想玩了以後，請記得按下第二個大區塊的執行。 這個步驟會把該次產生的圖片存回到 Google Drive 內。 網址： https://colab.research.google.com/drive/1irIstg03GHVtXJLVhYLOtNuUy3z7ELz_?usp=sharing

A.I. 當道後， 什麼以文生文、以文生圖、以文生聲（？）等玩意陸續蹦出來。 別的先不說， 光是以文生圖就有像是 MidJourney 還是 Dall-E 等模型提供相關服務。 而後 NovelAI 自爆自己的以文生圖模型是透過 Danbooru 上收集的圖片所訓練， 外加相關程式碼也不小心外洩後， 你各位紳士們就開始在以文生圖這塊領域中尋找自己的婆了。 不過以上都不是重點， 本文只是想要記錄下 Stable Diffusion WebUI （以下簡稱 SDWebUI）的架設步驟而已。 其實安裝步驟出乎意料的簡單（當然是指在 Google CoLab 上）， 只要以下幾個步驟，基本上就能把 SDWebUI 跑起來並且開始生圖： * 確保機器上有 Python 3 以上環境 * 下載 SDWebUI 原始碼，可以直接在 Github 上 clone 下來。 * 下載所需的模型：在產生 ACG 相關圖片的話，目前推薦使用 Anything 或是 Hentai Diffusion 等模型。不過要注意一點：模型檔案越大的話，硬體要求會更高（主要是顯卡的 GPU 和記憶體等級）。如果沒滿足需求的話可能會跑不起來 * 切換到 SDWebUI 目錄，執行以下指令開始跑 SDWebUI 的設定，會在這個步驟安裝其相依的 Python 套件並處理相關設定： COMMANDLINE_ARGS="--exit" REQS_FILE="requirements.txt" python launch.py *  把前面步驟所下載的模型檔案，搬移到 SDWebUI檔案目錄/models，例如 clone 到 /home/user/stable-diffusion-webui 的話，就把模型檔複製到 /home/user/stable-diffusion-webui/models 下。 * 執行以下指令，等待跑完以後，畫面應該會顯示一組 xxx.gradio.xxx 的網址，可以讓自己或朋友連進來玩（網址 72 小時內有效）。如果只是自用的話，也可以用 localhost 的網址開啟服務： COMMANDLINE_ARGS="--share --gradio-debug" REQS_FILE="requirements....

最近因為要把用 Go 寫的一些 API 搬到專用平台跑又不想花錢， 想到 App Engine 有免費方案， 所以看了一下就先搬一兩隻進去跑了一個禮拜後， 昨天好奇瞄了一下帳單後大吃一斤， 發現才跑一個星期就有 16 鎂的帳單！ 再仔細翻一下文件發現這其中的奧秘...... App Engine 分成兩種運作環境， 一為標準，另一個則為彈性。 前者有提供免費方案，依照選擇的類型不同，可能會有一天 28 或 9 個的免費時數可用； 後者完全沒有免費方案，一開下去就立刻算錢。 而我用的正是彈性，所以一開下去就馬上燒錢 Orz 話說回來了，到底標準和彈性環境有什麼差別？ 標準環境的特色： 使用的程式語言版本基本按照 App Engine 要求。以 Go 為例，他該死的就只支援到 1.16 ，想用 1.17 以上的版本，你只能使用彈性環境。 有免費方案（不是重點 運作系統規格只有籠統的 F1 / B1 這種讓你選，就算想要記憶體多一點你也只能選更高的等級。 AutoScaling 只能設定標準由 App Engine 自行控制 想在運作環境裝一些額外的東西嘛......應該是不行。 彈性環境的特色： 可以自己寫 Dockerfile ，所以要什麼東西用什麼語言環境，你自己決定 沒有免費方案（依然不是重點 運作所需的 CPU 核心和記憶體數量可以自訂，只要符合基本要求即可 AutoScaling 機制可以手動也可以自動控制 可以 SSH 登入，想查什麼東西還蠻方便的說 所以你知道為什麼彈性環境沒有免費方案了吧（眼神死 ====================== 不過根據使用和昨天翻文件下來， 我覺得 App Engine 彈性環境遠比 AWS 的 ECS Fargate 更懶人包。 前者只需要專注在程式撰寫和設定所需運作的環境，基本上沒什麼事要做了； 但後者除了上述的東西外， 還需要自己設定從 VPC / Security Group / Load Balancer 等一狗票東西， 老實說還挺麻煩的。 ====================== 不過地雷還是有， 在寫 App Engine 的 app.yaml （運作環境設定檔）時， 關於 auto_scaling 的相關設定必須要特別注意， 如果沒特別宣告的話， 會讓你的服務可能一開始就開出兩個 instance 運作...

通常為了要達成 IaC 的目標， 架構師還是 DevOps 工程師都會用很多工具來達成目標。 而比較通用的工具大概會是 Terraform / Ansible 之類的。 不過實際狀況是因為 AWS 服務眾多反而是使用 AWS 自家工具來做還比較方便。 所以用個表格來比較： 比較表 AWS CDK / CDK For Terraform GoFormation 原生 CloudFormation JSON / YAML 優勢 較為高階，有些細節不用特別處理（例如建立 Subnet 不用自己額外寫 RouteTable 那些東西） 跟程式語言結合，使用起來比較可讀好懂 跟 Terraform 結合的話要學的東西相對比較少一點 最接近原生 JSON / YAML 寫法，但又擁有建立每個資源時很快就可以知道要丟什麼東西進去的優勢 跟程式語言結合，可以做一些靈活變化 原生寫法不解釋 如果有新東西的話通常會第一支援 弱勢 因為太高階，比較細項的修改反而變得很麻煩 老實說，我覺得好像沒什麼弱勢！大概只有部分函式不能用還有需要產生檔案比較麻煩一點 很低階，所以在寫的時候要搭配文件才能知道需要丟什麼東西進去 一不小心會寫出上千行的檔案，也會不小心改錯項目出包

大概是去年聖誕節前夕， 不知道被什麼打到， 突然想考一張 AWS 認證考試， 所以就很突然地報了 AWS Certified Solutions Architect - Associate 的考試！ 為了那場考試我還買了對岸出的翻譯教科書（ 原文版 、 簡體版 ）讀。 只是......因為我真的很不會讀書， 外加我上班真的超懶， 那本書我只看了前面幾章， 然後隨便做了書內的練習題和 Google 到的考古題， 就直接上場考試了！ 雖然是很有驚無險地通過了啦（720 分通過，我考 761 分）..... 然後今年十一月左右也是因為很突然就離職， 所以也是很突然就決定再去報 AWS Certified Solutions Architect - Professional 的考試！ 這次考試比之前稍微認真一點， 除了把那本教科書的後面幾章......的練習題重做外， 也開始狂 K 官方的訓練課程， 外加又多冥想了各種考題方向， 也順便自己開了一些不常用的服務練習（估計帳單也......）， 大概是花了一個星期時間專心（？）準備！ 這次也依然是很驚險地通過（750 分通過，我考 797 分） ====== 以上都是廢話 ===== 其實我去年考的時候還不知道認證架構師是最難的考試， 不過考完架構師考試後， 其實就會理解到 AWS 認證架構師就某種程度是最了解 AWS 架構的人， 如果一間公司全部使用 AWS 服務的話， 這傢伙應該就是部門的 Center ！ 只是有沒有必要考到 Professional 等級就因人而異啦， 畢竟 Professional 級的考題很刁鑽， 遠比 Associate 級更為刁鑽， 除了出現一堆你壓根沒聽過的 AWS 服務外（我看到考題才知道有 EFA 這玩意）， 還需要你從安全面、成本面、可維護性去思考架構該怎麼設計（其實 Professional 級這幾個面向的考題遠比 Associate 多）， 這就很吃使用經驗和你有沒有想過最佳實踐。 如果是半吊子以為只是比 Associate 難一點點就上場去考的話， 保證很容易就會 GG ！ 再次聲明：我真的只是好運考過的 QQ ====== 怎麼準備 ===== 其實不是很建議無謀地只讀教科書就去考！ 最好是先有一段時間的 AWS 操作經驗， 至少要理解 VPC / SecurityGroup...

說到 K8S 喔，就不得不提到那精美的 YAML ， 當你想佈個 Service / Deployment 時， 可能會因為你常打還知道怎麼打出來！ 一旦你要用的元件是不常用的時候， 你應該會很幹的去翻 K8S 官網文件查！ （就跟我之前為了要寫 AWS Cloudformation 時還要翻那該死的文件一樣） 因此 AWS 推出 CDK8S ， 讓你開發時比較不需要花太多時間翻文件！ CDK8S 目前支援 TypeScript / Python / Java， 不過這裡直接用 TypeScript 做個說明好了。 安裝 CDK8S 工具 npm install -g cdk8s-cli 建立新專案 mkdir /helloworld cd /helloworld cdk8s init typescript-app 開始開發 打開專案的 main.ts ，那就是開發的起點了！ 部署 雖然一般都會直覺想到用 npm run build ， 但是實際上這會跑 compile / test / generate yaml 三個動作。 在還沒有寫測試之前，建議直接跑 npm run compile && npm run synth ， 這樣就能直接產生 K8S 所需要的 YAML（在 dist/ 目錄內） 接著輸入 kubectl apply -f dist/* 就可以開始部署到你的 K8S Cluster 上。 感想 老實說，這其實是個還蠻方便的玩意， 除了常用的一堆元件外， 也可以針對各種少見但就是會用到的元件寫自己的宣告（？）， 下次要寫的時候可以提示哪些參數是必須或是該填些什麼， 能夠省下每次翻文件的時間。

AWS 之前推出了 Cloud Development Kit （CDK） 工具， 讓以前寫 YAML 透過 CloudFormation 建立資源的麻煩和不便減少許多， 只是彼時只支援 C#、Java、JavaScript / TypeScript 以及 Python。 不過最近開始支援 Go 了， 所以我就來稍微試用一下！ 為了要使用 CDK Go， 必須確認開發機器上是否有以下工具： aws-cdk ：CDK 工具，可以透過這個工具進行建立新專案 / 部署等動作，最新版本： 1.100.0。 Go ：由於 CDK 會使用到 Go 內建的 embed 套件，所以版本必須為 1.16.x 以上 aws-cdk-go ：CDK 的 Go 函式庫，目前還在 preview 階段，最新版本是：1.100.0 以上工具安裝完後，即可開始建立新專案。 建立新專案 建立一個目錄後並切換到該目錄， 接著輸入： cdk init --language go  然後就會在該目錄下建立出相關的專案檔 開發 使用你習慣的 IDE，打開以該目錄為檔名的 .go 檔， 你所有需要的程式碼即會集中在這裡。 部署 輸入以下指令即可開始部署作業： cdk deploy 輸入以下指令則可以確認這次修改後會有什麼樣的資源變動 cdk diff 輸入以下指令則可以刪除 cdk destroy 注意事項  CDK 有兩種類型的物件： awscdk.NewCfn* 和 awscdk.New* ， 前者是為了仍在使用 YAML 操作重複類型資源的狀況下使用， 只需要帶入模板檔路徑與該模板所需參數即可建立相應資源； 後者則偏向懶人包， 可以在建立資源時一併設定其他相依資源的屬性以便一起建立， 如果未設定的狀況下也會以預設的屬性直接建立。

因為敝社使用了 emqx 這個玩意， 為了測試效能所以找了 emqtt-bench 這個測試工具來用。 結果拉下來後發現還需要 erlang 等一堆折騰人的東西， 好不容易弄完後怕組內有人要用還需要搞同樣的事， 所以就自己打包成一個 Docker Image （雖然 Dockerfile 內容才幾行） Dockerfile 內容： https://github.com/faryne/emqtt-bench-tool

jq 一套可以解析 JSON 內容的工具，基本上還算好用。但在解析層次比較複雜的 JSON 或是要產生 JSON 物件時會非常的讓人想死！ 基本用法： jo jq 雖然可以產生出 json 內容，但其語法各種煩躁。所以就有了 jo 這玩意。 基本用法： yq 這個工具則是可以解析 / 產生 yaml 的工具。 基本用法：

OpenResty 這東西基本上就是把 Lua 和 Nginx 結合在一起做成撒尿牛丸！ OpenResty 這東西基本上就是結合 Lua 和 Nginx 各自的優勢， 讓你可以直接用 Lua 寫程式讓 Nginx 直接執行， 從而避免像是要用 proxy_pass 丟到 node 或是 fastcgi_pass 丟到 PHP 執行這種等等等的狀況。 安裝方式說難也不難，只是要注意一下機器上要有這些東西： make / gcc ：編譯原始碼時需要的工具，有需要的話在 Ubuntu / Debian 可以下 apt-get install -y make build-essential ，這樣就會把需要的編譯工具裝好了。 PCRE：Perl 用的正規式函式庫，這東西基本上裝了會比較方便 zlib：gzip 功能相關。老實說沒想到不裝的理由。沒有的話要下 apt-get install -y zlib1g-dev 上面的準備完成後，可以直接 下載原始碼 ， 用 tar 解壓縮並切換到該目錄後， 就可以直接下 ./configure && make && make install ， 跑完以後 nginx 和 OpenResty 的相關元件就完成安裝了。 不過要補充一下， 上述的指令是按照預設設定安裝 nginx 及相關模組， 其實也可以根據需求在 ./configure 加相應參數來設定 nginx 主程式路徑 / log 路徑， 這部分可以下 ./configure --help 參考可用的參數。 最後補充，其實可以 參照這篇 直接安裝 OpenResty 。 但因為我在實驗所以我就直接手動編譯安裝了，顆顆！

因為某些原因想要不重新編譯 nginx ， 又想要用某個模組的功能， 所以就想到 nginx 可以動態載入模組的功能！ 首先需要的東西如下： 要使用的 nginx 版本必須為 1.9.11 以上......除非真的太舊否則這應該不是問題 跟你目前使用版本相符的 nginx 原始碼（ 完整版本列表 ） 你想要使用模組的原始碼，要確保該模組可以使用動態載入功能 操作方法如下： 打開你的 terminal 視窗，輸入 nginx -V ，這會列出當初編譯安裝時使用的參數，內容大概就是： configure arguments: --add-module=xxxx --with-pcre 之類的內容，請把 -- 後面的字串複製下來備用。 將你稍早下載的原始碼解壓縮某目錄下，這裡就假設是 /my/nginx-source 把你下載的模組原始碼解壓縮到某目錄下，這裡就假設是 /my/nginx-modules  切換到 /my/nginx-source ，輸入 ./configure 加上剛才的 nginx -V 內容，最後多加 --add-dynamic-module=/my/nginx-modules 後按下 enter。如此就會根據原本的編譯參數再加上新設定的動態模組參數準備編譯。 接著再輸入 make modules ，就會開始編譯模組 編譯完的模組會放在 /my/nginx-source/objs 下，你可以把需要的模組檔複製到其他地方備用。 接下來打開你的 nginx 設定檔（通常在 /etc/nginx/nginx.conf ），在最上方加入 load_module 模組檔路徑; 後重新啟動 nginx 就可以生效了。

AWS 什麼錢都要賺， 所以他們就拿 Elasticsearch 來賺錢了， 對於不想自己管 Elasticsearch 服務的人， 只要簡單拿出信用卡解決問題就好了。 設定步驟其實很簡單，大概只有以下三個內容要填： 設定這個 ES Instance 的名稱 設定這個 ES Instance 要使用的機器規格及數目 / 空間類型 / 大小 設定這個 ES Instance 要使用的存取規則 前兩點其實沒什麼， 至於第三點的部分就比較需要談了。 關於存取規則這部分， 如果是 AWS 初學使用者的話建議使用「Allow access from specific IPs」， 這樣就會只限定特定機器可以存取 ES， 後續要使用像是 Logstash 之類的東西同步資料會比較方便（因為不用做身份驗證）。 如果使用「Allow or deny access to one or more IAM users / AWS accounts」的話， 用 Logstash 同步的話就可能要用 logstash-output-amazon_es 這個 plugin 才有可能同步。 不過不知道為何我用這玩意就是會出問題， 也因為如此我才使用限定 IP 的方式來做， 這樣我就可以直接用 elasticsearch 這個 plugin 同步資料。 另外 AWS Elasticsearch Service 設定完後也會有設定好 kibana， 有需要可以再針對這部份善加利用。

......懶得解釋 Jupyter 是什麼了，自己去 Google 吧！ 如果你的機器上沒有 Python ，而且也沒有裝 pip 的話， 請自行安裝這兩樣東西！（爆死 安裝方法超簡單，一行指令搞定（Python2 時）： pip install jupyter  跑完安裝步驟下個以下指令就可以啟動了： jupyter notebook 然後照他的指示開啟 http://localhost:8888/?token=xxxxxxx 就能看到 Jupyter 畫面了。 ===========全劇終===========  上面是安裝在自己機器上的狀況， 但是如果是要裝在遠端機器上的話就還有多做以下設定： 增加密碼保護：否則就能讓不相關的人進你的主機惡搞 修改設定檔：以便可以存取 增加密碼保護可以透過以下指令： jupyter notebook password 接著會要求輸入密碼，這組密碼就會是登入 Jupyter 的根據。 之所以要修改設定檔的原因是因為 Jupyter 預設只提供本機存取， 所以只接受 localhost 或是 127.0.0.1 的 domain， 為了要能夠輸入外部 IP 存取 Jupyter ，才需要改以下這個設定檔： 家目錄/.jupyter/jupyter_notebook_config.py 通常剛裝完時都沒有這個檔案，所以要先透過以下指令手動產生： jupyter notebook --generate-config 接著開啟上述的設定檔，找到以下兩個項目，移除前面的註解，並且修改成以下內容： c.NotebookApp.allow_origin = "*" c.NotebookApp.ip = "0.0.0.0"  做完以上兩個步驟並重新啟動後應該就能夠在遠端存取了。 順帶一提： 這份文件 有提到設定檔中每個項目的作用說明，建議可以看看。        

前陣子因為鬧出 npm 之亂 ， 所以我有打趣著說要做一個玩具， 減少對檔案的依存。 基於這個想法，所以我做了個號稱 PHPFaaS 的 廢物 玩具。 基本上他的運作流程就是： 呼叫 http://php.maid.tw/[函式名稱] 將要傳進的參數列編成 json 格式，以 POST 丟過去 後端接到 POST 來的內容後做一次 json_decode 後再使用 call_user_func_array 去呼叫指定函式並輸出結果 開發這個東西不算是個問題，但是還是要注意一下一些事情： 基本上，為了安全起見，不可能開放使用所有的函式。所以要列一份白名單，列出可用的函式。 有些函式的參數列會收到像是 STR_PAD_RIGHT 之類的常數，但是這個服務目前還沒辦法應對，所以有用到特定常數的話，就要自己想辦法找到那個常數代表的值才行。

大家應該都知道 IFTTT 是什麼樣的東西， 所以我就不多解釋了。 雖然一般而言， 我們確實只要在某個服務的狀態發生時， 才需要讓 IFTTT 幫我們做些事， （像是我們收藏 Flickr 上某張照片時就自動下載到 Dropbox 之類的。） 但通常可以選的服務就是檯面上有名號的服務。 一旦要做些比較特殊的事時， 嗯......通常直覺下都是自己刻東西來做， 老實說有點麻煩啦...... 所以後來 IFTTT 推出 Maker 這個玩意。 她可以接收來自使用者端的請求， 也可以把請求轉發到另外一個地方， 對某些特殊需求而言， 就不大需要額外刻東西。 以下簡介一下使用流程： 首先先到  https://ifttt.com/maker 找到你的 API Key 並且記下來。 接著你就可以到 Create Recipe 中選擇 Maker 後再選擇 Make a web request 開始新增你的食譜了。 記得 Event Name ，這個東西會在呼叫時用到 另外 Receive Request 只收以下這些參數：v alue1、value2 及 value3   這些參數，其他東西會無視。 發出 request 直接使用 POST https://maker.ifttt.com/trigger/{Event Name}/with/key/{API Key} 然後就看你要讓 IFTTT 接到哪裡即可。 不過要注意一點：因為上面的 Request 只收 value[1-3] 這三個參數，所以你也只能在 Ingridents 選擇這三項東西來用。這個就比較麻煩一點...... 使用大致上應該沒啥問題， 反正就是簡單的 POST 機制， 做些比較沒有敏感性的事情其實還蠻方便的。 不過要拿來控制你家的電氣系統就可能要再三思了（茶

前陣子看了一堆鼓勵程式新手的文章， 因此身為一個半吊子又非本科系出身工程師的我， 也想跟著風潮寫些什麼紀錄我的 攻城屍 工程師人生。 說來也是無心插柳 柳橙汁 柳成蔭， 雖然我從國中就開始學電腦， 但電腦程度了不起就是可以玩玩遊戲而已。 雖然國高中時多少上了些計概和程式基礎（VB）， 我依然沒想過自己會走上工程師這條路。 畢竟我當初是選文組的嘛（菸 至於我會走上工程師這條路， 大概還是因為小時候不懂事。 好不容易大學聯考算幾乎落榜地考上新莊大學歷史系， 但是兩年間幾乎沒上什麼課， 考試成績也依然悲催， 到學校只是為了去圖書館看書和去計中上網， 現在想想那時還是真是廢物啊...... 反正這麼荒唐兩年後就直接退學了！ 離開學校後我先過著等當兵外加網遊廢人的一年時間， 就算過完十二天國軍夏令營後， 我還是再當了幾個月的廢人。 直到一個契機才讓我開啟了前往工程師之路的大門...... 那時候（2004~2005年）很流行個人架站之類的事， 拜此風潮，我也多少研究一下個人架站這回事， 稍微玩過 xoops 、 Discuz! 之類的玩意。 然而玩過以後發現只靠這些基本的東西不能滿足我， 因此我就買了一本 PHP + MySQL 的入門書， 從第一章的到最後一章內容讀過也實作過一遍。 不得不說，當時其實是一種挑戰， 因為會發現自己很多東西都不懂不知道， 做起來怎麼都搞不清楚為什麼書上的範例可以正常跑， 自己做出來的東西怎麼樣就是沒辦法得到一樣的結果。 在這段新手期，根本就是考驗自己的信心， 要不是我當時已經退無可退，堅持各種亂改求正解（？）， 或許我會直接放棄。 就這麼自學了一段時間後，我就很不怕死的地以一介新手身份開始投履歷。 想當然爾，當然沒人會用菜鳥， 在踹過幾家後好不容易有家小公司願意錄用我， 雖然工作內容包山包海， 從公司email（直接用 Google Apps，那時還自己弄 bind，我真的不知道我當初怎麼處理的）， 公司網站主機移機（從 hinet 虛擬主機移到家用 PC 的 Server，那時 hinet 的虛擬主機空間還真的小的要命，雖然是以現在的眼光看啦......）， 網站修改（直接硬改一堆 PHP flat code）， 到電腦設備維護（幹，我哪...

youtube-dl 大概是我看過最可怕的下載影片工具了， 雖然看名字你會認為她只能抓 youtube 的影片， 但實際上 主流的影音網站 的影片他都能抓。 （雖然這工具主要著墨於 youtube 就是了 安裝方法就不說， 反正 windows 用戶就抓一個可執行檔就可以跑了， linux / mac 下個指令應該也可以輕鬆安裝。 以下列出常用的指令： 簡單地抓影片：執行後會去抓最高畫質的影片並放在當前所在目錄。如果是播放清單的話，會整份清單上的影片都全跑一次。 [youtube-dl路徑] 影片url/或youtube播放清單 抓取指定畫質的影片：只限 youtube，其他網站沒試過 可以先用 [youtube-dl路徑] --list-formats 影片url 列出所有可用的 fmt 接著再下 [youtube-dl路徑] -f [fmt代碼] 影片url 只要影片中的音樂檔 [youtube-dl路徑] --extract-audio 影片url 如果還需要限定音質水準的話，可以多加 --audio-quality [0-9] ，0 品質最高，9 最低 也可以限定要輸出什麼編碼的檔案，只要多加 --audio-format [aac|vorbis|mp3|m4a|opus|wav] 即可。 只下載播放清單中的第 N ~ M 間的影片 [youtube-dl路徑] 播放清單網址 --playlist-start N --playlist-end M ，不過要記得如果是要從第一部影片開始抓的話 N 是要填 1 。 如果是要從第五個影片開始抓的話就只要加 --playlist-start 5 就好了 改變下載檔名 [youtube-dl路徑] 影片url -o "名稱或是名稱模板" 其中名稱模板可以放一堆變數替換掉，不過這就要翻說明內容才知道。沒設定這個選項的話，下載的檔名會是「影片標題_影片ID」。 其他還有一狗票選項可以設定，可以讓你的影片收藏更加豐富。 要說的話這東西的缺點就是只有文字列模式， 所以可能會用得很不習慣， 不過一旦習慣了， 大概會覺得一狗票抓影片的工具實在都弱爆了。 （回想起以前還要裝 GreaseMonkey Script 或是...

Clef 是一套算是方便的簡單登入機制，宣稱只要三個步驟就能讓你簡單登入： 點擊支援網站的登入按鍵，此時會出現 Clef 的登入畫面（其實就是一個 GIF 條碼而已） 打開安裝在手機上的 Clef APP ，掃描該 GIF。 若是第一次造訪該網站可能會要求你填寫額外資料。這樣就完成登入作業了。 要在自家網站使用這個服務，得先去他們網站註冊，並開啟一個新 Application ，接著就是要改一下 Code 了。 以下是 PHP 使用 CI 所寫出的範例 Code（這裡只實作登入部份，登出部份之後再另寫一篇說明）： 如果要玩玩看實際的操作流程，可以連到 這裡 看看。

Orchestrate.io 是一個把 NoSQL 和搜尋服務結合在一起的 DaaS（Database as a Service）。 對於想要用搜尋服務也想同時使用 NoSQL 服務，但是資源卻不夠多的人，他的免費方案讓你可以輕鬆使用，所以我非常推薦。 使用方法很簡單，初使用者可以直接看範例 Code，瞭解最基本的用法後就可以開始寫 Code 了。