Liusan's Blog

原文連結：エンジニアを面接するときに面接官が本当に知りたいこと - Qiita

接下來這篇文章，也同樣是從面試官的角度，說明「面試關注的幾項重點」。

原文連結：見たいエンジニアの職務経歴書の書き方 - Qiita

接下來這篇文章，是從面試官的角度說明「履歷撰寫方式」。

在閱讀本文前需要先注意，日文履歷通常分為兩個部份，與我們一般認知的履歷不太相同：

• 履歷書：通常為制式的條列表格，填寫基本資料、在學/職經歷、擁有證照、自我 PR、對工作期許等
• 職務經歷書：格式不固定，主要功能是延伸履歷書提到的項目，針對個人工作經驗、工作負責項目、展現工作成果等進行詳細說明

為了不搞混兩者，本文中出現的履歷書會以「個人簡歷」表示，而文章主要談論的「職務經歷書」則以「工作履歷」來表示。

原文連結：エンジニアの次のステップへの勉強法 - Qiita

接下來會針對職涯部分，依序介紹學習方法、履歷撰寫方式、以及面試準備方向等文章。即便是從日本環境的角度撰寫，道理還是大致相通。

本篇首先介紹的是「學習方法」，技能方面較偏向後端技術，未來求職可以作為參考。

原文連結：海外「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？」 - Qiita

常聽聞日本軟體界的各種評價，而這篇文章主要整理國外論壇針對此議題進行分析。

原文連結：世の中のエンジニアのalias設定 - Qiita

alias 是什麼？文章中也有稍微介紹到，簡單來說，就是「設定命令別名」，通常用於慣用指令特別長的情況，或是增設預設屬性在一些慣用指令，避免發生誤刪等憾事。

詳細可以參考鳥哥的文章：第十章、認識與學習BASH

原文連結：The S.O.L.I.D Principles in Pictures
本文所刊登的圖片，皆屬原作者 Ugonna Thelma 所有。

這篇比較特別一點，是從「イラストで理解するSOLID原則 - Qiita」這篇翻譯得知英文原文，因此會以英翻中為主。

本文將以圖解方式，依序說明 SOLID 原則：

• Single Responsibility 單一職責原則
• Open-Closed 開放封閉原則
• Liskov Substitution 里氏替換原則
• Interface Segregation 介面分離原則
• Dependency Inversion 依賴反向原則

原文連結：イケてるレポジトリのREADME.mdには何を書くべきか - Qiita

前言

在 GitHub 新建 Repository 時，首先會建立 README.md 這個檔案。您是否會將文件維持預設狀態，而不做任何修改呢？

README.md 是 Repository 的門面。通過編輯這份文件，能夠大幅提升 Repository 的質量。然而，可能有許多人不知道應該在 README.md 中寫些什麼。

原文連結：ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita

對於 pictBLand 和 pictSQUARE 受到非法訪問，且將密碼儲存在未加鹽的 MD5 Hash 中的事件，近來已成話題。

2023 年 8 月 16 日，有篇投稿聲稱持有從 pictSQUARE 竊取的數據，並將這些資料銷售給外部論壇（部分略）。該投稿指出，雖然密碼已進行 MD5 HASH，由於未進行加鹽，因此已取得 29 萬 4512 組簡單密碼的原始字串（剩餘 26 萬 8172 組仍保持 MD5 HASH 值）。
內容引用自 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog

原文連結：ソフトウェアはなぜバージョンアップしなければならないのか - Qiita

有時在一些官網下載軟體時（例如 node.js 或 Ubuntu ），會發現官方有提供兩種版本，分別是「LTS」和「Current」，其中 LTS 代表 Long Term Support（長期支援），穩定版本確保程式的安全性與可靠性，避免更新可能造成的風險。

軟體除了新增需求、修復 BUG 以外，是否就不需要再進行版本更新了？這篇文章將會介紹為何軟體需要版本更新，以及更新頻率可能帶來不同的結果。

原文連結：フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita

常聽聞免費 Wi-Fi 可能暗藏資安危機，究竟原理是如何、可能造成什麼影響，又該如何預防等等，本文將針對這個主題進行介紹。