跳到主要內容

[自言自語] 關於程式新手的感想

前陣子看了一堆鼓勵程式新手的文章,
因此身為一個半吊子又非本科系出身工程師的我,
也想跟著風潮寫些什麼紀錄我的攻城屍工程師人生。

說來也是無心插柳柳橙汁柳成蔭,
雖然我從國中就開始學電腦,
但電腦程度了不起就是可以玩玩遊戲而已。
雖然國高中時多少上了些計概和程式基礎(VB),
我依然沒想過自己會走上工程師這條路。

畢竟我當初是選文組的嘛(菸

至於我會走上工程師這條路,
大概還是因為小時候不懂事。
好不容易大學聯考算幾乎落榜地考上新莊大學歷史系,
但是兩年間幾乎沒上什麼課,
考試成績也依然悲催,
到學校只是為了去圖書館看書和去計中上網,
現在想想那時還是真是廢物啊......

反正這麼荒唐兩年後就直接退學了!

離開學校後我先過著等當兵外加網遊廢人的一年時間,
就算過完十二天國軍夏令營後,
我還是再當了幾個月的廢人。
直到一個契機才讓我開啟了前往工程師之路的大門......

那時候(2004~2005年)很流行個人架站之類的事,
拜此風潮,我也多少研究一下個人架站這回事,
稍微玩過 xoops 、 Discuz! 之類的玩意。
然而玩過以後發現只靠這些基本的東西不能滿足我,
因此我就買了一本 PHP + MySQL 的入門書,
從第一章的到最後一章內容讀過也實作過一遍。

不得不說,當時其實是一種挑戰,
因為會發現自己很多東西都不懂不知道,
做起來怎麼都搞不清楚為什麼書上的範例可以正常跑,
自己做出來的東西怎麼樣就是沒辦法得到一樣的結果。
在這段新手期,根本就是考驗自己的信心,
要不是我當時已經退無可退,堅持各種亂改求正解(?),
或許我會直接放棄。

就這麼自學了一段時間後,我就很不怕死的地以一介新手身份開始投履歷。
想當然爾,當然沒人會用菜鳥,
在踹過幾家後好不容易有家小公司願意錄用我,
雖然工作內容包山包海,
從公司email(直接用 Google Apps,那時還自己弄 bind,我真的不知道我當初怎麼處理的),
公司網站主機移機(從 hinet 虛擬主機移到家用 PC 的 Server,那時 hinet 的虛擬主機空間還真的小的要命,雖然是以現在的眼光看啦......),
網站修改(直接硬改一堆 PHP flat code),
到電腦設備維護(幹,我哪知道網路怎麼不能用啊?)
直到現在我也無法理解程度根本就是幼幼班的我怎麼能夠應付這些事?
對業界的認識總算是有一點了,雖然自己也依然懷疑這樣的程度能夠應付些什麼?

就這樣陸陸續續待了幾家公司,
我基本上都是在工作上學習。
除了早期針對新程式技術會買幾本書自己看自己實作外,
現在的我幾乎不買技術書籍,
更多時候我是看著別人寫的 Code 學習,
有問題找 Google / StackOverflow,
努力做些不能賺錢的玩具鍛鍊實力。
雖然依然不敢說自己能夠獨當一面處理各種狀況,
但是大部分狀況應該還是可以勉強應付。

以下算是過來人給新手的建議:

  • 不要妄想找到一本完美的入門書才開始學習:如果你真的想學一門技術,去書店隨便找一本相關的書,按照書中的教學實例全部實作過一遍,確定你可以重現每個範例的結果,或是吐嘲作者的範例有錯,然後就把書丟掉。接著用你自己的想法和所學寫一個小東西出來,不懂的就去 Google ,想一下該怎麼解,不要只想著 Copy / Paste 解決,因為你永遠不會有記憶。
  • 世界上不是只有一個解答:一個程式語言當然可以解決很多問題,但是閒著沒事多學別的程式語言也是無妨的,可以增加自己的見識,也增加解決方法的搜尋廣度。
  • 別光只看書,實作比較重要:實作才能增加自己的經驗值,你就算讀了一堆技術書籍卻不實作,了不起就是個活書架,你還是沒有實力應付現實的問題。哪怕是做別人眼中的玩具也好(在下就做了很多這樣的玩具),你還是比讀了一堆技術書的人來著好。
  • 不要妄想戰語言/技術:如標題,能戰這種東西的人不是平庸的你,只有那些技術的發明人才夠資格去找其他語言技術戰。你所要做的是冷靜分析哪些東西在哪些狀況有比較好的表現,哪些狀況可能會有狀況要處理,然後在碰到狀況時能夠提出方法處理。

留言

edsellgahr寫道…
Betway Casino NJ - Mapyro
The Betway Sports Lounge at Betway 안동 출장샵 will be 포항 출장마사지 open from 11:30am to 3:00pm on Tuesday, Monday, Thursday 양주 출장안마 and Saturday, 안양 출장마사지 Sunday. Viewing titanium tube hours.

這個網誌中的熱門文章

[野人獻曝] 串接 OpenAI 的 Assistant

你就直接把 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 來生個香香的老婆圖

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....

[野人獻曝] Google App Engine ...... 的踩雷

最近因為要把用 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 運作...