Ruby を始めて7日目、FeedlyGraph を公開しました

f:id:khei-fuji:20140418211459j:plain

photo credit: AJC1 via photopin cc


このたび FeedlyGraph を公開しました。


経緯

はてなブログでは Feedly の購読者数がいつの間に増えたかがわかりません。
ググるとかなり惜しいサービスはありましたが、僕のニーズとマッチしなかったので自分で作ることにしました。


概要

FeedlyGraph は、Feedly の購読者数の推移を見える化するサービスです。
こんな感じ。

Feedly Graph ギズモード・ジャパン


FeedlyAPI では過去の購読者数は取得できません。
今日から購読が始まったように見えるのはこのためです。


このブログも早速登録しました。
グラフの形は同じですが、数値が全然違いますね。

戦闘力・・・たったの12か・・・ゴミめ


一度表示すれば、翌日以降のデータは自動的に蓄積されるようになっています。
(そのはずです・・・)


環境

Rails + Heroku というオーソドックスな構成?です。
Ruby歴2日で月曜から作り始めたので、いろいろとおかしなところがあるかもしれません。


今後の予定

をするつもりです。
が、あくまでも予定です。


最後に

僕以外の方にニーズがあるかわかりませんが、もし利用された方がいれば、コメントや要望などいただけると励みになります。
その際は Twitterブコメでお願いします。


Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

Webサービス開発徹底攻略 (WEB+DB PRESS plus)

Webサービス開発徹底攻略 (WEB+DB PRESS plus)

  • 作者: 勝間亮,石田忠司,杉谷保幸,江口滋,上谷隆宏,青木俊介,久保達彦,池邉智洋,谷口公一,田淵純一,伊野友紀,西岡拓人,吉田俊明,古旗雅史,木野瀬友人,かなだまさかつ,牧本慎平,成田一生,舘野祐一,濱崎健吾,鈴木慎之介,齊藤宏多,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/01/26
  • メディア: 大型本
  • 購入: 6人 クリック: 65回
  • この商品を含むブログ (3件) を見る


HTML で適切なマークアップが分からないからサンプルコードに頼ってみた

html5

photo credit: yukop via photopin cc


HTML のマークアップはなかなか迷ってしまうもの。
正解が全然わからないので、いろんなサンプルコードに頼った記述をしている。

TwitterBootStrap あたりとか。


メリット

それらしく書ける

特に見た目の再現性(サンプルに対して)は高い。


マークアップの根拠がある

Demo コードを書いてるのは Web 業界の諸先輩方なので、かなり適切な記述をしてくれているはず。


デメリット

身につかない

基本的に Selector のための修正くらいしかしないので、記述自体が身につかない。


応用がきかない

UI が Demo ページ以上のものにならない。
Sample コードの詰め込みなので、トータルすると UI の完成度は低い。


最後に

昨今のモバイル事情などでフロントエンドの重要性はかなり高まっている。
ちゃんと勉強しよう。


よくわかるHTML5+CSS3の教科書

よくわかるHTML5+CSS3の教科書

これからの「標準」を身につける HTML+CSSデザインレシピ (Web Designing Books)

これからの「標準」を身につける HTML+CSSデザインレシピ (Web Designing Books)


特徴ばかりがひとり歩きするオブジェクト指向

世のプログラマオブジェクト指向をどのように教えているだろうか?
下のオブジェクト指向の特徴を教えて終わりとしてないだろうか?


僕はこんなふうに教えるものだと思ってた。
「人と犬は走り方の違いがあるけど、どちらも抽象的には動物だし、走るよね。」
でも最近は違うと思うようになってきた。
(ほんとに今さらだ)


特徴を教えることはもちろん必要だ。
問題はオブジェクト指向の教育=特徴の紹介となっていることだ。
これがどんな問題をはらんでいるだろうか。


問題

抽象的な概念を構造化できない

User とか Page とか、学生でも具体的な概念が理解しやすい要素は問題ない。
問題は抽象的な概念だ。

たとえば HTTP には Cookie や Header や Parameter がある。
これらがどういうものかは Web 系プログラマーならわかるだろう。
これが初心者からすれば、Cookie も Header も Parameter もただの送信データ。

これを構造化しようとすれば、ごちゃ混ぜにしたりと悲劇が生まれる。
(もちろん HTTP は言語の標準ライブラリがあるだろうから自分で書く必要はないけど)


名前がつけられない

初心者にアドバイスをして、適宜抽象的な概念に分けるように促した。
一歩前進。


しかし初心者はすぐに詰まる。
抽象的な「それ」を何と呼んだらいいのかがわからないのだ。
彼らには名前候補のレパートリーがない。


適切な名前が付けられないから役割があやふやになってしまう。
適切な名前が付いているのにその意味がわからないから余計な機能をつけてしまう。


たとえば .NET では FileStream や MemoryStream の上位クラスに Stream があるという構造だけど、Stream なんてプログラマをやらないと出てこない概念だ。


解決策

基礎を学ぶ

これはこれから学ぶ人に対しての解決策。
残念ながら簡単な解決策ではない。


残業するなら勉強しよう でも書いたけど、僕は基礎学習が有効だと思う。
Web に関しては「Webを支える技術」を読めば間違いない。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)


「資格は役に立たない」なんて言って何も勉強しないプログラマもいるけど、IPA情報処理技術者試験はよくできている。
僕はプログラマーになる前に基本情報技術者を取ったけど当時はよく分かっていなかった。 その後、開発経験と紐づいて初めて理解できて活用できたと感じた。


言語の標準的なライブラリに触れるのもいい。
さまざまなパターンの構造があり、学ぶところが多い。
名前づけの目安も身につく。


オブジェクト指向を意識させない

これは初心者をメンバーに入れる経験者側の解決策。


Rails をはじめとした MVC フレームワークはとてもよくできている。
この手のフレームワークでは、フレームワークが肩代わりしてくれる分、コードを書く量が少なく済むということは言うまでもない。

僕が素晴らしいと思うのは、「プログラマーの技量によってプログラム構造に極端な違いが生まれづらい」ことだ。


たとえば View のためのユーティリティは Helper という名前がついている。
あとは FooHelper の Foo の部分の名前だけ考えればいい。
アプリケーションの構造は既に出来上がっている。
大半の人は構造化を意識しながらプログラミングしなくて済むのだ。


そのうち一部の人はフレームワークに手を加えたり、全体像を構成したりできるようになる。


最後に

目的はプログラムを適切な大きさ・役割に構造化し、メンテナンスしやすくすること。 オブジェクト指向はあくまでも手段。
継承やポリモーフィズムはその表現方法に過ぎない。


よい構造、いわゆる読みやすいコードを書くために必要なスキルは、生まれ持ったセンスではなくて、IT技術のあらゆるレイヤーの知識や仕組みを吸収してきたかに尽きると思う。


オブジェクト指向」だけを切り取って教えることは敷居を下げるためには必要なんだけど、それだけだと困るよねという現場からの意見でした。


オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

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

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


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 だとモジュールがあるようで羨ましい


利用シーン

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


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