okhttpで非同期リクエストを実行するとき実行スレッドはどうなっているのか - たごもりすメモ
複数のホストに並行してHTTPリクエストを送るコードをJavaで書く必要があって、Undertowをサーバに使ってるんでUndertowの http client でもいいかなーと思ってたんだけど、okhttpにも非同期リクエストの機能があるみたい。 ただパッと見て実行スレッド数の設定とかどうなっとるんや、というのが全くわかんなかったのでちょっとコードを追ってみたところ、以下のような感じのコードを発見しました。 呼び出し順としてはの以下ような感じ。 OkHttpClient.newCall(Request req) Call.enqueue(Callback callback) RealCall.enqueue(Callback callback) client.dispatcher().enqueue(new AsyncCall(responseCallback)); ココ なんで、この
EmacsでJava開発をする @ 2017 - たごもりすメモ
お仕事でそれなりにまとまったJavaのコードを書くので、ちょっと真面目に手元の環境をアップデートしようと思ったらいろいろあったので、メモを兼ねてまとめる。なお手元の環境のアップデートにともない、次のエントリを大きく参考にさせていただきました。多謝。 qiita.com なおそれまでの環境は EmacsでJavaを書く - nekop's blog を元にだいぶ前に整備したもので malabar-mode をずっと使ってたんだけど、Java8 Lambdaでインデントが崩れるとかいろいろあってちょっとストレスフルだったのが主なアップデート動機。 環境は OS X El Capitan *1 + Emacs 25.2 で、全面的に MELPA をつかってパッケージ管理やっている。 結論 最終的には ENSIME (の ENJINEモード) を使っている。これでコンパイルエラーを出すとかメソッド
専門用語を並べてしゃべる専門家は許せない、という人は愚かである、という話 - たごもりすメモ
ちょっと最近腹に据えかねる記事がネットで散見されるので敢えてアレなタイトルで、よろしくおねがいします。 なおこの記事は、自分はソフトウェアエンジニアリングの専門家であるので、そのような領域を大雑把に想定して書かれております。が、たぶん他の専門領域においても似たような状況なのではないかと推察しております。 専門用語ばかり使って会話するような人は本当のプロではない という言説を最近ちょくちょく見ますね。曰く、普通の人に説明できないようではダメだ。曰く、普通の人でも重要性が理解できないように話せないということは、実際にはお前のやっていることは重要ではないのだ。曰く、専門用語ばかりで会話するようでは実際の能力はわからない、専門用語などわからなくても本当に能力がある人にはあるのだ。 んなわけねーだろ。 専門家というのは、非専門家には扱えない問題を扱う専門家だから専門家として働けていて、それなりの待遇
小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメモ
でっかい主語で入ったが、要するに2月にあちこち会社巡りをしたときに感じたことについてつらつら書こう、というのが目的。 特定の会社について書いてもしょうがないので、あれこれ*1回ったうちから少なくとも2〜3ケースで該当するなあ、と思ったことについて書く。特定の1社のみに該当する事項はこのエントリにはひとつも出てきません。 またエントリの主旨からして超上から目線になりますが、どうかご容赦ください。 これから成長が本格化するのでインフラを支えられる人材がほしい 正直に言ってこれが一番多かったパターン。スタートアップ的にサービスを作ってきたがその一方でデプロイや監視などの運用まわりが後手後手になっており、そのあたりを支えられる人物がほしい。 話としてはわかるのだが、気になったのは、これを聞くとき、詳しい内容を突っ込んでみると、どうも実際にはそう困ってはいない、というケースがほとんどだったように思え
#morisnite vol.2 やりました - たごもりすメモ
大人の節度でシャンパン #morisnite pic.twitter.com/0uvS77IKLu— Masatoshi Kawazoe (@acidlemon) February 6, 2015 このたびひと区切りついたところ自宅を埋め尽くさんばかりの勢いで届いたビールが一人で飲んでいる限り賞味期限という制約を突破できないことが明らかであり、みんなで飲もう、ということでまたも主旨不明としか言いようのないイベントが行われました。 #morisnite vol.2 - connpass このようなイベントにこころよく会場をご提供いただいたフリークアウトさん、ならびに調整してくださった @myfinder さん、本当にありがとうございました。 #morisnite はこの会場あってこそです。 というか、よくわからないけどITエンジニアがぞろぞろと酒と食べ物持ってきて好き放題話しながら飲み食いす
DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ
先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を
4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ
今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、
xargs を使ってカジュアルに並列処理 - たごもりすメモ
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい！と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
OSS CEP Server 'Norikra' v0.0.1 released! - たごもりすメモ
みんな大好きFluentdはプラグインも自由に書けて好き放題にリアルタイム集計を行うことが可能なわけですが、やりたい処理にあわせて無限にプラグインを書き続けてるとプラグインの数が爆発し何がどんな処理をしているのかもよくわからず混乱の海に呑まれて消えるという未来がみなさんの脳裏にもおそらく想像されていることと思います。 で、世の中にはCEPエンジンというものがあってストリーム状に流れてくるイベントデータに対して処理を行う仕組みがあるわけですね。これ使いたい！ しかもあれだ、簡単に処理が書けるものがいい！ 何が言いたいかと言うとWE NEEEED xQL!!!!!!!!!!!!!!! そんなようなことをこちらのエントリを書いたときに思ったわけです。 http://tagomoris.hatenablog.com/entry/2013/02/19/142017 で、RubyKaigiにも通っちゃ
本番環境でのperl/ruby/nodeのセットアップ - たごもりすメモ
本番環境にperlとかrubyとかnodeを入れるんだけど、もちろん system perl じゃやってられないので指定したバージョンのものを一般ユーザの管理下に突っ込みたい。 で、そういうのをこれまで perlbrew とか rvm とか rbenv とか nvm とか nodebrew とかでやってたんだけど、さすがに色々疑問が湧いてきた。バッチで単発実行するために eval "$(rbenv init -)" とかさすがにおかしくね？ みたいな。 ということで tokuhirom method 的にインストール用の簡単コマンドを使って実行、あとはパスを通せばいいじゃん、ということにしようかと思う。 参考: サーバーのセットアップは perlbrew とかじゃなくてよくね? という時のライフハック - blog.64p.org これ、今朝までは Perl::Build をどうにかしてC
GrowthForecastのJSON APIおよびクライアントライブラリについて - たごもりすメモ
雪にかこまれた温泉宿からこんちには。 クライアントライブラリを書いてからblogエントリにしようと思ったらこんな素敵エントリを書かれてしまった、くやしい……！ GrowthForecastでAPI使って複合グラフ作ったり、グラフの色を変えたりしてみた - mikedaの日記 みんな大好き GrowthForecast ですが、じつに簡単にグラフを作れてしまえるので調子に乗って作りまくった挙句、複合グラフを作る手作業で死んだり色を揃える作業で死んだりそもそも無いといけないグラフが本当にあるのか確認するのが面倒でうっちゃってたりするようなことがあります。必ずあるはずです。ですよねー。あるある。 ということでグラフの存在を確認したりグラフ設定を変更したりそもそも無ければ作ったり、という作業をコードからやりたかったので、ひとそろい作った。とりあえず GrowthForecast に JSON AP
CDH4 NameNode HA (QJM)でクラスタ構成 - たごもりすメモ
CDH4と延々格闘してたが、ようやくひととおり設定が終わったのでまとめ。 特にNameNode HA QJM版はドキュメントもけっこうグチャグチャで何をどうすればいいのかの把握が困難だった。また Auto Failover は設定するとマトモに動かなかったので無効にした。そのうち調べてもいいけど、実運用上も特に要らなそうだし、まあいいかな、と。 で、手順と設定のポイントについていくつか。なおNameNode Federationは使ってないので知らん。使うならクラスタ名の指定とかに影響があるはず。 セットアップ順序 基本的にはこのドキュメントを読む。 Redirecting... が、通常のセットアップとの関係やどういう順序で全体を進行すればいいかがいまいちちゃんと書いてなくて不明なところが多い。簡単に概要をまとめると以下のようになる。パッケージ名はyumでのものなので適当に読み替えを。
さくら石狩DC見学ツアーに参加してきた - たごもりすメモ
聞いたところによると40名の枠に150名の応募があったらしいが、幸いにも参加できたのでいってきた。 最新鋭データセンターの施設に萌えるべき！ さくら石狩DC見学ツアー - はてなニュース 人生で初めて北海道に行ったんだが、正直に申し上げてめちゃくちゃ楽しかった。ありとあらゆるものに価値があった。見たものも聞いたことも食べたものもすべてすばらしかった。DC見学もその前後もすばらしく丁寧にご案内をいただいた。 さくらインターネット様、特に社長の田中さんと広報の櫻井さん、またはてなやJTBの皆さん、本当にありがとうございました。 と、忘れないうちに御礼まで書いたので、あとは適当に見たものや聞いたことについて書く。こと細かなことは誰かが書くだろうからそれを見てもらうとして、印象に残ったことをあれこれ。写真は自分で撮ったものと、ツアー主催側から提供いただいたもの。 石狩DCまわったあれこれ 着いたら
#fluentd でアクセスログからメトリクス生成/リアルタイム監視するための設定例 - たごもりすメモ
このエントリは ウィークリーFluentdユースケースエントリリレー の参加エントリです。 いろいろアレでアレなときに回ってきて新ネタを思い付く余裕がないので、手元の設定を晒して解説しお茶を濁そうと思います。ユースケース！ 前提は以下の通り。 アクセスログ このサーバに送られてくる前の段階で適当にparseされている(いちおう in_file の apache 互換の名前のはず？) sampling_filter プラグインにより 1/1, 1/10, 1/100 それぞれの割合でサンプリングされている(基本は1/10) いくつかのメトリクス計算を行い、それらをGrowthForecastへグラフ登録、一部のものはリアルタイム監視を行いIRC通知する ping message ping_message プラグイン(および fluent-agent-lite の -P オプション)による p
Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ
Perlでコマンドラインオプションをparseしようと思うと組込みモジュールとしては Getopt::Std と Getopt::Long がある。が、long style option *1 つまり --option-name のようなオプションを解釈してくれるのは Getopt::Long だけだ。なので普通はこちらを使おう。 ただし 絶対にデフォルト、つまり以下のようにして使ってはいけない。 use Getopt::Long; my (@primary, @secondary, $silent); GetOptions( "server-primary|p=s" => \@primary, "server-secondary|s=s" => \@secondary, "silent|S" => \$silent ); これダメ！ 絶対ダメ！ 死ぬ！ 最初に結論を書く 必ず以下のように
PerlでSTDIN/STDOUTを任意のファイルハンドルに置き換える - たごもりすメモ
いま書いてるコードで、forkしてexecするんだけど、execする前にSTDIN/STDOUTを任意のファイルハンドルに置き換えたいなー、もっというとexecするプログラムのSTDINにソケットのREADから流れてくるデータを流し込んで、STDOUTの出力をソケットのWRITEに流し込んでやりたいなー、というようなことを考えていた。 で、これが例えば今のプロセスのSTDOUTの出力をファイルに置き換えるには、以下のようにすればいい。 open(STDOUT, '>', '/path/to/file'); シェルスクリプトでも簡単。*1 exec >> /path/to/file さて、STDIN/STDOUTとconnect済みのソケットを結合したい。connect済みのソケットはファイルディスクリプタは持っているがファイルパスを持っていない、ので、普通にopenし直すだけではうまくいか
#fluentdの死活監視を ping message + ping message checker で - たごもりすメモ
先日のFluentd meetup #2からこっちFluentdの監視熱が高まっている昨今ですが、みなさんFluentdの監視してますか。暑いですね。 ところで監視といえばプロセス監視とかは当然やってたんですが、まあやっぱりメッセージ飛ばしてみて実際に飛ぶかどうかとか確認したいよねって思いますよね。当然ですよね。 で、当日調子に乗って out_ping_message を書いたものの、いざFluentdの各プロセスからpingを流してみたら毎分数十以上のメッセージが流れてきてファイルに書いても1周目の目視確認すら困難な状況になったので、ちゃんとping message到着してるか(正確には到着しなくなっちゃったものが無いか)をチェックしてくれる out_ping_message_checker を書いて fluent-plugin-ping-message に追加しました。 fluent-
Hadoopクラスタでulimitを設定するときの注意点 - たごもりすメモ
Hadoopクラスタを運用する際に ulimit で nofile (プロセスがopenできるファイルディスクリプタ数の上限)の設定を変更しておくべき*1というのはもはや常識的なお話ですが、そこには実は罠がある。たぶんRHELのデフォルト通りならハマらないんだろうけど、手を入れている環境だとハマる。ので、その話。 要するにハマった。のを解決したよ多分！ まだ最終的な確認できてないけど！ 各書籍での解説 とりあえず、国内で売られているHadoop関連書籍の記述を確認しておこう。まずHadoop徹底入門。 ファイディスクリプタの設定は、/etc/security/limits.conf に記述します。エディタを利用して、limits.conf に以下のように記述します。ここでは、Hadoopの各種ノードを起動するユーザーを hadoop とします[12]。 hadoop soft nofile
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
