(565)
{希哲14年8月23日}{希哲14年8月23日のツイスト}{出場}{多糸}{デライト}{ツイスト}{外充て函数}{開発言語}{軽快}{最適化}=}(15)

今のデライト早まった最適化を避けてきたこともあり軽快とはいえないが,独自開発言語C++ を基礎にしており,多糸マルチスレッドFastCGI で動いている。出場(DB)側も Cμ で外充て(ストアド)函数化している。いくらでも最適化出来る。

2020-08-23 18:18
=}
{value()}{有効値}{希哲14年8月22日}{希哲14年8月22日のツイスト}{iffy_}{参照}{ツイスト}{問題児}{如零許容型}{std::optional}=}(14)

最近,如零(ヌル)許容型 iffy_問題児化しているので,有効値のみを参照する val() でも持たせるか,と考えていたのだが,C++std::optional でも同じ意図で value() があるのか。結局,考えることは似てくるものだな。

2020-08-22 22:16
=}
{指示型}{IP アドレス露出不具合}{希哲14年8月21日}{美しくない}{仕様検討}{輪符}{握接}{iffy_}{検討}{別途}=}(44)

半休にして一昨日からのまとめをしていたため,作業は出来なかったが,いくつか仕様検討が進んだ。

まず,先の不具合反省から,指示型p_)や如零許容型iffy_)で安全間接参照する方法について検討

最初は間接参照演算子上積みすることを考えたが,伝統的記法極力踏襲したいこと,非如零であることが自明な時にオーバーヘッドを避けて握接する手段も残したいため,別途val() のような道手を持たせる方向で検討を続けることにした。

以前から何とかしたかったマウスオーバー時の輪符展開動き付けについても,展開したい部分を spn 要素で囲っておけば,下装書animation 等を使って十分表現出来ることに気付いた。以前,滑らかに展開させるためにスクリプト側で文字列操作をしようとしたが,明らかに美しくない方法なので断念していた。

2020-08-22 01:32
2020-08-22 01:18
=}
{希哲14年8月10日のツイスト}{希哲14年8月10日}{自我情報}{ツイスト}{希哲社}{外充て函数}{論組言語}{独自}{PostgreSQL}{定義}=}(13)

これは希哲社独自開発した論組(プログラミング)言語 で,デライト自我情報を取得する PostgreSQL 外充て(ストアド)函数定義しているところ。自分で作っておいて何だが,が宿ってるな……。

2020-08-10 18:15
=}
{希哲14年8月10日の画面記録}{dg_ego()}{}=}(3)

2020-08-10 18:10
2020-08-10 18:09
=}
{希哲14年8月1日}{希哲14年8月1日のツイスト}{文字情報}{デライト}{ツイスト}{成り立つ}{黒字化}{軽い}{開発言語}{集客}=}(18)

デライトは,色々な意味で「軽いサービス文字情報だけで成り立つし,個人情報も扱わない。独自開発言語C++ が基礎で最適化もしやすい。それこそ動画共有サービスなんかと比べれば黒字化は遥かに。後は集客出来るかどうかだけ。

2020-08-01 18:45
2020-08-01 18:44
=}
{希哲14年7月25日の開発}{ls.syml}{lis.syml}{ls}{輪結リスト}{lls}{希哲14年7月25日の進捗時限}{希哲14年7月25日の進捗}{希哲14年7月25日}{左下吹き描き}=}(30)

前後景一覧整備,左下吹き描き実装続き。

途中で終了。

lis.syml を見ていて,交度英語における lis再考lst から移行してしばらく使っていたが,として中途半端なのは交語の性質上仕方ないとして,ls がよぎってしまうのでどうにも使いにくかった。もともと,vec_map_ の並びで語感が良く見えたというのも採用した理由だったが,vec_ も arr_ になっている今,それほどこだわる部分ではない。この際,〈list〉ls で統一してしまうことにした。輪結リストの意なら lls としてもいい。

lis.symlls.syml練名

2020-07-25 12:37
2020-07-25 12:36
=}
{公開連絡先}{暗証語忘れ対策}{ツイート埋め込み}{Twitter Publish}{一括挿入}{希哲14年7月16日}{渡括記法}{描写選り手}{描き直し}{非同期化}=}(45)

今日は前後景輪一覧実装を始める予定だったが,深刻不具合などに気を取られ準備程度のことしか出来なかった。

しかし,交度整理しながら描写選り手周りの改良をよく進めることが出来た。特に,描き直し挙動はこれまで自分で気に入らないところだったので,洗練されたのが嬉しかった。

以前から怪しかった AdSenseAejs干渉問題も根本的解決策を施すことが出来た。

昨日の開発記録をまとめていて,公開連絡先を使った新しい暗証語忘れ対策を思いつき,この方向でまとめていくことにした。

もう一つ大きな作業方針上の進展として,自我登録時の知番予約改良一括挿入バルクインサート)から試すことにした。初歩的なことだが,余裕がなかったのか 外充て函数過信していたのだろう。これも灯台下暗しだった。ずっと非同期化の方向で検討していたが,そもそも非同期化しないと困るような処理が自我登録のたびに走っていたら捌き手がもたない,かといって予約範囲の分割も煩雑化を招く,といった懸念があったため,これで済めば万々歳だ。

その他,Twitter Publish+ 記法を使ってツイート埋め込みをする方法について検討など。

2020-07-17 00:05
2020-07-16 15:31
{希哲14年7月16日の開発}{希哲14年7月16日の進捗時限}{希哲14年7月16日の進捗}{希哲14年7月16日}{手定め}{選り手}{描写欄}{溶暗}{不具合修正}{Aejs}=}(32)

知名変更時の不具合修正続き。

いったん終了。

一通り手定めし,問題ないように見える。かなり無駄の多かった Aejs 間の通信を大きく整理したので,保守性向上

ついでに,ずっと気になっていた描き直し時の挙動も大きく改善した。

これまで,描写欄保存すると一瞬で選り手が消え,一瞬描写ソースが見えた後で正しい表示に更新されていた。これも Aejs未整理原因だったが,今回,選り手が溶暗してすぐに正しい表示で更新されるようになったため,描き直し時のごちゃごちゃした違和感が無くなった。

2020-07-16 19:32
2020-07-16 19:25
=}
{大変さ}{氷山の一角}{希哲14年7月1日}{希哲14年7月1日のツイスト}{しんどい}{希哲館献典整備}{12年}{ツイスト}{楽しい}{蓄積}=}(11)

希哲館献典(コンテンツ)整備,約12年蓄積今年3月から公開しだしたので,楽しいしんどい。この画像にある というのが氷山の一角のそのまた一角だと言えば,大変さが分かってもらえるだろうか。

2020-07-01 17:54
=}(1){あれ}
1