【2024年度】エンジニア向け研修資料まとめ - Qiita
はじめに 本記事では無料で公開されている企業のエンジニア向け研修資料をまとめました。 近年では、多くの企業が新人向けの研修資料を公開しています。これらの資料は内容が充実しており、初心者から中級者まで幅広いレベルの学びを得ることができます。さらに、資料の作り方も参考になるため、勉強会で発表する人や企業の研修担当者にとっても貴重な情報源となっています。 本記事では様々な企業のエンジニア向け研修資料をまとめましたので、ぜひ参考にしてみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 この記事の主な対象者 有名企業の研修資料を幅広く確認したい方 エンジニアとして初級から中級レベルの方 独学で学んでいる方 今後研修資料
マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 - Sansan Tech Blog
Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は（使い古されたネタではありますが）モノレポ化についてお話ししたいと思います。 おさらい：モノレポ（mono repo）とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ（poly repo）と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること
公式ドキュメントを読め。Qiitaを開くな。 - Qiita
はじめに 公式ドキュメントを読め！Qiitaを使うな このような発言はネットで時々見かけるような内容であり、ある程度プログラミングができるような方を中心に見かけるイメージのあるものです。 私はこの発言を見るたび思うことがあります。 Qiitaに投稿すべき内容を多くの人が間違っているからこのような発言が生まれている 今回は、「公式ドキュメントを読むべき理由」「Qiitaが適切な場合」「Qiitaに投稿すべき内容」について書いていきます。 公式ドキュメントを読め 「公式ドキュメントを読め」 これは私として気持ちがものすごくわかります。 公式ドキュメントにはだいたいの知りたい内容については書かれていますし、1次情報になるので情報が正確です。 QiitaやZennなどに解決方法がないかを時間を書けて調べるくらいならいきなり公式を見たほうが早く解決することも多いです。 その一方で「公式ドキュメントよ
PythonのDockerfileをセキュアにするためのベストプラクティス - Qiita
はじめに PythonのDockerfileを作成する際、ネット上で適切な情報が見つからず、試行錯誤することがあります。そこで、ここでまとめてみます。 完成品 # 開発用ステージ FROM python:3.11.9-slim-bookworm AS developer ENV PYTHONUNBUFFERED=1 ENV PYTHONDONTWRITEBYTECODE=1 WORKDIR /app RUN apt-get update \ && apt-get install -y --no-install-recommends \ wget=1.21.3-1+b2 \ && apt-get -y clean \ && rm -rf /var/lib/apt/lists/* COPY requirements.txt ./ RUN pip install --no-cache-dir -
『ルールズ・オブ・プログラミング』を読んだ #iknowtherulesjp - Don't Repeat Yourself
Ghost of Tsushimaなどを作った会社の人が書いた本です。ゲーム開発におけるコードを書く際の教訓を整理し、改めて示し直したいい一冊だったと思います。大事なことですが、著者は決して「このルールを絶対使え」と言っているのではなくて、そもそもまず会社の製品の特性上、このようなルールを敷いておくと品質や生産性を高く保てたという前提があり、その前提を元に「ルールを選び取って自分たちのコーディング哲学を構築しよう」と推奨しています。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール 作者:Chris Zimmermanオーム社Amazon この手の本では『リーダブルコード』がよく薦められる傾向にあると思います。私にとってもリーダブルコードは確かに駆け出しの頃すごく役に立った記憶はあるのですが（もう10年くらい前に読んだので正直忘れた）、そこから知識がアップデートされ
これをやると「言語化が苦手な人」と、意思の疎通がしやすいかもしれない。
様々な会社に訪問していると、それなりの頻度で「言語化が苦手な人」に遭遇する。 例えばこんな具合だ。 「プロジェクトの基本要件を一つにまとめてマネジメントしたいんだけど。 例えば、一部のプロジェクトで必要なリソースを最初に一つの大きな枠組みで決めて、それを全部に使う、そんな感じ。」 「言葉にできてるじゃない」と思う方もいるかも知れない。 だが、本当に言語化の苦手な人とは、「言葉にはできているのに、その内容が、他の人にとって難解過ぎる人」なのだ。 「言葉が出てこない」 「説明しにくい」 「なんと言えばいいのか迷う」 というのは、実は「言語の苦手な人」よりもかなりマシである。 なぜならば、「言語化できていない」という認識を自分自身で持てるからだ。 それに対して、真に言語化の苦手な人は、自分自身で「言語化が苦手」と気づいていない可能性が高い。 前職にもこんな人がいたが、 「あの人、あたまが良すぎて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
