/ 最近 .rdf 追記 設定 本棚

脳log[2017-09-08~]



2017年09月08日 (金) [SakuraEditor] ツールチップがおかしいよね。選択した単語のヘルプがマウスカーソルのそばに出る。そこじゃないよ。■メニュー>設定>キーワードヘルプ自動表示するを選ぶと(※この設定をソースコードで見つけて、どこで設定できるのか探した。iniには書き込まれない揮発性の設定みたいだ)、選択しなくてもキャレット付近の単語の説明が出るんだけど、ポインタの先の単語じゃないんだよね。ポインタのそばに説明が出るのに……。■ポインタがビューの上にないときには表示しない処理もあるんだよね。表示するのはポインタではなくキャレットのそばの単語の説明なのに。■誰かのこだわりの結果なのかなんなのか。普通じゃないね。■2.3.1.0で補完をすると、例えば サクラ を入力してから補完ウィンドウを出して サクラエディタ を選ぶと、サクラサクラエディタ みたいに補完されるのだけど、trunkをデバッグモードでコンパイルしたものがたまたまあるので試してみてもそんなことは起こらないから、何かの設定のせいなのか、よくわからないうちに直ったのか。■単語検索といえば昔のはてなダイアリーは豪快だった。サクラエディタも Trieとか接尾辞配列とかを導入したら、予め決めた単語境界に基づいて抽出した単語を登録済みキーワードと比較するのではなく、もっとアグレッシブに編集中のテキストから登録済みのキーワードを見つけ出せるのに。……とかいって俺には難しすぎるデータ構造だから他人事(ひとごと)だよ。手を動かして理解する手もある?

最終更新: 2017-10-01T01:05+0900

[SakuraEditor] ツールチップ>a.patch

  • ベースは https://svn.code.sf.net/p/sakura-editor/code/sakura -r 4196
  • +1007行, -760行。増えた……
    • CEditView.h, CEditView.cpp, CEditView_Search.cpp, CEditView_Mouse.cpp に限定すると +28行, -429行。圧倒的に減った(ファイルが2つ増えてるんだから多少はね)。
    • 新ファイル(AsWithHelpTooltip.h, AsWithHelpTooltip.cpp)合計が 714行。
    • 目的は減量ではなく機能単位での CEditViewからの切り出しだから……。
  • class CEditViewから消えたメンバー一覧
    • BOOL KeySearchCore(...); publicだが privateにできる。
    • bool MiniMapCursorLineTip(...); publicだが privateにできる。
    • enum LID_SKH {...} publicだが privateにできる。
    • BOOL KeyWordHelpSearchDict(...); publicだが privateにできる。
    • bool ShowKeywordHelp(...); public
    • DWORD m_dwTipTimer; public
    • CTipWnd m_cTipWnd; public
    • POINT m_poTipCurPos; publicだが privateにできる。
    • CDicMgr m_cDicMgr; publicだが privateにできる。
  • 代わりに継承元がひとつ増えた
    • class CEditView: public AsWithHelpTooltip<CEditView>
      • この名前ちょっと微妙? AsSelectable みたいなのを想定した命名規則なんだけど。
    • 基底クラスだけど仮想のデストラクタはない。インターフェイスではないし、public継承されたのもたまたまで、想定される使い方では必要ないはず。
      • 「public継承されたのもたまたま」

        理想を追求する人は private 継承して public 部に using AsWithHelpTooltip::XXX を並べるなり、継承ではなくコンポジションを選び一行だけの委譲関数を書くなりすると思う。というわけで、public 継承している現状に対応して AsWithHelpTooltip::OnTimerAsWithHelpTooltip::OnMouseMove をクラス外部から隠す目的で public から protected に変更するのは間違い。public と private と protected が混在することになるという一事をもって即座に間違いだと気付くべきところ。

      • protected 継承のことは知らない。virtual だとか菱形だとかの継承も難しすぎてわからない。
  • [新機能] メニュー>設定>キーワードヘルプ自動表示する を有効にすると登録キーワードをポイントするだけでヘルプツールチップが出る。
    • その際ツールチップの X座標は単語が始まる場所で、Y座標は注目している行の1.5行下。
    • キャレットを動かしたときも同じ位置に出せるんだけど、そこは互換性。知っていればポインタという定位置にヘルプが出るのも悪くないかもしれないし。
  • [違う所] ビューの境界ギリギリでツールチップを表示したあとポインタをビューの外に持っていくとツールチップが消えないことが本家ではあったがそれがない。
    • ミニマップ(これもビューの一種)のツールチップは必ず消えるんだけど、どういう仕組みによるのかはわからなかった。
    • ミニマップのツールチップはメインメニューが展開しているときにも出る。これは m_bInMenuLoopTRUE にならないからなんだけど、なぜミニマップだけなのか。
  • [気付いた点] CTipWnd::ComputeWindowSize()CTipWnd::DrawTipText() の中で DrawText() の引数 pszWorknew してるけど、DrawTextはサイズを指定する引数も受け取るから _T('\0') を埋める必要も new する必要もないよね。
    • というのが DrawTipText() というひとつの static 関数に反映されてる。

 何がしたかったのか

CEditViewの問題は(ANSI版よりずっと改善したとはいえ)あらゆる機能がひとつのクラスに同居していることなので、publicが privateにできたからといってなんの安心材料にもなりはしない。試したかったのは1機能1クラスで CEditViewを拡張する方法。20091129p01とか20131130。新機能はただの余録。そういうのも簡単にできるよねっていうお試し。

個別機能クラスが結局は CEditViewのすべて(継承元である他の個別機能クラスを含む)に依存できそうなのがちょっと予想外だった。機能と機能の絡み合いがだんだんと窮まってきそう。privateデータメンバー(※)を狭い範囲に閉じ込めて守りやすいのだけが利点か。

※publicデータメンバーもメンバーアクセスを代行するだけのセッタゲッタもありませんよ。それを当然の前提にして privateデータメンバーに注目してる。

 述懐

たまたま目についたひとつのメンバ変数 m_cTipWnd を分離してやろうと思って初めてキーワードヘルプや補完機能をセットアップしてから、コードの絡み合いを解きほぐして再構成するのに一週間ちかくかかってる。これでは、とりあえず一か所に、とりあえず public, friend にしたくなるのもわかる。あえてクラスを分けてアクセスを制限して、その結果に頭を悩ませたい人間がいるだろうか。いやいるし必要なんだけど、結局自分の能力でできる範囲のやり方しかできない。この a.patch だって自信満々で晒してるわけではなくて、むしろクラス設計は迷いまくりで、AsWithHelpTooltip.GetLastHitKeywordDictionary() なんて行き場のない妥協の産物である。正しい設計なんてのは与えられればそれ以外に考えられないくらい当たり前のものに思えるのに、自分でそこにたどり着くのは難しかったりする。高校数学の問題とかがそう。解法をチラ見すれば解ける。しかし独力ではなんのとっかかりも見つけられない。

最終更新: 2017-11-04T18:59+0900

[C++] オブジェクトメンバーの持ち方。初期化と再初期化。参照とポインタ。

クラスを書くときの理想として、コンストラクタでメンバーを初期化して以後は変更したくないというのがある。メンバーの状態は自身の行動の前提条件であり、そこが流動的ではあらゆるメソッドが事前に前提を確認してからでないと本題に入れなくなる。コンストラクタで準備の完了と条件の確認をすべて済ませておきたい。そこが動く、動いたなら、それはパラメータを変えた別のインスタンスに任せたい。

上で登場した AsWithHelpTooltip というオブジェクトは CTipWnd というオブジェクトをメンバーとして持っており、寿命を共にする。CTipWnd のサイズ(を始めとするその他諸々)を隠したいならポインタ(か参照)一択だが、そういう制約がないなら new CTipWnd の手間を避けて、AsWithHelpTooltip のサイズに CTipWnd のサイズを丸々含めるような持ち方をする。

初期化である。AsWithHelpTooltip とそのメンバーである CTipWnd は As~を継承する CEditView の初期化(ウィンドウ作成など)を待たないと初期化が完了しないので、As~のコンストラクタでは呼ばれるのが早すぎる。また、CEditView はコンストラクタとは別に Create という名前の初期化(リセット)関数を持っている。であれば As~にも Create という名前の初期化関数を生やして CEditView の Create から呼んでもらうというのが自然な流れ。As~はそれでいい。そのメンバーである CTipWnd にも Create の連鎖を波及させるべきだろうか。CTipWnd は小さな部品であり、そこそこ汎用性もある。そこに、外部の都合で、リセット関数という全く不要で全ての前提を覆す邪悪なメンバーを生やしてもいいものだろうか。

代入演算子を定義しようか。しかし代入は邪悪で避けるべきものだ。なにより外部のリソースを作成するときに使用したパラメータは、コンストラクタの中で使用するのみで以後は不要なので保存していない。代入なんかのためだけに余計な荷物をしょいこむなんてまっぴらごめんである。

ではやはりポインタだろうか。Create 関数が呼ばれるたびに new CTipWnd でメンバーのインスタンスを作り直そうか。こういうとき参照は使えない。参照はコンストラクタで初期化するしかできないし、初期化しなければいけない。そこが参照のポインタとは違う参照たる所以であるので不便でも不満でもない。しかしポインタには不満がある。ポインタは無効な状態(nullptr)を許容する所が参照とは違う点で、今回の As~と CTipWnd の関係ではそういう無効な状態の入り込む余地などないのだから、CTipWnd をポインタで持つというのは意図や前提の過不足のない表現として不適切で不満がある。

結局 As~の Create 関数の中でこうやって CTipWndを再作成したんですよ。

m_cTipWnd.~CTipWnd();
new(&m_cTipWnd) CTipWnd( G_AppInstance(), asView(this)->GetHwnd() );

代入なし、(CTipWndに)リセット関数なし、new なし、ポインタなしで満足してるんだけど、何かの本で読んだテクニックというわけではなくて、どんな落とし穴があるのか戦々恐々としてる。普通の new ですら使うのが怖くてできるだけ見えないように(STLを使ったり)するのに、placement new なんてとてもとても。

 @2017-09-28 placement new より swap

picojsonというパーサを読んでいます。分からないのは、以下に該当するコードです。deleteしていないのに、配置newしたオブジェクトがメモリリークしないのはなぜなのでしょうか。

inline value& value::operator= ( const value& x ) {
    if( this != &x ){
        this->~value();
        new (this) value(x); // thisの寿命はどうなる?
    }
    return *this;
}

ほぼ同じ2行だ。そして picojson は知っているし信頼できるソースだ。だけど検索したら現在の picojson にはその2行がない。こういうことらしい。

make operator= safe when part of LHS is being assigned, as well as ex… · kazuho/picojson@96f6c81

exception-safe はわかる。破壊と構築がアトミックでないから、構築し損ねた荒れ地にさらにデストラクタが走る可能性がある。

でも when part of LHS is being assigned っていうのがわからない。さへんのいちぶぶんにだいにゅうされているとき?

 @2017-10-30 placement new より swap (続き)

c++ - Can I use placement new(this) in operator=? - Stack Overflow

ある回答者によれば『Exceptional C++』で言及されているらしい。もう一度読もうか。

その回答に補足して、継承とスライシングに関わる問題が placement new を使った手法にはあるとも指摘されている。picojson の主な理由もそれだったのかもしれないけど、よくわからん。

ある型の代入演算子の中で自身のデストラクタを呼ぶとき、それが仮想であるならば呼ばれるデストラクタは派生クラスのものであるかもしれず、placement new で新しいインスタンスで上書きするときに派生部分の初期化が行われない、と。そのようにコードを呼んだ側も呼ばれた側も意図するところは「ある型」部分に限った代入なので、仮想のデストラクタを呼んだのが間違い。

『[単行本(ソフトカバー)] Jaroslav Tulach【APIデザインの極意 Java/NetBeansアーキテクト探究ノート】 インプレス』を読んでその苦労を垣間見るけど、派生クラスは難しい。派生が可能なクラスを公開して、それを互換性を保ったまま改善するというのは、ほとんど不可能なのではないかと思えるほど。どれだけ注意を払っても余分なコードで対策しても、得られるのは「ソースコード上の」とか「バイナリの」とかいう条件付きの互換性なんだからやってられない。

 @2017-11-02 placement new より swap (続きの続き)

『Exceptional C++』の項目41がそのものずばりでアンチイディオムとして取り上げており、すでに述べた2つ以外にもこれでもかこれでもかと否定の論拠を挙げていた。C++怖い。そして、「何かの本で読んだテクニックというわけではなくて」とか書いていたのは誰だっけ?

実際のところ、a.patch のケースでは例外安全性以外の問題はないと思うんだよね。Exceptional C++ のケースも picojson のケースも、継承を伴う代入演算子の話だし。問題があるのはたしかで万事うまくいく解決策もあるのに、あえて危険な手段をとったのが知識と思慮の不足ゆえなのは否定しようがないけど。


2017年09月06日 (水) Unreal Engine採用タイトル増加の理由は? ゲーム以外でのUnreal Engineの使われかたは? Epic Games Japan代表に聞く(1/2) - ファミ通.com」■Unreal Engine 4は「増築につぐ増築」だった 3からガラッと作り直したらしい。最近よく名前を聞くけど、必ず Unreal Engine 4 なんだよね。ラストレムナントが使っていた Unreal Engineのバージョンは 3 で、「開発当時はEpic Gamesに日本支社がなく、ドキュメントも全て英語で書かれていたため、翻訳と時差に翻弄される開発となった。この出来事は後にエピック・ゲームズ・ジャパンを設立させるきっかけにもなっている」と書かれている。■ページを繰るのにスクリプトを要求するサイトはまあ珍しくはなくて、そういう場合はまず CSSを切ってみて隠されていたテキストが表示されないか確かめてみるのだけど、ファミ通.com は他に例のないパターンで、非表示の div要素の内容として JSON形式で全ページの HTMLが入っている。ロックだね。■作家の古橋秀之という人の Webサイトが、スクリプトと HTMLの境界がわからなくなるような不思議な造りだったと思ったんだけど、今はもう違うみたい。今でもツールの痕跡のない 1990年代風 HTMLが味わい深いページではあるけども。


2017年09月01日 (金) 書誌情報の「脱アマゾン依存」を! « マガジン航[kɔː]」■これはね、本当にある。書誌データにリンクするとき、書影を出すとき、ISBNからタイトルを引くとき、読んだ人の感想を確認したいとき、いずれもアマゾンが一番に来る。なんならそのまま購入もできる。新刊はもうアマゾンで買ってないのに、リンクはアマゾンになる。■アマゾンならキーボードも同じように扱える>20170826p01。これも FILCOキーボード工房で直接買ったけど、画像を伴ったリンクはアマゾンのものになった。■でも本以外の商品写真については共有データは有害かも。どの通販サイトでもメーカー提供なのか同じ画像ばかりで得られるデータが少なすぎる。色味とか質感とか張りとか、服を買うときに本当に参考になるのは個人の購入ブログを複数比較することだったりする。たった1枚のベストショット(下手したら実写ではない)だけでは決め手に欠ける。


2017年08月31日 (木) 「このパイロン、運転席に座ると1本も見えないんだぜ…」車の死角を分かりやすく表現した写真が話題に - Togetterまとめ」■車に乗らない人が知っておくべきなのは、運転者の顔が見えないなら運転者から自分は見えていないってことだけでいいのでは? 顔が見えているから、目があった(ように思えた)からといって見られているとは限らないのも矛盾しない事実だけど。■運転者だけどこのコーンの画像には驚いた。前方の倒れた青いコーンはセダンだからこそだよね。1M先の地面が見えるような車しか運転したことない。くわえてシートは前に出して背もたれは完全に起こしてシートベルトが邪魔に感じるくらい(実際ときどき引っかかって邪魔をする)上半身を動かしてミラーや周囲を確認してる。バイクのヘルメットをかぶるだけでも視野が狭まって首を振る頻度が増えるのに、車の運転席はさらにその上をいく視界の狭さとそれを解消する方法のなさが不安でたまらない、という一番最初の感覚を慣れで忘れないようにしたい。■ちょっと前に右コーナーの対向車(こちらからは左コーナー)にぶつけられそうになった。相手がこちらに向かって走ってくるというのは一瞬パニクる恐怖。右ハンドルで右コーナーだと対向車が Aピラーに隠れたままになるんだよね。くわえてコーナーの外周に沿って走ることができない横着者・へたくそが少なくない。■カーブのことをコーナーって言う人って……、というのをちらりと見かけたことがある。でもカーブって言葉が出てこないんですよ。カーブしてる道路のことをコーナーだと認識してるんでないかな。


2017年08月26日 (土)

最終更新: 2017-09-01T03:21+0900

[COSMOS] 新しいキーボード(赤軸・テンキーレス)が来た。

FILCO Majestouch 2 キーボード工房 越前漆塗りモデル 91 テンキーレス CherryMX 赤軸 日本語配列 側面印字かななし USB&PS2両対応 Nキーロールオーバー対応 漆 赤金砂子塗り FKBN91MRL/NFB2-AKS FILCO Majestouch 2 キーボード工房 越前漆塗りモデル 91 テンキーレス CherryMX 赤軸 日本語配列 側面印字かななし USB&PS2両対応 Nキーロールオーバー対応 漆 赤金砂子塗り FKBN91MRL/NFB2-AKS

ダイヤテック
¥ 21,800

 今のキーボード

ダイヤテック マジェスタッチNキーロールオーバー カナなし 黒軸 FKBN108ML/NB ダイヤテック マジェスタッチNキーロールオーバー カナなし 黒軸 FKBN108ML/NB

ダイヤテック
¥ 9,882
2009年からちょうど8年間くらい使ってる。最近ときどきあるキー(Nだったり Tだったり)が全く入力できなくなったり、Enterキーが2重に入力されたりしていて、ケーブルの断線を疑っていた。Enterキーが特に致命的で、日本語変換をしていて確定と同時にフォームが送信されることがたびたびあって、精神衛生上大いに問題だったので急いで新しいメインキーボードを調達したというわけ。

前々から赤軸とテンキーレスと漆塗り筐体に注目していて(20140103)、でも何枚もキーボードがあっても死蔵するだけだしと諦めていたので、渡りに船だったというのもある。

 赤軸

リニアで重たい黒軸の低反発バージョン。たしか前のキーボードを買ったときにはまだなかった。以前黒軸を「キータッチは重い。努力の必要なく底付きが避けられるほど。Realforceみたいなのをバチバチ叩かないための打ち方矯正キーボードではないか」と書いたのだけど、もはや矯正は完了したと思われるので低負荷の赤軸を使ってみたかった。(Realforceは PS/2接続が選べなかったり、Winキーが抜けていたりしてちょうどいいのがなかった。Winキーに関して今は違うとしても遅い)

日記を書いたりプログラミングをしてるときっていうのは案外考える時間が挟まることで適度に手が休んでいるのだけど、用意された原稿を PCに入力するみたいな単純で連続したタイピングではそれがなくて、手のひらが強ばって痛み出してくる。それが赤軸では軽減されるのではないかなと。なかなかそういう機会もないけどね。

黒軸でタイピングの調子が良いときはリズムがある。両手を上から下へ下ろす大きな動きがあって、その動きの間に両手の指がもにょもにょっと動く。ペチペチでもタタタンでもなく、もにょもにょっというのがポイント。そしてまた両手を持ち上げて、タイプする内容を確認して、一瞬の溜めで運指の計画が作成されるのを待ち、下ろす。

 テンキーレス

それほど深刻ではないスペースの問題。実際のところテンキーは有用。数字や日付の素早い入力が可能だし、マウスキー機能でマウスがない非常時でもポインタの操作が可能だし、Home/End/PgUp/PgDn/Del/Ins/↑/→/↓/←キーの代わりができるし、右下隅という狙いやすい位置にエンターキーがあるし、複数行コメント(/*...*/)を隣り合った2つのキーを連打することで開始できる。自分はこのように日々必ずテンキーを使っている。トラックボールを左手で操作しているので右手のマウスがテンキーに押しやられて遠くなりすぎるなんてこともない。テンキーは有用。だけどなくても困りはしない。どうしても欲しければテンキーだけを追加することができるが、たぶんそこまではしない。そういう存在。

フルキーボードから移ってきて、キー配置は標準的なものの意外にも打ちにくさを感じる。無意識にキーボード右端からの距離を測っていたようで、Home/End/PgDn/PgUpキーを押すときに指が右端から落ちそうになるのを恐れてためらってしまう。すぐ慣れるといいが。

 Majestouch 2

前のキーボードはスタビライザーがちゃりちゃりうるさいと書いたが、これはそんなことがない。キーを外してみたらグリスが塗ってあった。考えることは同じか。

 キートップが真っ黒で前側面に印字

自分が普段いかにキーボードをチラ見していたかを知る。ちょっと打ちにくい。特にテンキーに頼っていた数字が。

キャップの重さでタイプの感じが変わるので、赤軸の標準の感触を確かめてから2色成形のキーキャップに変えるつもり。そちらは普通の天面印刷……印刷ではないけども。

キャップの高さが2色成形と付属のとで違うのを利用して、Altと Winキーだけ低めのキャップにしてる。どちらもうっかり触るとうっとうしいことになるキーなので間違えないように。

 USB・PS/2兼用

USB・Bluetooth兼用タイプならケーブルが脱着式で断線しても交換が可能なのになぜ? PS/2なら BIOSで設定したホットキーで PCの電源が入れられる。スタンバイ(S3)からでも休止状態(S4)からでも。シャットダウン状態からでもたぶんできたはず。いずれもマザーボードによる。

PS/2延長ケーブルと付属の PS/2-USB変換コネクタを通してキーボードをつないでるけど、キーボードと変換コネクタの間は普通にプラグアンドプレイしてる。PS/2なのに。

 

印刷との違いをどこに見出すか考えてしまう。漆は表面処理であって材質はプラスチックで変わらないし、素材を水分から守るという実用性が期待されているわけではないし、機械による印刷よりもデザインに制約がかかりそうだし、印刷にコピーされたとしても優る価値とは。画像だけを頼りに選ぶのは難しい。しぶき塗りと漆黒と悩んだ結果、金粉というマテリアルで選んでみたわけです。それを言ったら漆も特徴のあるマテリアルだけども、あんまり滑らかでわかりにくいよね。現代は安価な代用品がいくらでもある。

矢印キーの上の平面で右手を遊ばせたり指先でコツコツ叩いたりするのだけど、そこにあばたがあるのですね。わざわざ粗を探したりしないし、他の場所であれば、また、目であれば見過ごしていただろうけど、指先を欺くことはできないのだった。気になってひっかいてしまう。画竜点睛を欠く感じ。


2017年08月25日 (金) ブコメにコメントする。「「メソッドは必ずインスタンス変数を使う」には全く同意できない。データだけしかないオブジェクトは設計ミスだがデータを持たないロジックのみのオブジェクトは存在し得る。デザパタにだってある。」■ない変数を用意しろとまでは言ってないと思うんだよね。俺が聞いたことがあるのは、メンバ変数を使わないようなメンバ関数をクラスにつっこむな、ってなもの。それは使いもしない暗黙のパラメータを受け取り、実際はどうあれそれと結びついたメンバのすべてを入出力に利用できるという宣言だから、関数の理解を難しくする。クラスの公開メンバにだけ頼って実装できるようなものは、C++だとクラスと同じ名前空間のフリー関数にする、C#だとエクステンションメソッドにするなどできる。それより関係の薄いメソッドなんだとしたら、それこそなんでクラスのメンバーにしようとしたのか百遍問い直すべきだろう。こういう場合 Javaでどう書けるかが重要? それは知らない。■元ネタの本『[単行本(ソフトカバー)] 増田 亨【現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法】 技術評論社』付箋を付けて読んだ人のメモを斜め読みしてもまともなことが書かれてるのがわかる、というのはつまり、自分がまともだという前提で同意できる内容だってことだ。しかも視点が実際にコードを書く人間のそれなので退屈しそうにない。ちょっと買ってきた。■書いた人のことは知らないんだけど、「日本のDDD(ドメイン駆動設計)界の父」だとか「DDDについて調べたら必ずスライドが出て来る」というような人らしい。参考文献には読んだものや読みたいと思ってるものがいくつかあったけど、DDDに関する本は一冊も読んだことがなかったのだった。この本のあとで読んだら「これがそうだったのか」ってな発見があるだろうか。■もはや一年に数回も行かなくなった久しぶりの本屋で嬉しくなって、前から興味があってすぐにも読みたい(でもすぐには買わなかった)本を他に2冊だけ選んで(※重さと体積による制約)買ってきたのだけど、なぜか3冊とも gihyoになった。元気があって良いですね。『Optimized C++』(これはオライリー)も手に取ったんだけど、退屈そうに感じて戻してしまった。網羅的・教科書的に書こうとしていたのだとしたら、そのせいで新たな発見が埋もれていた可能性がある。効率を考えると悩む。■どこかの感想で触れられていたボキャブラリがどうのっていうのは何かの本で読んだなと思ったけど、何の本だったか見つけられない。この中のどれか☞または☞。出版社のリンクをクリックしてみると技術評論社が19冊でトップシェアだとわかる(ってそれは今日だけで3冊増えたからだ)。■オブジェクト指向色が濃すぎるというブコメも読んだ。ドメインの知識を整理する手段としてアスペクト指向でも書けるといいね。『Multi-Paradigm Design for C++(の日本語版)』とか『ジェネレーティブプログラミング』とかを出したくなるけど、実務や対象読者からは離れすぎてしまうのかも。■@2017-09-04 面白かった(スライドの感想)。規格外の人間ってやつになりたいものだ>「“一般的なSI現場”の定義...(略)...それなりのフレームワークを使用し、規約やレビューで、極端にひどいコードが生まれないように統制するものの、それを突破する規格外のポンコツが必ずいる」(『現場で役立つシステム設計の原則』は一般的なSI現場で役立つのか? より)■@2017-09-15「PHP Mentors -> 「現場で役立つシステム設計の原則」批判 (2) ~ポリモーフィズムは何のために?~」 どうせ大上段に構えただけの難癖なんでしょと思って読み始めたんだけど、公平で真っ当な内容に思える。本を補完するつもりで読んだらいいんじゃないかな。本を読むときに俺はもう自分の定義を持ってるからオブジェクト指向かくあるべしみたいな論には興味がないし、部分部分で「そこは同意できないな」で流してしまうんだけど、そういう部分について、教育的視点で見るとそれってどうなの、という批判だと読み取った。すごく読みやすくて間口の広い本だけに無視できない批判かなと。


2017年08月19日 (土) 数か月ぶりに体重計に乗ったら 40kg台まで数百グラム! 食べないからだよ。夏バテ一直線!


2017年08月17日 (木)

最終更新: 2017-08-18T03:28+0900

横軸に期間を並べて、項目ごとに色を分けた折れ線グラフを重ね合わせたいとする。たぶんエクセルだと、表の範囲を選択して右クリックしてグラフを作成する、みたいな操作でグラフが作れるんじゃないかと想像する。そのとき選択する表の形式はたぶんこう。

2017年4月2017年5月2017年6月
項目11.41.51.6
項目22.42.52.6
項目33.43.53.6

このとき(20170223)に仕入れた概念に整然データというのがあって、RDBから自然に得られる表はたぶんこう。

項目12017年4月1.4
項目12017年5月1.5
項目12017年6月1.6
項目22017年4月2.4
項目22017年5月2.5
項目22017年6月2.6
項目32017年4月3.4
項目32017年5月3.5
項目32017年6月3.6

このギャップをどうやって埋めるのかを頭を洗いながら考えてた。たとえば一時的にこういう表を用意して、

2017年4月1.0NULLNULL
2017年5月NULL1.0NULL
2017年6月NULLNULL1.0

かけ合わせるとこう。

項目12017年4月1.41.4NULLNULL
項目12017年5月1.5NULL1.5NULL
項目12017年6月1.6NULLNULL1.6
項目2、項目3は省略

で、2列目3列目を隠して、項目名でグループ化して、NULLでない値だけを採用する。

どうだろう。これでいけるだろうか。わざと難しくしてないだろうか。そもそもエクセルでグラフを作成するときの入力とは。


2017年08月11日 (金) 教科書体が来る。「日本マイクロソフト、超読みやすい新フォント「UDデジタル教科書体」を披露 ~Fall Creators Update標準搭載のモリサワ製教育向けフォント - PC Watch」 漢字の種類はどれだけ?■2015032420150414


2017年08月10日 (木) 俺は「面倒くさい」という言葉を、「無駄が多すぎてやる価値がない」「個人の注意力を試すかのようでミスをしやすい」「もっと楽で効率的なやり方を模索した方がいい」という文脈で使うんだけど、なんかただのわがままだと思われてるっぽい。心外である。そりゃあ、無駄なことはやりたくないというのは俺の価値観だし、無駄とみなしたのは俺の(間違ってるかもしれない)判断だし、俺は経営者じゃないし、それで行くってんならそれでいいですけどね。■自分が体を動かしたくないというのを理由にして面倒だとは言ってないつもりだったけど、今書いたものを読み返してみると「無駄だやりたくない楽をしたいむしろやらないで結果だけ欲しい」って書いてた。でもこれが正しい欲求に思えるんだよね。価値を生み出すのに本質的でない部分は常にそう。仕事をしてはいけない>「パソコンにデータがあるのに手書きでフォームを埋めるとか嫌(20170315)」。みんなまじめなんだよ。まじめで一生懸命でどこも手を抜かないんだよ。俺にはない美徳。


2017年08月09日 (水) 秘密の質問とかなぞなぞ認証には2種類あることを知っているだろうか。愚かなのは(推測しやすい)第二第三のパスワードとして(必ず)設定させるもの。そうとばかりは言えないのは、たとえばいつもの端末とは違うところからパスワードを使ってログインしてきたときに、あなたは本当に本人ですかと念の為に尋ねるためのもの。罵る前に区別できてますか? それとも、どっちも同じようにダメ?


2017年08月08日 (火) ドラクエ11の楽しみってベロニカしかなさそうだからやらなくてもいいかなって思ってたけど、プレイ動画を見てると(まだ出会ったばかり)、ベロニカのためだけに11をプレイするのも悪くないかなって思える。ベロニカと下僕たちというコンセプトでパーティーを組みたい。■イベント消化つぼ割りタンスあさり鍵開けメダル集め乗り物でゾーニングされたマップみたいな要素はもう楽しめない。長持ちはしなかったけどドラクエビルダーズはたしかに楽しめた。■■■FF1はときどき無性にプレイしたくなって何度かクラス編成を変えてやってるんだけど、FF2は熟練度システムが(とくに魔法の強化が)面倒で1度しかクリアしてなかった。そんなわけで2度目の FF2を倍速でプレイしてるんだけど、マップを歩くのが怖い! 見えない境界をちょっと踏み越えるや強すぎる敵に瞬殺される。チョコボの森があってわりと早くから世界一周ができるのだけど、降りたらチョコボはどっか行ってしまうから、下手なところで降りると詰む! いいねえ、この緊張感。レベルが低いんだから当たり前のことだと思うよ。ちょっと強くなったら、もう倒せるんちゃうかと挑んでみてまた死ぬ! かろうじてでも倒せるようになってくると、熟練度の上昇とおたからの売却益がうまい。そんで気が向いたらストーリーを進める。結局、俺が望んでるゲーム(→20170623)っていうのは、覚えてなくても昔と同じ体験ができるものってことだった。とかいいつつ、実際の子供の頃には細長い攻略本片手に素直にストーリーをなぞってた気がしないでもない。


2017年08月07日 (月) 続(20170315)。データファイルを読んで SQLの INSERT文として出力し、また、TSVの[アイテム-要素]表データを SQLに加工し、両方を SQLiteに食べさせるなどしていた。NATURAL JOINでがっちゃんこして GROUP BY, ORDER BYでまとめて並べ替えて、アイテム横断要素リストが出てくる。細かいことを言うと、TSVの表の更新をミスって不備が生じたときにリストからあるべき行が消失しないように、NATURAL LEFT JOINして NULLで TSV由来の右の表のカラムを埋めるのだけど。■SQLってカラム名を書いていたところに式を書き出すと、途端に使い出が増す。乱用の始まり。果ては「Poor Man's Search Engine (貧者のサーチエンジン)」■sqlite3.exeをポンとコピーするのはありでも Rubyをインストールするのはなしなので(※俺ルール)、WSF(JScript)と SQL(SQLite3)とバッチのキメラになった。WSFというのは WSHの 5.6からサポートされてる XMLファイルで、.jsファイルのインクルードができるのでスクリプトのライブラリ化&共有ができる。最初は evalでやろうとして失敗した>「JScriptバッチで,外部のスクリプトをロード+再利用する方法 (WSFで import / include する) - 主に言語とシステム開発に関して」。■SQLが .sqlと .batと .jsの3種のファイルに散らばる結果となった。つらい。ヒアドキュメントすらない>excerpt.bat。繰り返しをサポートする SQLテンプレートで SQLを書いて、連想配列の配列をバインドしたい。■出力先がハードコードされたファイルだというのが嫌だから、また、エラー情報を垂れ流せるから、標準出力が欲しい。普通の入力デバイスはマウスである。だからバッチファイルが出てきたり、ショートカットファイルにパラメータを埋め込んだりする。エスカレートして VB製のフロントエンドが出てきたりはしないが、HTMLベースならありかもしれない。え、HTA……(古い)。