delirious thoughts

by Kentaro Kuribayashi

花金かつ給料日はスーパー花金

花金と給料日が重なるとめでたい。世にいうところの「スーパー花金」である。これをプログラムによって求めよというお題が提案された。

というわけで、酒のつまみに適当に書いてみた。

ルール

  • 花金はFizz
  • 給料日はBuzz
  • 花金かつ給料日は「スーパー花金」なのでFizzBuzz

実行例

弊社の場合、給料日は10日なので、2014年1月には以下のようになる。

$ go run hanakin.go -payday 10 -month 1 -year 2014
2014 January
====================
1
2
Fizz
4
5
6
7
8
9
FizzBuzz
11
12
13
14
15
16
Fizz
18
19
20
21
22
23
Fizz
25
26
27
28
29
30
Fizz

発展

  1. 給料日が休日の場合、その直前の平日が給与支給日になる会社が多いだろう(弊社もそう)。たとえば、10日が給料日だが、10日が日曜日の場合は8日が給料日、という場合。hanakinスクリプトをその場合にも対応せよ。
  2. また、フォーマットをcalコマンドに合わせよ。

2014年8月に読んだ本をブクログでふりかえる

今月は14冊。他、それなりのボリュームのある言語解説資料として、以下3つを読んだ。

また、今月は2回、技術イベントで発表したので、その資料としてあれこれ読んだけど、そのへんは割愛。

毎年新しく何か言語を学ぼうという感じなので、今年はSwiftとTypeScriptやるかーという感じになったので、上記と、『TypeScriptリファレンス』を読んだ。同時期に読んだせいでだいぶ頭がこんがらがってきたけど、それぞれに良さといまいちさがある感じがして、面白い。

経営学関連では、『ブラックスワン経営学』が、ビジネス書っぽい感じでありつつケーススタディについてちゃんと方法論から紹介している本で、とてもよかった。その流れで『リサーチ・デザイン』も読んだり。その辺は、普通に業務を行っていく上でも役立ちそう。

また、なんかにわかにアドラー心理学が盛り上がっているので、岸見先生の本を読み返したり、ブームの火付け役っぽいのを読んだりした。アドラー、とてもいいと思う。

その他、『ストレッチ』を読んで毎日なにかしらストレッチしているのだけど、そのおかげで体調がいい感じなので、読んでよかった。漫画自体もすごくいい。まあ、元々好きな作家だし(略)。

kentaroの本棚 - 2014年08月 (14作品)
嫌われる勇気
岸見一郎
読了日:08月31日
評価3

powered by booklog

YAPC::Asia 2014で「いろんな言語を適材適所で使おう」という話をした #yapcasia

YAPC::Asia Tokyo 2014で、いろんな言語を適材適所で使おう - YAPC::Asia Tokyo 2014という話をしてきました。

これまでのソフトウェアエンジニアとしての経験から、継続的に価値を提供し続けるための技術選択はどのようにあり得るのかということをずっと考えていて、「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdaysや、GMOペパボのエンジニア新人研修 #lldiverという発表でもそのあたりの問題意識に基いて話したりしてきました。今回の話は、では、それらの延長線上での、将来における技術選択の最適化について考えてみました。

もうちょっとちゃんと定量化できる感じにしたいけど、まだまだ難しそうだなあという感じ。もうちょっと深堀りして考えていきたいと思います。

GMOペパボのエンジニア新人研修 #lldiver

LL Diver | Dive into Lightweight Languagesで、「GMOペパボのエンジニア新人研修」というタイトルで話をしてきました。エンジニア新人研修については、その実施自体には、僕は既にあんまり関わっておらず、主にid:hibomaや新卒出身の若者たちが担っているのですが、その背景となっている考え方について一度まとめる必要があるなと思っていたので、この機会にまとめてみました。

いろいろ書いていますが、エンジニアがより楽しく働けるようにし、そのことでより高い成果を出すためにあれこれとやっているところです。ご興味を抱かれた方は、是非、以下をご覧いただきたく思います。

RESTが日本で受け入れられていった頃の話( #mozaicfm の補足)

mozaic.fm第7話のRESTの話で、RESTが日本で広く受け入れられていった頃、というか、その端緒の頃の話が出ていて懐かしかったのだし、細部にやや不正確なところがあるのが気になったりもしたので、補足を書いておきますね。

まず、いわずとしれた@yoheiさんがRESTをまず知ったのが2003年とかそれぐらいの時期とおっしゃっていて、それから数年経ち、RESTがWebエンジニアに広く受け入れられていったのは、2007年末にリリースされ、resourcesという機能を取り入れたRails2からというのは、@t_wadaさんがおっしゃっている通り、事実だろうと思います。

また、Podcastの中では、主催のJxckさんが、それはそれと認めた上で、彼自身にとってはAjaxの登場が大きかったということを述べた上で、@yoheiさんの主催された第八回XML開発者の日での高橋征義さんとid:secondlifeの話が語られるわけですが、日本での受入の端緒の情景としては、Jxckさんの回想に同感を覚えます。

ただ、若干時間の感覚にズレがあって、Podcastの中でAjaxの文書が2006年だと述べられていたけれども、それは2005年の2月で、さらには前述の「第八回XML開発者の日」はその年の11月にあって、わりと早い時期から日本のWeb開発者はRESTを受け入れていったわけです。

なんで僕がそんな細かいことをいちいち憶えているかというと、

といったことがあったからなわけです。その頃の様子は、たとえばこのブログの以下のエントリに記されている。

その流れから発して、以下の様な文書を書いたりした。

その頃のアツかったWeb界隈の動きがtumblr 創世記 その四 (ヤバイ、JavaScriptマジヤバイ の巻) - tumblr - たんぶら部 - Tumblove -にまとめられていて、懐かしい思いを感じる。

日本でのRESTの受け入れには、JavaScript界隈の動きが大きく関わっていた。なぜなら、Ajaxが現れたことで、フロントエンドとバックエンドとの区別が意識されることになり、そのことでRESTというアーキテクチャスタイルの存在が浮かび上がってきたからだ。少なくとも、僕の見ていたところでは、そういう流れであったように思える。

というわけで、別になにかのオリジンを主張したいわけではなくて、そういうことがあったなあという、Webおじさんの昔話でした。

`gate`をGitHub対応した

Google認証なリバースプロクシ&静的コンテンツ配信サーバー「gate」 - unknownplace.orgで紹介されている、typesterさんのgateという、GoogleのOAuth2認証付きプロキシサーバがとても便利そうだったので、即座に使いたくなった。

これは、昨今増えつつあるメトリクス系のツールだとかの、インターネット上に置きつつも、社内のみに提供したいサービスを立てるに際して、フロントにnginxをおいた場合に、認証のことを考えるのがだるい、というか、nginxの設定自体がだるいみたいなときに役立つツールです。その際、自分とこ的にはGitHubのorganizationでアカウント管理できるとさらによいので、GitHub対応をしてpull requestを送ったところmergeされました。ありがとうございます。

会社で運用しているorganizationがfoo_organizationbar_organizationとあって、それらのメンバーだけにアクセスを許可したい場合、設定ファイルに以下のように書くといいかんじになります。

auth:
  info:
    service: github
    client_id: your client id
    client_secret: your client secret
    redirect_url: https://yourapp.example.com/oauth2callback

# restrict user request. (optional)
restrictions:
  - foo_organization
  - bar_organization

早速、社内ツールのサーブに使ってみたいと思います。

RailsでTypeScriptを使う

JavaScriptは設計が難しい。経験上、すぐグシャグシャになってしまう。よくわからなくなる。もちろん、私のスキル不足というのはあるだろうけれども、スキルが不足してるのはしかたないので、学習は続けることは前提であるにしても、技術的に解決できるなら技術に頼りたい。そうした意味で、いわゆるAltJSの中ではTypeScriptが有望だろうと思う。

RailsとTypeScript

TypeScriptを使うにしても、それ単体で使うというシーンは、Webアプリケーション開発という文脈ではあまりない。たとえば、Railsで開発しているWebアプリケーションのフロントエンドを構成する言語として使うことになるだろう。その際、まず考えるべきことは、Asset Pipelineとどう折り合いをつけるかということだろう。

Asset Pipelineは、以下の機能を担っている:

  • 拡張子(例:application.js.coffee)により、各種言語のフロントエンドを判別し、最終的なプロダクトとしてのJavaScriptCSSを書き出す
  • 多数からなるそれらのファイルを、任意の数にまとめる
  • 一意のsignitureをファイル名に付与することで、ブラウザキャッシュとの折り合いをうまいことする

技術要素のライフサイクル

Railsから、フロントエンドを成す言語(coffee scriptやSassなど)を使う場合、一般には、それらに対応したRailsプラグイン的なものを使うことになる。それはそれでよいのではあるけれども、それらの処理系、あるいは、それがライブラリをも含む場合(jQueryとかBackboneとか)においては、Railsのライフサイクルとそれらのライフサイクルが異なりうる。すなわち、JavaScriptのライブラリやその派生言語であれば、それらのライフサイクルに基いて管理する方が適切であるという判断があり得る。

TypeScriptの場合、typescript-railsというプロダクトにより、Asset Pipelineの仕組み上でいい感じにしてくれるものがあるのだが、上記した通り、そもそもRailsとライフサイクルの異なるものを扱うのであれば、わざわざRailsに合わせる必要もないというのもひとつの考えだ。その場合、Railsの外で、自前でビルドする仕組みを用意することで、Asset Pipelineに頼らない環境を作るという選択肢もあるだろう。

Gulp + Rails

そのような環境を構築するに際して、それはそれでいろいろな選択肢が考えられるが、ここではgulp.jsを使ってみたいと思う。これは、単に私がそもそもフロントエンドまわりの技術に明るくないため、流行っていそうなものがよさそうだと思ってしまう偏向の現れである。

gulp.jsは、makeやrakeやその他もろもろそういった、処理の自動化を担当するツールである。まあ、rakeでもなんでもいいんだろうけど、今回使用するのはTypeScriptであるし、また、フロントエンド周りの各種言語、ツールへの対応が充実しているようなので、gulpを使うことにした。

全体としてはkentaro/gulp-for-railsに書いた通り。

gulpによるTypeScriptのビルド

TypeScriptは、JavaScriptコンパイルすることによって最終的な実行ファイルを生成するタイプの言語なので、Web開発においては、できるだけ楽な方法を採ることにより、開発スピードをさまたげないようにしたい。そこで、以下のようなgulpfile.jsを用意した。やっていることは単純で、app/assets/typescript以下にあるTypeScriptで書かれたファイルを監視して、JavaScriptコンパイルするというだけのものである。

var gulp = require('gulp');
var plumber = require('gulp-plumber');
var typescript = require('gulp-tsc');

gulp.task('typescript', function(){
  gulp.src(['app/assets/typescripts/*.ts'])
    .pipe(plumber())
    .pipe(typescript())
    .pipe(gulp.dest('public/javascripts/'))
});

gulp.task('watch', ['typescript'], function() {
  gulp.watch('app/assets/typescripts/*.ts', ['typescript'])
});

ちなみに、gulp-plumberを使っているのは、TypeScriptのコンパイルエラー時にgulpプロセスが落ちないようにするためのものである。詳細は、このGistの通り。

しかし、これをいちいち手動で起動するのは面倒なので、config/initializers/gulp_wathcer.rbに以下のような記述を行うことで、rails s時に自動的にgulp watchするようにした:

if Rails.env.development?
  pid = fork { exec 'gulp watch' }
  Process.detach(pid)
end

Asset Pipeline置き換えに向けて

上述のAsset Pipelineの機能のうち、上記だけだとTypeScriptをコンパイルし適当な場所に配置しただけであり、その機能の置き換えにはなっていない。とりあえず、RailsとTypeScirptを使ってみたかったぐらいの感じで試したので、上記はそこまでに留まっているが、それ以上に事を進めるためには、たとえば以下のエントリが参考になると思う。

まとめ

  • Railsと、JavaScriptあるいはそのライブラリとはライフサイクルが違うので、別に管理するという選択肢があり得る
  • TypeScriptとってもいいので、Railsや他のフレームワーク/言語に基づくプロダクトでも使いたい
  • いろんなツールを使えば、Asset Pipelineを置き換えることもできそうなので、がんばろう

しかし、Asset Pipelineを置き換えようと思うと自前でやることが多すぎるので、もっといい感じの仕組みがあるとよいなあとは思う。というか、Railsにもフロントエンド周りの現状にも明るくないので、こうやるのがベストプラクティス!みたいなのを知りたいところ。