Bind Peek をもっと使おうぜ！(柴田 歩) - JPOUG Advent Calendar 2014(Day 5) -歩 柴田
5.6 以前の InnoDB Flushing
Bind Peek をもっと使おうぜ！(柴田 歩) - JPOUG Advent Calendar 2014(Day 5) -歩 柴田
PDLで数値計算 - Articles Advent Calendar 2012 Casual
こんにちは、週末海でマンボウを獲っていたらラギアクルスに襲われた@hirataraです。今回はPerl Data Languageについて紹介します。 Perl Data LanguageとはMATLABやNumpy、Rなどと同様に、多次元配列を効率よく扱って数値計算を実現するためのライブラリです。cpanmで普通にインストールすれば使えますが、グラフを描画したり本格的な数値計算のライブラリであるGSLのバインディングを利用したりする場合はhomebrewでゴニョゴニョしたりする必要があるので、多少頑張って下さい。 基本的にはpdl関数でオブジェクトに変更してから使います。 use PDL; my $pdl = pdl [[1, 0, 0], [0, 1, 0], [0, 0, 1]]; print $pdl; 【実行結果】 [ [1 0 0] [0 1 0] [0 0 1] ] pdlが
Ansible 1.9がリリースされました — そこはかとなく書くよん。 ドキュメント
Ansible 1.9がリリースされました¶ 2015年3月25日にAnsible 1.9がリリースされました。結構な量が追加・変更されていますので、ここでリリースノートを訳してみなさまのお役に立てればと思います。 基本的に互換性が確保されていますので、playbookを書きなおす必要はないと思います。ただし、gitモジュールなどのバージョン管理システム用のモジュールでローカルに変更があると失敗するという、安全側に倒した変更がされていますので、その点でplaybookを変更する必要があるかもしれません。 なお、1.9は1系の最後のリリースとなります。大幅に書きなおされたAnsible 2.0は近いうちに出る予定です。 リリースURL: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md#19-dancing-in-the-s
Big Sky :: Re: Go で channel が close してるかどうか知りたい というアンチパターン
« golang のパッケージが Google Code に依存しているか調べるコマンド作った。 | Main | C++ 向けの扱いやすい json ライブラリ μjson » Goでchannelがcloseしてるかどうか知りたい というアンチパターン - beatsync.net そもそもGoのchannelがcloseしてるかどうかを知りたいっていう理由は、だいたい「Goのchannelはナイーブだから」というところに起因するのはないかと思います。 https://beatsync.net/main/log20150325.html golang には元々 closed() という、channel が閉じられているかどうかを返す組み込み関数がありました。しかし廃止されました。 closed は API としては目的を達成出来ているのですが、builtin が1つ増える、channe
[java] モダンな Annocation Processor の開発手順まとめ - tokuhirom's blog
APT とは Annotation Processing Tool のことで､Java でコードの自動生成を行う際に利用される｡ APT を利用すると､Java クラスやリソースの自動生成が可能となる｡ インターネットに情報は結構あるのだが､昔のものが多くて､Eclipse に JAR を追加して云々とかそういう感じのものが多くて辛いので調べたことをまとめておく｡ アノテーションを作る 適当なアノテーションを作る｡ import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention(RetentionPolicy.SO
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
