運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
Software is Beautiful | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
最近盛り上がってきた「かんばん」、ソフトウェア開発における「かんばん」（Kanban）とは何か
ここ数カ月、ソフトウェア開発の話題で「かんばん」（英語でも「Kanban」）という言葉を目にする機会が増えてきました。かんばんとは何で、どのようなものなのでしょうか？ 勉強がてら、いくつかのサイトを紹介していきましょう。 ビギナー向けの「Kanban101」 今年3月にかんばんビギナー向けのサイト「Kanban101」が立ち上がりました。このトップページがかんばんの特徴をよく表しています。 ソフトウェア開発におけるかんばんとは普通に日本語の「かんばん」のことで、誰でも見えるところに置かれて、ホワイトボードや黒板になっていて、記入したり、この画面のようにポストイットを貼って運用するのが一般的です。 かんばんの効果とは、このかんばんを模した画面に書かれているように「仕事のみえる化」「仕掛かりを減らす」「流れを見えるようにする」ということ。このサイトは英語ですが説明がとても簡潔で分かりやすいもの
自分にとっての情熱プログラマー - 未来のいつか/hyoshiokの日記
先日、情熱プログラマー読書会が楽天であったので、参加した。LT(Lightning Talks)で発表もした。発表スライド 情熱プログラマー 自分にとっての情熱プログラマーってなんだろうと考えた。 この「情熱プログラマー」という書籍は、ソフトウェア開発者の幸せな生き方という副題がついているのだが、純粋な技術書というよりもプログラマーにとっての自己啓発書みたいな位置づけの書籍だ。 ソフトウェア開発におけるプログラマという役割を取り替え可能な部品のような立場から見れば、プログラマはコストであり、どのようにしてそのコストを削減するかということになる。コストを安くするという考えで行けば年功序列的な賃金体系の中ではベテランより若いひとを使った方が安く上がる。数字でソフトウェア開発を見ていけば人月工数がすべてであり、開発コストは工数＊人月単価になる。 そのような立場で言えば人件費の高い日本で開発するの
楽天で角谷さんのお話を聞いた - 未来のいつか/hyoshiokの日記
解読アジャイルソフトウェア開発というタイトルでお話をしていただいた。*1 アジャイル開発の本質を角谷節で1時間あまり独演会してもらった。 Demystifying Agile Software DevelopmentView more presentations from Eiwa System Management, Inc. . ともかく映像を観てほしい。約1時間ちょっと、そしてその後に続く質疑応答も一緒に。 ソフトウェア開発における受託開発という立場ではない、もう一つのソフトウェア開発の現場が、自分のサービスを自分で作るという立場だ。 受託開発の場合はユーザー企業（発注する側）と開発する企業（受託する側）とがあって、時として敵対関係に陥る。一方の利益が他方の損というゼロサムゲームである。 自社開発の場合は、社内にユーザ部門と開発部門があったとしても、最終的にはユーザ部門の利益と開発部
サディストのための Ruby メトリクス計測入門 - たかみやの日記
ふぬけたコードをきたえるRuby で書かれたソースコードのまずい部分をメトリクス計測ツール (reek, roodi, flog, flay) を使って機械的に発見しましょうというお話です。それぞれのツールは次のことをチェックしてくれます。 reek: リファクタリングできそうな部分を発見 roodi: (reek とは別の指標で) リファクタリングできそうな部分を発見 flog: 複雑すぎる部分を発見 flay: 重複している部分を発見ポイントは、さまざまなチェックを rake コマンド一発でビシッとできるようにすることです。こうすることによって、その日の気分に左右されることなく一貫した厳しいチェックが繰り返しできるようになります。なおこの日記は、この記事を一部参考に書きました。ありがとうございます。 使い方コマンド一発で計測できます。 % rake quality もしコードにまずい部
SEMAT の「ビジョンステートメント」全文日本語：An Agile Way：オルタナティブ・ブログ
SEMAT.org から出ている、Ivar Jacobson, Bertrand Meyer, Richard Solely 連名の、 ソフトウェア工学の方法論と理論 (SOFTWARE ENGINEERING METHOD AND THEORY – A VISION STATEMENT) By Ivar, Bertrand and Richard を日本語訳しました。概要は、前回のブログを参照してください。 日本語訳: http://blogs.itmedia.co.jp/hiranabe/files/SEMAT-vision-ja.pdf 日本語訳の公開について許可をもらっていますが、レビューを受けていないので、正式文書はあくまで、英語の原文です。 原文: http://www.semat.org/pub/Main/WebHome/SEMAT-vision.pdf 先週、スイスのチュー
プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。彼らの考え方については、面接時に少しやり取りを行えばそれなりに見当が付くだろう。しかし、実際のプログラミング経験を推し量るのは至難の業だ。一部の企業では、さまざまなテストを実施することでこれを行おうとするものの、筆者の経験から言えば、こういったテストは近代的な開発環境では必要性が薄い知識（IDEのオートコンプリート機能や、F1キーの押下で表示されるヘルプ、インターネットといったものがあるため、ライブラリの知識は以前ほど重要ではなくなっている）の丸暗記能力を試すだけに終わることも多い。そこで本記事では、開発者を評価するうえ
今年注目のツール - プログラマの思索
面白い記事があったのでメモ。 明鏡止水: 今年のサーバーの楽しみ 僕が今年注目するツールは下記の通り。 Redmineは0.9.2が出て、使い易くなった。 プラグインが対応すれば、OSSのプロジェクト管理ツールの中でもかなり良い部類に入ると思う。 TestLinkも1.9beta2が出て、今年中に1.9が出るだろう。 要件管理、レビュー管理ができるそうなので、楽しみ。 特にTestLinkは使い辛い部分が多いので、どんどん改善して欲しいと思っている。 TestLinkによるテスト管理、要件管理は、かなりのポテンシャルがあると思っている。 個人的には、Review Boardを使いこなしたいと思っている。 コードレビューは重要と分かっているにも関わらず、結局実践出来ていない。 それから、教育管理システムMoodleにも注目している。 IT技術者にとって使う機会は少ないけれど、教育もWeb化で
ソフトウェア開発の諸問題はソフトウェアで解決する - プログラマの思索
課題と今後の目標 * ソースと要件の結びつけはできる * でも、テストケースとソース、 テストケースと要件の結びつけが できていない * テストケースのバージョン管理って どうやればいいんだろう？ * ツールは？ * エクセルはもう使いたくない この回答は僕は持っている。 TiDD＋TestLinkがその答えになる、と。 下記の記事を偶然見つけた。 プロジェクト管理は専用ツールを使うのが鉄則 － TechTargetジャパン (前略) プロジェクトマネジャーがプロジェクト管理専用のツールを使わない場合、それは彼らがしかるべき教育と訓練を受けていない証拠なのだ。 WordやExcelを使ってプロジェクト管理を行うと、間違いなくビジネス全体に悪影響がある。例えば、リソースの利用可能量やプロジェクトの状態、プロジェクトポートフォリオ全体の健全性が見えにくくなってしまう。プロジェクトの観点から見る
趣味のプロジェクトをきちんと仕上げるには? | スラド IT
金をもらってやるプロジェクトだと、完全なロードマップや納期もあるし、プロジェクトに集中することになる。しかし趣味でやっているプロジェクトは完成したためしがなく、品質にも納得したことがない。なぜだろう? 思うに以下のような問題がありそうだ。 自分に最もアピールする機能にばかり目が行って、他のところに手が回らない落ち着いて作業できる時間、まとまった量の時間をプロジェクトに割けない外部からのプレッシャーがない新技術の練習として、実験的に同じプログラムを違う言語やライブラリで実装することが多い。よって、機能的には進歩がない これに対する処方箋として次のようなものはどうだろうか。 最小限の機能セットを定義し、そこが終わるまでカッコいい機能の開発には取りかからない休暇や週末など、まとまった時間を割ける時だけ手をつける自分でデッドラインを設定して、達成したら自分にご褒美を出す実験はほどほどにする
プロダクティブ・プログラマ
TOPICS Programming , Business/Essay 発行年月日 2009年04月 PRINT LENGTH 284 ISBN 978-4-87311-402-6 原書 The Productive Programmer FORMAT PDF 生産性の高い人はそうでない人に比べ、同じ時間でより多くの仕事をし、より多くの成果を上げることができます。本書は、ソフトウェア開発におけるプログラマの生産性についての書籍です。プログラマ個人が、どのような意識を持ち、どのようなツールを使えば、単位時間当たりの仕事量を増やすことができるかについて示します。本書は2部からなり、「I部 技法編」では、作業を自動化するためのツールや集中を維持する方法など、開発に必要な作業の生産性を向上するテクニックとツールを解説します。「II部 実践編」では、テスト駆動開発や、メタプログラミングなど、生産性を
杉浦とソフトウェア開発
杉浦とソフトウェア開発 ダウンローダをお使いの皆様へ そういえば、秀和システム様より、筆者の「対戦型五目並べ」が、デザパタ入門書として「あなたのコードを[賢く]するデザインパターン Java プログラミング」というタイトルで出版されることになった。７月中旬に店頭に並ぶ予定である。定価は2800円と決まった。著者のクセにシレっと言ってしまうが、内容比だと相当にお買い得だな。ぜひぜひ買ってくれたまえ。より詳しくは→「あなたのコードを[賢く]するデザインパターン Java プログラミング」 私は古手のプログラマである。学生時代から、プログラマ以外のバイトをしたことがない。今まで書いたことのある言語というと、Basic, C, Fortran, Cobol, Scheme, C++, Java, Intel Assembler, Perl, Tcl/Tk, PostScript あたりか。あ、ほと
Ed Yourdon の『ソフトウェア工学で大切な１０の考え方』を訳しました。：An Agile Way：オルタナティブ・ブログ
先日、尊敬するエドワード・ヨードン博士が「Top 10 Software Engineering Concept」という文書の公開した、とtwitter でつぶやいていたので、「訳してもいいですか？」と聞いて、5分でOKをもらった。なんというインターネット時代だろう。 slideshare で見る PDFをダウンロード 原文を見る ヨードン博士の動機は、 不況時代に突入し、今後デスマーチが一気に増えるであろう。でも、ソフトウェア工学の大切な考え方は、そんなに昔から変わっていないんだ。新しい世代は、すごいよ、学生はみんなIMで会話して、Facebookで繋がっている。COBOLプログラマがまだ存在しているなんてことは知らないんだ。でも、ソフトウェア工学の大事なことは、なんども新しい世代が、同じ事実を発見し、過去の重要な論文や書籍にぶち当たる。ここで１０個上げて、フリー文書にしておくので、共有
スクリプトを使ったテスト駆動プロトタイプ開発<br> 設計仕様としてのテストコード
はじめに 本論文では，先に提案したスクリプトによるプロトタイプ開発手法の問題点を考察することから，テスト駆動開発手法を取り入れて，システム仕様となるテストコードの開発を主眼とする設計法を提案している．さらに，具体例として「バトル鉛筆」という戦闘ゲームに本手法を適用して，この設計手法を解説している． スクリプトによるプロトタイプ開発の概要 「ゲーム作りで学ぶオブジェクト指向開発」においては，UMLのオブジェクト図を用いたトップダウン的な設計からスクリプトによるプロトタイプ開発を提案していた． その方法では，以下のような４階層のアーキテクチャを導入している． ユーザーインターフェース層 具体的な開発手法としては，以下の手順に従う．まず，スクリプト言語を使ったプロトタイプを以下の要領で設計・実装し，うまくいくか全体の見通しを得る．プロトタイプなので単純に徹し，素早く作ってフィードバックを得ること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
契約書のツボ(3)
ソフトウエアって人と人をつなぐもんだと思う (arclamp.jp アークランプ)
都市シミュレーションと教育・学習をテーマ とした報告書。