Java♡HTML5 Night で話してきた

Event Java HTML5

Java ♡ HTML5 Nigtht で「JavaとHTML5のこれまで」と「WebSocket概要」について話してきた。

Java & HTML5 History

HTMLのスライドはこちら。

1993年からの20年を振り返ってみた。資料作りながら、感慨深い思いだった。JavaとHTML5を合わせてみてみると、なかなか楽しかった。
Javaの歴史については、こんなサイトがあった。英語だけど。HTML5でパララックスなサイト。ソースを覗くとbodyにはdivとimgしかなかったｗ

Java 5 が2004年で、ジェネリクスや拡張forループが入ったのはもう9年前かと。同年WHATWGが発足している。
2011年には、Java SE7がリリースされ、HTML5がLast Working Draftになった。いろいろ動いた年だった。
Java も HTML も停滞していた時期があったけど、いまはどんどん変わっていくので、これからが楽しみ。

WebSocket on Glassfish

HTMLのスライドはこちら。

Glassfishを使ったWebSocketのサンプルをライブコーディングしてきた。あとはnode.jsでのWebSocketのサンプルも紹介した。

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package websocket.sample;

import javax.websocket.Session;
import javax.websocket.WebSocketEndpoint;
import javax.websocket.WebSocketMessage;

/**
 *
 * @author sada
 */
@WebSocketEndpoint("/echo")
public class NewClass {
    @WebSocketMessage
    public String echo(String message, Session session){
        return session + " "  + message;
    }
}

これはほぼ最小限のサンプルだと思う。受け取った文字列を返すだけのechoサーバ。
Javaでこれだけ短いコードでWebSocketが使えるって、なかなかすごい。

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>JSP Page</title>
        <script src="http://code.jquery.com/jquery-1.8.2.min.js"></script>
        <script>
            $(function(){
                var host = "ws://localhost:8080/WebApplication3/echo";
                var socket = new WebSocket(host);
            
                socket.onmessage = function(message){
                    console.log(message.data);
                }
                $("#sendBtn").on("click",function(){
                    message = $("#message").val()
                    socket.send(message);
                });
            });
        </script> 
    </head>
    <body>
        <h1>Hello World!</h1>
        <input type="text" id="message" />
        <button id="sendBtn">send</button>
    </body>
</html>


細かいことはこっちに書いた。

これまでもTomcatやJettyでWebSocketを仕えたけど、こうやってアノテーションベースで書けるとすごく便利。そもそもこのコードはServletでさえないし。
JavaでWebSocketのクライアントも書けるから、いろいろ活用できるところは多いと思う。なかなか楽しい。

いろいろ

Node.jsの環境構築とサンプルを動かすまで。(Macのみ)


資料は reveal.js を使って作った。PDF出力もできるので、PDFにしたものをSlideShareに上げている。HTMLの資料もあげたいけど、バギー過ぎるのでとりあえず、PDFで。

まとめ

僕が初めてプログラムを書いたのはJavaだった。大学に入ってから、授業で書いた。それから10年以上ずっとJavaを使っていた。仕事だけじゃなく、趣味としてもJavaを書いていた。
Java Hot Topicには何回も参加したし、ここでもJavaのことをいろいろ書いていた。

いまはJavaを書いてないけど、今回の勉強会のために書いてみて、Javaも変わっていってるんだ、ということを感じた。

Javaを使わなくなってから、まさかこんなふうに話をする機会があるとは思わなかった。嬉しかったし、とても光栄なことだった。エンジニアをやっていると、いろいろなところで繋がるな、と。


自分より詳しい人がたくさんいて緊張した。でも懇親会で楽しそうに話してましたねって言われて、それが嬉しかった。話している技術の楽しさが伝わるといいなと思ってやっていたので。

GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" に行ってきた。

Event Ruby


GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" に行ってきた。

togetterはこちら。


印象に残ったことだけピックアップして書く。


立ち上げから利用者300万人までの軌跡

  • PJ Hyett(Github, Inc. COO)
  • Scott Chacon (Github, Inc. CIO)

Err the blog
クリスと一緒に立ち上げたブログ。これを通じてRubyコミュニティのなかでは有名になった。


大企業が嫌で Err Free というRubyのコンサルをやる会社を起こした。でもコンサルはクライントが上司になるようなものだった。
dogtimeという犬向けのソーシャル・ネットワークを作った。クライアントはよかったが、あまり犬向けのSNSを作る気になれなかった。



自分たちで初めて作ったプロダクトは famspam。家族向けのMLみたいなもの。楽しかったけどお金にならなかった。


SF Ruby Meetupを楽しみにしていた。Rubyについて語りバーでお酒を飲む。バーでトムに出会った。デザイナもしていた。
ここでgithubのアイディアもでてきた。一番重要なアイディアはforkだった。当時はforkはネガティブなイメージがあった。あまりメンテナンスされないものを、誰かがフォークして続けるといった感じ。forkをポジティブなものにしたかった。


Githubは自分たちが使いたくて作った。最初は Logical Awasome という会社で、githubはプロダクトのひとつのつもりだった。



あるときユーザがお金を払いたいといった。EngineYard。人件費の次にホスティング費用がかかるEngineYardがスポンサーに。ロゴを出すことで、無料でホスティングしてもらった。


最初はサインアップもできなかった。メールをもらってDBに手動でユーザを作る。beta invatesは10人招待できる。招待された人も10人を招待できる。バイラルに広まり、ゆっくりと進められた。
最初はサインアップもできなかった。メールをもらってDBに手動でユーザを作っていた。その後、beta invatesでは10人招待できた。招待された人も10人を招待できる。バイラルに広まり、ゆっくりと進められた。
(thanks id:pullphone)


最初の2年間はオフィスがなかった。onlineでコミュニケーションを密にとる。CampFireとGithubで進めた。自分たちで改善すれば、自分たちの作業効率があがる。



Public launch 2008/04/10。スムーズにいった。Ruby on Rails も当日に GitHub に。リリース後はみんなでバーで乾杯した。


MeetupをしていたがDrinkupになり、Drinkupを通じてスコットを採用した。Gitの知識がものすごい。毎週異なる言語でGitを書き換えたり。


Githubは多少利益をあげていたけど、充分な給料が払えなかった。でも毎月売上目標を立てて進めて、1年くらいでコンサル時代と同じくらいの給与になった。ローンチと同じくらい嬉しかった。


QA

社員を解雇していない。採用するときは何回くらい面接してるの、どんな面接？
辞めてないのは嬉しいことだけど、そこにフォーカスしているわけじゃない。信頼しているひとからの紹介を信じている。いいひとがはいると、そこからまたいいひとが紹介される。採用プロセスは特に決まっていない、そのひとのことを知ることにフォーカスしている。


githubは採用時に社員がその人を採用するか投票する。 +1 -1 +100がある。+100は投票した人がメンターとなって責任をとって育てる。


60-70%がリモートで作業しているとあったが、どうやってるの？
もともとonlineからはじまった。f2fのミーティングがない。出社することも必須じゃない。すべてonlineでやっている。



githubにユーザが集まったきっかけは？
面白いプロジェクトがサービスに載った。YouTubeは面白い動画があると拡散する。YouTubeを見たいのではなく、動画を見たい。それと同じような感じ。


Githubはどんなふうにマネージメントしている？
マネージメントはオープンソースと同じやりかた。好きなときに、どこからでも関わることができる。みんなで決めて進めていく。だれかが一方的にきめたりするわけじゃない。オープンソースのやり方で、githubのマネージメントしている。自分たちが働きたい環境を、自分たちで作る。


まとめ

テクニカルな話はあまりなかったけど、とてもおもしろかった。オープンソースと同じように仕事を進めるって、全然思いつかなかった。成り立つ気がするけど、自分ではなかなかできない。でも世界はそれでけっこう成り立っている。すごい。
多くの+1がもらえるのも嬉しいけど、+100 されるようなひとになりたい、と思った。


thanks [twitter:@yukop], [twitter:@tb_bot], mariko.

HTML5とか勉強会 / html5j.org のスタッフになって1年が経ちました

HTML5Study

HTML5とか勉強会 / html5j.org のスタッフになって1年が経ちました。
あっという間だった。スタッフになったときに書いた文章はこれ。懐かしい。


振り返り。


自分が主体となって勉強会の運営をすることはないけど、写真を撮ったり、受付したり、懇親会の準備したりしている。
以前の会社よりいろいろな活動がやりやすくなっているし、今年はもうちょっと違う形でも貢献したい。


1年経ったいまの気持ちは、去年書いたことからほとんど変わらない。

僕はまず、自分が楽しみたい。でも、自分がなにかして他の人が楽しんでくれると、自分も楽しくなるじゃない。それに自分が楽しめないことは、続けられないし。

もう1年、まだ1年。
去年よりも、もっとWebやHTML5が、楽しく、愉しくなるといいな。

Node.jsでWebSocketのサンプルを動作させるまで

JavaScript HTML5

Node.jsの環境構築から、WebSocketのサンプルを動作させるまでを書く。ちょっとはまったりしたので、そういうところも含めて書いておく。書いておかないと、自分がまたはまりそうなので。
インストールしたのは以下のバージョン。

  • nodebrew 0.6.2
  • node.js v0.8.18
  • websocket.io 0.2.1

Node.jsのインストール

brewで入れてみた。これは失敗。

# brew install node

nvmを使うべきだったか、とつぶやいたら、こもりさんが nodebrew がいいと教えてくれた。

brewで入れたやつは uninstall した。

# brew uninstall node


nodebrewのreadmeを見ながらインストール。

# curl https://raw.github.com/hokaccha/nodebrew/master/nodebrew | perl - setup

zshを使ってるので、.zshrcにパスを追加する。

export PATH=$HOME/.nodebrew/current/bin:$PATH
export NODEBREW_ROOT=$HOME/.nodebrew

反映させる。

# source ~/.zshrc

nodebrew が入った。

# nodebrew
nodebrew 0.6.2
...


node.jsのバージョンを確認する。

# nodebrew ls-remote
v0.0.1    v0.0.2    v0.0.3    v0.0.4    v0.0.5    v0.0.6  
...
v0.8.0    v0.8.1    v0.8.2    v0.8.3    v0.8.4    v0.8.5    v0.8.6    v0.8.7
v0.8.8    v0.8.9    v0.8.10   v0.8.11   v0.8.12   v0.8.13   v0.8.14   v0.8.15
v0.8.16   v0.8.17   v0.8.18   

v0.9.0    v0.9.1    v0.9.2    v0.9.3    v0.9.4    v0.9.5    v0.9.6    v0.9.7

0.8系は安定版、0.9系は開発版なので、0.8系の最新をインストールする。

# nodebrew install v0.8.18

インストールはこっちのコマンドのほうがよかったかも。

nodebrew install-binary <version>   Download and install a <version> (binary file)


node.js 入ったかな。入ってる。

# nodebrew ls-all
...
local:
v0.8.18
...

デフォルトのnode.jsを指定する。

nodebrew use v0.8.18
node -v
v0.8.18

これで node.js のインストールはおしまい。

websocket.io

WebSocketを使いたいので websocket.io を入れる。これは失敗。

# npm install websocket.io

コマンドを実行したディレクトリにインストールされるとこもりさんが教えてくれた。

websocket.io を uninstall する。

# npm uninstall websocket.io

npmのヘルプを確認する。なるほど。

# npm help install
In global mode (ie, with -g or --global appended to  the  command),
it  installs  the  current package context (ie, the current working
directory) as a global package.

もう一度 websocket.io をインストールする。

# npm install -g websocket.io
...
> ws@0.4.20 install /Users/sada/.nodebrew/node/v0.8.18/lib/node_modules/websocket.io/node_modules/ws

入った。いい感じ。

WebSocketを使う

サーバのコードはこんな感じ。ブロードキャストできるechoサーバという感じ。

var ws = require("websocket.io");
var server = ws.listen(8888,
  function () {
    console.log("ws start");
  }
);

server.on("connection",
  function(socket) {
    socket.on("message",
      function(data) {
        console.log("message " + data);
        server.clients.forEach(
          function(client) {
            client.send(data);
          }
        );
      }
    );
  }
);

こちらのコードを参考にさせていただきました。


ws.jsというファイル名で保存して実行する。エラーがでる。

# node ws.js

module.js:340
    throw err;
          ^
Error: Cannot find module 'websocket.io'
    at Function.Module._resolveFilename (module.js:338:15)

websocket.io が見えてない。ちょっと調べて、ファイルの先頭にこれを追加した。

require.paths.push('/Users/sada/.nodebrew/current/lib/node_modules');

実行する。require.pathsは無くなったから、NODE_PATHを使えと怒られる。

# node ws.js

Error: require.paths is removed. Use node_modules folders, or the NODE_PATH environment variable instead.
    at Function.Module._compile.Object.defineProperty.get (module.js:386:11)

NODE_PATHを使う。これを .zshrc に追記した。

export NODE_PATH=$HOME/.nodebrew/current/lib/node_modules

反映させる。

source ~/.zshrc

実行する。できた。

# node ws.js
ws start

クライアント側のHTMLとJSはこんな感じ。サーバにデータを送る、サーバから受け取ったデータを console.log に流すだけ。

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
  <script src="http://code.jquery.com/jquery-1.8.2.min.js"></script>
  <script>
  $(function(){
    var host = "ws://localhost:8888/";
    var socket = new WebSocket(host);
    console.log(socket.readyState);

    socket.onopen = function(){
      console.log(socket.readyState);
    }
    socket.onmessage = function(message){
      console.log(socket.readyState + " " + message.data);
    }
    socket.onclose = function(){
      console.log(socket.readyState);
    }
    $(window).unload(function() {
      socket.onclose();
      console.log(socket.readyState);
    })

    $("#sendBtn").on("click",function(){
      message = $("#message").val()
      socket.send(message);
    });
  })
  </script>
</head>
<body>
  <h1>Hello World!</h1>
  <input type="text" id="message" /><button id="sendBtn">send</button>
</body>
</html>

まとめ

node.js はいろいろなツールのプラットフォームになってきているから、インストールしなきゃなと思ってた。去年くらいから。ちょうどWebSocketを扱う機会があったので、node.jsをインストールしてみた。
いろいろ調べながら、ここまで大体1時間くらい。多少は前提知識があったのでこれくらいで済んだ。全くのゼロからだと、ちょっと大変かもしれない。
こもりさん、いろいろ教えてくださってありがとうございます。Thanks [twitter:@cipher].


多少はまったけど、それでもかなりスムーズに環境構築できた。nodebrewやnpmなど、node.jsを便利に使う環境がかなりそろっていて助かる。
環境構築が終わっていれば、いろいろさらっと試せる。これまではnode.js使うものだと、ちょっと面倒だなーと思ってしまうことがあったけど、これからはさくっと試してみようと思える。いろいろ使ってみたい。


ちゃんと勉強しないとねぇ。

サーバサイドJavaScript Node.js入門
サーバサイドJavaScript Node.js入門
posted with amazlet at 13.04.14
清水俊博 大津繁樹 Jxck 小林秀和 佐々木庸平 篠崎祐輔 高木敦也 西山雄也
アスキー・メディアワークス
売り上げランキング: 56,759
Amazon.co.jpで詳細を見る

東京Ruby会議10 #tkrk10 #p4d

ruby event

東京Ruby会議10

東京Ruby会議10に行ってきた。Rubyのイベントや勉強会は初めて参加した。
初日の午後は「Rubyistのためのデザイン講座」にずっと参加していたので、Rubyっぽい話は午前中だけ聞いた。
2日目は眠くて起きれなくて、基調講演は聞かずに11時頃行った。雪で14時終了になってしまったけど。
聞いたセッションはこんな感じ。

タイトル スピーカー
Rubyと過ごした半年間 井原正博さん [twitter:@ihara2525]
やさしいRails勉強会@東京のつづけ方 [twitter:@takkanm]
趣味とRubyと私 生井智司 [twitter:@ainame]
プログラミング未経験なんて怖くない！ 田垣亜季さん [twitter:@akiinyo]
周囲の助けを得ながら楽しく開発するためのアレコレ 蓮尾高志さん [twitter:@thso83]
RailsエンジニアのためのTwitter Bootstrapカスタマイズ例 [twitter:@machida]
少ない手間と知識で "それなり" に見せる、ズルいデザインテクニック [twitter:@ken_c_lo]
ノンデザイナーのための配色理論 [twitter:@saucerjp]
オトナの塗り絵で学ぶデザイン
Ruby、RoRでのオフショア開発をハノイで行ってみたら・・・ 本間紀史さん [twitter:@norifumi777]
東京にきて僕が作ったものについて Jun Fukayaさん [twitter:@fukajun]
Sole Rubyist's Fight [twitter:@yaotti]
ブログのススメ 前島真一さん [twitter:@netwillnet]

初日の Togetter はこちら。まとめてくださってありがとうございます。

Rubyと過ごした半年間

井原さんがみんなのカフェを作った時のお話。いいお話だった。

開発するにあたって、Ruby on Rails Guides/ Rails Tutorial / Code School / RailsCasts などで最近の技術を勉強しなおした。そのあと実際に開発して、9/21 に rails new して、10/15 にリリースしたとのこと。
企画開発運用を一人でやっていたので、一人Pivotal、一人Pull Request、一人CIしているそう。
スライドにこの言葉があって、ほんとうにそうだよなと思った。コード書けるなら、いろんなことができる。

What a wonderful world.

「やりたいことをやりましょう」、「life is short.」という言葉も印象的だった。

やさしいRails勉強会@東京のつづけ方

最近のrails勉強会はこんな感じとのこと。

  • 参加者は10-20人
  • テーマはその日に決める
  • 2-3つのテーマについて話し合う

気をつけていることで、「何か話して帰って欲しい」というのがあった。僕もHTML5とか勉強会のスタッフをしていて、いろいろ考える。参加者の交流が増えるといいよね。
長く続けた問題点として、「開催することが目的化してきた」ということが挙げれられていた。そして楽しく続けるために「自分のしたいことをする」ということが挙げられていた。ほかにもいろいろ挙げられていたけど、この2つは共感する。
楽しんで勉強して帰ってもらいたいけど、そもそも自分が楽しめないと続けられないよね。僕も楽しみながら、続けて行きたい。
直近の勉強会は予定が合わないけど、Rails勉強会に行ってみたい。

趣味とRubyと私

趣味での開発手法として、FDD(不満駆動開発)について説明があった。不満に思ったことを解決するために開発、これができなかったら死んじゃく！＞＜くらいの気持ちでやる。いいね。
地域Rubyコミュニティに参加して、Rubyでできた繋がりについても話があった。僕もこれからはRubyコミュニティに参加しようと思った。
参加したときは、よろしくお願いいたします。

資料はこちら。

プログラミング未経験なんて怖くない！

いまの僕に、とっても響いたセッションだった。
プログラミング未経験で、どのようにやってきたかということで、以下の3点を挙げられていた。

  • 真似する
  • 形から入る
  • 途中経過を見せる

「真似する」では「 永和のmasterには変なコードがない」という話があって、正直すごいなと思ったし、うらやましい。別にうちもそこまでひどいわけじゃないけど。
真似してると、自然とソースコードをたくさん読むから、既存のコードの理解に繋がる、いろいろな書き方があることを知る、といった話があって、そうだよな、と頷いた。
「形から入る」では、わからないけどやっていると、そのうち分かる瞬間が来て、わかった時にはやり方に慣れている、という話があって、こちらもとても共感した。

たぶん、こちらの記事のセッションをバージョンアップしたお話だと思う。

周囲の助けを得ながら楽しく開発するためのアレコレ

やっぱり周りを巻き込んでいくのは大事だな、と思った。アレコレは以下の4つにまとめられていた。

  • 作業環境を手軽にシェア
  • 開発環境を手軽に入手
  • メンバーの得意分野を見える化
  • 自分の状況を見える化

最初はちょっと固そうな感じだったけど、最後は「フリスク状のデバイスで脈拍をさりげなく計測し、Caps LockのLEDにさりげなく表示する」という内容で、会場は笑いと拍手に包まれた。
こういったことに、楽しく取り組んでいくって大切だよな、と思った。ちょっと環境が変わるだけで、ほかのメンバーが何をやっているのかわからなくなってしまったりするし。

資料はこちら。

RailsエンジニアのためのTwitter Bootstrapカスタマイズ例

ここからデザイン講座のセッション。このデザイン講座のセッションは、どれも自分の興味があるテーマだったのでとても面白かった。
色は、こんな感じで設定するみたい。でもこれが決められない。

  • ベースカラー(70%) → 地味な色
  • メインカラー(20%) → 好きな色
  • アクセントカラー(5%) → 目立つ色

そこで、好きな色を選んで、Sassの lighten や darken を使って色を決めたり、Sassの機能で補色(complement)を求めたりする方法が紹介されていた。
システマティックでいい。あと「色も設定より規約」という言葉が響いた。そのあとのherounitについての内容もわかりやすくて参考になった。

第一回 プログラマ向けデザイン勉強会のものだけど、資料はこちら。

少ない手間と知識で "それなり" に見せる、ズルいデザインテクニック

以前資料は見ていたんだけど、CSS力が低くてよくわからなかった。でもセッションで説明してもらって、半分くらいわかった。でも半分くらいはやっぱりCSS力が足りなかった＞＜
でも、わかんなくても、使ってみれば使えそうな気がした。細かいことは考えずに。
ズルい線、ズルい text-shadow、ズルい背景、ズルい角丸、あたりは使えそう。比較的簡単そうなので。
こうしちゃうと素人っぽくなる、っていうのが分かってよかった。例えば角丸の丸の半径が大きいと野暮ったくなりがち、とか。

第一回 プログラマ向けデザイン勉強会のものだけど、資料はこちら。

ノンデザイナーのための配色理論

配色はさっぱりわからない。セッションを聴いて、なんでわからないのかやっとわかった。自由度が高すぎてわからないんだとわかった。
こちらも以前資料は見ていたけど、背景知識が足りなすぎてよくわからなかった。セッションで説明を聴いて、いろいろ理解できて楽しかった。
理論を説明してもらえたのはよかったけど、それ以上に色を選んでいく過程を生で見れたのがよかった。ある程度は理論だって説明できるけど、やっぱり経験によるものも大きい。僕は色を選ぶという経験自体がほとんどなかったので、ささっと選んでいくところが見れて面白かった。

第一回 プログラマ向けデザイン勉強会のものだけど、資料はこちら。

オトナの塗り絵で学ぶデザイン

すごく楽しかった実習。サンプルはJavaScriptで見出しや背景色や文字色を変えられる。いくつか選べる色があって、それを選んで配色を試してみるという実習だった。
30分くらい配色を試すということで、けっこう長いなと思っていたけど、あっという間だった。
僕は勝手にこんなことを学んだ。

  • 面積の広いところに調和の取れやすい色をいれていくとやりやすい
  • 中間色を背景色にすると、コントラストが出しにくくなるので、きもくなる
  • 色を増やさないって大事。ついつい新しい色を入れようとしてしまう

文章にするのは難しいけど、いろいろなコメントがでてきて、ほんとうに面白かった。デザイナさんがどんなふうに考えているのか、ちょっとだけ知ることができた。

サンプルはこちら。

Ruby、RoRでのオフショア開発をハノイで行ってみたら・・・

Rubyでオフショアって、はじめて聞いた。でもなんだかか楽しそうだった。
ハノイでエンジニアを採用して、教育して、仕事を回していく。ベトナムでは転職は多いみたいだけど、Rubyをやったら楽しくてJavaに戻らないし、他にRubyをやってる企業が少ないので、人材の流出を止められるという話が印象的だった。
僕は仕事でRubyを書いてるけど、日本でもRubyをがりごり書く会社って少ないし。

東京にきて僕が作ったものについて

「PHPで関数を使ってはいけないというコーディング規約で開発」していた会社からフリーランスになったかたのお話。どうやってPHPで開発していたのか気になる。
毎週勉強会を開いているそう。毎週って、すごい。続けるためのポイントとして挙げられていた、「頑張り過ぎない」というのは本当に大切だと思う。さっきも書いたけど、まずは自分が楽しくないと続かない。
勉強会は、行くのもいいけど開くのもいいよね。

Sole Rubyist's Fight

Qiitaを一人で開発されていて、そのお話。僕も一人で開発することが何度かあったけど、ちょっと寂しいし、辛い。
ハッカソンはバックグラウンドがことなるエンジニアと交流できるのでおすすめとあったけど、ハッカソン行ったことないので行ってみたい。でも人見知りでちょっと怖いので頑張って勇気をだして。

資料はこちら。

ブログのススメ

ブログ書くと、いいことあるよね。というお話。もちろんあるし、僕もブログ書きました。
ブログ書いていなかったら、いまこんなところにいなかったと思う。やり方は人それぞれだけど、自分にあった続け方を見つけることが大切だと思う。

資料やエントリはこちら。

まとめ

初めて参加したRuby会議、いろいろあったけどすごく楽しかった。でも知らない人とはあまり話せなかったので、これからはもうちょっと積極的になりたい。と思って早5年って感じだけど。ちょっとずつ。
二日目は豪雪のため14時に終了となったけど、そう判断してくださったスタッフの方々に感謝。ちゃんと帰れました。


Rubyをまともに書き始めて約半年。これからもっと積極的に関わっていきたい。

リーダブルコード

book

「リーダブルコード」を読了した。いい本だった。こんなにいい本はひさしぶりかも。薄くて、訳がわかりやすく、さらっと読める。でも大切なことがぎゅーっと詰まってる。
リーダブルコードはリーダブルブックだった。


よいコードを書きましょうって書いてある本はたくさんあるし、何冊かは読んだ。なにが違うのか考えてみた。

  • 原理、原則だけを書いているわけではない
  • 理想論的ではなく、現実的な内容が書いてある
  • 実践的なプラクティスが書いてある

たぶんこんな感じ。もうちょっと詳しく書く。

原理、原則だけを書いているわけではない

たとえば、コーディングルールを徹底するというのは、原理主義的なアプローチだと思う。コーディングルールを徹底するのは効果的で必要なことだけど、それだけではリーダブルコードにならない。
「3.7 ユーザの期待に合わせる」ではこんな例があった。
プログラマは get で始まるメソッドは、値を返すだけの軽量アクセサであるという規約になれている。そのため、コストの高い処理が get で始まると、コストの高さに気付かずに使ってしまうかもしれない。
サンプルのコードはこんな感じで

public double getMean(){
  // すべてのサンプルをイテレートして、total/num_samples を返す。
}

それなら computeMean() などの名前に変えるべきだ、とある。
なるほど。

理想論的ではなく、現実的な内容が書いてある

読みやすいコードを書くためには、コーディングルールではカバーできない、もっと別のアプローチが必要になる。その別のアプローチが本書には載っている。
「7.3 三項演算子」ではこんな例がある。
三項演算子がわかりやすい例としてこのコード。

time_str += (hour >= 12) ? "pm" : "am"

これはシンプル。で、わかりにくいコードはこれ。

return exponent >=0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

if文を使うと、コードが自然になる。

if(exponent >=0){
  return mentissa * (1 << exponent);
}else{
  return mantissa / (1 << -exponent);
}

これならわかる。

実践的なプラクティスが書いてある

具体的で短いコードが提示されていて、改善するための考え方や、改善されたコードが記載されているのでわかりやすい。
この「具体的で短いコード」が、ほんとうに具体的で短いのでわかりやすい。こういうこと、これまでやっちゃったことあるなーと思うようなものが載っている。だから理解しやすい。

「2.2 tmpやretvalなどの汎用的な名前を避ける」では、こんな感じの2乗した値の合計値を返却するなら、retval ではなく sum_squares にしましょうって書いてある。

retval += v[i] * v[i]

例えば、sum_squares がこんな感じになってたら、名前からバグっぽいとわかる。

sum_squares += v[i]

確かに。



いくつかのプラクティスは、これまで無意識にやっているものだった。
このあたりのコードはごちゃごちゃしてるなー、なんかバグだしちゃいそうだなー、あとで読みにくそうだなーっていう、臭うコードはなんとなくわかる。それで、変数名を変えたり、メソッドを抽出したり、処理を分割したりする。
そのひとつひとつが、名前の付いたプラクティスとして紹介されている。これなら意識的に取り組んでいける。


いまは毎日コードを書いているので、読んでいていろいろ想像できた。人が読むことを考えると、丁寧に書くよね。仕事で書くコードは全部コードレビューされるし、読みやすいコード書きたい。
本書の解説にこんな一文があった。

「忘れても見たら簡単にわかるように書いておくんですよ。」

「情けは人のためならず」と一緒で、人のためではなく自分のためにリーダブルコードを書きたい。


リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
posted with amazlet at 13.01.12
Dustin Boswell Trevor Foucher
オライリージャパン
売り上げランキング: 1,331
Amazon.co.jp で詳細を見る



関係ないけど、ここで書いている文章はリーダブルじゃないことが多いと思う。それでいいと思っていて。もっと一文を短くしたり、主語を明確にすることで読みやすくなるだろうけど、あえてしていないこともある。
でも外部媒体で記事を書くときは、わかりやすくて伝わる、そして楽しい文章を心掛けている。

阪急電車

Book

有川浩の「阪急電車」を読了した。大阪に行く時に、合わせて読んだ。
読みやすい文体だけど薄っぺらいわけじゃなく、しっかりした物語があって読み始めると、すっと引き込まれてしまった。いい作品だった。バランスがいい。

阪急電車というタイトルの通り、阪急今津線の駅が舞台になっている。全部で8駅で、路線距離は9.3kmみたい。

ちなみに江ノ電の駅は15駅で、路線距離は10.0kmみたい。だいたい同じ長さだった。


小説は、電車の行きと帰り合わせて16駅分、16編の短編から成り立っている。それぞれの短編の登場人物が、他の短編にも出てくるので、1つの長編のようにも楽しめる。
こういう複雑なプロットをさらっと読ませるのはすごいな、と思った。
「宝塚駅」の図書館で出会う2人の話と、「宝塚南口駅」の彼氏を取られてその2人の結婚式に白いドレスを着飾っていく女性の話がよかった。いろいろと考えてしまうことはあったけど。
次、関西に行ったら、阪急今津線に乗ってみたい。


阪急電車
阪急電車
posted with amazlet at 13.01.06
有川 浩
幻冬舎
売り上げランキング: 158,483
Amazon.co.jp で詳細を見る