Ruby を始めて2日目の僕が驚いたこと

驚いた

photo credit: Kmark via photopin cc


Ruby を初めて 2日目。
Railsチュートリアル第4章Ruby の基本的な使い方を学んだ。


Ruby を使って驚いたことがいくつかあったのでまとめておく。
(プログラミング経験はそれなりにある。C#JavaScript, PHP など)


Rubyist の方は、初めて Ruby に触れたときのことを思い出すきっかけに。
Rubyist の方は、Ruby に興味を持ってもらえるきっかけになれば。


なお、いくつかのコードは Railsチュートリアルから抜粋している。


end はあるけど begin しない

多くの言語では関数やブロックを中括弧で括る。
Pascal 系言語では begin 〜 end で括る。

Ruby では begin なしで急に end が出てくる。

if string.empty?
  "string is empty!"
else
  "string is not empty!"
end


考えてみれば begin のきっかけになる if 文や for 文(Ruby では each)が目印になる。
だから begin がなくても成り立つのか、と納得させられた。


配列のインデックスにマイナスが入る

配列にマイナスのインデックスでアクセスすると、今までの言語ではエラーとなったり、メモリの怪しいところにアクセスする。


これが Ruby では -1 は配列の最後、-2 ならその手前、-3なら・・・となる。

>> a = [1..5]
=> [1, 2, 3, 4, 5]
>> a[2..(a.length-1)]
=> [3, 4, 5]
>> a[2..-1]
=> [3, 4, 5]


インデックスで落ちないための設計というわけではなく、array[array.length] にアクセスすると nil が返る。(デフォルトの場合)


array[0..-1] とすればすべての値を取得できる。
length を取る手間が省けて嬉しい。


関数に丸かっこがいらない

今までの言語では、メソッドには丸かっこがつきもの。
丸かっこがなければプロパティという切り分けだった。


これが Ruby では丸かっこを省略できる。

def string_message(string)
  if string.empty?
    "string is empty!"
  else
    "string is not empty!"
  end
end

>> string_message("test")
=> "string is empty!"
>> string_message "test"
=> "string is empty!"


これは・・・微妙な気がする。
前向きに捉えれば丸かっこはキーの位置からすると打ちづらいし、なければ早く書けるのかも。


まだ Ruby 界隈がよく分かってないけど、省略は基本的に使うべきではないのかも。
Rubyコーディング規約


既存のクラスに関数を追加できる

JavaScript では prototype の拡張がこれに当たる。
C# で言えば拡張メソッド。


class String
  # 文字列が回文であればtrueを返す
  def palindrome?
    self == self.reverse
  end
end


僕のようなアプリケーションエンジニアは使うべきではないと思う。
使うとすれば「 JavaScript でよくあるブラウザバージョンの挙動の違いを吸収したい」みたいなケース。


Railsチュートリアルでもこれを注意喚起した文章が書いてあった。

組み込みクラスの変更はきわめて強力なテクニックですが、大いなる力には大いなる責任が伴います (訳注: 「スパイダーマン」の名台詞)。従って、真に正当な理由がない限り、組み込みクラスにメソッドを追加することは無作法であると考えられています。
Railsチュートリアル - 4.4.3組込みクラスの変更


インスタンス変数にアットマークがついてる

インスタンス変数=メンバ変数。
Rubyインスタンス変数を扱うときはアットマークが先頭につくことになる。


class User
  attr_accessor :name, :email

  def initialize(attributes = {})
    @name  = attributes[:name]
    @email = attributes[:email]
  end

  def formatted_email
    "#{@name} <#{@email}>"
  end
end


これは嬉しい。
変数名で見分けが付くようにしようなどと考える手間が省ける。


最後に

新しい言語を学ぶってやっぱりワクワクする。
多くの OSS 界隈のプログラマを虜にする Ruby & Rails のことだから、まだまだ驚かされることになるんだろう。
期待しよう。


Ruby on Rails 4 アプリケーションプログラミング

Ruby on Rails 4 アプリケーションプログラミング


リーダブルコードを読みました

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

素晴らしい本だった!!
印象に残ったところを中心にまとめておく。


名前大事。超大事。

大事なことなので二回言いました。


抽象的な名前よりも具体的な名前を使う

下のコードでは誤解が生じる。

引数の単位は何だろう?
秒?ミリ秒?


実装を読めばわかるだろうけど、そうしなくてもいいようにすべきだ。


単位が明らかになった。


どれくらいの抽象度で書くべきかは都度判断するしかない。


誤解されない名前

下のコードでは2通りの解釈が生まれてしまう。

  • 問題があった場合に true が返る
  • 問題がなかった場合に true が返る


これはよくない。
曖昧さを残さない名前をつける必要がある。


これならば解釈の違いは生まれない。


テストコードに状況を書く

こういうテストは書くべきではない。


テストコードはプロダクト自体のコードと比べて雑に扱いがち。
さほど複雑でないメソッドのテストならなおさら。
上のコードのように一つのメソッドに詰め込んでしまうこともある。


でも大抵の場合、複雑さは後々増していく。
後でテストコードを追うのは至難のワザ。 なので初めからテストコードが想定する状況を名前に書くようにするのがベター。


自分以外の誰かがメンテナンスする場合にこの基準に合わせてコードを書いてくれることも期待できる。


最後に

気軽に読める分量で、この本自体がリーダブル。
Kindle 版がないのが唯一の不満。


プログラマーならば必読といっていい。
デブサミの技術書大賞にあがったのもうなずけた。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)


点と点が線になる瞬間

プログラマをやっているときの醍醐味の一つが「点と点が線になる瞬間」だと思う。
これは週に1度感じるときがあれば、運が悪いと半年に1度も出会わないこともある。
今日出会った小さい事例を具体例にあげてみる。


背景

まずは僕のコンテキストをあげておく。

  • Windows プログラミングがメイン
  • 社内ツールレベルの LAMP 経験あり
  • 4年くらい前に Rails やろうとしたが構築が面倒で断念した
  • 最近 Rebuild.fm をよく聴いてる


事例紹介

僕は作りたいものがあった。
PHP で書いても技術的なチャレンジがなく、面白くない。

Rails

おもむろに Rails 熱がこみ上げてきた。
Ruby, Rails を基礎から学ぶため、定番のドットインストールにお世話になることに。


動画中で Vagrant(仮想化環境を簡単に作るツール)使って開発環境を構築する、ということだったのでそちらも並行。


余談だがこんな事態になった。


VagrantVirtualBox

気を取り直して動画を進めると、VagrantVirualBox(フリーの仮想化ソフト)のラッパーだということが判明。(VMWare も対応)
この時、1本目の線


僕は社内ツールのホストで VirtualBox を使っていた。
まさかこんなところで役立つとは思っていなかった。
大体 Vargrant がどんなことをやっているかがわかり、学習コストがカットされた。


Vagrant と ベイグラント

動画内で「ベイグラント」という言葉がよく出てくることに気づく。
そして僕は「ベイグラント」を既に知っている。
なぜならRebuild.fm 14 に出てきていた。


Vagrant」は知らないものだと思っていた。
「ベイグラント」=「Vagrant」であることに驚くのと同時に、
自分がそれに気づかないレベルの英語力ということにも驚く。
(音で聴くのと単語を見ているときで、言葉がつながらないのはよくある・・・)


Rails の記憶

Vagrant では、ググって出てきた rails-dev-box を使うことに。
Vagrant 入門を進めていく間に Vagrant の設定を見てみると、

config.vm.network :forwaded_port, guest:3000, host:3000

こんな設定が。
ここで2本目の線

4年前のかすかな Rails の記憶が蘇り、Rails がサーバを内包していたことを思い出す。
Vagrant で立ち上げたゲストOS内のRailsアプリには、ホストOSから localhost:3000 でアクセスできるということに気づく。
Vagrantrails-dev-box はよく出来てると実感。


再度 Rebuild.fm

ドットインストールを進めていると、このサービスの特性上、広く浅い知識にとどまることに気になり始める。
そこで3本目の線
Rebuild.fm 35 で紹介されていたスポンサー Railsチュートリアル を思い出す。


ということで今はドットインストールと Railsチュートリアルを進めているところ。
はじめに思い描いた作りたいものが全く進んでいないのはご愛嬌。


最後に

今回挙げた事例で「点」の部分の Rebuild.fm 率が高すぎて焦った。
オープンソース界隈かガジェットが好きなら間違いなくこれは聴くべき。


独学で勉強するにはやる気が出ないと続かない。
自分なりの楽しみを見つけていく工夫が必要だ。


僕の場合はそれが「点と点が線になる瞬間」を見つけることだ。

Rebuild

Rebuild

  • Tatsuhiko Miyagawa
  • ソフトウェア ハウトゥ
  • ¥0
Vagrant入門ガイド

Vagrant入門ガイド


HTML-ShowCaseを公開しました

ソースコード(GitHub)

街で見かけるフライヤーのショーケースをHTMLで表現しました。
時間経過でコンテンツが切り替わる電子掲示板として利用できます。

from Readme


デモはコチラ


デモのデプロイ先は前回も利用した DropBox です。
↓前回の記事
読みたい・気に入った本をレスポンシブに公開してみた


コードについて

はじめは JavaScript で書いていたのですが、TypeScript で書き直しました。
↓TypeScript の導入記事
Mac で Sublime Text を使って TypeScript を始めるまでの手順


cron のスケジュール記法に対応したかったので少しばかりのテストを書いています。
しかしn分毎の表記に対応するのが面倒で需要がないので対応していません。
Rails だとモジュールがあるようで羨ましい


利用シーン

職場の大型ディスプレイで会社の情報を表示しています。
夜になったら「さっさと帰れ!」ってスライドを出すのが夢です。


街中のポスター張り替え作業はこういうツールに置き換わる未来を想像していますが、 変わらないのはまだディスプレイのコストのほうが高いようです。



優秀なプログラマーとは?要因を4象限で考えた

優秀なプログラマーかそうでないかを分ける要因として何があるかを考えた。


「センス」と「努力」だ。
図に表すとこんな感じ。


プログラマー4象限

プログラマーを4象限に分けてそれぞれについて考察を書く。
前提として、

  • センス=飲み込みの早さ
  • 努力=学習意欲の高さ・学習を行うスピード

を指す。


第1象限(センスがあり努力する)

いつもOSSをはじめ、各種ツール・ライブラリ・イベント・ブログなどでお世話になっているのはこの人達。


具体的に言うと誰かと言われるとわからない。
名前を上げたところで謙遜して、単に努力しただけと答えるだろう。


パレートの法則に見るように、こういうプログラマーが全体のレベルの底上げをしているのだと思う。
今後もお世話になります。


第2象限(センスはないが努力する)

日々学習することをいとわない人。


われこそは凡人だという人は、基本的にここを目指すべき。
その結果、いつかは第1象限にたどり着けるのだと思う。


多くの人が「自分はこの象限に属している」と考えている。
実態は、努力の方向性が間違っていることがざら。


たとえば残業や雑務が多い人。
その代わりに、残業する原因のスキル不足を補うための勉強をしたり、
雑務を人がやらなくていいようにシステム化(コードに限らずルールの場合も)するのがプログラマーとしての態度だと思う。


第3象限(センスはなく努力しない)

たまにいる「なんでこの業界選んだの?」って人。
上で書いた「努力の方向性が間違っている人」はこの象限に属する。


開発するために必要な技術や知識は常に誰かから下りてくるものだと考えていて、受け身である。
会社ってそういうものだよね、と言われればそうかもしれないが、プログラマーみたいな自己学習の必要性が高い職業には向かない。


ほかに、我が強く人のアドバイスに耳を貸さない。

今までと同じ考えや行動を繰り返して、異なる結果を期待するのは狂気である。
アインシュタイン


第4象限(センスはあるが努力しない)

自己学習がなくてもなんとかなるのがここの人。
会社に所属して働くうえで適宜教育すると、その教育だけで仕事に必要なスキルの必要条件を満たしてくれる。
初心者に陥りがちな、「複雑さを防ぐために説明しない部分が気になってしまう」ことがない。
フォーカスした部分に対して任務を遂行してくれるというイメージ。


キャリアのはじめのうちはいいが、後から第2象限の人に追い抜かれる。


最近はこの人達の存在が第3象限の人の存在を助長しているようにも思える。


最後に

こうして考えると、自分は第3象限と第2象限を行ったり来たりしている。

プログラマー4象限 現実

どうせなら上を目指して、こういう流れに向かっていきたい。


プログラマー4象限 理想


情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

Mac で Sublime Text を使って TypeScript を始めるまでの手順

仕事では VisualStudio 使ってます。

VisualStudio 使えば TypeScript はサポートしてくれるけど、
ちょっとしたライブラリを書く程度なら Mac でオシャレに書きたい!
ということで Mac で開発環境を整えました。


エディタ

Sublime Text 2 を採用しました。


Sublime Text 2ってエディタがすごくイイ。Dreamweaverから乗り換えた時の初期設定とか使い方とかをメモ | Mnemoniqs Web Designer Blog

今まで使ったことなかったので、上の記事を参考にしました。


いくつかのパッケージはデフォルトでインストールされるようになっているらしく、
参考記事で紹介されていたもののうち、いくつかは見つかりませんでした。


インストール済みのパッケージ

  • HTML
  • CSS
  • jQuery(これは記憶が不確か)


「もう使うな、こっち使え!」って書いてあったパッケージ

  • CSScomb JS(CSScomb)


見つからなかったパッケージ

  • Tag


インストールと同時にパッケージ入れると、どこまでがエディタの標準機能なのかわからないのでほどほどにしておきます。


TypeScript のインストール

この記事 を参考にしました。


Node.js と TypeScript はインストールするだけ。
続いて TypeScript パッケージをインストール。
参考記事は英語だけど、順を追っていけばなんとかなるはず。


ビルドの設定までいったところで驚く。


Sublime Text に Build コマンドがついている!」


ただのエディタだと思ってなめてた。
もはやエディタと IDE の違いが私にはわからない。
言ったもん勝ちなのかな。


HelloWorld 書いてビルドすると、No Such File or Directory とエラー表示される。
どうやら tsc (TypeScript のコンパイラ)が見つからなかった模様。

{
    "cmd": ["tsc","$file"],
    "file_regex": "^(.+?) \\((\\d+),(\\d+)\\)(: .+)$",
    "line_regex": "\\((\\d+),(\\d+)\\)",
    "selector": "source.ts",
    "osx": {
       "path": "/usr/local/bin:/opt/local/bin:/usr/bin"
    }
}

私の環境では /usr/bin にインストールされていたので、
こんな感じで参考記事の path の設定だけ修正したところ、動作しました。


それにしても Sublime Text 軽いな〜。
設定もエディタで書かせたり、パッケージの概念が入ってたりと、今までのエディタの価値観が変わった。


Web制作者のためのSublime Textの教科書 今すぐ最高のエディタを使いこなすプロのノウハウ

Web制作者のためのSublime Textの教科書 今すぐ最高のエディタを使いこなすプロのノウハウ

2ch とまとめサイト管理人の行方を考える

まとめサイトの行方

photo credit: Lori Greig via photopin cc


2ちゃんねる転載禁止の余波で「痛いニュース」が迷走中 - Hagex-day info
膨大なPVを持っているのに沈みゆく「まとめサイト」 - Hagex-day info


乗るしかない、このビッグウェーブに。


現状

2ch の年齢層SNS の利用度合いを見ると、

  • 学生は 2ch+SNS
  • 20代はSNSが中心
  • 30代〜40代はSNS2chが拮抗
  • 50代以降はネット利用自体が少ないが、SNSが中心

こんな利用実態。

(時間が豊富な学生は抜きにして)2ch ユーザの高齢化は進んでいるため、2chは緩やかに衰退していくと思う。



ただ気になるのは、過去ログを無償公開しようという管理会社の代表と見られる人物の動きだ。
2chにおいてこういった動きは今までなかったため、面白いことをしてくれそう。


提案

そこで提案だが、この際 2ch 公式のまとめサイトを作って、そこで収益を上げていくような動きをしてはどうだろうか。

本当に運営費がひっ迫しているのかは分からないが、まとめサイトが収益を生む以上は自ら運営するのが手っ取り早い。

2ch存続のために公式が運営するとなれば、転載禁止を投票した住人の理解も得られるだろう。


もちろんまとめサイトの管理については、絶賛衰退中のまとめサイト管理人を安く雇えばいい。

雇用創出になるし、2ch住人はもちろん、私のようなまとめサイトを毛嫌いする人間の溜飲を下げることができる。


今の状況が1年くらい続けば、まとめ作業のみに精通しているだけで、自らコンテンツを生み出す力は持っていない人が職を求めるはず。

そのときに手を差し伸べるのは、転載元の 2ch 自身になるというのは面白そう。


まとめ?(通常盤)

まとめ?(通常盤)

まとめ?(通常盤)

まとめ?(通常盤)