タグ

2014年11月30日のブックマーク (5件)

  • Goと大規模分散システムの相性 - ワザノバ | wazanova

    Googleで分散システムの開発をてがけ、現在はソーシャルメディア mttr.toを立上げ中のBen Sigelmanが、Goを分散システムの開発に利用する場合の、メリットおよびチャレンジについて講演しています。 分散システムのあるべき姿 分散システムの勘所は、最上位ビットをパフォーマンス的にも構造的にもうまく扱うことができるかというのがポイント。その効果が一番大きい。スループットの改善のような詳細は、自分もGoogleでそれに取組んだけれども、9ヶ月くらいたつとハードウェアの性能で解決される可能性が高い。また、構造的にというのは、なるべく小さなコンポーネントを組み合わせたシステムにできるかという意味。 Goのよいところは、 両方、とくに後者によい。Railsだとアプリを複数個用意して並列処理するのは大変だったけど、Goだとシンプルにできて、標準ライブラリも読みやすいとかなどなど。パフォー

    teppeis
    teppeis 2014/11/30
    「分散システムでは複数のメンバが開発に関わるため、自分が全てのコードを把握してない状況になる。そこで、静的型付け言語のメリットは大きい」わかる
  • Documentation - Materialize

    flash_on Speeds up development We did most of the heavy lifting for you to provide a default stylings that incorporate our custom components. Additionally, we refined animations and transitions to provide a smoother experience for developers. group User Experience Focused By utilizing elements and principles of Material Design, we were able to create a framework that incorporates components and an

  • vimrcアンチパターン - rbtnn雑記

    この記事はVim Advent Calendar 2014 - Qiita1日目の記事です。 今回は、もう130回も続いているvimrc読書会でよく見られるvimrcのアンチパターン、 まぁ「これは気を付けたほうがいいんじゃない」的なことを私なりにまとめてみようと思う。 vimrcの文字コード Vim scriptにはscriptencodingという現在のVim scriptファイルの文字コードを指定するコマンドが存在します。 一般的にscriptencodingはマルチバイト文字を使う前に宣言します。マルチバイト文字を一切使っていない場合、特に宣言する必要はないでしょう。 なので、マルチバイト文字をvimrc内で使用する場合(コメント内でマルチバイト文字を使用する場合も含みます)、vimrcの先頭で宣言するのがいいでしょう。 悪いパターン " ミュートにする。 set t_vb= se

    vimrcアンチパターン - rbtnn雑記
    teppeis
    teppeis 2014/11/30
  • 10 Examples of HotSpot JVM Options in Java

    There are hundreds of JVM parameters or JVM Options exists inside sun JDK and its virtually impossible to keep track of every single JVM option and based on my experience we don't even use most of JVM flags except a couple of important JVM option related to java heap size, java options for printing garbage collection details and most likely JVM switches for setting up remote debugging in Java. but

    10 Examples of HotSpot JVM Options in Java
    teppeis
    teppeis 2014/11/30
  • タスク・ランナーをnpm run-scriptでラップ

    npm で依存もタスクも一元化するという記事を興味深く読んだ。僕もしばらく前、具体的にはnpm v2出た時からGruntをnpm run-scriptでラップして使っている。概ね良好に機能すると感じている。懸念であった引数で特定の処理を行わせたいようなケースもnpm v2で引数を解釈できるようになったので解決した。 npm run-script経由にすることによる大きなデメリットとしては、そんなに速くもないnpm経由で常にタスクを実行することによる速度の低下が挙げられる。 この速度の低下は、Gruntやgulpの主要な目的であるビルドにおいてはそれほど問題にならない。ビルドにかかる時間に比べると、相対的にその低下の割合は低いものだと考えられるからだ。しかしタスクはそういったものにとどまらず例えばHTML(やMarkdown)のプレビューであったり、Sassのオンデマンド・コンパイルといった

    タスク・ランナーをnpm run-scriptでラップ
    teppeis
    teppeis 2014/11/30