Linux の top コマンドや free コマンドで表示される cached は、勝手にどんどん増えていきます。free がなくなるとこの cached が少しずつ解放されて使われます。 cached も buffers も空きメモリの一部ですので、これらが溜まっているからといって無理やり解放させる必要は通常はありません。cached を溜めているのはパフォーマンスのためなので、解放させると通常使用時のパフォーマンスが落ちます。逆にこれを解放しておかないと、パフォーマンスの測定などで、正しい計測ができません。 kernel の 2.6.16 以降では、解放をコマンドから解放できるようになりました。root で # echo 1 > /proc/sys/vm/drop_caches のように /proc/sys/vm/drop_caches に1～3の値を書き込みます。値によって解放され

ffmpeg を使って映像だけ、音声だけ、映像と音声を一緒に後ろにつなげることができる concat の使い方。 関連記事 【ffmpeg】動画・音声を連結する concat の使い方 其の2 【ffmpeg】動画・音声を連結する concat の使い方 其の3 例 -filter_complex concat=n=2:v=1:a=0 n は連結するファイルの組み合わせの数 既定値は2。映像と音声を別入力した場合の例。映像、音声、映像、音声の4ファイルを入力した場合、n=4 ではなくて、n=2 を指定する。つまり映像と音声で1つの組み合わせになりもう一つの組み合わせを連結する v は出力する映像ストリーム数 既定値は1。 a は出力する音声ストリーム数 既定値は0。（「1つの映像と2つの音声を持つファイルを3つ連結する」を参照） この方法は必ず再エンコードされる。無劣化連結ではない v と

2013-12-19 Scalaを使い始めてから半年だけど印象をまとめてみる Scala 僕はScalaを使い始めてだいたい半年というところです。業務で使ってるんですが、最近になってやっと楽しさが少しわかり始めたところで印象をまとめてみました。主観性が高いので異論･反論のある人も多いかもしれません 覚えることが多い ※個人差があります Scala は様々な文化のごった煮なところがあるため、様々な文化を知ってないとツライです。よく better Java として簡単に使えるよという甘言をささやく人がいますが、better Java として使うにはそもそも Java の知識が必要なわけですし、better Java なコードを書いてると、「varやミュータブルコレクション使っていいのは小学生までだよね」とか「while文なんて普通使わない」とか「Enumerationじゃなくて代数型データ構造

TypeScriptとMeteorでアプリケーション開発に着手する直前に、第2回Shimokita.jsで新井さんのHead First Haxeという発表を聴いて、Haxeへの興味が高まっています。 ちなみに、Meteorの採用は決定しました。 TypeScript + Meteor から Haxe + Meteor に切り替えつつあるのが現状です。 前提 やりたいことは、 IA DSLとしての抽象化CSSとドメイン駆動設計 アーキテクトがリードするUIプロトタイピング（OOSass と JavaScript MVC と DDD） UIコンポーネント単位のエンド・ツー・エンドの開発パイプライン です。これまでの経緯は『これまでの経緯 ver. 2 (2013–06–26)』の通りですが、要約すると Scala + Play Smalltalk + Seaside Dart TypeScr

Did you mean to visit any of these blogs, instead of uio.wordpress.com? uxio.wordpress.com — Rerum Novarum The address uio.wordpress.com cannot be registered. Site name must be at least 4 characters. But you can sign up and choose another one.

http://blog.pop.co/post/67465239611/why-we-chose-api-first-development POPは、簡単にビジネス/アイデアをかたちにするために、1分でドメイン/スタートページ/メアドを用意できるサービスとのこと。彼らが、「APIファースト」で開発しようとした理由を紹介してます。 1) 将来APIを提供できるように 機能を追加する都度、APIが既に準備できているかたちになるので、将来APIを第三者に提供するときもスムーズ。 2) フロント/バックエンドの分離 バックエンドのテンプレートコードがフロントエンドのクライアントビューとやり取りしない仕様にすることで、将来の開発に負の資産を残さない。 3) スケーラビリティ フロント/バックエンドそれぞれを独立してスケールさせることができるので、将来的にメリットがでるはず。 4) 開発言語のバリア

■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ

皆様こんにちは。今日も元気に自分を見つめ直していますか？自分を見つめ直す手段として、過去の自分の発言を見返すことは有用だと考えられます。たとえば、Twitter を使っている方ならば、その過去ログを用いることが考えられるでしょう。Twitter の過去ログはライフログとして機能し、それを用いることにより、過去の出来事のみならず、考え方、感じ方、ふとした着想、などなどを読み取ることができます。しかしながら、過去のツイートを全部見返すのは非常に面倒ですね。たとえば僕のアカウントはトータルで4万ツイート以上あります。これは非常にめんどい。Twitter は情報量多くてだるいよね問題については、従来「再生核 Hilbert 空間を用い、脱ベイズ確率主義に立脚したあまりだるくないツイッター」などの試みが行われてきましたが、今なおその面倒さを軽減する手段については十分とはいえません。本記事では、過去の