前一篇提到了 PHP 8 Array 的基本概念,對 PHP Array 還不熟悉的人,可以先閱讀前一篇哦。
這篇接著要來介紹 10 個 PHP Array 的實用方法,讓你對 PHP Array 有更深入的了解,知道 Array 可以用來解決什麼問題,也提高對 Array 應用的熟練度。
本篇將會依序說明及介紹以下十種作法與方法:
前一篇提到了 PHP 8 Array 的基本概念,對 PHP Array 還不熟悉的人,可以先閱讀前一篇哦。
這篇接著要來介紹 10 個 PHP Array 的實用方法,讓你對 PHP Array 有更深入的了解,知道 Array 可以用來解決什麼問題,也提高對 Array 應用的熟練度。
本篇將會依序說明及介紹以下十種作法與方法:
Array 是什麼?簡單來說,Array 是一種資料結構,用來儲存大量相似的資料。
如果沒有 Array,當你要儲存多個類似的資料,例如,三個數字,你必須要宣告並使用三個變數。
$num1 = 10;
$num2 = 20;
$num3 = 30;
但是透過 Aarry 的協助,你只需要使用一個變數。
$nums = [10, 20, 30];
當然 Array 不只讓你更方便地儲存資料,Array 作為 PHP 的核心資料結構,也提供了許多方便的方法,讓你可以更彈性的操作 Array 中的資料。
南北海道、東北之旅的第一天,從台北出發。
搭乘機場捷運到桃園機場,搭乘台灣時間 10:05 的班機班機,抵達北海道新千歲機場的時間是日本時間 15:00,搭乘時間約 4 小時。
由於預期今天搭飛機,會比較累,所以沒有安排什麼行程,就是先到飯店,然後吃成吉思汗!
新千歲機場很大,也有一些地方可以逛街,但因為趕著前往市區,所以就沒有多做停留。
從新千歲機場前往 JR 札幌駅,可以搭乘JR快速エアポート,只要 40 分鐘即可到達JR 札幌駅,而且大概每15分鐘就有一班車,很方便。
早些年的 AI 其實很笨,不太能理解人類真正的意思,但經過學者跟工程師們多年的努力,聊天機器人已經有很大的進展了。尤其是最近微軟推出的 ChatGPT,據說聰明到已經可以顛覆整個產業了!?
甚至傳聞 ChatGPT 已經足以取代軟體工程師了!事實真的是這樣嗎?難道我這次真的要失業了嗎?
這篇就來玩一個簡單的測試吧,來測試 ChatGPT 是不是真的有傳聞中的那麼厲害,是不是真的可以取代軟體工程師!那就廢話不多說,直接出動 ChatGPT 啦!
打開 ChatGPT 後,我直接問了這個問題:
請問我要如何在本地使用Docker建立起Laravel的開發環境?
問完後,不用幾秒, GPT 立刻就回了我一大串,如下面的截圖,洋洋灑灑的列出了六大步驟(完整原文貼在圖片下方)。
我自己認為,程式當然有比較需要天分的部分,像是演算法。
比較簡單的演算法、資料結構還可以理解,像是排序、最小路徑、Stack、Heap 這些常見的東西,都還可以理解。但是在深入往下探討,什麼 NP、NP-Complete 我是從來沒有搞懂過。
這就是為什麼我後來也放棄繼續唸研究所,因為資訊相關科系,研究所都是偏數理的,尤其是AI、資料相關的,非常仰賴數理能力,我自認沒興趣也沒能力,就沒有繼續往下走了,選擇直接就業。
回歸正題,所以說,你需要是一個天才,才有辦法寫程式嗎?
在一個時程已經落後的軟體專案中增加人手,只會讓他更加落後——人月神話
本書的第二章,章節名稱:人月神話,正是這本書的書名。這個章節能夠作為書名,代表他的重要性。
書中認為,軟體專案進行不順利的原因,大多是因為缺乏良好的時程規劃。其中最重要的觀點是,有許多專案管理者,錯把工作量跟專案進度混為一談,進而以為在時程延誤的時候,可以透過加人的方式來趕上進度。
一個專案有固定的工作量?是的,但這是最樂觀的時候。軟體專案有太多意料外的事情可能會發生,導致工作量可能會發生變化。
我們先撇開意外不談,來看看所謂的人月 (man-month)。
人月是用來衡量工作量的單位,指的是一個人工作一個月的產出。如果說一個專案需要 6 個人月,那代表需要花一個人 6 個月的時間,才可以完成專案。
漫長的疫情就該後來一場日本北方國度的旅行,看看不一樣的風光。
初秋時期(9月中)的北海道、東北,是旅遊的淡季,沒雪景、沒楓葉、沒銀杏。但也相對的遊客也比較少,適合討厭人擠人又想感受日本街景、食物、服務的朋友們。
訂機票的時候一個奇怪的念頭閃過,決定從新千歲機場(CTS)進,仙台機場(SDJ)出,中間會橫跨南北海道跟東北各個主要城市,是一趟大長征。
這趟旅程不開車,主要以大眾運輸為主。
行程規劃上,重點放在札幌跟仙台兩個城市,札幌規劃了四天,仙台規劃三天。
大型系統的軟體開發工作就像掉進了焦油坑裡。
當你掉入焦油坑中,越是掙扎,焦油就纏的越緊。軟體工程某種程度就像是這樣的東西
首先,先來個大哉問吧,你知道軟體工程是什麼意思嗎?
如果你認為,軟體不過就是寫寫程式而已,並沒有什麼工程的成分存在,那麼你不妨可以想像一下,為什麼有那麼多的「程式」天才,每年從台清交成的資工系畢業,卻沒有多少個成功的「程式」?
這個問題的關鍵在於,在市場上,真正有價值的,並不是程式,而是通過繁瑣的程序,最後終於成功上線的「軟體系統產品」。程式天才可能擅長設計程式,但他們卻不擅長處理更現實層面的工程問題。
不知道大家有沒有聽過一個玩笑話說,學校作業寫的東西就是玩具而已?其實我認為這個比喻還蠻有趣且適合的。
曾經待過一個新創團隊,因為產品才剛起步,所以團隊採取了敏捷模式。
一天上午的例行會議 (Stand-up meeting),一位資深同事氣沖沖的,說要告訴大家什麼才是正確的開發模式,似乎累積了長期的怒氣。
他不斷地強調,需求一直改變是不行的,大家沒辦法做事,需求必須要被固定下來。
但是啊,不就是因為,需求一直改變,團隊才採用敏捷的方式開發嗎?
敏捷這個概念本身並不難理解,但是能不能接受又是另外一回事。
轉職 PM 是很多軟體工程師正在考慮職涯發展的目標之一,不過問題是,究竟軟體工程師有沒有辦法轉職 PM 呢?
其實軟體工程師是一個還不錯的職業吧,薪水高於平均,工作風險低,生活品質也還可以,所以一定是有一點什麼原因,或遭遇一些問題,工程師才會開始考慮轉職。
這篇來聊聊,到底有哪些理由,會讓工程師想不開,想要轉職,再來講講 PM 的職責,看看是否跟你想像的一樣?最後來說說轉職 PM 可能會遇到什麼問題。
工程師的未來發展性,其實還挺不錯的。在大公司,可以從普通工程師、資深、主任、副理、經理、總監、一路當到技術長等等,所以若是從發展潛力的角度來看,應該不會是想轉職的理由,比較多的應該會是職務適性的問題。
作為一個寫網頁的 Web 仔 aka 碼農,到底找工作要找接案公司,還是自有產品的公司?先說結論,可以的話當然找自有產品的公司。
接案公司當然也有好的,但我認為好的接案公司真的太少了。雖然台灣有很多中小型的接案公司,但多數其實都只是在胡搞瞎忙,公司賺不到錢,也不會成長,只是在幫甲方打工,還有那種都已經成立十年的,居然還稱呼自己為新創公司的,真的是很好意思。
以下來講講,到底是什麼原因造成接案公司這麼雷。請好的接案公司不要自行對號入座,不是在講你們,感謝。
之前介紹過 Laravel 的一對一關係 hasOne
跟 belongsTo
(這裡),這次要進一步介紹 Laravel Eloquent 用來處理一對多關係的方法:hasMany
跟 belongsTo
。
hasMany
指的是「擁有很多東西」。我擁有很多東西,並且我在它們的身上貼上了我的識別代碼。
belongsTo
指的是「屬於某個人」。我屬於別人,我被貼上了他的識別代碼。
你沒看錯,belongsTo
重複出現了,至於為什麼,就請接著看下去吧!
Laravel 有預設的 Logger,可以透過 logging config 設定,滿足大部分情況的需求。
不過有些時候難免還是會需要動態的使用 logger,尤其是需要動態產生 logger 的寫入路徑,這個時候就需要用別的方式了。
這篇文章不是要談什麼演算法優化,也不是要談系統架構的設計。單純想聊的是,軟體工程師做為團隊成員的一員,如何高效率的完成工作。
江湖有個傳言,一個好的資深工程師,工作效率是菜鳥工程師的十倍。我認為這並沒有誇大。畢竟有些時候,菜鳥工程師鬼打牆一整天的問題,資深工程師可能早就遇過了,稍微看一下就知道是什麼狀況,直接秒殺。
作為十倍速工程師,當然除了經驗豐富,他的技術能力跟知識含量也都遠高於剛入行的工程師,不過,還有另一點會被大家忽略的是,其實資深工程師都有一套自己的工作哲學,可以用來提升自己工作的效率,這就是所謂的職場軟實力。
職場軟實力當然有非常多不同的面向,這篇想做的是,整理出一些可以直接參考,並可以拿來實際應用的做法,讓工程師可以提高工作的效率,遠離加班。
因為疫情期間,兩年期間無法出國,懷念起過去日本溫泉飯店吃的懷石料理,於是就開始尋找台北有沒有適合的餐廳。
其實日本料理很多元,懷石料理的特色就是很多道,雖然每一項都不多,但在一餐內可以吃到多種不同料理方式,對味覺跟視覺來說,都是幸福的。
這次找到的是位於信義區的《心月》,會選擇這家的原因是,感覺價格還算是可以負擔的。畢竟在台灣吃日式無菜單料理,一不小心荷包就會失血。這家有不同價位可以選擇,雖然還是不便宜,但相較之下,是相當平易近人的。
資管系其實算是一個很大眾的科系,幾乎每一所學校都有。但資管系實際上在做什麼,不要說是高中生了,連社會人士對於資管也是相當陌生的,存在相當多偏見與誤解。
由於對於資管系的不瞭解,很多時候,資管系只是一些人作為考不上資工系的備胎而已。但這樣真的好嗎?會不會踩到雷?為了提供各位更多選科系時的參考資訊,這篇文章就來談談資管系吧。
最近組了新電腦,添購了一些設備,剛好可以來記錄一下。
工作的關係,需要寫程式,所以有大量打字的需求。為了善待自己的手指,可以持續當一個有生產力的社畜,所以在辦公室擺了一把機械式鍵盤。
畢竟是辦公室,所以不希望製造太大的噪音,免得招來白眼攻擊,因此當時選了茶軸的 Cherry MX-Board 2.0 。這把鍵盤用了 6 年都沒壞,真是非常強壯,而且也一直都蠻好按的,所以對 Cherry 的印象相當不錯。
因為這樣,這次在挑選鍵盤的時候,本來也有考慮其他品牌,但比較了很久,覺得其他品牌差不多價位的產品,好像都有點華而不實,多了很多我不是那麼需要的規格,所以看了一圈又回來找 Cherry 老朋友了。
考慮到預算跟需求,這次選了 Cherry MX Board 3.0S 靜音紅軸,購入價格是 2,990 元。
作為軟體工程師,長期面對工作中各種惱人的瑣事,一開始的熱情與動力逐漸會被抹去,最後只能選擇關閉感官,不反抗、不思考,才能夠心平氣和地把工作完成。
其實這樣是一個很不好的狀態,如行屍走肉般地把工作完成,並不是我自己喜歡的樣子。
年輕的時候,我對於學習新事物充滿了熱情,對於每個月可以領薪水也充滿了熱情。但是現在,這些好像都不是那麼重要了,無止盡的學習變成令人疲倦的事情,而工作領薪水本來就是理所當然的。
所以我已經失去熱情來源了嗎?其實並不是這樣。往深處去探求熱情的來源,其實會發現我始終在追求的就是:「想做出自己滿意的系統或功能。」
大家或多或少有聽過日本的匠人精神吧?這些匠人們有著自己的個性,對自己的技能充滿自信,並且追求完美,不把一件事情做到自己滿意為止不肯罷休。而我覺得自己有一點這樣的特質。
然而,很不信的,這樣的匠人精神,其實並不適合存在於企業中。這也就是為什麼,想要做出自己滿意的系統,這麼一個簡單的目標,會如此難以達到。
2022 年 12 月 8 號 PHP 8.2 發布了,這是 PHP 8 的第二次重大更新。從 2020 年開始,PHP 維持著每年更新一個次版本的進度,2020 年 11 月的 8.0,2021 年 11 月推出了 8.1。
作為最熱門的 PHP 框架,Laravel 9 及 10 都支援 PHP 8.2,如果還在使用 Laravel 8 及以前的版本,最多只支援到 8.1。
那我們話不多說,趕緊來看一下 PHP 8.2 有哪些重大的調整吧。
在黑白畫面打幾行指令,東西就跑出來了,在外人眼中看起來是相當的酷炫的行為。
而 Laravel 就提供了一個這樣的工具。
這個工具叫做 Artisan,它提供了一個方便的命令列介面(CLI)指令工具,讓開發者可以方便地執行指令,例如 Controller
、 Model
的創建,或是執行 migrate
,也可以用來啟動排程 schedule
。
學會 Artisan,可以將許多重複的瑣事轉換成自動化的行為,有助於提升開發效率,並減少錯誤的發生。
你有沒有想過要主動找老闆爭取加薪或反映不合理的制度?
很多時候,員工對公司或團隊上的安排、制度,會有一些埋怨,但卻對於主管感到權威,不敢表達,只能悶在心裡,讓自己不舒服。
但我認為現在的時代跟以前不一樣了,尤其在資訊軟體產業,大部分的主管都願意傾聽下屬的意見,所以我倒覺得大家都可以試著找主管反映自己的想法。
其實很多主管都沒有想過要定期找下屬聊聊,或是沒有把這件事的優先序放在前面,但這件事情在很多外商或是比較開放的台商其實是非常例行性的工作,會安排所謂的一對一會議(1 on 1 meeting),來定期的安排主管與下屬的對談。
工作這麼多年了,經常在思考,究竟資深的軟體工程師該是什麼樣子?只要年資夠久就能稱得上是資深工程師嗎?只要有足夠的技術能力就是資深工程師嗎?我想每個人心目中都有一個資深工程師該有的樣子吧?
這篇文章主要聊聊我自己對資深工程師的想像,除了是我認為該有的樣子,也是我個人努力的方向。以一個團隊的角度來看,作為團隊中的資深工程師應該要有什麼樣子?我覺得可以從開發能力、溝通能力、工作態度幾個面向來看。
目前軟體開發方法中有兩大流派,分別為瀑布式跟敏捷式。
瀑布式是比較早發展出來的開發模型,敏捷則是近十年來被大力的提倡。有許多公司或團隊,以採用敏捷開發做為賣點,認為敏捷可以打造出更好的產品,或是加快軟體開發速度,所以敏捷比瀑布式開發還要好。
但我們要理解,每一種方法論都有其適合的情境,並無絕對的優劣,例如,敏捷適合於需求不清、變動快速的場景,而相對的瀑布式開發也有其優缺點跟適合的情境。