| @技術/プログラミング

Homebrew で rbenv と ruby-build をインストールし、Ruby をインストールしている。Nokogiri をインストールしようとするとlibiconv が足りないとエラーがでる。Nokogiri のインストールマニュアルを見ると以下のようなことが書いてある。

homebrew 0.8 or later

brew install libxml2 libxslt
brew link libxml2 libxslt
gem install nokogiri

言われたとおりにシンボリックリンク張って、さらに libiconv にもシンボリックリンクはった。この状態だとちゃんと Nokogiri 入る。入るが、

$ brew doctor

| @技術/プログラミング

7644ee081ba12f35fff2ea939a122da8.png (541×174)

Lokka になくて不便だと感じていたのがスパムコメントの一括削除機能だった。スパムを取得するメソッド、またそれらをまとめて削除するメソッドはあったので、それを呼び出すインターフェースを作ってみた。最初はテストなしで pull request しようとしてたけど Lokka に怒濤のようにテストコードを書いて push している tomykaira さんのブログ記事(lokka コミッタからのお願いをお読みください - tomykaira makes love with codes)を読んで心を入れ替え、本日の Lokkathon でテストコードを書いて pull request してみた。無事 merge して頂きました。

P_BLOG の改造とかして地道にコードを公開したりはしてたけど、やっとオープンソースにコミットできた感じがする。もっと頑張っていきたいです。

| @技術/プログラミング

Unicorn の設定をミスって(たと思ってけど実はそうじゃなかった)ポータルシットが12月の半ば頃から死んだままになってた。きっかけは Capistrano の導入で、仕事で Capistrano 使っていて大変便利なので、これをポータルシットでも使おうとした。

Unicorn で便利なのが、 kill -USR2 `cat tmp/pids/unicorn.pid` とかやることで、ダウンタイム無しに Rails アプリケーションを再起動できるとこだ。これを Sinatra 製の Lokka でも実現したかった。Capistrano と併せて運用することで、サーバーに SSH で接続せずとも

$ bundle exec cap deploy:restart

とかで Lokka を再起動できるようになる。

これまで Lokka の database.yml に DB への接続情報をべた書きしていたのをやめ、起動時にはシェルで以下のコマンドを実行するようにした。

$ env DATABASE_URL=path/to/db bundle exec unicorn -c config/unicorn.rb -D -E production

Capistrano の deploy.rb に書くと以下のようになる。

namespace :deploy do
  task :start do
    run "cd #{current_path}; env DATABASE_URL=#{db_path} bundle exec unicorn -c config/unicorn.rb -D -E production"
  end
end

| @技術/プログラミング

Railsで画面を作っていて、DBを参照せずにselect -> option なHTML(ドロップダウンリスト)を出力したいと思った。DBに入ってない値をドロップダウンリストとして表示する方法。ググったらこういうやり方がヒットした。

このやりが方がかっちょいいのかバッドノウハウなのか判別つかないけど、モデルに定数を書いてそこにいろいろ入れてしまうらしい。以下のような感じ。

class Event < ActiveRecord::Base
  DAYS = ['Monday', 'Tuesday', 'Wednesday', ...]
end

でこれをモデルから参照するときは以下のようにする。

<%= select(:event, :day, Event::DAYS) %>

これでうまいことドロップダウンリストを表示できる。

ところが一点問題があって、このドロップダウンリストで表示したい値が "(ダブルクオーテーション)を含んでいたとする。ダブルクオーテーションはRailsによって自動的にエスケープ処理されてしまうので、 " と表示させたいのに &quot; とか表示されてしまう。Form系のヘルパーメソッドで text_area_tag なら :escape => false とか出来るんだけど、select でそれをやるのは不可能だった。

Railsで文字列のエスケープをせずに出力する方法は一般的に

<%= raw("文字列") %>

とか

<%= "文字列".html_safe %>

だけど、「まさかそれをモデルの中でやっちゃってもエラー出るよね?」と思いながらやってみたらちゃんとエスケープせずにHTMLを出力できた。

モデルクラスのなかにヘルパーメソッドを書くのは気持ち悪いと思うけど、それ以外ではビューの中でイテレータを書いて一個一個エスケープしない処理を書くか、独自のヘルパーメソッドを書くしかない。なんかまどろっこしい気がするのでとりあえずこのやり方で行ってみることにします。

| @技術/プログラミング

Git flow を導入して仕事してる。master ブランチと develop ブランチをベースに、 feature ブランチ、hotfix ブランチ、release ブランチをつくって色々やるあれ。確かに便利何だけどだるいところもある。

hotfix ブランチのバージョン番号

たとえば誰か(A さんとしよう)がバグを見つけて hotfix を start したとする。hotfix 用のタグを 1.0.1 としよう。

$ git flow hotfix start 1.0.1

ここで別の誰か(B さんとしよう)が他のバグを見つけたとする。このとき B さんは A さんがローカル環境で 1.0.1 のタグを既に使っていることを知らない。ので当然 $ git flow hotfix start 1.0.1 してしまう。そんで B さんが

| @労働

荒れた砂浜

いまの会社は労働環境よいんだけど、前働いていた会社がとてもつらかった。どのくらいつらかったかというと、もう辞めてしばらく経つのに、いまだに前の会社にいたころの夢を見てうなされて夜中に目が覚めるくらいつらかった。ある意味トラウマになってしまっている。

つらかった頃のことをここに書いても意味がないことは分かっているし、ネガティブな感情をインターネット上に発露するのは個人的な信条に反するんだけど、セルフヒーリングのために前勤めていた会社のことを書いてみる。

無限サービス残業

  • 22時に帰るときも日報に「本日私用のためお先に失礼します」と書かなきゃいけない雰囲気だった。
  • 「23時に佐川が来るので申し訳ありませんがお先に失礼します」と日報に書いてる女の子とかいた。
  • 社長が「震災のおかげで仕事が減って早く帰れてうれしい、とか言ってるやつは許さない」とか言ってた。
  • みんなサービス残業してるので会社の飲み会に開始時間通りに現れる人はほとんどいなかった。
  • 週末だからと会社のメンバーで飲みに行くなんてことはなく、金曜の夜は2時くらいまで仕事するのが普通だった。

前の会社でまずつらかったのが労働時間の長さだった。もちろん残業代は出ない。完全に違法なんだけど、雇用主と労働者が対立する時代は終わったとか、不満があるなら辞めろとかいうような内容のメールを総務担当者が月に一回くらい送ってよこしていた。自分は弱いから会社に待遇を改善するよう申し出ることなんてできず、短期間働いて辞めることであの環境から脱した。

軍隊っぽさ

  • 上長にメールを送るときには宛名に「様」とつけなければならなかった。
  • 毎晩2時まで働いてたせいで心身を病んだ人が二人いたけど、二人とも「体調管理は自己責任」といって休職中に辞めさせられてた。ちなみに休職中に辞めさせるのは労働基準法違反らしい。
  • 細かく職位が分かれていて社内に軍隊のような階級制度があった。職位によって届くメールやグループウェア上で閲覧することのできるファイルが細かく分かれていた。たとえば上長の書いた日報は部下は読むことができなかった。

全体的に戦時中の日本みたいな会社だった(「欲しがりません 勝つまでは」的な感じ)。ライバルに勝つため・家族を守るために自分を犠牲にしろとか、そんな感じのことを経営陣が言ってた。

職位ごとに権限が異なっていて閲覧可能なファイルに違いがあるのはよその会社でも普通にやってると思うけど、それが露骨かつ過剰に行われている感じだった。Active Directory が Windows Server の外にもやってきて従業員をコントロールしている感じだった。

離職率の高さ

  • 入社してから二ヶ月以内に辞める人が多かった。いわゆるバックレも多かった。
  • 入社一年も経ってないのに入社時期で降順ソートしたとき真ん中くらいになってた。

自分の歓迎会開いてもらったときにすでに入社してから半年経ってた。すぐ辞める人が多いので新人の歓迎会とかはなかなか開いてもらえない。なんか先月入った人最近見かけないなー、と思ったらいつの間にか辞めてたということが日常茶飯事だった。

待遇の悪さ

  • 試用期間の二ヶ月間は各種保険に加入させてもらえなかった。
  • 内定の時に伝えられた年俸と全然違う給料だった。

全体的に、社長に気に入られないと昇級も出世も望めなかった。まぁどこの会社でも多かれ少なかれそうなのかもしれないけど、給与の等級表とかなかったし、どうすればどのくらいの給料をもらえるというような明確な指標がなかった。

労働基準監督署に届けてある就業規則はあるにはあったけど、偉い人の机の前にあって簡単に読める雰囲気じゃなかったし、そんなことしてる暇あったら仕事しろと注意される感じだった。ボーナスが支払われるのはいつか、基準額はいくらなのか、など労働契約に関する諸々のことを知らされない状態で働いていた。

技術力よりも人間力

  • 技術について熱っぽく語るとめんどくさいやつみたいな扱いを受けた。
  • 出世するにはエンジニアをやめてプロジェクトマネージャーにならないといけなかった。
  • テストコードとかなかった。テストは全部手動だった。
  • 勤務時間のうちコード書いてたのは25%くらい。あとは全部ドキュメント作成だった。

これらの開発カルチャーに加えて、会社が依拠する技術が Microsoft や Adobe などプロプライエタリなものが中心であり、UNIX/Linux 系の開発が好きな自分には大変つらかった。Capistrano とか使えば20秒くらいで終わりそうなことを手動・目視確認で行っていて、技術面のアナクロニズムに耐えられなかった。

インターネットのことを好きな人がいなかったのも辛かった。はてなとか誰も見てなかったし、 Twitter アカウントはみんな隠してた。そもそも Twitter よりも Facebook な感じだった。ソーシャルネットワークはプロモーションのツールとしてしか認知されていなかった。Twitter なんて技術的には大したことない、が社長の口癖だった。エンジニアも誰も GitHub とか使ってなかった。

不用意に転職したのが間違いだった

一番の間違いは、Web制作の会社に入ってしまったことだと思う。Twitter で見かける楽しそうに仕事してる人たちはだいたいみんなWeb系のベンチャー企業とかで働いてた。制作会社とWeb系ベンチャーでは全然雰囲気が違うと思う。制作会社にはクライアントがあり、その人たちの言うことは絶対だから、アホみたいなリクエストにも全力で答えなければならない。

Aという企業があってその会社のユーザーのためのサイトをWeb制作会社が作っているとする。すると要求の流れが以下のようになる。

A社製品のユーザー -> A社(顧客) -> 営業担当 -> プロジェクトマネージャー -> エンジニア・デザイナー

エンジニア・デザイナーはこのサイトの制作に携わるプレーヤーの中で最下層にある。顧客の要望を営業担当が聞いてきて、それをプロジェクトマネージャーが伝え聞き、エンジニアとデザイナーに指示を出す。このメカニズムのなかで軍隊的な階級構造ができる上がるのではないかと感じる。良くない仕組みだと思う。

近況

前の会社には一年近くいたけど、何か身についたかと問われると何も身についてない。自分の人生の中で最低最悪の暗黒時代だった。がんで入院していた頃の方がまだ良かったような感じさえする。

この記事のような愚痴というか後悔の塊みたいな文章をネットにのっけても何の得にもならないんだけど、職探しは本当に真剣にやった方がいいと身をもって思った。確かに結局のところ会社に入るまでその会社が自分に合っているのかどうかはわからない。しかしだからといって適当に就職活動して就職するとものすごく後悔することになる。時間がかかってもいいから就職・転職先はじっくり見極めてから決めた方がいいと思う。

実は前の会社に入って二ヶ月経たないくらいのときに、入った会社を間違ったと思って転職活動を行った。在福岡の良さそうなベンチャー企業を見つけたので面接を受けに行った。技術的には面白そうなことやってそうだったが、外に向かって社内のことを明らかにしていない会社で、中のことが全然わからなかった。なので結局内定を辞退した。面白そうだけど社員のブログやTwitterが読めないとなるとものすごく不安になる。

ペパボに入ったのは、アラタナ研究所所長の rytich さんのかつての職場で、rytich さんに声かけてもらってペパボの人と一回酒飲んだことあったし、かぶりものの社長とか創業者の家入さんとか何となく知ってて安心感があったから。とはいえどんなことやってるかよくわかんなくて不安がないわけじゃなかった。そういうよくわかんなさを吹き飛ばしてくれたのは刺身☆ブーメランさんのブログだった。

これ読んで「あ、なんか大丈夫そう」と思ったから面接受けに行った。

刺身さんにはペパボに入ってからもRailsのこととか教えてもらって世話になってるけど、あの記事読まなかったらペパボ受けようと思わなかったかもしれないと思うと何とも言いようのない感謝の念がわいてくる。ありがとうございます。もちろん rytich さんも、もうペパボ退職されたけど taketin さんもありがとうございます。

雑然とした感じの日記になったけど、自分はいま楽しく働いてます。

追記 2019/05/13

| @散財

プログラマならUS配列でしょ、と思って最近買ったHHK ProとMacBook AirはUS配列を選んだけど、使いにくくて非常にストレスを感じている。プログラマは全員英語環境でパソコン使うべきってのは妄言だと思った。JISに慣れてたらJISの方がいい。

個人的に耐えられない点を以下に列挙。

1. 英数 <-> かな切換の煩わしさ

自分の場合、英数 <-> かなの切換をキーを一個押すだけでできないのには多大なストレスを覚える。コマンド + スペースで切り換えられるとはいっても、いま英数・かなどちらの入力モードにいようとも英数文字を入力したければ英数キーを叩いてから入力すれば必ず英数文字を入力でき、逆の場合も確実にかな文字が入力できるJIS配列キーボードの方が便利だ。

2. MacBook AirのUSキーボードのtildeキーの位置

なんと狂っていることに、”~” (tildeキー)が左上エスケープキーの下部分にある。JIS配列でいうところの「1」のとこらへんだ。なんだってこんなところにtildeを用意するのだろう。tildeはシェルで自分のホームディレクトリを表す記号で大変よく使うキーだ。アメリカ人は不便に感じないのだろうか。

3. returnキーの小ささ

JISキーボードのreturnキーは大きく、大変打ちやすい。しかしUS配列ではreturnキーは小振りになり、右shihtキーの上に同じ程度の横幅で慎ましやかに座している。こんなの超打ちにくい。しかもreturnキーのすぐ上にdeleteキーがあるものだから、JISキーボードの癖でreturnしようとしてdeleteしてしまうことがしばしばあるのだ。非常にうざい。

4. コロン入力時にshiftキーがいる

僕のメインテキストエディタはVimなんだけど、Vimではコマンド入力時に “:” (コロン)を多用する。JIS配列ではコロンは単独キーで入力できるが、US配列ではセミコロンとコロンが同じキーに割り当てられており、shihtキーを押しながらセミコロンを押すことで入力できる。Vimでガリガリコードを書いているときに非常に煩わしい。Vimでコード書くときの時間が1.5倍くらいになってるような気がする。

以上、自分にとって英語配列キーボードのいけてない点をつらつらと書いてきた。KeyRemap4MacBookとかでキーマッピングをカスタマイズしてから使えやハゲ、とかいわれそうだけど、非純正のソフトに依存しないとキー入力すらままならなくのは嫌なので自分はそんなん導入したくない。

結局、JIS配列に慣れ親しんだ人間がUS配列のキーボードに切り替えるメリットは少ないように思う。キートップからひらがなが消えてシャレオツになるくらいか。アメリカに転勤することになって今後は現地のUSキーボードのパソコンしか買えなくなってしまった、とかであればUS配列への鞍替えは避けられないと思うけど、そうでない場合は無理してUS配列のキーボードを使う必要なし。