はてなキーワード: OpenGLとは
最近、YouTubeでナムコの社員だった人の技術動画見たりして、スゲーなぁ、でも、やっぱり制約大変だよなぁ、と思い出したりしてたんだけど、
過去のゲーム機とかパソコンでの開発、面白そうだけど、今の自分に精神的に余裕がなかったり、ゲーム機って温故知新というより時代背景と制約の歴史だよね
自分は雑魚レベルだったし、こんなに制約あるんだったらパソコンでOpenGLやDirect3D使ってた方が精神的にもいいや、って思って逃げちゃった人だからなぁ…
最近というか、ときどきというか、自分と同世代が偉業を成し遂げたりしているのを眺めては、スゲーなぁ、としか思えないし、
自分も新聞にちょっと写真付きで記事が出たことが一度だけあったけど、そんな大した話ではないし、運が良かっただけだし、
スゲー人にはなれなかったけど、ダメ人間なりになにか総括したいよなぁ…😟
フリーランスでゲームエンジン担当したり調整したりの仕事を今でもやってます。
「ITがつまらなくなった」「ゲーム制作がつまらなくなった」のは違う角度の話も入りますが同意です。
おそらく現在40歳あたり以降の人たちは「めちゃくちゃコード書けた時代」の人たちだったと思います。
私もめちゃくちゃコード書いてましたし、他人のコードも修正してたし(それでキレられたり1日中討論したりも)、何より車輪の再発明がすごく楽しかった。
Game Programming Gemsが唯一の経験者のナレッジの詰め合わせで、貪るように読んでましたね。懐かしい。
というよりそうでないと生き残れなかった。
何よりもコードを書くのが楽しい、起きてる間は全てコーディング、アーキテクト、新技術の調査に時間を充てるような生き方しか出来ない人たち。
生産性?それよりもテンプレートプログラミング面白くね?意味あるか分からんけど。そういやこのコンパイラいいよね、メモリの使い方上手くてさあ。
プログラミング全般の技術力は、正しい知識を身に着けているかも重要なんですが、それよりも重要なのはライブラリの仕様を覚えるくらい何度も何度もアウトプットすることなんですよね。
DirectXやOpenGLの仕様を追えばだいたい効率的な計算方法や描画手法は身についちゃうので。
技術体系に紐づくものだったり、デザパタとかある程度知っておくものもあるにはありますが、何なら自分で見つけたくらいの方が遥かに理解度が高い。
頭で創るより、実際に書いてコンパイラ通して目で確認するほうが何倍も重要。
3Dゲームの知見がまだまだ日本に足りていない時代、ドラマチックな演出を行おうとしたら別の技術が必要になった。
今の時代では、ただFPS/TPSにすりゃええって回答になっていますが、模範解答として映画しかモデルが無かったんですよね。
しかも日本の画作りは時間を使った画作りより、止め画、見栄を軸とした画が多くて、海外のセンスとはジャンルが違う。
最先端の技術を生業にしていた大手ゲームパブリッシャー、デベロッパーは頭を抱えていました。
なにせ、個人の技術で戦ってきてしまっていた日本では太刀打ちできないことがわかったからです。
すでに海外では映画や映像の最先端の技術者やクリエイターをかき集め、サイエンスとしてナレッジ化を進めていました。
物理学者を集めまくってたのもそのときだったのを覚えています。
結果的に、大手は各社最高のグラフィックエンジンやクロスコンパイルエンジンを自社開発しようとして、(ほぼ)全て断念していますね。
……ただフォローのつもりで言いたいのですが、失敗ではあったと思いますが、そこで得た技術は非常に重要なものでして
日本は失敗を許容しない組織が多く、初めるのが遅く、辞めるのも遅い、それでいて二度と挑戦させない文化なので育つ土壌が無いんだと思います。
だいたい誰かが俺仕様で作ったクソみたいなコードを修正して、高速化したりメモリリーク改善したりがメインです。
「またコレか…」のパターン多すぎる。これがつまらなくなった所以です。
GCの仕様くらい考えたらなんでスパイクが起こるかわかるやろ……なんで調べんのなんて思うこともあります。
ただ出来ない人が多い、才能の無い人がビジネスだけでゲーム作ってる時代でもあるので、そのおかげでおまんま食べられてるんだよなって考えてます。
プロジェクトが破綻してることも多くて、その大部分はエンジニアがクソすぎるってのが多いですね。
体制の問題もあるにはあるんですが、ゲームにこだわることもなく、ただ稼げるで来ちゃった人たち。
だからそんな人達に何か伝えても響くことも無いし、生き方も違うので何も言わない。
ゲーム自体もどこかで見た何か。なので正解が存在するのでアーキテクトや制作に頭をひねる必要も無い。
感謝されるのでやりがいはあるんですが、当時激論を交わしていたような人たちはゲーム業界から離れ超ホワイトな外資系や大手でぬくぬくやってます。
幸いなことにソーシャルゲームバブルが起こり、その波に乗れた人たちです。
たまたま私の周りはコミュニケーション能力や問題解決能力、分解能力が高かったのでちゃんと地位を築き、ちゃんと生活しています。
Device Info は、高度なユーザー インターフェースとウィジェットを使用してモバイルデバイスに関する完全な情報を提供するシンプルで強力な Android アプリケーションです。たとえば、デバイス情報/ 電話情報には、CPU、RAM、OS、センサ、ストレージ、バッテリー、SIM、Bluetooth、ネットワーク、インストール済みアプリ、システム アプリ、ディスプレイ、カメラ、温度などに関する情報が含まれます。また、デバイス情報/ 電話情報は、ハードウェア テストでデバイスのベンチマークを行うことができます。
中身 : 👇 👇
👉 ダッシュボード : RAM、内部ストレージ、外部ストレージ、バッテリー、CPU、利用可能なセンサ、インストール済みアプリ & 最適化
👉 デバイス : デバイス名、モデル、メーカー、デバイス、ボード、ハードウェア、ブランド、IMEI、ハードウェア シリアル、SIM シリアル、SIM サブスクライバー、ネットワークオペレータ、ネットワークタイプ、WiFi Mac アドレス、ビルドフィンガープリント & USB ホスト
👉 システム : バージョン、コード名、API レベル、リリース バージョン、1 つの UI バージョン、セキュリティ パッチ レベル、ブートローダー、ビルド番号、ベースバンド、Java VM、カーネル、言語、ルート管理アプリ、Google Play サービスバージョン、Vulkan のサポート、Treble、シームレスな更新、OpenGL ES およびシステム稼働時間
👉 CPU : Soc - システム オン チップ、プロセッサ、CPU アーキテクチャ、サポート対象の ABI、CPU ハードウェア、CPU ガバナー、コア数、CPU 周波数、実行中のコア、GPU レンダラー、GPU ベンダー & GPU バージョン
👉 バッテリー : ヘルス、レベル、ステータス、電源、テクノロジー、温度、電圧と容量
👉 ネットワーク : IP アドレス、ゲートウェイ、サブネット マスク、DNS、リース期間、インターフェイス、周波数、リンク速度
👉 ネットワーク : IP アドレス、ゲートウェイ、サブネット マスク、DNS、リース期間、インターフェイス、周波数、リンク速度
👉 ディスプレイ : 解像度、密度、フォント スケール、物理サイズ、サポートされているリフレッシュレート、HDR、HDR 機能、明るさのレベルとモード、画面のタイムアウト、向き
👉 メモリ : RAM、RAM タイプ、RAM 周波数、ROM、内部ストレージ、外部ストレージ
👉 センサー : センサー名、センサベンダー、ライブセンサ値、タイプ、電力、ウェイクアップセンサ、ダイナミックセンサ、最大距離
👉 アプリ : ユーザーアプリ、インストール済みアプリ、アプリバージョン、最小 OS、ターゲット OS、インストール日、更新日、アクセス許可、アクティビティ、サービス、プロバイダ、レシーバー、抽出アプリ Apk
👉 アプリアナライザー : 高度なグラフを使用して、すべてのアプリケーションを分析します。また、ターゲット SDK、最小 SDK、インストール場所、プラットフォーム、インストーラ、および署名によってグループ化することもできます。
ディスプレイ、マルチタッチ、懐中電灯、ラウドスピーカー、イヤースピーカー、マイク、耳近接、光センサ、加速度計、振動、Bluetooth、WI-Fi、指紋、音量アップボタン、音量ダウンボタンをテストできます。
👉 温度 : システムによって指定されたすべての温度ゾーンの値
👉 カスタマイズ可能なウィジェット : 最も重要な情報を表示する 3 つのサイズの完全にカスタマイズ可能なウィジェット
👉 レポートのエクスポート : カスタマイズ可能なレポートのエクスポート、テキストレポートのエクスポート、PDF レポートのエクスポート
権限 👇 👇
READ_PHONE_STATE - ネットワーク情報を取得するには
BLUETOOTH_CONNECT - Bluetooth テスト
なんか昨日から色々悩みまくってググりまくって、どうもVisual Studioのバグみたい、
というところまでGitHubのissuesとか読んで、たどり着いたけど、なんか精神的にもつらい…
そういえば、だいぶ昔にAccessの開発中にバグを見つけたこともあったなぁ…
あれは自分で試行錯誤して回避できたけど、昨今のMicrosoftのデスクトップ開発はわけわからん…
WPFだのUWPだの、これからReunionだのWinUI 3だの、.Net Frameworkのバージョンも乱立し、
.Net coreだのstandardだの、なんか面倒になってElectronだの、
もうゲームのフレームワークでOpenGLなりDirectXなりでGUIも自分で書いた方が早いんでなの?
みたいになったり、なんだかんだでWindowsのストアが盛り上がらないの分かる気がする、
というか、Windows Phoneが失敗した痛手をまだ引き摺ってる気もする
HTMLだけ書ければWebは最低限GUIができてしまうわけだけど、
どうしてこんなにネイティブWindowsだと、.NET時代になっても魔窟になるんだろうな
MVVMフレームワークも乱立してるし、
でも、それでできたアプリがElectronと変わらないような感じだったりして落胆するんだけど、
こういうオープンソースとか詳しい人ってどんなスマホやパソコン使ってんだろ?
気になるし資金的余裕があれば真似したい
とのことなので暇だし書いてみる
OS | Arch Linux |
CPU | Ryzen 9 5900X |
ワーキングメモリ | 32GB DDR4 SDRAM |
ストレージ(システム) | 1TB NVMe SSD |
ストレージ(データ1) | 6TB SATA HDD(RAID0+1) |
ストレージ(データ2) | 6TB SATA HDD(RAID0+1) |
ストレージ(データ3) | 6TB SATA HDD(RAID0+1) |
ストレージ(データ4) | 6TB SATA HDD(RAID0+1) |
GPU | Radeon RX 6900 XT 16GB |
ディスプレイモニタ(プライマリ) | LG 35WN75C-B |
ディスプレイモニタ(セカンダリ) | 中華ノーブランド14インチ16:9タッチスクリーンディスプレイ |
キーボード | Lily58 Pro(黒軸) |
トラックボール | Expert Mouse K72359JP |
AMDな理由はOpenGLを重視したから
データには主に子供の写真や動画が一杯入ってるので速度と冗長性を取ってHDDを無駄使いしてる
タッチスクリーンディスプレイはタッチスクリーン使うアプリ開発用でAliExpressから拾ってきたガワがない詳細不明品、3Dプリンタで作ったガワで無理矢理マウントアームに付けてる
OS | Chrome OS |
CPU | Core i7-10510U |
ワーキングメモリ | 16GB DDR4 SDRAM |
ストレージ(システム+データ) | 512GB NVMe SSD |
ディスプレイモニタ | 14インチFullHD |
ノートパソコンではメインとなってるChromebook
実質的にAndroid Appsが動くLinuxディストリビューションなので非常に便利
Chrome OSの有用さを友人へ伝えるたび鼻で笑われていたが、コロナ禍でまさかの注目株に
Chrome OSを使ってる理由が、UNIX使いたい人が安定しているUNIXとしてmacOSを選ぶみたいなノリで、安定しているLinuxディストリビューションとしてChrome OSを使っていると理解してもらえれば良い
ちょっと突っ込んだ使い方しようとすると途端に意味不明な挙動をするところまでmacOSと同じである
OS | Chrome OS |
CPU | Core i3-10110Y |
ワーキングメモリ | 8GB DDR4 SDRAM |
ストレージ(システム+データ) | 512GB NVMe SSD |
ディスプレイモニタ | 7インチFullHD+ |
Windows 10からChrome OSへ置き換えた我が家では実質的にタブレットとして運用されているノートパソコン
ほぼ子供の玩具で一緒にゲームしたりYoutubeみたり電子書籍を読むのに使われている
Chrome OSへ置き換えたのでAndroid Appsも動く
OS | Android 10 |
CPU | Tegra X1+ |
ワーキングメモリ | 3GB DDR4 SDRAM |
ストレージ1(システム+データ) | 16GB NVMe SSD |
ストレージ2(システム+データ) | 1TB SATA HDD |
日本ではほとんど注目されないスマートセットトップボックス
リビングのTVでYoutubeやNetflixを観るのにこれ以上の選択肢はないのだが一般家庭にはあまり普及してないようだ
ちなみにゲームをプレイできたりNASへ接続できたりもする
OS | Android 10 |
CPU | Snapdragon 835 |
ワーキングメモリ | 6GB |
ストレージ1(システム+データ) | 128GB |
ディスプレイモニタ | 5.99インチFHD+ |
カメラ(フロント) | 8MP |
カメラ(リア) | 16MP |
バッテリー | 3,200mAh Li-ion |
防水 | IPX67 |
生体認証 | 指紋・顔 |
IC | NFC A/B |
充電 | USB-C・ワイヤレス |
重量 | 243g |
メインで使ってるスマートフォン
ハードウェアQWERTYキーボードを搭載していてTermuxでsshするときに役立つ
スライド機構を搭載しておりQWERTYキーボードをシャコンとスライドさせて出せ、普段は普通のスマートフォンのように使える
OS | Android 10 |
CPU | MediaTek Helio P60 |
ワーキングメモリ | 6GB |
ストレージ1(システム+データ) | 128GB |
ディスプレイモニタ | 4.6インチHD+ |
カメラ(フロント) | 8MP |
カメラ(リア) | 16MP |
バッテリー | 6,000mAh Li-ion |
防水 | IPX67 |
生体認証 | 指紋・顔 |
IC | NFC A/B |
充電 | USB-C・ワイヤレス |
重量 | 303g |
サブで使ってるスマートフォン
ガジェット界隈では有名な鈍器で、iPad mini 2019が約300gだったことを考えれば鈍器と呼ばれる所以がわかる
バカバカしいスマホに思えるけど本来はタフネススマホなので頑丈さに特化したからこその重さ
バッテリーが大容量なためモバイル無線LANルーター代わりで持ち歩いている
小型版のUnihertz Titan Pocketが予定されているけれどもちろん買う
OS | SailfishOS |
CPU | Snapdragon 690 |
ワーキングメモリ | 6GB |
ストレージ1(システム+データ) | 128GB |
ディスプレイモニタ | 6インチFHD+ |
カメラ(フロント) | 8MP |
カメラ(リア1) | 12MP |
カメラ(リア2) | 8MP |
カメラ(リア3) | 8MP |
バッテリー | 4,500mAh Li-ion |
防水 | IPX67 |
生体認証 | 指紋・顔 |
IC | NFC A/B |
充電 | USB-C |
重量 | 169g |
お遊び、検証・研究用のスマートフォン
最近のスマホは一般的に普及しているものと異なるアスペクト比を採用していることが増えてきてるのでTitanと合わせてアスペクト比確認用としても使う(アスペクト比が異なってても正しくレンダリングさせるの今後マジで必須だよ。アスペクト比の決め打ちイクナイ)
現在は一部界隈で注目されていたSailfishOSがインストールされているが、ぶっちゃけオープンソースコミュニティ関連で人と会うときに見せるためだけに用意している
OS | Wear OS |
CPU | Snapdragon Wear 3100 |
ワーキングメモリ | 1GB |
ストレージ(システム+データ) | 8GB |
ディスプレイモニタ | 1.28インチ |
バッテリー | 310mAh Li-ion(1Day+) |
防水 | IPX67(3気圧) |
IC | NFC A/B |
充電 | 独自 |
重量 | 約50g(モデルにより異なる) |
AndroidベースのWear OSを搭載したApple Watch対抗のスマートウォッチ
美点はスタイリングデザインの豊富さと微妙にApple Watchよりもバッテリーの保ちが良いこと(使い方によって逆転できるレベルの違い、誤差レベルと言って良い)
AndroidやChrome OSとの連携はさすがで、スマホを取り出さなくても使えるGoogle Assistantはスマート電球やスマートSTBの操作に便利
ただやはりApple Watchも抱えている問題でフル機能を活用するとバッテリの保ちが1日+数時間というのは時計としてどうなんだろう
スマートウォッチが好きじゃないと毎日充電する気にはならないとは思う
OS | 独自ファームウェア |
CPU | Dialog DA14697 SoC |
ワーキングメモリ | 512KB |
ストレージ(システム+データ) | 16MB |
ディスプレイモニタ | 1.1インチ |
バッテリー | 125mAh Li-ion(14Day+) |
防水 | IPX67(3気圧) |
IC | NFC A/B |
充電 | 独自 |
重量 | 約12g |
スマートウォッチの大本命
安価でありながらスマートウォッチに求められることの大半が可能
大半の人にはMi Smart Band 5で十分、Apple WatchやWear OSスマートウォッチは必要ないこと間違いなし
そろそろ新型のMi Smart Band 6が大陸以外でもリリースされる予定なので楽しみだ
万が一、億が一、Mi Smart Bandに機能不足を感じたらApple WatchやWear OSスマートウォッチを検討しよう
Apple WatchやWear OSスマートウォッチは自分のようなマニアがポチポチして遊ぶような代物であって全くもってマニア以外にはオススメしない
ちなみに自分はマニアなので左手首にTHE CARLYLE HR SMARTWATCH、右手首にMi Smart Band 5だ
自分は商用UNIXっぽいから20年近く使ってきたけどM1から完全に買う気力が失せた
その商用UNIXっぽさで国立大学とか公的な研究所でMacは導入されてきた経緯があるけど、
それはXQuartzとか前提にしている話であって、もうUbuntuもWaylandがデフォルトになる時代になってきたし、
Macはハードで強制的に対応できるOSを切り捨てるので、自分が所有するMacもOSを上げられなくなったし、
といっても、財産というか色々あるので、homebrewも対応が切れていちいちソースからビルドしろと言われるようになったけど、
まだWebとかグラフィック関係ないならコードも書けるし、テキスト周りはまだ使うけど、
でも、このへんでMacはやめてUbuntuかなあ、と思って、こうやってUbuntu使って書いてるわけだけど
Metalとかも面白そうではあるけど、もういいかなあという気がする
VAIOの偉い人が言ってたみたいに、AppleのM1みたいな試みは非常に面白いし歓迎するけど、
快適なユーザーエクスペリエンスはたった1つのチップから生み出されるわけではないので、
CPUが速いだの遅いだのも大事だけど、総合的なハードウェアの構成が快適環境に繋がるというのは同意なんだよね
そういえば、MacはOpenGLも対応しなくなったし、OpenGLの規格がクソみたいなのは理解できるけど、
MacのためにMetalに対応するより、動的にVulkanを無理矢理動かすような方法に落ち着く気もするし、
自分は不勉強なのでよく知らんのだけど、参考にしてるソースの中の1つの作者がWayland対応はやめてたなあ…
男は黙ってQtを使え、
なんだろうけど、なんかQtもなあ…、嫌なんだよなあ…、
と思いつつ、GLFWとかSDLで抽象化するのも困るみたいでX11書き始めたらハマった…
でも、GitHub漁ってると一人でX11だろうがGDI+だろうが、サクサク全対応書く人はいるんだなあ
もうWinMainだの忘れたよ…、はー
そういえば、ペゾルド本がWin32の鈍器みたいな本だった時代があったけど、
あれは良い本だけど、正直、第一章で疲れて読む気が失せたんだよなあ
ウィンドウ一枚表示するのにこんなに書くの?数行で出ないの?みたいに思いながら読むのが苦痛だった
でも、未だにQtとか使わないと、そのへんの基本設計も含めて世の中解決していないことは多いのだよなあと思ったり
OpenGL 1の時代は非力だったけど、ちょっとしたものを書くのは分かりやすかった
GLUTで対処できた時代だったからでもあるけど、やれることは今よりショボくても分かりやすかった
でも、今は乱立するバージョンとかシェーディング言語のバージョンとか、色々ハマることが多くなった気がする
Windowsだけ、Linuxだけだとしても、あらゆるグラフィクス環境に対応しなければならない
もしくはできるだけ低いバージョンに抑えるとかなんだろうけど
パソコンもスマートフォンも普段使っていて別段困る事はない。しかしながら戦術の通りプログラミングやソフトウェア、
そして最新のハードウェア等になるとまるっきりついていけない。ハードウェアはUSB-TypeCにも種類があるとか理解できない。
俺もコネクタなんて種類が多くてもう分かんないw
こういうのも技術的な意味合いのものと、商業的な大人の事情によるものが混在しているわけで
メンテナンスできないものを使い続けるというのはあんまりないはず
印刷の現場でClassic Macを使っていたり、工場でPC-9801を使っている現場は今でもあるにはあるけど、
日常でClassic MacやPC-9801を頻繁に見ることはないはず
西暦2020年にもなって、プログラミングが簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。
というかプログラミング言語自体多すぎる。ソフトウェアはデファクトスタンダードのモノ程度は知っているが、
例えば、Windowsのゲームを開発するときDirectXを使うと思うのだけど、なんでマイクロソフトがわざわざDirectX作ったかというと、
商業的側面は、OpenGLとかはJISのような規格なので、マイクロソフトは口出しできない、主導権が握れない、
技術的側面は、規格の策定はビジネスのスピードより遅く、グラフィクスカードの進歩に追いつかない、OpenGLよりも先んじて先進的な技術をユーザーに提供したい、
みたいな思惑があるわけだ
この選択は正しかったと思われる、それがXBoxの開発にもつながるし、Windowsデスクトップの表現力にもつながった
言語が多くなるのは近年のCPUなどのアーキテクチャに則した言語を作りたい、
折角作り直すんだったら文法なども変えたい、みたいな考えがあると思う
フロッピーディスクなんてもう終わったのだからいい加減AドライブをSSDまたはHDDにするべきじゃないのかとすら思う。
だけどずっとCのままだ。
古いプログラムの中には「C」と決め打ちで書かれてしまっているため、Cドライブという概念をなくすとこれまでの資産が全部動かなくなる
そうすると、Windowsのような最初のHDDをCドライブと決めているOSは誰も使わなくなってしまう
俺も役所への手続きだの、これを知っているのが大人の常識だの、みんなクソ喰らえだと思っているけど、
そうしないと駄目みたいな世間の空気があるので、嫌々ググって調べたり、お役所ルールバカすぎるだろwと思ったりするけど、
ただ、コンピュータを製造するのは企業だし、そこにはビジネス的な大人の事情とか思惑が介入するわけで、
そうなると純粋な情報処理という学問を阻害されることは容易に起こるわけである
だって、自分でゼロからコンピュータやOSを作るわけにはいかないし
かと言って、企業もまったく情報処理学や数学を無視したものを製造できるはずもないわけで、
これって流行り廃れる技術なのか、少なくとも死ぬまで廃れることのない技術なのか、みたいな選定の目につながる気がする
言語も、まあ色々だけど、とりあえずCのような言語がちゃんとできればコンピュータの中が分かってないと書けないところがあるからCをやる意味はある
Linuxカーネルの一部にRustを実験的に持ち込んだりしてるみたいだけど、Cがなくなることはまだまだない、というかこれからもずっと続くと思う
なんだかんだCはRustより書きやすいと思うし、書きやすいからこそRustよりデンジャラスなのだ
Cドライブ云々は、例えばLinuxではCドライブという概念がないが、
同じコードをWindowsとLinuxで動かすなら、まずOSの種類を判定するコードを書いて、そこからパスの生成を分岐させればいい
ので、まずはTCP/IPとか喋れるようにカメレオンだったかをインストールするところからがスタートだった時期があった気がする
それは当然、箱で買ってきて中のCD-ROMからインストールするわけで、インストールすればモデム経由でtelnetやmosaicが動作するようになる
そもそも、MicrosoftはWindows 95になってもインターネットに否定的で、独自のネットワークを推していたから(Microsoft Network?
まあ、OpenGLに対してDirectX作ったのは正解だったのかもしれないけど
最近のMicrosoftは180度方向が変わったかのように、
独自Edge放棄してChromium使った方がコスト安いし車輪の再発明なんてバカバカしいよねーw
なんだったらオープンソースコミュニティに金出すよGitHubに金出すよ、
Rustいいね採用してみるよRustでWindowsデスクトップアプリとりあえず書けるようにしてみたでー
みたいに急転換してしまったが、これはこれで楽しい気もするし、