分かってる。2017年にもなって、まだ Boxen ユーザーがいたことに驚いているんだろう？ 参考）Boxen 使ってて許されるのは 2013年だけだった - Qiita しかし、今回の焦点はそこではない。少なくとも僕のユースケース（後述）にとっては、パーフェクトではないにしろ、Boxen は良い働きをしてくれていたし、長く苦楽を共にした戦友ともいえる存在だった。 そんな Boxen がリブセンス入社初日に死んだ。 具体的に言うと、 Mac の ユーザー名が数字のみ だと Boxen がエラーを吐いてマトモに動かない 原因は Boxen が使っている Puppet が、ユーザー名が数字のみだと、user ではなく uid として扱ってしまうため ユーザー名が数字のみだと Boxen や Puppet だけでなく他のツールでも不具合を引き起こす可能性がある ということについて、皆さんに注意を

ペパボを退職した。2011年11月から丸 6年所属したことになる。 先日、ペパボのみんなから寄せ書きをいただいたのだけれど「おいちゃんのブログがきっかけで入社した」という旨のコメントがとても多くて驚いた。それ自体はとても光栄なことで、おそらく下記のエントリーあたりのことを言っているんだろうと思う（いま読み返すとちょっと恥ずかしい） paperboy&co.（ペパボ）に入社して 1か月たちました paperboy&co.（ペパボ）に入社して、半年が経ちました ペパボのエンジニア評価制度を、社内の一般エンジニアはどうみているのか？ ただ、そんな自分が辞めたとなると、ペパボの外の人たちはペパボに悪い印象を持ってしまうのではないかと不安になったので断っておくと、ペパボの仲間は相変わらず最高だし「いるだけで成長できる環境」にも偽りはないと言い切れる。 退職するのはあくまで自分の中に変化があって、新し

ペパボでは小学3年生までの子どもがいる場合とか、一定の条件で短時間勤務をすることができるので、それを利用して昨年（2016年）の 3月から 1年半、短時間勤務をしている（通常 8時間勤務のところを 2時間減らして 6時間勤務にしている） 実際やってみてどうだったのか、ひとつの事例として参考になればと思い、書き留めておく。 環境（チームの規模等） 前提として、僕がどんな環境で働いているかというと、チームの人数やメンバーは変動があるけれど、およそチームの規模としては、 エンジニア 6人 デザイナー 1人 プロダクトマネージャー 1人 という感じ。1スプリント = 1週間でアジャイル開発している。 短時間勤務にしたかった理由 なぜ短時間勤務にしたかというと、手続上、何か理由がないと短時間勤務できないというわけではないんだけど、子どもの保育園の送迎というのが表向きの理由。 もう少しいうと、5歳の息

昨日 第9回 ペパボテックカンファレンス Vue.js 特集 を開催した。自分が企画して、準備、開催、無事に終わってホッと一息というところだが、まだ余韻が残っているうちに、主催者としての想いを書き留めておきたい。 勢い 人には、勢いというものが必要なときが、ある。 ある朝、いつものように井の頭線に乗って通勤していて、ふと、あ、Vue.js の現場特集やらなきゃ、という気持ちになって、一人で盛り上がっちゃって。お気に入りのノート（Rollbarn）にバァァーッと内容とかを書き出して。 そのままのテンションで会社のデスクについて、GitHub Enterprise の開発者全員がみるリポジトリの Issue にバァァーッと書いてポチっと投稿した。 あとでゼッタイ後悔するだろうな、と分かってて、やった。 後悔というか、こういう「やったほうが良いけど準備が大変」系のやつは（少なくとも自分は）冷静に

転職ドラフト（第6回） に参加した。参加に至る経緯については こちら に書いたが、それはともかくとして、結果を受けて、いろいろと自分を見つめ直す機会となったのでメモしておく。 結果 利用規約 を読むに（特に16条）あまり詳しく書いてはいけないと思うので企業名は伏せるけれども、 年収 800万 x 2 指名 年収 750万 x 1 指名 自分がパフォーマンスを発揮できる環境において、出せるバリューはこれくらいかなと考えて「希望年収」欄には 800万と記入していたので、まあだいたいそのくらいだよなと確認できて良かった。 全体の分布をみると下記のような感じで、ああ結構高く評価していただけたんだなと、嬉しく思った。 評価の理由 企業が記入してくださる欄に「指名理由」という項目があって、 フロントエンドとバックエンドどちらも高いレベル 適切な技術を選択してユーザービリティの高いものを一気通貫でつくり

Nuxt.js はユニバーサルな Vue.js アプリケーションを構築するためのフレームワークで、その公式ドキュメントの翻訳をはじめたのは 前回お伝えした とおり。 そして翻訳が完了し、昨日、日本語バージョンが公開されたのでアナウンス。 ja.nuxtjs.org Nuxt.js というレール 先日行われた Vue.js Tokyo v-meetup="#3" でも発表したんだけど、Nuxt.js は「レール」を用意してくれている。 これに乗れば、サーバーサイドレンダリングだけでなく、Vue-Router、Vuex、Vue-Meta など Vue.js 関連ライブラリとの統合を Nuxt.js がまとめて面倒みてくれる。したがって（本来やりたかったはずである）Vue コンポーネントの開発に集中することができる。 「レール」という言葉を使ったのは、かつて Rails にはじめて触れたときの感

今日はペパボの社内勉強会に TDD の実践者として知られる @t_wada さんが来てくださって「毎日コードを書く」ということについてお話をしていただいた。内容はおよそ こちら にあるようなことで、お話いただいた後の質疑応答でも、大変参考になる知見が得られたので、感謝の気持ちを込めてメモ。 何を得ようと思って参加したか 「今度 t_wada さんを囲む会をやるよ、内容はこんな感じだよ、希望者はぜひ参加して〜」という感じのアナウンスがされていて。 僕は以前、下記に書いたように、毎日コードを書くというのを試みたことがあって、もちろん得るものもあったが、インプットの量が減ってしまったという反省点のほうが大きかった。 プライベートで 689日連続でコードを書いた（ことの振り返り） 2016年になって、Pivotal Tracker でインプットの質と量を保てた一年だった と振り返ることができるほど

DHH さんが Rails 5.1 に Webpack を取り入れる意向 を示し、webpacker gem なるものをつくり始めたようである。 今後ますます Webpack は利用されていくであろうが、一方で Webpack はいろんなことができ過ぎるが故にかえって本質が掴みにくい点があると思う。そういえばこの間も、同僚のデザイナーに Webpack がよく分からないんですけど？と質問されていたのだった。 そこで今回 Webpack の本質つまり Webpack がどんな問題を解決しようとしているものなのかについて整理する。また Webpack の中核となる機能をよく理解できるチュートリアルを見つけたので紹介する。 （フロントエンドエンジニア Advent Calendar 2016 - Qiita の 9日目が空いていたので、後付けだけどそこに登録した） Webpack がつくられた背

プライベートで新しいサイトを作りたいと思い、ここ最近はデザインに関する本を集中して読んでいた。何冊か是非薦めたいものが見つかったので紹介する。年末年始のお休みのお供にどうだろうか。 今回紹介する本の範囲 デザインといっても範囲が広いが、今回紹介するのは主に UI デザイン、ビジュアルデザインに関するもの。また主にウェブサイトのデザインに関するもの。 なお今回できるだけ新しい本を挙げるようにした。ほとんど今年（2015年）発売されたものばかり。理論的なところはずっと前から変わっていないのかもしれないが、何せウェブデザインの流れがはやいので、説明がしっかりされていることに加えて、取り上げられているサンプルが新しいものか否かが読むときのテンションに大きく影響すると感じたため。 伝えたいことを整理しよう 今回、紹介する本の順番について悩んだが、最初の本だけは迷わなかった。 なるほどデザイン〈目で見

プライベートで 689日連続でコードを書いた。 あるとき毎日コードを書いてみようと思い立ち、それを 1年間続けたならば、何か大変なもの（力・成果）を手にしているのではないかと、はじめる前には予想していた。 しかし、いざやってみて、もちろん得るものもあったが、改善すべきことのほうが多い気がする。ので、ここで振り返って書き留めておこうと思った。 GitHub の Current streak もともと「継続は力なり」という言葉への憧れがあったと思う。ただ、継続は力、のような気がするが、子どもの頃から、皆勤賞とか何かをコツコツやる、みたいなものとは縁遠い日々を送っていたので、なんというか、そこに引け目みたいなものを感じていた。 そこへ（細かい話は割愛するけれど）「とりあえず 1週間だけ毎日コードを書いてみるか」と思い立つことがあって、それが運良く成功したら、GitHub の「Current st

少し前に Ruby 製のバッチ処理を省メモリ化したときの話をメモしておきます。 どのようなバッチ処理だったか 動画共有サイトにアップされた動画がオトナの事情によって削除されることがしばしばあるということは周知のことだと思う。そこで、一定時間おきに配信元サイトをチェックして、もし動画が配信元から削除されていたら、当該動画をこちらのサイトでも動画一覧に表示させないようにする、検索に引っ掛からないようにする、ということをやっていた。 便宜上、そのバッチ処理のことを「（動画の）存在確認くん」と呼ぶ。 oom-killer に殺されていた 彼は非常にデキる子だったが、なんか最近、動画の落とし漏れがあるなーと感じた。原因を調べたら、メモリを食い過ぎて oom-killer に殺されていた。 cat /var/log/messages Apr 6 12:46:45 xxx001 kernel: Out

長年の課題だった英語をようやく本気で勉強する気になった。三日坊主になるかもという危惧もあったが、気がついたら 2週間たっていたので、このまま習慣になることを願いつつ、一旦整理する。 やりたいこと（優先順位順） そもそも何がやりたくて英語を勉強をするのかというと、 1. 英語のドキュメントを読むスピードを上げたい。ちゃんと理解したい これがモチベーションの半分以上を占める。IT エンジニアなので読むドキュメントの半分くらいが英語で書かれていて、読むスピードが遅いと効率に直に影響する。 あとはまあ、例えば RailsCasts の動画 とかを見ながら理解できるようになりたい。つまり、 2. 英語を聞き取れるようになりたい とか、GitHub のプルリクエストや Issue とかで英語で言いたいことを伝えられるようになりたい。つまり、 3. 英語を（あまり考え込まずに）書けるようになりたい とい

これは Pepabo Advent Calendar 2014 の 8日目の記事です。昨日は Ubuntu + Monit + Fluentd 起動の自作 Docker イメージを DockerHub に配置までをやってみた でした。明日は laughk さんです。 今日はペパボのエンジニア評価制度について書きます。 （エンジニアの働き方 | キャリア採用 | 採用情報 | GMOペパボ株式会社） 評価制度そのものの内容は下記の記事が詳しいのですが、 ペパボのエンジニア評価制度をパワーアップした - delirious thoughts ペパボの2014年上半期エンジニア評価について - delirious thoughts 今回はできるだけこれまでにあまり語られてこなかった側面に光を当ててみようかと思います。つまり、 社内の一般エンジニア（シニア以上の職位を有していないエンジニア）はこの

これは Elasticsearch Advent Calendar 2014 の 11日目の記事です。 社内の新卒エンジニア研修で、先輩エンジニア＆デザイナが自分の得意なことや好きなことをそれぞれ 1時間使って講義するという枠があって、先日 Elasticsearch について話しました。 当日はほぼ口頭で説明したので、ほとんど見出しのみのスライド＆ホワイトボードを使いましたが、今日はスライドに若干の手を加えて公開しようと思います。 彼らに伝えたかったこと 彼らに何を伝えたかったかというと、Elasticsearch の全体像です。 「ちょっとチュートリアルやってみましたー」の後に、仕事で Elasticsearch を使えるようになるには、どこをおさえておかないといけないか、を話しました。 もちろん彼らが実際に仕事で使うようになるのはもう少し先のことで、そのときは今聞いたことなんてほとん

みんな大好き babyshark では全文検索に Elasticsearch を使っています。テストの書き方について日本語情報が少ないようなので、僕はこういう感じで書いてますというのを共有します。 環境は下記のとおりです。 Elasticserch 1.3.1 analysis-kuromoji（ブラグイン）2.3.0 gem rspec-rails 3.0.2 elasticsearch-rails 0.1.4 elasticsearch-model 0.1.4 searchable.rb まず、先に Elasticsearch へ検索クエリをどうやって投げているのかを簡単に擬似コードで説明すると下記のような感じです。 ActiveSupport::Concern を使って、Video モデルに search というクラスメソッドを生やしています。 # app/models/concer

最近、仕事でずっと iPhone アプリの API を Rails でつくっていて、ようやく 2014年2月6日（木）にやっとリリースできました。いろんなメディアに取り上げていただいて、ユーザー数も伸びてきて、嬉しい限りです。 古着フリマアプリ kiteco（キテコ）- 手数料無料キャンペーン中！ 開発の過程のなかで、Ruby コミッターの @hsbt さんと、WEB+DB PRESS で連載記事持ってる @udzura さんにだいぶ「かわいがって」いただいたので、得られた知見をここに書くことで、少し還元したいと考えています。 で、手始めに Rails の高速化のハナシから。 セキュリティに配慮してコードやログは加工しておりますが、できるだけプロセスを再現するかたちで書いてみます。 もくじ 1. はじめに 2. 高速化に着手する前に 3. 現状分析 - ログから読み取れること 4. テーブ

最近 Rails で API をつくりはじめたのですが、ドキュメントをどうしようかなと悩んでいまして。なにかイイ感じに自動生成してくれるツールはないものかと探していたら、@hsbt さんと id:antipop さんがまさにズバリのものを教えてくれました。 先日ふわっとリリースされた模様。 体育の日って高速に唱えるとテストの日に聴こえる - ✘╹◡╹✘ r7kamura/autodoc これヤバい。ので、どのくらいヤバいかを共有しようと思います。 Step 1. テスト内に autodoc: true と書く 例えば下記のような感じで、ドキュメントを生成したい対象のテストに autodoc: true と書きます。 # spec/requests/videos_spec.rb require 'spec_helper' describe '動画に関する API' do describe "