;´Д`)< 収拾がつかなくなってきた
現在JavaScript習得も兼ねて進めているプログラムが、だんだん収拾がつかなくなってきつつある;´Д`)
実現方法について色々調べながら対応しているために
- 修正が何度も発生し、ソースが汚くなる
- 別の手段があることを知り、そちらも試したくなる
- 新たな機能があることを知り、それも入れたくなる
その結果、今何をやっているのかさえも分からないことに……;´Д`)
もうちょっとまじめにやらないといけないな。あと、面倒な箇所の実装から逃げ気味なのもまずい。
どうしよう、もう一回設計をやり直すべきかなあ;´Д`) 分かったことも含めて実現方法について設計しなおしたほうが早いかもしれない。
´Д`)< OSDNか…
OSDN (旧 SourceForge)
OSDNのサイト。知らない間にOSDNに色々機能が追加されていた。
いや、元々あったけど自分が知らなかっただけかもしれない ;´Д`)
なんか Wikiが借りられたりするみたいだし、ひょっとして便利かも!?
OSDN site 主な機能
- OSDN magazine
プログラミング関連ニュースサイト - OSDN Blog
ここにも Blogがあるのか ;´Д`) - OSDN コピペ
Gistのようなもの。特徴としては Ascii Artにも対応している点だろうな! - プロジェクト環境一式 レンタル (OpenSourceのみ)
SourceForgeだったころから OpenSource向けに色々提供していた機能。
プロジェクト作成には審査が必要なようだ。 - 作業部屋
プロジェクトほど多機能ではないが、下記が使えるらしい - Version管理機能
- Ticket機能 (Schedule管理機能はないっぽい? Issue管理のみかな?)
- Wiki機能
- File管理機能 (容量はどれくらいなんだろう。Version管理と紐づいているのかな?)
この「作業部屋」というものが結構気軽に借りることができるみたいで。
試しに借りてみようかなあとちょっと思っている。
Blogで使っている 定型Partsなんかを置いて、直接リンクできたら便利かなあとか……。
´Д`)< 色々と思い出すなあ……
過去の日記でExcelに絵を描いていたやつ。あれをゴソゴソと対応している。
しかしやりたいことは絵に描いた通りなんだけど、それを JavaScriptで実現する方法がはっきりしていないから "3歩進んで2歩下がる" を繰り返している状態。書いては消してを繰り返しているからソースも汚い;´Д`)
ただまあゆっくりとだけれど、形にはなってきているような気がする。
……色々と不安な箇所はあるが;´Д`)
スレッドを使ったアプリのデバッグがよくわからん
先日の絵の通りなのだが、なんとなく JavaScriptの "専用スレッド" とかいうやつを使ている。しかしこれが厄介で……。
まず、Local環境の場合、スレッドを使っていると Google Chromeがセキュリティーエラーを吐く;´Д`) どないせえと
ちょっと対応が面倒っぽかったので Edgeを使って進めているが……Worker threadに break pointが貼れない ;゚Д゚)< ナゼダ・・・
いや、貼れるはずなんだ。ただ、貼るための操作方法が分かっていないだけで;´Д`)
そんな感じのえっちらおっちらな感じで進めているが……。
´Д`)< ログ出力を使おう
そうだ今までずっと仕事ではログでデバッグしてきたじゃないか。パソコンだからリッチなデバッグ環境を使わなければならないわけじゃないさ!よい子の味方、console.logさんに頼ってしまおう。
´Д`)< 過去を思い出してしまう
こうしてログを埋め込んでいると色々思い出すことがある。
組み込み系だったから……ってわけでもないと思うんだけど、ログは不具合が発生したときの最後の頼み綱になりかねないものだから、入れる場所、出力する情報にはホントに気を付けないといけない。
過去に何度か「将来のデバッグのためにログを入れておいて」と言われ、思うままにログを入れた結果、ほとんど解析の役に立たないようなログを入れてしまったことがある。もちろんめちゃくちゃ怒られた。怒られたが、結局どう対処するのが正解なのかは分からなかった。
最初にログを入れる場所
「どの場所で発生するか分からない」という不具合を捕まえるために入れるログ。
ソース1行ごとにログを埋め込むか?というとそんなはずはない。後々になってからようやくわかり始めたから、自分が知っていることを少し書いておこうと思う。
なんていうか、ログを入れる目的が不明確なのが問題なのかもしれない、と思ったり。
- 不具合が発生したときに真っ先に聞かれる内容について答えるためのログ
問題が発生したときに聞かれること。それは「#゚Д゚)< どのチーム(どのモジュール)の問題じゃゴルァ」。
自分のモジュールが怪しい動作をしているなら、
- 変なデータを渡されたからなのか
- 他のタスクに邪魔されて動けていないからなのか
- 出力データを渡したいけど輻輳制御で詰まってて……なのか
- 外的要因は考えられないから、自分のモジュールのロジックに問題がありそうなのか
その切り分けを行うために、外部モジュールとの入出力部分にログを入れる。もちろん入力部分は入力してすぐの箇所。出力部分はデータの作成が完全に完了し、相手先へ渡す寸前の箇所。
ひとまずこれさえあれば問題発生モジュールの切り分けはできるはず。
次にログを入れる箇所
モジュール間通信 (http, ftp, Message, pipe, shared memoryなどなど) での切り分けができる情報が出力できたら、次はライブラリ使用部分かと思う。ライブラリと言っても開発言語の標準ライブラリではなくて、他チームから提供されている API 部分の呼び出し前後など。
とにかく問題発生箇所を絞り込んでいける情報が必要になってくる。最終的に自分のモジュール単独問題だと分かったならまずその内容を報告して、詳細解析に進むかもっと他の優先不具合解析になるかはその状況しだいという感じだろうか。
なんにしても "入力データが明確" になっていて、"自分のモジュール内ロジックが問題"だと分かったなら、その入力データを再現させてステップ実行すれば再現できる可能性はそれなりに高いはず。
もちろん "現象発生時はたまたま処理負荷が高くなっていて……" ということもあるだろうけれども、まずは 単純な問題をすぐに絞り込める ようにログを入れておくのが重要かなと。
その他:他チームのログも普段から見ておこう
他チームが不具合解析の助けになる情報をログに仕込んでいることがある。例えば「ログ出力日時」「CPU負荷状態」など。
また、処理負荷が高くなっているときのログ出力パターンを見ておくとか。例えば電波状態が悪い時のログなど。そういう状態ではたいていどこかのタスクがひたすら回り続け、ログを出し続けているはず。そのタスクが自分のタスクより priorityが高い場合に自分のタスクが動けなくなることはないか、動けない状態でMessage queueに要求が積み上げられて、取りこぼしたりすることがないか、など。
;´Д`)< ログと関係なくなってきた
なんだか内容がログと関係なくなってきたのでこの辺で話を切り上げることにする;´Д`) 年寄りの話は長くてすまないネェ……
´Д`)< Editorって何を使ってますか?
様々なことが過渡期の現在。
Web系の技術も、仮想環境も、サービスのあり方も。
そんな現在だから今まで使われてきた開発環境も変化せざるをえないのかもしれない。
使っている開発環境を変えるか、IDE環境側が変わるか。
なんて大げさな話でもないんだけど;´Д`) 前々からサクラエディタに限界を感じていたものの、これといった代わりのものが見つからなくてずるずる使っている状態だった。
サクラエディタ……長く使わせてもらっていたけど、やっぱりファイル保存時のデフォルト設定がShift-JISから変えられないというのは痛いよ……。
日本語Windows環境と共に使われてきたものだから、色々と無理があるんだろうけどね;´Д`) 秀丸エディタもかな。両方とも内部はShift-JISで処理しているとか書いてあるのを見た記憶が。だからマクロでUTF-8を使えないとかいう制限が発生したり。
;´Д`)< ATOM editorって使いづらいよ…
各所で取り上げられ、Pluginも多く開発され、「今どきの開発者はATOM editorが使えないとね!」というこの空気感。使いにくいだなんて言ってしまったらもう「これだから昔の人間は!」だとか「古い技術と共に滅んでください」なんていう罵声が飛んできそうな、すごく居心地の悪い気分。
数週間、無理して使ってみた。ブログの下書きにしたりJavaScriptを書いてみたり。
……でもやっぱり駄目だ。あの「Editorに使われている」感が体にまとわりついて非常に不快な気分になる;´Д`) 全然思うように動いてくれないからさー。
今までのEditorってあんな感じじゃなかったと思うんよ。
高機能なのもいいし、カラフルなのもいいんだけど。自分がEditorに求めるのはそこじゃないんだよね……。
´Д`)< 自分が Editorに求めるもの
自分が求めるのは
「Textが書きたいときにすぐに書き始められる」
「(Binaryでもなんでも)とりあえず一回 Editorで読ませてみようか」
っていう、ひとまずこれで開けば悪くはならないという感じで使えるものなのだ。
毎回毎回Projectのフォルダ構成とか覚えてほしくないんだ。こっちの好きにさせてほしい。そして様々な場所にある様々な形式のファイルを開いてほしい。
けどどちらかというと IDEっぽいんだよね、ATOM editorって。
´Д`)< だから Visual Studio Codeもしっくりこない
そんな感じだから、Base環境が ATOM editorと同じ Visual Studio Codeも使っていて気分が悪くなってくる。やりたいことをさせてもらえない。常に違和感と共に過ごし続けている感じ。気分が悪い。
というか Visual Studio Codeを使うくらいなら初めから Visual Studio Communityを起動するよ。自分なら、ね ;´Д`)
゚Д゚)< そんな Editor暗黒時代の中、一筋の希望の光が!
私ゃもうダメかと思いましたよ、ホントに。
しかしそんな暗黒時代の中、期待のホープが!!
📔 Notepad++
若干老舗寄りな気がしなくもないが;´Д`)
Notepad++とは
外国生まれの、サクラエディタに近い Text editor。
あー、以前職場の環境で使っていたのにな。なんで忘れていたんだ;´Д`)
この Editorも Pluginが非常に多い。仕事で使っていたときは、開発中の実機から出力される Log file (printf等で流しているもの) の解析に使っていたんだよね。Analyse Pluginを使って。
そうだ、これだよ!これなら デフォルト文字コードを UTF-8にできるし!結構使っている人が多いみたいだし!(英語圏の方が多いようだが……)
たぶんこれで今までのような Editor lifeが過ごせるはずだ!
いかがでしたでしょうか?
「いかがでしたでしょうか?」
このフレーズ、急に見かけることが多くなった気がする。CSSやJavaScriptの解説サイトを探すことが多いからだろうか。
原因は分かっている。アフィリエイトサイトによる製品紹介記事か、もしくはブログ参照数を上げようとしているサイトの記事だ。
いや、別に「いかがでしたでしょうか?」という言葉自体には何の問題もない。作成された記事について、どういう感想を持たれたでしょうかという内容なんだから。
しかしその肝心の記事が……。世の中にはすごい記事もあって、
「この〇〇社の新製品!すごいですねスペックも前の機種より上がっています。私は別メーカーのものしか持っていませんが興味がありますね。この新製品、買いだと思います! いかがでしたでしょうか?これからも新製品や使いやすいものを云々……」
いかがでしたでしょうかって。なんとも思いようがない記事でしかない。
製品レビューですらない。メーカー発表スペックを読み上げて自分の感想言っただけの内容について「いかがか」と聞くのか。
CSS解説サイトでいくつか見かけたものは
「最近は〇〇デザインが流行です。こちらのサイトではこんな装飾を紹介しています。こちらのサイトではこんな装飾を紹介しています。こちらのサイトではこんな装飾を紹介しています。 いかがでしたでしょうか?技術トレンドは刻一刻と……」
いかがでしたでしょうか。……いや、こんな記事をあげた上に読み手に「いかがか」と聞く行為がいかがかと思うよ。
様々なサイトの良い記事の紹介記事が悪いなんて全く考えてはいないけど、それでもあまりにも内容が無さすぎたり。せめて紹介した記事の内容について補足するなり解析するなり発展させるなり自分の考えを書いてみるなりしてもいいものだと思うが……。
この文言自体、記事内容からまとめへと移行するためのテンプレート文字列なのだろうとは思うものの、もう少しなんとかならないか?と思うことが何度かあった。
この、まとめへ移行するための文言が「読み手に対する問いかけ」だから余計に引っかかるんだろうな。読み手としては。
´Д`)< 何か作ろうかと考えてみる
JavaScriptをやらねばと思いつつ脱線し続けること数週間。
そろそろJavaScriptに再チャレンジしようかなと考えている;´Д`)ツヅクカナ
でもまあ脱線したことで得た知識も役に立ちそうだしいいかな。ブラウザアプリを作る場合は、CSSでできる部分は極力CSSでやったほうが良さそうということが身に染みて分かったし……。
画像配置ツール再チャレンジ
前回、JavaScriptに対する理解不足から中断を余儀なくされた画像配置ツールについて再チャレンジしてみるかな。
やりたいことは決まっていて、お絵かきツールほどの自由度はないけど、既存の画像の追加・移動・変換ができる程度のものを。HTML5でできる範囲で。
たぶん、だいたいこんな感じになるんじゃないかなと。
(左右に記事スクロール操作のための余白を設けています)
どうだろう……。
というかExcelの埋め込みって、資料の表示倍率指定とかできないのか;´Д`)
普通に埋め込むと大きく表示されすぎるからわざわざ 1/2に縮小して表示してます。めんどい。
あと、埋め込むときに表示するsheetを指定できないんですかね;´Д`)絶対見逃すと思うよ、コレじゃあ
Undo / Redoについて
作り直すにあたって最初に考えなければならないのはコレらしい。
なんというかJavaScritpは関係ない内容になるが;´Д`)
Undo / Redo処理について今まで考えたことがなく、前回作成時も「最後に考えればいいかな」という感じで先に重要と思われる機能から考えていったんだけど。
このUndo / Redo、こいつらは地味なくせに一筋縄ではいかない超めんどくさい機能なようだ;´Д`)
まず、今まで様々な技術系サイトを見てきたけれどもUndo / Redoを自動化してくれるライブラリってほどんど聞かない。……なぜなら applicationの内部処理と深く関わるからなのだ;゚Д゚)< だからこそ初めに決めておかなければならない
Undo / Redo概要
ネットで記事を探し回ってわかったこと。
- 内部処理を「コマンド化」する必要がある
- コマンド処理するために必ず通すゲート役がいる
- ゲートを通った時に処理したコマンドをUndoListに積む(逆操作へのコマンド変換が必要)
という感じ。
つまり、Undo / Redoを実装しようとすると 根本的なApplicationの内部処理がだいたい決まってしまうのだ ;゚Д゚)!!
……という流れで上のエクセルのような図を書いてみた。それにしてもエクセルの埋め込みって見づらいな;´Д`)