タグ

ブックマーク / qiita.com/hirokidaichi (5)

  • なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita

    はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

    なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
    t-wada
    t-wada 2021/11/02
    スケールメリットが必要なら、コミュニケーションコストの低い組織とプロダクトの実現が重要。コストパフォーマンスが必要なら、大人数の大型プロジェクトではなく小プロジェクトに分解しながら進めることが重要。
    リンク

  • もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita

    はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo

    もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
    t-wada
    t-wada 2016/04/04
    UI Flows を Markdown 風の記法で書けるエディタ。すばらしいアイデアだと思う。
    リンク

  • [翻訳]なんでGoってみんなに嫌われてるの？ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 原文：http://npf.io/2014/10/why-everyone-hates-go/ 酔っぱらった勢いで訳出してるので、違ってたら修正リクエストください。 訳者の１行でわかるサマリ それって、Goのシンプルな言語哲学が、ML系言語好きのアイデンティティを挑発しちゃってるからじゃないの？ なんでGoってみんなに嫌われてるの？ いや、実際みんなって訳じゃないんだろうけど。最近、なんてGoをみんなそんなに批判的なのかって言うquoraの質問が出たもんで。（わるい、普段はquoraへのリンクを張らないんだけど、それがこの記事のきっかけ

    [翻訳]なんでGoってみんなに嫌われてるの？ - Qiita
    t-wada
    t-wada 2014/10/17
    “人は、その人のアイデンティティの一部となっている事について、実りある議論はできない” "クールエイド（信じ込んでいるのを馬鹿にしやすい）ポイント" 示唆に富んでいる
    リンク

  • isomorphicなJavaScriptプロジェクトのパッケージ管理 - Qiita

    Node.jsでフロントエンドもバックエンドもJSのプロジェクトをはじめる際に、 それぞれのパッケージ管理をどのようにするか悩んだ記録。 要件としては、 1.フロントエンドもrequireでmoduleの探索をしたい 2.フロントエンドとバックエンドでパッケージ管理を分けたい 1を満たすためにcomponent.jsかbrowserifyか悩んだ。 browserifyは作りが怖かったが、component.jsはもっと怖かった。 browserifyを単純に使うとnode_modulesを共有してしまうので、 2が満たせない。debowerifyというpluginがあるようなので、 フロントエンドはbower_components/にという方針でやってみた。 // バックエンドの依存管理 package.json // バックエンドのパッケージ置き場 node_module/* // バ

    isomorphicなJavaScriptプロジェクトのパッケージ管理 - Qiita
    t-wada
    t-wada 2014/09/16
    Isomorphic な JS プロジェクトでフロントエンドに browserify を使うとバックエンドと package.json が混ざりそうだけど、どうする? という話。
    リンク

  • microservicesに分割する際に注意するべき5つのこと - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくこと

    microservicesに分割する際に注意するべき5つのこと - Qiita
    t-wada
    t-wada 2014/09/09
    microservices への移行を行う際に考慮しておかなければならないことが述べられている "microservicesへの分解は、実のところ組織パターンの問題です"
    リンク
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2025 Hatena. All Rights Reserved.