The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット
「プロジェクトマネジメントの基本が全部わかる本」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基本が全部わかる本」 （ @paradisemaker 著）が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある
良い設計と悪い設計の違い
2022年11月7日（月） 「現場で役立つシステム設計の原則 - Forkwell Library #9」 発表資料
コードは2回書きたい - Mitsuyuki.Shiiba
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
先輩エンジニアから「メモリを意識してプログラムを書かないやつは三流だ」と言われたのですが、今は令和ですよと言いたかったです。メモリを意識してプログラムを書く必要性を分かりやすく教えて頂けませんか？
回答 (25件中の1件目) 令和だろうがなんだろうが意識はしてないとダメだと思いますよ。 ハードウェア資源の限られた組み込み系やゲーム系は別として、業務系でもWeb 系でも 1バイトでも少なくなるように無駄を削るみたいなことはしなくてもいいでしょうし、たいていは解放漏れも意識しなくて良くなってます。 昭和〜平成初期のハードウェア/ ソフトウェア事情から考えれば、およそ足りなくなることが考えられないような大量のメモリーを使えはしますが、無限ではありません。 メモリー搭載量は予算次第で増減しますしね。 そして使えるメモリーの量よりも知識や想像力の欠如、考えなしのプログラミングからくる...
[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita
下記ドキュメントバージョンに関する注意点です。 バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。 ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを防ぐことができま
![[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7d131e38e26f54466aece3306435a4c09990de8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCRG9jJTVEJTIwJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgzJTg2JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFDJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgzJUJCJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgxJUFFJUU2JTlCJUI4JUUzJTgxJThEJUU2JTk2JUI5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz01MjE0ZDhhMTY1ZjE1ODIxNGE5NzU4Njc3MTNjOTBmNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzeWFudGllbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MTc4MmM0MTlmNzhiYTJjNTk0ODYwZmExZDc0OWYzNjQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db088349e276a1ebcdb9dcf1e2d753094)
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
2022年10月1日に開催された #postdev での発表です
ホテルの客室検索APIのアーキテクチャ設計時に考えたこと
作ったもののイメージ ホテルの客室検索APIとは、チェックイン日やその他の条件を入力として受け取り、マッチするホテルの客室を返すものです。以下の画像はExpediaのものですが、赤枠で囲っている部分（他にもたくさんある）が入力になります。2022年4月頃に無事リリースされました。 この検索APIを構築を任された際に、何を考えて設計していったのかを以下に示していきます。 顧客からの要望 顧客の会社は当時エンジニアがおらず（やりとりしている社長は元エンジニアだが）、これまでも私と仕事をしたことがあったので依頼が来ました。顧客と密にコミュニケーションを取りわかったのは、以下のような要望でした。 このAPIは自社サービスとして第3者（要契約）に使ってもらえるようにしたい 完全に一般公開ではなくちゃんと契約を結ばないと利用できないようなもの 検索条件を柔軟に、かつ使いやすい感じで指定できるようにした
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
2022年におけるフロントエンド開発のベースライン
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
増え続けるTODOコメントに立ち向かう - Sansan Tech Blog
データ戦略部*1でエンジニアをしています、22新卒の金子です。 突然ですが、皆さんはコードにアノテーションコメントを使っていますか？アノテーションコメントというのはTODO、FIXME、NOTEなど、コメントに何かしらのプレフィックスを付けて、コメントの意図、性質を分かりやすくするというものです。 今回の記事では、その中でも最もよく使われるであろう、TODOコメントとの向き合い方について考えたいと思います。 TODOコメントの問題点 何の気なしにTODOコメントを使っていると、以下のような問題が生じます。 数カ月前に書かれたTODOコメントが未対応のまま放置されている。 対応済みのTODOコメントが消されていない。 メンバーによってTODOコメントの温度感が違う。 このような理由から、TODOコメントは増加の一途をたどります。私の所属するプロジェクトはまだ発足から日が浅く、古くとも数カ月前
文化シヤッターのシステム開発頓挫で、日本IBMが19.8億円の賠償を命ぜられた理由
システム開発の頓挫を巡る、文化シヤッターと日本IBMとの間の裁判で、東京地方裁判所は日本IBM側に19億8000万円の支払いを命じた。米セールスフォースのPaaSを用いた販売管理システムの構築を目指し、2015年に始めた開発プロジェクトだったが、2017年にストップしていた。東京地裁は開発失敗の原因をどう認定したのか。裁判記録をもとに読み解く。 文化シヤッターが、20年以上前から使用していた販売管理システムを刷新するプロジェクトを本格的に始動させたのは2015年1月のことだ。日本IBMに提案依頼書（RFP）の作成を委託。そのRFPを基に複数ベンダーから提案を受けた上で、日本IBMを開発委託先として選定した。 日本IBMの提案はシステム構築に米セールスフォースのPaaS（プラットフォーム・アズ・ア・サービス）である「Salesforce1 Platform」を用いるものだった。RFPでは標準
営業日などの規則性と例外を扱うための設計
解決したい問題 例として、飲食店の予約サービスを考える。 予約を受け付けるためには各店舗の営業スケジュールを管理しておいて、営業日の営業時間内のみ予約を受け付けるようにする必要がある。 たとえば、ある店舗は各曜日の営業時間について、以下のように定めているとする。 平日：11:30-22:00 土曜日：11:00-22:00 日曜日：11:00-21:00 定休日：木曜日 これを素朴に設計すると、たとえば以下のような「営業日については営業時間を保持し、定休日についてはレコードがない」というテーブルになるかもしれない。 店舗 曜日 開店時刻 閉店時刻
個人開発のコストはDB次第 - laiso
個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある 「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。 そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。 通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。 ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。 仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいか
Web開発者の悩みの種ランキング（2021年版） | POSTD
私は先日、開発者が何を最も大きな課題に挙げているかを知ることで、開発者コミュニティのニーズを理解できるという記事を書きました。 元々の投稿はMDN Developer Needs Assessment（2019年）の結果を要約したものでしたが、不運なことに、この調査は2020年に中止されました。この調査情報は、Webプラットフォーム全体の方向性を定めるのに役立つ点で、私たちのチームにとって重要だったため、調査の中止は残念なことです。 調査を実施していたMozillaの代わりとして、私はチームのために、開発者の大まかなニーズを把握する調査を企画しました。 3カ月ごとに、米国、英国、インドのWeb開発者やWeb開発における意思決定者約700人をランダムにサンプリングして実施し、過去に実施したすべての調査とデータを比較して、トレンドに変化があるかを見ていきます。 注意すべきなのは、MDN Sur
ほんの少しHTMLを変更して検証したい時 – TravelBook Tech Blog
本番のサイトを眺めていて、「あーここのHTMLこうしたら、もっと速くなるのになー」って思う時ありますよね。 僕はあります。でも、検証するだけのために、プロダクトのコードを直接いじるのは大げさ。 そんな時に、wgetとmirrorというコマンドを使ってページをダウンロードして「ほんの少し」HTMLを変更しています。 紹介します（追記にLocal Overridesという「そのものズバリな」Chromeの機能も紹介してます）。 最近あった話です。特にCore Web Vitalsとか速度改善について。 トラベルブックのとあるページのスコアが落ちていて、Chrome DevToolsで観察してみると、どうもYouTubeの埋め込が足を引っ張っている。 表示領域外にも関わらずiframeの中身がロードされています。 これは直したい（本来なら本番へ上げる前に気づく仕組みを作りたいのですが、一旦置いて
ブラウザで動くサービスを作るときの技術選定
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
art-of-readme/README-ja-JP.md at master · hackergrrl/art-of-readme
提案依頼書に含まれる 無理難題の分類
開発環境へのこだわり
