2012-06-05

asakusa.rb 第161回

@hsbtさんを見習ってWeb日記を付けてみる。

今週のasakusa.rbは3週連続でヒカリエ開催でした。

git監視業
- git blame捗りますよねという話
  - git警備員ですね
- gitを使った大規模開発大変そう
  - 大変なんですよ、リモートブランチとか増えちゃって
    - マージ済みのブランチとそのブランチの最後のコミットauthor取れるようにしたので個別に肩たたきします
      - なにそれこわい
@sora_hが来てた
@punytanがフラっと立ち寄ってくれた
松田さんのEuroko2012報告
- 会場がすごかった
  - すごい綺麗な映画館で開催
- スピリチュアルな話少なくて楽しそうだった
- euruko votingっていう次回開催地を決めるのが面白かった
  - 会期中ロビー活動してる
  - あまり気合入れてロビー活動してなかったアテネが2013の開催地
    - アテネあるんですかねー
Ruby会議:rebootedの裏話
- コロッケ

ヒカリエ開催も3回目にしていつものMeetUpっぽくなってきた感じ。
自分はドアマン業をやりつつC拡張でgem作るには、みたいなことをやっていた。
久しぶりにC言語書いてmake通ってやったーみたいなところで終わり。

来週の開催場所はどこですかねー

2012-02-23

git log のフォーマット指定で区切り文字を指定する

git logには--prettyオプションが存在していて、フォーマットをカスタマイズできるようになっている。

カスタマイズするには

git log --pretty=format:""

として"の中にフォーマットを記述すればよい。
具体的は"%H %an %ad"とすると"コミットハッシュ Author Authorコミット日付"などと指定できる。

$ git log --pretty=format:"%H %an %ad"
5b9f417cca453f1d8df6baea95eb7a718da4e5c5 Ryoichi SEKIGUCHI Tue Jan 31 14:36:48 2012 +0900
ae4d7c4392e16ce41bff5141f2266fac901e63eb Ryoichi SEKIGUCHI Tue Jan 31 14:35:15 2012 +0900
bc0a8bb66446072f9e13d1d035012941cef1067f Ryoichi SEKIGUCHI Tue Jan 31 14:29:38 2012 +0900
b6fbf1dd0690345e867e381a2a02dc0238a6ce33 Ryoichi SEKIGUCHI Tue Jan 31 14:27:33 2012 +0900

他にも指定可能な要素があるのでそれはman git-logを参照。

出力に区切り文字を使いたい場合は区切り文字を指定するオプションがないので、任意の文字をprintする要素を利用する。
manには "%x00: print a byte from a hex code" と書かれているもの。

例えばタブ区切りにしたい場合には"%x09"を指定すればよい。

$ git log --pretty=format:"%H%x09%an%x09%ad"
5b9f417cca453f1d8df6baea95eb7a718da4e5c5        Ryoichi SEKIGUCHI       Tue Jan 31 14:36:48 2012 +0900
ae4d7c4392e16ce41bff5141f2266fac901e63eb        Ryoichi SEKIGUCHI       Tue Jan 31 14:35:15 2012 +0900
bc0a8bb66446072f9e13d1d035012941cef1067f        Ryoichi SEKIGUCHI       Tue Jan 31 14:29:38 2012 +0900

2011-12-18

高専カンファレンスに来ないような人達に思う

この記事はKosen Advent Calendar2011の記事です。
前日はmasushinさんのロビー部と高専でした。

自己紹介

@ryopeko
014tokyoのアンカンファレンスやLTで遊んだりしてました。

はじめに

昨日までの記事をひと通り読んでみると、予想以上に高専カンファレンス寄りだなーと思いつつもそれだけ参加者が高専カンファレンスから色々なものを持って帰って自分の中で大事にしていて素敵だなと電車の中で一人で感極まったりしてました。

で、自分は何を書こうかと思ったときに高専カンファレンスのことや高専の良さについて書くというのが初めに思い浮かびました。
ただこのAdvent Calendarを読んでいるというかここに辿り着くような人はそんな事にはとうに気が付いていると思うんですよね。
だったら何を書くか。

それならここを読まないような人に向けて書こうかなと。
読まないような人に向けて書いても読んでもらえないなら何で書くのかというと、ある種の決意表明に近いのですかね。

今回の内容を一言で書くと、
「全ての高専をうまく活用出来なかった人を消し去りたい、全ての宇宙、過去、未来全ての高専を黒歴史としてしまった人を」

高専カンファレンスで学生や卒業生や先生方が生き生きとしている一方で、そうでない人の方がたくさん存在しているという現実に目を向けたい。
(何も高専カンファレンスに参加していない人がダメという話ではない)

というのも自分自身、学生時代はどちらかというと高専不適合者の一人だったからだ。
(あわせて読みたい:高専カンファレンスのLTで発表しました)

実感した出来事

先日当時の同級生と久しぶりに飲んだ時のお話。

その時集まったのは卒研時代の同じ研究室の友人で、更に同業者。
ITエンジニアというくくりで同業者。
色々話をしていく中で高専カンファレンスについて話題を振ってみたところ、その友人達は存在すら知らなかった。
更には興味すら示してくれなかった。
これは高専カンファレンスだけでなく、勉強会に行っていると話すと勉強会ブーム全盛であることも知らなかった。

これはとてもショックだった。

仕事外で勉強してるなんて偉いねーなんて言われた。
当人にはそんな意識は全くないのだが、これは勉強会っていうワードが良くない。
(実際はサークル活動に近い)

仕事の事に話が及ぶと、各々コードはもう書きたくないから管理側に回っているのだそう。

エンジニアとして生き生きとしてるか？と言われると自分はそうは思わなかった。

彼らにとって高専で学んだことってどう捉えているのかな？
聞けばよかった。

振り返って考えてみた

ただエンジニアとして活躍しているのはまだ高専で学んだ価値はあると思っていて、そうでない人もたくさんいる。
でもそれが良くないというのではなくて、肝心なのは自分をどう捉えているかということ。

当時の同級生でエンジニアの道を選ばなかった人もたくさんいる。
自分に合わないからそういう道を選んだ人もいればそうでない人も。
(実際エンジニアの道を選ばずに一級建築士を取った友人がいる。超すごい。)

つまり何が言いたいかというと、卒業するまでの間に自分をどう捉えて将来何をしたいのかということを考えられないのが問題だと思っている。

きっと高専生活の5年間の間にいくつか考えるポイントがあるのだけど、そこでの身の振り方で全てが決まってしまう。
自分が見ていた世界ではほとんどの人がここできちんと身を振れていない。
なぜならそのような選択肢(非エンジニアの道)から目を背けるようになっているから。

自分が高専に入ってからは、
やれ高専卒のエンジニアは優秀だとか
やれ就職率は100%だとか
年に4回ある定期試験では一週間で15科目とか今考えると想像を絶するスケジュールだったり
更にはその合間を縫って週4通のレポート提出とか
まあとにかく自分や自分の環境以外に目を向ける機会が少ない。

学生のころ下から数えたほうが早いぐらいだった自分にとってはエンジニアとしてやっていけてる人なんて一握りの優秀な人だけだろと思っていた。

だから別にエンジニアの道からドロップアウトすることが悪いなんて全然思わない。
悪いのはその事実から目を背けることだ。

なんで目を背けられているかというと、将来のエンジニアとしての自分と社会のエンジニア像にギャップがありすぎるからだ。
(なあなあでエンジニアを目指して勉強するしかない)

この状態を実際の生きたエンジニアをもっと学生の前に晒すことで解決したい。
それぐらい学生側からすると社会っていうのはリアリティが無い。

そのひとつのアプローチが高専カンファレンスだと思うし、それによって一定の効果を挙げているのも事実。
このAdvent Calendarで学生が書いているのが良い証拠。

だから学生の目の前にもっと生のエンジニアを送り込みませんか？

@june29が釧路高専でやっていることがロールモデル。

たくさんリアリティを突きつけることで他の道を選ぶ学生が出てくることを目標にしたい。
きっと気付きは早ければ早いほど良い。
その結果生き生きと技術について語る卒業生が出てきたらもっといい。

ということでせっかくなので高専カンファレンスの財産をもっと現役学生に使ってみませんか？
特にOBとしては島田先生や鈴木先生方面となく。

まとめ

在学中に自分を見つめ直す材料がたりませんよ。
他の道を選ぶのはとてもいいことだけどなかなか判断できないし許容されていないよね。
在学中に言われるエンジニアって何さ。
いい標本が高専カンファレンスにたくさんいるよ。
その標本を現役学生の前に晒してエンジニアという職業にリアリティを持たせて、学生の将来に向けての判断材料にしてみませんか？
現役学生に向けてもっと高専カンファレンスの財産を還元しましょう。

続きは新春高専カンファレンスで。

2011-12-10

Rails3レシピブックを"読んだ"

Rails3レシピブックを読んでみて、最初はRailsレシピブックとの比較として読み始めていたけど、
まずその前提が違っていた。

似たような名前、表紙で改訂版みたいな扱いかとタカをくくっていたらいい意味で痛い目にあった。

Railsレシピブックはとてもいい本で、Railsを使い始めたばかりのころは常に手元に置いて表紙が擦り切れるぐらい利用していた。

Rails3レシピブックになってもこのいい所は変わらなくて、Rails3時代に手元に置いておきたい一冊になっている。

でもRails3レシピブックのすごいところはレシピブックという皮をかぶった別の何かだというところ。
Rails3は個人的に色々作ったりしてよく活用しているが、それでも頭から読み始めて全て読み通してしまうぐらいのものだった。

つまりRails3レシピブックはレシピブックを謳った読み物だった。

この本に込められたメッセージはRailsを取り巻くエコシステムに読者を巻き込もうとする意思だ。
それは巻末に収められている"Railsを直す"という項の存在からも明らかだと思う。

加えてレシピブックというとやりたいことがあるけど、それをどうやって実現すればいいかを調べる逆引き的な用途があるが、
Rails3レシピブックにはそれ以上のものが収められている。
つまり、こういうことをするにはこういうやり方があるんだけどね、それはRailsの思想としてほげほげだからなんだよ。
といったきちんとRailに乗せる役目もこの書籍は担っているからだ。

RailsにおいてはこのRailに乗せるというのが重要で、
更にはRailsの本質はそれを取り巻くエコシステムなのだから、そこにしっかり乗せてあげることが次のステップを見越して、より読者の利便性を高めることになっているのだと感じた。

それは"Rails用ライブラリを探す"の項を用意することでエコシステムに巻き込んでいく足がかりを示していることにも繋がってくる。

こうまでRailsレシピブックから方向性がひとつ加わったのは著者に松田さんが加わったことがとても大きいんだろうな。

ということRailsを使っている人は読み物として読んでみるといいと思います。

Rails3レシピブック 190の技

作者: 高橋征義,松田明,諸橋恭介
出版社/メーカー: ソフトバンククリエイティブ
発売日: 2011/07/25
メディア: 単行本
購入: 34人クリック: 952回
この商品を含むブログ (37件) を見る

2011-06-26

Ruby会議2011のLTで発表します

Ruby

タイトルの通りRuby会議2011のLTで発表することが決まりました。
それに合わせてブログのサイドバーにRuby会議2011 SPEAKERバッジを付けました。
(LTスピーカーでも貼っていいんだよね...?)
<追記:LT Talker用のバッジが作られたので貼り替えました>

まさか自分がこのバッジを貼る日が来るとは。
いつか貼れるようになりたいと思ってはいたけど。

自分にとってはRuby会議で発表することはひとつのマイルストーンだったので感慨ひとしおです。

本編で発表することはあまり頭になかったので、発表するならLTだろうなと思っていました。
というか本編はRubyコミッターかRubyistに大きな道しるべとして物事を啓蒙する人が立つステージだと考えています。
なのでそんなネタを自分で作り出せるようになって、かつ採択されるような機会があれば是非本編でも話してみたいなと企んでいます。

ここから先はRuby会議が終わってから書こうかと思っていたことだが、きっと最後のRuby会議が終わった後にはもっと書くべきことがあるはずなので、今書くべきだと感じたので書く。

Ruby会議は自分にとってこの業界のコミュニティに入っていくきっかけとなった"門"です。

初参加はRuby会議2009。
このときはRubyを使い始めて間もないころで、Rubyコミュニティの特色はおろかコミュニティ自体何も知らない状態でした。
最初はなんとなく身を委ねて各セッションを聞いていましたが、角谷さんのセッションを聞いたあとに何週間かかけてジワジワ昂ぶってくものを感じたのが大きな収穫でした。
そこで感じたことは具体的な事柄ではなく、自分という一エンジニアがどうありたいか、どうなりたいかということを考えるきっかけだったのだと思います。
そこからどう周りをドライブしていくかということにシフトしていって、周りを巻き込みつつ好き勝手成長していきました。

その後はデブサミに参加して更に当てられて様々な勉強会に参加してRuby会議2010に至ります。

このRuby会議2010がとても大事なものになっていきます。
2010では会期中フルで参加し、コミュニティナイトや懇親会、RejectRubyKaigiなどで様々なRubyistと知り合うことができました。

その1ヶ月後の高専カンファレンスではLTで発表しました。
そこではRubyつながりで@hmsk , @june29 と知り合うことができました。

ここからRails勉強会東京等でもどんどんRubyistの知り合いが増えて沢山刺激を受け、自分の世界が広がりました。

Rails勉強会東京ではささいなきっかけからrubykaigi.orgのソースを読む、というセッションを持ったりしてrubykaigi.orgに接するきっかけを持ちました。

それが今年に入って、前職を退職し現職になってからはRubyから大きく離れた世界に身を置くことになりました。
Rubyから離れることはとても辛いことでしたが、プライベートでRubyを書くことは続けていこうと思っていました。

そんな時にほんのささいなtweetからrubykaigi.orgに誘っていただき、今回のLTに繋がります。
最後のRuby会議に少しでも貢献したい、と思っていた矢先だったのでとてもとても嬉しかったです。

rubykaigi.orgでは小さなコミットや刺身タンポポ業をしたりして、大きく貢献はできていませんがLTでrubykaigi.orgについて話すことも仕事のひとつだと思い、話すことにしました。

今回のLTでは個人としてではなく、rubykaigi.orgに携わるたくさんの人たちに代わって話すという気持ちで望みたいと思っています。

この3年間の区切りとして、5分間のLTを噛み締めて大事にお話します。

2011-04-30

ガローア会議に参加してきました

昨日は#galore(ガローア会議）のハッカソンに参加してきました。
参加者は@june29と@hmsk。

当日は会場と札幌をskypeで結んで#sappathon0430との同時開催でした。

両会場とも@june29, @darashiをはじめ、活発な発言で距離を感じずところどころで成果の中間報告を行う等して、とても楽しいハッカソンでした。

自分はというと色々ネタ出しした結果、CoffeeScriptからnode.jsに移行し、サンプルアプリを作りました。

CoffeeScriptに関しては正直現状手に余るという印象でした。
チームでCoffeeScriptを用いて開発するとなると導入コスト以上のものが見えないと感じました。
JavaScript Replacementとして挙げられますが、jQuery以上のメリットというよりは完全な新しい言語を取得するという意味合いのほうが強い気がします。

一方でJadeを用いてHTMLを記述したのですが、こちらはとてもしっくりきました。
むしろ素のHTMLを書くより自然な感じがしたぐらいです。

Rubyに関しても言えることですが、<>や;は思考をコードにアウトプットすることの妨げになるんだなと強く思いました。

最終的な成果物としては目新しいものはできませんでしたが、node.jsとsocket.ioを用いてメッセージの送受信を行えるところまでもっていけました。
今更ですがnode.jsに触れ自分の中で新しい世界が開けたなという感触です。

ハッカソンが終わり撤収した後は東京会場のメンツで飲みに行きました。

そこで話したことは、今回のきっかけとして高専というものが大きく関わっていたよねということです。
今回集まったきっかけといえば僕が高専カンファレンスで僕が面識が無いにも関わらず@june29と@hmskをLTでいじったということです。

そのLTで話したことは、僕自身が高専時代は御世辞にも優秀な学生とは言えない学生だったけど、今こう考えて頑張っているよ、ということでした。

今回@june29と話しながらそれらを振り返って、自分だからこそ高専の学生をはじめ、これから世に出て行く学生達にできることがあるんじゃないか、ということを初めて言葉にして伝えました。

この時@june29は釧路高専をはじめ、故郷の北海道に対する思いを熱っぽく語っていました。
僕はこれにあてられた訳ではないけど、アプローチは違えど、目指すところは似ているなと感じとても幸せになりました。

と同時に北海道でえにしテックがとてもとても素晴らしい想いを持って立ち上がり、活動している中で同じ環の中で行動していることが羨ましくも想いました。

だからこそ自分にも、自分にしかできないことがあると感じていて行動していることをもっと加速しようと思ったわけです。

これらを踏まえて直近の目標としては、母校の高専で@june29がやった講演みたいなことができるように頑張っていこうと思います。

他にもWebサービスについてのモチベーション等たくさん話したのですが、Webサービスに対する考えとかについてはもう少し考えてからまとめます。
転職したばかり、というタイミングもありますし。

と、今日はとても有意義で楽しい時間をすごせました。
ありがとうございましました！

2010-12-15

Arelで色んなSQLを組み立ててみる

Ruby Rails

（この記事は Ruby Advent Calendar jp:2010の 15 日目です。前日は tomohiro68 さんでした。）

Arelとは

Arelの概要については@a_matsudaさんのgihyoの記事を参照してください。
http://gihyo.jp/dev/serial/01/ruby/0043

はじめに

扱うRDBはSQlite3です。
例として以下のようなスキーマを持ったテーブルを取り扱い、進めていきます。

class CreateBooks < ActiveRecord::Migration
  def self.up
    create_table :books do |t|
      t.string :name
      t.string :category

      t.timestamps
    end
  end

  def self.down
    drop_table :books
  end
end

基本的な操作

where句

books = Arel::Table.new :books

#=
books.project(Arel.sql('*')).where(books[:id].eq(1)).to_sql
   => SELECT * FROM "books" WHERE "books"."id" = 1

#like
books.project(Arel.sql('*')).where(books[:name].matches('book_name_2_%')).to_sql
   => SELECT * FROM "books" WHERE "books"."name" LIKE 'book_name_2_%'

#>,<,andで条件を追加
books.project(Arel.sql('*')).where(books[:id].gt(5)).where(books[:id].lt(10)).to_sql
   => SELECT * FROM "books" WHERE "books"."id" > 5 AND "books"."id" < 10

#orで条件を追加
books.project(Arel.sql('*')).where(books[:id].gt(5).or(books[:id].lt(10))).to_sql
   => SELECT * FROM "books" WHERE ("books"."id" > 5 OR "books"."id" < 10)

order by句

books = Arel::Table.new :books

#default
books.project(Arel.sql('*')).order(books[:id]).to_sql
   => SELECT * FROM "books" ORDER BY "books"."id"

#昇順
books.project(Arel.sql('*')).order(books[:id].asc).to_sql
   => SELECT * FROM "books" ORDER BY "books"."id" ASC

#降順
books.project(Arel.sql('*')).order(books[:id].desc).to_sql
   => SELECT * FROM "books" ORDER BY "books"."id" DESC

集計関数とgroup by

books = Arel::Table.new :books

#count
books.project(books[:id].count, books[:category]).group(books[:category]).to_sql
   => SELECT COUNT("books"."id"), "books"."category" FROM "books" GROUP BY "books"."category"

#集計カラムに別名をつける
books.project(books[:id].count.as('count_id'), books[:category]).group(books[:category]).to_sql
   => SELECT COUNT("books"."id") AS count_id, "books"."category" FROM "books" GROUP BY "books"."category"

#sum
books.project(books[:id].sum.as('sum_id'), books[:category]).group(books[:category]).to_sql
   => SELECT SUM("books"."id") AS sum_id, "books"."category" FROM "books" GROUP BY "books"."category"

おまけ

SQLで既存のテーブルから値を参照する方法がありますが、
一時テーブル(?)を作ってそこから参照することもできます。

select
  1 as num
=>
num 
----
1

unionでつなげると

select
  *
from (
  select
    1 as num
  union
  select
    2 as num
) as tmp
=>
num 
----
1   
2

これをArelで書くと以下の様になります(使い方違っているような気もしますが...

table = Arel::Table.new nil
table.from('(select 1 as num union select 2 as num) as tmp').project(Arel.sql('*')).to_sql
   => SELECT * FROM (select 1 as num union select 2 as num) as tmp

無理矢理ですね。

おまけをjoin句でinner joinしてみる！

さらにおまけで紹介したものを未紹介だったjoin句でつないでみます。

table = Arel::Table.new nil
books = Arel::Table.new :books
table = table.from('(select 1 as num union select 2 as num) as tmp').project(Arel.sql('*'))
table.join(books).on(books[:id].eq(Arel.sql('tmp.num'))).to_sql
   => SELECT * FROM (select 1 as num union select 2 as num) as tmp INNER JOIN "books" ON "books"."id" = tmp.num

もはやfind_by_sqlを使え状態です。
しかも使う機会があるのかさえ微妙です。

わかってないこと

サブクエリや型変換を伴うようなSQLの組み上げについては調査中です。
型変換についてはfind_by_sqlを使わないと無理な気がしています。
サブクエリはSQLを一つにまとめる方法でなければできたのですが。

まとめ

このようにArelを使うことによって、より自然な形でSQLを組み立てることができるようになりました。
またArelになってからSQL厨の皆様にとっても使いやすくなったのではないかと思います。