  |
はてなキーワード: 関数とは
dbplyrは知らないけど、こういうORMによくある
いい区切りだったので乱文になるけど吐き出させてほしい
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か月後）で退職に伴う書類の送付先の確認で何度か電話をしたが繋がることはなかったという
どうやら彼はこの連絡を会社からの謝罪の連絡だと思っていたのかもしれない
今日は入院している祖母に会いに行く日だ。入院前はもう呆けて風呂も入らないぐらいひどい状態だったが、入院してからはちゃんとしているらしい。
それはそうと、lispでpython環境を構築する話だが、結局オートコンプリートはうざいし、使う機能といったらautopep8とisortぐらいなので、以下を.emacsに組み込んだ。
(defun python-autopep8-and-isort () "Run autopep8 and isort on current Python buffer." (interactive) (when (eq major-mode 'python-mode) (shell-command-on-region (point-min) (point-max) "autopep8 - | isort -" nil t))) (with-eval-after-load 'python (define-key python-mode-map (kbd "C-c C-r") 'python-autopep8-and-isort))
.emacsファイルには他にも様々な設定を付与したが、ここではコードを書ききれない。
さてそういうわけで週末コーディングが趣味としてちゃんと機能することはわかったが、毎週作るとなると、いくつも何かを作るよりは一つのタフなものを作りたいと思うわけである。
それで、最有力候補は「Elasticsearchのようなものをpythonで実装する」という話がある。
Elasticsearchが徹底された設定外部化によってjsonを多用するのだが、これがあまり柔軟性がないので、コードを直にいじれるようにしたいと思ったためである。
例えば自作の日本語トーカナイザを組み込みたいときElasticsearchプラグインをJavaで書かなければならない。私はJavaが嫌いであり、プラグインを「インストールする」という手順も冗長に感じる。
それよりはpythonで作られた検索システムに、適当なトーカナイズ関数を実装して呼び出すことができればかなり柔軟であるように思うわけである。
難しい点があるとすれば、大規模分散システムへの対応で、金をかけなければそういうシステムをテストすることができない。
できるだけ金をかけずに趣味をやるというのがモットーなので、これではまずいわけである。
まあ何事も困難というものはある。まずは手を動かすことが重要だ。Linus Torvaldsも"Talk is cheap, show me the code"と言っているではないか。
4連休が始まり、専ら散歩とインドカレーを楽しんでいる。「インドカレーのスパイスで頭がおかしくなるのではないか」と思ったことはあったが杞憂だった。
家で過ごすときは、自分の気力のレベルでも作れる程度の簡単なプログラムを書いている。今日作ったのはポモドーロタイマーとTODOリスト管理ツールだ。
何かを作るとしても、自分が使えるようなものでないとやる気が出ないので、便利ツールとして作っている。
作ったものを自分自身で使って試すのは「ドッグフーディング」と呼ぶらしい。ドッグフードが犬にとって健康的で安全であることを示すには実際に食って確かめろ、というわけだ。
次に作ろうと思うのはブログ記事推薦ツールである。廃人日記を読み込み、ふさわしい記事をピックアップするツールである。
1. ブログ記事を収集しその集合をS1とする。廃人日記を収集しそれをS2とする。
2. S1, S2をベクトル化する。S2は時間減衰関数で重み付けして線型結合し、これをTというベクトルとして保存する。
3. Tのベクトルに最も類似するベクトルを数件S1から取得する。
仕事とは違い、趣味のコーディングはルンルン気分だ。期限もなければ収益もない。自分がほしいかどうかだけがモチベーションである。
もう令和だから、Excel関数や誰もメンテ出来ないマクロでドヤるのやめてほしい
あと、Azure認証とTeams がデファクトスタンダードで、
Teamsに関してはEUの独禁法違反懸念対策で別売りするねってやってるターンなので、
AzureやM365Apps(MS Office)使ってないアピールするのもやめて欲しい
つか、広告業・メーカー・製造業だと専門職でもバリバリExcelとか使うやで
独自のマクロライブラリまであったりするし、なぜかExcelをOracleやBIツールに取り込んで〜みたいなこともしたりする
(そんな運用にするなよ・・・とは思うが、その運用を変えられる自信あるなら、該当企業に乗り込んで変えてみてどうぞ)
大学、ましてや名前がある程度知られている大学を卒業をしておいて、高卒でも問題ない会社に入社したり、高卒でも問題ないポジションにいるヤツは、すべてポンコツと見做して良い
でも、自分自身の能力で余力のある場所にいるから強いだけで、そうじゃないところへ行ったら自分がポンコツ側の人間になると思うので、他人には優しくね？
そういう気分にはなれねぇなぁ・・・なら、とりあえず金稼ぐと良い、死ぬほどどうでも良くなる
当方、高卒（出席と成績足りなくて春休み全日補習で卒業）でエクセルとアクセスを独学で勉強して
中小で事務員兼社内IT雑務担当くらいのポジションでやってるんだけど。
普通に名前聞く大学出てる2，3年目の子でもxlsxとxlsmとcsvの違いわかってなかったりして驚く
SUM以外の関数全く分かりません、数式のトレースも無理です、解像度よくわかりません、メールの設定できません、スクリーショット撮れませんとかざらにいるレベルで大学ってそんな感じでも卒業できるんだなぁってなってる。
「ソースコードに間違いが見つからないのに想定される出力をしない。あるいはソースコードに修正を加えていないのにいきなり想定出力を返すようになった。」
こういう経験がある人はいるはずだ。なぜこれが起こるのか。一つの原因を見つけた。
それは環境変数や設定ファイルに存在する。デプロイ時には設定ファイルを特定の値に修正してから、ということがあるだろう。
開発環境でコーディングする人が、デプロイ時の設定ファイルには関与せず、デプロイの担当者がそれを把握している。
開発者はセキュリティ上の理由でデプロイ時の設定ファイルの内容を見ることができない。
この場合、設定ファイルの内容が間違っていても、開発者が原因が正しく特定できないケースがあるのである。
対処方法は以下である。まず事前にやっているであろう対処は以下である。
追記:
他に遭遇したケースは、環境のアップグレードによってphpが特定の関数を廃止したというケースだ。
プロットライブラリ、データフレームライブラリ、データベース、などが集計関数を用意している。
例えばある場所ではプロットライブラリの集計を使っているが、別の場所ではデータベースで集計してからプロットするということがあるだろう。
各ライブラリが内部でどういう処理をしているかがブラックボックスであるため、これは問題である。
ライブラリの集計関数を使う場合、テスト用のデータを用意しておき、集計値が一致するかを確認するのがまず必要。
次に集計方法はバラバラでなく揃える必要がある。プロットライブラリに集計させるより、データフレームに集計させてそれをプロットしたほうが良い。
またデータフレームにおいても、groupbyとpivot_tableで集計の扱いに差があったりする。
これらの差が生じる一つの理由はNullやdatetimeに対する処理の違いだったりする。
暗黙の集計に対応するのは大変なので、テストデータに対する集計が正しいバリエーションを選び、その方法で全部揃えたほうが良い。
女の人生をイージーだなんて言うから、男の辛さを分かって貰いにくくなるんだよな。
性欲をぶつけられるという入力に対し、出力は快感なのか、恐怖なのか。
自分の生きづらさを理解してもらうための第一歩は、「異性」等々別の立場を生きる人間の生きづらさを理解し、共感することだよ。
やり込めば分かるけど、元素反応システムはめちゃくちゃ奥が深いから
安易に1人2元素をやったりパーティが扱える元素を5以上にすると考えることが指数関数的に増えてしまう
現状では伝説任務のような5人目が借りられるクエストでしか5元素を能動的に扱えない
まあよく考えなくてもフィーリングで戦えてしまう良い塩梅に調整されてはいるけど
行動によって異なる元素付着量や付着頻度、反応による減衰、時間による減衰を考慮して最適な反応を起こせるローテーションを考えるようになると
増田のような文句をつけるプレイヤーはほぼいなくなると言っていい
マルチプレイは仕方ないとはいえ、ソロプレイでつねに共闘状態を作ってしまうと、この「元素反応をコントロールする」という楽しみがぶち壊されてしまう
雑に反応をボンボン起こせるかもしれないが大味なゲームになってしまうし、キャラによっては反応を妨害され、切替型のソロなら毎回蒸発できる動きが機能せずDPSが落ちたりもする
それにキャラ切替型だからこそ、設置スキルや裏から連動攻撃できるキャラがいたりと、それに合わせた性能設計になっている
頻繁なキャラ切替を前提とする戦闘だっていうのは、初心者やアクション下手な人はずっと同じキャラで戦いがちで切替が億劫だと感じるかもしれないが
切替操作にさえ慣れてしまえばいかに効果的で面白いか気づけるようになるし、キャラを収集・理解・育成する楽しみを与えてくれるから
ある程度慣れてきたらあんまり決まり切ったキャラばかり使わず、色々使ってみるとこれを「ゲーム」として楽しめるだろう
そのため、新参はガチャゲーのノリで星5の強キャラと言われる1人ばかり凸や武器を充実させて戦力を強化しようとするが
よほど急ぐのでない限り、基本的にはいろんなキャラを確保すること優先の石配分でじっくり遊んでいったほうが「おいしい」内容となっている
もちろん序盤の序盤にメインで使うと決めた4人は集中的に育ててあげたほうがいいが
MMORPGのパーティビルドと同じように、1人が担えるロールは限られていて、組み合わせが重要だということを理解してもらうことで
キャラ収集へと目を向かせ、キャラを集めていくことで取れる幅広い戦略に魅力を感じてもらうという、マネタイズ上の理由もあるとも言えるな
まあ買い切りゲーだとしても1人でなんでも出来る万能キャラなんていうのはよっぽど終盤にならないと出てこない贅沢要素だと思うが
というか増田が抱いている違和感の大部分は、オンラインゲームに慣れていないことに由来すると思う
今後数年間で、eVTOL（電動垂直離着陸機）が「高度な空中移動」のモードとなり、500 億米ドルのヘリコプター産業を混乱させる可能性があります。それはすべて、NASA の研究者である Mark D. Moore によって 2009 ―2010 年の間に始まりました。 彼は、個人/ワンマン航空車両の概念を導入しました。 その後、2014 年に電動垂直離着陸 (eVTOL) が AIAA (アメリカ航空宇宙学会) によって導入されました。
eVTOLがエアモビリティの未来をどのように変えるかを理解しまします。
資金調達と投資は指数関数的に増加しており、最初の商用 eVTOL サービスを開始するためのコンテストが行われています。 2030 年までに空を飛ぶ「空飛ぶ車」を目の当たりにする大きな期待が寄せられています。今日の車の認識と同じように、eVTOL は社会全体の標準的な移動手段になります。
大手企業は、世界最大の航空会社と比較して、より大きな機材、より短いフライト、および 1 日あたりのより頻繁なフライトを提供することを計画しています。 フライトの長さは約17〜18分で、乗客は少なくなります
以下のリンクからすべての情報を見るには、ここをクリックしてください：https://www.sdki.jp/blog/evtol-aircraft-market-demand-for-helicopters/9
https://anond.hatelabo.jp/20240415070458
約10年前、Evernoteが多くの推薦を受けていたことを覚えています。安価なサービスがユーザーを引きつけた後に突然終了するのは、残念ながら一般的な現象です。マイクロソフトのOneNoteのようなメモアプリの必要性については、個々のニーズによって異なります。GitHubはコードやプロジェクト管理には優れていますが、日常的なメモやドキュメントの整理には最適ではないかもしれません。Vercelとの連携による認証付きホスティングの無料提供は魅力的です。Googleサイトも文書やメモの保管には有効な選択肢です。マークダウンの使用や、テキスト以外の内容をJPGなどの画像フォーマットで保存する方法は、特定のアプリケーションに依存しないため賢明な選択です。マイクロソフトオフィスの使用を避けたい理由は理解できますが、Excelの関数のような便利な機能もあります。そして、テヘランがイランの首都であることは興味深い事実です。確かに、マイクロソフトがサービスを突然終了することは稀ではありませんが、それは業界全体の問題でもあります。
目指す目的地はどこにあるの？
意味を探し求める旅の途中
デバッグの道を進んでいく
真実の値を見つけ出したい
再帰的に答えを探し求める
たどり着く先はまだ見えない
プログラミングの旅は続いてゆく
（質問文：「あとNaNマイルでundefined会員」から始まる詞を考えてください。
回答：CLAUDE 3 OPUS）
去年から稼働している現場で、以前からあったReact Nativeの面倒を見ているんだがまあこれがひどい出来なんだ。
jQuery時代に見かけたようなコードをやたら見かけたので思わず懐かしくなってしまった。
リファクタリングしようとしたけど直す範囲が広すぎてアプリを壊しかねなかったので、早々に諦めてだましだまし保守をしていた。
そんな中今年に入ってアプリのリニューアルの話が出てきた。React Native捨ててSwift/KotlinやらFlutterに書き換えるとかそういうのではなく、デザインの刷新といくつかの機能改修。
このままだとアプリが更に魔窟化するので、マネージャーに色々相談したところいくつかの事実がわかった。
ということだった。
結局現状のまま進めるわけにはいかず、要件定義の傍らリファクタリング作業をしている。
そういう経緯もあったので、リファクタリングとテストの工数も積んだ上で見積もりだしてもらってる。
「レガシーアーキテクチャをモダンアーキテクチャに刷新」なんてよく聞く話しだけど、
実態は「長年の増改築とだましだましのリフォームが限界になってきたので新築で建て替えます」何だと思う。
最近は「Vue.jsからRemixにマイグレーション」なんて見かけるけど、悪いのはVue.jsじゃなくて禄に設計しないでコード書いてるエンジニアと、
リファクタリングには予算でないけどマイグレーションなら予算取れるという悪しき風習。
年がら年中フロントエンド刷新しているような会社は地雷なので行かないほうがいい。
いくらRemixやらNext.jsやら最新鋭のフレームワーク使ってても、クソコードで書いたらクソが出来上がるだけだ。
AIで何でもできることが、かえって人間の発想の貧困さを暴いてしまう。
AIの活用事例がメール文章作成、資料作成、自社商品やサービスの紹介文作成、企画の壁打ち、表計算ソフトの関数の作成・・・
これだけか？
何でもできるんだぞ？
それでいいのか？
そんなんじゃ、
発想の貧困だけはどうにもならない。
幼い頃から、小説をいつか書きたいと強く願っていて、文章読本や小説講座的な本などを多数読み込んできたけれど、それらが小説に変わることはなかった。
好みの文体やストーリーパターンはわかってきたのだけれど、それらを何らかの社会、何らかの人間関係に落とし込んで書くことができなかったからだ。
つまり、社会の仕組みやわだかまりをどう描いていいかわからなかった、会話や気持ちの移り変わりをどう描いていいかわからなかったのだ。
文章読本などで、文章というガワの部分を学んだとしても、そこに盛り込むものがわからなかった。
ストーリーとして導きたい方向に、社会や人間関係を配置する方法がわからなかったのだ。
増田ではわりと、ブックマークをいただけたりする自分ではあるが、書く文章は常に一人称で、自分の思ったことをエッセイ的にまとめることしかできない。
これを、背景装置としての社会や人間と絡めて、ストーリーとしての段階を踏んで、人々を驚かせる素晴らしい結末につなげる小説として昇華させることができない。
それなりの人気を持つ雑文に仕上げるためのアイデアはたくさんあるのだ。それを、小説として具象化できないだけ。
いや、なんだろう、プログラム的に組み立てることができないといった気分。
そもそもが理系なので、プログラムもそれなりに組んだことがあるのだが、小説としての文章の組み方がわからない。
結末に向かう伏線を社会のどの部分に絡めて描写し、物語の展開をどのキャラクターの変容に仮託するか、みたいなものがよくわからない。
文体やレトリックのような基本文法はわかるのだが、社会や人間を相手にした「組み込み関数」みたいなものが何なのかが見えず、途方にくれてしまう感じだ。
というか、そもそもだが、こんなにダラダラ文章を書く私ではあるのだが、小説は一行たりとも書けたことがない。
だって、結論に至るアイデアが思いつけても、そこに向かう「これは書けるぞ！」というビジョンが見えないので。
この小説ならプログラム的に書けそう、ああなってこうなって結論に至りそう、みたいなものが、私の場合、小説に対して浮かんでこない。
そうそう、プログラムでもそうなんだが、もっと言うなら、数学の入試問題のように、とりあえず三角比を求めるとかベクトル計算するとか、
この「とりあえず○○を書いてみる。そのうち、ストーリーがつながってくる」みたいなのを知りたい。
とりあえず手を動かして、作り出す小説を何らかの方向に進める方法を、まずは身につけていけたらいい。
この文章だって思ったことをズラズラ書いているだけなのだ。ビジョンで書いてない。
って、あっ、それが小説を書く前のキャラクターシート、世界観作成シートみたいなものなのか。
あれも苦手なんだよな。好ましい感情を抱けるキャラクターを造形できないというか。
いや、自分以外のキャラクターが描けない。世界観も、今自分が感じるもの以外組み立てられないし。
結局のところ、私は自分のことしか書けない。自分のことならそれなりに書いて、それなりに注目される文章が書ける。
自分の考え方を、ある社会やある人間関係に落とし込んで、世の中にその素晴らしさを理解してほしいんだ。
「私の気持ち」じゃ他人に届かないんだ。客観性というか、作者でない「キャラクターの気持ち」として描写しないと、私ではない誰かに届くことは無いんだ。
だから、ここに書くような、一人称の雑文じゃダメなんだ。物語に仮託しなくちゃダメなんだ。
そういった点では、私は「物語」というものに、論文のようなものを感じているのかもしれない。
つまり、物語の人間関係や世界観という客観性のもとに、自分のアイデアに向かって組み立てた文章を、誰かに対して発露し、評価を得たいのだ。
いや、誰かに届けばいい。個人的なアイデアなり感情なりが、誰かに届けば、無意識的にでも届けば、それで十分なんだと思う。
…などと長々と書いてきて、結局は今回の文章も小説にはなりえなかったわけだけど、まあなんだか、そんな気持ちなのだ。
薄い鬱気分で休んでしまった気晴らしにしては、またも長々と書いてしまった。
最近、Youtubeでいろんな分野の技術的な解説を見るのが好きなんですけど、その中にロケット方程式の説明があったんですよ。
ツィオルコフスキーの公式ともいわれているもので、ざっくり言ってロケットの最終的な速度はその燃料にたいして、logでしか増えないっていう方程式です。
logってことは、1:1の直線よりも寝た曲線な訳で、燃料を倍に増やしても速度が倍になるわけではなく、１．何倍かにしか増えないということです。
なんでそうなるかというと、燃料自体にも重さがあるので、燃料を２単位積んだ時には、
最初の燃焼時には燃料２単位を積んだロケットを持ち上げないといけないので、燃料１単位のときよりも、効率が悪くなるということだと理解した。
んで、同じようなことは、EVの航続距離にも言えるんじゃなかろうかという考えが浮かんだ。
つまり、バッテリー２０ｋWhで１００ｋｍ走れるなら、バッテリー１００ｋＷｈで５００ｋｍ走れるわけではなくて、せいぜい３００ｋｍ４００ｋｍくらいにしかならない。
ロケットでは、燃料は使うたびに燃えてロケットの外に放出されるのでどんどん軽くなるから、まだｌｏｇの関係、つまり、効率は悪くなっても、
燃料を積めば積むだけ速度は上りはするというのに対して、
ＥＶのバッテリーは、使用しても軽くなる訳ではない、空のバッテリーでも重さは変わらない。
ということは、バッテリー容量を増やしまくっても、航続距離が伸びない、logでさえない、最大値が存在するような関数になるんじゃなかろうかと。
そうなると、乗用車はまだいいとしても、長距離トラックなんかにはちょっと向いてない、水素じゃないととか言われているのを聞いたことがある気がするけど、
たぶんこういうあたりが原因なんじゃないだろうか。
