『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
チケット駆動開発を運用する上で、あった方がよいと思う運用ノウハウをプラクティスとしてピックアップしてみる。 なお、下記には、他の人のアイデアも含まれているので、引用先をリンクしておく。 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 チケット駆動開発のベストプラクティスを収集したい: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 チケット駆動開発 - Live a meaningful Life チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11) 2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記 チケット単位に並行開発する事例: プログラマの思索 [tech]チケット駆動開発 - Kazumi
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
交わるときが、来た。 ライ麦畑のエントリが書かれたのはもう、1年以上も前のことだった。 このエントリが書かれた頃、私は、DevLOVEでアジャイルプラクティスの読書会を開催していた。 社内に閉じていたコミュニティが、社外を巻き込み始めた丁度そんなタイミングだった。 ライ麦畑のエントリもあって、そのときの興奮する思いで書きなぐったエントリの最後に、こんな言葉を添えた。 行動を起こす人々が、どこかで、交わったら。 この業界が変わるわけがないと、言う人はまだいるだろうか。 交わるときが、来た*1。 【DevLOVE2009】世界一言語トークス 〜Python〜 開発の楽しさを味わう。それは最初に掲げたこと。 勉強会カンファレンスで社内勉強会の事例を発表したおり、一緒の枠で話していた方に、Kwappaさんが居た。そのときは、全く絡むこともなく その後、MSのとあるイベントで共演した際に、Kwapp
2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト
昨日、ウェブキャリアさんが主催する月間524万人が利用する食のインフラ、「クックパッド」のものづくりセミナーに行ってきました。 クックパッドと言えばRails での大規模リニューアルがニュースになりました。また、大規模開発には向かないと言われたこともあるRails でこれほど大規模なサイトを開発するノウハウに興味があり、参加しました。 めちゃくちゃ良い情報を得ることができました。これはすごいセミナーでした。以下、まとめです。メモ不足だったので、一部他のサイトの情報を元にまとめています。 CookPad 概要 サイト レシピ検索No.1／料理レシピ載せるなら クックパッド Rails で作られたサイトの中、ユーザ数で世界で8番目の規模 rails100 wiki / Alexa Rankings Rails で作られたサイトの中、ページビューでは世界で2番目 構成 Rails 2.0（現在2
ソフトウェアを創造するエンジニア。しかし、その仕事は本当に「創造的」だろうか。仕事を創造的なものに変え、価値を生むための発想法を紹介する。 前回、自分の中に宝物が眠っていることを知った。どうすれば自分の宝物を掘り当てることができるだろうか。宝物探しの出発点は、身の回りに散在している問題を考えることだ。身近な問題を解決することができれば、その効果を直接獲得できるばかりでなく、解決策形成の体験を通じて、将来発生するであろう問題を解決するための応用力も獲得できる。 自分にとって身近な問題、自分のプロジェクトや自社が抱えている問題、あるいは自分のお客さまが抱えている問題に取り組むことから始めるといい。そして、問題解決のアイデアや提案を生み出し、自分だけでなく、プロジェクトチームにも、会社にも、そしてお客さまにも喜んでもらおう。 ■解決すべき問題をはっきりつかむ 前回挙げた、「身近な問題の例」を再掲
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
※ 画像は一部公式サイトデモより Web2.0（？）の特徴はCGMや共有と言ったキーワードだ。サイト側から与えられるコンテンツではなく、ユーザが皆で協力してコンテンツを作り上げていく楽しさがある。ブックマーク、ニュース、コミュニティ…様々な要素がシェアされている。 そうした中、これもまた新しい共有の要素になるだろう。それはソースコードだ。 今回紹介するオープンソース・ソフトウェアはReview Board、ソースコードレビュー共有サービスだ。 Review Boardはリポジトリを登録し、そのDiffファイルを使ってReview Board上でソースをグラフィカルに表示する。そして差分に対して皆でコメントしていくのだ。ソースの一部分に対して的確にレビューできるので、分かりやすい。 SubversionやCVS、Perforce、Git、Mercurialのリポジトリに対応している。興味深い
Mac, Lifehack, Tool追記：書いた直後にマイコミジャーナルさんで同じソフトウェアの紹介記事が出ていることに気がついてしまった。しかも数日前に。二番煎じでしたね...でも集中するには本当にいい組み合わせなのでぜひどうぞ。http://journal.mycom.co.jp/column/lifehack/065/index.htmlMacにどっぷりはまっている方ならご存知のものかもしれませんが、私の作業効率はものすごく上がったので紹介します。 最近私は特に土日なんかは家でも作業することが多くなっています。いま本を書いているのでとにかく机に向かってひたすら文字を打ち続けていくのですが、これにはとにかく集中力が重要。テレビは見ないのでＯＫ。音楽はむしろ静かに流せば適度な雑音になってくれるのでＯＫ。問題は、ネットです。Macを使って作業してるので常にネットに接続している。twitt
やたらと豪華なメンバーで話題沸騰のイベント、ITpro Challenge!に行って来た。 定員70名の中のラッキーな一人だったのでさっそくレポート…というかただのメモ。 もし会社員のままだったら今日絶対休めてないのでいいタイミングで辞めた俺GJ。 詳しい内容は後日動画がニコニコとかに上がるそうなのでそちらをチェックされたし。 発表者とLTの面子だけでも豪華なのに、右斜め前を見ればMatz氏が、左を見れば吉岡氏がいらっしゃったり…など聴衆もスゴかった。 メモが取り切れてないので細かい点は色々はしょって印象的だった所だけ…。（聞き入ってた。） 懇親会は存在を知らずに申し込んでなかったので直帰。出来れば参加者宛にメール流してほしかったなぁ…ブログの存在知らなかった…。 参加者へのリマインドメールにブログの記載がありました。僕が勝手に見落としていただけのようです。 2007/09/10追記 もは
JavaScript開発ツールの本命！ FirebugとAptana：どこまでできる？ 無料ツールでWebサイト作成（4）（1/3 ページ） ついに「Aptana STUDIO」がリリース 先日、連載第1回と第2回で紹介したAptanaが、2年にわたる開発期間を経て「Aptana STUDIO 1.0」としてリリースされた。 「Aptana STUDIO 1.0」には、「Community Edition」と呼ばれるフリー版と、「Professional Edition」と呼ばれる製品版が存在し、製品版は1年間の更新と優先的なサポート、最新開発版へのアクセスパスが付いて199ドル（現在はセール中？）で、以降更新のために1年ごとに79ドル、というプランが用意されている。Professional EditionはIE（Internet Explorer）のデバッグサポート、JSONエディタ、S
2007-11-01 14:29 : 平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか書いてみた 最近、八角研究所で技術記事を書いているのですが、私が参加した 2006 年度下期未踏ソフトウェア事業（2006 年 11 月 ～ 2007 年 8 月末まで）の体験談を書いてみました。 未踏の体験談を書こうと思った動機について書きます。 私がお世話になった PM は東工大の千葉先生だったのですが、同じ PM 配下でも他の方は凄腕のエンジニアであり、能力的にも住む世界が異なるという感じでした。そういうエンジニアは目立つので、私は未踏のエンジニアというともの凄い凄腕ばかりを思い浮かべてしまうのですが、未踏ソフトウェア創造事業そのものは、適切な提案ができれば平凡なエンジニアにも門戸が開かれています。 というか、普通のエンジニアこそ挑戦すべき制度です。とはいえ、
Thank you, Firebug. You made the web amazing for all! The story of Firefox and Firebug are synonymous with the rise of the web. We fought the good fight and changed how developers inspect HTML and debug JS in the browser. Firebug ushered the Web 2.0 era. Today, the work pioneered by the Firebug community through the last 12 years lives on in Firefox Developer Tools. Switch to the latest version of
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
