タグ

ブックマーク / kazuhooku.hatenadiary.org (13)

  • direnvを使って実行環境(perlとか)の切り替え - kazuhoのメモ置き場

    plenv の話を聞いていて、別解もありそうだなと思ってググったらあった。以下手順 direnv をインストールする .bashrc あるいは .zshrc の末尾に "eval `direnv hook $0`" と書いておく 適当なディレクトリに perl とかをインストールする 実行したいディレクトリに .envrc ってファイルを作って "PATH_add <上のディレクトリ名>" とか書いておく こうすると、cd すると自動的に .envrc の内容がロードアンロードされて、適切なスクリプトが起動されるようになる。 プロダクション環境で使う場合は、上記 2 のかわりに "direnv exec <プログラム>" とか書いておくと、ディレクトリ依存の環境設定をロードしてからプログラムを起動してくれる。

    direnvを使って実行環境(perlとか)の切り替え - kazuhoのメモ置き場
  • OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい(もしくはコードレビューの話) - kazuhoのメモ置き場

    以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G

    OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい(もしくはコードレビューの話) - kazuhoのメモ置き場
    cu39
    cu39 2014/03/13
  • テストファーストなGitワークフローについて - kazuhoのメモ置き場

    Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス(の部品)やオープンソースプロジェクトです。 まず、以下の2点を原則として考えています。 origin masterを壊さない origin masterの(1st parentをたどるツリー)にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ

    テストファーストなGitワークフローについて - kazuhoのメモ置き場
    cu39
    cu39 2014/02/04
  • 「今日使われているプログラミング言語の多くは、なぜ1990年前後に誕生したものなのか」に関する一考察 - kazuhoのメモ置き場

    若い人たちは、「文字列型」があるプログラミング言語しか知らないかもしれない。だが、汎用的な文字列型が一般的になったのは、プログラミング言語の歴史の中でも比較的最近のことである。 たとえば、1972年に誕生したC言語には文字列型がない。1980年代に良く使われていたPascalの文字列型は最大255文字しか格納できなかった。 なぜか? それはメモリが貴重なリソースだったから。 1980年代のPCの搭載メモリは多くて数メガバイト。これに対し、長編小説の長さは1MB程度に達する*1。 当時、メモリはとても貴重な資源であり、テキストを処理するプログラムを開発するにあたっては、文字列をどのようにメモリ内に展開するかプログラマが細かくコーディングする必要があった。 だから、汎用的な「文字列型」というのは「夢」にすぎなかった。CあるいはPascalにおける文字列(CのASCIIZ文字列あるいはPasca

    「今日使われているプログラミング言語の多くは、なぜ1990年前後に誕生したものなのか」に関する一考察 - kazuhoのメモ置き場
    cu39
    cu39 2013/12/22
  • パスワードをソルトつきハッシュ化してDBに保存するのがベストプラクティス…とは限らないという話 - kazuhoのメモ置き場

    フレームワークの責務とセキュリティ - MugeSoの日記についての感想文です。 世の中にはたくさんの通信プロトコルが存在し、中には、特定の条件でパスワードを含む文字列をハッシュ化した値を検証しなければならないものも含まれています。 例えば、HTTP Digest認証の場合は、MD5("realm:user:password")を保存しておく必要がありますし、APOPの場合は生のパスワードを、CRAM-MD5の場合はMD5("password")を保存しておく必要があったはず。 で、こういった様々なプロトコルに対応可能な認証データベースを準備しようとすると、パスワードを復号可能な方式で保存しておく必要があります*1。 ただ、パスワードを復号可能な方式で保存するとか、開発者あるいは管理者としてやりたくないというのはもちろんそうなので。で、長期的には世の中どこへ向かってるかというと: 選択肢a

    パスワードをソルトつきハッシュ化してDBに保存するのがベストプラクティス…とは限らないという話 - kazuhoのメモ置き場
    cu39
    cu39 2013/11/19
  • 30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場

    「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので3分で書く。 オープンソースライセンスは、以下の3種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い(そしてどちらを選んでも問題ない)。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ: ライセンスの解釈については、

    30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
    cu39
    cu39 2013/10/04
  • 巨大な bookmarklet を信頼できる形で配布する方法 - kazuhoのメモ置き場

    Twitter で聞いてみたところ @hasegawayosuke さんいわく、Bookmarklet の文字数制限は最短だと約2,000文字らしいです。 でも、その長さで bookmarklet を書くのって難しいですよね。かといって、別のサーバから JavaScript をダウンロードして実行するとなると、そのダウンロードされたスクリプトが安全か、という問題が出てきます。 ならば、暗号学的ハッシュ関数を2,000文字以下で実装し、ダウンロードしたスクリプトの改ざん検証を行った上で実行すればいいのではないか。そうすれば、文字数の制限に悩むことなく Bookmarklet の開発に勤しめるのではないでしょうか。 ジャジャーン!というわけで、とても短い SHA-1 の JavaScript 実装を作りました*1。 GitHub - kazuho/sha1.min.js: SHA-1 impl

    巨大な bookmarklet を信頼できる形で配布する方法 - kazuhoのメモ置き場
  • JSX はなぜ「速い」のか - kazuhoのメモ置き場

    なぜ「速い」のか、について JSX 開発者の立場から。 たとえば、シューティングゲームで一番重たい処理は何か。言うまでもなく衝突判定。多数の弾や敵機の衝突判定を毎フレームごとに行う必要があり、この演算が重たい。 JSX に同梱されている web/example/shooting.jsx には衝突判定のコードが複数あるが、一番重たいのは Bullet#update 関数で、その処理は以下のようになっている*1。 for (var rockKey in st.rocks) { var rock = st.rocks[rockKey]; if (this.detectCollision(rock)) { if (rock.hp == 0) return false; inDisplay = false; if (--rock.hp == 0) { st.score = Math.min(st.s

    JSX はなぜ「速い」のか - kazuhoのメモ置き場
    cu39
    cu39 2012/06/03
    インライン展開。
  • node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場

    node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre

    node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場
    cu39
    cu39 2012/04/20
  • TwitterやFacebookのURLには、なぜ#!が含まれるのか (SEOとAjaxのおいしい関係) - kazuhoのメモ置き場

    Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UISEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started  | 

    TwitterやFacebookのURLには、なぜ#!が含まれるのか (SEOとAjaxのおいしい関係) - kazuhoのメモ置き場
    cu39
    cu39 2010/10/13
  • 海外のクラウド環境と国内のVPSを比較検討してみた - kazuhoのメモ置き場

    Amazon EC2 や Rackspace Cloud Servers を色々調べていて分かったこと。 国内の比較対象は、仕事や個人で使っている WebARENA SuitePRO と CPI VPS スケーラブルプラン。 まず、価格について。国内の VPS は、転送量に関わらず価格が一定なのに対して、EC2 や Cloud Servers は、サーバ代金の他に、従量制のネットワーク使用量がかかる。なので、運用するサービスによっては、海外勢の方が割高になる *1。一方、通信量が少ない場合は、割安。 では、海外のクラウド環境でしか得られないサービスとは何なのか。 L3 ロードバランシング サーバレンタルが月単位か1時間単位か*2 借りた仮想サーバ間の通信を前提としているか の3点っぽい。逆に言うと、これらの機能を必要としないなら、国内 VPS でいい。 3点目は、国内の VPS サービスで

    海外のクラウド環境と国内のVPSを比較検討してみた - kazuhoのメモ置き場
    cu39
    cu39 2009/08/28
  • mysql と drizzle の負荷テストツール「skyload」が凄い! - kazuhoのメモ置き場

    tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql

    mysql と drizzle の負荷テストツール「skyload」が凄い! - kazuhoのメモ置き場
  • NanoA というウェブアプリケーションフレームワークをかいてみた - id:kazuhookuのメモ置き場

    CGI というシーンにおける現状の Perl のウェブアプリケーションフレームワークの問題点とは 都度 perl のインタープリタインスタンスを起動するのでモジュールの読みこみ/コンパイルコストを無視できない bless の速度を無視できない といったあたりであると認識している。 http://d.hatena.ne.jp/tokuhirom/20081111/1226418572 自分は、Sledge も Catalyst も Mojo も Rails も boofy も使ったことがありませんが、別に必要なモジュールをロードしたり bless したりするのはしょうがないのかなと思います。ただ、 不要なコントローラ (+それに伴う多数のモジュール) までロードしている ということが一番の問題なのかなと思いました。というわけで作った。 CodeRepos の /lang/perl/NanoA

    NanoA というウェブアプリケーションフレームワークをかいてみた - id:kazuhookuのメモ置き場
  • 1