「YOUはどうしてエンジニアに？」は開発現場のエキスパートから滋養深い洞察を聞き出し、皆様のキャリアにお役立てればというインタビュー企画です。エッジな人がどういう考えをお持ちなのか、気になりますよね。第一回は @kitak さんをお迎えしました。（聞き手：こんぴゅ） こん: 今回はkitakさんにお越しいただきました。めちゃんこ出来るエンジニアだと僕は尊敬してるんです。さっそくなんですが、YOUは技術領域ではどこがお得意ですか？ kitak: webのフロントエンドを仕事で担当しているのでそこですかねえ。前職ではRailsをやってました。Vagrantやpuppetを使って環境構築をしたりするのも得意でしたね。 こん: そすよね。とりあえずフロントエンドで困ったらkitakさんに聞いちゃいます。そんなプロフェッショナルなkitakさんですが、YOUの仕事道具でこだわりポイントはあります？

母校の学生(1年生)にお仕事紹介してきたシリーズです。今回から本題のエンジニアの仕事紹介です。しっかりとポエムを叩き込んできました。 第一回: https://note.mu/konpyu/n/n9d3e3195b673 第二回: https://note.mu/konpyu/n/nc603b5942cbd webエンジニアの仕事webサービスは複数のサーバー（コンピュータ）からなります。サーバーをセットアップしてネットワークに投入し、動作や性能を監視するのがまず大きな仕事です。 これは、Pixivのサーバールームです。サーバーをラックに乗っけて配線して冷やして....と色々やる事があり、いかにも大変そうですよね。 参考: http://ascii.jp/elem/000/000/844/844678/ ですが、最近は直接サーバーの機械類を触る機会は減っています。「クラウド」といって高品質

ポアソン分布という確率分布を習ったのでまとめてみます。ポアソン分布は二項分布と近い関係があります。具体的には、回数が大きく、発生確率が少ない時二項分布の近似とみなせます。まずは二項分布から見ていきます。 二項分布二項分布は発生確率pの事象Aがあったとして、それがn回の試行で何回起こるか?を表したもの。n回の試行でk回起こる確率は nとpで形が決まる分布になっていることを確認してください。 ポアソン分布二項分布の期待値λは事象Aの発生確率pに回数nをかけたものです。例えば、100回コインを投げて表が出る期待値は100*0.5=50（回）となります。つまり、期待値λはλ=npとなります。二項分布はnとpをパラメタに置く関数でしたが、ポアソン分布はλだけで二項分布を表現し、nを非常に大きく、pを非常に小さくという縛りを加えることで近似できるようにしたものです。 ポアソン分布は二項分布（及びその近

バス停に到着した瞬間にバスが来て滑り込めると最高に嬉しい。そりゃ誰でもそうだろうが、僕は人一倍「待つ」という行為が嫌いなので喜びもひとしおである。 いままではジャストで乗れりゃあラッキーくらいの感じだったのだが、先週偶然に、停留場からみてバスがどれくらい近づいているかをリアルタイムで表示しているサイトを東急バスが公式で運営していることに気づいた。 東急バスナビ｜バス停名称から検索(停留所別バス接近情報) http://tokyu.bus-location.jp/blsys/navi?VID=top&EID=spn&PRM= コレを見れば、バスがどれくらいの本数近接していて、あと何分くらいで来るかがざっくり分かるので、時間を合わせて自宅を出ればジャストで乗ることが可能になりそうだ。 さっそくためしてみた自宅からバス停のドアtoドアの時間を計測してみたところ 3分半くらいだったので、4分〜5分

ケーブルが増えるのがとにかく嫌いである。 線が床に着地しているとルンバが引っかかるし、絡み合うと面倒だし、延長タップはダサいし....とイイことが全然ない。特に、家電の中でも専用アダプタ・専用端子が必須なタイプの製品は、付属の線を無くすと大変に困る（メルカリに泣きつくハメに）ので更に最悪だ。 そういうわけで、USBが出てきた時はかなり嬉しかった。昔はPS/2やらRS232CやらIEEE1394やら機器ごとに色々端子がありややこしかったのだけど、USBでかなりスッキリした。端子のフォーマットなんて機能を満たすなら必要最低限でいいはずで、あるべき姿ではある。 しかし、USBは登場からだいぶ時間がたち、そろそろ他のフォーマットと比べると速度や性能面で弱点が目立ちはじめてきた。なにより裏表を間違って時間を無駄にするという半端ないBad UXをなんとかしてほしい。そんなこんなで、USBの次世代フォー

「広告」だけに依存しない収益モデルを備えたウェブメディアを構築するため、世界中でいろいろなトライアルがなされている。この潮流に関して、示唆深い事例が2つでてきて参考になったので紹介したい。 steem: 仮想通貨の報酬ドリブンで良記事を選ぶsteemはbitcoinのようなブロックチェーンベースの仮想通貨だ。コンテンツを投稿したり、コンテンツに対しコメントや投票（Vote）をすることでコインが得られる。 多くの評価を得たコンテンツは良質とみなされ、発生する報酬が多くなる。投票側では、Voteをとあるコンテンツやコメントにした際、それが大量のVoteを集めるほど高報酬になる。更に、そのコンテンツやコメントが作成されてすぐに投票するほど高報酬になる。つまり、皆が評価する良記事をいち早く発見して投票するのが最も儲かることになる。 で、肝心の報酬（steemコイン）はどこから支払われるかというと、

先月あたりから、オープンソースソフトウェア（以下、OSS）のライセンスのあり方について、Facebookを火種にして侃々諤々の議論が起こっているので解説してみる。 ASFがFacebookにNOをつきつけることの始まりは、Apache Software Foundation（以下、ASF）という著名OSSプロジェクトを多数保有する非営利団体が、Facebookが自社OSSに付加している独自ライセンス Facebook BSD+Patents license を「Category-X」リスト（禁忌リスト）に追加したことだ。 ASFプロジェクトは、Category-Xに含まれるOSSに依存してはいけない決まりがあるため、Facebook製のOSSに依存しているプロジェクトは、8月31日以降はそれらの依存を取り除いてからではないと新しいリリースが出来ない。影響を受けたプロジェクトは少なくとも C

エンジニアは趣味で自分のプロダクトを作ることが昔から推奨されている。いちからフルスクラッチでサービスを作るのは開発以外の目線が身につくし、普段使ったことがない技術の素振りに丁度よい 。何より、自分が欲しいものを作るのは楽しいのである。 ※ちなみに、業界ではよく知られているのだけど、就活や転職活動では趣味プロダクトをやっていることは良いアピールで抜群にウケる。それでも、実際に作っている人は少ない。 では実際のところ、趣味プロダクト開発はどのように進むのか。僕のケースについて紹介してみたい。 StartMapの場合東京のスタートアップを一覧できるStartMapというサイトを作った http://startmap.info/ 2015年の大晦日前、みんな帰省して暇だしなんかつくるかという話になり、友人の @tejitakさんと@tyshgcさんとで三茶のデニーズでブレストをした。「これだ！」と

Y Combinatorはシリコンバレーの有名なVCで、少額を多くのスタートアップに投資するユニークなスタイルで知られている。その代表者、Paul Grahamの言葉に「Make Something People Want（人々が求めているものを作り出せ）」というのがあり、スタートアップを成功させるコツを簡素に表したものとして業界では広く知られている。 このスローガンを地でいっており、こりゃすげえわと感じた事例を見つけたので紹介したい。ipinfo.ioというサービスなのだが、やっていることはかなり地味で、IPアドレスを与えるとそのIPの国や緯度経度や管理組織などの情報を返すAPIを提供している。 ↑これだけ、といえばこれだけである Make What People Ask For（人々がいま要求しているものを作り出せ）stackoverflowという開発者なら誰もが知っている技術系Q&A

先月、Twitter社が"Twitter Lite"という軽量バージョンを発表した。新興国向けに、2Gや3Gのような低速で不安定なネットワーク下でも快適に使えるように通信量を抑え、動作速度も向上させる、というのがコンセプトらしい。 Twitter Liteのご紹介 https://blog.twitter.com/ja_jp/topics/product/2017/twitter-lite_.html たしかに、初回ロードの読み込みサイズを見てみると、なんと400キロバイト以下しか転送されていない。普通の画像2,3枚分よりも小さく、めちゃめちゃコンパクトである。 それだけ?それだけなら「ふ〜ん、そうなのね」で終わりなのだが、技術的な側面で言うと、じつはTwitter Liteはネイティブアプリではないというのが見どころだ。単なる、普通のwebサイトなのである。mobile.twitter.

この世には、ダウンすることが許されないシステムが存在する。金融機関の基幹系、原子力発電所や鉄道の制御システム、流通業の物流管理システムなどはもちろんであるが、最近ではtoCのサービスでもダウンタイムが長くなると大事件として騒がれ、ヤフトピに載ってしまったりする。 ではダウンへの対策はどうするかというと、いくつか手法はあるのだけど代表的なのは「冗長化」である。簡単に言うと、全く同じシステムを裏側に待機系として用意して、有事の際は自動的に切り替わるようにしておくのである。素朴だが、殆どのシステムではこの種の仕組みを用意している。 それでうまくいけばいいのだけどじつは、この待機系への切り替えというのは鬼門であり、高確率で失敗する事になる。 ［続報］東証のシステム障害、原因はハードウエア故障後の切り替えミス http://itpro.nikkeibp.co.jp/article/NEWS/2012

エンジニア稼業をやっていると、正確に作業量を見積もることは困難だと感じることが多い。ある程度まで作ってみないと当初の設計がうまく機能するのか把握できないし、仕様を変えたほうが好ましいと途中で気づくケースもある。ソフトウェア開発のあるある話である。 同じように、必要なサーバーの台数や帯域なども事前に予測するのは困難なことが多い。AWSやAzureのようなクラウドがメジャーになっているのは、そのような課題に「使った分だけ課金」という従量課金で答え、バチコーンとハマったからである。 そして...何年もクラウドを使ってると、すっかり従量課金の考えに慣れてしまい日常もそれでいきたいと感じるようになった。 現在、僕の家には洗濯機がない。洗濯というサービスは近くのコインランドリーで享受すればよいのだ。洗濯機と乾燥機を回した分だけ課金。わざわざ洗濯機を買うとなると、選ぶのも設置するのも干すのも捨てるのもく

就職活動では色々なシチュエーションで面接が設定されますよね。 ソフトウェアエンジニアの枠で面接を受ける際、スキルチェックの一環でコーディング面接を設けられているケースが多々あります。あまりに多いので、専門の攻略本もたくさん出ています。 世界で闘うプログラミング力を鍛える本 ~コーディング面接189問とその解法 https://www.amazon.co.jp/dp/4839960100 出される問題はだいたい、コンピュータサイエンスの基礎知識を前提にしていて、アルゴリズムをホワイトボードに書かせたり、計算量の見積もりをさせたり、漏れ無く考慮が出来てるかをチェックされたりするわけです。 僕もこの手の本は好きでたまに見ます。とはいえ、実際の業務で、コンピュータサイエンスの知見をフルに活かしてゴリゴリ効率的なアルゴリズムを書いたりメモリ空間をカリカリにチューニングしたりすることはあるか?と言われ

急にMastodonという分散型マイクロブログが話題になってきましたね。短文投稿が出来るTwitterライクなサービスですが、ソースが公開されており、自分でインスタンス（=サーバー）を立てることができます。その上で、サーバー（=ドメイン）をまたいで、フォローをすることができます。これをリモートフォローと呼ぶようです。 これにより、Twitterが障害などで落ちても全滅することはなくなり、データもTwitterのみに握られることもなくなり、勝手にアカウントの凍結やBANも食らうこともなくなります。 Mastodon自体はOStatusというオープンなプロトコルの実装レイヤでしかありません。つまり、思想的には別段新しくはないのです。 詳しくは以下の記事がめちゃんこよくまとめてくれています。 https://blog.cardina1.red/2017/04/13/federated-socia