Webサイト制作をどれくらいの粒度で分解してタスク化するか｜重松佑 / Shhh inc.
プロジェクトが始まるときにかなり初期の段階でWBSを作ることは多いとおもいます。そのWBSの作成、プロマネやディレクターに任せっぱなしになっていないでしょうか。WBSはスケジュールをガントチャートで表したものを指していると思われがちですが、実はスケジュールだけでなく見積もりやアサインを精度高く行うためにも重要なものです。 たとえば「Webデザイン作成」というスコープにどのような実作業が含まれているかはWBSを作ることによって見える化しプロジェクトメンバーやクライアントと共有できるようになります。ときどき下記のように書かれたWBSを見ることがあります。 Webデザイン作成 ・作成 ・確認 ・修正 ・確認2 ・修正2 ・確定 しかし、これでは「Webデザイン作成」に必要な知識、さらには作業量・スケジュール・予算も分かりません。Webデザイン作成の例を続けると、下記のように「作成」のスコープを分
DI はなんのためにあるのか - Qiita
この記事について DI (Dependency Injection: 依存性注入）とはなにか、という解説はよく見るんですが、なぜ DI か、という解説はあまり見ない気がするので、自分の考えを文書化しておこう、という試みです。 DI（依存性注入）とはなにか Wikipedia にある説明を載せるのに留めます。 コンポーネント間の関係はインタフェースを用いて記述し、具体的なコンポーネントを指定しない。具体的にどのコンポーネントを利用するかは別のコンポーネントや外部ファイル等を利用すること https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E3%81%AE%E6%B3%A8%E5%85%A5 Laravel での使用例です。Laravel においては、インタフェースを介さず、キーとなる文字列（クラス名、コンテナを用いる場合は任意の
SaaS系スタートアップのリアルなAWSアーキテクチャ設計
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア - Findy Engineer Lab
日本におけるテスト駆動開発の著名人といえば誰か？ この問いを投げかけられたとき、多くのエンジニアが思い浮かべる人物がいます。ITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さんです。和田さんは日本のテスト駆動開発の第一人者として、長年、この分野の実践や講演・執筆などの普及活動を続けてきました。 こう書くと、読者のなかには「和田さんはもともとテストが好きだったから、テスト駆動開発の第一人者になれたのでは」と思われた方もいるかもしれません。しかし、その答えはNOです。むしろ和田さんは、テストが嫌いなエンジニアだったといいます。ある出来事をきっかけとして、嫌いだったテストを好きになれる方法を見つけたのです。 読者の方々にも「自分には○○なんて向いていない」という印象を抱いている技術領域があるかもしれません。ですが、そんな領域にこそ、あなたの新たな可能性が詰まっているかもしれ
PUT か POST か PATCH か？ - Qiita
CRUDの操作をRESTで表現すると一対一で対応していないことに気づきます。RはGET、DはDELETEと考えておいて良さそうですが、CとUはPUT、POST、PATCHの3つの選択肢があり、APIを設計していると迷います。整理するためにまとめておきたいと思います。 下記の資料を参考にしました。 http - PUT vs POST in REST - Stack Overflow When to use PUT or POST | - The RESTful cookbook GitHub API v3 基本的な考え方 PUT: リソースの作成、リソースの置換 POST: リソースの作成 PATCH: リソースの部分置換 PUT PUTはPOSTと違い、リソース名を指定して作成または更新をかけるメソッドです。PUT /articles/3421は新規作成かもしれませんし、更新かもしれませ
Reactのprops/contextの使い分け - saneyuki_s log
Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき？」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数） 実装の指針
ちょうぜつ - Qiita Advent Calendar 2019 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可
はじめてのユーザーテスト 〜リモート編〜｜hitomi nabeno
コネヒト株式会社でデザイナーをしている鍋野です🍲 こちらはコネヒト Advent Calendar 2020 11日目の記事です。 先日なっぴさんがコロナの渦でユーザーインタビューを実施したことについてnoteを書いてくださっていたのですが、本日は最近リモートで実施をしたユーザーテストについて、いろいろと学びがあったので記事にしてみようと思います。 少しでも読んでくださったみなさんの参考になるとうれしいです。 ユーザーテストの目的今回ママリのアプリ内で一部機能のUIを大幅にリニューアルをすることが決まったため、ユーザーテストを実施することで ・新しいUIの操作感に迷いがないか ・リニューアルをしたあとのデザインを実際使ってみてどのような印象を受けるのか など、開発実装前に確認をすることを目的に、ディレクターの星野さんと私で社内のママさんにご協力いただき、簡易的なユーザーテストを実施しまし
あと2時間でElastiCacheのメモリが枯渇！そのときあなたは何をしますか？
突然ですが... あなたは、あるゲームプロジェクトの本番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか？ はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクトの本番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし
社内勉強会でサービスクラスがなぜ存在するのかについて紹介しました - UUUMエンジニアブログ
設計と実装で 抑えておきたい サービスクラスと例外 from Takuya Sato nazoです。 最近はUUUMもエンジニアを含む開発チームもメンバーが増えてきました。メンバーが増えてきた時に、どうしても技術力にムラがある（単純に高い低いという話ではなく、得意な点や考え方が個人により異なるということ）という問題が生じます。 個別の細かい技術についてはその場で説明すれば良いのですが、「設計」と言うと単純に説明するのは難しく、そもそも人によって考え方にも違いがあります。とはいえここは抑えておいてほしいというところはあるので、社内で勉強会を開催して説明した内容を社内向け文書も兼ねて公開したいと思います。 今回は「サービスクラス」の作り方について紹介したいと思います。サービスクラスという概念はバックエンドに限らず、フロントエンドやその他様々なアプリケーションで応用できる概念かと思います。資料に
Serviceクラスの意義と勘所 - Qiita
今回はRails界隈でもいくつかの議論がある「Serviceクラス」について 一つの考え方を書いていこうと思います Serviceクラスとは MVCやDDDにおいて分離させているレイヤーの責務が大きくなった際に活躍の場がある概念です DDDでは「ドメインサービス」と「アプリケーションサービス」とそれぞれのレイヤーで定義されていますが MVCにおいても「モデルサービス」「ビューサービス」「コントローラーサービス」みたいな考え方ができますね ただし、「ビューサービス」ではなく「ビューヘルパー」だったり、別に置き換えられたりします それ故、世間一般にいうServiceクラスは「ドメイン知識を持った手続きクラス」を指すことが多いです 意義 MVCなど完成された概念になぜServiceクラスが必要なのか？ その答えは肥大化したクラスを整理することにあります 処理系をまとめて、カプセル化し、責務を分け
この設計は何がダメなの?ー新人君の設計事例ー | しぶちょー技術研究所
以前、Twitterで呟いたもので反響が大きかった内容がありました。今回はその呟きに対すると皆様の回答について整理・考察していきたいと思います。 新人くんの設計事例 下記が私がTwitterで呟いた内容です。 【新人君の設計事例】 新人君が出してきた設計案。これは"やってはいけない締結"だよと色々説明したが、あまり納得してもらえず。上司も"部品強そうだし、問題ないでしょ"と一言。 個人的な感覚では、"絶対にダメな奴"なんだけど上手く納得させる説明ができなかった。皆さんならどう説明しますか？ pic.twitter.com/FYMZOu9dqx — しぶちょー (@sibucho_labo) September 5, 2020 ある日、新人君がこのような設計を提案してきました。ボルトの下は隙間になっていて、普段あまり見ない形です。詳細な意図は省きますが、他部品との干渉の関係もあり、こういう形
プログラミング上達したい人に繰り返し読んで欲しい4冊｜erukiti
プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか（例えばリファクタリング第二版） の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 追記
さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
オワコン大手SIerに学ぶアンチパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 軽い読み物としておもしろおかしく読んでください。 はじめて社外の人の仕事を見た 今まで社内の成果物しか目にしてこなかったのですが、ふとしたきっかけで外部ベンダーが作ったシステムを移行することになりました。 会社名を見て、よく知った会社でちょっと安心しました。 「ここなら設計書とかもきちんとしてるだろう、多少古臭くても堅実にやってるんじゃないかな」って思ってました。ええ。 実態は全然違った とんでもない量のExcelが設計書として渡されました。 さすがに設計が専門だけあって設計書の量はすごいなぁ。と思って読んでいるといろいろ察してきました
真偽値の判定に、tinyint(1)を使うか、bool,boolean型を使うか、bit(1)を使うか、enumを使うか - ぽひゅっとメモ
MySQLレベルでの話。 最近SQLの細かい挙動とか、しっかり把握しきれてないなーとか、 一度覚えたことが年が経ってあやふやになってるところが多くある。 また勉強し直したい。 RDBMSとうか、KVSだのNoSQLだのDBのシステムによって大きく違うと思うけれど、 私はMySQLとちょっとPostgreSQLとかSQLiteとか触ったくらいなしょっぱい男です(先の言い訳)。 主に扱うのはMySQLで、そのくらいしかついていけません(わかるとは言いません)。 「MySQLってそうなんだ〜。Oracleだとこうなんだよー、きゃははー」とか言われても、しょんぼりとしかしません。 本題。 Rails使ってると、マイグレーションファイルでDBのテーブル定義して、 rake db:migrateでマイグレーションファイルを元にテーブルが作成されちゃう。 ここで使うDBによって、うまいこと作られる型に差
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTにおけるべき等とは何を意味するのだろうか？
副作用（メール送信、データの更新、削除など）のある処理を、HTTP GETで起動..
進捗率を何で測るか？ −−情報処理技術者試験の問題より | タイム・コンサルタントの日誌から
