株式会社永和システムマネジメントを退職します - moroの日記
本日2015年7月31日をもって、9 年間勤めました株式会社永和システムマネジメントを退職します。 在職中は多くの方々に助けられ、Rails を中心としたたくさんの仕事をしながら育てていただきました。個別のご挨拶ができなくて大変申し訳ありませんが、本当にありがとうございました。これからもどうぞよろしくお願いします。 今後ですが、すぐ他社で働くことが決まっておりまして、8 月 3 日から出社予定です。 以下、思い出話なので「このひと誰?」という人はスルーしてください。 永和ではほぼずっと Ruby や Rails の仕事をしてきており、次の職場でもやはり Ruby / Rails に関わる仕事をする予定です。 この私のキャリアのきっかけとなったのは、もう 10 年も前になる(!!) 2005 年にはじまった Rails 勉強会@東京でした。当時は Rails が"来そう" という噂はありつつ
SQLアンチパターン -- 苦い経験を思い出させる良書 - moroの日記
献本いただきました。ありがとうございます。 本書は、データベース設計や、そのDBをアプリケーションから利用する際によく見られるアンチパターンを、簡潔かついきいきとまとめた書籍です。もちろん、単なる「べからず集」ではありません。そのアンチパターンの背景である現実の問題の説明と、アンチパターンを回避した解法もしっかり紹介されています。さらに、それでもアンチパターンを採用する場合のメリットデメリットもしっかり提示されています。 特に気に入ったところとして、2013年の書籍(原著は2010年)にふさわしく、ORMの存在をしっかり意識した内容になっている点が印象的でした。たとえば、全テーブルにサロゲートキーを貼る(IDリクワイアド: とりあえずID)のアンチパターンも、避けるべきではあるが、ORMの規約であればしたがってよいと紹介するなど、 全体として現場寄り、実践的なノウハウの紹介になっています。
達人出版会から「はじめる！Cucumber」という本を出版しました - moroの日記
先ほど、「新しいコンテンツを、新しい読者に、新しい速度とプロセスで」という理念を持った電子出版社、達人出版会が試験公開でサービスインしました(http://tatsu-zine.com/)。こちら、ご存じの方も多いと思いますが、日本Rubyの会会長であり、Railsレシピブックも一緒に書かせていただきました、高橋征義さんが興した出版社です。 まずは、サービスインなさいましたことのお祝いを申し上げるとともに、これからのますますのご発展と、それに伴って日本のソフトウェア業界がよりエキサイティングになることを祈念いたします。本当におめでとうございます。期待しています。 さて私も、同サイトにて拙稿「はじめる！Cucumber」を配信させていただいています。こちら、Rubyの受け入れテスト自動化フレームワーク、Cucumberについての(おそらく)日本で初めての書籍です。Cucumberの使い方を、
OSC2009 Tokyo/FallでCukeとRSpecの紹介をしました - moroの日記
休んでいるうちにずいぶん時間が経ってしまいましたが、10/31のOSCにてお時間をいただき、Railsの昨今のテスト事情について紹介させていただきました。普段から申しているようにCucumberとRSpecをぐいっと推しています。 Rails testing environment, 2009 fallView more documents from Kyosuke MOROHASHI.あとはRSpec方面で、subjectやitsの使い方について、使いながら考えているようなことを書いています。 前にオブラブ方面でCuctomMatcherの話をしたときに、簡単なCustomMatcherを量産するのはだるいんじゃない?という懸念があったんですが、その一つの解としてits()はありかなー、と。使い分けはこんな風になると思います。 CustomMatcher作る 検証内容が複雑になるとき エ
つくったLRUHash - moroの日記
私はid:fistfvckさん(ですよね? お名前確認してなかったのでちと不安)と一緒にコードを書きました。仕様はこんな感じ。 Hashぽいインターフェースが欲しいとの要件だったので[]と[]=をまずは実装(上2つのexample)、その後100個という最大値を挟んでのLRU的機能を実装してみました。実際のストレージは、ふつうのHashへのdelegateで。継承したペアも多かったんですが、私たちは「コレはis-a Hashじゃなかろう」ということで委譲を使ってみることにしました。Forwardableは凄く便利。 このあたりのテストを書いてみると、LRUぽい機能はと=で何かやれば良さそうだぞ、というのが導出されてきます。また、テストを書いてみると、実際のクライアントとしてはcacheされていてnilなのか、そもそもキャッシュされていないのかを見るためにhas_key?系のメソッドも欲しか
ぼくが見ているレール(map.resouces編) - moroの日記
先日のQConで大場さんもおっしゃっていたことですが、Railsで開発をする上でものすごく重要なポイントに、Railsの敷いたレールから降りないというのがあります。別にコレはRailsが不自由だというわけでなく*1、通り一遍のものしかできないというわけでもなく、ただ基盤と相性の悪い設計すればあとで苦労するという、当然の話なわけです。 最近、私を含めいろいろな方が「レールから降りないで作るのが重要」と話しています。が。じゃあそのレールはどこにあるのかという話はあまり聞かれません。ということで、ふだん私がRailsアプリを設計するときに意識しているレールを言語化してみて、議論なりのたたき台にしたいな、と思った次第です。 とはいえDB周りは「羽生さんのERDレッスン嫁」で7割くらい済む話*2なので、まずはコントローラから。 設計指針としてのmap.resouces Rails 2.xにおいて、コ
ustream時代のプレゼン資料の作り方 - moroの日記
今回は前々からどっかで話したかったことを話す機会をいただいたんですが、スライドの作りに難があってustream経由で見ていた方々にはご不便をお掛けしました。また、写経をしてくださった角谷さんありがとうございました。 ということで指摘を受けた点を備忘録的に書いときます。最近はustreamでセミナーや勉強会の様子を配信することも多い十もいますが、そういったときの参考になれば嬉しいです。 赤字はダメ、絶対 プロジェクタやビデオカメラの質にもよりますが、よほど輝度が高くないと赤字は見えづらいみたいです。今回は強調したいところを赤字にしたので意図せずにもんたメソッドを使ってしまいました。黒背景での強調なら黄色使ってればよかったみたいです。確かに。 グラデーションもダメ、絶対 スライドの上部と下部でコントラストが変わるとフォントの色配置が余計に難しくなる。あとはどっちかが濃くも薄くもない半端な色にな
ActiveResourceとかそのルーティングとかのドキュメント - moroの日記
まちゅさんのhttp://www.machu.jp/diary/20080104.html#p01を見て宣伝です。 以前同じようなことを調べたなぁ、と思ったら某書籍の原稿でした。日本語でのリファレンスっぽいのを探している方がいましたらこちらもどうぞ。 ActiveResourceに対応したルーティングを定義する 複雑なルーティングを定義する 他にもActiveResource関連の情報をまとめておりますので、ご参考まで。内容の誤りや読み辛い点がありましたら、ご指摘お待ちしています。コメントなどを頂けるとうれしいです。 http://rails-recipebook.g.hatena.ne.jp/rrbk/?word=%2a%5bARes%5d 関係ないんですが、AResというかREST関連で、年末年始に読もうと思ったRESTful Webサービスがまだ読めていないんですよ。 で読まなきゃな
大晦日 - moroの日記
この日記を読んでいらっしゃる皆様には、今年も一年間たいへんお世話になりました。私の怠け癖のせいで2008年に持ち越しになっていることもいろいろありますが(Rails勉強会のこととか)、年始休みの間にはアクションを起こしますのでいましばらくお待ちいただければ幸いです。 思えば昨年は結婚と転職という、いろんな人生の転機フラグがたった年でした。で、今年はそれらをうけて順調に前に進む年にしたい、というのが2007年の年初の目標でした。力不足でご迷惑をおかけしたことも多かったのですが、目標を達成できたことも少なからずあるように思います。それもこれもひとえに同僚や周りの方々に助けられてのことです。本当にありがとうございました。そういえば今年は一年を通してずっとRubyとRailsで仕事をした年でした。すげー。 2008年は再び変化が訪れそうな年(転職はしない予定)でいろいろあるかとは思いますが、どうぞ
TDDとテストファースト => TDDのオレオレ定義と5回リロードルール - moroの日記
自分でももやもやしてるのでツッコミ希望。 考えだした元記事 : http://techon.nikkeibp.co.jp/article/TOPCOL/20070806/137518/ TDDを紹介するときに、「TDDではプロダクトコードの前にテストを書く」という紹介のされかたが多いんですが、これはちょっと誤解を招く表現だなぁ、と思います。TDDを達成するための1つの(とても有効な)技法としてテストファーストがあるわけですが、その関係は"=="じゃなくて包含だよなぁ、と思うのです。 TDDは字義通りに解釈してもしなくても、テストが開発を駆動することが重要なわけです。駆動するというのはもちろん先にテストを書けば駆動してるんですけど、それは必要条件じゃない。 別にあとから作っても*1、 自分が作ってるモジュールを使ってみたら、APIが「ねーよwww」くらい使いづらいものであると気づいたり、とか
moroの日記 - Railsでテストを書く勘所
昨日はOSCに行ってきました。セミナーやブースはほとんど行かず、例によってRubyの会のあたりでだらだらしてたわけですが。 思いがけず師匠の師匠、id:t-wadaさんにもお会いできてびっくり。 で、そこでRailsとTDD(BDD)の話なんかしたので、一週間で思ったことをつらつらと。たぶん不正確というか、理解の足りないところもいろいろあるので、そのへんのツッコミをいただけると感謝です。 書いてたら長くなったのでagenda モデルのテストでは、とにかくロジックを書いたらテストを書く*1。def..endブロック(wを書いたら必ずテストもあるはず。 RailsのMVCコンポーネントの中では一番テストし易いので、そういう意味でもモデルを厚くすると幸せになりやすい。 コントローラのテストでは、基本的にリクエストを受けてから表示対象のオブジェクトを導出するまでをテストしたい。 ビューのテストでは
RailsとABDとCRUDとワークフロー - moroの日記
羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと＝イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ
お客様と同じ方向を向くための手段としての改善型開発 - moroの日記
改善型開発 〜 システムを作るのではなく育てるという発想 上記を読んで感じたこと。 意識面での現状から必要な変化が大きい。大変そう。 でもその変化は*名目上は*いまSIerが謳っている建前と同じ。 それが建前だけでなく、お金をもらうための本音に近付いていくような気がします。そりゃあいい。 で、じゃあそのハッピーな状況になるためには個々人に何が求められるか。どうすればその変化を私が元気で働けているくらいの近い未来に起こせるか。 ポイントは、システムベンダ側とお客様の方向性が近付いていくこと。上記エントリ中にもあります、いわゆるWin-Winですな。 お客様と同じ方向を目指すことができる 当然のことながらお客様は『システムを作る』のが目的では無く、『システムを使う』さらに言えば『システムを使って本業の利益をあげる』のが目的なわけです。それなのに現在のSIerのミッションは、あくまでもシステムを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
