はてなキーワード: オブジェクトとは
おまえは「ピンの話ばかりしている」と主張するが、
まず、大前提としてgoogle mapはスパムによる虚偽の申請があまりにも多いので、机上で確認できる手段がないと更新されないことがある。
このとき既存の建物のピンが立っているときは、ピンでないところをクリックして何もないところをクリックして灰色のピンを立てる。
で、右クリックして「場所を追加」を選ぶと、新しい施設の登録ができる。
もしかしたら、ここまでは増田はたどり着いている可能性がある。
「マーカーの位置を編集」でなるべく正しい位置にマーカーを移動してやってくれ。
もうないはずの既存の建物のピンと同じ位置なら重ねてしまっていい。
更に、現在googleに認定されてるランドマークと申請したい建物が一緒に写っている写真を添付する。
つまり、どの位置かというのを別の建物に証明してもらっている状態だな。
近くにランドマークがない場合は、最新のストリートビューとなるべく同じ画角で撮った写真を添付する。
こっちはストリートビューに位置を証明してもらってる状況だな。
これを逆利用して、ストリートビューに写ってるのに登録されてない建物を申請するという方法もある。
とりあえずクリア
難易度は一番低いやつ
途中詰まりそうになったときもあったけどなんとかクリアできてよかった
ps2の1はラストステージで詰まってクリアできんかったからなー
ロックマンのワイリーみたいな立ち位置なんだなラチェクラのラスボスって
声もあってた
画面のきれいさとロードのなさはすぐ慣れて、後半は逆につまんなかったなー
まちとかステージのオブジェクトもやたらリアルで数おおいけど、逆にそのせいでどれが壊せるものかとか、
大事な隠しアイテムかとかがすげーわかりにくくなっててイライラした
最後の最後でアクセシビリティってオプション設定あることしって、インタラクトできる箱とかゴールデンボルトとかギミックとかの色を変えたらすげープレイしやすくなったわ
わりとメインのはずの遠距離武器の爽快感がいまいちだったのは微妙だったなあ・・
近距離攻撃とどかねえから遠距離必須みたいな敵やボスが多いから余計に感じた
ベルトスクロールみたいにエリア内の敵倒さないと次に進めないのが結構あるけど、
終わってるかどうかがすげーわかりにくくて、終わってないのに進もうとして死ぬってのも何回かあってうざかったなー
まあ1回やればいいかなって感じ
スターオーシャン6とかもこういう感じで交互に見せてくれればよかったのになと
ラチェットとリベットで2週させられてたらクソうざかったと思うわ
こんな感じで1周で両方みせてくれたらいいんだよ
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて(キラキラ)」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
3行でまとめます。
〇 エクセルシートはユーザーインターフェース(インプット)か出力結果(アウトプット)のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列(連想配列)に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
(もちろん、ユーザーインターフェースの別の欄(セル)に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。)
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
(これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…)
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
1.元となるcsvファイルをエクセルに読み出してシートに格納
2.そのデータは日付が数値型になっているので、日付(数値型)の入った列を文字列に変換した日付(文字列型)列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず(あるいはエクセルのセルオブジェクトを変数のように扱い)、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか?。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列(連想配列)と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
(逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・)
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列(連想配列)で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
(参考)【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
(参考)Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ(VBA)から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列(連想配列)のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある(ローカルウィンドウやDebug.printを使うなど)ので、リハビリに取り組んでほしいです。
(参考)VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
(最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。)
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用(加工用)のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ(VBA)は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
(あと、コマンドプロンプトの真っ黒な画面が怖かった)
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
(そのやさしさが上述したとおり悪魔の罠なわけですが。)
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
「この関数にこういうパラメータを使ったこういう処理を追加してくれ」などと言われたら、コードは複雑化するのは当然だろう。
かといってこういう要求が来た時に、コード全体を一から作り直して簡潔にしようと思うのはナンセンスだ。
コードの量にもよるが、一定程度の量のコードがそこにあるときは、やはりリファクタリングの方が効率よく進められる。
「僕はリファクタリングなんてしませぇん、一から書いた方がいいでぇす」というのは、特定の現場・状況だけにあてはまるものだと認識しておこう。
確かに「コード全体をリファクタリング」なんてしようと思ったら大変すぎるが、通常は「修正を担当する部分をついでにリファクタリングする」でOKだ。
ユニットテストさえかけていれば、そのリファクタリングによって、バグが見つかりやすくなるだろうし、保守性も上がるのである。
なお、本当にコードベースが酷いカオス状態で、ゴッドオブジェクトを使っているような状況になったら、「書き直す」という利点が少しはあるかもしれないが、そういう場合は関係各位に同意を取らなければやってはいけない。
そういったカオスな状況でさえ、平均的なプログラマーは「良いコード」よりも「慣れているコード」に愛着を持つ傾向にある。
もしあなたが「コードを綺麗にするためにすべてを一から書き直そう」と、無断でそのようなことをやったら、彼らが慣れていないという理由で批判の嵐が殺到するだろう。
量子力学における観測者問題についてはよく知られるように、人間の主観性が量子実験の結果に重要な役割を果たしている。
ドイツの物理学者ヴェルナー・ハイゼンベルクによる有名な引用がある。
「私たちが観察するのは現実そのものではなく、私たちの質問の方法にさらされた現実です。」
例えば有名なダブルスリット実験では、スリットの後ろに検出器を置かなければ電子は波として現れるが、検出器を置くと粒子として表示される。
したがって実験プロトコルの選択は、観察する行動パターンに影響する。これにより、一人称視点が物理学の不可欠な部分になる。
さて、数学にも一人称視点の余地はあるか。一見すると、答えは「いいえ」のように見える。
ヒルベルトが言ったように、数学は「信頼性と真実の模範」のようである。
それはすべての科学の中で最も客観的であり、数学者は数学的真理の確実性と時代を超越した性質に誇りを持っている。
ピタゴラスが生きていなかったら、他の誰かが同じ定理を発見しただろう。
さらに定理は、発見時と同じように、今日の誰にとっても同じことを意味し、文化、育成、宗教、性別、肌の色に関係なく、今から2,500年後にすべての人に同じ意味があると言える。
さて、ピタゴラスの定理は、平面上のユークリッド幾何学の枠組みに保持される直角三角形に関する数学的声明である。しかし、ピタゴラスの定理は、非ユークリッド幾何学の枠組みでは真実ではない。
何が起こっているのか?
この質問に答えるには、数学的定理を証明することの意味をより詳しく調べる必要がある。
定理は真空中には存在しない。数学者が正式なシステムと呼ぶものに存在する。正式なシステムには、独自の正式な言語が付属している。
つまり、アルファベットと単語、文法は、意味があると考えられる文章を構築することを可能にする。
その言語には、「点」や「線」などの単語と、「点pは線Lに属する」などの文章が含まれる。
次に正式なシステムのすべての文のうち、有効または真実であると規定した文を区別する。これらは定理である。
それらは2つのステップで構築されれる。まず、最初の定理、証明なしで有効であると宣言する定理を選択する必要がある。これらは公理と呼ばれる。
公理からの演繹は、すべての数学がコンピュータで実行可能な印象を生む。しかし、その印象は間違っている。
公理が選択されると、正式なシステムで定理を構成するものに曖昧さがないのは事実である。
これは実際にコンピュータでプログラムできる客観的な部分である。
例えば平面のユークリッド幾何学と球の非ユークリッド幾何学は、5つの公理のうちの1つだけで異なる。他の4つは同じである。
しかしこの1つの公理(有名な「ユークリッドの5番目の仮定」)はすべてを変える。
ユークリッド幾何学の定理は、非ユークリッド幾何学の定理ではなく、その逆も同様。
ユークリッド幾何学と非ユークリッド幾何学の場合、答えは明確である。これは、単に説明したいものに対応している。
数学は広大であり、どのように公理を選択するかという問題は、数学の基礎に深く行くと、はるかに感動的になる。
すべての数学的オブジェクトは、いくつかの追加構造を備えたセットと呼ばれるものであるということだ。
たとえば自然数のセット1,2,3,4,...は加算と乗算の演算を備えている。
集合論は特定の正式なシステムによって記述される。Ernst ZermeloとAbraham Fraenkelと、選択の公理と呼ばれる公理の1つに敬意を表して、ZFCと呼ばれる。
今日の数学者は、すべての数学を支える集合論の正式なシステムとしてZFCを受け入れている。
彼らは、無限の公理と呼ばれるZFCの公理の1つを含めることを拒否する。
言い換えれば、有限主義者の正式なシステムは、無限の公理のないZFCである。
無限大の公理は、自然数の集合1,2,3,4,...が存在すると述べている。すべての自然数に対してより大きな数があるという声明(「ポテンシャル無限大」と呼ばれる)よりもはるかに強い声明である。
有限主義者は、自然数のリストは決して終わらないことに同意するが、いつでも自然数の集合の有限の部分集合のみを考慮することに限定する。
彼らは一度にまとめたすべての自然数の合計が実在することを受け入れることを拒否する。
この公理を取り除くと、有限主義者が証明できる定理はかなり少なくなる。
正式なシステムを判断し、どちらを選択するかを決定することができるいくつかの客観的な基準...なんてものはない。
「時間と空間を超越した何かを象徴しているので無限大が大好きだ」と言えば無限大の公理を受け入れることができる。
ゲーデルの第二不完全性定理は、十分に洗練された正式なシステム(ZFC等)は、自身の一貫性を証明することができないと述べている。
数学者は、今日のすべての数学の基礎であるZFCが確固たる基盤にあるかどうかを実際に知らない。
そしておそらく、決して知ることはない。
なぜなら、ゲーデルの第二の不完全性定理によって、より多くの公理を追加することによってZFCから得られた「より大きな」正式なシステムにおけるZFCの一貫性を証明することしかできなかったから。
一貫性を証明する唯一の方法は、さらに大きな正式なシステムを作成することだけだ。
数学を行うためにどの公理を選択すべきかについて、実際には客観的な基準がないことを示唆している。
要するに、数学者が主観的に選んでいるというわけである。自由意志に任せて。
公理のための主観的な基準というのは、より豊かで、より多様で、より実りある数学に導くものを選ぶという人は多い。
これは自然主義と呼ぶ哲学者ペネロペ・マディが提唱する立場に近い。
特定の公理のセットを選択する行為は、量子物理学の特定の実験を設定する行為に似ている。
それには固有の選択肢があり、観察者を絵に導く。
コードを簡潔に保つにはモジュール化が必須である。しかし同じモジュールに関係のない機能が含まれていたりすると混乱の元になる。
一方で、関数というのは引数の細かな仕様に依存せずに、汎用的に呼び出せた方が何かと好都合だ。引数になんらかのオブジェクトを渡し、そのオブジェクトしか持ち得ないような特殊な情報で処理を行なったりすると、関数とオブジェクトが互いに依存しあってしまう。
これはモジュールの結合度と呼ぶ。
高い凝集度、低い結合度によってモジュールを作れば、保守性は上がる。
さらにモジュール内では、公開する必要のない関数はprotectedまたはprivateにするべきだ。
そのためにはモジュールが公開すべき関数についてインターフェイスを作り、公開関数に対するユニットテストを書いておくのが良いだろう。
意外なほど反応ついてたけど読まず返事せず続ける。というか言いたいことの1割も書いてないので返事してたら続けられない。
読み返しててアズレンとブルアカが混ざっててどっちの話だかわからなくなってるが、すまん。
神バハだって当時すごい盛り上がって楽しかっただろというのは自分もそうですはい。
三目並べだって楽しめれば別にゲームとして欠陥あっても関係ないというのもその通り。
この場合、ゲームデザインとして実際のゲーム内容とゲームのルックが嚙み合ってないのが、よろしくないと感じる理由になる。
つまり、なんか雰囲気がドルフロに似てるなあという類似が、ゲームの性質からくるのではないと考えるからだ。
ゲームジャンルが同じだと見た目が同じになるのはむしろ当たり前。ファイアーエムブレムとラングリッサーが見た目が似てると言って怒るのは…譬えが悪かった。
艦これとアズールレーンでいうと、艦これはジャンル分けが難しいオリジナルジャンルだがああいうゲームで、アーケード艦これは3Dのアクション?ゲーム。アズールレーンは2Dシューティング。アズレンがアーケード艦これのルックにあえて似せる必要は特にない。が、実際、なんかそれっぽくなってしまってる。
パクリではない。キャラクターは独自の2Dに落とし込んであるし、ゲームシステムも違う。別物である。
ただ、軍艦モチーフのヒット作の後追いで出た軍艦モチーフゲームのゲーム画面の全体のルックが、ゲームシステム上の要請によるものでなく、なんとなく似てる。
おそらくは、参考にしました、ということだろう。
アズレンの場合、一番近いのは二次創作同人ゲーだと思う。キャプテン翼のやおい同人誌を商業向けに絶愛にしました、みたいな…譬えが悪いか。
気にする奴は気にするが、気にしないやつは気にしない、ただネタ元へのリスペクトは本当にあるんか? と思いたくなるような微妙な感じだ。
この場合、似てるから悪いのではなく、似てないことが気持ち悪さの原因になっている。別にネタ元のニュアンスをあえて残す必要がないのに残ってしまってるのが、単なる素材として雑に扱ってるんだろうなと感じるのである。自分は。
ブルアカでも、同様の、パクリではないけど…を感じ取ってしまう。
基本的にゲームシステムは生煮えである。2Dキャラがちょこまかと動きまわり、いろんなアクションを取るところが一番のセールスポイントであるのは間違いないが、それを使ってゲームシステムとしてうまくできてるかというと、見た目がちょっと豪華になっただけというのが正直なとこだろう。
プレイヤーが操作可能な範囲とゲーム画面のルックがうまく繋がってない。範囲攻撃の範囲指定ぐらいだろうか。回避指示はごく少数の特定キャラしか使えないし。AIオートにすると本当に頭が悪すぎるのでスキル使用はプレイヤー操作するしかないのだが、正直、ここまでオートが使い物にならない理由がわからないぐらい使えなさすぎる。なんとかゲームっぽさを演出しようとして、プレイヤーのやることを無理やり残すためにオートをあえて役立たずにしたのではないかと疑っている。
美少女が実銃で銃撃する動作を頑張って作ろうという熱意は凄くある。あるが、ゲームにはならなかった。
銃と美少女という組み合わせだけが先行してて、後が続かなかった。
さて2D銃撃部分ではグラフィックが先行してゲームデザインが追い付かなかったという話なのだが、そうなると気になるのが「もう一方のゲーム画面」であるフロアマップ。
メインと銘打ったステージで見れるのだが、これは完全に、まったく、寸分の違いもなくドルフロそのまま。ユニットの動かしかたまで同じだし、マップ上のオブジェクトも似てる。
ドルフロでは、マップはゲームの中心部分として機能していた。最初に見ると艦これの海域マップみたいに見えるが上手くアレンジしてあって、要は戦術シミュレーションのマップの簡略化した形だ。ゲームデザインとしての中心部分なので先に進むほどマップが大きくなり難易度が上がり、そのうちスマホだとマップを見ることすら不可能みたいなことになり(ゲーム公式がPCエミュでのプレイを推奨してたぐらい)、ライトユーザーが引くぐらいなことになるのだが、そのぐらいゲームとしての意味がちゃんとあった。
ブルアカでのマップは、ドルフロの凶悪マップを反面教師としたのだろう、基本的に戦術シムみたいなことは一切ない。というかやらせてくれない。代わりにボタン押しギミックがやたら増えた。
結果、マップはあっても、実際のユニットの移動ルートは実質1つだけ、というのが現在のブルアカのマップである。この部分はトライアンドエラーで運営の用意した正解を引くパズルみたいなもので、プレイヤーのやれることはほぼない。こうなってくると、マップ攻略はほぼ作業でしかなく、こんなことやらせず戦闘だけ抜き出して置いておけばいいだろ、という気分になってくる。
書いてみて思ったが、自分がドルフロとブルアカを対比してしまうのは、かなりの部分ここだと思った。ドルフロは艦これフォロワーとして作られたがゲーム部分は独自性が強く、艦これから受け継いだように見える部分でも自作品に合わせるように作り変えてあり、ゲームのルックとゲームデザインの間に乖離がない。ブルアカはドルフロから全く変えずに完コピしたが、(おそらくソシャゲとして楽に遊べるようにするためにという思惑もあって)その完コピした部分はゲームとしての機能を失い煩雑なだけの盲腸となってしまってる(かといってマップをなくすのも微妙かもしれない。先述したように2Dキャラ銃撃部分はプレイヤーがやることがあるように見えて少ない、基本的にキャラを愛でるためのパートだ。形骸化してるとはいえマップをなくしてしまうと、ただでも少ないゲームっぽさがさらに失われてしまうことになる)
ドルフロと同じなことについて「真似した」以外の理由が思い浮かばなくなってしまっている。このへんの真似っぽさは「銃と美少女」というセールス部分からは外れたとこなので雑にやっつけちゃったんだろうが、ここがあるからこそ、「銃と美少女の組み合わせなんて過去にいくらでも前例がある、別にドルフロは関係ない」と言いづらくなっている。ゲームシステムとしての合理性がありプレイヤーのゲーム体験としてうまく昇華させていれば、同じジャンルだから似てるだけと言えてたはずだ。
自分がブルアカのゲームデザインが雑なのが、単に雑であるよりあかんとこだと思う理由は、上記となる。
まだまだ続きます。
見た通り基本お気持ち表明なのでそのように。
プログラミング言語側に組み込まれている「型」だけでなく、プログラマーが独自に「型」を定義する方法も用意されています。
struct、class、interface、type, enumなどを使って独自の「型」を定義します。
開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります。
多数の「型」を分類し、組織化するために名前空間を利用します。
近年「クラス」が「型」の定義であるという基本概念を理解していないエンジニアが増えているので、エンジニアを採用する際には注意しましょう。
ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています。
例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。
業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります。
これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます。
CPUは機械語しか理解できません。一方で人間は機械語でプログラミングすることは困難です。
人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。
CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまいます。
そこで、人間にとってプログラムを読みやすくすることと、CPUに意図しない演算をさせないために、データの種類を表す「型」という概念がプログラミング言語に用意されるようになりました。
金融やECサイトなどのお金の計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。
メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります。
例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。
オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。
これだから3Dオブジェクトのコピペゲーをなんとも思わず消費するSteamユーザーは嫌いなんだ
ゲームってのはパン作りのように粉からこねて自分で作ってこそクリエイターの思想が反映されるってもんだ
それすらこだわる気がないのに、見栄えのするゲームを手抜きで量産していくことに、意味はあるのか!
それは最終的に、人がゲームから受けるセンス・オブ・ワンダーを損ね、薄味なゲーム文化体験を推進してしまうことになる
ゲームにおけるQoLが下がればゲームという産業それ自体がパチンコのようなものに成り下がってしまうおそれがある!
事実、買い切りだからという紛い物の安心感のために、クリエイターたちの血と汗が数百円で安売りセールされる地獄がそこにあるだろ!
そういう環境を作ってるのはあんたらだ! そうなれば作り手もいかに手抜きしつつ一発当てるかしか考えなくなる! ソシャゲと同じだろ!!
同じ2Dスプライトやドットキャラ、聞いたことあるBGMを使いまわすようなRPGツクールゲーばかりになった世の中を想像してみろ!
それはDLsiteでは現実になってるが、同人だからこそ許されてるもんだろ
module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。
でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合は分岐コードが増えて共通関数の保守コストが上がる。
あとありがちなのは、php開発者が関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。
とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスのフィールドに関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドとメソッドを追加して、さらに進むとユーザーとは無関係な機能も含めすべてをユーザークラスに定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。
先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。
ingressを離れた諸氏は知らないだろうが、最近のingressには、OVER CLOCK HACKなるものがある。簡単にいえば3D版グリフハックだ。
お馴染みのグリフが3DのARオブジェクト上に表示されるので、それを解読・記憶して2Dのグリフを入力する。
そうすると、正解率に応じてとんでもない量のアイテムがもらえるというミニゲームだ。
私は元々ingressのグリフハックが好きで、グリフとそれらを組み合わせた頻出熟語(例:human + civilization)や、LV8のグリフハックのパターン(例:create + pure + future + human + civilization)も結構覚えてる。
しかし、そんなグリフハック好きな私でも、OC HACKだけは無理だ。
難易度が高いからこそリソースが沢山もらえるってことなんだろうが、ミニゲームとしての完成度が低過ぎて、やっててストレスしか溜まらない。本当につまらん。
石川の能登は冷やかしどころかボランティアすら断るほどインフラが壊滅していて、現地入りした人が色々と叩かれてるけど、ぶっちゃけSNSにあげるかどうかは別として震災直後の現地を観光してみたいって気持ちはある
311のときの東北は津波で街が流されていて壊滅した瓦礫ばかりである意味圧巻だったようだが、残念なことにそれを見ることなく終わってしまった
なお、そこから1年後に現地入りしてもまだ瓦礫が残っていて被災地としての風情があった(意訳)と知人が言っていたけどね
例の奇跡の一本松とかは今は立派な観光名所になってるがあれはただのレプリカで、本物は震災直後の数週間でしか見れなかった(塩害で死んだので)
岩手の大槌町では建物上に乗り上げた船とか風光明媚なオブジェクトもあったがあえなく解体されたんだが、むしろああいうの残しておけば観光地として生きながらえて過疎地にならずすんだはず
まだ産まれてないが阪神・淡路大震災の崩壊した高速道路とかああいうのもさっさと解体撤去されたけど、ああいう非現実的なものを見れた人が羨ましい
石川の被災地は風情のある古民家が多いしプチ京都みたいな町並みだったが、それが倒壊しまくってる姿は、まさに東京大空襲や関東大震災のときの東京を彷彿とさせてくれるのではないか
これは見たい・・・是非とも見てみたい・・・そういう思いがムクムクと元旦からこみあげてくる
というので連休はまだまだ続くので、被災地入りしてみようかなと思っている
今は関西の某所に住んでいるが、石川の首都である金沢はほとんど無傷でインフラは生きているので、そこまで車や公共交通機関で行ったあとあとは自転車あたりで能登半島まで行ってみたい
例の倒壊した輪島塗の五島屋とか特に立ち入り制限されてないらしいから真っ先に見て写真とってこようと思う
でも炎上はしないだろうね
僕はプログラミング歴2週間の初心者です。キーと値を入力できるデータベースを作っています。
以下のコードを実行してデータを追加し続けると、一定のサイズを超えるとエラーが出てしまうみたいです。
理想は、データが追加された後にサイズが足りなくなったら動的に自動拡大されることです。
もし詳しい人がいたらご教示お願い致します。
import sys import os import mmap import hashlib def h(x): return int(hashlib.sha512(x.encode()).hexdigest(), 16) def create_db(filename): with open(filename, 'wb') as f: f.write(b'\0' * 1024 * 1024) # 1MBの空ファイルを作成 def set_key(filename, key, value): with open(filename, 'r+b') as f: mm = mmap.mmap(f.fileno(), 0) pos = h(key) % mm.size() while mm[pos:pos+1] != b'\0': pos = (pos + 1) % mm.size() if pos == h(key) % mm.size(): f.seek(0, os.SEEK_END) f.write(b'\0' * mm.size()) # ファイルサイズを2倍にする mm = mmap.mmap(f.fileno(), f.tell()) # ファイルサイズを反映させる pos = h(key) % mm.size() # ハッシュ値を再計算する data = key + '\0' + value + '\0' data = data.encode() mm[pos:pos+len(data)] = data mm.close() # mmapオブジェクトを閉じる def get_key(filename, key): with open(filename, 'r+b') as f: mm = mmap.mmap(f.fileno(), 0) pos = h(key) % mm.size() while mm[pos:pos+1] != b'\0': end = mm.find(b'\0', pos, mm.size()) # 第2引数と第3引数を指定する if end == -1: end = mm.size() if mm[pos:end].decode() == key: pos = end + 1 end = mm.find(b'\0', pos, mm.size()) # 第2引数と第3引数を指定する if end == -1: end = mm.size() value = mm[pos:end].decode() mm.close() # mmapオブジェクトを閉じる return value pos = (pos + 1) % mm.size() if pos == h(key) % mm.size(): break mm.close() # mmapオブジェクトを閉じる return None def main(): cmd = sys.argv[1] if cmd == 'create': create_db(sys.argv[2]) elif cmd == 'set': set_key(sys.argv[2], sys.argv[3], sys.argv[4]) elif cmd == 'get': print(get_key(sys.argv[2], sys.argv[3])) if __name__ == '__main__': main()