2016/05/15

React で input 要素に focus したい話

したいよねー、focus。
生DOMを扱えるようなパターンはすぐに見つかるんだけど、自前Reactコンポーネント作った場合にどう扱えばいいのかっていうのがよくわからなかったので調べた話。

statics に focus メソッドを定義してあげるといい感じに使えるみたい。
違った。ごく普通にクラスに focus メソッドを生やしておけば大丈夫だった。

1. 生DOMを直接扱うパターン

一番ベーシックなパターン。以下の方針でなんとかできる。
  1. refs と findDomNode で生DOMを取得する
  2. 生DOM の focus() を呼ぶ
refs で生DOMが取れるというのさえ押さえておけばわかる。

なるほどなるほど。こうやるのね...

export default React.createClass({
  componentDidMount() {
    ReactDom.findDomNode(this.refs["target"]).focus();
  },
  render() {
    return (
      
); } });

2. Reactコンポーネント化する

さて、生DOMはわかった。しかしどうコンポーネント化してやればいいのか...

ここで参考にしたのが React-Select
これは select2 の React 版実装のようなもので `focus()` というメソッドをを提供している。これを参考にしてやると良さそう。



export default React.createClass({
  componentDidMount() {
    this.refs["target"].focus();
  },
  render() {
    var options = [{label: "選択肢1", value: "1"}, {label: "選択肢2", value: "2"}]
    return (
      
); } });

どのように定義されているか調べた。

クラスに focus メソッドを生やせば ref を通して呼べる仕組みになっているようだ。

------------------------------
以下は間違っていた。
  • Async に定義されている
  • Select の statics に取り込んでいるっぽい?
  • statics でコンポーネントの static メソッドを定義することができる

なるほど statics にメソッドを定義することでコンポーネントのAPIを定義できるらしい。
それを利用して生DOMと同じようなインターフェイスにしてやるといい感じに扱えるよね、という話みたい。

2016/01/02

emacs のパッケージ管理を Cask から El-get にした

Caskはもう古い、これからはEl-Get - いまどきのEmacsパッケージ管理 を参考にしつつ El-get に移行しました。


Cask 管理だったのですが、以前 cask update をかけたら環境が不整合を起こしてツライ事態になったので、バージョン管理が必要だと痛感したのでした。
動く分にはひたすら最新に追従していけば良いかなーと思っていたんですけどね。。。

  • 経緯
    • cask update かけたら色々と不整合起こしてツライ事態になった
    • 最近しょっちゅう magit のキーバインドが変更されていてツライ
    • cask でバージョン戻せないっぽい?あの頃に戻りたい
  • どう?
    • el-get-lock よい
      • bundle.lock
    • require は el-get-bundle! か :features に置き換える
      • init-loader で分割したファイルのコンパイルで失敗するっぽい
      • パスの問題だとは思う、、、が詳しいことはわからない
    • el-get-cask 使えばよかった
      • 手作業の書き換え面倒
      • 全部 init-loader で分割したファイルに書いておきたいとかある
      • ・・・けど、そっちは後回しでもよかったなー
  • ちょっとハマった
    • flycheck のインストールにちょっと手順が必要
      • brew install texinfo; brew link --force texinfo 必要だった
      • texinfo のバージョン古いのが問題だったらしい
      • OSX El' Capitan と Yosemite で確認
    • flycheck-pos-tip を flycheck-tip に変更した
      • どこかの時点で pos-tip.el がうまく動かないようになった?
        • でも pos-tip.el はバージョンアップしてないような?
        • pos-tip-hide(alias of x-hide-tip)が動かない??
        • x-hide-tip とは・・・
      • flycheck-tip なら大丈夫だった
        • flycheck-tip は pos-tip.el ではなく popup.el を使用
        • auto-complete も popup.el を使っていてちゃんと動く
        • いけた
    • magit の古いバージョンを使うために依存ライブラリとのバージョン合わせ
      • magit/magit :branch "1.4.2"
      • magit/git-modes :branch "1.0.0"
magit のバージョンアップは様子見しよう作戦。半年くらいしたらキーバインドとか落ち着いているといいなー。。。

2015/09/19

PyCon mini Sapporo に行ってきた #pyconsap

先日 PyCon mini Sapporo に行ってきた。最高だった。

内容については http://togetter.com/li/872506 あたりを見てもらうとわかると思う。
  • 1セッション20分というのは聞く方としてはわりと楽
  • 特に LT が発表者が手練揃い。すごいスムーズかつ多彩な話題だった
  • Python メインではない発表が多かったので Python 自体にさほど興味がなくても楽しめた
    • 発表で"Python は glue(のり)だ"って言う話があったけど、まさにそういう感じ
  • sakura さんのセッションが最高にあたまおかしかった。超最高です。ありがとうございます
    • 手元のメモには"ヤバイ"としか書かれていない。。。
・・・ほんとうに僕たちの知ってるインデントの話だったのだろうか?

2015/04/29

「SQL実践入門」がとてもわかりやすい

最近出た「SQL実践入門」を読んでいます。「達人に学ぶ〜」シリーズで有名なミックさんの新著で主にSQLのパフォーマンスについての話をメインとした本。
相変わらず説明がとてもわかりやすく非常によい本だったので紹介。

SQLとパフォーマンスについての話がメイン

個人的にDB関連の書籍の分類は大きく以下の3種類に分類して考えているのですが、本書については一番上のカテゴリにはいりそうです。(「プログラマのためのSQL」も一番上かな・・・)
  • SQL、パフォーマンス(実行計画)
    • 本著
    • 達人に学ぶSQL徹底指南書
    • SQLパズル(積んでる・・・)など
  • テーブル設計
    • 達人に学ぶDB設計徹底指南書
    • 理論から学ぶデータベース実践入門など
  • DBMS製品個別の話(DB運用含む)
    • 内部構造から学ぶPostgreSQL
    • SQL Server 2008 ビギナーズガイド
    • エキスパートのためのMySQLトラブルシューティングガイド(読んでない・・・)など
SQLの基本となる考え方、テクニック、実行計画の読み解き方といった所から、DBを使用する際のボトルネックをどのように解消していけばいいのかという話がメインになっています。

ミックさんといえば「達人に学ぶSQL徹底指南書」「達人に学ぶDB設計徹底指南書」が有名。両著は非常にわかりやすく、DB関連の入門書としてかなりオススメの2冊です。
本書は「達人に学ぶSQL徹底指南書」より一歩踏み込んだ内容になっており、恐らくそちらを読んでからの方が深く理解できそうです。

主にPostgreSQLとOracleの実行計画を確認しながら、話を進めていくような形になっているので、少なくとも実行計画とはなんぞや?くらいの知識があるとよさそうです。
なお、実行計画の読み方は本書内で説明されているのでなんとかなるかと。

SQL実行時に使用されるアルゴリズムがわかる

この辺りちゃんと理解していないとオプティマイザーの気持ちがわからなくて、有効なインデックスの付け方や実行計画の操作が上手くできないのですよね。。。

SQL実行時に使用されるアルゴリズム(実行計画で見ることができる)にはそれぞれの操作毎に複数のアルゴリズムが存在します。
  • 例)Join
    • Nested Loop Join
    • Hash Join
    • Merge Join
自分はDB関連の知識としては主にMySQLあたりから入ったので、MySQLでサポートされていないアルゴリズム(例えばJoinはMySQLは5.5まではNested Loop Joinしかサポートされていなかった)について説明されているのがとてもありがたい感じでした。

あと、「達人に学ぶ〜」よりもウィンドウ関数に関してさらに複雑な使い方が紹介されていたりします。
衝撃的だったのは本著で「ぐるぐる系」と呼ばれているカーソルを回して処理をする系のロジック(性能問題になりやすい)をウィンドウ関数で書き換える話の中で、現在のレコードとひとつ前のレコードを比較して何かを判定するみたいな処理をウィンドウ関数で書き換えるという例で、これは目からウロコでした・・・!

これ、ウィンドウ関数を使えばできるのかー!!まじかー

まとめ

DBのパフォーマンス問題で悩んでいるような人は一度読んでおいて損はないのではないのかなと思います。

ただ、MySQLやSQL Severなどで最近採用されているクラスターインデックスの話なんかはこの本ではサポートされていない(まだ読んでいない箇所に書かれていなければ・・・)ので、そういった製品を利用している場合はその辺りについても併せて知識を得ておくとよさそうです。
(実際このあたりの製品使っているとクラスターインデックスの理解大事なんですよ。。。)


2015/03/12

PostgreSQLのコードを読む話(4)

前回はオプティマイザー周りに入ったのでした。


多分 optimizer の planner.c あたりを読み進めると検索プランの作成方法が、
Portal あたり(どこだ?)を読み進めると、検索プランに従って実際に検索を行う処理が見つかる気がする。

今回は Portal の方にあたりをつけて読み進めてみることにする。

CreatePortal

  • http://127.0.0.1:9292/home/postgres/src/backend/utils/mmgr/README
  • readmeみる
  • mmgr は Memory Manager っぽい
  • Context単位でメモリ管理をするようなモデルらしい

PortalDefineQuery

parseされたStatementを受け取っているので、ここで実行?
statement 名を設定しているだけだった。。。

PortalStart

実行準備とのこと
なにやら strategy にしたがって動作している

PortalSetResultFormat

見てない

PortalRun

多分ここが実行。。。
時間切れだったので、次回はここから。

PostgreSQLのコードを読む話(3)

前回の続き、フロントエンドとバックエンド間の通常操作サブプロトコルのひとつ、Queryを読んでみることにした。

ここから
https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c#L3969

exec_simple_queryに入った

https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c#L824
  • start_xact_command - トランザクション?いったん飛ばす
  • drop_unnamed_stmt - 名無しのステートメントを除去?一端とばす
  • MemoryContextSwitchTo
  • pg_parse_query - クエリをパースしてツリーを作るっぽい
  • コンテキスト戻している
  • ツリーをトラバースしている。。。
    • pg_plan_queries - クエリプラン作成?ここで色々しているとのこと
    • Portalってなんだろう?カーソルのことらしい
    • CommandCounterIncrement トランザクション関連らしい。飛ばす
      home/postgres/src/backend/access/transam/README トランザクションシステムの説明

pg_plan_queriesからオプティマイザーあたりに入った

  • プラグインでoptimizerのプランナーフックを仕掛けることが可能っぽい
  • pull_up_sublinks - any/existsを内部的にjoinに変形するらしい

オプティマイザーの全体を俯瞰した方がよいかと思いREADMEを見る

https://github.com/postgres/postgres/blob/master/src/backend/optimizer/README#L286
optimizerの動作についての説明がのっていた

時間切れ、次回はここから見ていこう。。。

2015/01/25

PostgreSQLのコードを読む話(2)

前回の続き。先日のサッポロビームで活動してきた。
今回はほとんどコードを読んでいない。
postgres.c の PostgresMain の query とか parse とは?というあたりを調べた。
あとはPostgreSQLのドキュメントを色々読んでた。

"簡易問い合わせ"と"拡張問い合わせ"

PostgreSQLのドキュメントの「フロントエンド/バックエンドプロトコル」が参考になります。通常利用される問い合わせプロトコルに"簡易問い合わせ"と"拡張問い合わせ"があるとのこと。

フロントエンド/バックエンドプロトコル


  1. 接続開始
  2. 通常操作
    • 簡易問い合わせ
      • Query
    • 拡張問い合わせ
      • Parse
      • Bind
      • Execute
    • 関数呼び出し
      • FunctionCall(非推奨らしい、Bind & Executeを利用せよとのこと)
    • その他特殊な操作向け
      • Copy
      • など...
  3. 接続終了

PostgresMain ではこのプロトコルの内、接続開始後の各サブプロトコルの種類を判別してそれぞれのサブプロトコルで定義される操作を呼び出している模様。

簡易問い合わせと拡張問い合わせの概要は次の通り。
"簡易問い合わせ"プロトコルでは、フロントエンドはテキストで問い合わせ文字列を単に送信し、バックエンドによって解析され、即実行されます。
"拡張問い合わせ"プロトコルでは、問い合わせの処理は、解析、パラメータ値の結び付け、そして実行という複数の段階に分離されます。 これは複雑性が加わりますが、柔軟性と性能という点で利点が生まれます。
このあたりを念頭に各操作の内容を読んでいけばなんとかなりそう。

その他

演算子クラス/演算子族

ひたすらドキュメントを読んでたらインデックス周りで演算子クラスとか演算子族というのが出てきた。
インデックスの種類やデータ型ごとに演算子クラスをユーザが定義することで、独自にインデックスを拡張できる?らしい。演算子クラスをまとめたのが演算子族?なのかな?インデックス周りを確認するときにもうちょっとちゃんと調べる予定。

Notify

肉さん情報。バックエンドからフロントエンド側に何らかのタイミングで通知を送る機能があるらしい。そのうち調べる。

次回

https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c#L3969
前回と同じくここから。通常操作のサブプロトコルからひとつ(Queryがよいかな)を読んで、その後DBの物理ファイルやインデックス周りの箇所を調べる予定。

参考資料