サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
ko.meadowy.net/~nay
■ 万葉がRubyKaigi2016のNursery Sponsorになりました 私が社長をしている (株)万葉が、RubyKaigi2016のNursery Sponsor（ナーサリースポンサー）になりました。 https://www.everyleaf.com/articles/8 Nursery Sponsor って何？ っていう方も多いと思うのですが、Nursery（ナーサリー）っていうのは、幼稚園、保育園、託児所、というような意味の言葉で、要は、RubyKaigiというカンファレンスの参加者が、会場でお子様を預けることのできる託児サービスを提供するスポンサーです。 託児サービスという企画の凄さ カンファレンスに託児サービス、というのは素晴らしい企画だと思います。 というのは、もしカンファレンスに子どもを連れていく選択肢がなければ、男女を問わず、みるべき子どものいる人は、自分がカン
■ 就職・転職活動と視点 前々から気になっていたのだが、就職・転職活動をしている人の中には、採用されるために必要な大事なポイントに気づいていない人が一定割合いるような気がする。 これは大変に勿体ないことだ。おそらくそのポイントを抑えているかどうかで、勝率も大きく違うことだろう。特に、年齢が上がれば上がるほど、この点の違いは顕著に響いてくるはずだ。 そのポイントとは、「誰の視点で自己PRをするか」である。 典型的な「わかっていない人」の応募資料に書かれているのは、次のようなことである。 1. これまで自分が所属した世界のなかでどうがんばったか 2. 自分のやりたいこと、希望 3. 採用してくれたらがんばります 一見、何が悪いの？というような感じがするかもしれない。 そこまで悪くはないようにも見える。 しかし、このような応募資料を書いてくる人は、いわば「自分の視点」で就職／転職活動をしていると
■ 社長になってわかった「面談の仕方」 2007年4月に会社（万葉）を作って社長になった。2008年に本格的に従業員を（知人ではなかった人たちを）採用した。 前働いていたベンチャーで、社長たちが期末の面談を重視していないのが嫌だったので、当初から"きまじめに"面談をやるように仕組み作りをした。 で、面談をしてみて驚いたことがある。 というのは、突如として私の面談スキルが飛躍的にあがっていたのである。自分でも驚くほど上手にできたのだ！ ここでいう上手というのは比較の問題で、比較対象は昔ベンチャーで開発本部長として働いていた頃の自分だ。そこそこの期間働いていたし、自分が面談が下手だという意識もなかったのだが、2008年に社長としてやった面談とは、全然質が違っていた。それはもう、衝撃的だった。 面談を終えた私は相棒の専務に、すごい勢いで話し始めた。「ねえねえ、私面談うまくなったよねー？！」もちろ
■ 万葉.rb ありがとうございました 弊社（株式会社万葉）６周年イベントということで万葉.rbが開催され、基調講演その２をつとめさせていただきました。はるばる札幌からいらしてくださった島田さんはじめ、たくさんのスピーカーの皆様、お越しいただいたお客様、会場をお貸しいただいたIIJさま、社内外のスタッフのみなさま、そして海外から素敵なビデオメッセージをお寄せくださったまつもとゆきひろさま、本当にありがとうございました。天候が嵐ということでどうなる事かと思いましたが、思ったよりはひどくなくてほっとしました。 私のスピーチ（「世界を描く Drawing the world」）の資料をこちらにあげました。 http://www.slideshare.net/nay/nay-rb 資料をつくる過程で、2010年の仙台RubyKaigi02で話した時の資料（「Rubyの教えてくれたこと」）をアップし
■ みなとRubyKaigi01に参加してきました みなとRubyKaigi01に参加してひさしぶりに話をしてきました。大盛況でとても良いKaigiでした。毎月活動を継続した上でああいうのを開けるというのは本当に素晴らしいですね。 懇親会行けなくて残念＆申し訳ないです。 ところで、女子多いって声があったけど、まだまだ、うちの会社からみると男子校みたいでしたよっと… :p お話しした資料はこちらです。 http://www.slideshare.net/nay/rails-13185381
■ 受託開発と技術者の育成 今のところ、私たちの会社（万葉）は受託開発がメインになっている。 世の中には、受託開発 VS 自社プロダクト/サービス提供 という対立軸もあって、それについての私の見解は、こんな感じになる。 まず、純粋に「自社プロダクト/サービス楽しそう。やりたい！」という思いがある。自分たちの作りたいものを自分たちで作るというのはとても明快であり、齟齬が生まれにくい。作る立場として、とても気持ちが良いのはわかっている。 一方で、会社として次のどちらに力点を置くかというテーマがある。 ある目的を実現するために自社プロダクト/サービスを作る。たとえば「世の中をこんな風に変える」ために。 社員が、ソフトウェアの開発をすることで価値を提供できるようにする、すなわち食べていけるようにする。 前者の場合、自社プロダクトやサービスの開発というのは目的達成の一部であるので、話の展開によっては
■ 呼び出し側から書く Rubyを使うようになってからのような気がするが、私は日頃、コードを「呼び出し側から書く」ようにしている。とても役に立つ手法だと思うので、ここで紹介したい。 例えば、勤務表から総役務時間を得たいとする。 このとき「ええと、勤務表である MonthlyWork クラスのインスタンスには日ごとに DailyWork があって、それらのうち実役務時間と有給休暇を足して... 」といったことを考えたりは *しない*。 「どうやってその機能を実現するか」を最初は考えないようにする。「本当にその機能を実現できるだろうか、不安だ」というような感情が襲ってくることもあるだろう（特に初心者には）。しかし、大概のことは最終的には実現できるし、もし本当に実現できない問題があったとすればそれは個人のせいではない。 「どうやってその機能を実現するか」を考え始める代わりに、私はまだ存在しないそ
■ 会社をやるということ 私は2007年4月に株式会社万葉という会社を友人と二人で設立して、以来、社長という立場で「会社を経営」し続けている。 正直なところ、さして立派な社長ではないと思う。しかし、ともかくも一応もう5年くらい「自走」しているわけなので、最悪の部類ではないと思う。というか願っている。 それで、会社をやっているとさすがに色々と勉強になって、見えてくるものがある。モヤモヤもする。そういうのをぼちぼちと日記に書いていこうかな、なんて思ってきた。前からそんな気分はあったのだが、 時間がない 批判が怖い - 批判も怖いし、自爆も怖い 社員があらぬ不安を抱いては困る というような理由で、踏み出していなかった。しかし、色々なことを考えたり気づいたりしているのなら、それを書いていくのは悪くないと思うので。 とりあえず今日は、「会社をやっているとき、地面は止まっていない」ということを書こう。
■ TODOの使いこなしを工夫してみている このまえの日曜日くらいから、TODO管理を新たな使い方で使い始めた。ちなみに使っているのは checkpad だが、基本機能があればなんでもできるとおもう。 何を工夫しているかというと、 人生にとって重要なものと、そうでないものの２つのフォルダを使う 朝、昨日クリアしたタスクをすべて消して、２つのフォルダに、「今日やり遂げるとコミットすること」を入れる 重要なものには、１日のメインである主たる勤務も入れる というあたりが特徴だ。だいたい、フォルダあたりのタスク数は２〜５個くらいになる。 まず、「やりたいこと」「やれないかもしれないが何とかやりたいこと」を入れないことが大事だ。私の目的は、長期的な備忘録やプロジェクト管理ではなく、１日の充実感を得て着実に物事を処理することである。「いつかやりたいこと」を混ぜると、長期間そのタスクが鎮座してしまって、
■ 昨年の島根大学での講義のこと あけましておめでとうございます。 年が明けるというのは区切りとしていいものなので、なにか目標を立てておきたいと思う。会社としての目標はもちろんあるが、個人としてはブログでの発信を増やしていきたい。あと、英語でも発信したいな。 さて、昨年12月に島根大学で講義をさせてもらったときのことを少し紹介したい。なお、この講義のことは野田先生のブログで取り上げてくださっている。私たち夫婦は今回が講義は４回目。最初の頃は居眠りさせてしまったり、誤植で大騒ぎになったり、全然予定が消化できないといった失敗をしていたものの、近年では、歴戦の強者化してきて、そこそこスムーズにできるようになってきたと思う。もちろん完璧ではないし、不満足な点はあろうかと思うが、とりあえず以前よりはうまくなったなと思うのだ。 今回の講義でいちばんうまくいったと思うのは、資料の構成だ。Railsをほぼ
■ 札幌Ruby会議03と「現実の砂漠」 先日、2010/12/4に札幌で開かれた SapporoRubyKaigi03 に参加してきた。それはそれは素晴らしいカンファレンスだった。会場が快適で適切、プログラムが秀逸、ホスピタリティに溢れ、各トークが素晴らしい。私自身も何とかトークをすることができたし、思いがけないほどの好評をもらえて非常に嬉しかったし、ガラスの仮面の布教(?)もできたし、もっと少女漫画を読めと "ガツンと言ってやった" しで、本当に楽しかった（どうしても話したかったことを話させていただいて感謝しています）。 しかも誕生日ということもあって、懇親会でみなさまに温かくお祝いをしていただいて感激したし（本当にありがとうございます！）、個人的な目標であった「前夜祭の舟盛りを制覇（完食）する」「風邪をひかない」も達成して、言うことなしの満ち足りたイベントだった。 そんな中で、以前か
■ 仙台Ruby会議02 土曜は仙台Ruby会議02（http://regional.rubykaigi.org/sendai02）へ行ってきました。テーマは「Rubyとビジネス」。 同系統のテーマだった栃木Ruby会議02では聴衆として気楽に聞いてきただけだったので、私にとっては "親方デビュー" の日でした。 私はxibbarさんの次に話しましたが、話の内容が全然かぶらなくて、そのこと自体も非常に興味深かった。パネル、懇親会でも色々なことを話せて非常に面白かったし、だいぶ経営者脳を使った一日となりました。 サービス、雇用、組織、仕組みづくり等、いろいろ考えさせられて大変面白かったのですが、それはすぐには書けないので後に譲るとして、緊急性のある大事なことだけ書いておきます。 懇親会のじゃんけんで華麗に勝利して（７人くらいでやって、私以外全員チョキでした）、本選びの際も譲っていただいたりし
■ routes職人の資料を更新しました 多少間違いやわかりにくい点があったので、修正しておきました。 （URLは元のままです） http://dl.dropbox.com/u/391979/routes-master.pdf
■ TokyoRubyKaigi03 昨日はTokyoRubyKaigi03に参加してきました。すごい勉強になる内容でとても面白かった。スタッフ・講師の皆様、ありがとうございました！ 私のワークショップ「routes職人への道」の資料を以下にアップしましたので、見たい人はどうぞ。参加者が少なくて残念でしたが、参加してくださった方には満足してもらえたようなので良かったと思います。この資料は、"東大のシケタイ時代" のことを思い出してキリキリ作ったのでそれなりにドリルのように使えるんじゃないかと思っています。 Railsは少し触ってるけどroutes.rbはまだよくわからない、RESTfulもよくわからない、という人におすすめです。 なお、Rails3にも触れているけど、今後の仕様のなりゆき次第で、最終形ではないとおもうので注意してください。書き方もさることながら、背景となっている世界観や、考
いろいろな方のご協力のおかげで無事出番を終えることができました。感謝感謝です。また、懇親会では沢山の方とお会いすることができました。中でも、海外の女性エンジニアと女性エンジニア＆起業話ができたのは感動的でした。つないでくださったレオさんありがとうございます。 今日の資料を以下に公開しました。 ■ RubyKaigiで話してきます 書き忘れているうちに当日朝になってしまった！ 今日はRuby会議2009初日ですが、はじめてスピーカーとして話してきます。うまく行くといいなあ(><) http://rubykaigi.org/2009/ja 会社としてもスポンサーになり、ブースも出すので楽しみ。何より、まずは自分の出番が終わって気楽に楽しめるようになることが楽しみです。 いいKaigiになりますように！
■ QCon Tokyo 2009の資料 すっかり遅くなってしまいましたが、QCon Tokyo 2009の資料をアップしました。
■ デブサミ2009 初日に参加してきました。いくつか感想などを。 【12-B-2】iPhone 開発者座談会 予想外の話はなかったけれど、審査の話など具体的な話が聞けて、温度が伝わってきてよかった。 【12-A-3】時を超えたプログラミングの道への道 電波でとてもよかった。感動した！ が、公平にみるとやっぱパターンランゲージのところは会場置き去りだったかも。”道”に関する電波を受信できた気になってとてもホクホクしたセッション。 【12-A-6】オブジェクト指向エクササイズのススメ 面白かったけど、少しストレスを感じたセッション。各エクササイズの背景には同意だし、エクササイズも具体的なので興味深くはあったが、実用的ではなかった。というか、オブジェクト指向は本来実用的なことから発生した話題のはずなのに、実用的でないと感じさせるのはもったいなかった。エクササイズだから実用第一ではないし、鵜呑み
■ Ruby Kaigi 2008 参加してきました。発表はせず気楽な参加者として楽しませていただきました。 MacRubyはじめ、印象的なプレゼンが色々あってとても参考になりました。運営の皆様、本当にお疲れ様でした。 順不同に感想としては、 MacRubyすごい！ yuumi3の教育系のお話も印象的でした。 生産性だけでは採用に至らない業界構造にモヤモヤ・・。 ステージの上から愛を告白された（’−’＊ きゃー わー monyakataさん（http://d.hatena.ne.jp/monyakata/）とお会いできて、いろいろ小槌の要望などをお聞きして嬉しかった。赤いものを身につけるも良いですねえ。 嬉し恥ずかし、本にサインさせてもらいました。買ってくださった皆様、本当にありがとうございます。(_o_) まつもとさんにまでサインさせてもらっちゃいました。光栄(T^T)！！ 本を販売して
Module階層化関連 気になっていた問題がほぼ解消された。 fixture は fixtures 直下にテーブル名で用意する。（Rails 1.2.5 ではサブフォルダ下に入り動作させるためにステップがあった） ただし、model を generate すると空のモジュール名ディレクトリも作られる。何に使うのかなこれ？ テーブル名は module とクラスを _でつないだものにすると楽 ↑その場合、モデルクラスに set_table_name が必要 同じ階層同士のモデル間で関連をはる場合、:class_name は指定しなくてよくなった（Rails 1.2.5 では必要だった） と思ったら不具合もあった。 has_many で extension しようとすると例外。どうも、has_many を記述している側のクラスがModuleの下にあるという状況を想定していない不具合っぽい雰囲気。
伊藤忠商事のTLab（Web系先端技術部隊）で開発された image_upload プラグインを RubyForge にて公開しています。 http://imageupload.rubyforge.org/ どういうプラグインかというと、画像をかっこよくアップロードするプラグインです。通常の file input field だと、submit して次ページに遷移しないとアップされた画像を見ることができませんが、このプラグインだと、ファイルを選択した時点で一時的な領域にアップロードされてふわ〜っと表示されます。もちろんその時点ではまだDBには反映されません。 また、DBに格納済の画像の削除も、submitを押さない限り反映されない（Railsで素直につくると即時削除になりますが）など、統一感のある仕様となっています。 ほかの特徴としては、モデルの自由度が高いと思います。image_uplo
親子構造のあるモデルのRESTfulなURLの形は、親の情報の下に子の情報が並びます。例えば、ID=3のプロジェクトに参加しているメンバー一覧の画面は、次のようなURLにするとRESTfulです。 http://localhost:3000/projects/3/members このような形のI/Fを簡単に定義するには、routes.rb に次のように記述します。 map.resources :projects do |project| article.resources :members end これは、次のように記述するのと同じ意味です。 map.resources :projects map.resources :members, :path_prefix => '/projects/:project_id', :name_path => 'project_' ちなみに、この書き方で
「コントローラをRESTfulにする」では、map.resources を使った単純な RESTFul インターフェースの指定方法を説明しましたが、実際には、アクションの構造がそのような典型的な形でないこともあるでしょう。ここでは、map.resources のオプションを使って、任意のアクションをRESTFulにする方法をご紹介します。 なお、「親子構造のあるモデルを扱うコントローラをRESTfulにする」、「モジュール下のコントローラをRESTfulにする」もそれぞれ参考にしてください。 典型的でないアクションに対するルートを用意する map.resources で自動的に作られるルート以外に、独自のアクションに対して RESTful なURLを対応させたい場合は、３つのオプションを使います。どのような性質のアクションであるかによって使うべきオプションが異なります。 :collecti
RESTful なI/Fには次のような特徴があります。 HTTPメソッドで表現できる処理は、URLではなくメソッドで表現する。 同じURLでも、メソッドの種類によって異なる動作をする。 主語（上記でいえば、projects/1など）が先にきて、動作は後にくる。一見して意味がつかみやすい。 なお、一般的にブラウザは PUT と DELETEには対応していないため、Rails はPOST を _method パラメータ付きで呼んだリクエストも受け付けます。例えば、以下のようなフィールドを含む form を POST で送ると、PUT メソッドと同様の処理が実行されます。 <input type="hidden" name="_method" value="put" /> ブラウザでは PUT, DELETE に対応していないとしたら、なぜわざわざこのような回りくどいことをするのでしょうか？ R
API・マニュアル Rubyリファレンスマニュアル Rails Framework Documentation prototype.js v1.4.0 の使い方 公式 Ruby on Rails Rails活用情報 http://wiki.rails2u.com/ ... 右上の search で有用な記事が色々ヒットします クラスや変数の命名に便利な和英翻訳 スペースアルク ... 例文が色々でるので直訳でなくなるべくラシイ単語を選びたいニーズに非常にマッチ。最近のお気に入りです。
モジュールによって階層化されたコントローラをRESTfulにする場合は、map.resources などの記述を、map.namespace ブロックで囲みます。 例えば、Admin::UsersController を RESTfulにするための routes.rb の記述は次のようになります。 map.namespace(:admin) do |admin| admin.resources :users end 上記は、ブロック内の map.resources を単独で次のように記述するのと同じ意味です。 admin.resources :users, :path_prefix => :admin, :name_prefix => "admin_", :namespace => "admin/" namespace ブロック内で記述することで、これらのオプションを、複数のルート記述に対
■ RailsのRESTful関係の記事 現在進行中のプロジェクト（そのうち明らかに！）の一環で、お正月にRailsのRESTful関係をいろいろ調べたので、成果を公開してみます。 何か間違い等あれば教えてくださいませ。 コントローラをRESTfulにする コントローラのRESTfulインターフェースをカスタマイズする 親子構造のあるモデルを扱うコントローラをRESTfulにする モジュール下のコントローラをRESTfulにする
■ 講演内容と感想 忘れないうちに内容と感想を書いておこう。 まず私の覚えている内容は以下のようなものだ。メモをとっておらず、完全に記憶に頼っているので多少違うかもしれない。お気づきの方は補足してください。 自分は実はスピーチするためというより、Rubyの生まれ故郷でみなさんにお礼を言うために来た （ここで最初の拍手。以後、計１０回くらい拍手の飛び交う感動的なプレゼンとなった） 自分はRuby が大好きである。愛しちゃっている。Rubyとの出会いの頃は、いろいろな開発言語を１時間くらい試してはダメだと言うのを繰り返していたが、Rubyを試したときは、ランチになっても夜になっても翌日になってもずっとRubyで遊んでいた。 要するに、恋に落ちた 恋に落ちた理由を言うのは難しいが、強いていえば、Rubyは人間の考えるように動作してくれる。つまり、日々考え方ややり方の変わる人間のために色々な書き方
Engine を作る手順をまとめてみます。 Engine は Ruby on Rails の plugin の一種で、controller, mode, view をまるごと plugin 化するのに便利です。 手順 1. Engine 化対象のアプリケーションをまず作る 2. Rails Engines プラグインをインストール 3. Engine の雛型を作成 4. Engine化したいソースを Engine 側へ移動 4-1. ApplicationController, ApplicationHelper 4-2. レイアウト 4-3. スタイルシート 4-4. JavaScript 5. アプリケーションの environment.rb の変更 5-1. 設定データの定義方法の変更 5-2. Engines.start Engine の migrate Engine の テスト
次のページ
このページを最初にブックマークしてみませんか？
『ko.meadowy.net』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
