脳log[2018-11-02～]

2018年11月02日 (金) [C++] .o と .a の違い。.a の順序依存性。■「静的ライブラリのリンク時にundefined referenceエラーが出る(gcc)」「static link について - 兼雑記」■リンカってバカだな。ハードウェアリソースが少なかったんだな。■指示されたことを指示されたとおりにしか実行しないというのは道具として望ましい特性ではあるが、お客様気分では使えないわな。

ツッコミを入れる

2018年11月01日 (木) AI が何度目かで流行している今あらためて読みたい『O嬢の物語』。自分たち小さな人間が奴隷になりたい存在であることを自覚するところから機械との関係を考えよう。自分は同時に天邪鬼なので、そういう傾向があると知ればそこに甘んじること大多数と同じであることには満足できない。アンチとシンパが自分がないという点で表裏一体だと肝に銘じながら。

ツッコミを入れる

2018年10月29日 (月) [C++] if 文が嫌いである。その感覚の出所(でどころ)を考えてみた。■if 文というのは低いコードカバレッジへとつながる、実行コードの分裂である。if 節と else 節には無制限に無関係なコードを書くことができる。その無秩序さが許容できない。■if 文やループといった制御構造自体が無秩序なジャンプを飼い慣らしてプログラムを構造化する過程で生まれてきたと思うが、今はもう if を飼い慣らす段階なのだということ。■if が嫌いということは分岐が嫌いということと同じではない。CPU の分岐予測を無用のものにする実用コードが書けるわけではないし、パターンマッチングは有用だし、再帰関数の終了条件だって書かなければいけない。if 文に代えて条件演算子を使用することを擁護する根拠がここにあると思う。条件演算子では型を逸脱した無秩序なコードを分岐のそれぞれに書くことができない点で、飼い慣らされた if の側面があるからだ。■考えたきっかけはこれ>「pull/553#pullrequestreview-165680225」実行効率を犠牲にしてまでそう書く理由。wmemchr の戻り値の仕様を矯正してまで最初からそういう風に書くつもりがなかった>「pull/553#pullrequestreview-165133091」その理由。■コードの分裂を避ける。変数の定義を変えない。変化するのは変数の値だけそれも変数の定義時に一意に定まる、というようなコードを書きたいということ。状態の管理をしたくないから、クラスとアクセス制御で管理をオブジェクトに任せる。関数の内部でも、条件に応じて組み代わる関数の内部構造の変化に注意を払いたくない。変化するのは変数の値だけで手一杯。■値としての関数？値が変化する=関数が変化する？型が保たれているからいいんじゃないでしょうか。よう知らんけど。■さっきの PR に含まれていたコードのこの部分に心残りがある>「sakura_core/types/CType_Tex.cpp#L258-L266」当然のように条件演算子で書こうとしたのだけど、条件演算子が嫌われやすいということがあり、他の場所でヨーダ記法が嫌われていたということもあり、控えてしまった。

ツッコミを入れる

2018年10月22日 (月) GitHub の障害。書き込みは基本的に通ってるみたい。でも参照が安定しない。ログインしているのに(※これは事実)、ログインしていないときのページが表示されたり、最新版ではないページ(※過去の版のいずれか)が主に表示される。リロードして運がよければ最新版。■@2018-10-23 報告「October 21 Incident Report | The GitHub Blog」

ツッコミを入れる

2018年10月21日 (日) ちょっと何を言っているのかわからない。「栃木県警が、夜間運転でのヘッドライトの上向き使用（ハイビーム）についてドライバーに行った意識調査で、「原則ハイビーム使用」を「知っている」との回答が７割を超えたにもかかわらず、実際に行っている人が５割あまりにとどまっていることがわかった。実践しない理由では「まぶしくて他の車に迷惑をかけるから」との回答が多かった。道交法では、他の車に影響しないよう、こまめにロービームなどに切り替えるとされているが、県警は「多くのドライバーが『常時』ハイビームと誤解している」とみて、さらに広報活動を進めることにしている。」■ドライバーの半数以上が「原則ハイビーム」を知っていて、でも「まぶしくて他の車に迷惑をかけるから」ハイビームにしていないという(※程度・頻度について言及がない)。■ドライバーは原則を知ったうえで適切に状況を見極めてロービームを使用していると考えられるのだが、栃木県警に言わせるとそれは「多くのドライバーが『常時』ハイビームと誤解している」せいだかららしい。■何をアホなことを言っているのか。お前らが「常時ハイビーム」だと誤解させたがっているというだけのことではないか。歩行者、自転車、車、何が見えてもロービームにしろ。ドライバーだけが見えていればいいってもんじゃない。そんなパトカーがいたら眩しくて目の前によろめき出てやるからな。

ツッコミを入れる

2018年10月18日 (木)

最終更新: 2021-05-12T04:21+0900

♪ [Git] Git, GitHub 初期設定

あまり書かれていないことだけ。

ローカルリポジトリ

(クローンしたなら)リモート名 origin を削除する。git remote
- 余計な自動化も自分が管理しない名前もない方がまし。
自分の GitHub リポジトリをはじめ、外部リポジトリの URL に名前を付ける。git remote
- ブランチ名とひと目で区別できるように、リモート名は @ を付けたり大文字にしたりしようかな。
自分のではないリモートリポジトリへのプッシュをできなくする。git remote set-url --push <remote> ""
新しく作成したブランチが自動的に設定する、分岐元との繋がりを断つ。git config --global --add branch.autoSetupMerge false
- --no-track を既定値にするということ。git branch のみならず git checkout -b においても。
- 最新版の取得がチェックアウト＆プルでは済まなくなるはずだが、読み取り専用にするつもりのブランチなら --ff-only なマージで済むはず。でもマージする範囲が自動ではわからないかも。なら毎回新しくチェックアウトするとか。
  - プルできないのが面倒なら、<remote> へのプッシュ不可設定を徹底することにして、この設定はしなくていいかも。
- 変更を加えたブランチは、最初に必ず自分の GitHub リポジトリにプッシュする。git push [-u] <myRemote> localBranch[:remoteBranch]
  - -u オプションを付けて一度プッシュすれば、以降は引数なしのプッシュ、プルが可能。
  - タイプ頻度が高いローカルブランチだけ短い名前にしようかな。
    - [Tips] localBranch の部分を HEAD にするとチェックアウト中のブランチ名を意味するみたい。※コミットオブジェクトへの参照(refs)ではなく、refs への参照ってこと？
    - [Tips] 単独のコロン(:)はローカルとリモートにおける全ての同名のブランチの組を指すらしい。ローカルにだけ短い名前を付けると対象から外れてしまうし、それがリモートに存在する無関係のブランチと同じ名前だったりしたら……(考えるだに恐ろしい)。
[Tips] チェックアウトしているブランチを削除したければ git checkout --detach してから。これでひとつのブランチも残しておかなくて済む。
[Tips] おそらく一番タイプするコマンドのエイリアス。
```
[alias]
	co = checkout
	st = status --short --branch
```

GitHub の自分のリポジトリ

フォークする。
- GitHub はフォークツリーをメンテナンスしており、プルリクエストを出すためには GitHub 上でフォークしたという事実が大事。他に方法がないとは限らないが、Web での操作に苦労したくないなら、そう。
フォーク元とは別のリポジトリ名にする。
- リポジトリを削除するときにはリポジトリ名の入力が要求されるのだが、アカウント名は省略できる。リポジトリの名前が同じならフールプルーフは機能しない。
フォークしたときに作られた master を巻き戻して、空のブランチを作る。git reset, git push
デフォルトブランチを空のブランチにする。
空のブランチだけを残して、クローンしたときに作られたブランチをすべて削除する。git push <remote> --delete <remoteBranch> (--delete の代わりにコロンでも同じ。:<remoteBranch> 空のブランチを push = 削除)
- 自分の GitHub リポジトリにコピーブランチはいらない。ローカルの作業リポジトリで git fetch --all して <remote>/master などと参照すればよい。

すべては自分のリポジトリを表示したときに、他人の作業の成果があたかも自分のものであるかのように表示されるのが嫌だから。あとは一見したページの印象がそっくりだと、自分のリポジトリを削除するつもりでフォーク元のリポジトリを削除してしまうことがあるから。

根底にある考え

自分にとって３つのリポジトリの関係は「本家―ローカル―フォーク」として捉えられている。でもひょっとしたら「本家―フォーク―ローカル」の想定もあるのかもな、と考えてみた次第。でも自分で GitHub にフォークリポジトリを持たなくても「本家―ローカル(フォーク)」の２者間でもフォークは成り立つので、中心に GitHub 上のフォークリポジトリを置くのは、GitHub の中の人の立場としてならともかく、個人としては順序が違うと思う。メンタルモデルはひとつで十分だ。そのとき GitHub 上のフォークリポジトリは３番目に位置するオプショナルな存在となる。

ツッコミを入れる

2018年10月11日 (木) 「焦点：アマゾンがＡＩ採用打ち切り、「女性差別」の欠陥露呈で | ロイター」■医大を志望する女子受験生の点数を一律に下げていた大学側の論理と、アマゾンの採用 AI のしていたことが同じってことでしょう。過去のバイアス、是正すべき現在を強化、追認するだけで、あるべき未来が見えていない。AI はいいけど AI と同レベルの人間の先行きとは。

ツッコミを入れる

2018年10月08日 (月) 「数学のテストで用語を問う問題 - Togetter」■元のツイート主が「塾屋」という軽率な言葉を使うような人であることから、当たり前のようにつまんない盛り上がりを見せている。一枚乗っかろう。■この法則をなんというか、ではなく、交換法則(という言葉を知っていることは前提)が成り立っていることがわかる恒等式を選べ、という出題だったら納得いただけたのでは？

ツッコミを入れる

2018年10月06日 (土) 「桂隆俊さんのツイート: "ガラケーの時のUIとして面白かったのは「お」を表示させるのに「あ→い→う→え→お」と5回押すので、エンジニア的には「5回押す必要がある」と言っていたのに対し、女子高生にインタビューしたら軒並み(50%以上)「1回」と答えていたこと。これはUIでよくやる観察手法の限界の一つ。… https://t.co/sF5SQf2eSV"」■これね、今も使用中のガラケー(W53S)で試してみたけど、押し続けてると「あ→い→う→え→お」と遷移していった。主観でも何でもなく、１回押しただけで入力できる。とはいえ、女子高生のあいだで主流の入力方法がどんなものだったかはなんともいえない。おっさんは待てないし、視覚的フィードバックとタイミングみたいなものより、指の動きを数える方が確かで頼みにするけども。■遷移するまでの待ち時間と間隔を設定で調整できるし、遷移するかどうかも同じ場所で設定できた。メニュー番号527。■入力ツールとしては、子音だけ(あ行、さ行みたいな)を入力していくと、母音を補ってそれらしい単語を候補に出してくれるものがあったと記憶してる。「かわなたは」と入力すると「こんにちは」が候補に出るみたいな。これもボタンの連打を省く手法。アラビア語は母音を表記しないために読み手が補うのだとか。無理な入力方法ではないってことだ。

ツッコミを入れる

2018年10月04日 (木) 「図柄入りナンバーに都民そっぽ、世田谷区申し込み15件に肩落とす担当者「3桁はあると思ってた。キャラにかなわない」：バイク速報」■(世田谷とワースト１、２を争った)杉並はすごく好き。子供の落書きってコメントがあるけど、子供の絵をへたくそってけなす奴がいるか？そのテイストとキモカワ具合が最高じゃないか。美人さんやぞ。

ツッコミを入れる

2018年10月03日 (水) 食事っていうのは体の欲求に従って食べたいものを食べればいいという考えなんだけど、だから食餌制限にまったく興味がないんだけど、糖質を制限することにひとつの閃きを得た。そんなことどこにでも書いてあるのかもしれないし、どこかのマイクロWeb日記にも難しいことが書かれているのをわからないまま読んでるんだけど、勘違いであれ何であれとりあえず腑に落ちたことがある。■糖質を制限するのは、飢えとは無縁の日本社会において、糖質という優先的に消費されるエネルギーを制限することで、脂肪を燃やす回路を鍛えるのが目的だということ。あれを食べれば健康、これを食べれば不健康、みたいな考えはすべて間違いだけど、体内の回路で考えるとそうかもなあと思う。■それとは関係あるのかないのか、まったく根拠はないのだけど、最初の空腹がきてから１時間かそこら我慢するとその後何時間も空腹を感じなくなるのは、体内でエネルギーを供給する回路が切り替わってるからだと、比喩として自分に説明していた。■嘘でもこじつけでもすっきりしたので事実はどうでもいい。食べたいものを食べる(その結果>20180720p01)。ただ、以前にも書いたと思ったけど、満充電状態を常に維持するような食べ方ではなく、空腹に慣れたいと思ってる。いつでも手の届く範囲にお菓子などを置いておくのは危険。それでは食べたくないのに、必要がないのに、手や口がさびしいという理由だけで食べて、かえって苦しくなってしまう。そろそろ付き合いが長いので、自己に対するそういう理解がある。知れば対応できる。■ところで、脂肪を効果的に消費できる体が、脂肪を蓄えることに長けていることと表裏一体の可能性は？蓄えたくなーい。■生命に繋がる自己組織化のスタートは、回路の発生から始まる物質の偏在だという考えを読んだのは『[文庫] スチュアートカウフマン【自己組織化と進化の論理―宇宙を貫く複雑系の法則 (ちくま学芸文庫)】筑摩書房』だったか。パラパラと開いてみたらキーワードは「自己触媒作用」「開いた熱力学系」。ハーパー生化学をパラパラと開いてみようとは思わないなあ。

ツッコミを入れる

2018年10月01日 (月) 車で前進で入ったところからは(条件が変わらなければ)必ずバックで出られるはずだと思うんだけど、往々にして苦しんでしまうのはなぜなのか。ハンドルを切る早さと戻す早さが非対称で、それなのに前進と後退で同じように操作してしまうから、結果として張り出した前輪が壁をこすりそうになるのではないか、と考えた。すると違ってくるのはハンドルの操作だけではなく右左折点までのアプローチの長さもそうだと気がついた。思えば前進しているときは、交差点のどこまで突っ込むかでハンドルの切り方が変わるわけだけど、どこまで突っ込むかというのはつまり実際に曲がるところまでの距離に影響する。バックの時にはそういうオプションを持っていなかった。壁際に沿って車があって壁から離れるようにバックで方向転換をするようなとき。ゆっくり切り始めて長い距離を使って壁からスペースを作ってから、大きくハンドルを切って向きを変えなければいけないはずなのだけど、実際に向きが変わるところまでのアプローチを長くとるという意識がなかったから、苦しかった。これが逆回しの前進であれば、交差点からの出口でゆっくりなめらかに車の向きをまっすぐにする段階に相当する。

ツッコミを入れる

2018年09月23日 (日) [SakuraEditor] バックステージ。バッファがあふれる、スタックを破壊するっていうのは、原理的に起こりうる、そういう可能性があるというだけでバグだと思ってるんだけど、同意してもらえない。■Web アプリケーションではセキュリティを考えるうえで「外部入力」というものを峻別せずにはいられない。できなければ SQLインジェクションなり OSコマンドインジェクションなりを許す穴を作り込んでしまう。で、話は戻るけど、Windows アプリケーションで HWND 経由で得られるコントロールの値は「外部入力」だと、自分は考えてる。外部といってもネットワークの外部ではなくシステム内の第三者なので、権限の昇格が伴わなければ他のプログラムを操作するような迂遠な方法をとる理由がないわけだけど、サクラエディタを、管理者として実行してはいけないプログラム、とマークさせたいわけでもなし。■２つの理由で見過ごせないわけだけど、理解してもらえない相手になすすべがない。判断の分かれ目などではなく、問答無用だと思っているから。

ツッコミを入れる