$age++ - @kyanny's blog我孫子武丸の「殺戮にいたる病」を買った（よりによってこんな日に 前の会社で作ったサービスの閉鎖が告示されていた（よりによってこんな日に 月が変わると Linkedin の職歴上で、 Quipper での勤続年月がライブドアを抜き、人生で最も長く勤めた会社になる
modern.ie で配布している IE テスト用バーチャルマシンのライセンス期間を延長する方法は VM のデスクトップの壁紙に書いてある - @kyanny's blog
https://www.modern.ie/ で IE テスト用のバーチャルマシンを無料配布していて、 90 日間は無料で利用でき、さらに回数制限はあるもののライセンス利用期間の延長もできる、と、ここまでの情報はたくさん見つかるが、不思議とライセンス利用期間を延長する方法をどこのウェブサイトも記載していなかった（たぶん方法を知らず、調べもしないのだろう） modern.ie のサイト上を見て回ったり、ライセンス条項を記したテキストファイルも読んではみたものの、やり方がわからずじまいだったのだが、この前ふと立ち上げた VM のデスクトップの壁紙を眺めていて、「実は壁紙にやり方が書いてある」ことに気づいた。まさか有意義な情報が書いてあるとは思いもせず、読もうと思ったことすらなかった。灯台下暗し。 残りの利用期間を知るには、コマンドプロンプトを起動して slmgr /dlv と入力する。 利用期
Solarized Light / Dark themes for Quiver - @kyanny's blog
I made Solarized Light / Dark themes for Quiver. github.com I've used Solarized themes sometimes in my favorite editors (Vim, Emacs and RubyMine). I like it. Now I'm using Quiver, so why not use Solarized? Unfortunately, Solarized themes didn't exist for Quiver. Fortunately, Quiver allows me to make custom theme, and Solarized makes its color scheme public, so why not create theme? It was a really
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
最近思ったこと - @kyanny's blog
日本経済新聞 特定疾患の自己負担額がまた上がり、月ごとに一回の診察・治療につき二万円になった。レミケードを八週感覚でやっているので、ならすと月一万くらいになる。 自己負担額は所得に応じて決まるものだから負担が重すぎるということはないし、補助なしではもっと高額になるところを免じてもらっているのだから有り難がりこそすれ不満など言えた立場ではない。 元アナウンサーが人工透析の患者を誹謗するようなことをいって炎上した一連の記事などを少し読んだ。正論だと思うし、自分が病気一つしない健康な身体の持ち主だったら賛同していたかもしれない。 けれども、人工透析ほどではないにせよ高額な医療に依存して生きている身からすると、医療を「足切り」すべきだという風潮は受け入れがたい。だって金払えなくなったら死ぬ、死ねってことだもの。それは過酷すぎる。人並み以上に働いて稼ぐことが難しい病人には、なおさら。 1 on 1
line-bot-sdk-ruby のサンプル echobot を Heroku で動かす方法 - @kyanny's blog
2016/10/06 14:59 追記 コメント欄参照。IPアドレスをホワイトリストに登録する必要は無いのでHTTPプロキシを通す必要もなく、従ってサンプルコードは無改変で動く模様。以下の内容は全て徒労だった。 Gemfile.lock とか config.ru を足して、固定グローバル IP で LINE Messaging API にアクセスするように HTTP プロキシを通せばよい。それらが設定済みの できるリポジトリはこちら↓ github.com ...が、 HTTP プロキシを通すようにするだけのことで異常にハマった。結論として、必要最小限のメソッドをオーバーライドするのが良い。オリジナルの app.rb との Diff はこんな感じ。 Comparing c2f3dd962772b2c8a2cda05528ff643d750b5597...v1.0.0 · kyanny/li
なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか - @kyanny's blog
ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を
How Quipper tests software - @kyanny's blog
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ
BOM つき UTF-8 ファイルの作り方・確認方法・削除方法 - @kyanny's blog
CSV ファイルを一行ずつ処理するプログラムを実行したら一行目のデータでエラーになったが、ログをみてもファイルをエディタや cat(1) でみてもおかしなところはない、ということがあって、 BOM かな？と思ったけど BOM つきかどうか確認するのに手間取ったので、次回（何年後だろう）のためにメモ。 BOM がついてるか確認する more(1) か less(1) で開いてみてファイル先頭に <U+FEFF> があったらビンゴ。 file(1) でも教えてもらえる。 Emacs でファイルを開いて BOM を確認する・表示させるのはやり方を見つけられなかった。 hexdump(1) でファイル先頭に？ ef bb bf あるか見るのでももちろんよいが、普段からバイナリファイルのダンプを見慣れていないと見てもとっさに BOM つきであることがわからないので、一目見て明らかにおかしいとわかる
Contents is king - @kyanny's blog
学習サービスのソフトウェア開発に二年半ほど携わってきて、「主役は教材コンテンツである」ということが、ペンキを重ね塗りするように最初はうっすらと、徐々にくっきりと、心の底から納得するというレベルで「理解」できてきた。自分が作っているソフトウェアはコンテンツを利用するためのツールに過ぎない、ということだ。 ツールがヘボいせいで教材が利用しづらくなり、結果的に教材そしてサービスの価値を毀損してしまうことは十分ありうる。しかし、ツールがどれほど素晴らしくても、教材コンテンツがヘボかったら価値はゼロだ。ダメな教材で勉強したいとは思うひとは誰もいない。ツールたるソフトウェアは価値を殺さず・より引き出すための引き立て役なのだ。 その前提に立ってようやく、あの「UI・UX」というやつが、限定的ながら理解できた。主題が明らかになって初めて、引き立て役が「何を」引き立てるのか、という議論が成り立つ。価値あるコ
最近思ったこと - @kyanny's blog
ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。 おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。 そのシステムが実現するビジネスにおける仕様について（仕様書なのに）触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不
理想的なコードレビュー - @kyanny's blog
理想的なコードレビューとはどういうものだろう。前提として、 Git のよくあるワークフローで常識的なサイズのトピックブランチを、 GitHub か似た何かの Pull Request 的なビューの単位でレビューする、とする。 無言、または LGTM や :+1: など、「ちゃんとレビューしたよ、オッケーだよ」というシンプルな意思表示のみでマージに至るものは理想的に思える。レビュアーの「自分だったらこう作る」という設計・実装イメージとレビュイーの「自分はこう作った」という設計・実装がほとんど違わない、もしくはレビュアーのイメージとは違うけども納得できる結果になっている、よってコメント不要、なのだといえるからだ。 これを理想だとすれば、なんであれコメントがつくのは理想的ではない、ということになる。レビュアーとレビュイーの見解・実力に差があり、それが設計や実装の欠陥を指摘するコメントや、逆にコー
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
いま、 Quipper ではたらく魅力とは何か - @kyanny's blog
イベント等で社外の方と会うと、セールストーク気味に「Quipper の魅力」を語ってしまうことがある。そういうときはたいてい、 世界各国でサービスを提供しているグローバル企業であること モダンな開発環境・開発プロセスを採用していること 「教育」という社会的に意義がある事業をやっていること みたいなことを言うのだが、内心「グローバルでモダンな開発で社会的意義のある事業をやってる会社は他にもあるよなぁ」と思わなくもなかった。平凡ではないが、圧倒的でもない。他との差別化には、これだけでは不十分だ。 だが、いまの Quipper には他を凌駕する魅力がある。「世界一への挑戦権」がそれだ。 jp.techcrunch.com TechCrunch の記事にも書いてあるように、 EdTech シーンはビッグプレイヤーが世界中で陣取り合戦をする段階に入っている。特定の分野や地域に特化したサービスは今後も
Quipper のスピード感 - @kyanny's blog
先日、ブログ記事を読んでいて autodoc というツールを見つけた。 Rails の Request Spec から自動的に API ドキュメントを生成するというもの。コードとドキュメントが食い違ってしまう問題を解決できるかも、と思って試しに Quipper 社内で紹介してみた。 当初は「良さそうだね、でも今使っている API サーバー用フレームワークでは使えないようだし、こまごまと不満もあるので、いずれ Rails に乗せかえるときにでも再検討しよう」なんていう反応を予想していた。自分の担当箇所でちょっと使うくらいが関の山だろうなと。しかしその予測は見事に外れた。 紹介した当日、我々が API サーバーを書くのに使っている grape という gem で autodoc を利用するのは骨が折れそうだということがわかる。にもかかわらず翌日、 API サーバーを Rails にマイグレーシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
