ふーん、という印象。
ただまあ、イーロンマスクは別に二足歩行
好きでやりたいわけじゃないと思うので、
時間、投資に見合わない、か
もっと訴求力のあるテーマが出来たら、
途中までできていたとしても、
ぱっと売却すると思うけど....
ソフトバンクの例を出すまでもなくね。
二足ロボットやりたくて、生涯
それに掛けてるような人とは別の価値観
で動いているから、いずれどこかで
歩む道が分かれると思う。
それが全てネガティブなこと
だとは思っていないけど。
まあ価値観、いやこの場合は利害だね。
共有できているうちに、お互い
うまく利用していくのがいいだろなあ、
とは思う。
ネットワークプログラミング？をちょこちょこと。
色々やってくうちに、これってどうやって
実現、実装すりゃいいんだろう？ってことに
出くわすんだけど。
多分、仮にAというなにか、概念、手法が
用意されているはずなんだけど、
名前が分からないばっかりに、
検索では全然出てこない。
自分なりにこのAを意味するような
単語で検索するんだけど、これをやると
同じようにAを探している人の
質問ばかりヒットする。
------
こういうの読んでて、質問者の
聞きたいことは良く分かるんだけど。
回答者の方は、
良く分からないですけど、
こういう風にやれば同じことを
実現できませんか？とか、
本質的にズレた回答が並んでいる。
まあ、好意でやってくれてるんだろうけど、
いや基本的に、問題を回避したいわけじゃなくて、
解決したいんだけどなあ、と
多分、そんな回りくどいことしなくても、
そのものズバリが有るのは確実なんだけど
なあ.....
まあ、気持ちはみな同じなんだろうけど
FQAが検索ノイズになってるの、
なかなか厳しいなあ、と感じたりする。
何時の時代も、検索エンジンを使いこなすのは大変だ
------
結局、件のAは、いずれの環境でも、
標準的に実装されていることが分かった。
Aの名称で検索すると、普通に大量の
リファレンスがヒットするけど、
FQAは、全くヒットしないのであった。
検索エンジンのデータベース上で、
Aと、それを表す（表したい）言葉の
距離が非常に遠い、関連性が
保持できないってことなんだろね。
色々と捗っている....
なんでもそうだけど、関連の知識が
増えてくると加速度的に理解が深まる。
しかし、そこに来るまでは、
試行錯誤の時間が必要な気がする。
なので、時間をかけて、
じっくり試行錯誤する。
------
そんなことがゆるされるのは
随分贅沢なことではあるんだけど。
たとえその時は贅沢で
あったとしても、
それによる恩恵が大きければ、
最後にはちゃんと収支が合うよな、
と思うので、確信犯的に
贅沢なことをやっている。
諸説？あるタイヤのキャンバ角について、ちょっと書く。
実車では当然、車両のキャラクタ付けのための重要な
パラメーターなんだけど、マウス界隈でも、
色々トライする向きも多い。
でも何を狙ってるかは、あまり公開情報には
出てこない様だ。
情報統制なのか、あんまりはっきりしないのか。
------
何事も、狙いがあって、それの実現のため
各種実装があるんだけど。
実装ありきで何を狙ってるのか
分からない、なんて感じでは、
その時、たまたま結果が良くても、
次もいいとは限らない、みたいなことになってしまう。
まあ、一般的に実車ではサスペンションが
動作したときに、タイヤをちゃんと正しい角度で
接地させるために付ける、という理由が一つ。
（実際にはもっといろいろな要因が絡む）
じゃあ、サスペンションの無い、
マウスやトレーサーなら、キャンバって
そういう意味は無いのか？というと
まあ、まんざらそうでもないと思う。
------
実際には、タイヤのスリップを生んでいる
変形があるので、走行状態で
タイヤの接地状態は刻々と変化する。
最大グリップが欲しい時に、
接地面が最大にならないのは
タイヤの性能を使い切ってないって
事になって、これはもったいない。
最もグリップが欲しい時に
最大の接地面を与えられるように考えると、
自然とキャンバを付ける方向になりそうだ。
------
まあ、もっとも。
そもそもタイヤの最大グリップを
使いきれてないようだと、キャンバがどうであろうと
違いなんて出てこない、なんてことになるわけなんだけどね....
それを持って、キャンバ角効果なし、
の結論は、いささか性急に過ぎるとは思う。
もっとじっくり取り組んでもいいかと。
多分、結構奥が深い。
これ以外にもキャンバの狙いは合って、
そっちの方が多分重要だとは感じている。
話としては、こちらの方が分かりやすいとは
思うのだけど。
Perlのスクリプト、手元環境で動くようになったので、
ちょっとレンタルサーバーを借りてみて、
実際の動作環境を作って試してみる。
今どきはレンタルサーバーの申し込みから
使用開始までもほんの数分だ。
簡単にsshでログインして、作ったスクリプトを設置。
すべてデフォルトのまま実行してみると、
ちゃんと意図した通信をするのが確認できた。
ああ、こりゃ楽だなあ。
手元環境作る方がよっぽどメンドクサイｗ
------
たしかに、この環境はレンタルサーバーならでは。
月々数百円で、常時動作＋ネットワーク環境
＋固定IPアドレスだからなあ.....
ノートパソコンを24時間常時動作させると、
電気代だけで￥500～￥1,000／月って処だから、
実は自前で用意するより、全然安いんだよなあ。
日本での初任給が外国に比べて安い、
なんて言われて久しいが、
制度上、まあ無理もないかなあ、とも思う。
採用する方、される方、お互い自分の
視点で考えちゃうので、こういう認識の
ズレも出るわな、という。
------
日本では、採用時にパフォーマンス条項が
あるわけでも無いので、反社会的行動
でもない限りは、採用する側の都合での
解雇、契約終了はかなり難しい。
まあ、働く方を保護するための
ルールだけれど、これ、パフォーマンス
とか適性のあるような仕事にまで
適用する話じゃないと思うんだけど、
実際そうなっている。
仕事や組織が合わない、専門がずれてる
とかの理由で、実質的に仕事にならない場合も
結構あるんだけど、そういう状況を
打開できるのは、雇用されている側だけだ。
なので、雇用されてる側が
合わない、給料分稼げてないないと
分かった時点で離れれば、
双方ハッピーなんだけど、
実際には生活を守る？ために
稼げなくてもその場にとどまるのは
これもまあ、よくある話だ。
もちろん保証されていることなので
そこは問題ない。
でもその結果、そういうケースが
多いとなってくると、当然原資は
限られているので、
稼げてなくてもその場にとどまる
人間含めた頭割りで全員の収入が
設定されることになる。
これ、めちゃくちゃ全体には
負担掛かってると思うけど、
まあ世の仕組みとして、
皆、許容しているようだしなあ。
給料取れると分かってる人にとっては
まあ、大概迷惑な話だけど、
一般応募で行く以上は、
その人が稼げるかどうかなんて
ギャンブルなので、これ
仕方ないよなあ、と思う。
自分だって保証できないしねｗ
------
自分視線だと理不尽極まりない
ことも、別視線だと全く
反対方向で理不尽だったり
するものだ。
あー、裏面に部品付けるの前提なのか....
部品裏面にも実装すると、裏面でないと
当たれないパッド出来ちゃうでしょ。
どっちかだけならまだ
大したことは無いんだけど、
表裏で同時にプローブ当てるの、
結構つらい....
実体験から、そういうの、
回路デバッグの
馬鹿にならないレベルで
手間増える気がしている。
デバッグ時に苦心するくらいなら
表側に全部の部品集結させる
スタイル。
プローブ当てそこなって回路壊すとか
かなりの悪手。
ふとした切っ掛けで、Perlなぞ触り始める。
まあ普段、使うようなものではないんだけど
ちょっと思うところあって....
いまさらと言えば今更だけど、
自分の人生、どれもこれも
いまさら....から始めたものばかりだ。
数日触って、ほんの少しづつ様子が分かり始める。
結局言語って、目的があってそれを実現
しやすいように実装されているもんだ。
なので、想定された使い道を
理解すれば、なんとなく言いたいことが
見えてきたりする。
------
なんとなく、必要な要素が見えてきたので
がんばって実装して、近いうちに
本番環境でトライしてみたいところだ。
こいつも釣りあげたら、地味にデカイ
ような....気がする。
本当なら、この筋のプロに頼みたい
位なんだけど。
自分も含め、手を付けられる人員が
全くいないので、そもそも
依頼するのも難しい....
ちょっとづつ道具を増やしていく
時間はかかるけど、結局これが
一番早いんだよなあ。
マニュアル化すべきもの、
マニュアル化できる物って、
すでにやることが整理されていて、
手順が確定している物。
読んでる方が、都度判断する必要が無い、
が大前提な気がする。
そういう範囲であればマニュアル化
大いに結構だと思うんだけど。
試行錯誤の過程や、前提条件
がどんどん変わって、都度調整が
いるような物って、
記載すべき項目が多すぎて、
包括的なマニュアル化に向いてないよな、
と思うことも。
根幹部分だけマニュアル化したいんだけど
マニュアルが必要な人には、
どこが根幹でどこからが枝葉の部分か、
そもそも判定できなとか。
結果、マニュアルを読める人には
マニュアル要らないとか
の構造が出来ちゃう。
たとえば入学試験、解法記入マニュアル
なんてものが作れるのか？
みたいな感じ？かな。
最近のコメント