「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
受託開発でアジャイルソフトウェア開発を始める - @ledsun blog
はじめに 「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。#devlove - HOW TO GO というブログエントリに 受託でアジャイルはどうなのか？ という記述がありました。世の中には受託でアジャイルをどうやって始めるのか悩んでいる人がいるらしいので、体験談を書きます。 ざっくり言うとハイブリッドアジャイル*1です。 請負契約でアジャイルっぽくやるための方法です。 業務委託で契約できるなら（開発側は）リスクが低いのでその方がおすすめです。*2 それから「ディシプリンド・アジャイル・デリバリー」は未読です。読んだ人には釈迦に説法かもしれません。 三回以上の分割納品 始めるのは簡単です。お客さんにスケジュールを提示する際に納品を3回以上にすればOKです。 最初に提示すれば納品回数を一回に変更したがるお客さんはいません。 同じメンバーで同じシステム
プログラマのためのカラーパレットツールを作りました - shoya.io
Paletta - HSV Color palette for every Programmer 背景 フラットデザインの台頭によって、昨今のアプリ/サービス開発において「色選び」が重要視されています。例えば上の写真は次のトイレの時刻を機械学習で予測するRestCastというアプリですが、「いい感じの青」を基調としたタイルを敷くことで、トイレというワードをニオワセないデザインに仕上がるよう心がけてつくりました。 デザイナー/プログラマーの皆さんは普段どうやって色を選んでいるのでしょうか。多くの場合、既存のカラーパレットをぽちぽち選択したり、#123456のようなカラーコードを調整するのではないかと思います。実は、この方法で「いい感じの色」を選ぶのは難しいのです。その理由を色の表現方法を踏まえて説明します。 混色系と顕色系 色を数値で表現する方法を表色系といいます。オストワルト表色系やマンセ
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
優れた仕様を決定するために必要なこと - GoTheDistance
たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない？
スクラムに関する無料の日本語資料のまとめ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムを学習するにあたって参考になる【無料】の資料を以下にあげておきます。 僕がコーチングする際は上２つの資料については事前に読んでもらった上で、トレーニングを実施したりしてます。 スクラムガイドスクラムの父であるジェフ・サザーランド氏とケン・シュエイバー氏が書いた公式のルールブック。 これを読まないでスクラムをやるのはマズイです。 http://www.scrumguides.org/日本語版は、多くの本の翻訳をされている角さんが訳されてます塹壕よりScrumとXP昨年開催したScrum Gathering Tokyoで基調講演をされたヘンリック・クニベルグ氏によるScrumとXPの実践事例。 どういう問題がおきてどう改善したかも分かる。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-t
データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
第51回 ソフトウェア品質保証の温故知新 ～先達の知恵に学ぶ～｜SQiP：Software Quality Profession
「ソフトウェア品質のホンネ」連載中！ SQiPポータルサイトでは、SQiP委員のソフトウェア品質へのその想いをコラム的に綴る 「ソフトウェア品質のホンネ」のコーナーを好評連載中です。 肩肘張らずに気軽にお読みいただける内容を掲載していきますので、お仕事の合間などに是非ご覧ください！ ※本コーナーに対するご意見、ご感想がありましたら、sqip@juse.or.jpまでお寄せください。 ■はじめに ソフトウェアの品質保証問題は古くて新しい課題であり、これからもソフトウェア開発関係者の頭を悩まし続けるでしょう。 ソフトウェア品質保証の方法論を考えるとき、二つの切り口があると思います。一つ目は、ソフトウェア開発そのもの方法論・技法、開発環境を高度化し、開発そのもので品質を向上させる考え方です。二つ目は、開発管理技法を適用し、開発過程の品質を監視・制御する、すなわち、管理のPDCAを廻しな
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
アジャイル開発の反対はウォーターフォール開発じゃなくて「おまかせ」だと思う - 思っているよりもずっとずっと人生は短い。
メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する（という言い方が悪ければ「最大限許容する」と言い換えてもいい）というものだろう。文書や契約や計画は、あらかじめ（多少はコストをかけて）まとめておけば、それ以降のコミュニケーションは省略できる（ような気になる）、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協
Sphinx-Users.jp :: ドキュメンテーションツール スフィンクス Sphinx-users.jp
Sphinx-Users.jp¶ Sphinx-Users.jp(略称#sphinxjp)は、美しいドキュメントを簡単に生成することができるドキュメンテーションツール、 Sphinx （スフィンクス）の普及を主眼としたコミュニティです。SphinxはPythonの公式ドキュメントだけでなく、このSphinx-Users.jpのサイトも含め多くのマニュアルやサイトで使用されており、詳細を Sphinxの歴史で紹介しています。 Sphinx-Users.jp は日本の Sphinx コミュニティです。 Sphinx-Users.jp では、日本で散らばっているSphinx関連情報を集めて、Webサイト、イベントを通じてSphinx情報を発信します。 slack のコミュニケーションや勉強会の開催などを通じて、ドキュメントをパワーアップしたい人、ドキュメントや翻訳で苦労している人、Sphinxの
本の虫: 新しいビルドシステム、ニンジャ
Chromium Notes: Ninja, a new build system ChromeをWindowsから移植し始めたとき、我々はSconsを使ってChromeをビルドしようとした。Sconsは、正しく動作して、使い方も簡単であった。しかし、開発を始めてすぐに、Sconsはとても遅いということに気がついた。ソースを実際にビルドし始めるまでに、40秒もかかるのだ。Sconsが全面的に悪いというわけでもない。Chromeのビルドは、たったひとつの実行ファイルのために、WebKitも含めて、30000ものファイルがあるのだ。 結局、私はLinuxビルドのために、単にMakefileを使うことにした。これは、我々のビルドシステムが、メタビルドシステム、すなわち、WindowsやMac用のビルドファイルを生成するビルドシステムだったから可能だったのだ。開発を進めるほどに、私はどんどんビルド
日本Jenkinsユーザー会
ผู้ช่วย ผู้บังคับบัญชาตร. ยืนยันมิได้แกล้ง กรณีส่งตำรวจไปถามลูกค้าที่ซื้อสลากฯ จากกองสลากพลัส แค่ต้องการเก็บหลักฐาน จากกรณี แม่ค้าออนไลน์ที่ จังหวัดจังหวัดเชียงใหม่ เผยแพร่คลิปวีดีโอเหตุการณ์ที่มีตำรวจ ขี่รถเครื่องมาหยุดที่หน้าบ้านเมื่อวันที่ 1 กุมภาพันธ์ ขอให้ไปให้ปากคำกับตำรวจ สภ.สารภี จังหวัดเชียงใหม่ โดยขอให้ปากคำในฐานะผู้เห็นเหตุการณ์คดีกองสลากพลัส ขายสลากเกินราคา แต่เจ้าของบ้านไม่สบายไป ถัดม
AsakusaSatellite | 開発者向けリアルタイムチャットアプリケーション
動作環境 Ruby 1.8.7 / 1.9.3 / 2.0.0 / 2.1.0 or JRuby 1.7.1 RubyGems 1.4.2 or later Bundler 1.0.7 or later MongoDB 1.8.1 or later Google Chrome / Firefox / Safari 詳細は AsakusaSatellite documentation - セットアップ をご覧ください。 インストール ダウンロードページ から最新版をダウンロードし、展開してください。 展開したディレクトリを AsakusaSatellite にリネームし、以下のコマンドを実行してください。 $ cd AsakusaSatellite # 依存ライブラリのインストール $ bundle install --path .bundle --without development t
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
ヤフーにおけるパッケージ管理 - Yahoo! JAPAN Tech Blog
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R＆D統括本部 開発推進室 セキュリティプラットフォーム技術の戸田 薫です。 個人的に自宅では、 FreeBSD でよく遊んでいて、FreeBSDのパッケージ管理には、portsnap、portupgrade を利用していますが、ヤフーでは独自の方法で行われます。 その背景としてヤフーには、平均15億以上のPVを支えるためやサービスの付加価値のために何万台ものサーバがあり、サービスやシステムごとに大規模なシステムを構成する必要があるため、一般的なパッケージ管理システムよりもより柔軟で効率的なパッケージ管理が必要となっています。 今回は、ヤフーにおけるパッケージの管理についてご紹介します。 ヤフーインストーラ ヤフーでは
オープンソースによる新しい受託スタイルの提案
前々回のエントリ「受託開発とGPL」では、受託開発においてGPLのソフトウェアを用いる際に注意すべき点やライセンスの扱いについて書いた。ただし、その視点はあくまでも「GPLはSIerにとって注意すべき≒厄介なシロモノであり、如何に地雷を踏まないようにするか」というものであったように思う。だが、「厄介である」という性質は、裏を返せば「味方につけると頼もしい」ということだ。つまり、GPLは、味方になれば強力で頼もしい存在なのである！今日は、SIerが今の開発スタイルから脱却し、如何にしてGPLを味方につけて戦っていくかということについて語ろうと思う。ちょっとひどい妄想夢物語的な記述も入っているのだが、「何言ってんだコイツ？！」とツッコミたいところをぐっとこらえて最後までお付き合い頂ければ幸いである。 システム全体を再構築するのは大変SIと一口で言ってもその規模は大小様々であるが、業務（基幹系）
Pivotal Trackerの「Getting Started」を翻訳しました - Ruby x Agile
ストーリーベースの計画づくりのためのツール、Pivotal TrackerのGetting Startedのページを永和システムマネジメントの有志で翻訳しました。開発元であるPivotal Labsの許可を得たので公開します。どうぞご利用ください。 Pivotal Tracker: はじめかた Pivotal Trackerについて 永和システムマネジメントでは、まだ一部ではありますが、社内やお客さま向けのプロジェクトで3月頃からPivotal Trackerを使っています。Pivotal Trackerは kakutani が翻訳者のひとりである『アジャイルな見積りと計画づくり』の考え方をほとんどそのまま実装したようなとても素敵なツールで、プロジェクトにおける計画や見積りといったプロセスをアジャイルにしていくことを強力にサポートしてくれます。 現状は英語UIのみであるにもかかわらず、一緒
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
