64bit時代のバッファ処理
プログラミングの「常識」は時代とともに変化します。そのひとつが、サーバプログラムにおけるバッファ処理です。 1990年代後半から2010年頃までは、メモリ空間の大きさ（32bitすなわち4GB注1）を超える大きさのファイルを扱う時代でした。このため、httpdなどのサーバプログラムにおいても、入出力データをいったんテンポラリファイルとしてバッファリングする必要がありました。ですが、ファイルI/Oはメモリアクセスと比べると低速です。このため、小さなサイズのデータについてはメモリアクセスする一方で、大きなサイズのデータについてはファイルI/Oを用いる、という煩雑なコードを書く必要がありました。 しかし、2014年も暮れとなる今 、サーバサイドにおいては64bit環境のみを考えれば良い時代に入りつつあります。 もちろん、64bit環境といったところで、64bit空間の全てをユーザプロセスが使える
plot.lyを使ってnode.jsでプロットする - マルシテイア
ちょっとプロットしたいとき、以前はmatplotlibを使ってたんだけど、node.jsでもやりたいときあると思う。 Plot.lyはプロットするサービス。 Python, MATLAB, R, Julia, Node.jsに対応してる。 ユーザー登録したら以下のページでAPI KEYもらえる。 https://plot.ly/settings/api ↓のようなコード書いて、 #!/usr/bin/env node var plotly = require('plotly')(USERNAME, APIKEY); var data = [ { x: [-1, -0.9, -0.8, -0.7, -0.6, -0.5, -0.4, -0.3, -0.2, -0.1, 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1], y: [0.2419
Go言語によるCLIツール開発とUNIX哲学について - ゆううきブログ
この記事ははてなエンジニアアドベントカレンダー2014の8日目です。 今回は、Go言語でサーバ管理ツール Mackerel のコマンドラインツールmkr を作るときに調べたこと、考えたこと、やったことについて紹介します。（mkr は現時点では開発版での提供になります。） コマンドラインツールについて コマンドラインツールを作るにあたって、@deeeet さんの YAPC Asia 2014 での発表資料が非常に参考になります。 書籍 UNIXという考え方ーその思想と哲学 の内容をベースに、コマンドラインツールはどうあるべきかということが丁寧に説明されています。 上記資料から引用させていただくと、コマンドラインツールにおいて重要なポイントは以下の7つであるとされています。 1つのことに集中している 直感的に使える 他のツールと連携できる 利用を助けてくれる 適切なデフォルト値を持ち設定もでき
HTTPパーサにおけるSSE4.2最適化の威力と注意点 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、サイボウズ・ラボの光成です。 PicoHTTPParserは@kazuhoさんたちが開発している高速なHTTPパーサです。 同じ作者によるHTTPサーバH2Oにも使われています。 11月4日の開発ブログによると、その時点でNode.jsなどに使われているhttp-parserの10倍程度の速度を誇るそうです（現在はhttp-parserも速度向上しその差は縮まりました。それでも4倍以上の差があるようです）。 該当ブログにはその高速化のためのノウハウが書かれていて大変興味深いです。ただIntel系CPUに搭載されているSIMD命令は用いられていませんでした。今回、@kazuhoさんと一緒に文字列処理専用のSSE4.2を用いることで1.7～1.9倍の高速化を達成しました（Improving Parser Performance using SSE Instructions (in
“飲むおにぎり”ヨーグルト味でポッカから
「今朝もぎりぎりまで起きられず、朝メシは駅のホームで飲むゼリー。でもこのゼリー、原料が人工チックなのがちょっとなー」というIT戦士に朗報だ。ポッカコーポレーションは、米を主原料にしたゼリー飲料「ポッカGOHANDY（ごはんディ）エナジーサポート」を7月26日に発売する。価格は200円（税抜き）。 ヨーグルト風味のゼリー飲料。長野県産コシヒカリ由来100％の糖化液が主原料で、消化吸収が良い上、体内で素早くエネルギーに変えることができるという。その他の原料も発酵乳や寒天、こんにゃくなど天然素材のみを使い、さらに海洋深層水でミネラルを、米ぬか抽出液でビタミンBを補った。1食当たりのカロリーは98Kカロリー。 容器は新開発したおにぎり型ソフトパウチを採用し、商品の特性をアピールする。 同社によると、食事型ゼリー飲料市場は2003年度で360億円と拡大中。しかし人工的な原料を使用した商品がほとんどで
リモートワークの地味な知見 - ✘╹◡╹✘
華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね？」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく
avans アプリの処理フロー - tokuhirom's blog
avans にかぎらず､java の web application 全般そうですが､ src/main/webapp/WEB-INF/web.xml がエントリポイントになっています｡ 最近では Spring boot や Dropwizard などのような､web.xml いらずのものもありますが､avans では web.xml で記述することにしています｡ web.xml はコンテナがいい感じに読んで実行してくれると思いねえ｡ <?xml version="1.0" encoding="UTF-8"?> <web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ht
maven archetype の作り方 - tokuhirom's blog
Java の世界では maven archetype を作成して､それを使って行うのが基本となっている｡ なんだかめんどくさそうなので LL で生成していたのだが､やはりその LL のスクリプトをインストールさせる方法が特になく､辛い｡ ということで諦めて maven archetype の作成方法を学ぶことにしたわけであります｡ maven archetype の作成方法は公式サイトのこのあたりにのっています｡ http://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype は velocity を用いて生成されます｡ チュートリアルがここにあるので､これを順番にやっていけばそれなりのことはできる｡ http://maven.apache.org/guides/mini/guide
Validation Night で話してきた - tokuhirom's blog
なんかしらんけどスライドアップしようとしたら slideshare に拒否られてるので悲しみ溢れております｡ とりあえず思ってることをいくつか｡ 相関バリデーションどうよ? ベーシックな単項目の Validation 以上のものを Validation framework でやろうとするのは悲しみしか産まないので､たとえば以下のようにしています｡ List<String> messages = new Validator().validate(params); if (params.isHojin()) { if (!params.has代表者名()) { messages.add("法人は代表者名いれてね!"); } } else { } そこあんま気張ってもね､的な｡ HTTP で Validation error 上げるとき 200 を返すべきか 200 を返すべきだと思います｡ 僕
Validation Nightに行ってきた。 - パルカワ2
ですよねー！！！！！！！！！！と思うことが多かった。 帰ってる途中に長文書いてたらめっちゃ体調悪くなってきて消した。 何が言いたいのか箇条書きにすると ControllerとModelのバリデーションは必要 ControllerとModelはバリデーションエラーを見せる相手が違う Controllerのバリデーションエラーはユーザー（APIを使う人、アプリケーションを使う人）に見せる Modelのバリデーションエラーは、APIを開発する人に見せる FromValidator::Lite、Data::Validator、Perl最高！ jQuery Plugin Validationで痛い目を見た。もう使いたくない。 ユーザーのためにClientのバリデーションは必要 サーバ側(Controller)とJS側のロジック共通化はずっと解決しない課題として何年も塩漬けされている 最後のやつとか、
Validation nightで発表しました。
「RDBにおけるバリデーションをリレーショナルモデルから考える」という、なんとも捻りも面白みもないタイトルである。だが、RDBとValidationという2つが相容れないものだということを知っている人には、割と琴線に触れる話かも知れない。 正直なところ、現在私はデータベースエンジニア一直線なので、アプリケーション開発におけるセキュリティというのは門外漢であると言って差し支えない。しかもイベントにはあの徳丸浩氏（バリバリの本職）も発表されるというではないか！！順番的には徳丸氏の次に話したのだが、徳丸氏はSQLインジェクションの実演までするというガチっぷりである。 「場を白けさせてしまうのではないか・・・」 「ガチの人から特大のマサカリが飛んでくるのでは・・・」 そんな想いを脳裏に抱きつつ発表に望んだのであった。 今回の持ち時間は20分と短めであったが、あまりたくさん話したいネタも無かったので
先に疑問を考えてから本を読む - $shibayu36->blog;
久々に昔のエントリを読み返していたら、以下の様な記事があった。 最近の本の読み方 - $shibayu36->blog; どんな本を読むかの部分と、読んだ後ブログに書くというのはずっと変えてないが、最近は読む時どうするかという部分についてちょっと調整を加えている。この部分について書いてみる。 ちなみに今回説明する本の読み方は、特定の事柄を学習したい場合に読む本に限定している。ざっくり興味関心で読む本はここまでしっかり読まず適当に流し読みしてる。 読むときの流れ 読むときは以下の様な流れで読む。 目次を見ながら学びたいことを疑問形式で書く 読みながら印象に残った部分をメモ書きする 最初に書いた疑問に答える 読書ノートテンプレ(自作)に従ってまとめる ブログに書く ここから以前会議の前に決めることは何か - 「感動の会議！」読んだ - $shibayu36->blog;で書いた「感動の会議」を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
島根ドライブイン日本海 スパイラル自販機の仕組みとうどん自販機