そういえば昨日「ピクシブ株式会社」って言おうとして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年6月12日に、拙著　「納品」をなくせばうまくいくーソフトウェア業界の“常識”を変えるビジネスモデル　が発売となりました。 私はこれまで技術者として、そして経営者としてずっと取り組んできたソフトウェア開発の業界を、少しでも良くしたいという思いから、新しいビジネスモデルに取り組んできました。 その取り組みを、今回のような１冊の本にまとめることが出来たことで、より多くの方にソフトウェア開発の世界で起きている問題と、それを解決するためのアイデアの一つとしてのビジネスモデルを知って頂く機会になれば、私にとってもとても嬉しいことです。 本書では、技術的な用語はほとんど使わずに表現することを心がけました。技術者の皆さんだけでなく、経営者やビジネスマンの皆さんにとっても読みやすいものになっていると思います。 ソフトウェアやプログラミングの仕事とは本来は楽しいものであり、そのことをもっと多

merge済みのブランチがいつまでも環境に居座っていると精神衛生上よろしくないのでこまめに消す派なのですが，いちいち手作業でやるのもダルいしコマンド一発ですべてを片付けたいというのが人情と言うものなので，最近ではゴリッとスクリプトを書いてそれを使っています． ここにも同じものを置いてあります． シェル力が低いので，正直これが良いやり方なのかどうかはわかっていませんが，とりあえず動いていて便利なので記した次第．

どもです、nobkzです。昔からずっと考えていることを、うだうだ書きます。 「Prologなんて何でやるんだ!!!」 とある情報系の学生のつぶやきでした。僕は衝撃を受けました。 情報系の人間じゃない僕 ぼくは、福岡のIT系の勉強会に足をよく運び、また主催として開催したりしています。Technical RockstarsにCTOとして就任し、FLOWer言語をTechnical Rockstarsで開発しています。そしていまでは近日中に公開予定のBaaSを開発中であって、LispやHaskell、Prologなどを書いてたりしています。一日中プログラミングの事を考えて生活しています。 そのせいか、他人にはどうも僕が完全に情報系の人間の様に見られるようです。そして、大学では情報系の学部なんだろうと、小さいころからやって来たのだろうと。 しかし、実際は違うのです。僕は九州大学芸術工学部音響設計学

インターネットのほとんどの初心者向けに書かれたと宣言されたコンテンツは、想定すべき初心者のペルソナを失っている。初心者向けの記事は、「これは(俺が想定する都合のいい初心者には)わかりやすい」であり、「実在する初心者」の方を向いていない。習熟すると初心者の気持ちがわからなくなるから、構造的な問題もあるんだけど、それにしても、と思うケースが技術者界隈には本当に多い。 初心者向けと銘打った発表をして、似たようなコミュニティから「わかるわかる、そう説明するよね」的な同意を得られることに満足して終わっているだけで、実際には誰も救っていないの、本当に滑稽だと思う。当人の自己満足と、コミュニティから賞賛を得る以上の価値がない。ネタでやってるケースだけでなく、本気で初心者のつまづきに理解があるよ的な前振りから、突然理解に困る技術的な飛躍が行われるの、やられる方はかなり迷惑で、しかし自分の頭が悪いのを認めた

何度か経験しており、友人からも割りと聞くので、割りと普遍性があると思います。 発注者/ディレクターなど:「いつになったらできるんですか」 プログラマー:「〜というテストを行いました。あとはOKが出ればリリースできます」 上司:「とりあえず持ち帰って検討します」 【持ち帰った後】上司:「で、いつになったらできる？」 プログラマー:「先ほど言ったようにOKが出ればリリースできます」 上司:「とはいっても、OKを出すのは(発注者/ディレクター)だしなぁ…」 あれ、OKを出せる人が誰もいない！

最近書いてるコード、難しいことをしていて、先週からやってるけど、なかなかうまくいかなくて、疲れる。先週うまくいかなくて帰って、週末酒飲みまくったらいろんなことを忘れたけど、朝来たらいろいろ思い出した。うまくいかなくても、とりあえず書くことはできて、気は進まないけど、とりあえず書いてみると、よく考えるとここでこういうことをするのはおかしい、とか気づいて、ちょっと戻ってなんとかしたりする。先に見通しが立たないのに書き始めるのどうかという感じだけど、能力が低くて、計画も立てられないような感じなら、とりあえずやってみるしかない。ソフトウェア作ることに関して言えば、間違ったら戻せるし、戻った時には、こっちはおかしいっていうことが分かってるので、戻った時にはもうちょっとましになってる。ので、とりあえず迷ったら作ってみるほうがよい。そもそも必要な知識が足りないとかなら、地道に勉強するしかないけど、そうで

はてなブログって重いですよね～・・・ ブラウザ変えたら早くなるかなと思ってIE11、Firefox、Google Chromeで計測してみたけど、どれもそんなに差は出なくてどれも遅い（苦笑） いったい何が原因なのかなと調べていったら、JavaScriptのせいでした。 「もふぬこ戦記」のトップページを計測しました。 使用したのはGoogle Chromeのデベロッパーツール。 条件はJavaScriptオン、キャッシュオフです。 12.84秒でした。 次にキャッシュをオンにしてみます。 8.38秒です。 次にJavaScriptをオフ、キャッシュをオフにしてみます。 3.48秒！ キャッシュオンの場合・・・ 746ミリ秒 JavaScriptをオフにするだけでサクサク快適動作します！ 星つけたりできなくなるんですけど・・・（´～｀；） ・・・あれ？JavaScriptエラー出てる気がするけ

GroovyはJavaの上位互換言語であり、インタラクティブシェルがあります。なので実質JavaのREPLとして使えます。 $ brew install groovy $ groovysh Groovy Shell (2.2.1, JVM: 1.7.0_45) Type 'help' or '\h' for help. --------------------------------------------------------- groovy:000> System.out.println("Hello") Hello ===> null groovy:000> import java.util.concurrent.*; ===> [import java.concurrent.util.*;] groovy:000> a = new CountDownLatch(10) ===>

不慣れな環境を不意にいじった時にあるあるネタ。 とりあえずー とか言って勢いで書いたsetupスクリプトを実行してみたら意外と時間かかって、 ちょっと目を離した隙にsshの接続が切れちゃいました！ 。。。ありますよね。ほんとよくありますよね。 そうなる予感はあったんだ なんて後の祭りです。ふとした油断から、screenもnohupすらも使わずにやってしまって、こんなことに。 shellがHUPしなかったからプロセスは生きてるものの、ログが見れないから進行状況がわからない。 うまく行ってるのかどうかモヤモヤした気持ちのまま、プロセスが終わるのをじっと待つ。。。 まぁ実に切ないです。 こんな時、いつも思うこと。 このプロセスの出力、もっかいstdoutに繋げられたらいいのに。。。 はい。というわけでつなげましょう。 長い前座ですみません。 切り離したプロセスを用意 #!/bin/bash wh

感じていた違和感の正体がわかった． レビューにおいて，レビュアーとレビュイーの関係には上も下もない． レビューという場では，両者の立場は対等でなければならない．さもなければ，「このレビューおかしい気がするけれど，あの人は立場が上だから指摘しにくい」だとか，「相手は格下だから適当にレビューしても良い」だとか，そういう良くない雰囲気が形成されてしまう． 確かに，レビュアーというポジションはチームの技術力が高い人やそれに伴ってパワーのある人が担うケースが多いと思う．レビュイーはそれに萎縮してしまいがちというか，僕もその1人なんだけれど，そういうのは実際のところ保身でしかなくて，下手に意見言うとレビュアーとの関係悪くなりそう，みたいな卑屈な理屈に基づく駄目な萎縮な感じがする．こういう良くないところはちゃんと直して，健全化していかなければまずい． あとレビューされた内容は素直に受け入れるべきだと思う

2014-01-15 Test::Base::SubTest というモジュールを作った。またはテストケースとテストコードは分離されていたほうが嬉しい話 perl 自分は Test::Base が好きでよく使うのだけど、subtest 的な、テストのグルーピングができないのがずっっっと不満だったので、Test::Base::SubTest というモジュールを書いた。 https://metacpan.org/release/CSIDE/Test-Base-SubTest-0.1 https://github.com/Cside/Test-Base-SubTest 以下の様な拡張記法が使えるようになる。### でsubtestの 1 単位を表現する。 use Test::Base::SubTest; filters { input => [qw(eval)] }; run_is input =

来る1/10〜12の「第55回プログラミング・シンポジウム」にて「抽象化」をテーマとしたセッションを行います。 セッション概要 「抽象化」をキーワードに、参加者から「知りたいこと」を募集、みんなでそれに対する答えを考えてワイワイする会です。 「知りたいこと」の例 プログラムを書く上でどこまで抽象化するのか？ どうやって適当な抽象化レベルを判断する？ 抽象化する上での適切な言語の選択がある？ 抽象的に考えることをどうやったら習得できる？教えられる？ そもそも「抽象化」って何？ 抽象化のオーバーヘッドはどこまで軽減できるのか？ OSの権限分離のような強制的抽象化と、フレームワークのような強制でない抽象化について、何か違いはあるか？ 抽象化をうまくやる，あるいは抽象的に考えるには，どんな環境・制約があるといいのか？(今回「知りたいこと」という制約を付けたことが具体例。他には？環境の具体例としては