  |
はてなキーワード: 直交とは
応答ありがとう。
知らないで話してる人も大勢いるよね？
まあそこに関しては否定しないけど、少なくとも私は知っててあの増田を書いたので、「表現の自由戦士は当然のようにBL18禁問題知らないんだね」って言われたら「ん？ 俺に向かって言ってる？」って思っちゃったわ。自意識過剰ですまんな。
そして本文、なんか色々言ってるけど同じコーナーにしたらいいじゃん！はい解決！でだいたい済ましててそれを実際に負担する書店の現実的な問題点が見えてなくない？
コーナーを一緒にすれば不審者が減るというのも短絡的、不審者からしたら自分も気軽に入れて店員から死角になるって反論されたらどうするの？
（あんま杞憂する風潮は好きじゃないけど、こうしたらいいのにしないだけって考えはあなたの押し付けであって何も解決してないと思う）
これに関しては、まあぶっちゃけゾーニング反対派だから原理原則論を唱えて事足りると思ってるというのはある。設置に反対してるコーナーなので。R-18が別コーナーに隔離されるのはそもそも不当だけど、仮に隔離するとしたら別に一緒にまとめればいいじゃん？ みたいな感じ。
それにしても、コーナーを別にするの、そんなに重要か？ たとえば現在の書店では、私はエグめのBLが置かれてるコーナーまで行こうと思えば普通に行けるし、何なら商品を物色することもできるわけで。たまに少女小説系の文庫本を買いたくなったときは普通に女性向けエロ本の棚の近くも通ってるし、気が向いたら表紙を眺めてるよ。だから一緒のコーナーで何が問題なのかピンと来ないんだよね（もちろん、コーナーは一緒でも、棚まで一緒にしろとは言ってないよ。だいたい検索性が悪いし）。
加えて、既述の通り、実際に知り合いにBL読みの男がいるので。彼のような人が普通にBL売り場で商品を物色できるような仕組みが望ましいと思う。
あと私はR18化に賛成してどうやったらR18にできるかを話しててだからBLを規制しないでとは言ってないんだよね
ゾーニングをもっとしてほしいという考えとゾーニング反対派で根本的に全然違うよね？それをゾーニング反対派じゃん！認めろ！って突っかかられても困る
この点についてはあなたが立場を明示せず現状を説明しているだけなのにそれを肯定であるかのように捉えて突っかかってしまいすまない。
単純に誤読、R18コーナーに学生を入れろじゃなくて規模から考えてBLを丸ごとR18にするとR18に相当しないBLを学生に売れなくなってしまうという意味、ひとつの書店でそんなに多くのBLを扱っていないことも多い
これは確かに誤読だった、失礼。こちらも元増田では「BLのうち、R-18に該当するであろうもの」だけを指して規制について話していたつもりだったけど、確かにBL全体をR-18にしろと言っているようにも読めてしまうな。反省。
で、仮にゾーニングを肯定するとして、R-18に相当しないBLはもちろん学生向けに売り続けていいと思うけど、「仮にゾーニングを是とするなら」まず18歳未満の学生にR-18のBLを見せない方が優先度高いと思うんだよね。残りのBLをどうするか、はその次でしょ。なんでゾーニングをするのかって、それは子供たちも含む望まない人たちに不意に見せないようにするためなわけだから。
あと、東京都のガイドラインだと「高い棚に置く」とか「仕切り棚を設置する」とかもOKらしいね。
三 陳列棚の指定図書類等を陳列しようとする各棚板の前面と直交する鉛直面上に、当該棚板の前面から１０センチメートル以上張り出した仕切り板（透視できない材質及び構造のものとする。）を設け、指定図書類等を、仕切り板と仕切り板との間に陳列すること。
仮にゾーニングを是とするにしても、たとえば低い位置の棚には性行為の描写がないマイルドなBLだけを陳列する、というのも有り得、それならまあそこまで大変じゃないんじゃないかな（もちろん本来はこんなゾーニングの義務なんてなくすべきだけど、あくまで現実を前提にした妥協案としてね）。
私は原則派だけど、書店が個々の裁量で子供の手に取りにくい場所にアダルト系の商品を置くのは流通が阻害されるわけでもないしその気になれば手に取れるわけだから許容する。ゾーニングの義務に反対しているだけで、個別の書店がどんなふうに商品を置くかはその店の自由だと思うので。もちろんR-18のBLをドドーンと子供の目につくところに平積みにする書店があってもよい。
これはただ恥ずかしいという意味ではなく男性と世間からの扱いが違うから困るという意味がある
からかいや視線など、嫌がらせもありえるしつきまといが発生するリスクもある
その上でコーナーを作るべきという話と男性だって同じなのにという感情論は比べ物にならない、同じではないから問題にされてるのに同じなのにと言っても意味がない
私はマッチョ思考なので問題ない！売れ！と思っているが多くの人が男性と女性で状況が違うことくらいわかっているのに男も同じだと言い切る傲慢さにもそれを男女平等という卑怯さにもげんなりする
まずもって、法律や制度は性に対してなるべく中立であるべきだと思うんだよね。もちろん、月経や出産みたいに生物学的事実によって違いが生じてる事柄に関しては片方だけに特別な手当てがあっても仕方ないけど、基本は制度は中立の方が良いでしょう（たとえば強姦罪が強制性交罪に改正されたのも、性犯罪の定義をより中立にしようとしたものとして評価されるべきだと思う）。
加えて、すでに男性向けに対してはある程度規制がかかってる状況なので、申し訳ないけど中立的な規制をしてくれないと非常に不公平感があって腹立たしいというのがある。これは規制の話、つまり我々の権利が減らされている話だから、そこで不平等は受け入れがたい。権利を増やす話ならともかく。
嫌がらせやつきまといが発生したら警察を呼びましょう。嫌がらせやつきまといをより摘発しやすくしたりするために警察の予算増やせとかストーカー規制法改正しろとか、そういう話なら賛同しますよ。
もっと簡単に考えて、今あるBL棚にR18本はタグだけ置くとかしたらどうだろうか、それなら本をレジに出す動作と同じだし
他のR18ジャンルだってあるわけだし女性向けR18コーナーも絶対あった方がいいとと思うけど、まずは普通に書店でR18BLを売れるようになったらいいんじゃないかなって思うよ
まあ、仮にゾーニングするならひとまずはそれが現状でありえそうなラインかねえ。私は別に現状のままエロいBLを本棚に置いてても構わんだろうと思ってるから、それ余計な規制じゃない？ って思うけど。「普通に書店でR18BLを売れるようになったらいいんじゃないかな」ってのは同意。BLも男性向けも、たとえそれがドギツいエロであったとしても普通に書店で陳列できるようにすべきだよね。
https://www.mazda.com/ja/innovation/technology/gihou/2021/
これについてちょっと色んな感情を抱いたわけで感想というか考察というかなんかそういうのを書きます。
電池制御屋さん(?)なのでメインはEV関連のところだけピックアップしてみます。本当は全部やろうと思ったけどエンジンとか分からなくて書くことなかったです。
普段こういうことやらないので読みにくかったら見なかったことにしておいてください。
あと、そもそも私は社員でもE&Tさんや販売店さんでもないですので間違ってたりしたらごめんなさい。
去年に比べてボリュームも多く、メインのトピックとしてMX-30のEVが挙げられていますね。マツダ初のEVですからそりゃあ力を入れますよね。(デミオEV?あれは量産されてないからノーカンで)
では順に見ていきます。
こういった経営戦略は専門外ですし特にないです。頑張って下さい、という感じです。でも、スモールプレイヤーであることを自覚しているならなぜスバルさんのようにEV開発にトヨタの力を借りなかったのかが不思議ですが極めて高度な経営戦略的判断なのでしょう。
私はEV反対でもEV賛成でもなく、ユーザが好きなものを買えばいいと思いますが以下の件、エンジニアとしてずっと疑問に思ってますよ。
https://www.mazda.com/ja/csr/environment/lca/
ところで、技報は直近だと技企が担当っぽいんですがどういう基準で毎年内容とか選んでるんですかね。分かりません。
両開きドア、必要だったんでしょうか。使いにくいと思うんですが…
車格的にこれ以上大きくできないけど四人乗りだし特徴出さないといけないという苦肉の策でしょうか。
私は美術の成績が2くらいしかないのでデザインはよくわかりません。
あ、でも、インテリアのコルクの件は誰が思いついたんでしょうか?どういうコルクでどういう工夫がされているかわかりませんが、熱衝撃でボロボロにならないんですかね。ぜひそういうのを技報で取り上げて欲しかったなぁ。
書かれていることは難しくて分かりません。商品企画って大変だと思います。
みなさん、一回乗ってみるといいと思います。思いの外普通の車です。
制御って難しいですよね。まず式が多くて難しい。
この手の制御は実車でのフィーリング評価が多いでしょうからそれだけ走らないといけないだろうし大変だと思います。
Fig.4ってどう見ればいいんですかね。そりゃ制御切ってる赤線が0なのは当然だと思うんですが。GVCのリクエストに対してモータのリクエストトルクが遅れているのはなにか意図があるんでしょうか。私には分かりません。てかこれ実トルクじゃないのね。
Fig.6ではGVCの有無による加減速が記載されてますね。GVCの有無で横Gは変わらないけど前後方向は、「ターンイン時に減速」「ターンアウト時に加速」と。いやこれ、運転してる人には誤差みたいなレベルのGだけど(たぶん、普通に運転してたら0.1~0.4Gくらいでこのデータだと最大0.4m/s^2≒0.04G)いるのこの制御?
この辺で読むのやめたけど、Fig.20はどうかと思う。基準値おかしいでしょそのグラフ。
この辺も専門外だから流し読み。ペダルの味付けの話かな(適当)
Leafとかi3とか回生がキツくて慣れるまでなんか気持ち悪かったけど、MX-30はその辺まだ運転しやすかった気がする。
これもよく分からない。感想としては、エレキシフトである必要ないよねって思う。
電子制御にすれば車側からの介入がかけられるってこと書いてあるけど、ソフトウェアのバグのリスクを抱えることになりそうだし、そもそもどういうヒューマンエラーを想定してんの?って素人的には思うんですよねぇ。
でもそれよりもあの変なシフトの形状の方が気になる。
LCA(ライフサイクルアセスメント)の件はいったん不問にするわ。
ふむふむ、LiBの温度管理をしっかりして容量と入出力を使い切ると。むしろそれ以外にはないわな。
「クーリング・ヒータシステム」うん、こういうのでいいんだよ、こういうので。
なるほど、冷媒冷却なのね。Fig.8を見ると温めるのにはヒートポンプ使わないのか。もっぱら冷却専門って感じね。そりゃあ電池が動かないくらい寒いときに温めるんだから効率の悪いヒートポンプ使わないのは当然か。Hondaさんはモータ系の冷却水を電池に回して加温にも使ってた気がするけど冷媒だと難しいんでしょう。
ところで、車室内が暖房で電池が冷却を求めている場合(真冬の高速連続走行)とかの時はどうなるんでしょうね。ヒートポンプ一個しかないけど。
冬場はヒータを使って電池を温めて充電時間短縮に貢献しているんですね。
あ、そういえば低温の充電についてはこんな記事ありましたよ。
https://insideevs.com/news/486109/mazda-mx-30-battery-pack-heating-issue/
マツダさん、色んなところでMBDのお話してるのでやっぱりありました。
元々シミュレーションで研究やってたんで、モデルベースとかシミュレーションとか僕は好きですよ。
これを見るとHILSがメインなんですかね。HILSって物できてから色々するものだと思ってるんですがこれはMBDなんでしょうか。まぁHILSにはモータとか電池とかのモデルが入っているのでその意味ではMBDか…
ゴリゴリの計算化学的なのはないんでしょうか。EVだから電池系でその辺もあるかと思ってたんですが。
気になるのは4.1の説明で「ユニット間通信もPCMとの Peer to Peer通信を基本とした」と書いてますね。だいたい今の車載系のネットワークはCAN通信なのでP2PっちゃP2Pなんですが、わざわざ書いてるということは何か特別なことがあるんですかね。
Fig.5らへんでは「充電みたいに特定の機能しか使わないときは他の機能を切って余計な電源使わないようにしたよー」って書いてますが、充電してるなら誤差みたいな電流では…?てかまぁ、関係ないユニットをそもそも動かさないのは当然だと思うんですが。
4.3はよくソフト系の品質検証である直交表ですかね。私も何度か作成したことあります。MBDでやるにしてもテスト数絞らないといけないからこういう感じで管理してるんですね。でも、機能毎の組み合わせをみるだけでも効果あるんでしょうか?不具合が見つかったとしても書けないでしょうから記載なくても仕方ないか…
市場での適合性とか考えると特に大変そう。でも気になるのは「1.はじめに」に書かれている「MX-30は約40分でSOC 80%まで充電できる」の文言。
え?40分?いつの車?35.5kWhしかないのに?もしかして急速充電器の出力30kWとかで想定してる?市場の急速充電器は大部分が(少なくとも日本は)50kWだと思うんですが。
外部充電関連やってる人はホント尊敬してます。だって仕様書難しいし仕様書曖昧なときあるし。COMBOとか仕様書自体なんか怪しいし。
本文中でも「HILSだけでは発見できない」って書いてあるけど本当にそうだと思います。
2.1見ると電池は電子部品扱いなの…?なんか共振点が被らないように工夫しました的なこと書いてある。
でも電池って重量あるし、特に考慮とかいらなそうなんだけど、マツダさんでは電池も細かくモデリングしてるのかしら。あとこれ疑問なんだけど、EVで使われるモータとかってエンジンよりも高周波成分持ってそうなんだけど言うほどないのかね、知らんけど。
2.2には不思議な式が載っている。ダメージ量というのはマツダさん独自の概念だと思う。少なくとも俺はいままで振動とか疲労とかの勉強していてであったことはない。疑問なのはFig.4の加速度に通常ひずみに対して使われるレインフロー法を適用していることになってるんだけどあってるこれ??加速度と応力は比例関係にあるけど周波数成分考慮しないと意味なくない??まぁ、そこはマツダさん独自の手法が隠れてるってことなんだろうか。
そして3.1には気になることが書いてある。
いや、とんでもない超過剰品質じゃん。強度半分でいいから車両価格下げてくれ。
3.2はモデルの話。しかし、写真を見るとマツダさんのアッパーケースは樹脂。これどうしているんだろうか。樹脂のシミュレーションなんてあまり精度よくできるとは聞かないし熱とか湿度とかの影響をもろに受けるはず。この辺もシミュレーション出来ているならすごいと思うんだけど特に書かれてない。一番壊れたらやばそうなのに。
ボデー屋さんじゃないからよくわかんない。でも、MX-30って両開きだから剛性保つの大変そう。
2.1には前突時の話が載ってて、電池を守らなきゃいけないから大変だとか。電池ってR100でメカニカルショックの試験あるからそれなりに大丈夫だと思うんだけどそうでもないのかな。あるいはR93/94で代替してるのか。ところで、実車見たことある人は分かると思うんだけど、MX-30ってモータルームスカスカでバカでかい支柱みたいなのがあるんだけどあれどうにかならなかったのか。てかバランス悪すぎるだろあの構造。内燃仕様も作る都合で仕方なかったのかもしれないけど他の車みたいに充電器入れとかにすればよかったのに。てか充電口とかフロントに持ってくればハーネスとか安くなりそう(モータ/インバータ系と同じところからバッテリパックに入れればいい)のになんであんな構造なんだろう。
3.1は側突の話。MX-30は両開きだから大変そう。ところで、これ全部解析の画像しかないけど、実車のやつはやっぱり画像写せないんだろうか。シミュレーションの研究やっていた身としてはシミュレーションが完璧でないことは分かっているので逆に不安なんだけど、こういうでか物はシミュレーションで十分ということなのかな。(認証試験は実車だろうけど)
よくわかんない。たぶん難しい。
日本語でおk。なんだそれは。とりあえず読んでない。
電池もEVも関係ないけど私が元々分子動力学シミュレーションやってたから。
でも、ほとんどMDの話が書いてない。シミュレーション条件も特に書いてないけど、写真を見る限り大した分子数で計算してなさそう。
これで精度が出るんだろうか。その辺を詳しく書いて欲しかった。
この手の計算は結果自体は出る。シミュレーションしてるんだから計算自体はできるものだから。ただ、現実の実験結果と定量的に合わせるのは非常に難しい。定性的傾向は出ても、定量的な比較はMDでは非常に難しい。
これは経験的なもので私が研究していたのは何年も前だけど傾向は変わっていないと思う。4.1でいちおう妥当性検証が書かれているけど、MDの結果については定量的に比較されているわけではない。紙面の都合もあるから仕方ないか。
ということでマツダ技報2021年度版の感想・勝手な考察でした。適当に読んだから読み間違えてたりしたら申し訳ないです。私はマツダ車乗ってるしこれからも頑張ってください。
近所で幹線道路が十字に直交してるんだが、さらにその近くに斜め方向にそれらの幹線道路と交差している道がある。
そうすると中学生レベルの知能を持ったドライバーが、斜辺が他の2辺の和より短いことを知って、この斜めの通りに入ってくる。
警察も当然、その斜めの通りに入る交差点に右折信号などはつけていない。
それでも朝などは入ってくる車が多くて生活道路が混雑してしまっている。
徒歩通勤で、幹線道路への出口を通るのだが、生活道路に入ってくる残念なドライバーに自覚を促すため、横断歩道はゆっくりわたっている。
なかには強引に右折してきて横断歩道の直前で急ブレーキを踏む車もいるので、そんな時はちょっと立ち止まって
「オー、ニポンジン、ウンテン、ヘタクソ、デース！」
みたいに肩をすくめている。
twitterで話題になっていた例の高専プロコンの審査員の発言と態度の件
「言い方が悪かったのは明らかだが、発言の主旨は正しくて、これはハラスメントと言うほどではない」というような旨の発言をしていて意外だった。
なんとなく読み解くと、「態度と内容は直交している」というような発言もあったので、表題を思いついた。
ハラスメントを定義するためにハラスメントの程度を表すハラスメント度を考えてみる。
ある発言に対してハラスメント度を算出する関数を考えるとする。
この前提のもとにハラスメントであるとはハラスメント度が一定の閾値を超えた発言の事である。と言えそうな気がする。
とすると上の発言を正当化するにはハラスメント度は態度と内容の線形和で表せて、
件の発言は態度としてはアウトだけど正しさを足してみるとトータルハラスメント度としてはセーフという理屈に（発言者にとっては）なるのではないか。
でもその主張（ハラスメントではなかった）に異議を申し立てる人としては、正しさによって下がるハラスメント度はそんなに大きくなくて、「これはハラスメントでしょ」と言ってるように見える。
なんならハラスメント度と内容（正しさ）は直交していると言いたげなぐらいの人も居そう。つまり人それぞれに独自の係数を持っている。
ここからは個人の意見だけど、線形和で書いていくとしたら緊急性とか公益性とかとかも入りそうだなあと思った。
例えば何か工事現場のようなところで大きなものが倒れてくる時に、人間うっかり手で支えようとしたりしちゃう習性がありそばで見てる人が「馬鹿野郎！逃げろ！」みたいな事は割と現実にある気がするけど、これをハラスメントと言うことはそんなにない。
緊急性がめちゃめちゃに高く、内容としても正しいので態度を凌駕してハラスメント度が上がらないのである。
リアルタイム性のある仕事って割と傍から見ると怒号が飛びがちなイメージもあり、そういうもんかなと思う。
あと公益性を思いついたのは名誉棄損罪みたいなものの例でも良いし、あるいは感覚的な「ここで放っておくと冗長する」から「怒る/叱ることが必要」という主張をしてる人たちを正当化しそうなパラメーターだなと思ったからだ。
それでいて個々人の差が大きそうなパラメーターでもあると思う。
最初の例の人も言外にそんなニュアンスを感じたので、コミュニティに貢献するタイプはむしろこういう使命感が高めだったりするんだろうか。
ハラスメント度を表す線形和に組み入れたい要素、ほかに何か思いついたら教えてください。
「双方の合意」みたいなのは客観性が薄いのと、一方だけが合意してると勘違いしてるパターンが多そうなので（それが割とハラスメントの本質っぽくもある）別次元かなあと思っています。
蓋を開ける工程が増えているだけであり、全く不条理な改変である。
新しい蓋は明け口が2つあるが、これはUX上問題があると思う。
増田としては次の3点が複合的にその使いづらさを生み出すと考える。これらのほかにも要因はあるかもしれないが、十分に説明のつく範囲の項目であろう。
従来の開け口はガイドに対して垂直に開ければよくその動作に非合理性はない。開け口をつまんで真っすぐ引けばよいだけである。
ところが、新デザインにおいては斜め方向となっていて開け口のつまみ部分とガイド左右端の距離が異なるため、微調整が必要となる。
この蓋に不慣れな私のような若輩者の場合、念のためにパッケージに記載される説明に目を通して少しでも事前のミスをなくすように努めることが好ましい。
なるほど蓋には「お好きなタブ(開け口)からはがして、両方でとめる」と丁寧で簡潔な説明がある。
ところが、この指示に従うと1点目に挙げた問題と直交する現象が起きる。
ガイドは2つの開け口の中心から垂線を下した形の位置にのみ存在しているため、「お好きなタブ(開け口)」から開いてしまうと選択しなかった開け口にスムーズな開封を阻害されてしまうのである。
私が不器用なことは否めないが、このために旧パッケージでは起きえなかった蓋の裂傷が起きてしまった。
また、これは結局のところ次両方の開け口から開かねばならないことを意味する。
上記2点を総合したところ、どうやら両方の開け口から慎重にガイドまで開けることを想定したインターフェースであることが分かった。
この時点で明確に食べる準備の手順が増えているのだが、ここで述べたい問題としてはパッケージ変更の主目的の一つである「フタ止め感」である。
カップ麺の蓋不要論も存在するようだがそれは今回の話からは除外するとして、止めるためのトリガーが2点増えたとて特に「前よりも蓋をちゃんと止めているぞ！」とは微塵も思わなかった。
日清は苦心してこのデザインを設計したのであろうが、明確な失敗である。そうでないなら押し付けがましい定性的な改善というものではなく、定量的な効果を示してほしい。
以上、むかついたので書きなぐった
亭主関白の家庭でレイプの訴えが頻発していないことから、誤解であることが分かる。
男性に主導権を握らせることを好む女性であっても、不同意の行為には性被害を訴える。
性被害の訴えと、主導権の訴えは、無関係で直交した概念であり、別々に考える必要がある。
余程のことがない限り、恋愛関係、婚姻関係間にて不同意が発生することはない。
また、男女仲がこじれた場合、別れ話や離婚調停で済む場合がほぼ全てであることからも、誤解であることが分かる。
但し、恋愛関係・婚姻関係が無く、加害者側の社会的地位が上である場合等、
被害者側の同意が本音ではないことが疑われる場合は、慎重に同意を取る必要がある。
凄く久しぶりに映画に行った。はいふり劇場版を観て以来だと思う。
前々からきらら系のアニメを劇場で見たいと思っていたので、楽しみにしていた。
やはり映画は平日の昼間に限る。部屋には私と、あと夏休みの大学生風なお客さんが一人。
私は前列に、学生さんは最後列に着席。これ以上にないソーシャルディスタンスを取って鑑賞。
上映が始まると、ああ懐かしいという気分になると同時に、TV放送を見ていたときのことを思い出した。
レポート書きながらだったり、仕事帰りにごろごろしてたりしてたな。
入試、卒業式と終わりが近付くにつれて、終わっちゃうんだなと感慨にふけってた。
カレンの正規直交基底のポーズが見れると思っていたけど、なかったのは残念。
最近は、きんモザみたいにひたすらキャッキャッしてるアニメがなかなか出ない気がする。
大学物理の教科書では、ベクトル場を曲線lあるいは曲面Sに沿って積分する際に、「∫l F・dl」とか「∫S F・dS」といった表記が使われる。これは教育的に何のメリットも無いので、本当にやめて欲しい。
何が問題かと言えば、多くの教科書でこの表記が使われるにも関わらずその定義が書かれていないことだ。これは喩えるなら、実数a, bに対して「a ☆ b」という操作が行われているが、肝心の二項演算子「☆」の定義が無い、というようなものだ。
定義が書いていないなら、例題などからその計算方法を推測するしかない。しかし、よりにもよってその例題が、「Sが球面で、Fの大きさはSの中心からの距離にのみ依存する」といった積分が必要ないものしか載っていないのである。
このような教科書では、この計算が出てくる概念を正確に学ぶことはできない。
そもそも、この計算はこんな意味不明な表記を使わずとも書ける。
x, y, zを変数とする直交座標で、F = (Fx, Fy, Fz)とすれば、
である。ただし、lやSを適切な「向き」でパラメータ表示しないと符号が逆になることに注意。この表記は、同時期に数学で学ぶであろう微分積分の教科書に必ず書いてある。
上記のように微分形式を使うことには、単に曖昧さがなくなるというだけでなく、大きなメリットがある。
みたいなベクトル解析の定理を3つほど覚えている。微分形式を使うと、これらの定理を覚える必要がなくなる。
Dを境界がなめらかであるなどの十分によい性質を持った領域とする（2次元でも3次元でもいい）。∂DをDの境界とする。ωはDの内部および境界で定義された微分形式とする。このとき、上の一連の定理はすべて
∫D dω = ∫∂D ω
何事もなければ社長が死んだショックだけで終わったかもしれない。
7Payと言えばわかるだろうか。詳しくは書けないのだけど、あれと似たようなことが起きてしまった。
かなりのストレスだったと思う。ネットで調べたところ、急性心筋梗塞はストレスでも発症することがあるらしく、そこが少し引っかかってしまった。
様々な理由から現状社長の訃報を知らせるページを検索エンジンにインデックスされないようにしています。
もし心当たりのある会社があった場合でもリンクは貼らないでいただけますようよろしくお願いします。
使うのであれば、ライブラリ、フレームワーク、ミドルウェアの更新（バグ、脆弱性情報）を一生追い続ける覚悟で使ってほしい。
テスト自動化とかそういう発展的なものではなく、もっと根本的なテストについて勉強してほしい。
コードレベルのカバレッジとかそういうのではなく、「境界値分析」、「デシジョンテーブル」、「オールペア法」、「直交表」こういう物について勉強してほしい。
他にもいろんな手法はあるのだけど、上記に上げたもので1個でも知らない単語があった人は今すぐ検索してほしい。
いくら進捗が悪いからと言ってお客さんに順調などと嘘をつかないで欲しい。
遅れている理由を正直に言って（例えばテストの工数が膨れているとか）相談すればお客さんもわかってくれるかもしれない。
また、テストの質もそこまでの物が求められていないとかがわかるかもしれない。
お客さんに相談しないで工数圧縮の為にろくなテストも書かないで動いてるからいい！っていうのは危ない。
自信がない、もしくは、やったことがない・使ったことがない、などは正直に話してほしい。
もしかしたらそのせいで給料があがらなかったり、出世できなくなったりするかもしれない。
だけれど、その嘘のせいで他の誰かに負担がかかったり、他の誰かが不幸になるようなことがあってはいけないと思う。
これに関してはいろんな批判があることは覚悟している。嘘をついてでもいろんな経験をした方がいいって言う人もいると思う。
それでも、どうしても書きたかった。
別にLPIC(LinC)は持ってなくてもいい。本屋で適当に対策本をパラパラめくって、聞いたことのない単語がないレベルであればいい。
インターネットには嘘が散りばめられている。昔は本当だったけど今は嘘になっているものだってある。
一番いいのはエラーメッセージを出している物のソースコードを読むこと。二番目はドキュメントを読むこと。それでもわからない時だけ検索してほしい。
そして、その情報が誰が書いているかをよく見てほしい。書いている人が本当に信用できる、かつ、更新日付が近かったときだけそこの内容を信じてほしい。
公開リポジトリにpush/commitされているメールアドレスを収集している人がいるということ、
公開リポジトリにpush/commitされている秘密情報を収集している人がいるということ、
RDBによってはSQLのIN句に指定できる数に上限があること、
他にもいろいろあるが、1個でも知らないものがあった人は検索してみて欲しい。業界にもよるかもしれないが、本来であれば最低限知っておかなければいけない知識。
これを知らないと適切な設計、ましてや適切なコーディングすらできなくなる。
ぼくはエンジニアに向いてない
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)
private メソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、private メソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の public メソッドの重複部分を private メソッドに抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)
きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)
しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。
伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)
単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)
private メソッドをテストするかどうか？ まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)
特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1
テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)
private メソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)
RustやGoではプライベートメソッドに対するテストが簡単にできる。
そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。
Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)
Rustではプライベートに対して何の手間もなくテストが書ける。
Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
今日のコーデ（coord）は、直行する三本の直線をあしらったクールなコーデだよ！
＼カーテシアンコーデ！／
「パッカーン！ コーデゲットォ！」
今日のコーデ（coord）は、円と直線のをあしらったキュートなコーデだよ！
「パッカーン！ コーデゲットォ！」
今日のコーデ（coord）は、球対称が素敵なエレガントなコーデだよ！
コーデ：ファッションのコーディネート(coordinate)と座標系(coordinate)って同音異義語だったんだね
カーテシアンコーデ：みんな大好きX-Y-Z軸の直交直線座標系。名前はデカルトにちなむんだね
シリンドリカルコーデ：茶筒でおなじみ円筒座標系(cylindrical coordinate)なんだね
スフェリカルコーデ：まんまる球座標系(spherical coordinate)なんだね
新快速は速いから普通列車を降りた途端にホームにやってくるじゃん。
だから急いで新快速の乗車列に並ぼうとホームの直交方向に走るじゃん。
でも新大阪はホームが長いから新快速はなかなかスピード落ちないじゃん。
それが目に入ると新快速につられてホームの進行方向に身体が動くじゃん。
でも新大阪はホームが広いから乗車列になかなかたどり着かないじゃん。
そのうち頭が新快速と合体して頭に働く合力と身体に働く合力が違うじゃん。
新幹線も通るから人も多くておれが新快速で新快速がおれになるじゃん。
気づいたら新快速は多くの人と夢を乗せてホームから居なくなってるじゃん。
残された方の新快速こと自分はホームを枕にして夢見ずに反対側を見るわけじゃん。
普通列車は発車してなかったから新快速のスピードで慌てて戻るじゃけん。
普通列車は停まったままだからホームの直交方向に走るもコケずに乗れたじゃん。
それって結局新大阪では新快速になるも乗れずホームでスーツを汚しただけじゃん。
新快速の「新」って何なの？
公理から初めて論述によって命題を示すという手法は現代数学の基本
ユークリッド幾何学では厳密な論証を学ぶことができる
もしユークリッド幾何学を学ばなければ抽象代数学などが理解できなくなることは明らか
微分積分などだけを教えていると群論やガロア理論などが理解できなくなってしまう
ガロア理論では作図が主に扱われるからユークリッド幾何学応用になっている
ユークリッド幾何学はまず中初等教育において論述を教える題材として適している
代数などはただの計算であって厳密ではないがユークリッド幾何学は公理から始めて曖昧さなく命題を示す
これは現代数学の基本であって群論やガロア理論を学ぶ際に必要な能力
代数では多項式とは？集合とは？などが厳密に説明されていないがユークリッド幾何学には曖昧さは無い
ユークリッド幾何学が扱う題材は図形であって初等教育にも馴染みやすい
現代数学を厳密に展開するには公理的集合論まで遡らねばならないが
このような条件を満たす単元は他には無い
群論やガロア理論などの抽象代数学はユークリッド幾何学の考えを継承している
これらが確立されたのは18世紀であり微分積分などはそれよりも大分昔の理論だから厳密性がない
ユークリッド幾何学は現代数学のモデルであるから論述を教えることができる
群論やガロア理論は対称性を扱う数学で対称性とは回転や相似変換などの一般化だから
やはりユークリッド幾何学を学ぶことは群論やガロア理論を学ぶことに役立つ
特に群論では、群の正規群（特異点を持たない群）による商で対称性を分類する
この割り算にはユークリッドの互除法のアルゴリズムを用いることができるからユークリッド幾何学の応用になっている
群論の一部であるリー群ではユークリッド空間の回転である直交群を扱うからこれもユークリッド幾何学が直接役に立つ
ユークリッド幾何学では公理系から始めて命題を証明するがこれは現代数学の基本
群論やガロア理論もこのスタイルを継承していてユークリッド幾何学を学ばないと抽象代数学が理解できない
ガロア理論はユークリッド幾何学と同様に、対称性の公理から作図可能性を論ずる
これはいくつかの公理から始めて可能な手順の組み合わせを厳密に論述することで様々な図形を作図していく
ヒルベルトが提唱した円積問題などもこの応用であって、現代数学において極めて重要
ユークリッド幾何学は公理から始めて論述のみによって命題を証明する
これは現代数学の基本であってガロアの理論やヒルベルトの理論などがその手法を受け継いでいる
ユークリッド幾何学をやらないと抽象代数学などを理解できなくなってしまう
代数などでは計算しかやらず概念の定義が曖昧だがユークリッド幾何学の論述には曖昧さが一切無く
