Loading...

社内システム開発日記:その111

前書き

お疲れ様です!
小手投げです。

WBC初戦は大味でしたが、乱打戦は見てる側としては楽しいですね。
筒香のHRを初めて見たにわかですが、打った瞬間に他の選手とは違う凄さを感じました。
山田の幻のHRをとった少年はTwitterで大炎上してちょっと可哀そうですね。

今回は日記です。

日記

セレクタ.val()で値が取れない件を調べる
見つからない

結局htmlが読み込まれてから実行するべしということだった
$(function(){});で囲ってやる

テキストボックスで予測変換できた
テキストエリアでもできた

改行しても各行でできるが、一番下の行でないとダメ
現在の入力位置にできないか

導入したsuggest.jsを読んでみる
現在のキャレットの位置が何行目にあるか取得できればいけそう

キャレットの位置は何文字目かしか取得できないらしい
取得して改行位置と比べればいけるか

選択範囲の開始位置を取るメソッドがあるがIEだけ対応してないらしい
IEに対応するためdocument.selection.createRangeを使ってみる
ダメ、調べたらすでに使われていないらしい
代わりにdocument.getSelectionを使ってみる
ダメ

一旦IE気にしないでやってみる
selectionStartでとれるらしい

部長から入力補助の検索対象をクライアント側で持つことの理由を聞かれる
Ajaxで投げる、あるいは折衷案として簡単な単語のリストを用意して、
ヒットしたらその単語で問い合わせに行くというのもあると

メリットデメリットそれぞれあるが、近藤さんでも決めかねる
エンジニアに聞いてみたらとのことだったので開発部全体に投げる
早速返信があり、
最初の1回だけ読み込んでメモリ上にリストを保持するのが良いという意見
理由としては問い合わせの度にアクセスログが生成され、
アクセスログを解析するときに邪魔になるから

帰社したエンジニアにも意見をいただく
クライアント側でいいのではと
見た感じ業務特性としてそんなに負荷が大きくないので、
クライアントにいっぺんに読み込ませても大丈夫、
最大手のベンダーが1万人規模で、1割の千人が1時間に集中して
Ajaxの問い合わせが発生したら厳しいのでは、とのこと
社員全員のデータをリスト化するとしたらクライアント側では厳しいので、
データをフィルタリングして絞ればいいとのこと

部長から環境についても指摘を受ける
本番やステージング環境はrootで入らないのでユーザーを用意しなきゃいけない

本番、ステージング→AWS
テスト環境→ドッカー社内サーバ
テスト環境は社内でlinuxの確認用

基盤の方がいたので軽く確認すると、
管理側で操作していることが分かればユーザーは何でもいいんじゃないかとのこと

後書き

予測変換のデータをクライアントとサーバどちらに持つかというのは考えていませんでした。

何となくクライアントに吐いちゃえば楽かなくらいの感覚でした。

ではまた次回。

情報戦略テクノロジー