なぜRubyのcase/whenはインデントしないのかを考えてみた - give IT a try
はじめに 昨日はソニックガーデンにしては珍しく、ちょっとしたコーディングスタイル論争(?)が発生しました。 議論のネタになったのはRubyのcase文のインデントについてです。 when節はインデントすべきか、それともcaseキーワードと揃えるべきかの議論になりました。 x = 1 # インデントする場合 case x when 1 puts "x is 1" when 2 puts "x is 2" else puts "x is other" end # インデントしない場合 case x when 1 puts "x is 1" when 2 puts "x is 2" else puts "x is other" end Rubyのコーディング規約をいくつか見てみると、後者のインデントしないスタイルの方が多数派だったので、「インデントなしでいいじゃん」で結論付ければいいだけかもしれ
ユーザーのつぶやき(要望)はなぜ1時間で本番リリースできたのか - give IT a try
はじめに 昨日の朝、Twitter上でこんなやりとりがありました。 youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は分かっても「年」までは表示されていないので、ちょっと困った #youRoom— yoh nakamura (@yohhatu) October 31, 2012 困ってないで@kuranukiさんに要望を伝えれば… RT @yohhatu: youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は分かっても「年」までは表示されていないので、ちょっと困った #youRoom— Ryutaro YOSHIBA (@ryuzee) October 31, 2012 やりましょう。 RT @ryuzee: 困ってないで@kuranukiさんに要望を伝えれば… RT @yohhatu: youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は
アジャイルサムライとは大きく異なるソニックガーデンの見積りと計画作り - give IT a try
はじめに アジャイル開発に興味を持っている人に取っては「まだ読んでなかったの？」といった感じかもしれませんが、先日書籍「アジャイルサムライ」を借りたので、ざっくりと読んでみました。 今回のエントリは読んでみた感想に加えて、ソニックガーデンでの開発スタイルとの比較をしてみたいと思います。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る とりあえず最初から読んでみた 1章の内容はアジャイル開発の基礎知識が中心で、読みながら「うん、まあそうだよねえ」と思いました。 14ページの挿絵にある「やり方がたった1つなんてことはないんだ！」「君自身が編み出
Vimコマンドを定期的に解説してくれるTwitterボットを作りました - give IT a try
はじめに 昨日、初めてBe VimmerというTwitterボットを開発しました。 このエントリではそのプログラムと制作過程を紹介しようと思います。 Be Vimmerとは？ 定期的にVimコマンドとその説明をランダムにツイートするボットプログラムです。 日本語版、英語版、中国語版の3種類があります。 be_vimmer_jp be_vimmer_en be_vimmer_cn 情報源は各言語のVim Documentationから拝借しています。 例えば日本語版ではこちらのページです。 更新頻度は2012年4月15日の時点では2時間おきに3ツイートとなっています。 ただしこの頻度は今後様子を見ながら変えていくかもしれません。 プログラムの目的、および開発の動機 Vimのコマンドをたくさん覚えて立派なVimmerになりたい！と考えているプログラマがターゲットです。 自分から積極的に勉強しよ
JavaやC#の常識が通用しないRubyのprivateメソッド - give IT a try
衝撃を受けたできごと 最近Rubyを勉強しています。 JavaやC#でオブジェクト指向プログラミングの基本はマスターしてるから、Rubyもそのあたりは楽勝〜！・・・と思っていたら、JavaやC#の常識が全く通用しない振る舞いに遭遇してかなり衝撃を受けました。それは、 privateメソッドはサブクラスからも呼び出せる ・・・ということです！！がーん。 たとえば、JavaやC#だと自分のクラス内でprivateメソッドが使われていない場合、不要なメソッドとして削除できます。(リフレクションを使って呼び出される可能性はここでは無視ね) しかし、Rubyでは誰かがサブクラスを作って呼び出している可能性があるので、privateメソッドを削除する場合は注意が必要です。メソッド名を変更する場合も同様ですね。 また、知らずに親クラスと同名のprivateメソッドを定義すると、予期せず親クラスの実装をオ
これまでに読んできた技術書を振り返る - give IT a try
このエントリを書こうと思ったきっかけ irofさんのこちらのエントリが面白かったので、僕も技術書についてあれこれ書いてみたくなりました。 私の技術書の選び方 - 日々常々 僕の場合は技術書の選び方、というテーマではなくて、自分が技術書とどのように付き合ってきたのかということを振り返ってみたいと思います。 序盤 僕もこの業界に入った時は、技術書らしい技術書よりも「xxxポケットリファレンス」とか「逆引きxxxの技」みたいな、「書いてある内容をそのまま書き写せば終わる」タイプのリファレンス本をよく買っていた気がします。 代表的な一冊はやはりコレですね。 【改訂第3版】 SQLポケットリファレンス (POCKET REFERENCE) 作者: 朝井淳出版社/メーカー: 技術評論社発売日: 2009/04/29メディア: 単行本（ソフトカバー）購入: 6人 クリック: 117回この商品を含むブログ
FizzBuzz問題が解けなかった理由を聞いてみた - give IT a try
はじめに かなり大きな反響があった第１回社内プログラミングコンテストの後日談です。 FizzBuzz問題が解けなかったメンバーに、なぜ解けなかったのか、どうすれば解けていたのかを質問してみました。 また、第１回コンテストの良かった点、悪かった点をふりかえり、次回以降の改善ポイントを考えてみます。 何の話かよくわからない方は先にこちらをどうぞ↓ FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try なぜ解けなかったのか、どうすれば解けていたのか？ メンバーの回答から、解けなかった理由をピックアップすると以下のようになります。 Perlに慣れていなかった 起動時引数の取得やあまりの求め方を調べるのに大半の時間を使ってしまった Perlの業務経験は改造案件が中心で、この種のプログラムをゼロから作ったことがなかった ルールを勘違いして、もっと得意な
FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに！？ ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第１
正規表現で楽々コード置換 - give IT a try
会社で紹介した正規表現の入門的なテクニックをこっちにも載せておきます。 まずは例題から ちょっと訳あって、これまで型付けDataTableを使って書いていたロジックを、型無しのプレーンなDataTableに書き換える必要が出てきました。 イメージ的にはこんな感じです(もちろん説明のためにかなり簡略化しています)。 // 変更前 BookShopDataSet.BookTable table = FindBooks(); BookShopDataSet.BookTableRow row = table[0]; Assert.AreEqual("詳説 正規表現", row.Title); Assert.AreEqual("ジェフリ− E．F．フリ−ドル", row.Author); Assert.AreEqual("オライリージャパン", row.Publisher); // 他にもたくさんの
開発時間短縮のためのプラクティス10選 - give IT a try
このエントリを書いた背景 先日会社で「開発時間を短縮するためのアイデアやノウハウをみんなでシェアしよう」という課題が出されました。 「カウボーイコーディングとコピペプログラミングで技術的負債たっぷりのシステムを作りましょう。そうすれば開発時間はぐっと短くなりますよ」なんてことは口が裂けても言えないので、真面目に考えてみました。 色々あるとは思うのですが、その中でも特に重要だったり、言語や技術を問わずに使えそうなものを10個選んでみました。 どれもまあ、基本中の基本だったり、アジャイル開発だと常識的に行われているようなことばっかりかもしれません。 とはいえ、おいらの会社に限定されるような話は載っていないので、ここにもその時に書いた内容をそのまんま載せておきます。 ただし、あなたの仕事とおいらの仕事は少し違うと思うので、読む前に以下の前提条件を確認しておいてください*1。 このエントリを読む前
O/Rマッピングツールに対する誤解をときたい - give IT a try
2010.12.23 追記 本エントリの続編となる「実装編」のブログを書きました。 こちらも合わせて読んでみてください。 O/Rマッピングツールに対する誤解をときたい -実装編 Part1- - give IT a try 本文にコメントすると泥沼に巻き込まれそうなので、ここに書いておきます。。。 http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.html なんかこのコラムのコメントを読んでいると、「O/Rマッピングツール(ORM)はSQLを書きたくない開発者のためのツールだ」と思われているような感じを受けます。 おいらはこれまでORMを使った開発プロジェクトに3回参加しました。 確かに最初のプロジェクトでは「SQLを書かなくてもいいんだよ」とリーダーから説明されたような記憶があります。 しかしその発想は大きな誤解です。 ORMを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
