マウンテンビューの片隅で意識低く短期間滞在を生き抜くためのノウハウ - たごもりすメモ
自分もシリコンバレーはマウンテンビューに本社があるベンチャーに就職して仕事でカリフォルニアの青空すばらしい! とか言っているからにはこの地域でいかに生き抜くべきかみたいな意識の高いことを書こうかと思ったが、青空を見ながらも既にビールが入っていて到底無理そうだった*1。 なので、シリコンバレーとかベイエリアなんて風呂敷を広げず、マウンテンビュー、しかもダウンタウン近くではなくSan Antonioという微妙に離れた田舎でクルマ無しにショートステイを無事生きるにはどうすればよいかについて書き残そうと思う。 そんなニッチな文書書いてどうするんだという話はありそうだが、少なくともこれから東京で入社してくる同僚のためには役に立つ……はずだ。 前提 San Antonio Mountain Viewというところにオフィスがあって、そこに徒歩で通えるあたりのホテルもしくはAirbnbに宿泊すると思いねえ
2015年を振り返ってみる - たごもりすメモ
今年はとにかく仕事してた……。ということで、Blogエントリ数を見てみるとこれまでの数年に較べてだいぶ少ない。 転職した 大手インターネットサービス事業者から、いろいろあって結果的には西海岸のスタートアップ(の東京オフィス)に移った。 tagomoris.hatenablog.com tagomoris.hatenablog.com 今年のいちばん大きな変化だったのは間違いない。このあとUSオフィスに少し行ってたり、この「いろいろあって」のときに考えてたことをエントリに書いたりもしていた。 結局その後に仕事をしていてこれまでと全く違う環境になったし、書くコードの種類や性質、考えかたなんかもけっこう変わったなという自覚はある。 マウンテンビューの片隅で意識低く短期間滞在を生き抜くためのノウハウ - たごもりすメモ 小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメ
ISUCON5の出題をやった - たごもりすメモ
(11/2 11:03 末尾に追記と得点経過グラフ掲載) 正確にはいままさに決勝のイベント中なのだが、思った以上に順調にイベントが進行していてヒマな上、完徹の後でコードとか書いてる最中に意識が飛んだりするのでコードも書けない。のでつらつらこれを書いている。 9月末にISUCON5予選をやり、10月末のいま決勝をやってます。3年ぶりのISUCON出題側でしたが、いやはや、過去最高にきつかった回だった。ちょっとday jobのほうでもクリティカルなあれこれが重なったのもあるけど。 しかし両方とも、直前までの死ぬ寸前みたいな追い込み状況に対し、イベントとしては*1大きな破綻もなく進み、本当に良かったと思っている。このイベントがイベントとして成立したことが本当に嬉しい。 そういったあれこれは本当に一緒に出題をやってくれた@kamipoさん、そして実装を手伝ってくれた@hydrakecatさん、@n
就職しました - たごもりすメモ
結局3月からそのまま働くことにしました。 先日のエントリを書いて以来、本当に多くの方から声をかけていただきました。ありがとうございました。本来なら個別にご報告するべきところですが、ちょっと数が多くて厳しいので、このエントリをもって報告にかえさせていただきます。 またいろいろと話を伺う中で考えたことなどもあるので、そちらについては別途エントリを書くつもりです。 様々な話を聞いた上で、1月末の時点では自分でもわかっていなかったことがわかりました。最終的に重視したのは以下の点です。 技術ベンチャーであること ベンチャー企業として大きな成功を狙っていること、またそれが有望に見えること 優秀なプログラマが同僚に多いこと 退職エントリに書いた観点のほかに、この3点が今回の自分にとって重要だということは後から見えてきたことでした。 ということで Treasure Data に入社しました。Softwar
RubyConf 2014にいってきた＆しゃべってきた - たごもりすメモ
出していたproposalが通ったので Rubyconf2014 に行ってきていた。旅費および会期中の宿泊費は現勤務先のLINE株式会社に出してもらいました。いつもいつもありがたいことです。 サンディエゴの会場付近はとにかくリゾート地っぽい感じで、あちこちに背の高いヤシがぽんぽん立っており、空も海も青いし、なるほどこれは国民性も変わろうというものだ、という感じ。初のアメリカ行きがこれだったので、USに対してだいぶ変なバイアスがかかった可能性がある。 そこでまたNorikraの話をした。何回目だと言われるかもだけど、英語だとまだ2回目だったし、英語圏でのカンファレンスでは初めてだったので……。 Norikra: SQL Stream Processing In Ruby from SATOSHI TAGOMORI 人によっては*1多少ウケたっぽいのでよかったよかった、ということにする。が、こ
Norikra v1.0.0 - たごもりすメモ
English article 以前からスキーマレスなストリーム処理をSQLで！というソフトウェアとして作っていたNorikra、このたびあちこち機能改善したりしたので、既にお仕事で絶賛稼働中ということもあるし、区切りとして v1.0.0 としてリリースした。 ついでにロゴとかも作ったので、なんとなくいい感じになりつつある。 https://rubygems.org/gems/norikra/versions/1.0.0-java http://norikra.github.io/ 修正点は リポジトリ のChangesに書いてあるが、curlだけで操作できるようHTTP JSON APIが加わってたり、GCまわりでハマらないようなデフォルトオプションが入ってたり、分析系クエリを書きたい人のために Group-by with Rollup や Grouping sets, Cube などの
業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ
先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を
4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ
今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、
tagomorisとDMM.comのはなし - たごもりすメモ
前にこんなblogエントリを書いた。 dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ このエントリ、Cassandra Casualという勉強会でCassandraのようなそうでないような話を聞きながら、しかもビール2本飲んだ状態で書いたものだった。書いてさっさと公開して放っておいた*1ところ、だいぶ経ってはてブがやたらとついていることにびっくりしたものだった。 正直に言おう。対象はなんでもよかったんだ。世間に知られている大規模インターネットサービスを運営していて、会社としての・中の人としての雑誌記事やイベント登壇やblogエントリがあまり見られない企業であれば。DMMでなくても、たとえばFC2でも楽天でもNTT docomoでもY!Jでもドワンゴでも。 もちろんどんな会社の人でも行くべきところに行けば中の人がいるのは知っているけれども、そういう話じゃない。単に
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
#fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場
前に自分で書いた fluentdのためのプラグインをイチから書く手順 - tagomorisのメモ置き場 はたいへん重宝していたのだが、書いたすこし後になって実は現在すでに bundle gem コマンドを使うやりかたが良さそうだということがわかってしまったがばたばたしてて移行してなかった。 で、またひとつプラグインを書くことにしたのでついでに bundle を使った手順をざっくりまとめておく。以下のエントリをたいへん参考にさせてもらった。 T-POINTを取得するスクリプトをGistから移動, Bundlerを使ったGem作成メモ (自分用) - ただのにっき(2012-02-18) 準備とディレクトリツリーの作成 bundler は必要なので、なにはなくとも入れておこう。 gem install bundler そしてプラグイン用ディレクトリツリーを作成する。今回は DataCount
RubyKaigi 2013にいってきた＆しゃべってきた - たごもりすメモ
この5月30,31日および6月1日に行われた RubyKaigi 2013 にproposalが通ったので、スピーカーとして参加してまいりました。 http://rubykaigi.org/2013/ 面白いトークがいろいろあったし色んな人と話ができたし、空き時間にfluentdの修正についての話や作業も進んだし、本当にすばらしいイベントだった。 お台場は遠かったけどHerokuさんのおかげでお昼に困らなかったし、Microsoftさんのおかげで飲み物にも困らなかったし、Githubさんのかげで懇親会にも困らなかった。すごい。スポンサー様すごいですね。 セッションはいろいろ聞いたけどまとまらないのでパス。テクニックの話が多かったな。Rails以外にRuby本体の話がちゃんといくつもあるのがさすがRubyKaigiですごい。RGenGCはFluentdにすごい効きそうなので期待したいなあ。
dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ
dmmは世の中のオトコノコにとっていろいろと言及するのに躊躇いつつ誰でも知っているアレなわけです。で、それなりの規模のWebサービスの裏側を見たことがある人なら誰でも、dmmの裏側はきっと物凄いことになっているに違いない、ということが想像がつくわけですね。 簡単に思い付く範囲でも以下のようなものがあります。 膨大な画像(サムネイル)および実コンテンツ(画像、動画、ソフトウェア圧縮ファイル)を配信するトラフィック しかもトップ数パーセントだけではなく、おそらくかなり裾野が広いトラフィック 膨大な商品の高速な列挙・表示 膨大な商品に関するタグつけ 膨大な商品に関する自然言語による全文検索 全トラフィックにおける膨大な量の課金・決済トランザクション 実物の通信販売に決済結果を載せる流通関連の問題 大勢のユーザに対して膨大な商品から適切に行うためのレコメンデーション これだけのことをやっているから
xargs を使ってカジュアルに並列処理 - たごもりすメモ
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい！と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
Hadoopクラスタでulimitを設定するときの注意点 - たごもりすメモ
Hadoopクラスタを運用する際に ulimit で nofile (プロセスがopenできるファイルディスクリプタ数の上限)の設定を変更しておくべき*1というのはもはや常識的なお話ですが、そこには実は罠がある。たぶんRHELのデフォルト通りならハマらないんだろうけど、手を入れている環境だとハマる。ので、その話。 要するにハマった。のを解決したよ多分！ まだ最終的な確認できてないけど！ 各書籍での解説 とりあえず、国内で売られているHadoop関連書籍の記述を確認しておこう。まずHadoop徹底入門。 ファイディスクリプタの設定は、/etc/security/limits.conf に記述します。エディタを利用して、limits.conf に以下のように記述します。ここでは、Hadoopの各種ノードを起動するユーザーを hadoop とします[12]。 hadoop soft nofile
HDFSでMissing blocksが出た場合、DataNodeに問題があって外したい場合の対応メモ - たごもりすメモ
手元でちょっとやったのでメモっとく。 Missing blocksが出た場合 HDFSのブロックが読めなくなることがある。手元ではHoop Server経由でappendが高頻度で発生している状況で、さらにHiveのクエリ実行が重なって派手にiowaitが出たときに起きた。 こうなると、そのブロックを含むファイルをMapReduceジョブが読みにいったときにIOErrorでコケてどうにもならなくなる。 状況は以下のコマンドで確認できる。 $ hadoop dfsadmin -report Configured Capacity: 35339596017664 (32.14 TB) Present Capacity: 33745796892986 (30.69 TB) DFS Remaining: 13764055724032 (12.52 TB) DFS Used: 19981741168
サラリーマン人生における希望と絶望 - たごもりすメモ
自分のささやかなサラリーマン人生において、大きい会社(の一部)も小さい会社も見てきたけれど、そこで気付いたことがあって、そんなもやもやが堆積してきたのでここに吐き出す。たぶんまとまらない。 サラリーマンには2種類いる。 会社を肯定する奴と文句ばかり言う奴、ではない。会社の文句を言う一方、同じ口で会社を肯定することも言う奴、と、会社のことを肯定も否定もしない奴だ。*1 自分の所属する会社に対して不平を言う人はけっこういる。取締役会の決めることや人事異動や予算配分やプレスリリースにしじゅう文句を抱えていて、お昼休みや飲み会やタバコ部屋であーだこーだいう話をする人はたぶんどこにでもいる*2。 曰く、なんで会社が利益を出せているかが分からないくらいだ、会社がなんで存続できているかが不思議だ、あの上司はなんにもわかってない、今度のアレは失敗するに決まってる、あそこのアレがいつまでも改善されなくてうん
RAIDレベルの話: 1+0と6はどっちが安全か？ - たごもりすメモ
仕事でちょっくら12台のHDDを使ったRAIDアレイを組むんだけど、その折にちょうどTwitterで「RAID-1+0にしないとRAID-6とか怖くて使えませんよ！」というウソ八百な内容のWebページのURLを見掛けたので、いいかげんそのような迷信が消え去ってもよかろうと思って書くことにした。 1重ミラー設定のRAID-1+0は安全性においてRAID-6に劣る。ただし、正しく運用されている場合に限る。*1 知っている人はずっと前から知っている事実ではあるんだけど、某巨大SIerなんかでも高い方が安全に決まってる的な残念な脳味噌の持ち主がいっぱいいて「いやあデータの安全性を考えるとRAID-1+0」とか考えもなしにクチにし、そっちの方がディスクがいっぱい売れて嬉しいストレージベンダーもニコニコしながら否定せず売りつけて去っていくといううわなにをす(ry まあそんな感じで。ちなみに正しくない運
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
