{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{ページ遷移無し}{停止する}{フォームの送信}{`-webkit-tap-highlight-color`}{妙な効果}{タップ時}{用意されている}{`-webkit-text-size-adjust`}...=}(75)

{希哲16年4月7日14歩 K#F85E/A-E74C-D3A9}

進捗時限記録中略

細かい装体調整など。

iOS上のSafariで,横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが,確かに手元iPhone同様現象があり,気になっていたデライトの不具合にしては不可解なのでもしかしたら舞覧稀なバグなのかと思ったが,再現性があるらしいことが分かったため調査した。

結局諸場舞覧自動拡大機能であり,text-size-adjust-webkit-text-size-adjust)という制御用CSS プロパティまで用意されていることが分かった。以下のようにして解決

-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;

もう一つ諸場舞覧気になっていたことに,輪結ボタンタップ時妙な効果入るというのがあったので,ついでに調べてみると,これも諸場舞覧特有機能で,-webkit-tap-highlight-color不可視出来た


スマホ弄っているうちに,iOSSafari全知検索ボタン動き付け止まっていることに気付いた

これはフォームの送信などで描画処理停止する Safari 特有仕様であることが分かったSafari の問題といえばそうだが,実用上の問題はなく,まともな解決策無さそうなので放っておくことにした。

全知検索整備方針定まったことだし,そろそろページ遷移無し輪郭一覧更新出来るようにしてもいい頃だろう。

=}
{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{多段化}{進めて}{後縁の対応}{追加取得}{フラグ化}{確定出来る}{余計な検索}{目に見えている}...=}(109)

{希哲16年4月7日10歩 K#F85E/A-E74C-B300}

進捗時限記録中略

全知検索整備方針検討終了

2月23日頃から検索結果改良について本格的に考え始めていたが,「検索属性」を導入し,検索結果多段化進めていくことにした。

現状例えば括弧類自動付加した検索は出来るが,その出来ない括弧付き描出したい場合括弧無し検索して既存輪郭無いことを確認した後,括弧を付け再検索するということがく,とりあえずこの手間無くしたかった全知検索演算子制御任意の括弧類使える好都合ということもあった。

文字数昇順揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが,上手く行かない場面多々あるので一時凌ぎ域を出ない

将来的な拡張性考える検索結果多段化好ましい風船輪郭輪括内検索にも応用出来る希哲14年7月30日8歩から輪括内検索輪括内のみにすると使いにくいという理由中途半端な状態になっていたが,優先表示解決出来ることに気付いた

整数値揃え兼ねた役割を与え,これを「検索属性」として利用出来るようにする。

ここまでは良いが,効率的な実装難しい単純に全ての検索パターンUNION結合すればひどいことになるのは目に見えている外充て函数余計な検索省くようにする,挿入更新時に確定出来る情報フラグ化しておくといったことに加えて後縁での出力最低限にして前縁追加取得するといった工夫必要になるかもしれない。

いずれにせよ後縁の対応進めて問題ないだろう。設計方針さえ固まれば最適化どうとでもなる

=}
{新生デライト}{『希哲日記』}{御しやすい}{希哲15年8月24日}{考え尽くした}{救われてきた}{何度となく}{上手く行っている}{追いつかない}{乗っている}...=}(75)

{希哲15年8月23日の日記 K#F85E/A-E74C-979F}

開発では全知検索整備についての検討急進展し,新生デライト全文検索など一通り検索機能盛り込める見通しとなった。

新生デライト開発デライト収益目標達成も,日に日に展望明るくなり,期待感も高まっているが,一方で,不思議な不安もある。

これは恐らく,意思思考齟齬の大きさによるものだろう。今月は,先月まとまった新生デライトの要件実装する作業没頭するつもりだった。ところが,実際にはここまで検討作業がやたら捗るばかりで,実装作業はほとんど進んでいない

振り返ってみれば,無闇手を動かすより考えるべきこと多かったのも確かだ。それによって困っているかというと,まだ気持ちのゆとりもあり,総合的状況はむしろ良くなっているようにすら思える

結局,意識出来ないほど膨大情報を,意識が追いつかない速さ処理させているということなのだろう。これだけ想定外のことをしていながら,なぜ上手く行っているのか,もはや自分でも分からない

今日の全知検索整備検討にしても,やろうと思って始めたわけではなく,なんとなく考え始めたするするまとまった。本当は輪郭選り手整備を進めたかったが,結果をみれば確かにこれで良かったと認めざるをえない。

こんなことは過去にも何度となくあったし,それに救われてきた。しかし,景色がどれだけ良くなっていようと,何度経験していようと,全く自分言うことをきかない乗っているのは不安なものだ。ましてやこれまでにない山場でだ。とにかく心臓に悪い

そろそろ考えるべきことはほぼ考え尽くしたはずなので,明日にはもう少し御しやすいになっていることを願う

=}
{進捗記録}{希哲15年8月23日の開発}{早期実装}{正規一致検索}{整理がついた}{全知検索の課題}{組み合わせる}{OR 検索}{AND 検索}{希哲15年8月23日の進捗時限}...=}(48)

{希哲15年8月23日11歩 K#F85E/A-E74C-BB18}

全知検索整備についての検討終了

全知検索の課題として,AND 検索などと正規一致検索整合性をどうするかという問題があったが,これも概ね整理がついた

AND 検索はそもそも部分一致検索組み合わせるものなので,これは OR 検索 とともに部分一致検索一種位置付けることにした。OR 検索正規一致矛盾しないが,そういう検索をしたい場合はなので統一感を取るべきだろう。必要になったら正規一致検索明示する演算子導入すればいい。

ただし,前方一致検索後方一致検索指定することは出来てもいい。a... & ...z で開始文字列と終了文字列を指定出来るのは便利そうだ。

指定にかかわらず,描写検索部分一致検索となる。


ここまでで概ね全知検索設計実装上の課題片付いたと言えそうだ。

早期実装の目処がついたため,19日の開発まとめた作業項目優先順位で「検索語提案機能実装」としていた所を「全知検索整備」に拡大することにした。

=}
{デラング}{進捗記録}{交度}{デライト}{`whr_kw()`}{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}...=}(70)

{希哲15年8月23日7歩 K#F85E/A-E74C-ECC6}

全知検索整備についての検討終了

全文検索にはとりあえず pg_bigm採用しておくことにした。知名検索でも中間一致検索性能課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse()組み込み函数として提供されるようになっているので問題ないだろう。

後縁実装どうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能実装したい。これに関しても,だいぶまとまってきた

カンマAND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難&AND で AND 検索,|OROR 検索対応することにした。除外検索条件次第- を使えるようにしてもいいだろう。

部分一致検索については,省略記号 ...ダッシュ記法応用した ---対応する。

描写検索については,基本的には昨年7月27日3歩方針踏襲し,末尾に ?? を加える形で対応することにした。デラングとの兼ね合い検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。

一つの可能性として,検索ボタンダブルクリックダブルクリック検索対象切り替える機能があってもいいかもしれない。

いずれにせよ,まずは既存の検索語変換交度whr_kw()まとめる作業から始めることになるだろう。

=}
{全知検索整備}

{}