  |
はてなキーワード: 変数とは
先日とある話し合いの場のような所に参加してきた。
そこは哲学的に議論しようというスタンスの集まりで、ある話題について色々と話したんだ。
どんなことを話し合ったのかは身バレしてしまうので詳しくは書けないんだけど、それでも話を聞いていて一つ思ったことがある。
x + 1 =
xは変数で、どのような数も入れることが出来る。このとき正確な答えを導き出すことは可能か？
当然、無理だ。
話を聞いていて、ふとそう思ったのだ。
そもそも答えのないものを哲学的と呼ぶようだし、人によって価値観は違うのだからxの数値は常にバラバラになってしまう。
それなら答えが出ないのも当然で、答えのない答えを求めたところで意味はあるんだろうか？
「技術的に何ができるのかは、仕様を考える上であまりにもインパクトが大きい変数です。それを考慮せずに仕様案を作ること自体が筋が悪い」
ここでもうわかってるんだけど、世の中よくあるように近視的になっちゃってその後が迷走してる
仕様案を作ること自体が筋が悪いんだからつまり仕様案を作っちゃダメなんだよ
普通に考えたらそれ以外ないじゃん
ユーザーのやりたい事は例えばここみたいなサイトなら「興味がある記事が見やすいとこに出る」とかであって、どこを太字にするとかどこに表示するとかどういう条件でやるとかなんならAIぶち込むかとかはエンジニア側で決める事
まあそれをやるには組織がフラットでエンジニア側の能力と給料と権限がPOと同等以上じゃなきゃいけないわけだけどおそらくそこが癌だろうね
オブジェクト指向とかかっこいい言い方をしても無駄だ。従来の構造化プログラミングから進歩したことなど一つもない。オブジェクト指向がなぜダメであるのか、それを今から話すぜ。
1. データと処理をまとめるという発想。
データと処理をまとめてクラスとして置くという発想がある。しかし、このようなことをしなくとも、モジュールという単位で利用データと処理の集合をまとめればよかったので、クラスを使う必要はない。しかもクラスはインスタンス化のときに、不要な情報まで持ってくるのでメモリ効率が明らかに悪い。コンピュータが進化しているからメモリのことはあまり考える必要がないとはいえ、必要ない処理をまとめて閉じ込めるのは無駄が多い。なぜクラスという名詞で概念分類できると考え始めたのかは不明だが、アルゴリズムとデータ構造という構造化プログラミングの手法を、クラスと型というパラダイムに変換することで型にうるさいC++馬鹿を生み出し、彼らが発狂することになってしまった。しかもデータと処理にわざわざ依存関係を持たせて、変更に対する柔軟性を失わせている。
2. 継承
継承によって既存の構造を持ってこようとする必要性が全く無い。それどころか、継承を使うことによってプログラムがスパゲティ化し、依存関係のグラフがややこしくなってしまう。継承など使わず、必要な情報はスコープの限られた共通の変数、または関数の引数として用意しておけば良い。もしクラスをどうしても使いたければ、共通のインターフェイスをもたせたほうがマシである。インターフェイスを使えば、クラス利用者が意識すべきpublicメソッドがなんであるか把握できる。
3. カプセル化
オブジェクト指向の中で役立つ概念はカプセル化だけである。しかし、カプセル化はクラスなしで構造化プログラミングの方法で実装できる。pythonでは、モジュールの中でアンダースコアから始まる関数を用意しておけば、それがprotectedやprivateと似たように機能させることができる。オブジェクト指向がなぜカプセル化が独自の概念だと言い始めたかは謎。
4. ポリモーフィズム
同じ名前のメソッドを、入力に応じて処理の内容を変える。このようなことはオブジェクト指向などと誇大宣伝をするほどのことでもない。構造化プログラミングで似たようなことができる。
https://jp.reuters.com/article/column-tetsuya-inoue-idJPKBN2WL053
「中央銀行が政策金利を上げ下げすると、企業や家計の設備投資や消費といったフローの経済活動に直接的な影響を及ぼし、総需要の変化を通じて物価動向に影響を及ぼす、というのが伝統的な金融政策の理解である。」
https://www.zenginkyo.or.jp/fileadmin/res/abstract/affiliate/kintyo/kintyo_2016_1_10.pdf
「理論的には、金融政策は、何らかの名目変数（例えば、マネーや名目金利）を操作変数として、名目総支出ないし名目総需要をコントロールする政策と捉えることができる。」
「中央銀行が通常用いる経済モデルでは、供給ショックで生じたインフレは一過性のものであり（供給が増加すれば解消する）、金利政策の目的は総需要の制御である」
米雇用統計が予想より弱い結果になったことでドル安が進んだが、金利が雇用統計に影響を及ぼすまでに相当な時間がかかるわけでこの結果は相当前の金利の影響と考えられる。
様々な変数かつ複合的な影響があるためいつの金利操作が原因かを特定することは不可能と思われるが、ここで雇用統計が多少下がったところで金利政策に影響することはないのではないか。逆に強ければ急いで利上げをする必要があるので今後の安心材料とは考えにくい。
サービス部門PMI購買担当者景気指数も予想より弱く50.6となったことも裏付けか。ISM非製造業景況指数も51.8と弱い。
全体としては減速したもののマイナスに落ち込むほどではなく絶妙なバランスではないだろうか。少し先行きを見ないと判断しにくい。心配なのは放置すると一気に不景気に陥るのではないかという点。指標が出てからでは遅すぎる。
中立金利r*をどこにFRBが設定しているかは当然明かされなかったがどこかの時点でそこに向かう必要がある。
パウエルは市場との対話を少しばかり重視すぎではと思うところもある。金利操作が表れるまでに時間差があることは十分認識しているはずなのに市場や実体経済へFRBが示すサインとしての金利政策を使っているようにみえるというか。やや危険に思う。
俺は気象予報士試験は一般は通って専門は15問中一問分ボーダーに届かなくて落ちた経験がある人間だが、そんな人間が気象大学校の学生が教材として使ってる気象庁ホームページで公開されてるテキストの理解を試みてみたところ、さっぱり分からないという始末になった。
https://www.jma.go.jp/jma/kishou/know/expert/pdf/textbook_meso_v2.1.pdf
これの14ページ（資料下に印字されてるページ番号としては8ページ） なのだが
dVc/dt=αVsという式が成り立ってて、この式は気圧傾度力が考慮されてるとも書いてあるが、まず一体どういう力の作用の構図を想定してるのかが分からない。
左辺はただの時間変化を微分として表現したもので、右辺もまた中層風と下層風の単なる速度差だから、これが気圧傾度力が考慮されてる式だとしたら、αの一文字が気圧傾度力を表してるって自動的に解釈されるというか、それ以外に解釈の余地が見当たらない。
一方、傾度風や地衡風について立式するとき速度（ベクトル）にコリオリパラメータを掛けそれに気圧傾度力（と遠心力）を足し引きしたような方程式になるわけで、そうなる理由も予報士試験の参考書に力の作用関係の図示付きで書いてあったし理解してるつもりなのだが、だからこそなぜベクトルに「掛けてる」のが気圧傾度力でそれが速度の時間変化に等しくなるのか全くぴんと来ない。
そもそも左辺が速度の微分なのに右辺も速度の定数倍になってるのも理解が追いつかない。なぜ加速度でないのか？
Vc=aVl+bVmについて大気の密度が小さくなると速度が大きくなるのでa+b>1となるとも書いてるが速度が大きくなることからどうその不等式が成立することが導かれるのかもわからない。もっといえばなぜ密度が小さくなると速度が大きくなるのか…ときりがない。
おそらくこちらにとっては天下り式で説明が足りてないように見えるテキストも、気象大学校に入れる学生から見ればあれだけの情報から私が分からないと言った理由も十分読み取れるのだろう。
それはなんというか、少なくとも高校までの履修内容の理解の完成度が全く質的に違うことがこのような差をもたらしてるんだと思う。
たとえば逆に俺でも先に成立する理由が分からないと言った微分方程式が正しいことを前提としてなら、その下に書かれているのがそれを解いた式であることは納得できる。俺でも高校のうちに初歩的な変数分離法は身に付けてるからだが、人によっては同じ理系でも化学系の学部に入る人とかで大学入試を終えた直後の段階で大学レベルの教養数学を学んだ経験が皆無な状態だとただの変数分離で解かれた式にすらぴんと来ないってことはあるかもしれない。
そして気象大学校に入る人たちはこんなのよりもさらに奥深くまで見通しよく高校までの内容を理解してるのだろう。うまいたとえかわからないが、数学の白黄チャートしかやってこなかった人間が赤チャートを見たら同じ単元でも全く別物の内容を学んでいるんじゃないかってぐらいのものに感じるような感じだろうか。気象大学校の入学者も高校段階の知識でもはや私とは全く異なるような理解を持っているのだと思う。彼らから見れば私が分からないと言ってることは変数分離が分からないことが不思議になるぐらい当たり前のことなのだろう。
ただ5chの気象予報士試験対策スレで質問しても、独学で合格したけどここで聞くより予備校で聞いた方がいいぐらいさっぱり分からないと言われた。
気象予報士だって合格したら割と誇れる資格なのにそういう人でもさっぱり分からないって、もう気象大学校の学生は私や予報士とは住む世界が違うような頭の良さを持ってるんだと思う。
そういう人たちでやっと気象災害の対策に責任持てる仕事をする資格が持てるんだなーとある種納得と途方のない挫折感。
地震が起こると毎度同程度の地震が数週間起こる可能性があるとか同じようなこと言ってるなあろか馬鹿のしてる場合じゃなかった。
PowerAppsでSharePoint Listにレコード追加したのち呼び出すPowerAutomateで
「項目を取得」で1行取得できそうだなぁ、と思ったら条件「ID」に変数が指定できず。直で「1」とかは通る。
どうやって使う想定なんだ？と右往右往してたら、
「複数の項目の取得」だったらできる、と。確かにできたが1件しか要らないのにForEach挿む羽目に。
というのが先月だったんだが、今日試したら「ID」に変数が指定できるようになってた！
やったぜさすがMS、ちょっと疲れてただけだったんだね！あ、なんかほかのとこも変数指定しやすくなってる！
とその矢先保存できませんエラーになり一回閉じると
このプログラムは、Pythonのようなインタプリタ型のプログラミング言語を使用しています。提供されたコードは関数と変数の組み合わせで、カウンターの機能を実現しています。以下にその説明を詳しく説明します。
let キーワードを使用して、内部のカウンターを定義しています。カウンターは cnt という名前の変数で初期化され、値は0に設定されています。このカウンターは、外部から直接アクセスできないように、ローカルスコープ内に存在します。
:reset というキーを持つ場合、カウンターの値を0にリセットします。
:incr というキーを持つ場合、カウンターの値を1増やします。
この無名関数が counter 変数に代入されて、カウンターオブジェクトが作成されます。
.reset メソッドが呼び出されると、カウンターの値は0にリセットされます。
このプログラムは、カウンターの値を増加させたりリセットしたりするシンプルなカウンターの実装例です。Pythonなどのプログラミング言語では、関数やクロージャを使用して、このような動作を実現することができます。
エイリアスという言葉は、プログラムやコンピューターの世界でよく使われます。エイリアスは「偽名」や「別名」のようなものです。プログラムでエイリアスを使うと、コンピューターに対してあるものを別の名前で呼ぶことができる。
プログラムの世界では、エイリアスは特にデータや変数に関連して使われます。例えば、数値「10」を変数「x」という名前で使っているとしましょう。その後、別の場所で同じ数値を「y」という別の名前で使いたい場合、エイリアスを使って「y」を「x」と同じものとして扱うことができるのです。
つまり、エイリアスはプログラムの世界で名前を使いやすくするためのテクニックです。これを使うことで、コンピュータープログラムをより理解しやすく、効率的に書くことができます。
20年ぐらいプログラミングやってるっていう40代の人とペアプロしてるんだけど
変数はほとんどがグローバル的な扱いで独自の命名規則で宣言しるし
その命名規則も全然守られてないしスペルミスも多くて読んでてイライラしてくる
根本的な作り方が無茶苦茶でちゃんと動いてるのかバグがあるのかも分からん状態
PR出てくる度に打ち合わせして、そもそものデータ構造とか機能分割について指摘してるんだけど
この前ふと
「そういやJavaで書いたことありますか？Javaだとこんな感じですよね」
って話したらJava知らんと言われた
で、聞いてみたらオブジェクト指向言語で書いたことないし勉強したことも無いとのこと
JavaなりC++なりオブジェクト指向言語で書ける必要は無いけれど
少なくともデータの堅牢性とか再利用性とかの考え方は知っといて欲しい
多変数微積分の問題に没頭していく中で、数学の魅力と深遠さを再び見つけました。
関数と曲線の振る舞いを探求し、微小な変動が全体に及ぼす影響を追求する過程で、数学は私にとってまるで美術館の中の至宝を鑑賞しているかのように感じられました。
数学の問題はその複雑性から挑戦的でありながら、それを解明する喜びと充実感は何よりも素晴らしいものです。
数学は単なる計算や公式の羅列ではなく、知の探求の旅でもあります。
微積分を通じて、数学は宇宙や自然の法則を解き明かす手段であり、知識の宝庫であることを改めて理解しました。
関数と微分方程式の背後にある論理的な構造や、微小な変化が物理現象や経済の動向にどのように影響を及ぼすかという洞察力は、数学の美しい魅力の一部です。
数学の世界は無限大であり、それを探求することは知的好奇心を満たすための果てしない冒険です。
新しい概念を学び、新しい問題に挑むたびに、私の思考能力が高まり、知識の深化が加速します。
数学は私にとって知的な挑戦の場であり、同時にクリエイティブな問題解決のプレイグラウンドでもあります。
最初の数年はWindowsプログラミング、そのうちWebプログラミングにうつり、必要があればミドルウェア等の修正もしていました。
その中で特に印象深いのは、当時存在していなかったDBの接続ライブラリを制作した経験です。
これは私にとって未知の挑戦であり、それを克服することで得られた達成感や、新しい技術の習得が自分の世界を広げてくれる感覚は何物にも代えがたいものでした。
また、自分の会社を立ち上げ、一人でプロジェクトを進めるのもとても楽しかったです。こちらもやったことないことをやるということで、とても良い経験をしたと感じています。
それとは別に、テックリードとして2年、プレイングマネージャーとして半年の経験もありますが、正直マネージメントの世界は自分には合わないと感じました。
そもそも人にお願いすることが苦手であり、自分でやってしまおう、ってなってしまうのです。
基本的に一人で作業するのが好きで、最近の「みんなで開発していきましょう！」みたいなのには辟易しています。
例えば、コードレビューの際にはカッコの位置や変数名など、些細な点での指摘が多く、これには正直疲れてしまっています。
私はコーディングにおいて「完全な正解」は存在しないと信じており、そのため目的の達成（仕様を満たすこと）において多少のバリエーションがあっても良いと考えています。
過去には車でドライブすることを趣味として楽しんでいましたが、最近はその機会も減ってしまいました。
技術的にはWeb系のバックエンドや中規模のインフラ構築が得意分野です。
インフラは本業の詳しい人には敵わないけど、ほどほどの規模なら構築/運用できます。
若い世代の技術者がどんどんと頭角を現し、狭い分野では差を感じることが増えてきました。（その分視野は狭いな、と感じますが）
