Navigation Timing とか Resource Timing とか、パフォーマンスまわりのAPIについて自分で整理できていなかったので、これを機会にまとめてみました。
Navigation Timing とか Resource Timing とか、パフォーマンスまわりのAPIについて自分で整理できていなかったので、これを機会にまとめてみました。
レプリケーションの問題でよくある10パターン。 1) セッションのみで有効なバイナリログ sql_log_bin = 0を設定すると、そのセッション内でバイナリログを無効にできる。つまり、マスタのセッション内で実行したDMLやDDLは、スレーブにはレプリケーションされない。 マスタでバイナリログをオフにする。 mysql> set sql_log_bin = 0 ; Query OK, 0 rows affected (0.00 sec) reptestデータベースにテーブルを作成してみる(マスタ上で実行)。 mysql> create table reptest(ID int) ; Query OK, 0 rows affected (0.01 sec) mysql> show tables ; +-------------------+ | Tables_in_reptest | +-
ClojureやHaskellのような不変データ構造体のJS実装です。facebook製。 不変データ構造の特徴として、元のデータ構造は不変です。 Immutable = require 'immutable' map1 = Immutable.Map a: 1, b: 2 # => Map {a: 1, b: 2} map2 = map1.set a: 3 #=> Map {a: 3, b: 2} map3 = map1.update (val) -> {foo: val.a} #=> Map {foo: 1} Mapの他に、List, OrderedMap, Set, OrederedSet, Seq, Range, Record, Stack等があります。内部的にはトライ木になっています。 面白いのはSeqやRangeで、filter関数やmap関数を与えても、getで呼ばれるまで遅
この記事はC++ Advent Calendar 2014の21日目にエントリしています。 内容はC++メモリモデルと逐次一貫性についての概説記事となっています。 flickr / nomadic_lass もくじ 忙しい人のための「C++メモリモデル」 C++メモリモデル一問一答 ソフトウェアからみた「C++メモリモデル」 “メモリ”という共有リソース C++ソースコードが実行されるまで メモリの一貫性と整合性 逐次一貫性モデル is Easy ハードウェアからみた「C++メモリモデル」 ハードウェア・メモリ一貫性モデル C++コンパイラの責任と自由 強いメモリモデル vs. 弱いメモリモデル 逐次一貫性モデル is Hard (本文のみ約9600字) まえがき When your hammer is C++, everything begins to look like a thumb
Web based on Standards Web は誰のものでもありません。 だれかプロダクトオーナーがいてその人が意思決定するとか、そういうのとは真逆の成り立ちをしています。 標準的な仕様を決めて、その仕様に則って Web の世界は成り立っている。 政府が作るサイトも、 Twitter も、学生が作ったブログも、全部同じルールで作られている。だから繋がる。 これって結構凄いことだと、自分は思っています。 Standarization このルールの決め方にもルールがあって、ちょっと敷居は高いかもしれないけど、誰でも自由に参加して、自由に意見を述べることができる場があります。 標準化団体ってやつですね。 なんか一部の人たちが勝手にやっているように思えるかもしれないけど、それは選挙に行かない人の理論と同じです。 あなたが仕様について意見を持ってて、それが妥当であるならば、その発言は仕様を根
イケてると思う dotfiles の管理方法 この記事は、今年もやります!KMCアドベントカレンダー!! - KMC活動ブログの21日目の記事です。 昨日の20日目の記事はReturn Value Optimization (RVO)の話 【KMCアドベントカレンダー20日目】 - KMC活動ブログでした。 KMC5回生の wacky です。今日は dotfiles の管理方法についての話をします。 dotfiles を管理していないと 何らかの UNIX を長いこと使っていると、ホームディレクトリには自分の書いた .zshrc や .tmux.conf などの設定ファイルがたくさん転がっていると思います。そして、長いこと UNIX を使っている人であれば、自分が単一のサーバにしかログインしない、というのは稀でしょう。当然、自分のログインするサーバ全てのホームディレクトリには .zshrc
ホームディレクトリにrpmbuildという名前のディレクトリと.rpmmacrosという名前のファイルが作成される。 .rpmmacrosの%_smp_mflagsは、rpmをビルドする際のmakeの並列数を指定するマクロであり、環境に応じて適宜編集する。 SPECファイルの作成 作成したいパッケージのspecファイルを $HOME/rpmbuild/SPECS ディレクトリに配置する。 作成したパッケージの旧バージョンなどが既に存在する場合は、ソースRPMをダウンロードして、それに含まれるspecファイルを編集するのが簡単だろう。 ソースRPMを提供するリポジトリはデフォルトでは登録されていないので、以下のような内容のファイルを/etc/yum.repos.d/CentOS-Source.repo というファイル名で保存する。 (CentOSのバージョンは適宜変更する) [base-so
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く