  |
はてなキーワード: 変数とは
１．恣意的に別条件付け足したらミラーリングじゃなくなるでしよ
の記載内容に関して論理的根拠は問題ないと思う。ただ今時、女性向けの性的商品であるBLが駅や新聞広告に頻繁に登場する中で、ネットの素人議論ならともかく「たわわ」に関しては、なぜ曲がりなりにもプロの報道機関や研究者が取り上げるんだろうか？
https://www.moj.go.jp/content/001324318.pdf
P.12より
「◦ アダルトサイト（暴力的性行動，小児ポルノなど）などで逸脱した性的ファンタジーを強める
https://www.moj.go.jp/content/001362700.pdf
P.16より
「アダルトビデオやアダルトサイトのようなことをみんなしたいと思っているはずだ」
https://www.jstage.jst.go.jp/article/pacjpa/71/0/71_3PM012/_pdf/-char/ja
「モデルで導入された外敵潜在変数は「メディア興奮」「性的欲求」「性格特性」「女性認知」の４つである。強姦や暴力メディアに興奮しやすいほど、そして性的欲求が高いほど買春、違法ポルノやのぞきといった逸脱した性行動をしやすく、逸脱した性行動をしやすいほど、そして性的欲求が高いほど、および平等的性役割感が低いほど、悪質な性加害行為を執行しやすくなる。」
上記のように法曹や心理学の分野では、性犯罪者は男尊女卑的な価値観に影響されやすく、性的ファンタジーの反芻と強化が逸脱した性行動を引き起こしてると記載がある。性的商品が性犯罪者の認知に影響を与えることが認められてるよう。
なので言及元の記事にある「言われたことに反論出来なくなったらとりあえず『性暴力ガー』と絶叫しておけば最悪引き分けまで行ける」などの主張は、法曹や心理学の世界での根拠付きの議論と比べると弱いと思う。少なくとも、性犯罪の要因として根拠が示されていることを考えると、男性向け性的商品の批判はある程度根拠があると言えると思う。
ポルノも酒と同様に、禁酒法のように全面的な規制が闇に潜り犯罪化を促す可能性があると思う。実際、フランスで買春を禁止する方向での規制が行われた結果、セックスワーカーの活動が闇に追いやられたという報告もある
「フランス買春処罰法がセックスワーカーの仕事と生活に及ぼした影響」
引用記事はセックスワーカーの権利を推進する団体が書いた記事とはいえ示唆としては参考にできる。
ポルノや買春の極端な規制は性暴力の問題解決に効果がない可能性があるよなあ。結果として、男性向け性的商品がなくなることはないと思う。
性暴力被害者側が多い女性（もちろん男性にも被害者はいる）だけでなく、性被害に遭っていない男性も「男性向け性的商品はファンタジーであり、性暴力衝動を肯定するものではない」って当たり前の考え方を広めることしかないかなあ。引用した法務省の二つの資料でも
「性犯罪者の現状」P.10より「性に関する認知のゆがみとは◦性犯罪者だけでなく，実は社会もその多くを共有してはいないか？」
「性犯罪加害者の理解と対策」P.5より性暴力を強要する側とされる側の力関係の発生について「この背景には日本社会の文化的背景も影響している」
と社会の性差別的な思考が性暴力の発生に影響を与えている可能性があると認識してるようなのよ。昨今例のジャニーズ問題で女性と思われる人によるセカンドレイプが問題になる中でさえ、「フェミニストはバカ」と同じくらい、いえそれ以上に「男性は性犯罪者になりやすい、統計的数値にもでてる。男性向け性的商品も影響ある」と思われてる。その認識を解消するしかないんじゃないかな。
ネットの匿名記事とはいえ、ジェンダーの話は、どの立場からも問題点の洗い出しや分析、解決案を考える気の無い素朴な記事が多いなと思うので女性の立場からちょっと書いてみた。
https://b.hatena.ne.jp/entry/4753165127601855040/comment/frothmouth
この記事に対するエビデンスの弱さを指摘いただいた。ありがとう。ただブコメでも書いたけど、私のリテラシーのなさより、男性が法務省のような政府機関から弱い根拠で性犯罪と結び付けられる方が問題大きいと思う。その関係が弱いなら性犯罪の対策誤った認識で取られてるってことやん。ちょっと検索したけど性犯罪とポルノの因果関係が弱い証明の記事って本当に見つけにくいのよ。それを持って性犯罪とポルノの因果関係の強弱は決めれないけど、その辺り「女はばか」みたいな話より、ポルノの自由含め、ちゃんと洗い出しや議論する方がええと思う。
https://b.hatena.ne.jp/entry/4753165127601855040/comment/kishimoto0050
「法務省がそうなっているのも大学や言論人の偉い方々が様々な議会や勉強会なんかに参考人として出入りして色々言った結果でもありフェミニズム言説と法務省を切り離せる問題ではない気がしていますがどうなんでしょう」
法務省はフェミニストにロビイング受けている！と言いたいと思うけど、仮にロビイングがポルノ業界に悪影響与えてるなら、なぜネットでフェミニストに反対してる人筆頭に、エビデンス出して反論しないの？酒とかタバコ業界はある程度ロビイングしてるからこそある程度の規制で済んでるのに、なぜポルノ業界はネットの世論味方につけてそれをしないんだろう。ポルノ業界の味方の方々は、たとえネットでも、もっと実行力のある発言を心がけた方が良いと思う。
「法曹界でも意見が割れている」「根拠ない」なら頼む、本当にエビデンスを持ってちゃんと議論した方がいいと思う。少なくともポルノ業界と利益造反するフェミニスト業界と思われる人は一応政府機関に食い込んでるわけよ。勝ち負けで言うと、どっちが有利かは考えてみよう。
https://b.hatena.ne.jp/entry/4753165127601855040/comment/li_tide
「法曹の間でも意見が割れてるけどポルノが因果関係をもって悪影響を与えるとまでは認められてないかな。それとたわわや性的商品広告も資料にあるようなポルノとは全く違うので、これらを結びつけるのは雑過ぎる」
確かに雑だ、すまん。ただ規制する方はこちらの記事で２例ほど出したけど、大抵「性犯罪を犯す人は男尊女卑の価値観に過剰適応している」って前提で活動してると思う。
https://anond.hatelabo.jp/20240508152120
なんでポルノに限らず、たわわみたいな性的商品広告も少なくとも女性のモノ化みたいな意見で男尊女卑の価値観に沿ってる、てなロジックで槍玉に上がりやすくはなる。てかなってる。それが間違いだ、という意見はもっと言っていい。
たとえ雑とはいえ、私の稚拙な意見でも、ある程度考えたら批判意見でも煽りみたいな意見減って、論理立てた反論が返ってくるのよ。この調子で男性ももっと言葉を積み重ねてほしい。できれば根拠となる引用つきで。
いい区切りだったので乱文になるけど吐き出させてほしい
8年ほど前、まだ20代後半だった自分が今の会社に中途採用された際に同時入社の同期が１人いた
自分とは歳の離れた40代後半であった同期である彼こそが後に、時限爆弾を仕掛ける人物である
入社した会社はその時期に基幹システムの刷新を考えていたらしく
その募集でシステム部として採用されたのが自分とその同期であった
当時のシステム部の社員は2名体制で1人が60代で定年間近の上司A、もう一人は50代の上司B
2人でなんとか基幹システムの維持だけを行っている状態であった
会社としては基幹システムの刷新以外にも社員の世代交代を徐々に行っていくための採用だったと入社直後に言われた記憶がある
60代の上司A、50代の上司B、40代の同期、そして20代の自分
確かにそのまま行けば年齢層は順調に推移して、10年単位で20代を採用することを繰り返せばいい感じにも思えた
入社してからの仕事としては60代上司Aの定年退職が控えているため、まずは稼働中の基幹システムの仕様理解に日々の業務の引継ぎ
そんな多忙な業務をこなすなか同期と話すうちに彼の人柄が徐々にわかってきた
箇条書きでまとめるとこんな感じだったと思う
・今の会社に採用される前、同じような職を転々として現在8社目であること
・受託システム開発ばかりやっていたが、そろそろゆっくり仕事ができる社内SEでまったり過ごしたいこと
・年齢と経歴の割にプログラムが雑なこと（※これは自分視点だがそう的外れではないと思う
また、今の会社に対してのスタンスや不満が溜まってきていることも伝わってきた
・システムを作る自分たちのチームが上で、運用するチームを下だと見下していること
・その運用チームから稼働テストの際にミスを指摘されると不機嫌になること
中々怪しい気配が漂ってきたと当時の自分は思った
残業に関しては、毎日という程ではないが20時頃までは働いていたと思う、遅くても21時までだったはずだ
ただこれはシステムの刷新が終わるまでという明確なゴールがあったのでそれまでは申し訳ないが対応してほしいと事前に説明があったし残業代もきっちり出ていた
自分は前職が完全にブラックで終電帰り、残業代なしが当たり前という環境もあったため特に問題なく仕事ができていたが同期はかなりストレスだったようだ
給料については会社の方針として勤続給ではなく年齢給であったため同時入社であるものの同期は自分よりかなり貰っていたはずであるが、それでも不満だったようだ
トラブルといってもただ上司Bが打ち合わせ中の同期の態度について不真面目だと切れて説教したのだ
この上司Bと同期の彼は相性が悪いようで度々小さな衝突はあったが上司Bが声を荒げて説教するのは始めてのことであった。
しかしこのことがきっかけで上司Bは同期に対して我慢がきかなくなったのかこの後もおよそ2ヶ月に1度のペースで業務のミスといったことから朝に挨拶をしなかったといった細かいことまで説教は続いた
この状態に嫌気が差した同期はある時を境にプライベートの予定があるからと基本残業はしなくなった
たまにどうしても必要がある際は業務命令という形で残業を依頼していたが、それでも19時くらいまでであった
しかし同期はそれもかなり不満だったらしく
残業した日は会社の最寄り駅と会社の間にあるビジネスホテルに泊まり
翌朝、ホテルの前を出勤中の社長や役員の前を偶然を装ってチェックアウトして遭遇し上司Bが無茶な残業を強要するせいでホテルに泊まる羽目になったとアピールするということもあったという
そのため、ちょくちょくシステム部にたいして過度な残業に関する指導が入っていたと後に上司Aから聞いたことがある
そして入社からおよそ3年が過ぎ、なんとか新システムも完成に近づいた時
しかしこの時は同期も相当機嫌が悪かったのか、それとも今まで積もり積もったストレスが限界だったのか、もしくは両方か分からないが
上司Bも同期もお互いに売り言葉に買い言葉で収集が付かず、上司Bが一旦頭を冷やすといって席を離れた際に同期はPCを少しいじると私物をまとめ無断で早退として帰っていった
なおこの時、上司Aは有給で休み、自分は電話応対中であったため止める者がおらず気がついたら終わっていたといっていいスピード感だった
そして同期は翌日、人事部に退職すると電話するとその後出社することはなかった
新システムの作成中データを取り出すために起動したがそれ以降はそのまま一度も起動することなく放置という状態であった
上司Bは撤去したい様子ではあったが、ある役員から戻って来るかもしれないからとりあえずそのままにしておくようにと指示があったので触れることもしなかった
その後、同期の担当分を自分が引継ぎ新システムの作成にとりかかるが彼の担当していた機能はなんとなく察してはいたが、かなり雑な作りな上
運用部門の要望をまったく聞かなかったため、とてもリリースできる状態でないことが発覚
改めて要望に沿った形で修正をする方針で進めると彼が作成したコードで残った部分は30％も残らなかった、ほとんど作り直しと言っていいレベルだ
そのときには定年から雇用延長となっていた上司Aは区切りがついたと退職
会社の業績もあまり安定しない時期でもあったため追加人員の採用は見送られシステム部は上司Bと自分の2名体制となった
その際に新システム作成が評価されたのと2名体制で苦労をかける事情からか自分は課長に昇進した、4年目のことである
新システムはその後、小さなトラブルはあるものの順調に稼働を続ける
なお小さなトラブルの大半は同期の彼が作った部分が関わっていることが多く
その度に彼が作ったコードは修正され、今では機能の殆どに彼のコードは残っていない
残っているのはせいぜい彼が名付けた関数名や変数名くらいである、中身はもう別物だ
そして6年目のある日、上司Bが突然亡くなった
腹痛を訴え病院へ、で即入院してそのまま復帰することなくという形だ
癌だったらしい
その時の会社の上層部はかなり大慌てであったらしいがシステム部としては正直あまり変わりがなかった
というのも新システムを作る際に運用部門の要望をほぼ取り込んだ結果
システム部の基幹システムに関する仕事はほとんどなくなったといっていいレベルとなったのだ
しかし周りはそうは思っていないらしく、システム部は1人しかいないのだから極力負担をかけないようにと各部門には通達がいったらしい
しかし実態はあれだけ忙しく残業していた日々が嘘のように毎日定時で帰っても問題ないのだ
同期の彼が望んでいたゆっくり仕事ができる環境がここに完成していた
そんな中、同期のPCを残しておくよう指示を出した役員も退職する時期となり
そこで改めてPCを起動して中をいろいろ確認していったのだが、そこであることに気づく
起動回数は1回限りで未実行、起動予定はかなり過去の日付が指定されており、とっくにその日付は過ぎていた
バッチ処理の内容を詳しく見てみるとPCの全ドライブの消去コマンドが書かれていた
同期の嫌がらせだったらしい
起動予定の日付を良く確認すると彼が退職を連絡した日の翌月が指定されていた
しかし実際は彼が退職した翌日以来、PCを起動した事はないしバッチも動作していない
※今回は不発だったから良いけど実際にやると損賠賠償になるから
このことは報告していないが、業務でバッチ処理に関わる度に同期のことを思い出す
もし彼が残っていたら昇進したのは自分ではなく同期となり、彼の言う満足いく給料を貰えたかもしれない
もし彼が残っていたら上司Bがいなくなりストレスがない職場で彼は働けたかもしれない
もし彼が残っていたら運用部門からの要請はなくなり、残業とは無縁な仕事が出来たかもしれない
いや最後のは無理かな
作ってたコード雑だったし、人の話聞かなかったし
ふと彼のその後が気になって調べてみたことがある
世間話で同期がSNSをやっていると聞いたことがあり検索してみたのだ
アカウントは知らなかったが彼の話していた世間話の内容で検索してみると意外なほど簡単に見つけることができた、アイコンも自身の顔写真にしており間違いないと思われた
また次（の次？）の職場で残業がらみのトラブルを起こした愚痴が書いてあった
うちの会社を退職したときの事は何を書いていたのか過去の在職期間の投稿を見てみると大半は案の定愚痴の羅列が並んでいた
そして、その連続した投稿の中で退職直後の時期に面白い投稿があった
要約するならこうだろうか
社内システム作っている自分に無茶ぶりばかり、データ全部消去して退職してやった
直してくれと謝罪の連絡してももう遅い、既に新しいホワイトな職場でまったり仕事中です
彼の中でうちの会社は有用スキルを持った人間を無能と決めつけ追放したギルドのように写っていたらしい
しかし実際はデータ削除の時限爆弾は不発であったし、仮に成功していても
現在彼の書いたコードはほぼ残っていないから直してくれと依頼することもない
そして彼の新しい職場は現在のSNSの投稿を見るに彼基準ではホワイトな職場ではないと自白をしている始末だ
ところで実際彼に連絡した人がいたのかという話だが
上司Bは既に亡くなっているので分からないが、おそらく連絡はとらなかっただろう
彼が退職の連絡をしてきた後、残っていた有給を消化したくらいのタイミング（大体1か月後）で退職に伴う書類の送付先の確認で何度か電話をしたが繋がることはなかったという
どうやら彼はこの連絡を会社からの謝罪の連絡だと思っていたのかもしれない
.txt と .TXT で挙動を変えていた話しがあったやん？
プログラム全体で、TxtFileExt が一カ所でしか使われてないなら、変数にする必要はほぼないけど、
２か所、３カ所になったら、.txt を .TXT に変えるだけでもミスする人でてくる。
.txt を .debug.txt とか .masuda.txt に気分次第で変える時も楽やん
const 〇〇ParamIntMax = 25;
もプログラム全体で、一カ所しか使われてなければ変更ミスは生じないけど、
何カ所にも別れたら、変更時に見落とすやん。
いろんなアプリケーションのメンテ(バグ取りとか細かい機能追加とか)を何度か経験してきた。
主にテキストファイルとかCSVファイルとかExcelファイルとかを入出力するものばかりだったんだが、その大半がファイルの拡張子をグローバル変数化していた。
こんな感じ
const TxtFileExt = ".txt"; const CsvFileExt = ".csv"; const ExelFileExt = ".xlsx";
outFileName = 〇〇 + ×× + "ABCDEFG" + TxtFileExt;
みたいな指定をしなきゃならない。
あと、プログラム言語の標準的なメソッドのあらゆる引数も全部変数で定義されてて、そのまま渡すのは禁止、みたいな規約になってる。
たとえば引数が三種類(true、false(未指定時のデフォルト値)、任意の数値(ただし当該プログラムでは0、10、25以外指定不可))しかないやつはこんな感じ。
const 〇〇ParamTrue = true; const 〇〇ParamFalse = false; const 〇〇ParamIntMin = 0; const 〇〇ParamIntMid = 10; const 〇〇ParamIntMax = 25;
const charCodeSJIS = "Shift_JIS"; const charCodeUtf8 = "UTF-8";
以前関わった改修内容に「××の処理は開始時と終了時にそれぞれUTF-8(BOMなし)形式でログを出力する」みたいなのがあって、普通に文字コード指定する部分に「UTF-8」で直に書いたら、規約に従ってないからとコードレビューで指摘されて差し戻されたんだけど、そもそもこういう規約って何の意味があるの？
「与えられた変数のオーダーに従って、それが許容される計算量のラインのアルゴリズムを探して、それを実装するゲーム」
って理解で合ってる？
難しいところは
・アルゴリズムを探す
・実装する
という認識でいい？計算量がいくら許容されるかは結構すぐわかりそうだし
で最終的には「アルゴリズムを探す」という点に終着する。アルゴリズムがわかれば、実装するというのは比較的簡単だろうしね
この変数のオーダーならO(n^2)でも大丈夫だけど、これはO(logn)のアルゴリズムが必要だ。O(logn)のアルゴリズムで処理したデータはこの程度のオーダーなので......。これを繰り返していく感じ
自分はマジで最初の最初の問題すら実装できないんだけど（AtCoderならABCのA問題すら ChatGPTの解説が必要）
電気料金が複雑化しすぎて、どの電力会社が得なのか計算しきれなくなってるんだけど、どうしたらいい？
たとえば、自分（単身者）の3月の電気料金は、「まちエネ」で20A契約（きほんプラン20A）・124kWh・4016円だった。
4016円の内訳
まちエネから東京電力エナジーパートナーの「従量電灯B」か「スタンダードS」に変えたいと思っているんだけど、変数が多すぎてどれが最も得なのかが分からないんだ（電力比較シミュレーションを使っても燃料費調整額などはなぜか計算されない）。
ちなみに年間で最も電力を使わない月は98kWh、最も使う月は322kWh。
発達障害みたいなバグを量産してしまってチームからの目が痛い。
正直これはPythonのせいだ。
例えば
if is_checked:
この構文、”False"という文字列ではTrueになってしまう。想定外にオブジェクトが入ってしまっても普通にTrueになってしまう。想定外のNoneが来てしまうとFalseになって開発中はなかなか気付かないなんてこともある。基本的にifの後は if hoge == True: と書くべきだと思ってる。linterで怒られることもあるが、それよりもバグに気付けない方が怖い。
if "1" == 1:
これはfalseだけど、これが変数で来てたりすると全然気付かない。
for i in user_list:
こんな構文でuser_listにはリストが来ることを期待していたのに文字列を入れてしまうことがある。
そうなるともうぐちゃぐちゃ。
user_list += user_id
これはuser_idが ["hogehoge"]ならうまくいって"hogehoge"なら["h", "o", "g", "e", ...]が追加されることになる。
これも気付きにくい。
いずれも開発段階では気付かないことが多い。テスト段階になったり、テストないような突貫工事体制だとリリース直前の動作確認で気付いたりする。
リストを入れるつもりだったのに文字列を入れてしまったりbooleanを入れるつもりだったのに文字列が入れられるからこんなことになる。性的型付けしか受け付けたくない。
コーンフレークじゃなくて、Haskellだとして、全体のネタを書き直してくださいっていう指示した結果
ボケ＆ツッコミ「お願いしますー ありがとうございますー」
ツッコミ「あー ありがとうございますー ねっ 今Githubでスターをいただきましたけどもね」
ボケ＆ツッコミ「ありがとうございますー」
ツッコミ「ねー 有り難いですよ ほんとにね」
ボケ「入れておきましょう」
ボケ「いきなりですけどね うちのオカンがね 好きなプログラミング言語があるらしいんやけど」
ツッコミ「プログラミング言語の名前忘れてもうて どうなってんねそれ」
ツッコミ「分からへんの？ いや ほな俺がね おかんの好きなプログラミング言語 ちょっと一緒に考えてあげるから どんな特徴ゆうてたかってのを教えてみてよ」
ボケ「あのー関数型言語で、型システムが強力で、遅延評価するやつやって言うねんな」
ツッコミ「おー Haskellやないかい その特徴はもう完全にHaskellやがな」
ツッコミ「すぐ分かったやん こんなんもー」
ツッコミ「いやそうやろ？」
ボケ「オカンが言うには 将来の夢はそれで書かれたOSを使うことやって言うねんな」
ツッコミ「あー ほなHaskellと違うかぁ Haskell製のOSなんてまだ無いもんね」
ボケ「そやねん」
ツッコミ「HaskellはOSを作るのには向いてへんからなぁ」
ボケ「そやねんな」
ツッコミ「な？ Haskell側もOS開発に任命されたら荷が重いよあれ」
ボケ「そやねんそやねん」
ツッコミ「Haskellってそういうもんやから ほなHaskellちゃうがなこれ」
ボケ「そやねん」
ツッコミ「あれほなもう一度詳しく教えてくれる？」
ツッコミ「Haskellやないかい モナドは確かに難しいねんHaskellの でも俺はね あれはHaskellの良いところやと思うねん 俺の目は騙されへんよ 俺騙したら大したもんや」
ボケ「まあねー」
ツッコミ「ほんであれよー いざ使ってみたらね モナドのおかげでコードがスッキリするねん 俺は何でもお見通しやねんから Haskellのモナドなんて」
ツッコミ「そうやろ」
ボケ「オカンが言うには プロダクションで使うにはまだ早いって言うねんな」
ツッコミ「ほなHaskellちゃうやないかい プロダクションでHaskell使ったら 上司がひっくり返すもんね Haskellはねー まだ研究段階やから実務では使いにくいねん」
ボケ「そやねんそやねん」
ツッコミ「な？ Haskell使ってみたらだんだん罠が見えてくるから 最後ちょっとだけ避けてまうねんあれ」
ボケ「そやねんそやねん」
ボケ「そやねんな」
ツッコミ「Haskellちゃうがな ほな もうちょっとなんか言ってなかった？」
ボケ「学生の頃 なんでみんな憧れるんか分からんかったらしいねん」
ツッコミ「Haskellやないかい 学生の頃はHaskellとOCamlとLispに憧れるんやから あとSmalltalkも憧れたな Haskellそんなもんよ」
ツッコミ「そうやろ」
ボケ「オカンが言うには 関数型プログラミングの教科書に必ず載ってるっていうねん」
ツッコミ「ほなHaskellやないかい 教科書のサンプルコードにHaskellのコードが出てこんわけないやん」
ツッコミ「Haskellはね 関数型プログラミングの王道中の王道やねん」
ツッコミ「Haskellや絶対 ほな ほなもうちょっとなんかゆうてなかったか？」
ツッコミ「Haskellやないかい Yesodとかあるやろ な？ RubyとかPythonの次はHaskellが来るって言われてるねん 俺はそう思うよマジで Haskellや絶対」
ツッコミ「そうやて」
ボケ「オカンが言うには ジャンルでいうたら数学やっていうねん」
ツッコミ「ほなHaskellやないかい ジャンルで数学言うたらHaskellしかあらへんやん な？ Haskellは数学の理論がベースになってるんやで ラムダ計算とか圏論とかな」
ボケ「そやねんそやねん」
ツッコミ「ほなHaskellに決まりやないかい ほなもうちょっとなんかゆうてなかった？」
ツッコミ「Haskellやないかい Haskellは変数が不変やから 変数に感謝するのは当然やねん ね？ 状態変更せんと安心して使えるからな」
ボケ「そやねんそやねん」
ツッコミ「Javaとかの変数は裏切るからアカンねん Haskellの変数は一生そばにおってくれるから最高やで」
ボケ「でも分かれへんねん」
ツッコミ「分からへんことない おかんの好きなプログラミング言語はHaskell もぉ」
ボケ「でもオカンが言うには Haskellではないって言うねん」
ツッコミ「ほなHaskellちゃうやないかい オカンがHaskellではないと言うんやから Haskellちゃうがな」
ボケ「そやねん」
ツッコミ「先ゆえよ 俺がラムダ計算の説明してる時どう思っててんお前」
ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」
ボケ「んでオトンが言うにはな」
ツッコミ「オトン？」
昨年子どもが生まれ、育休を3ヶ月取った。都内の上場スタートアップ勤務ということもあり、男性育休には寛容な環境で、同僚からはお祝いにおくるみもいただき、前向きに送り出してもらった。
当然だが、とてもハッピーな気持ちで育休に入った。出産に立ち会って自然と流れた涙は、これまでの人生で最も無垢で、言葉にならない嬉し涙だった。仕事と子育てを両立して、より一層充実した人生を送っていくぞと意気込んだ。
しかし、育休中に痛感したことがふたつある。
まず、育休中は仕事をしていないので、育休を取ったからと言って仕事と子育てを両立したとは思えなかった。数ヶ月程度の育休は「特に大変な新生児期を乗り切る手段」であって、「仕事と子育てを両立する手段」にはならないのが現実だ。
そして2つ目に、「両立」と勝手に言っているが、それは自分だけの問題なのかということ。子育ては夫婦の共同プロジェクトだ。義務教育までとしても15年を要する、一大プロジェクト。そのプロセスにおいて、当然、妻には妻の「両立」がある。
育休は子育てのほんのプロローグに過ぎず、その後が本番と言ってもいい。
3つそれぞれの満足度（納得度の方が適切かも）のバランスをどうやって保っていくか。中長期的にはこれが1番のテーマで、もはや、要素がふたつであることを前提にした「両立」という言葉で捉えること自体が、時代遅れに思えた。
妻はメーカー勤務で、仕事好きな人間だ。バリキャリ志向ではないが、自社商品を愛してやまないタイプで、今後もフルタイムでの仕事を望んでいる。彼女が仕事を通して充実感を得ることは、一緒に生きる私や子どもにとっても大切なことだ。
私は会社に働き方の相談をした。フレックスがなく、リモートにも回数制限があるため、せめて後者は緩和できないかと。しかし残念ながらその交渉は実らなかったため、転職を決めた。
次はリモートかつフルフレックスの環境で、幸いなことに年収も大きく上がるオファーをもらえたので、自分自身の問題は解決できたが、これだけ少子化が社会問題になる中でも、子育てと仕事の両立に優しくない現実を突きつけられたモヤモヤは消えていない。
経済合理性が伴う事由や、事業を左右するような外圧がなければ企業は変化しない。女性社員の活躍を進めて社会情勢に応じつつ、男性社員にはこれまで通り仕事にフルコミットさせたい。これが経営者の本音だろう。
しかし、その男性社員に子どもがいるとなれば、しわ寄せはパートナーの女性にいき、どこかで働くその人のキャリアを制限し、家庭の幸福度の総量も減らす。間接的に女性活躍を阻害しているわけだが、大半の企業は「知ったこっちゃない」と言うだろう。
だから思う、男性こそ子育てを理由に転職した方が良い。環境や制度を変えなくても男性社員が辞めないから、企業も変わらない。賃上げだってそうだろう。
厄介なことに、子育ては本当に千差万別。子の性格や体質、家庭の経済力、時間の柔軟性、幼稚園や保育園の環境、本人やパートナーの体力、実家の頼りやすさなど、いろんな変数で難易度が変わる。
カードに恵まれただけだったかもしれないことに想像が及ばず、n=1の個人的な体験談で断じてしまう人もいる。そういう人が上司や経営者の会社にいるなら、すぐに転職した方が良いと個人的には思う。
少子化と人手不足が課題の社会なのだから、共働きで子育てもしようという自分は多少わがままを言ってもいい。自分にそう言い聞かせることで、同僚に迷惑をかけることを頭から消して長めの育休を取り、転職も決めることが出来た。
仕事より家庭、という安直な二元論では捉えていないし、仕事ももちろん頑張っていくが、「仕事=今の職場」ではないはずだ。
繰り返すが、男性こそ子育てを理由に転職した方が良い。それが大きなうねりになれば、いろんな問題が少しずついい方向に向かうように思う。
本屋自体が少なく、あっても技術書の専門コーナーなんてない田舎住まいだったので、
Amazonで専門書を買って勉強してたんだけど、本当に何も知らないので「基礎から」って本を数冊買った。
しかしどの本も全体のうちの半分は「ハローワールド」と「変数の基本的な使い方」と「ifの使い方」で占められ、
そこを超えるといきなり、コード掲載だけが10Pくらい続く本格的なプログラミングを解説なしでやらされるものだった。
知らない命令とか構文がいっぱい出てくるし、それを一々ネットで調べないと進められないので全部挫折した。
更に本を追加で買って、運良く段取り良く進めていってくれる本にあたったことでなんとかなった。
その後、別の言語を勉強しようとする度に、全体のうちの半分は「ハローワールド」と「変数の基本的な使い方」と「ifの使い方」で占められ、る本に当たるし、そこについては大体どの言語でもやり方は同じで、まるまる読み飛ばすことが多い。
今日日、エクセルをちょっと触ってればifくらいは普通に使うものだからパソコンで仕事する人ならみんな知ってると思うし、シリーズとして「ifくらいまでは知ってるところからスタートする入門書」が欲しいなぁと思う。
標準的な経済理論で経済主体の行動を決定するのは、名目変数ではなく、実質変数である。
「賃金と物価の好循環」がなぜ好循環なのか。「デフレを抜け出したいでーす！ピロローン！」ぐらいの根拠しかない。
経済の実質値がインフレによって高まるということはあるのだろうか。
名目賃金と物価が同時に上昇する経済の方が、互いに凍結し合っている経済よりも好循環が起きやすい、という見方を100歩譲って認めるとしてみる。
家計が企業のように、物価・賃金の名目値が上昇する経済が、消費や住宅投資をより増やすかと言われれれば、それはかなり怪しい。
貨幣錯誤はあるかもしれないが、実質賃金が低下し、物価が高まれば消費は減る。当然である。
「賃金と物価の好循環」の正の効果が、他のリスク要因を上回るかというと、断定はできない。
経営者としてお答えしよう
ファック死ね
業務時間を割いてなにかやってるのは知っていが注意すると拗ねてモチベ下げるので黙っているが、管理職には絶対に上げないフラグを立ててるからな
持続可能性
頼むよ、これを意識してよ
仮に５秒短縮が当該業務担当５人、１０回／日だとして年間１６時間。。。
ん？わりとデカいな。
頑張れ
違う違うちがう
どうせ空いた時間は給湯室でくっちゃべってるだけだ
知るかボケ
あのな、頑張って勉強して業務効率化に寄与してくれるのはありがたいが、
オマエ死んだらどーすんの、連想配列が保守メンテできるスタッフ他にいる？
ワークシート上のセル式ならなんとか追いかけられますが、VBAでややこしいことやれたらわかりませーん、だよね？
VBAでゴチャゴチャやられるといざ業務拡大近代化の時に余計な工数もかかるの。
ワークシート上で処理完結してて適度にコメントも書いてくれてたらそれがそのまま要求仕様、ドキュメントになるの。
プログラム化されちゃうと要求仕様はそこから紐解かなきゃならない、そんだけ余分な工数がかかる。
残業して連想配列してるのは分かってるが、さっさと帰って婚活でもして、ブサイクな嫁とアホの子供でも作って、あぁもう迂闊に会社辞められねぇ、ってなってくれたほうが会社はありがたいの。
美しくない？
知るかボケ
どこにどれほどリソース割くべきか
こっちもアホでは無い、経営多変数パラメーターを加味して妥協し方向性と優先順位決めてるんだ
頼むから言う事聞いてよ
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
数学の必然性は実は人間の言語分析能力によるものなので、言語能力が異なる宇宙人とは、数学的語彙が共有できない可能性があるんですよね～
なぜ数学と言語能力が関係するんだ？と思う人は、以下のノーム・チョムスキーの有名な、無意味な二種の文を見ればわかってもらえるかもしれませんね～
・“Colorless green ideas sleep furiously.”（「無色の緑の考えが猛烈に眠る。」）
・“Furiously sleep ideas green colorless”（「猛烈に」「眠る」「アイデア」「緑色」「無色」）
前者は文法的には正しいが意味が無い文で、後者は文法的に正しくないから意味がない文、ということはわかっていただけるかと思います。
しかし、上記二種の文は、両方とも経験的には何も想起させないがゆえに、経験的には同様に意味の無い文です。
ということは、経験こそが認識の基礎、基底であると考える人にとっては、二種の文の違いを説明することができないのですよね～。
なぜならそのどちらも経験することができず、経験による理解が基底であると主張するのだから、経験的基底において違いのない(意味のなさ、指示対象が存在しないという点において同質という意味)上記二種の文の本質的差異(基底的差異)を指摘することができないのですね～
現代の言語哲学、そして現代論理学の基礎を作ってきた哲学者たちは、数学の必然性がどこから来るのかという問題について、
文の経験的理解よりも前に、文の文法的分析が先に行われる(そして数学的必然性は、文法分析に基づく理解そのものから正当化可能である)ことを示すことによって、
前経験的(アプリオリ)に論理や数学の必然性の正当化が可能であることを証明してきたんですね～
例えば上記二種の前者の文でいえば、経験できないにもかかわらず文法的に正しいことが理解できるのは、まず文法分析が先に行われ、その後意味の解釈に失敗するから無意味なのであって、その逆ではないのですね～
そして数学で扱われる文、例えば2+2=4は、なんらかの経験を前提せずとも、形式的な理解(つまり文法的理解)から正当化可能であるがゆえに必然的(=非偶然的、または前経験的)なのですね～
そして例えば上記二種の文とは別の有意味である文「無職の緑色のジャージを着た男性が猛烈に眠る」であったとしても、まず文法的理解が先に行われたあと、その意味解釈を行うことができるがゆえに有意味なのですね～
プログラミング言語だって、まずどれが変数で、その変数に何が割り当てられているかといったセマンティクスよりも先に、シンタックス的分析が行われますよね～
だから、数学の必然性は実は人間の前経験的な言語分析能力によるものなので、言語能力が異なる地球外生命体と遭遇した時、数学的語彙が共有できない可能性ももしかしたらあるのかもしれませんね～
なぜなら我々の理解する必然性とは、我々の言語分析能力に基づくものであって、よそから来た宇宙人にそれが期待される理由がないからですね～
GitHub Copilotは変数名やメソッド名をちゃんと規則立てて付けてるとめちゃくちゃ優秀に機能する
boolean open
みたいに付けてると微妙なこともあるけど
boolean isDialogOpen
他にも、createDataDayっていうメソッドがあって似たようなcreateDataMonthとかが乱立してるときに実装を共有化したいって思ったときなんかは
function createDataBase
ぐらいまで打ち込むと共有部分だけ抽出してくれる
命名規則だけじゃなくて実装のアルゴリズムがちゃんと整理されて設計されているとこっちがやりたいことを把握して実装してくれる
この辺は例が難しいけれど、なんかCopilotがまともなことを返してこないな、と思う時はこっちの実装が微妙な場合が多い
整理しなおして分かりやすい状態にしておくと綺麗に動いてくれる
Copilot使えねーって言ってる人のソースはほぼ100%こういう最低限のことができてなくて
とか言ってる奴は50%ぐらいの品質の命名規則やアルゴリズムになってる
の具体的になんて本(ネットのpdfでもよい)の何ぺージあたりからが元増田の問いにとって核心なのって話よね
てか、ラムダ計算よりむしろ記号論理学のほうが学問としての領域が気持ち広くなってね？
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
(後略)
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
「Aかつ¬Aの証明を得ることができる」に対して、「いいや得られない。お前がそのように見せかけているだけだ」おれの計算(記号処理)手続きこそ推論規則に適っているし正しいと、反論されたら？
また、「そもそもここでいう『得る』とは」どういう意味か？と突っ込まれたら曖昧でなく『得る』ということが『得る結果の具体例ではなく』『どういうことか』記述できるのかという話です。
￢￢Ａ→Ａという規則に基づいた結果が
￢￢￢￢￢Ａ→￢￢￢(￢￢Ａ)→Ａ
なんだよ！と言い張られる。もちろん常識的にはおかしいと思えますが、いまは突き詰めたことを言っています。
一般には、￢￢￢￢￢Ａを書き換えるために、この記号列の一部分￢￢Ａに着目して、規則からＡと書き換えられるから、この結果を￢￢￢(￢￢Ａ)に代入？して、￢￢￢Ａに書き換えられる、という思考プロセスをとるでしょう。
しかしあくまでものとしては、ここで考えているのは￢￢Ａではなく￢￢￢￢￢Ａなわけです。
規則通りに書き換えられてない、言い換えるなら同じ規則を使っていないという主張に対して、そもそも同じ規則が適用できているということ、規則が同じとはどういうことか自体を定義や公理に組み込むことはできるのか。
矛盾や証明ということはまだその概念を記号列で示す余地があるが、規則が同じかどうかという定義もとい「規則」は厳密に定義可能かということです(無定義語として関係性の定義でもよい)。図形が合同か、みたいな合同の概念の定義など比べてもまたレイヤーが一段メタ的になっていて厄介というか。「違うのは自明じゃないか！」といっても、自明は説明できてこそ自明なのですが、ここでいう同じかそうでないかということについてはそれを根拠だてる定義は原理的に無理なんじゃないかと思えてしまいます。
さきほど『得る』という言葉に突っ込まれたら云々ということを言いました。
ブコメには「自然言語の曖昧さで数学をの厳密さ否定しようとしてるだけだ」というのがあります。
別に私は自然言語の曖昧さを問題にしていません。そこは問題の本質ではないです。
むしろこうした言葉は一般に疑いようなく明らかなものです。「左右」とか「これやあれ」みたいな近称や遠称の概念などもそう思われるでしょう。
しかしむしろこれらの概念には一切曖昧さはないという前提に立っても、これもごく単純な話で、曖昧でないからといって、いままでその概念を持ってなかった知性的存在に対して、「これ」や「左右」といった「概念」を、対面やジェスチャーを使えばいざしらず、記号列を用いて一意に定義できる保証はないよね、ということです。定義の厳密さを担保する必要条件が、記号論理学に基づくということにあるのなら、数学を厳密とのたまうかぎりにおいて、当然対面やジェスチャーではなく、これとか同じとかみたいなもっとも原始的な部類の言葉まで全て記号で一意に定義できることを示せなければならないでしょう。
あとあなたが↓のトラバと同一だと言ってくれたら以降↓の方のツリーに返信書いて一元化するのでそのつもりで
https://anond.hatelabo.jp/20240216215810
ちなみに関連しそうな話題として自分自身ラムダ式を勉強した経験があるけど
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
分かってる人からみれば、そして俺にとっても￢￢￢￢￢Ａ→Aと同程度にバカげた主張なんだが、そのわかってる人にとっても「この規則ならこういうことが言えると思うのに、なんで正解とされてるのと自分が思ってることが違うの？」ってなることはあるはずで、それはこの世で一番数学ができる人であってもありえること。この世で一番数学ができる人さえ規則を正しく適用できていないらしいとき、そもそも正しい適用とはなんだってなりそうに思うんだが。