Qiita Conference 2025 における発表の資料です。 設計とはなんだろうか、というお話をしています # プロポーザル https://qiita.com/official-campaigns/conference/2025#day1 設計とは単なる技術的な構造を定める行為…

『建設労働のひろば』という変わった媒体から寄稿を頼まれた。12000字という字数要請だったので、あちこちに脇道に入り込んで無駄話をすることになった。たまにはそういうのも許して欲しい。 寄稿依頼の趣旨は「劣化する民主主義、広がる格差、極まる『自分ファースト」、戦争が終わらない世界情勢など、国民が直面する危機的な日本の現状とその要因について、また(ほんの少しでも)希望について語っていただけないでしょうか」というものだった。 同じようなことをよく訊かれる。だから、答えもだいたいいつも同じである。だから、以下の文章を読まれた方が「これ、前にどこかで読んだことがあるぞ」と思っても当然である。でも、それを「二重投稿だ」と咎められても困る。「現実をどう見ますか」という問いにそのつど新しい答えを出せるはずがない。いつもの話である。 長く生きてきてわかったことの一つは、歴史は一本道を進むわけではなく、ダッチ
50代のおっさんエンジニアになってたので、雑に40代にやっておいてよかったことなどを振り返ってみた。思い出補正があるかもしれないので参考にしようとする人は注意。 運動習慣をつけた 資格学習を継続した 読書習慣を維持した 仕事と関係ない勉強を始めた IT勉強会コミュニティへの参加をやめた ブログを書き続けた 運動習慣をつけた 40歳になったころに人間ドックでメタボ判定を1度受けたことをきっかけに、運動をするようになった。現在も続けているので習慣化に成功しており、おおむね健康を維持できている。 ゴルフを含めてスポーツの趣味はない(今もない)。ゴルフは誘われるけど、興味がない(週末に会社の人と遊ぶような思考を持ち合わせていない) ダイエットするなら食事改善というのは理解しているけど難しそうなので、筋肉つけて代謝を高める方向性を選択 コロナ禍以前は会社帰りに福利厚生で安く使えるジムのプールで泳いで
前記事 AWS ECS Fargate Autoscaling の実戦的な基礎知識 の続きというか派生的なところで、こんな監視項目がこんな理由でえぇんちゃうん、という基礎知識的なお話です。 当ブログでは『監視よければ全てヨシ!』という格言を推していますので、監視の仕込みをサボっている人は今からでも頑張っていきましょう。 はじめに もともと書くつもりでいた本タイトルは、公式からこのドキュメントが出たことで、ゴミ箱行きかと思いました。 推奨アラーム – Amazon CloudWatch > Amazon ECS んが、まぁ所詮はドキュメントということで、ここではもう少し実戦に寄り添う形でまとめていければと思います。 あったら嬉しい監視項目をカテゴリごとに整理しつつ、その理由やら補足情報によって、楽しく監視できるようにしていきたいところです。合わせて読みたいところとしては、この辺もどうぞ。 ミ
以下のセクションでは、ベストプラクティスアラームを設定することをお勧めするメトリクスを一覧表示しています。各メトリクスには、ディメンション、アラームの目的、推奨しきい値、しきい値の根拠、期間の長さとデータポイントの数も表示されます。 一部のメトリクスはリストに 2 回表示されることがあります。これは、そのメトリクスのディメンションの組み合わせによって異なるアラームが推奨される場合に発生します。 アラームを発生させるデータポイント数は、アラームが ALARM 状態になるのに必要な違反データポイントの数です。評価期間数 は、アラームの評価時に考慮される期間の数です。この 2 つの数が同じ場合、期間の値がその数だけ連続してしきい値を超えた場合にのみ、アラームは ALARM 状態になります。アラームを発生させるデータポイント数が評価期間数より少ない場合、そのアラームは「N 件中 M 件」のアラーム
TL;DR 「最短でプロダクションで扱うため」のコンセプトはそのままに 入門 Docker がv2になりました 5年ぶりにのアップデートで、古くなった情報を消し最新の情報の追加をしてほぼ書き直しました。 現代でも残ってしまっているような古いプラクティスについても言及しているので、再読もオススメです。 概要 入門 Docker を5年ぶりにアップデートしました。 deprecatedな部分だけは綺麗にするかと思い、git cloneしたところ筆が乗りだいぶ様変わりしてv2になりました。 変更点 古くなってしまっている情報を修正したことがメインです。 特に以下3点です。 1. DockerfileのDSL 2. compose v2対応 3. Dockerfileのベストプラクティス 他にもいくつか。 現在でも使用されている非推奨な使い方への言及 古くなってしまっているが、現在でも使用されてい
2024年8月、日経文庫は創刊70周年を迎えました。その長い歴史の中で、日経文庫は数々のロングセラーや専門分野の名著を生み出しています。そこで、日経文庫の平井修一編集長に、さまざまなテーマでおすすめの日経文庫を解説してもらいました。今回は、20年、60年…と何十年も売れ続けているロングセラー11冊について。聞き手は、日経BOOKプラス編集・副編集長の小谷雅俊。 日経BOOKプラス編集・副編集長・小谷雅俊(以下、小谷) 今年、日経文庫は創刊70周年を迎えます。70年前というと1954年。日本史年表を見ると吉田茂内閣最後の年で、ゴジラ映画の第1作が公開された年です。これから高度成長期が始まるという時期ですね。改めて、その長い歴史を感じます。 平井修一編集長(以下、平井) 本当ですね。最初に出たのは『手形の常識』という本でした。実務的な内容の本が多いという傾向は、現代にも引き継がれていますね。こ
社内LT会の好評だったところ一部抜粋。 DDD関連の本を読み漁って、それぞれの感想一言メモと、どの順で読んだらいいか考えてみたやつを紹介。 2021/05/15 追記 こちらでも紹介した通り、最初に読むべきは現場で役立つシステム設計の原則(2017年発行)だと訂正したいと思います。紹介追記しておきます。 オブジェクト指向の考え方を用いて、変化に強い設計をするための実践紹介。リーダブルコード的な内容や、ドメインモデルの見つけ方、その実装方法など DDDと謳ってないが、やってることはDDD DDD特有のわかりにくい用語が全然出てこず読みやすい DDDを薦めるうえで、間違いなく一番最初に読んでほしい一冊 戦略的設計と戦術的設計 この記事でDDDの内容にはちゃんと触れないけどこの点だけ説明。 DDDの考え方、パターンは数あれど、それらは 「戦略的設計」と「戦術的設計」に分類することができる。 関連
大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。 私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。 タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。 上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それ
唱えたことが現実になる。 これはオカルトではなくテクノロジーの話だ。 常時装着したヘッドセットが人生を変える。 常時装着の有効活用 左耳の前を触ってみよう。きっとそこには「ボタン」がある。 そこにはブームマイクしかないが、という人は右側を触ろう。 本記事はこのボタンを有効活用する記事である。 何も無いとのたまう旧人類は早くヘッドセット常時装着(アップデート)してほしい。 前回の記事への反応で、「読んでAfterShockzを買った」というコメントをわりと見た。記事を書いた者として、せっかく買って常時装着するのなら有効活用してほしい。そこで前回の記事では触れていなかった活用方法、リマインダーへの音声入力の話をする。これは音声アシスタントへの入力端末を常時装着することの、真の価値を感じられる手法である。 これを前回紹介しなかったのは、俺はApple Watchで音声入力をすることが多いからであ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事はHow to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Mapを翻訳したものです。 翻訳がおかしい箇所などあればご指摘頂けるとありがたいです。 元記事の著者: Khalil Stemmler(@stemmlerjs) 設計、アーキテクチャ、フロントエンド、ブロックチェーンに興味ある方是非Twitter(@show_clements)フォローしていただけると嬉しいです! 設計に関する記事
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール岩瀬義昌氏:ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC(株式会社エーピーコミュニケーションズ)さんが「カプセルトイ
デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション(DX)」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。 システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。 そこでIPAでは、要件定義の過程で直面する問題への対応をガイドすることが、ユーザへのよりいっそうの支援策となると考え、「ユーザのための要件定義ガイド(初版)」の内容を一新し、「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」と
私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは2時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう?すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー
こんにちは、ユビーでプロダクト開発エンジニアをしている Sosuke Suzuki です。 最近、チームのエンジニア間の連携がいい感じだなーと思ったので、その要因の一つであるモブプログラミングについて、実践したことを紹介します。 はじめに 最近、私の所属するチームでは、データベース、バックエンド、そしてフロントエンドにも大きな変更を加える必要がある、規模の大きなプロジェクトに取り組んでいました(そして、今も同じチームで別の大きなプロジェクトに取り組んでいます!)。 そのプロジェクトの具体的な内容を書くことはできませんが、大雑把に事情を説明します。 数年前に設計されたいくつかのテーブルがあり、それは当時からずっとユビーのビジネスにとって重要でした。しかしそれらのテーブルは、この数年の間に複雑になったビジネス要件には耐えられなくなっていました。 このままではビジネスの機会を毀損することになりま
こんにちは、バクラク事業部のMLチームでソフトウェアエンジニアをしているTomoakiです。 今回はMLチームのスプリント管理におけるタスク・プロジェクト管理にNotionの新概念であるProjectを導入してみたら嬉しいことがたくさんあったので、それらを紹介したいと思います。 イントロダクション Notionの2.30リリースでプロジェクトという概念が登場し、プロジェクトの管理のテンプレートが公開されるなど大きなアップデートがありました。 www.notion.so 本記事でも紹介しますが、このリリースで紹介されているテンプレートが優秀すぎるので、まだみてない方は是非見てみてください。 MLチームでは5月末ごろから、ちょうどスプリント管理に課題感を感じており、早速NotionのProjectを取り入れて6月中に運用してみましたかなり良かったので、本記事では我々目線でのその効果を紹介したい
ソフトウェア開発において注目されるパフォーマンス指標には、デプロイに関係するものがあります。GoogleがDevOpsの取り組みから発表したFour Keysも、デプロイ頻度のほか、コミットからデプロイできるまでのリードタイム、デプロイにともなう障害発生率とその回復時間と説明されています。 そのためデプロイできるブランチへのマージは小さく、回数を重ねることが推奨されるようになっています。一方で、ビジネス用途のSaaSなどでは顧客との関係から、新機能は適したタイミングで完成度を上げてからリリースしたいという要求もあります。 タレントマネジメントシステム「カオナビ」の開発チームでも同様の課題感を抱えており、その解決のためFeature Toggle(機能トグル)を導入してデプロイとリリースの分離を図りました。その経緯や成果について、導入を主導したCTO室の富所亮さん、サービス開発部で実際にFe
こんにちは、Web Engineer の @wozaki です。 今回は、採用プロセスの改善として、職務経歴書に記載いただきたいことを公開した背景をご紹介します。 概要 職務経歴書に、採用チームとして期待する情報が不足していることがある 不足すると、以下の課題が発生することがある 書類選考は通過するが、その後の選考でミスマッチと分かる (経歴書が充足していたら、より早期にミスマッチが分かったかもしれない) 面接の前に経歴に踏み込んだ質問を設計できずに、面接時間内でマッチしているか情報を引き出す難易度が上がる 既存の対策として、情報の追記をお願いすることがある 新たな対策として、記載いただきたいことを ガイドとして公開 することにした 記載いただきたいこと 早期ミスマッチ解消の必要性 Web Engineer の採用は競争が激化している肌感があります。 応募者の方々にとっても、様々な企業の中
2023年4月中ごろから6月の今日までの2ヶ月と少しかけた転職活動が終了したので、記録ついでに振り返りたいと思う。 あくまで個人的な記録である。 応募手法 応募方法は、さまざまな方向から行った。 Twitterでの公開募集 エージェント経由 YOUTRUST経由 直接応募 Twitterでの公開募集 正直なところ、一回やってみたかったという部分が大きい。今回の転職活動における大きなチャレンジだった。ありがたいことに20社以上から声をかけていただいた。知り合いのフリーランスの方から「うちが関わってるところどうですか?」という声がけも3名からあった。その節はありがとうございました。 数は多いものの、話を聞く聞かないを考えなくてはならなくなり対応に追われた。公開募集とは、受動的な方法なのだと痛感した。また「会社名も書いてないから怪しいな?」と思ってDMの送信主を調べたら国際指名手配者だったという
2024年以降、NISAの抜本的拡充・恒久化が図られ、新しいNISAが導入される予定です。 まだあまり盛り上がっていないように筆者は感じるのですが、新NISAは個人が資産運用を行うにあたって是非とも取り組むべき制度です。 恐らく銀行や証券会社は新NISAではほとんど儲からないでしょうから、案内が微妙かもしれません。今回は、この新NISAが、特に定期的に収入がある個人にとって、いかに良い制度であるかを見ていこうと思います。 新NISAの特徴 新NISAがあればほとんどの世帯にとっては十分 所見 新NISAの特徴 とにかく新NISAの特徴はどのようなものかをまずは確認しておきましょう。以下が新NISAのポイントです。 非課税保有期間の無期限化 口座開設期間の恒久化 つみたて投資枠と、成長投資枠の併用が可能 年間投資枠の拡大(つみたて投資枠:年間120万円、成長投資枠:年間240万円、合計最大年
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く