実行中のプログラムの進捗度を手っ取り早く確認したい - その手の平は尻もつかめるさ
完了するまでに結構時間がかかるプログラムを実行している時，そのプログラムの進捗度を確認したくなることがままあると思います．ほんとに動いてんのかお前，みたいな． そうした時に考えうる最も簡単な方法は，こんな感じで進捗度を標準出力に流してしまうという方法でしょう． (1..100).each do |i| # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例) sleep 0.1 # ここで進捗を表示 (プログレスバーみたいなもっとリッチな感じでも可) puts "#{i}%" end 簡単なものだとこれで良いでしょうが，途中で端末のセッションが切れると「アッアッ」という感じになったり，そもそもプログラムの実行に際して端末が割り当てられいるとも限らないし，というか時間のかかるプログラムがその処理中ずっと端末を占領しているのはつらいので別の方法が欲しかったりします．
トークナイザーとパーザーについて，結合するということについて - その手の平は尻もつかめるさ
トークナイザーとパーザーについて，それに準ずる物を書いていて，その最中ふと思った事について記す． トークナイザー書くよりもパーザー書く方が圧倒的に労力が高くて，そのパーザー書く苦労を軽減するためにトークナイザーを弄って後段のパーザーの理解を助けるような小細工を始めるんだけど，そうするとトークナイザーとパーザーが密に結合し始めてああああああ、という感じになる— moznion (@moznion) 2014, 11月 11 トークナイザーとパーザー，直交してた方が良いのかどうかわからなくなる— moznion (@moznion) 2014, 11月 11 @moznion シンプルなケースだと直行してたほうがベターだけど、そうじゃないとある程度結合したほうがらくなイメージあります— tokuhirom (@tokuhirom) 2014, 11月 11 一般的に考えて直交してたほうが良いん
CUDAで特定の条件に合致したGPUのIDを持ってきたい - その手の平は尻もつかめるさ
CUDAで，特にマルチGPUプログラミングなどをやっておりますと，特定の条件に合致したGPUのIDを持ってきたいという要求に高確率でぶち当たる事となると存じます．俺はぶち当たる． GPUがマザーボードに5枚刺さっていて，そのうち4枚は映像のアウトプット端子がないGPGPU専用の板で，残る1枚は映像を出力するためだけの貧弱なボード，という構成のサーバはこの世の中少なくありません *1． そうした構成の時に，不慮の事故によりcudaSetDevice()によってGPGPU専用のグラボではなく映像出力専用の貧弱な板がアサインされてしまったばかりにパフォーマンスが死ぬほど落ちて死ぬ，というのは割とよくある事例であります．そうした事故は未然に防がなくてはなりません． 原因を考えてみましょう． なぜこういう悲しい事故が起こるかと言うと，cudaSetDevice()に食べさせるGPU IDをハードコー
ページャNight 1ページ目という勉強会やりました - その手の平は尻もつかめるさ
そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前
「メソッドに対してテストをするな」という話題について - その手の平は尻もつかめるさ
―「間違っているかもしれないので，その時はこの銃で僕を撃ってくれ，良いね？」 [2014-05-19T17:48:28Z 追記] http://a-suenami.hatenablog.com/entry/2014/05/17/131326 補足してもらったので読むと良いと思います． わかっちゃはいたけれど上手く言語化できていなかった部分，あるいはわかっていない部分について言及されていたので参考になりました．ありがとうございます． いやーつーかさー，「『メソッドに対するテスト』っていう言葉自体がわかりにくくね？」っていうのはその文言を見たり，この文章書いている間もずっと思ってて，つまり端的に言うとそういう事を言いたかったはずなのに，今このエントリ読み返すとそうした[趣主]旨から完全にズレててメッチャ違和感あるな！ ってなりました．俺のバカ！ これを仮に言い換えるとしたら「内部構造に対するテ
Ukigumo入門 ― 2014年スタイル - その手の平は尻もつかめるさ
とりあえずデモサイトを示しますので適当に見て下さい． http://ukigumo.moznion.net/ さて今回はゆるふわCIシステムであるところのUkigumoのナウいスタイルについて説明しようと思います． ここ最近ではUkigumo::AgentというAgentサーバが存在しており，これを使うとまあ便利なんですけれども，ドキュメントが少ない為か *1 あまり利用されている事例を見かけませんので，それらも踏まえて解説したい感じです． まずUkigumoとは何か CIシステム．Perl製． Perl製だが，もちろん他言語のプロジェクトでも使える． Travisのようにサービスとして提供されている感じではなく，自前でインストールして使う． 多分，感覚としてはJenkinsに近いと思うが，そこまで複雑ではなく，シンプル． 基本的に，「テストの実行及びその結果の取得」と「テスト結果の保存」
tmux 1.9系でもcurrent pathの情報を引き継いでnew-windowやsplit-windowしたい - その手の平は尻もつかめるさ
去る2014年2月22日にtmux 1.9がリリースされたので勇んでアップデートしたところ，1.9からはdefault-pathオプションが削除されており，またそれが原因かどうかは定かではありませんが *1，new-windowやsplit-windowするとcurrent pathの情報を引き継いで *2 くれなくなってめっちゃ不便！！！！ ってなって，「これもう1.9にアップデートしなくても良くね？？？ CHANGES見てもこれといった変更ないし……」という心意気に一時はなったんですが，僕みたいな糞ミーハーはやっぱり新しいものを使いたいのでちょっと調べてみました． 結論 bind '"' split-window -vc "#{pane_current_path}" bind '%' split-window -hc "#{pane_current_path}" bind 'c' ne
Hokkaido.pm #11に参加した報告とTestとDocumentの甘い関係に関して - その手の平は尻もつかめるさ
Hokkaido.pm #11に参加してまいりました． 以下が僕の発表スライドです． Hokkaido.pm #11 from moznion 言いたいことは大体スライドに書いてある通りで， TestとDocumentは同じ方向 (どちらも正しいソフトウェアの動作について論じている) を向いている 従って協調できるのではないか 協調するメリット Documentの不整合や陳腐化を防げる DocumentとTestをそれぞれ別個に書くよりもコストを低減出来るかもしれない 方法は2つあると思う Documentにテストケースを埋め込む方法 TestからDocumentを生成する方法 という感じです． “TestとDocumentを同居させる方法”というのは割と以前からある考え方っぽくて，PythonではDoctestというテストモジュールが一般的なようですし*1，JavaScriptにおいては
Test::JsonAPI::Autodocをリリースしました - その手の平は尻もつかめるさ
Test::JsonAPI::Autodocをリリースしました． https://metacpan.org/pod/Test::JsonAPI::Autodoc https://github.com/moznion/Test-JsonAPI-Autodoc これは何 Ruby (RSpec) にはautodocという，@r7kamuraさんが書かれたクールなモジュールがあって， これが何かと言うと，JSON APIのテストを記述するとそのリクエストとレスポンスに応じて 自動的にそのAPIのドキュメントを生成してくれるという大層便利なモジュールです． 「テストを書くとドキュメントが出来る」という発想は最早発明と言っても過言では無いでしょう． autodocにまつわる情報は以下を参照頂いた方が詳しくて良いでしょう． r7kamura/autodoc 体育の日って高速に唱えるとテストの日に聴こえ
YAPC::Asia Tokyo 2013 でトークしてきました - その手の平は尻もつかめるさ
YAPC::Asia Tokyo 2013 で、「CPAN Testers Reports の情報を上手に使う」というタイトルでトークして参りました。 YAPC::Asia 2013 - CPAN Testers Reports の情報を上手に使う from moznion 序盤は CPAN Testers Reports の概略みたいなのの説明だったので、 「これ、大体の人が知ってるだろうから、もしかしたら退屈かもなあ……」 と思っていたんですが、このトークの後に 「Testers Reports、知らなかったけど便利で良いっすね！」 とか 「Ruby にも欲しい！」 とか言ってくださった方がいらっしゃったので、まあそこは喋ってよかったかな〜と思いました。 (ちなみに、Testers Reports の Ruby 版みたいなのは存在しますが、現在機能していない感じです) (恐らく近日中に
はてなインターン2013に参加して参りました、そして与太話がしたい - その手の平は尻もつかめるさ
幸運にもはてなインターン2013に参加する機会に恵まれましたので、謹んで参加して参りました。 「参りました」っていうのは、「精神的に参ってしまいました」とかそういう意味合いではありません。謙譲語です。 (非常に遺憾な事に、他のインターン参加者のブログを見ると、僕が精神的に参っている人のように描かれているので) さて、本エントリの前半でははてなインターンの全般の話を取り上げます。が、このへんは他のインターン参加者のブログの方が詳しいし丁寧だと思うので、そちらを読むと良いでしょう。本エントリではできるだけ技術的な部分 (というか、開発プロセスのあたり) に触れて行きたいと現時点では考えていますが、スピリッチャルな内容になるかもわかりません。 エントリの後半は与太話です。それは例えばソフトウェアエンジニアの話かもしれないし、漫画家の話かもしれないし、サラリーマンの話かもしれないし、あるいはそう、
Perl の Package 書くときにめちゃめちゃ便利な Vim スクリプト書いた - その手の平は尻もつかめるさ
世の中の Perl の Package の末尾には大体 `1;` って書いてあって、これが何か言うと「このモジュールは真値を返していますよー」という表明で、まああけすけに言うとこれが記述されていなければ、そのモジュールは use とかされた時に不正なモジュールとして扱われてしまい、読み込みが 失敗してしまう訳です。 さっきも言ったように、返す値は真値であれば何でも良いので、`42;` って書いたり `"HELLO";` って書いたりしても別に良い。 で、世の中には `!!1;` っていう面妖な記述をしているモジュールがあって、人が泣いている。 `!!1;` は、1 という真値を ! によって偽値にして、さらにそれを ! する事によって真値にすることによって、真値であることを表明している。 これでも問題なく動くけれど、`!!1;` って初見の人はびっくりしてしまうし、そもそも2回も否定演算し
bless と Mouse、あとClass::Accessor::Lite でオブジェクトを作る際の性能比較 - その手の平は尻もつかめるさ
巷で「爆速！ ヤバすぎ！」と目下話題の Mouse ですが、「bless でオブジェクト作るよりも速い」という風なことがちらほら聞こえて参りましたので、そこら辺を比較してみました。 今回は生 bless と、Mouse、そして参考として Class::Accessor::Lite の3つを比較しました。 なお、Perl のバージョンは 5.16.3、Mouse のバージョンは1.11、C::A::Lite のバージョンは0.05 でお届けして参ります。 比較に利用したのは以下のコードです。 かくして結果はこのようになり、流石に bless よりも速いという結果は得られませんでしたが、Class::Accessor::Lite よりかは高速ということで Mouse すごい、という感じですね。 しかしながら、上記のコードを以下のように書き換えると (わかりにくい！ との指摘を受けましたので補足
職質テックトーク #07 やります - その手の平は尻もつかめるさ
明日、8月14日 (水) の 20:00 くらいから職質テックトークの#07 をやります。 ゲストは、YAPC で はてなのサーバ管理ツールの話 というタイトルでトークされる @y_uuk1 さんです。 はてなのサーバーまわりとか皆さん興味をお持ちでしょうから是非お聞き頂ければと思います！ ？？？「それはそうとPodcast の更新が滞ってるんだけど？」 すみませんすみません、目下作業中です。いつもと違うDAWで編集作業を行なっており、非常に難渋している状態です。今しばらくお待ちください。 第2回 (@songmu さんの回) が Podcast から消えている件 なぜ消えているのか理由がわからなかったのでAppleに問い合わせていますが、返答が無くて悲しい思いをしております。 詳しいことが分かったらお知らせするか、あるいはお知らせするまでもなく直っていると思います。
Provisioning Frameworks Casual Talks vol.1 に参加してきました - その手の平は尻もつかめるさ
Chef とかChef-Solo とかを最近触っていて、知見を広めたいというモチベーションがあったので、 Provisioning Frameworks Casual Talks vol.1 に参加してきました。 講演の内容としては以下の通りです。 @fujiwara さん - 新卒研修でserverspecとChefを使った話 http://dl.dropboxusercontent.com/u/224433/pfcasual_1/index.html @antipop さん - 宣伝Puppet Book https://speakerdeck.com/kentaro/puppet-book @naoya_ito さん - 入門 Chef Solo 落ち穂拾い https://speakerdeck.com/naoya/ru-men-chef-sololuo-tisui-shi-i @
PhantomJS + QUnit (with qunit-tap.js) + prove を使ってJavaScript のテストをTAP で回す - その手の平は尻もつかめるさ
QUnit とTAP を用いた JavaScript のテスト環境構築の話です。 前提として、QUnit でテストを実行出来る環境が構築できていることとします。 QUnit の実行のやり方等は以下のエントリが詳しくてマジ最高なので、ご参照下さい。 QUnitの基本的な使い方 - Block Rockin’ Codes さて、今回例として扱うディレクトリの構成としてはこんな感じです。 . ├── lib │ ├── qunit.css │ └── qunit.js ├── main.js ├── test.html └── test.js main.js: テストの対象となる JavaScript ファイル test.html: テストの結果を表示するための html ファイル test.js: JavaScript のテストコード lib以下: QUnit 本体 この段階でtest.htm
cpanfile 向けのVim 拡張を書きました - その手の平は尻もつかめるさ
cpanfile が書きやすくなるかも知れないVim 拡張を書きました。 「書きやすくなるかも知れない」ってことは「書きやすくならないかも知れない」って事です。 深淵ですね。 プラグインたち https://github.com/moznion/vim-cpanfile https://github.com/moznion/syntastic-cpanfile 何ができるのか vim-cpanfile cpanfile キーワードの自動補完 (neocomplcache に依存) シンタックスハイライト syntastic-cpanfile シンタックスチェック (syntastic に依存) ハウトゥユーズ インストール NeoBundle 'moznion/vim-cpanfile' NeoBundle 'moznion/syntastic-cpanfile' 的な感じで。他の管理シス
Perl Beginners #6 に参加して参りました - その手の平は尻もつかめるさ
いつの話だ！！！ *1 今回はJPA 代表の牧さん (@lestrrat) が特別講師 *2 として来られていました。 Q&A セッションとして、1時間牧さんに自由に質問して牧さんがそれに答える、というスタイルで進めていました。 以下まとめ 牧さん (Q&A セッション) コードのコメントは英語で書くのか、日本語で書くのか GitHub とかにアップするコードは英語 仕事で書くコードの時は、日本語で書いたりもする 結局、その「ソースを読む対象」による CPAN モジュールのひな形を作るモジュールは何を使っているのか 何も使わない XS の時はオレオレひな形を使う ライブコーディングで実証 "makamaka" を"nakanaka" に書き換えるモジュール マジで何一つ使っていなかった！！！ XS は本当に面倒臭い XS モジュールを書きたいんだが、何か良い教材は無いか 「モダンPerl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
