{進捗記録}{進捗}{デライト}{希哲17年4月28日の開発}{希哲17年4月28日の進捗}{希哲17年4月28日}{保たれている}{高めず}{渡配無し}{調整出来る}(121)

{希哲17年4月28日6歩 K#F85E/E74C-9EF4}

進捗時限記録中略

デライトにおける νSJavaScript渡配トランスパイルについての検討などで終了

しばらくES5 への渡配やめて様子見することにした。備立環境調整済み次回の前縁出振るい本番環境にも反映されるだろう。

希哲13年8月23日の開発以来νS では ES2015基礎にしているが,同時に Babel導入し配信スクリプトES5渡配していた。それから4年近く経ちデライトの舞覧対応方針洗練されES2015対応舞覧十分な市影有しているもはや ES5 との互換性引きずるべきではないと判断した

とりあえず--presets 応付子外してbabel --no-babelrc --minified --no-comments だけで換配するようにしてみると,ae.js譜類サイズ20kB近く減った譜類サイズ削減以上にスクリプト複雑化伴うオーバーヘッド増加抑制期待出来る

ES2016 以上交度うっかり紛れ込む紛れ込んでいる可能性考えるES2015 への渡配をしておいた方がいいかと思ったが,どうもそういう考え方をする時代でもなく,Browserslist使った手法主流らしい。確かに舞覧対応状況非常に流動的なので実態合わせる方が合理的ではあるが,ブラックボックス化避けたいこれまで通り導入付徴対応状況個別に把握しておくことにした。デライトの能力活かせるだろう。

いずれにせよ Babel の設定後からいくらでも調整出来るので,いったん渡配無し様子見する


ついでに変数名などの短縮などについても再検討したが,やはり外部通類への依存度高めず保守性維持するのは難しいため見送った交度英語おかげで一定の短縮性保たれている

{『希哲日記』}{日記}{}{希哲17年2月}{譜類添付機能}{希哲17年3月31日}{一年毎}{離れられなくなっている}{作業に没頭する}{消耗している}(88)

{希哲17年3月31日の日記 K#F85E/E74C-94C6}

今月の雑務片付き晴れ晴れとした気持ち過ごせるのはずだったが,親戚についての不吉な報せから聞いてしまい気分沈んだ

私自身このまま健康ならあと五十年粘れるが,待ってくれないものもある,という単純な事実思い出させられたここ数年一年毎くらいで似たようなことがあり,似たようなこと考えている気がするそういう年齢なのだろう。

希哲館事業の成功果したには恩返し償い出来ないままいなくなっているかもしれないと思う背筋が凍る雑務なまじ楽しくなってきて良くも悪くも緩んでいた気持ちが,思いがけず引き締まった

とはいえいま自分出来ることデライト開発着実に進めていくことしかない。杞憂消耗していても仕方ないので,気を取り直して平常心作業に没頭することにした。


今月の開発では閲覧専用模動譜類添付機能大きな収穫だったが,新生デライトの完成持ち越しとなった。

特に譜類添付機能中途半端に良い出来で,先月ダークテーマ全知検索窓固定機能のように調整作業から離れられなくなっている早く落とし所見つけたい

いずれにせよ年度替わり集客には不向き時期なので,また黄金週間睨んで調整していくことにした。

{進捗記録}{波括弧}{進捗}{デライト}{希哲17年1月22日の開発}{希哲17年1月22日の進捗}{希哲17年1月22日}{似た形態}{似た機能}{錆びついている}(119)

{希哲17年1月22日7歩 K#F85E/E74C-DD27}

進捗時限記録中略

デラング整備化学記法見直し終了

現時点ではやはり \ce( ... \)\ce[ ... \]最も無難な記法であると結論付けた


昨日直感的にこの記法思いついたが,実際に使ってみると,閉じ括弧前の \忘れやすいという問題気付いた慣れの問題もあるので欠点結論付けるのは早いが,数式記法\( ... \)比べて \ce( ... \)括弧対応関係直感的に認識しにくいというのはありそうだ。

TeX では \ce{ ... }数式模動内側書く必要無いため,いっそのこと,これだけでもいいのではないかと思った

しかし,これだと化学記法というよりは TeX 風記法mhchem使っているように見えてしまうTeX ではバックスラッシュ波括弧多用されるからこれが自然に見えるだけで,デライトでこれがぽつんとあっても違和感が大きい特に波括弧デライトにおいて特別な記号なので,濫用避けたいいずれにせよ行内別行立て書き分け出来ず書き分けせずに文脈挙動変えれば TeX 的でもなくなるので,良い案ではなかった。

似た機能似た形態に」という言語設計原則立ち返ると,やはり化学記法数式記法似ているべきだろう。

では,閉じ括弧前のバックスラッシュ省略可にするかと考えたが,これは実装上の問題大きい入れ子になりうる閉じ記号処理出来なくはない一気に面倒になる。しかも,化学記法でそれをすると数式記法でもしないと整合的ではなくなる。現時点化学記法使い勝手のためにそこまでの実装コスト払う意義見出せない

読み込み中...
{進捗記録}{}{一通り}{一種類}{}{}{}{}{}{進捗}(253)

{希哲17年1月19日14歩 K#F85E/E74C-3191}

進捗時限記録中略

highlight.js版存更新終了

10.6.0 からスクリプト最新版11.7.0 へ,Zenburn装体書最終版10.7.3上げた出振るい手定め済み

希哲15年7月18日10歩更新検討したが,当時対応言語検証必要判断し見送り,以来そのままだった。約2年前版存なので,流石に対応言語云々より弊害の方が大きいだろうと更新決めた

作業自体あっという間に終わる見込んで昨日深夜着手したが,最新版従来の Zenburn事実上消えていたため,カラーテーマ検討時間を取られてしまった散々考えた結果Zenburn最終版利用して現状維持とすることにした。

カラーテーマ検討

最新版Zenburnstyles/zenburn.min.css から styles/base16/zenburn.min.css移動していた上に,従来とはほとんど別物になっていた様子Base16 になったからなのか事情よく分からないが,読みにく過ぎるのでいずれにせよ使い物にならない

気になる部分装体上書きして調整出来なくもないが,そこまでするならデライト独自カラーテーマ作りたくなってくる取り急ぎ代替テーマ探すことにした。highlight.js 導入時それなりに時間をかけ検討した希哲15年3月9日11歩ので,当時の記憶からある程度見当付いた

読み込み中...
{開発記録}{}{サービス}{デライト}{デライトはoEmbedに対応している?}{描写下見機能}{希哲17年1月16日の副日記}{この手の}{埋め込み献典}{検討しておく}(243)

{希哲17年1月16日の開発 K#F85E/E74C-6ADB}

作業方針検討4歩閲覧専用模動実装検討5歩デラング整備埋め込み記法処理改良8歩13歩

埋め込み記法処理改良

これまで埋め込み記法処理の中でも oEmbed利用したものについては,Dex 内で埋め込み交度取得直接描写 HTML埋め込んで返していたが,埋め込み交度取得処理専用 API /mbd委ね前縁 Aejs から利用することにした。結果として応答速度改善成功した

埋め込み記法+[URL]URLoEmbed必要とする場合Dex では適当な分類名付与した <div>出与え属性URL埋め込んで描写 HTML返すAejs ではそれを検知し,URL/mbd転送する/mbdURL対応したサービス埋め込み交度oEmbed取得して返す,という流れになる。過剰な立求抑止するため,Aejs には簡易的な隠し持たせておいた

想像していたよりすっきり実装出来た


そもそもきっかけは,先日の SlideShare 対応だった。oEmbed必要になったので,埋め込みツイート使っていた Dex 内の oEmbed 埋め込み方法取り急ぎ使った。ただ,記法処理範枠同期通信処理組み込むというのは正気の沙汰ではないなんでこんな実装になっているのか,引っかかりはあった。

KNEST 隠し使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状そこまで最適化する必要時間も無い出来たとして,隠し有効利用出来る握接パターン限られているいずれにせよこの種の埋め込み記法利用増えてくれば破綻目に見えている。ということで,いったん埋め込み処理前縁移すことにした。

読み込み中...
{進捗記録}{十分}{曖昧}{輪郭整備}{希哲16年9月}{進捗}{デライト市場戦略}{Firefox}{希哲17年1月7日の開発}{希哲17年1月7日の進捗}(210)

{希哲17年1月7日20歩 K#F85E/E74C-370E}

進捗時限記録中略

知名欄描写欄捕活フォーカス関する仕様検討結果ともにマウスオーバー捕活する仕様確定実装した出振るい手定め済み

なお,知名欄自動全選択については正式に廃止決定した


仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活全選択描写欄では捕活,という方針だった。これは実用上の都合というのも大きく,こうでなければ単純に描出効率悪かった

昨年9月までの第二次用合い改良中の交度整理で,知名欄捕活全選択機能しなくなっていた。これは確か中景輪符事象イベント改良したことで干渉懸念があり,再実装後回しにしたという経緯だった気がするもっと地味な描写欄捕活過去に何度か再実装した記憶があるものの,どの時点機能しなくなっていたのかは曖昧だが,いずれにせよ第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた

もしかしたらこれはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率重要な作業になると,クリックでの捕活やはりまどろっこしく,鈍重感じる。そこで最近はかつての挙動復活させる機会窺っていた

懸念は,他要素他機能との干渉誤操作だったが,これは昨日の検討から急速に氷解した今のデライトで,マウスオーバー捕活移動すること自体前提のようなところがあるので用者体験大きな悪影響はないだろうということ,むしろほとんどの要素マウスオーバー反応するのに知名欄描写欄無反応なことが直感性損ねているとも言えること,スクロールとの干渉実際の舞覧ブラウザでは生じないこと,誤編集問題については,そもそも閲覧編集用合い切り分けていることが一定の保護機能になっており,更に取り消しボタン変更有無分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した

そこでまず,知名欄全選択含めてマウスオーバーでの捕活機能復活させてみたところが知名欄全選択については数十分廃止決定することになった。実装上の問題としては,選択状態やはり周辺要素干渉する干渉しないようにマウスアウト解除すると,今度は選択状態意図せず解除されやすくなる。もっと問題なのは,誤入力上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態好都合だが,知名欄での利点写し取り素早く行えることくらいでさほど大きくない

これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても熟練用者向け過ぎ採用出来ない

次に知名欄全選択機能し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら編集軽快感明らかに向上している捕活さえしてくれれば Ctrl + A写し取り十分効率的に行える今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時発生するスクロール意図しない場合多く考えられるため抑止する

どこまで普遍的な現象分からないが,常用している LinuxFirefox では,<textarea>選択状態残して捕活解除すると,再選択のつもりが未捕活状態のせいで)意図しない文字列ドラッグ発生しやすいため,これがなくなったのは個人的に嬉しかった近頃多用している複数輪符引き入れ欄への写し貼り障害になっていた。

とにかく第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった

{整清記録}{希哲15年}{}{入浴}{整清}{給湯器の故障}{希哲16年12月22日}{投げ込みヒーター}{ネットで買う}{回ってみた}(100)

{希哲16年12月21日の整清 K#F85E/E74C-B8E0}

1時間ほど家事など。


昼頃蛇口から出なくなった

希哲荘給湯器設置から17年以上経っているであろう古いものなので,いつ壊れてもおかしくなかった。ここ5年ほどの間か,給湯温度やや不安定になったり,風呂場リモコン効かなくなったり,全てのリモコン画面映らなくなったり,少しずつおかしくなっていた昨年交換ちょっと検討したが,すでに半導体不足入手困難という時期だったため騙し騙し使ってきた

明日業者来てもらうことになったが,とりあえず給湯器使わずに凌ぐ方法考えておいた一番心配だったのが入浴だが,これは足湯バケツ電気ケトル使ったバケツ浴」で何とかなりそうだ。

ネット見かける投げ込みヒーター使えるかもしれないと近く家電量販店回ってみたが,どうも当たり前売っているものではないらしく,見つからなかったネットで買うのも安全性などが怪しい上に,どれも配達日遅い結局必要なさそうだ。

しばらく給湯無し生活する覚悟が出来寝よう思った26時頃ランプいたまま全く反応しなくなっていたリモコン電源ボタンランプ消えていることに気付いた試しに押してみると,あっさり起動して出るようになった。

いずれにせよ交換することになりそうだが,新しい給湯器来るまでってくれることを願うばかりだ。

{いずれにせよ}

{}