再結成だったそうで。最初の結成の頃はOrinetDB触ってた頃だけど気づかなかったっぽい。
Neo4jユーザーグループ再結成 & Neo4j 無料セミナー - connpass
Read moreこれは過去にQiitaに投稿したもの
High Performance JavaScriptに書かれているJavaScriptにおけるregular expressionの書き方に関するメモ。
Regexpの処理に関しては他言語と共通かも判りませんが。
解析中にある文字でマッチングに失敗した際、直近の処理の分岐点まで遡る事。
遡った後、まだマッチングが行われていない選択肢(e.g. 次の文字、|
で隔てられた右側の候補)から処理を再開する。
*, +?, {n}
など|
/h(ello|appy) hippo/.test("hello there, happy hippo")
h
がマッチする。それ以降の文字に対するマッチングを開始する。ello
とのマッチングを行う。ello
までマッチするが次の文字(h
vs t
)でfail。backtrackしてalternationの分岐に移動し次の候補appy
のa
からマッチングを始める。failなのでbacktrack。h
とのマッチングを繰り返し、14文字目のh
がマッチ。2.と同様分岐からello
とのマッチングへ。e
vs a
の時点でfail。backtrackして分岐に戻り、次の候補appy
とマッチング開始。happy hippo
とマッチ。// 例文 var example = '<p>a paragraph.</p>'; // greedy /<p>.*<\/p>/.test(example); // lazy /<p>.*?<\/p>/.test(example);
greedyの場合、.*
でのマッチングでa paragraph</p>
まで全て検査し、その後残りの<\/p>
とのマッチングの為に1文字ずつbacktrackして.*
に含まれる文字を減らしながら検査していく。
lazyの場合<p>
までマッチングした後、.*?
と空文字がマッチした状態から<
のマッチングを開始し、対象の文字列中の<
にマッチするまでbacktrack->1文字.*?
のマッチ対象に含めながら1文字ずつ検査を進めていく。
マッチさせたいパターンからbacktrackingの回数を求め、適切な方を選ぶ。
隣り合ったトークンが対象についてオーバーラップしないようにする。
例えば適当な文章から""で括られている文をマッチさせたい時に/".*?"/
ではなく/"[^"\r\n]*"/
を使うとか 。前者では.
と"
による対象文字列中の"へのオーバーラップが生じ、backtrackingが起こる分岐点が発生している。後者にはオーバーラップが無い。
Lookaheadとは: https://developer.mozilla.org/en/docs/Web/JavaScript/Guide/Regular_Expressions#special-lookahead
JavaScriptには無いatomic groupingの機能を模倣する事が出来る。
atomic groupにマッチした文字列はbacktrackingで検査が再開されるポイントにはならないので余計な検査が行われない。
Lookaheadは通常その中に含まれるregexpをマッチ対象として扱わない(上記リンクに挙動の例があります)が、以下の様にregexpをcapturing groupに包んで、lookaheadの外にバックリファレンスを与える事でマッチした対象として扱う事が出来る。
/...(?=(pattern))\1.../
使いどころとしてはmarkup言語に対して検査を行う時。
複数単語のマッチングに対してalternationで単語ごとに分けるのではなく異なる部分だけ切り出す感じ。
以下例
instead of | use |
---|---|
cat | bat | [cb]at |
red | read | rea?d |
red | raw | r(?:ed|aw) |
(. | \r | \n) | [\s\S] |
補足としてcharacter class ([\s\S]
とか) を使った方がエンジンの実装的にalternation使うより速いっぽい。
backtracking捕捉の為、作ったregexpに対して大部分がマッチするけどマッチしないパターンを含む長い文字列を使う。
検査対象が非常に具体的な場合はString型のメソッドで処理した方が安上がりだったりする。
シンプルに、具体的に、明示的に、等々
特に前知識など無しに参加してみた。技術調査的なノリだった。
"Essentially, an FST is a SortedMap<ByteSequence,SomeOutput>, if the arcs are in sorted order."
誰得なのか知らないですが、Lucene FST の実装の元になった論文です。 #SolrJP http://t.co/WvH7QaB1R8
— Tomoko Uchida (@moco_beta) December 8, 2014
Read more
すでにだいぶ前の話ではありますが。
大学時代NoSQLはそれなりに追っていたのですがRDBはそうでもなかったので、一度理論側からしっかり勉強してみようと言う事で、1冊目にこの本を選びました。
200ページそこそことそれほど分量もなくさくっと読めるかと思ったら結構手こずりました。その辺に関しては後ほど。
構成としては3つのパートに分かれており、パート1がrelational modelについて、パート2はデータベースのトランザクションとデザインについて、パート3はSQLについて述べられています。Relational modelのoperationについてはTutorial Dで、SQLはISO標準に基づいて記述されています。パート1とパート3を対応させるように書かれており、理論と実装の差異がより明確に浮かび上がらせ、この対比を通してrelational theory本来の簡潔さや表現力の高さを主張しています。
AppendixではTutorial Dの補足的な解説や定義について、また集合論のちょっとしたまとめが付随してるので、数学的な背景に自身の無い人でも必要最低限は押さえられると思います。
内容とは関係ないですが、とてもwordyな本だという印象を持ちました。もっと簡潔に書いてくれたらもっと評価高かったんだけどな...。
あとDate氏はSQL嫌いなんだろうなーと思いました。Prefaceののっけから"... considered as a concrete realization of the abstract ideas of the relational model, SQL is very deeply flawed" なんて言ってますし。その後も SQLは全然relationalじゃないよーと度々主張していたり、パート3の最終章ではその具体例を列挙していたり。
RDBやそのoperationの集合論的な捉え方をある程度習得できたし、よりrelationalなSQLの書き方も解った所で、さて次は何を読もうか。
ひょんな事からLinux上でTortoiseHgを使う事になったがdiff toolやmerge toolにgvimdiffを設定した所上手く起動せず、二進も三進もいかなくなってtwitterでぼやいたら入門TortoiseHg+Mercurialの著者フジワラさん(@flyingfoozy)を始め複数人の方に助けていただいたので、教えていただいた内容をまとめます。
なおこの記事は私のケースと同じくgvimdiffを設定する場合のみ扱っています。より一般的な情報についてはフジワラさんによる解説記事を参照してください。