Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
Single Page Application ではない場合 JavaScript コードのエントリポイントはどこにあるべきか？ - @kyanny's blog
仕事で中規模程度の Rails アプリケーションのコードベースをいじっている。このアプリはもともと app/assets/javascripts 以下に必要に応じて JavaScript ファイルを置き、適当なテンプレートファイルから直接 JavaScript の関数を呼び出したりしていた。ごく普通の Rails アプリである。 このアプリは CMS で、いわゆる「ブログの管理画面」みたいな用途で使われている。一部の機能はそれなりに込み入った UI 操作を必要としページ遷移なしに操作できる必要があるが、旧来のやり方では JavaScript コードの管理が間に合わなくなってきたので部分的に Backbone.js を導入し始めている。 最近悩んでいるのが、 Backbone.js なコードのエントリポイントをどのように呼び出すべきなのか？ということ。そもそも自分が Backbone.js
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
Quipper のスピード感 - @kyanny's blog
先日、ブログ記事を読んでいて autodoc というツールを見つけた。 Rails の Request Spec から自動的に API ドキュメントを生成するというもの。コードとドキュメントが食い違ってしまう問題を解決できるかも、と思って試しに Quipper 社内で紹介してみた。 当初は「良さそうだね、でも今使っている API サーバー用フレームワークでは使えないようだし、こまごまと不満もあるので、いずれ Rails に乗せかえるときにでも再検討しよう」なんていう反応を予想していた。自分の担当箇所でちょっと使うくらいが関の山だろうなと。しかしその予測は見事に外れた。 紹介した当日、我々が API サーバーを書くのに使っている grape という gem で autodoc を利用するのは骨が折れそうだということがわかる。にもかかわらず翌日、 API サーバーを Rails にマイグレーシ
#isucon 2013 予選通過 - @kyanny's blog
isucon 2013 予選通過した。チーム名は :ok_woman: 選んだ実装は Ruby (Sinatra) ISUCON 本戦出場者決定のお知らせ : ISUCON公式Blog 予選二日前に @banyan から誘われ急遽参戦を決めた。予選当日までは十分な準備期間はとれなかったが、三回連続参加と場数だけは踏んでいるので振り返りという名の反省文を private repo の issue に書いて共有したりした。 当日の流れ。なんとなく役割分担したほうがいいねと事前に打ち合わせていたのもあり、チームリーダーの @m4i がデータベースを中心にパフォーマンス計測とチューニングの方針決定担当、 @banyan がデプロイ、開発環境整備、フロントエンドなどの足回り担当、残った僕がアプリケーション担当でひたすらコードを書く、という感じだった。 はやい段階で git pull によるデプロイ、
ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
Leave from paperboy&co., join to Quipper - @kyanny's blog
来週ペパボを退職します！転職先は Quipper です！みんな大好きウザい退職エントリも当然あとで書きますがウィッシュリストとか無いので！ブクマとスターを！！くれ！！！承認欲求！！！！— Kensuke Nagae (@kyanny) May 24, 2013 May 27 is my last day at paperboy&co. I had a great time with gentle people in this 3 years and 3 months. Thank you for all my colleagues! paperboy&co. is a good company for the following reasons: Culture: There are so many nice people here. They gather and play natura
書評: リーダブルコード - @kyanny's blog
オライリー・ジャパン高様より献本いただきました。ありがとうございます。 「The Art of Readable Code」については過去にブログで二度触れたことがありますが*1、日本語訳の出版に際し改めて紹介すると、これはコーディングに上達したい人のための本です。良いコードとは読みやすいコードである、と明確な定義をまず述べて、具体的にどのようなコードが読みやすいのか、読みづらいコードのどこをどう改善すれば読みやすくなるのかを掘り下げていきます。 この本が素晴らしいのは、徹底して具体的かつ実践的なテクニックを取り扱っていることです。ともすれば抽象的で主観的な内容になりがちなコードの読みやすさという話題を扱っていながら、豊富なサンプルコードと的確な改善例を示すことで、誰もが日々のコーディングに取り入れて毎日のコードをより良くしていけるように配慮されています。 本書で紹介されている考え方やテク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
