Jose Valim、Rubyにおける並行プログラミングのためのいくつかのアイデアを提案。～ RubyKaigi 2013 基調講演 2日目 | gihyo.jp
RubyKaigi 2013 レポート Jose Valim、Rubyにおける並行プログラミングのためのいくつかのアイデアを提案。～ RubyKaigi 2013 基調講演 2日目 2013年5月30日～6月1日の3日間、お台場にある東京国際交流館にてRubyKaigi 2013が開催されています。基調講演をそれぞれレポートします。 2日目の基調講演の演者はJose Valimです。司会の角谷さんにより「再起動したRubyKaigiの基調講演に最もふさわしい人物の一人」と紹介をされたJoseは、Rubyにおける並行プログラミングの可能性について話しました。 自己紹介 Joseは、2006年からRubyを書き始めたそうです。それからOSSにも深く関わっており、2010年からRails coreチームにジョインしています。そして、Elixirという言語の作者でもあります。ElixirはErla
まつもとゆきひろさん、Rubyに影響を与えた言語とRuby開発初期を語る。 ～ RubyKaigi 2013 基調講演 1日目 | gihyo.jp
RubyKaigi 2013 レポート まつもとゆきひろさん、Rubyに影響を与えた言語とRuby開発初期を語る。 ～ RubyKaigi 2013 基調講演 1日目 2013年5月30日～6月1日の3日間、お台場にある東京国際交流館にてRubyKaigi 2013が開催されています。毎日1つある基調講演をそれぞれレポートします。 1日目の基調講演では、RubyのパパであるMatzこと、まつもとゆきひろさんが「Rubyのつくりかた」と題して話をしました。まつもとさんは今までのRuby会議すべてで基調講演をしており、いわば定番のキーノートと言えるかもしれません。 Ruby 以前 Rubyを作る前、まつもとさんとコンピューターの関わりについて、歴史をおって話しました。 1979 BASIC まつもとさんが初めてプログラミング言語と触れあったのは1979年のことで、SHARP製のポケットコンピュ
rubykaigi & rubyhiroba に参加した - おもしろwebサービス開発日記
RubyKaigi 2013 と RubyHiroba 2013 に参加しました。以下感想をつれづれに。 RubyKaigi RubyKaigi に参加するたびに、もっと勉強しないといけない！という気持ちになります。 英語 まず英語。僕と同じように、英語勉強しなければ…と思ったRubyistも多いのではないでしょうか。札幌Ruby会議2012に参加したときにもどうにかしなければと思いラングリッチを使ってみたりしたのですが、結局挫折したのでした…。これは意識が高まっている今のうちに一つ新しい施策を打ちたいと思います。英語の発表のニュアンスが理解できなかったり、海外の開発者と話せないのはそろそろ卒業したいところ。 発表 技術的には、最近は fat model をどうするかに関心があるので、諸橋さん、Bryan Helmkamp、Jim Gay の発表をとても興味深く聴かせていただきました！これ
第2回 仕組みを育てる | gihyo.jp
すばらしい製品というのは、単に良い習慣の副産物でしかありません。 『Ship It!』（注1） はじめに 本連載では「アジャイルに開発する人達（アジャイル開発者）が開発するからアジャイル開発である」と考え、アジャイル開発者になるために必要なスキルを磨くための習慣を紹介しています（図1)。 図1 アジャイル開発者の習慣 前回紹介した習慣は、習慣を身につけるための習慣（メタ習慣）、「フィードバックを重視する」でした。 第2回である今回は、最初の具体的な習慣として「仕組みを育てる」習慣を紹介します。そのために、アジャイル開発者にとっての「仕組み」とは何か、なぜ重要なのかを説明――する前に、先日体験した印象深い経験について語らせてください。 RubyKaigi2007のDave Thomasとアジャイル 6月9、10日に日本Ruby会議2007（RubyKaigi2007）が開催されました
第15回 追い込まれたときのテスト | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326039 担当からの発言「追い込まれている」というのが理由で、テストをさぼることはありますか？ 私の場合は、テストをサボることはあります、いや、ありました。もう少し正確に言うと、テストを書くのをさぼるというより、テストを「先に」書くことをサボった、そういうことはありました。 以前、もうリリース間近のプロジェクトで、お客様が機能が欲しいことがわかっていて、さらに直近で仕様変更もありました。その結果、赤くなってしまった（テストが失敗する）プログラムがいくつか出てしまったり、新たにテストを書いてから開発しなければならないコードがあるというとき、これはもう大きいテストを通すまでに、小さいテストを積み上げていく余裕はないなと判断したことがあります。 そのような場合に、ちょっと冒険的に、小さいテストを少なめに、要する
第19回 チーム開発での規約・規律 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326598 宮澤さんの発言チームでTDDを行うときは規約を決めると思うんですけど、その点について教えてください。 チームでの開発では、複数人で開発を行う際に、テストの書き方を個々人好きにやっていいというのではなく、書き方の取り決めや指針みたいなものを出すかどうかという話ですね。 大きいプロジェクトの場合 プロジェクトの性質にもよると思いますが、指針を出すプロジェクトは多いのではないかと思います。「ユニットテストはこういった視点でやります」とか、「このようなところは重点的にテストしてください」などというテスト指針は、大きいプロジェクトになればなるほど重要になってくると思うんですね。 また大規模プロジェクトの場合には、そのプロジェクト用のテストフレームワークを作ることもあると思います。JUnitやS2Uni
第16回 プログラミング言語とTDDは、どちらを先にマスターすべきか？ | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326111 クロコさんの発言TDDの学習を始めるときに、プログラミング言語はマスターしておかないと始められないのですか？ この疑問に関しては、みなさんいろいろ意見があると思います。 まず、TDDをマスターしていて言語をマスターしていないのか、言語もTDDもマスターしてしていないのかで全然状況は違うと思います。 私自身はTDDをある程度マスターしていると考えていますが、私はプログラミング言語をマスターするために、TDDをやってみることがあります。ちょっとピントのずれた回答かもしれないんですけれど。 全然経験がないプログラミング言語があるときに、どういうやり方をしていくかというと、どんな言語にも、だいたいテストコードのサンプルとテスティングフレームワークがあるわけですね、たとえばSmallTalkだったらSUn
第18回 公布済みインタフェースのリファクタリング | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326506 家永さんの発言リファクタリングの話のときに、publishedインタフェース、publicインタフェースというキーワードが出てきましたが、その点についてもう一度整理してください。 publishedインタフェース、publicインタフェースという言葉が出てきました。 まず、publicというのはJavaのpublicだと思ってかまいません。プログラムのどこからでもアクセスできる可視性を持っているインタフェースをpublicインタフェースといいます。Javaで言えばインタフェースは全部publicですね。 それに対してpublishedインタフェースというのは、そういったpublicインタフェースの中のさらに一部分のことを指します。publishedというのは「公布済み」とか、「公開済み」と訳さ
第17回 リファクタリングをどこまでするか、いつやめるか | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2326406 担当からの発言みなさんが、リファクタリングをどこまでするかとか、やめどきとかについて聞かせてください。 「重複は悪」「DRY（Don't repeat yourself）」 リファクタリングをどこまでするかというのは、実はすごく難しい質問なんですけども、端的に一言で「いつまで」と言うならば、「重複がなくなるまで」ということが一つの指標としてありますね。重複というのは、コードの重複です。まったく同じコードが二箇所以上に存在している状態です。 「重複は悪」もしくは「DRY（Don't repeat yourself）」という言葉があります。たとえばあるコードが書かれています。そのコードをコピーして、もう一つ機能を作りましたというときには、ほぼ同じコードが二ヵ所に書かれていることになります。 ある
2007-12-21
角谷さんの「勉強会のススメ」にでてくる「ちょっとした勇気」を社内のみなさんに言うことが目的。私としては勉強会を自ら開催するためのキーワードとしてだけでなく、普段の業務でも勇気を持ってもらいたかった。わたしも強く伝えなかったけど、やはりそこまでは伝わらなかったようだ。 大前研一さんのブログに似ていると出ました。 http://myboo.kizasi.jp/
第13回 私のTDDへの目覚め | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325802 前回までで、講義でお話しようと思っていたトピックは一区切り付きました。 今回からは、今日お集まりいただいてる方と、フリースタイルの質疑応答のような形でこの場で議論していきたいと思っています。 家永さんの発言TDDを最初は疑いの目で見ていたと思うんですが、和田さんがTDDに目覚めたタイミング、「これは！」「こりゃいいぞ！」と変わったタイミングについて知りたいです。 実際にまず、連載第6回でお見せした『テスト駆動開発入門』（Kent Beck 著／テクノロジックアート 訳／長瀬 嘉秀 監訳／ピアソン・エデュケーション 刊）を写経しました。写経した結果、テスト駆動開発がちょっとわかったと思いました。 私自身はもともとテスト駆動開発する前まではあんまりテストを書かないタイプのプログラマだったのです
第12回 モックオブジェクト技法：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325718 家永さんのコメント そうですね。 今「モックテスト」という言葉が出てきました。モックテスト、モックオブジェクトという技法は、『WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」でも少し説明しましたが、この場で詳しく説明しましょう。 モックオブジェクト技法とは 「モックオブジェクト」「モックテスト」とは、ニセモノのオブジェクト（モックオブジェクト）をテストに使う技法です。本物のコードや本物のクラスではなく、テスト用の偽者のオブジェクトを作成し、テストを書きやすく、実行しやすくします。 詳しくは後述しますが、具体的には、テスト対象である本物のクラスと、それと協調動作するオブジェクトの偽物を使います。偽者オブジェクトは、テストの中で、テストの内容に即した動きをします。 メリ
第10回 テストの最小単位は不安 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2316665 クロコさんからの質問 なるほど。連載第5回でも、「写経をやってみた、リズムもわかってきた。でもいざ自分でやろうとすると、最初はどういうテスト書こうかとか、どういう単位でテストを書けばいいのかとかで詰まってしまう」という質問をいただきましたね。 私は実は、明確にこういう単位でテストを書くべしという決まりはないと思っています。 不安をテストで表現する では、私がどういうときに小さいテストを書いているかというと、私は「不安」を最小単位の基準としています。不安を手がかりにしてテストを書きます。 私たちプログラマの手を止めるものは何でしょうか。私は「不安」だと思っています。「もしかしたら」という感情ですね。「もしかしたら、自分の書いているコードは間違っているかもしれない」「もしかしたら、ライブラリ
第1回 フィードバックを重視する | gihyo.jp
僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。 Kent Beck （注1） 自分の仕事を憎むには人生はあまりにも短い 私は、200名程度という微妙な規模のSIベンダーに勤務するプログラマです。主に企業で利用する業務アプリケーションの構築に携わっています。 私には夢があります。業務アプリケーションのプログラマとしての夢です。 自分だけではできないことをチームで成し遂げたい チームの成果が誰かの役に立ってほしい チームの成果に対して適切な報酬を受けたい 「自分の仕事を憎むには人生はあまりにも短い」。Joel Spolskyのこの言葉[2]と同じ思いを私自身が抱きはじめたきっかけは、2冊の書籍との出会いでした。1冊は『達人プログラマー』（注3）。もう1冊は『XP エクストリーム・プログラミング入門』（注4）です。 この2冊に出会ってから数年後、縁あ
連載：アジャイル開発者の習慣―acts_as_agile｜gihyo.jp … 技術評論社
第4回特別コラム 「なぜそんなにも（アジャイル開発者にとって）Wikiは重要なのか」 角谷信太郎 2008-04-22
第11回 テストの資産価値 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325613 宮澤さんからの質問 そうですね。またよい質問をいただきました。「テストの資産価値」という話をこれからしたいと思います。 小さいテストがすべて真っ赤っかに…… 私も「不安」ですし、新人の人だったら不安がいっぱいでしょうから、たくさんの小さいテストができることはあると思います。 その場合、小さい単位のテストを基盤にして、それらの学習結果やそれらの不安をもとにしたテストコードと、それらの上で実際に書かれたコードが存在することになります。 それに対して仕様変更があった場合、小さい視点のテストが全滅してしまう、もしくは真っ赤っか（テスト失敗だらけ）になってしまうということはよくあります。 そのときに、そのテストを一つ一つ直していくことに意味があるのか、割に合うのかという話が出てくると思います。実プロジェ
第9回 テスト駆動開発の「サイクル」――次にテストリストでToDoを洗い出し、レッド、グリーンでサイクルを回す | gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第9回テスト駆動開発の「サイクル」――次にテストリストでToDoを洗い出し、レッド、グリーンでサイクルを回す ニコニコ動画：https://www.nicovideo.jp/watch/sm2316617 前回は、テスト駆動開発のサイクルとしてまず最初に受け入れテストを土台として作るという話をさせていただきました。 今回は、その受け入れテストを通すために、内部の設計をどうやって行っていくかという視点の話、つまりサイクルをどうやって深堀りしていくかという話をしたいと思います。 テストリストでToDoの抽出 受け入れテストを通すために、たとえば前回紹介した『WEB+DB PRESS Vol.35』のサンプルでしたら、URLを解釈する機能が必要だなとか、XMLに変換する機能が必要だなとか、それらをつないでいくコードが必要だなとか……そういった、シス
第8回 テスト駆動開発の「サイクル」――まず受け入れテストで土台を作る | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2316518 テスト駆動開発には「リズム」と「サイクル」があります。 リズムについては前回説明しましたので、今回と次回でサイクルの話をします。 テスト駆動開発のサイクル テスト駆動開発のサイクルとは、1つの機能を実装するにあたって、どんな手順を踏んで、どういう回し方をしていくかということです。たとえば、ある1つの機能を実装したい、提供したいということになったときに、まずどういうテストを書いて、それからどういうコードを書いていくのか。 今回は、テスト駆動開発のサイクルとしてまず最初に受け入れテストを土台として作るという話をします。 そして次回、その受け入れテストを通すために、どのようにレッド、グリーン、リファクタリングというサイクルを回していくのかというお話をします。 なお、ここで説明する回し方の対象は、スタッ
第7回 「経験者」からTDDのリズムを学ぶ ――セミナー、ペアプログラミング、レビュー、動画 | gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第7回「経験者」からTDDのリズムを学ぶ ――セミナー、ペアプログラミング、レビュー、動画 ニコニコ動画：https://www.nicovideo.jp/watch/sm2316447 テスト駆動開発を学習するにあたって、前回紹介した「写経」（本を写すこと）以外にどのような方法があるかについて説明します。 経験者から学ぶ テスト駆動開発をマスターするための二つ目の道として、「テスト駆動開発の経験者から学ぶ」ということが挙げられます。具体的には、セミナーやレビュー、ペアプログラミングなどです。 セミナー テスト駆動開発のセミナーですとか、レクチャー、ハンズオンは、一定数開催されています。 テスト駆動開発はどのようなものなのか知りたい、体験してみたいと思う方は、そういうセミナーに足を運んでみるというのも一つの有効な手段ではないでしょうか。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアマインド Webマガジン | エンジニアマインド … 技術評論社