はじめに 最近、APoSD(A Philosophy of Software Design)を読んで、ソフトウェア設計に関して色々思う事が出来たというか、整理してみたくなったので、記事にまとめてみました。なお、APoSDの言葉を多用はしていますが解説記事という分けでは無く、自分の考え方の言語化にしっくり来たので使わせてもらってるという感じです。 TL;DR モジュールとは関数/クラス/サービスなどの何等かの機能のまとまり 良いモジュールは複雑性を隠蔽する 複雑性を隠蔽しないモジュールの価値は低い モジュールとは？ プログラムは正しく動くことがまず何より大事ですが、その次というかほぼ同じくらい大事な事が読みやすく拡張しやすいことですよね？　コードは圧倒的に読みものなので、どう読みやすく、つまり理解しやすい状態にしておくかは重要な事です。APoSDでは複雑性が低いコード、という言い方をしていま

Justtechtalk #9でお話した資料になります！

これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr

仮説検証サイクルを高速で回す為に、DMMポイントクラブ アプリチームが行っている取り組み | DMM iOS Meetup #2

アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分

こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの

2023-11-02 JaSST'23 Kyushu 招待講演 https://www.jasst.jp/symposium/jasst23kyushu.html 実装完了後の手動テストに依存した開発サイクルに継続的テストのアプローチを適用し、段階的に品質を向上する方法について説明しています。

フロントエンドのビルドツールが色々ありすぎて、何がどうなっているのかがわかりづらいため、 各ツールができること、特徴 ツール間がどのように依存しあっているか を一気に調べて整理した。(情報は2023/10時点) 概要 ツールの依存関係整理 上層: dev server付きのバンドラ/ビルドツール。アプリ開発者が直接configなどを書いて取り扱うのはここが多いと思われる。(Next.jsに関しては、ビルド機能に着目した場合) 下層: やや基盤的なdev serverなしのツール群。 矢印は、明示的な依存関係を表す。実際には、明示的な依存関係がなくても、下層のツール群は上層のバンドラ(やRollup)に対してプラグインを提供していることが多い。 各ツールのできること整理 ツールごとに、大まかな機能区分で、できることとできないことをまとめた。 各機能区分の定義は次セクションを参照。 ツールごと

Qiita Conference 2023 Autumun での発表資料です 発表時間の見積もりが下手で後半全然説明できませんでした、すみません！ 実際のプロダクト開発ではどうすればいいのか? というケースは以下のスライドを参照してください。 (本スライドは、こちらのプロダクト開発の経験をベースに基礎を再整理したものになります) https://speakerdeck.com/naoya/typescript-niyoru-graphql-batukuendokai-fa-75b3dab7-90a8-4169-a4dc-d1e7410b9dbd

インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏：ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC（株式会社エーピーコミュニケーションズ）さんが「カプセルト

みなさんSREしてますか？ サービスなどの品質を維持していくために切っても切り離せないSREですが、 日本でもSREという言葉が定着しつつあるかと思います。 このSREについて書いていきたいと思います。 SRE NextのCFP忘れてたのでその代わりに・・ SREってインフラですよね？ 非常によくあるケース、というか多分ほとんどがこうなっていると思います。 もちろん会社としてインフラのことを指しても問題はありませんが、 SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで さらに良い活動に繋がることが多いと思います。 なんのこっちゃ、という方も多いかもしれません。 SREはエラーバジェットなどの話が必ず出てきますので、 モニタリングや監視などが必ずセットにはなっていきます。 ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、 というのが定着している場

2023年度リクルート エンジニアコース新人研修の講義資料です

Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C) - UI スクリーン・キャプチャ集

Dockerを触りながら学んでいく、初心者向けの記事です。 用語の解説等はほとんどせずに、とにかく触ってみることを目的としています。 Phase 1: Dockerの基本 コマンドを試しながら基本操作を学びます。 Phase 2: Dockerfileをもう少し書いてみる Dockerfileを使って、簡単なWebアプリケーションを作成します。 Phase 3: Docker Composeを使ってみる Docker Composeを使って、複数のコンテナを一括管理します。 Phase 1: Dockerの基本 Dockerの基本的な操作を試してみます。 プロジェクトフォルダの作成 次のコマンドを実行して、プロジェクトフォルダを作成します。

ストックマークの社内研修の公開版※資料です。 （※実際に研修で利用したものとは異なります）

みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います