稲枝の押入れ

いなえが適当なことを書いては、しまっておく場所

Fortniteというゲームについて

初めに

最近少しずつ話題になってきているFortniteというゲームについて、あまりに情報が少ないので、少しプレイしただけですが、現時点でわかっている事を書いておこうかと思います。

基本言語が英語なこともあって、初見だと戸惑う所もあるかもしれませんが、これを読んで少しでも楽にプレイできたらと思います。

Fortniteって?

PvP(プレイヤー同士のオンライン対戦)モードに限って話すと、PUBGとマインクラフトを足した感じのゲーム性です。

つまりは多くのプレイヤーで同時に島に降り立ち、そこに置かれた物資(武器・回復道具・素材等)を回収して、戦いつつ、適宜壁や階段を作り、最後の1人になった人が勝ち、という感じです。

簡単にイメージを掴みたい人はこちらの動画を御覧ください。

youtu.be

PUBGでいうところのSQUAD(4人1組でのチームプレイ)も存在します。

PvE(CPUとの対戦)モードはムービーを見た限り、L4D2とマインクラフトを足した感じのゲームなんでしょうか。メタルギアサヴァイヴを思い出しました。

いくらなの?

2017年10月8日現在、アーリーアクセスなのでPvPは無料で遊ぶことが出来ます。2018年中にPvEモードも無料になるそうです(今も課金することでプレイできるみたい?)。

入手方法

  • 公式サイトPLAY FREEをクリックします。
  • Epic Gamesアカウントを持っていたらSIGN IN、持っていなければSIGN UPを押します。
  • インストーラーがダウンロードされるので、指示に従ってインストールします。

起動方法

Epic Games Launcherを起動して、タブがFORTNITEになっていることを確認し、起動をクリックします。

f:id:makiofinae:20171008015026p:plain

プレイ方法

起動後BATTLE ROYALEをクリックします。

f:id:makiofinae:20171008015508p:plain

参加方法

ソロプレイする場合

Match Type:Solo、Squad Fill:No Fillのまま、Playを押します。

チームプレイする場合

友人等とプレイする場合はまずフレンド登録が必要です。まず右上のフレンドのボックスをクリックします。 f:id:makiofinae:20171008020524p:plain

ドロップダウンしてきたリストのタブのうちAdd Friendをクリックし、フレンド登録したい人のIDを入力し、ADDを押した後、相手に承認してもらいます。

プレイヤーのキャラクターの横にある+マークをクリックして招待します。

もし友人と合わせて2人しか身内にはいないが、4人でプレイしたいと言うような時はSquad FillをFillにします。

4人チームのゲームに、2人のみで参加するのでかまわない場合はSquad FillをNo Fillにします。

ルール

1つの島に沢山の人間が着陸して、最後の生き残りになるべく戦います。ソロプレイの場合は体力がなくなると終了です。

チームプレイの場合は、体力がなくなっても即時死亡ではなく、気絶するだけです。チームメンバー全員が気絶するか、気絶させられた後もダメージを受け続けると、死亡扱いとなり終了です。

操作方法

基本操作

操作方法についてはまず列挙しようと思います

  • 移動:WASD
  • 走り:Shift
  • しゃがむ:Crrl
  • ジャンプ:Space
  • 攻撃/設置:左クリック
  • 狙う:右クリック
  • 使用、拾う等のアクション:E
  • マップを開く/閉じる:M(or Tab)
  • インベントリを開く:I(or Alt)

これらは書いてある通りなので特に詳しくは触れません。

ただ一つ言うことがあるとすれば、右クリック長押しで狙うことが出来ますが、このゲームではADS(サイトを覗くこと)は基本的には出来ず、三人称視点の状態で画面の中心に向かって射撃することになります。しかし例外があって、スナイパーライフルの場合は覗き込んで射撃することになります。

飛び降り

メッセージが出てくるので問題ないかと思いますが、PUBGと違い、島に降下するのに押すキーはSpaceです。

また、地表から近いパラシュートを強制される一定よりも低い高度を除いては、パラシュートを開いたり、もう一度閉じて自由落下したりをSpaceで切り替えられます。

建築

さて、このゲームでは通常モードと建築モードとでも言うような2つのモードが有り、それらをQキーで切り替える事ができます。

通常モード

通常モードにおいては、ピッケルや銃・アイテム等が使用できます。建築モードで何かを立てるための資材を集めるためにピッケルで様々なものを壊す時や、敵と交戦する時等、プレイ中の殆どの時間をこのモードで過ごします。

マウスホイールで手に持つものを順に変更でき、数字キーなどを使って指定のものを手に持つ事もできます。

手に持つ事のできるもの、つまりカバンに入っているアイテムは、下のスロットに表示されています。

建築モード

建築モードにおいては、フィールド上に壁・床・階段・屋根・その他オブジェクトを設置できます。コレを使って敵から隠れたり、銃弾を防いだり、高い所に登ったり、どこかに渡ったりします。

同じくマウスホイールで建築するものを変更できます。左クリックで設置しますが、右クリックすることでその建築物の材質(=材料)を木→レンガ→鉄→木→…と変更することが出来ます。

全ての建築物は、その建築物の材質の素材を10消費して建築できます。

その他備考

武器やアイテムの取得

基本的に光ったオブジェクトが家の中などの床の上に浮いているのでそれを拾う感じです。

しかし稀に光る金色の宝箱が落ちているためそれをEで開けることで取得することも出来ます(レアなものが出る確率が高い気がする)。

金の宝箱は音を発しているので、家の中などで不思議な音がしたら屋根裏など音のなる方を探してみましょう。宝箱は叩いて壊した場合武器やアイテムを出さないので注意が必要です。宝箱が設置された床を壊した場合も同様なので注意しましょう。

他にも鉄の箱を開ける音でアイテムを手に入れられたりもします。こちらは光ってもいなければ音も出ていないので見落とさないようにしましょう。

木を切り倒すとそのなかに武器やアイテムがあったりすることもあるらしいです(僕は見たことないです)。

持ち物

基本的にアイテムは5スロット分、つまり最大5種類までしか持てないようです。ただ、武器以外の特定のアイテムは、同種類なら重ねられるようです(Bandageを10個もつ、等の場合でも1スロットのみしか消費しない)。

銃弾については通常の範囲内では制限はないようです、自由に持てます。

木・レンガ・鉄等のフィールド内オブジェクトをピッケルで殴る事で得られる資材についても、制限はないようです。

武器の種類

武器は確認できた範囲だと、

  • ピストル
  • ハンドガン
  • サブマシンガン
  • ポンプアクションショットガン
  • セミオートショットガン
  • セミオートライフル
  • スナイパーライフル
  • ロケットランチャー(自分で手に入れたことはない)
  • グレネード

等があるようです。

アイテムの種類

  • 包帯(一定量を回復。ただし上限は75まで)
  • 応急セット(全回復)
  • シールドポーション(数敵弾を受けても代わりに消費する事でダメージを受けないようなシールドを50付与)
  • 各種弾薬

武器のレアリティ

同じ種類の武器でもレアリティによって性能が違うようです。レアリティは武器に付いている☆の数で表されます。また、レアリティによって武器についているオーラの光の色が変わるのでそれで判別することも出来ます。

PUBGとの違い

ここまでであまり触れていない所をメインに書くと

  • 大分軽いように感じる。ロード等も一瞬だし、通信でカクつくことはあっても処理でカクつくことはない
  • PUBGのように草むらに隠れたり、と言ったプレイは難しそう(出来なくはなさそうではあるけど…)
  • フリールックは存在しないので前しか見れない
  • パラシュート周りが非常に操作感が良く、基本的に思った位置に降りられる
  • パラシュートがよくわからない所に引っかかったりしない
  • ブースト系アイテムがない
  • 銃のカスタムは出来ない?(要確認)
  • ADSが基本できない
  • 設定を変えないとRevive中などキーを押しっぱなしにする必要がある(押してから待つのではない)
  • 操作感がアクションチックで非常によく、意図しない動きをすることが非常に少ない
  • カメラが荒ぶる率が少ない
  • 銃を拾ったらデフォルトでワンマガジン分は弾が入っている
  • 応急キット的なアイテムが全回復
  • 乗り物がない(オブジェクトとしてはあるが乗れない)
  • 島が少し狭い?

というかんじ

最後に

PUBGとはまた違った楽しさがあるよ!!是非皆もやりましょう!!

DXライブラリのパスワード付きアーカイブ機能を楽に使いたかったので適当なソフト作った

前置き

はい、完全にタイトルのとおりです。

そんなに大したこともしてないし、そもそも需要があるのかわからないので自己満足なんですが、一応軽く説明しておきます。

ツール自体は「ツール(EasyDxArchive)について」のところにリンクがあるので、注意書きを読んでお使いください。

DXライブラリ(DxLib)とは?

これをそもそも知らない人は別にこの記事を読んでも何も嬉しいことがないと思います。

という事ここでは割愛します。

アーカイブ機能について

アーカイブ機能とは?

DXライブラリは、ゲームを作るのに役立つ機能を提供してくれていますが、実はライブラリそれ自体以外にもツールを提供してくれていたりします。

それらのツールは、DxLib_VCというDXライブラリについての様々なファイルが入っているフォルダ直下のToolというフォルダ内にまとめられています。(C:\DxLib_VC\Toolだったり)

その中の1つがここで言うアーカイブツールです。アーカイブについてはこちらのDXライブラリ置き場でも参考にしてください。

まあ簡単に言うと、ゲームの素材(画像やら音やら)をそのままゲームのexeファイルと一緒に配布してしまうと中身が丸見えになってしまって、ネタバレが起きたり素材を流用されてしまったりとか有り得るよね、みたいな色々な要請から簡単には見えないようにするのがアーカイブ化と呼ばれるもので、これをするのがアーカイブ機能です。

そして勿論、DXライブラリはアーカイブ化した素材(つまりアーカイブファイル)も読み込むことが出来るようになっています(対応しているものなら)

パスワード付きアーカイブ機能とは?

さて、本来DXライブラリについてくるアーカイブ化ツールは、フォルダをDxaEncode.exeにドラッグ・アンド・ドロップすればアーカイブファイルを作ってくれるという楽に使えるものです。しかし、それだと問題がある部分があります。作ったアーカイブファイルをDxaDecode.exeドラッグアンドドロップすると簡単に元ファイルに戻せる(デコード出来る)のです。これではアーカイブ化しようとしている要請を満たせていないですね。

そこで、DXライブラリのアーカイブ機能は、パスワードによって、DXライブラリからの素材の読み込みやデコードを制限することが出来るようになっています。

例えばパスワードにosageを指定してアーカイブ化すると、デコード時にそのパスワードを入力しないとデコード出来ないし、DXライブラリから読む時も、ある関数でパスワードがosageであると指定してやらないといけなくなるわけです。

パスワード付きアーカイブ機能の面倒な所

パスワード付きアーカイブ機能は便利なのですが、1つ面倒なことがあります。それは、さっき言った「フォルダをDxaEncode.exeにドラッグ・アンド・ドロップ」するという方法が使えないということです。

パスワード付きアーカイブ機能の場合は、コマンドプロンプトからオプションをつけてコマンドとして実行する必要があります。少し面倒ですね。ファイル階層が複雑なところにあったりすると、素材がリリース間近で更新される度にこれをやるのはとても面倒です(経験談)。

今回、これを楽にできないかということで手が空いていたので、よくわからないC#を適当に叩きながら2時間位でこのツールを作ってみました(雑)

拡張子について

アーカイブ機能で製作したアーカイブファイルの拡張子はデフォルトでは.dxaなのですが、これではDXライブラリのアーカイブファイルだと一瞬で分かる人にはわかってしまいます(結局readme等に権利関係を記載する必要がありわかってしまうじゃん、という話はあるのですが)。

そこでDXライブラリにはアーカイブファイルの拡張子を変えても読み込める機能が備わっています。プログラム内で関数から拡張子を指定してやることで.dxaではなくともアーカイブファイルを読み込めるようになります。

しかし、結局アーカイブツールから生成されるアーカイブファイルは*.dxaなので、これを手作業で例えば*.osg等と変えてやる必要があるのです。

…面倒ですよね。これもツールの側で指定して一気に変更できるようにしておきました。

ツール(EasyDxArchive)について

注意書き

C#がよくわかっていない初心者が適当に作ったツールです。

したがって、このツールを使った事による損害等についてはこちらでは責任は取りかねるということをご了承の上お使いください。どうでもいいファイルで一度試してみることを推奨します。

バグの報告などは受け付けておりますのであったら報告がいただけると嬉しいです。

また、使用に関しては自由にして頂いても構いませんが、ソフトそのものの二次配布等についてはご遠慮ください。

置き場所

こちらからダウンロードしてください。

exeファイル1つというとてもシンプルなものですので好きな所に置いて使ってください。

ツールの使い方

起動するとこんな感じのウィンドウが開きます。 f:id:makiofinae:20170910142354p:plain それぞれのテキストボックスは、

  • Program Adress : DxEncode.exeのアドレスを指定
  • Data Adress : アーカイブ化したいファイル(フォルダ)の置いてあるフォルダを指定
  • Target File Name : アーカイブ化したいファイル(フォルダ)を指定
  • Password : パスワードを指定
  • Extension : 拡張子を指定(.は要らない)

という構成になっているので、自分がしたい設定をし、「Make Archive!」ボタンを押します。すると下に実行結果が出力されます。

アーカイブ化したファイルはData Adress、つまりはアーカイブ化したいファイル(フォルダ)のあるフォルダに生成されます

アーカイブ化したいファイルの有るフォルダと、アーカイブ化したいファイルとをわざわざ分けているのは、例えば同じ階層にimageフォルダとsoundフォルダがあった場合にTarget File Nameを書き換えるだけで楽にアーカイブ化出来るようにと言う配慮なので、特に大きな意味はありません。

おしまい

というわけで締まりもクソもないですがこれで終了です。これで少しでも皆様の制作が楽になれば幸いです。

git初心者によるgit入門

前置き

対象

この記事は、「gitって何?」もしくは「名前だけ聞いたことはあるんだけど何となく手を出さないままでよく知らない」という人を主な対象としています。「コマンド普段から打つわけじゃないから抵抗がある or 面倒だ」という人にも向けています。また、僕自身の備忘録も兼ねています。あしからず。(おそらくこれらのユーザーの殆どはWindowsを使っているだろうという邪推から特に断りなくOSはWindowsを使っているものとして話を進めていきます)

目標

これを読んで、とりあえず最低限の機能については使える、知識としてではなく使えるくらいにはgitをわかってもらえたらなと思います。

注意

gitは一般には(というか原則は)CUI(文字だけの黒画面でコマンド打ち込んだり)で操作をするものなのですが、周りの人を見ていると、gitを使うことに抵抗を覚えている人がメインとしてGUIを使っている人(僕もその1人ですが)が多いので、SourceTreeというGUIフリーソフトを使ってとりあえずgitの便利さを知ってもらい、かつ難しい事をしている訳ではないという事を知ってもらうつもりでいます。コマンドをカタカタ打ってgitを使いたい!という方は沢山ドキュメントが転がっていますので適当なワードで検索することをおすすめします。とはいえ、SourceTreeについての説明部分以外についてはCUIで使う人にとっても有用な部分があるかもしれないので軽く見ていってください。

また、この記事では本当の本当に基本的な事を扱います。あくまでもgitに対するよくわからないという意識を拭うことのみを目的としています。

加えて、筆者も初心者なので、記述が正確であるかはわかりません。他のサイトと記述が矛盾している場合、自らでどちらが正しいか判断してください。そのような場合など、こちらにコメント等頂けると筆者も勉強になるばかりでなく、記述がより正確になるのでありがたいです。

本題

gitとは?

gitとは何か、と聞かれて一言で答えると「分散型バージョン管理システムの一つ」と僕ならば答えるのですが、人によっては何のことやら?という感じだと思います。順をおってみてみましょう。

バージョン管理システムの説明

バージョン管理システム」とは、そのまま「バージョン管理をするシステム」のことだろうというのは推測できるかと思いますが、ではその「バージョン管理」とは何でしょう?ゲームなどで(特にオンラインゲームで見る気がしますが)、「ver.1.2」みたいな表記を見ることが有りますよね。あれがバージョンだということは大体の人は知っていると思います。バージョン管理システムとはまさにあのバージョンを管理するシステムなのです。さて、バージョンはこれでわかったと思いますが、バージョン管理とはなんでしょうか。

それではここで、普段見るゲームのバージョンというものを、遊ぶ側からではなく作る側として考えながらバージョン管理とは何かを見ていきましょう。

例えば、

  • ゲームの基本システムが完成したものをver.1.0
  • 「モンスターA」を追加してモンスターの数を増やしたものをver.1.1
  • 「ボスA」を足したものをver.1.2
  • 「モンスターB」を追加してモンスターの数を増やしたものをver.1.3

としましょう。その上でこれをゲームを作る、開発者目線から見てみます。ver.1.2ではボスを追加しましたが、ボスの動きの実装が難しく、バグが出てしまったとします。バグが取り除ければそれに越したことは無いのですが、バグがなくプレイできる様なバージョンを用意して置かないと、ちょっとプレイして確認したいところがある、などといった時にバグのあるバージョンしかプレイが出来ずデバッグ的な観点からも不都合です。

ではどうすればいいかというと、それぞれのバージョンの状態でプロジェクトを何処かにコピーしてバックアップしておく方法が考えられます。そうすれば仮に最新バージョンでバグが出たとしても、ひとつ前のバージョンのバックアップがあるのでプレイ自体は問題なく行えます。こういったバージョン毎の管理がバージョン管理です。 しかし、多くの方がお気づきでしょうがこのような手動のバージョン管理は無駄が多いです。例えば

  • 新しいバージョンが完成する度に手動コピーをするので特にプロジェクトの規模が大きくなると時間がかかる
  • 同じく、プロジェクトの規模を増すほどに容量を食う
  • コピーした後、「ゲームver.1.0」「ゲームver1.1」とプロジェクトフォルダの名前を手動で書き換えないといけない
  • バージョンはわかってもそのバージョンでどのような変更がなされたか等はフォルダ名に書くわけには行かないので別途テキストを用意して管理しないといけない
  • モンスターAとモンスターBだけを実装したバージョン、つまりバグのあるボスAの実装を全て消したバージョンを作るのに手動でやるしか無い
  • 下のようにリネームの際の表記がブレてしまうこともあり、一貫性がなくなる

f:id:makiofinae:20170818164303p:plain

という感じです。欲を出すともう少しデメリットを出していけるのですが、ここではこれくらいにします。

ではどうすればいいのか、というところでバージョン管理システムの登場です。バージョン管理システムでは、上記のような手動のバージョン管理によるミスを防げる上に、より無駄のない管理が出来るようになっています。 例えばgitではフォルダをコピーしてバックアップしなくても、コミットという動作をすれば、バージョンを作ってくれる上に、その日時や変更内容、コメントなどの情報をまとめたものを作って管理してくれます

バージョン管理システムのイメージ

と、ここまで説明しましたが、イメージがつかめない人がいるかもしれません。その人はゲーム等のセーブをイメージしてくれればいいと思います。バージョン管理システムとは、開発(先程はゲーム開発の例を出しましたがそれ以外のソフトウェア開発についても)等をする際に、その開発内容のセーブやロード等を出来るように管理してくれるシステムなのです。 ゲームでの「あのアイテム取りそこねて先に進めないからあそこのセーブデータに戻ってアイテムを取り直そう」というのと同じように、開発でも「新しく実装したものがバグが有って取るのが難しいから前のバージョンに戻ってもう一度コードを書きなおしてみよう」というのを出来るようにするのがバージョン管理システムです。

gitの大まかなイメージ

「分散型バージョン管理システム」のうち、残りの「分散型」について説明をする前に、gitの簡単なイメージを掴んでおきましょう。 gitでは、ユーザーは「リポジトリ」というバージョン管理の情報等を入れる入れ物の様な物をつくり、そこに新しいバージョンについての情報を追加したり、そこにある過去のバージョンの情報を参照したりすることでバージョン管理をします。つまり、自分のPCの中には実際に開発中である様々なファイル(ソースコードやデータ等)とリポジトリがあり、開発中の様々なファイルの変更をセーブしたい時は、ローカルのリポジトリに対して、バージョンを保存してくれと言ったような命令を出して現状の情報を保存するわけですね。 また、gitではサーバ上などオンラインにリポジトリを作ることも出来、ここに自分のローカルのリポジトリの内容を反映させたり、逆にサーバ上のリポジトリの内容をローカルのリポジトリに反映させたりすることも出来ます。これを用いると、多人数開発等で非常に便利で、これこそがgitの便利な所ではあるのですが、ここについて詳しく書くのはこの記事の趣旨に沿わない上に、僕もそれほど詳しくないのでこの記事では書きません。もし機会があれば別の記事に起こしたいですね。気になる人はGitHub等について調べるといいかもしれません。

「分散型」の意味

ここではそれほど重要なことではないのですが、gitは「分散型バージョン管理システム」だと言ったので分散型の部分も説明しておこうと思います。どうでもいい人はここは読み飛ばしてもらって構いません。 まずそもそも、バージョン管理システムには、分散型でないもの、つまり集中型というものがあります。集中型バージョン管理システムとは、リポジトリはサーバーに1つであり、そこで直接バージョン管理をする、というシステムです。つまり、新しいバージョンが出来た時に、自分のPCにあるローカルなリポジトリにその情報を追加するのではなく、サーバ上のリポジトリに直接追加します。 これに対してgitでは、説明してきたとおりバージョン情報の追加は自分のPCにあるローカルなリポジトリに対して行います。サーバ上のリポジトリには、ローカルなリポジトリの内容を一部若しくは全部反映するという形でバージョン情報を追加したりするので、サーバ上のリポジトリに全てのバージョン情報があるわけではないという状態になります。このような管理の仕方をするものを分散型バージョン管理システムと言います。

gitの基本的な知識

はじめに

GUIで使えるようになろうといっても流石にgitの事がわかっていないのにツールの話ばかりしてもわかるようにはならないので、まずはgitの基本的な事について話そうと思います。ただし、恐らく使いながら慣れたほうが良いと思うので、それなりに細かく書くつもりではいますが、イメージさえ掴めたらここで全てを理解しようとせず次に進んで構いません。 ここではGUIを想定しているので、コマンドという言い方よりも機能という言い方を採用します。

repository(リポジトリ)

先程軽く説明して、ここまでの説明でも使ってきましたが、念の為確認しておきましょう。リポジトリとはバージョン管理情報を入れておく入れ物の事です。もう少し具体的に言うと、ソースやファイルの状態について、保持しておくファイル(群)の事を指します。gitではまず最初にこの入れ物を作ってから、そこにデータを追加していったりする形でバージョン管理を行っていきます。

commit(コミット)

一番よく使うことになるであろう機能がこのコミットです。何をする機能かというと、ゲームで言うとセーブをする機能です。つまりはリポジトリにコードの変更について保存します。

どうやって管理してるの?

gitはセーブをしたり出来るといって、commitについて先程書きましたが、gitはその時のソースコード等の情報を保存しているのではありません。commitによって保存されるのは、commit時の情報ではなく、前回までのcommitから導かれる前回のソースコードと、現在のソースコードとの差分です。 ゲームに例えてみましょう。RPGポーションを初めから3つ持っているとして、その状態でまずセーブがされているとします。そのあと、ポーションの数が4つになったとして、そこでセーブします。ゲーム等であれば大体「ポーションの数が4つである」というのを元のセーブデータに上書き保存する形でセーブすると思います。 しかし、gitでは「ポーションの数が1つ増えた」という情報をコミットすることになります。これによって

という情報から辿っていって現在のポーションの数を4つだ、と認識するわけですね。これをソースコードでもやるわけです。例えば

#include <stdio.h>
int main() {
     printf("Hello World\n");
     return 0;
}

というデータが既にcommit等を済ませた状態であるとして、

#include <stdio.h>
int main() {
     printf("Good Night World\n");
     return 0;
}

と書き換えた場合、commitをすると、リポジトリにはこのコードが保存されるのではなく、 「3行目の『 printf(“Hello World\n”);』が『 printf(“Good Night World\n”);』に書き換えられた」 という情報がリポジトリに保存されるわけです。(厳密に言うと「書き換えられた」と言うのは違う気がしますが、ここでは分かりやすさを優先します)

これを繰り返していってバージョンを管理する訳なので、gitは変更情報(差分)を連ねて保持してくれるシステムとも捉えることが出来ます。

branch(ブランチ)

ブランチというのは、ゲームで例えるとセーブスロットと考えると良いかもしれません。もしくは、世界線と考えると少しわかりやすいかも知れないですね。gitは変更情報を連ねて保持してくれるシステムとさっき言いましたが、このブランチというのはその連なりの分岐を作る機能なのです。ただ、ここで注意しておかなければならないのは、ブランチは分岐を作成・管理するのに使われるものの、ブランチそのものは直接分岐を作成するというよりも、commitの連なりやその分岐の中で現在どこにいるかというのを示す機能でもあるという事です。 ゲームの例で見てみましょう。世にいうギャルゲー、つまり恋愛シミュレーションゲームを考えます。あの手のゲームは所謂攻略対象としてヒロインが設定されているのですが、1周のプレイでは誰か1人を攻略することになると思います(自分はギャルゲーに詳しくはないので、本当にそうなのか!?と詰め寄られると困りますが、ここではそう考えます)。例えば、クリスマスに誰をデートに誘うか、というベタベタの選択肢があったとしてAさんとBさんがその候補にあがったとしましょう。この場合、素直にやるのであれば、まずAさんを誘って攻略を進めた後、また最初からやり直してBさんを攻略します。しかし、このクリスマスイベントまでは同じ手順を辿るのであれば、わざわざ二度も行うのは面倒ですよね。そこで考えられるのが、セーブです。セーブスロット1ではAさんを誘って、セーブスロット2ではBさんを誘う、そして最後には、セーブスロット1ではAさんを、セーブスロット2ではBさんを攻略します。 さて、プログラミングの話に戻りましょう。ソフトウェアの開発では、複数のメンバーが同時に機能の追加や、バグ修正を行ったりすることがあります。また、複数のリリースバージョンが存在し、そのそれぞれを保守しなければならないといったこともあります。こういった場合に役に立つのがブランチです。上記のセーブスロットの例の様に、例えばブランチ「bug_fix」ではバグの修正を、ブランチ「add_enemy」では敵の追加を、と言った風に、依存性の無い機能をそれぞれ平行に管理することが可能になります。この機能のメリットは、次に紹介するmerge(マージ)を含めての部分が多いのですが、そうでなくとも、ブランチについた名前から、そのブランチに属するcommit達が何をする為にされたものなのかを推測する事ができるという利点があります。とある機能についてのコードしか書かない、と決めていたら良いのですが、バグに気付いたら修正したくなるものですよね。かといって敵の実装の一部→バグ修正→敵の実装の一部という風にコミットされているとあとで見直す時に見にくくなってしまいます。しかしブランチを分けて置くことによって、いつでも当該部分についてcommitをすることができるようになるのです。

merge(マージ)

mergeというのは、分岐を再び統合する処理です。gitはその時のコードではなく変更についての情報を保持しているとさっき言いました。そして、その変更情報の連なったものは、分岐してbranch等を通して意味のあるかたまりとして捉えることができました(例えばバグ修正、など)。つまりは、元の情報に変更情報を1つずつ適用していけば、現在の情報が導ける訳です。となると、とある所で分岐したブランチについて、その元は同じであるがゆえに、ある変更情報の連なりに、別の変更情報の連なりを反映する、といったことも可能になります。このようにして、一度分岐した変更のかたまりを、再度統合する処理がmergeです。(以下、便宜上変更情報の連なりをブランチと表現します) しかし、このmergeはいつでもうまくいくとは限りません。あるブランチに別のブランチをマージしようとしたとき、それぞれの変更内容が矛盾してしまった場合、gitはそのどちらを採用すれば良いのかわからないのです。これをconflict(コンフリクト/衝突)と言います。コンフリクトが起きた場合は、その矛盾を解消してやらなければなりません。 具体的にどの様な時にコンフリクトするのでしょう。例えば、

#include <stdio.h>
int main() {
     printf("Hello World\n");
     return 0;
}

というコードに対して、ブランチ「night」では

#include <stdio.h>
int main() {
     printf("Good Night World\n");
     return 0;
}

と、3行目を書き換えてcommitしているのに対して、ブランチ「leave」では

#include <stdio.h>
int main() {
     printf("See You World\n");
     return 0;
}

と3行目を書き換えている事を考えましょう。 この時、3行目について、それぞれのブランチでは「 printf(“Good Night World\n”);」と「 printf(“See You World\n”);」という変更がなされています。この状態でどちらかのブランチにもう一方を統合することを考えてみたらどうでしょう。gitは3行目をどちらにすればいいかわかりませんね。ここでコンフリクトが生じます。 では、「wanna_know_name」というブランチがあって

#include <stdio.h>
int main() {
     printf("Hello World\n");
     printf("What's your name?\n");
     return 0;
}

こういった風になっているとします。元のHello Worldと比較すると、変更分は3行目と4行目の間に「 printf(“What’s your name?\n”);」が追加されたになります。これを「night」ブランチにマージしたらどうなるでしょうか? この場合変更分は、

  • 3行目と4行目の間に「 printf(“What’s your name?\n”);」を追加
  • 「 printf(“Good Night World\n”);」を追加

の2つなので、矛盾することなく、マージ後のコードは

#include <stdio.h>
int main() {
     printf("Good Night World\n");
     printf("What's your name?\n");
     return 0;
}

になります。

checkout(チェックアウト)

コミットは変更の積み重ね、ブランチは変更について分岐したもの、というのは話しましたが、となると今自分がどこに居るのでしょう?「そりゃ最新のコミットでしょ」と思うかもしれませんが、ブランチがいくつもあったら?また、今までゲームで例えた場合のセーブについて話してきましたが、ロードはどうするのでしょう?あのブランチの最新のコミットの状態をロードしたい、となったらどうすれば良いのでしょうか。 それはともかく、gitは差分で情報を保持するといいました。となると、常に現在の最新コミットがどこで、その最新コミットに比べた差分を見るわけです。この最新コミットがどこにあるかというのは何を基準に見て居るのでしょうか。 この二つの問いに対する答えはcheckout(チェックアウト)という機能を見ることで見えてきます。 チェックアウトとは、現在の作業ブランチを変更する機能です。またゲームの喩えをすると、選択しているセーブスロットを変更する機能になります。もっというと、別のセーブスロットをロードする機能、になります。 ブランチAからブランチBに移る場合「ブランチBにチェックアウトする」といいます。「ブランチAからチェックアウトする」といいたくなりますが、こうは言わない様です。

導入

実践

gitを使うメリットと、基本的な機能などについては何となく掴んでもらえたと思うので、そろそろその使う準備をしようかと思います。まず、この記事においては上記の通りGUIでgitを使えるようになる事を目的としているので、そのツールの紹介からしましょう

SourceTree

使うツールはこちら、SourceTreeです。もしかしたらもっと良いツールがあるのかもしれませんが、僕が教えてもらって非常に簡単に使うことが出来るようになったという事や、使い続けてきて充分使えるレベルのソフトウェアだという事を僕がわかっているのでこちらのツールを使っていこうと思います。

インストール

こちらのサイトからSourceTreeをダウンロード、インストールしてください。基本的に無料で使えると思うのでその辺は心配しなくて良いと思います。インストールする際等にアカウントを作ることを求められるかもしれません。もし将来オンラインでソースコードを管理することを考えているのであればGitHubのアカウントを取得してそれを登録しておいても良いかもしれません。(この記事ではSourceTree Version 1.9.13.7を前提として話を進めます)

不親切

色々ともしかすると選択肢等が出てくるかと思いますが、その辺は読めばだいたいわかると思うのでがんばってください…

リポジトリの作成

gitを使うにはリポジトリをまず作る必要がありますのでリポジトリを作ってみましょう。とはいっても難しいことはありません。左上の「新規/クローンを作成する」をクリックします。するとウィンドウ内に小窓が開くので、そのタブの中で「リポジトリを作成」を押し、「保存先のパス」にプロジェクトのパスを指定して「作成」を押します。これでリポジトリが作れました。

コミットしてみる

さて、次はコミットです。本当はgitにはaddという機能があって、gitで管理するファイルをこのコマンドで追加するのですが、Sourcetreeでは、これを自動で認識してくれるので、何も考えずコミットをすれば良いです。 コミットの仕方も簡単で、上の「コミット」ボタンを押して、コミット画面を開きます。変更点があるファイルが下側に表示されるので、コミットしたいものを選んで「Stage selected」を押すか、「Stage All」を押して、変更をステージします。変更をステージする、とは、変更を今回のコミットに含むと言うことを意味します。変更をステージできたら、下のメッセージボックスにコミットに関するコメントを書いて、右下のボタンを押すか、ctrl+Enterを押すだけでコミットは終了です。

ブランチを切る

ブランチを切る、とはブランチを作ることです。ブランチを作る、つまり新しい世界線・セーブスロットを作るのさえ、難しいことではありません。上にある「ブランチ」ボタンを押して、出てきた小窓に新しいブランチの名前を入力し、決定ボタンを押すだけです。

マージする

マージをしたい場合にも、またも上にあるマージボタンを押すのですが、この時に少し注意があります。それは、統合したい先のブランチにチェックアウトした状態でマージを押す必要があるということです。統合元ではないのです。 つまり、ブランチAにブランチBの変更を適用する(統合する=マージする)場合、ブランチAにチェックアウトした上でマージボタンを押す必要があります。 マージボタンを押すと、マージするコミットを選ぶよう言われます。マージしたいブランチの最新コミットを選択して右下の決定を押せば、自動でマージが行われます。 コンフリクトが発生した場合はダイアログが開くので、説明に従いながら衝突を解決してください。

現在のブランチを指定したコミットに移動させる

もう大体話したのですが、たまに便利なのを紹介しておくと、ブランチの現在位置を変更する機能があります。後から「うまくいかない原因を比較検証するためにあの状態からこの機能を実装してみたい」と言った時に過去のコミットに戻れる機能になります。これもいわばゲームでいうロードに近いですね。 やり方は、戻りたい先のコミットを指定して右クリックから「現在のブランチをこのコミットまでリセット」を選択するだけです。選択すると「Mixed」「Hard」など、どの設定で移動するかを聞かれますが、大体Mixedで問題ないでしょう。こいつらがなにかというと、ブランチの現在のコミットに合わせて、コードの方も変更するかという選択肢です。 オンラインリポジトリを使うようになるとこいつのせいで変に整合性が取れなくなることもあるので注意して使いましょう。

gitignore

地味に大事なのがこのgitignoreです。何かというと、変更を検知しないファイルをリスト形式で定義できるものになります。 例えば、コンパイルするたびに生成される.exeファイルや、VisualStudioを使っているのであれば、ソリューションについて更新があるたびに変更される.slnファイル等、定期的に変更が入り、かつ別にそれをコミットしたくはないというオブジェクトがあったりすると思います。これを検知せず、つまりはコミットの対象から外す様に設定できるのがgitignoreです。実際にはこれはgitignore.txt(ここでは名前が違うかもしれませんが気にしないでください)を編集することで行います。どこからそのgitignore.txtを開けるのかというと、まずSourceTreeのウィンドウメニューのツール->オプションを選択してオプションウィンドウを開きます。ここでGitのタブを選択し、「グローバル無視リスト」とある行の一番右の「ファイルの編集」をクリックすることで開けます。これは名前の通り全体に効果のある無視リストになります。ローカル環境でのみ無視するには.git/info/excludeを編集するという手がありますが、これは入門の範囲で扱う必要はないと思うので、必要であれば調べてみてください。
さて、gitignoreの中にどうやって更新を無視するファイルを定義するかですが例えばこのように行います。

#ignore thumbnails created by windows
Thumbs.db
#Ignore files build by Visual Studio
*.obj
*.exe
*.pdb
*.user
*.aps
*.pch
*.vspscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.cache
*.ilk
*.log
*.dll
*.lib
*.sbr

簡単に書くと

  • #で始まる行はコメント
  • *.[拡張子]の場合、その拡張子のファイルすべてが無視される
  • 特定のフォルダ以下を無視したい場合は"folder_name/"

という感じです。

詳しくはこことかここあたりを参考にするか、「gitignore 書き方」とかでググれば出てくると思います。

総括

gitについて

さて、グダグダな説明になってしまいましたが、みなさんgitのイメージは掴めたでしょうか。もし、この有用性にまでイメージを膨らませることが出来たのであれば、あなたは今日からでもgitを使うべきでしょう。 gitにはここで紹介していない機能や、その本領を発揮するオンラインリポジトリについて等、まだまだ強い機能が沢山あります。それらについて皆さんの興味をひくことが出来たなら幸いです。

その他ページ

gitの学習をするにあたって、役に立ちそうなページを紹介しておきます

  • サルでもわかるGit入門
    有名どころ。なんだかんだ忘れた時にみるのはここな気がする。一通り書いてある気がするのでここを見てやるのは普通にアリ。

  • LearnGitBranching
    めっちゃ便利なサイト実戦形式でブラウザ上でコマンドを打ちながらgitについて学べる。CUIも気になる人には特におすすめ

  • こわくないGit
    スライドでGitの原理等から色んな機能に触れてくれる。非常に分かりやすい。スライドなのでとっかかりやすい。

  • チーム開発に必要なGitコマンドを神速で習得しよう! 
    そういえば殆どここにまとまってたななんて今更思い出した。個人使用に慣れてきて、オンラインリポジトリでの多人数開発したいってなったら見るといいかも。

最後に

gitも他の技術同様、実際に使ってみるのがその理解には早いと思います。しかし、バージョン管理という大枠の重要な位置を占める機能であるが故、少しのミスでデータをすべて飛ばす可能性も否定はできません。バージョン管理システムを導入しようとしているのに皮肉な話ではあるのですが、最初の慣れないうちは、プロジェクトのバックアップを手動でとっておくことをおすすめします。ただし、gitはそんなにこわいものではないので、恐れずに使って見てほしいなと思います。 それでは、これを読んだ方がgitの恩恵を受けられることを願っています。

就活について 準備編

はじめに

こんにちは、いなえです。

なんとか就活を終え、とりあえず一息ついたという感じです。 というわけで、多くの人が苦しめられる就活において、少しでも楽に出来ればと思い、記事にしようかと思いました。

最近記事を書いてなかったからとかではないです。ええ。

準備編とか書きましたが現時点でなんか面倒になってきてるのでこれで途絶えるかもしれません。

今回は、主にその就活を実際に始めるにあたっての準備をする段階の話をしようと思います。

準備とはいっても、「インターンに行け」だの「ボランティアをしろ」だの「バイトはしておけ」だのといった、そういう就活アピールに向けた準備ではなく、就職活動がやりやすくなるような準備の事です。

多くの人は自分でやり方を見つけていくんでしょうが、就活が始まるとその試行錯誤にもおそらくメンタルを削られることになると思うので、脳死でこれに倣うのもアリではと思っています。 取り敢えず、参考までに見てもらえれば幸いです。

情報の整理

就職活動において、大切かつ一番面倒なものとして、情報収集があります。
就職活動が始まったからといって企業から勝手に情報が来る、というものでもありません。おそらくほとんどの人がリクナビマイナビといったサイトに嫌々登録し、その中で企業を探し、エントリーをしていくことになると思います。初めの方こそ問題はないのですが、だんだんたくさんある情報を整理するのが面倒になってくると思います。後からやり方を変えようとすると無駄に労力がかかったりするので、適当に始めるよりはこういった方法を取ったほうが良いのではないかと思います。

ソフトウェア的な部分

メールアドレス

就活を始めるとわかるのですが、多くのサイトは登録を要求してきますが、その際に通知を飛ばすメールアドレスを要求されます。
また、何か連絡がある度にマイナビリクナビからメールが届きます。一番使っているアドレスで登録するのが、メールを見ずに重要な連絡(例えば面接の日程の打診など)を見逃す可能性はないのですが、おそらく一番使っているアドレスは、他のメールも来るため、就活関係のメールとそうでないメールが混ざってしまい、後々就活関係だけ見たい時に面倒だったり、多くメールが来ると就活関係の大切なメールが流れてしまったりすると思います。

それを防ぐために、僕は就活専用のメールアドレスを取っておくことを推奨します。

加えて、その中でもGmailのアドレスを取得することをオススメしておきます。

gmailを取得する際にgoogleアカウントが使われますが、これが色々と便利なためです。また、スマホでもPCやタブレットでも確認できるという意味でも、キャリアメールを使うよりもこういったフリーメールを使ったほうが良いのではないかと思います。これは後で話すカレンダー等についても同じです。

カレンダー

就活で一番まずいのは、参加予定の説明会をドタキャンすることになってしまったり、行けると言った日程で面接がバッティングしたりということです。
場合によっては選考それ自体に響きかねないミスはなくしたいですよね。普通ならそんなことほぼないと思うのですが、時期によっては予定がすごい勢いで入ってきて、脳みそだけだと管理できなくなってきます。おとなしくカレンダーを使いましょう。

さて、その上でどれを使えば良いのかですが、僕は先程取ったGmailアカウントでのGoogleカレンダーを使うことをオススメします。コヤツは、スマホのカレンダーに追加しておくと自動で同期を取ってくれるので、PCからもスマホからも予定が見れる上に、追加削除ができるという優れものです。iPhoneでそういったことが出来たのできっとAndroidでも出来ると思います(開発元的な意味で)。

スプレッドシート

Gmailアカウントを使ったサービスについて2つ来たので、流れでいってしまいます。

就活が始まると、特に解禁時期から暫くは、「何処の企業にエントリーしたか」とか「何処の企業がどこまで選考がすすんでいるか」等がわかりにくくなります。勿論リクナビマイナビからエントリーしたのであれば、(UIが壊滅的に悪いので探すのに苦労する可能性があるのは否定しませんが)企業ごとのそれらについては見ることは出来ます。ただし、パッと見て全体の状態は掴めません。
また、リクナビマイナビの両方に載せている企業は、自分がどちらからエントリーしたのかわからなくて困ることがあります。

こういった情報をまとめる方法はいくつかありますが、僕はGoogleスプレッドシートでまとめました。これは所謂Excelの様なものなのです。「じゃあExcelでいいじゃん」となると思いますが、Googleスプレッドシートの利点は今までも何度も言ってきた通りスマホでもPCででも見れるし編集できるところにあります。

このGoogleスプレッドシートというのは、Googleドライブ(Googleが提供しているクラウドサービスと認識してください)上で作成できます。ブラウザ上で編集が可能で、GoogleドライブもGoogleスプレッドシートも、Gmailアカウントを持っていれば無料で利用可能です。Excelと比べると、操作が違ったり、機能が少なかったりしますが、就活の情報をまとめる程度ならこれで充分でした。

僕は一番上の行に、

  • 企業名
  • 志望度
  • 説明会参加日
  • 履歴書締め切り日
  • 筆記or適性試験
  • ES提出締め切り日
  • 一次面接日程
  • 二次面接日程
  • マイページ登録の是非
  • マイページID
  • 経由したサービス
  • 備考
  • マイページURL
  • 応募情報URL

と言った感じで書いておいて、その下の行に企業ごとに色々と書き込んでました。参考までに。自分でいい方法を模索してみてください。

後は、交通費が非常にかさむのでそれを記録していたりしました。色々自動化出来るので楽ですね。

EverNote

説明会や面接など、メールで会場や日時についての連絡が来れば先程のGmailで確認すれば良いのですが、例えば、企業が自社ページを持っていて、「そこに詳細置いておくから見てね」形式だったり、リクナビマイナビに連絡が来るタイプの場合、サッと確認したい時にログインを要求されて面倒だったり、電波の入りにくいところにいる時に開けなかったりして不便です。

そこでEverNoteを活用する事をオススメします。

これは簡単に言うとクラウドメモ帳サービス的な感じなのですが、画像も使えたり、何ならその画像に加工もできたりと実は多機能だったりします。ブラウザに表示されている内容を選択して貼り付けると、そのままの感じで貼り付けてくれます。これを使って自社ページの面接の詳細案内を貼り付けておけば、確認したい時に、IDやPasswordを忘れていても、電波が入らないところに居ても*1すぐに確認できます。
マップで位置を示した画像なんかがあったりしてもそれもコピーしてくれたりするので、そういった点で普通のメモ帳を使うよりも良いと思います。

また、最初は特に忘れがちですが、ESを残しておくのにもEverNoteは有効です。面接などではESの内容を元に色々なことを聞かれたりします。そのESの内容がわからなければ、面接で何を聞かれそうか一切検討がつかず、準備もできません。どこまでESで書いたのかを把握しておくためにもESを残しておくのは重要です。
ESでなくても企業の自社ページのエントリー設問等もコピーアンドペーストするだけで非常に楽です。
また、ESで共通して聞かれる様な自己アピール等についてEverNoteにおいておけば、新しい会社のESを書く際も楽ですし、自己分析についても置いておけばESを書く助けになるかもしれません。
pdfファイルを貼り付けることも出来るので提出したOpenESをそのまま貼っておけるというのも楽ですね。

そしてくどいですが、これもスマホからもPCでからも使えるのも利点です。

交通系アプリ

特に僕が千葉住みという事もあるのですが、都心に出る機会が多くなるので、都内の鉄道周りに詳しいとか、そういう場合でなければ交通系アプリを入れておくのをオススメします。

結構色んな所に行くことになるので、初見の場所に面接の時間に間に合う様に行くというのは意外と神経を使います。当たり前でしょと思う人も多いと思いますが、念の為。

僕はYahoo!乗り換えに非常にお世話になりました。これはMyページに検索した乗換案内を保存したり出来るのでオススメです。

地図系アプリ

流石に殆どの人が入れてると思いますがこれも念の為。駅から遠い場所に行かないといけない事もあったりしますしね。僕はGoogleMapsにお世話になってました。

Twitter

情報収集の為(大嘘)

ハード的な部分

手帳

さっきカレンダーの話をしたので「えっ?」と思う人がいるかもしれませんが、一応用意しておいたほうが良いです。就活が行われるのは大抵は少しフォーマルな場ですし、スマホを取り出すのが憚られる場面というのもあると思います。何故か手帳なら取り出しても社会的に特に問題ないらしいのでこれは用意しておきましょう。

ただし、カレンダーアプリの予定と同期を取っておかないと予定を聞かれた時に困り、意味がありません。注意しましょう。

クリアファイル

こいつが意外と便利かつ重要です。安くてもいいので透明なやつを適当にエントリーする会社の数程度買っておきましょう。説明会や面接などで書類等を渡された時に1つのクリアファイルにまとめておくと非常に楽です。

A社の面接に行く前にA社の書類のすべて入ったクリアファイルを持っていけば、直前にA社のことについて確認できたりもします。

僕はこれをしやすくするために、説明会や面接などでのメモは手帳やメモ帳、ノートではなく、ルーズリーフに取っていました。そしてそれをクリアファイルに入れておけば、全てのアナログな情報は1社あたり1枚のクリアファイルの中に集約されるわけです。管理が楽ですね。

クリップボード

特に合同説明会などにおいて、机が無いという場面は多くあります。ノートやクリアファイルを下敷き代わりにしてもいいですが、僕はクリップボードを買っておくことをオススメします。何なら立ち見でもメモをとるのに困りません。

所謂画板に似たもので、殆どの人が見たことはあるかと思いますがわからなければググってください。

扇子

汗っかきな人は夏近くまで就活がのびるとスーツのせいで非常に困ったことになると思います。扇子やタオルを持ち歩くことは考えておいたほうが良いと思います。

携帯バッテリー

電車の中でスマホをいじるのであれば、あると安心。

スーツやビジネスバッグ等

買わない人はほとんど居ないと思いますが念の為。2着あると安心ですが、結局僕は2着買ったものの、1着しか使いませんでした。むしろ、一人暮らしならば、忙しい時は洗濯が面倒になってしまったりするので、中のカッターシャツは3枚はあったほうが良いんじゃないかと個人的に思います。

人的な部分

就活の話を出来る友達

志望する業界が同じだとなお嬉しいが、違ったとしても共通する一般的な情報が入ってくるのでいるとありがたい。ひとり何も知らず取り残されているかも…という不安は少なくとも小さくなる。Discordで鯖立てて情報交換とかも良いと思います。

まとめ

例によってまとめる能力が無いのでタラタラと駄文を連ねてしまいました。結論から言うと、

ということですね。何だ、僕もうまくまとめられるじゃん。

スマホとPCのどちらからでも見れるということは、思った以上にメリットなので、環境依存レスな感じで就活を進めていきましょう。

ということでお役に立てば良いですが今回はこんな感じで終了です。それでは。

*1:なんか本当は課金しないとローカルで保存されないらしいんですが、キャッシュに残ってるからか普通に見れる

結城 浩 氏著の『Java言語で学ぶ デザインパターン入門』を読んで

結城 浩 氏著の『増補改訂版 Java言語で学ぶデザインパターン入門』を読了しました。記録として、そして他の方の参考のために感想を書いておこうかと思います。

非常に読みやすくわかりやすく、いい本でした。勿論、概念的な部分があるので一度では読み込めず飲み込めない所もありましたが、こちらの理解を促そうとする工夫が要所に感じられ、そういった所も読んでいくことが出来ました。著者の結城浩さんの日本語が僕にとって非常に相性が良かったのか、はたまた誰が読んでもそうなのかはわかりませんが、説明が非常にわかりやすいです。自分にはこういった才能がないと思っているので羨ましい限りなのですが、短い簡潔な文でわかりやすく伝えるという事が非常にうまい方のようで、1文を読んで「あー、なるほど」と知識としてあるものの絡まっていたものが解けるような感覚を何度か味わいました。

ただ、本著の評価自体からは少し外れる話なのですが、自身の知識の再確認が多く(この書き方or考え方使っていたし知っていたけどこういう名前がついていたんだ、とか)、新規性自体は自分の中では大きくなかったです。しかし、その分インターフェースを始めとした色々な考え方の根底にあるものを復習しつつ、知らなかった情報を補足していく形で自分のものに出来たのではないかと思います(勿論、マスターには程遠いですが…)

逆に言うとこれをもっと早くに読んでいれば無駄な試行錯誤もなかったかな、と思います。付録Dにもあるように

デザインパターンが重要なのは、経験を積んだプログラマの知恵を効率良く学ぶことができるから

という事なので、恐らく必死に自分で最適な設計を考えていた時間でこれを読んでいたらもう少し時間がかからなかったのかな、と思います。

因みに言うと、僕は一度この本を途中で読むのをやめたことがあります。Template Methodがイマイチわからなかった、というのがその理由なのですが、当時よくプログラミングについてわかっていなかったことも有り、久々に読んでみるかと引っ張り出してくると、当時わからなかった所もスラスラ読めて楽しくなって全部読んでしまいました。

その上で、これを読むのに苦労している方が居たら言いたいのが、始めのUML図の説明をちゃんと読むこと、Template Methodはちゃんと理解すること、です。

前回よくわからなくて読むのをやめた時には、UML図の説明が面倒で適当に読み飛ばして読み始めてしまったのが原因だと思っています。今回は、応用情報技術者試験の勉強で出てきたことも有り抵抗がなかったのでちゃんと読んだらUML図がきちんと読めるようになって非常に理解が楽になりました。

また、3章Template Methodについては(というか全てのパターンについてなのですが)、わかってしまえば難しいことはないものなので、しっかり理解に努めましょう。そこでインターフェースやsubclass responsibility等についてしっかり理解しておけば、あとは個人的にはそのマイナーチェンジと言うか、やりたいことややり方を変えたバージョンで通底する考え方は似通っているという風に感じたので、恐らくそれほど理解は大変ではないと思います。勿論量が量なので時間はかかるとは思うのですが…

後もう一つ言うことがあるとすると、厳密にわかろうとするより、概念や考え方を理解しようとした方が簡単に読んでいけると思います。何故こういったことをするのか、という話は大体章の終わりの方に解説として載っているので、よくわからなくても章を通して取り敢えず読んでみる、という読み方を個人的にはオススメします。

僕はJavaは過去に1度、非常に簡単なゲーム的なものを作るのにしか使ったことがなく、時間で言うと3時間も触ったことがなく、詳しく言語仕様は知らなかったのですが、C++オブジェクト指向プログラミングをしている人であれば何の問題もなく読めると思います。Java言語で学ぶ、とあたかもJava言語は前提知識かのように書いている割には説明もあったりしたので、プログラミングをしている人なら読めるのではないかと思います。

ただし、勿論とっても簡単、と言うものではないです。ただし、この本を読んで得られるものが多いのは僕は初学者だと思うので、チャレンジしてみることはオススメします。わからなければ少し寝かせておけば良いのです(それこそ僕のように)。いつかわかる日が来て、読めるようになる、と考えて、今はどうせ読めないだろうけど、位の気持ちで読み始めるのが良いのではないでしょうか。

DXライブラリでasserionマクロを使えるようにする

C言語にはassertという関数がある。

詳細は(ここらへん)http://www.c-tipsref.com/reference/assert/assert.htmlを見たりググったりして欲しい。

これは簡単に言ってしまえばプログラマの意図を記述するのに使われる。

例えば、除算を定義する際にゼロ除算を除きたい場合は、assert(割る数!=0)と書いておくと、間違って0で割ってしまった時にそこでプログラムを強制終了して、「割る数!=0が満たされてないよ?」的なメッセージを出してくれる。

さて、これをDXライブラリでも使えるようにしたい。assert関数を使えば良いんじゃないの?と思うかもしれないが、assert関数はプログラムをその場で強制終了する。つまりはDxLib_End関数が最後に呼ばれず、場合によっては変にプロセスが残ったままになってしまう。

解決策として、適当なプログラム全体の管理クラス的なものを作って、そいつのデストラクタにDxLib_End関数を書けば良いのではないか、と思うかもしれないがそうも行かないらしい。assert関数が呼ばれた場合はデストラクタも呼ばれないらしいのだ。

さて、ということで自作assertだ。単にラップすれば良いんじゃないの(=Adopterパターンでなんとかなるんじゃないの)と思うかもしれないが、せっかくなので多少使いやすいものを作りたいと思ってしまった。

そして出来たのが以下である。

assertDx.h

//
//assert
//

//assertionマクロ。こっちをつかう。
//意図していない部分や、ファイル名、何行目か等の情報が得られる。
#define assertDx(assertion) AssertDx(assertion,#assertion,__FILE__,__LINE__,__FUNCTION__)

//assertionマクロ。こっちをつかう。
//意図していない部分や、ファイル名、何行目か等の情報が得られる。
//デバッグ用に情報(std::string)を1つ埋め込める
#define assertDxInfo(assertion,info) AssertDx(assertion,#assertion,__FILE__,__LINE__,__FUNCTION__,info)


//マクロが実際に動く時の中身の関数。こちらではなくassertDxを使う
void AssertDx(bool assert_bool, std::string assert_tex, std::string file, int line, std::string func);

//マクロが実際に動く時の中身の関数。こちらではなくassertDxを使う
//デバッグ用に情報を1つ埋め込める
void AssertDx(bool assert_bool, std::string assert_tex, std::string file, int line, std::string func, std::string info);

assertDx.cpp


//マクロが実際に動く時の中身の関数。こちらではなくassertDxを使う
void AssertDx(bool assert_bool, std::string assert_tex, std::string file, int line, std::string func) {
    if (assert_bool == false) {
        //意図しない動作をしている旨を表示
        MessageBox(NULL, (
            "Assertion failed: \"" + assert_tex +
            "\",\n File:" + file
            + ",\n Line:" + std::to_string(line)
            + ",\n In Function:" + func
            ).c_str()
            , "Assertion failed", MB_OK | MB_ICONSTOP);

        DxLib_End();// DXライブラリ使用の終了処理
        exit(-1);//-1を渡して終了する。
    }
}


//マクロが実際に動く時の中身の関数。こちらではなくassertDxを使う
void AssertDx(bool assert_bool, std::string assert_tex, std::string file, int line, std::string func, std::string info) {
    if (assert_bool == false) {
        //意図しない動作をしている旨を表示
        MessageBox(NULL, (
            "Assertion failed: \"" + assert_tex +
            "\",\n File:" + file
            + ",\n Line:" + std::to_string(line)
            + ",\n In Function:" + func
            + ",\n Infomation:" + info
            ).c_str()
            , "Assertion failed", MB_OK | MB_ICONSTOP);

        DxLib_End();// DXライブラリ使用の終了処理
        exit(-1);//-1を渡して終了する。
    }
}

正直申し上げてよく分からず書いているところがある(特にWinAPI周り)ので動作については保証できないが、一応こんな感じで良い感じに動く。

使い方としては

//読み込みに失敗していない
    assertDxInfo(load_result != -1, handle_name);

として読み込みが失敗しているのにプログラムがそのまま動くのを阻止したりと言った風に使う。(ちなみにこのassertDxInfo関数は、assertion警告が出る時に追加表示する情報を付加できる)

改善点はまだまだありそうだが、今のところ実用に耐えているっぽいので(そもそもそんなに引っかからないので本当に耐えているのかは不明)これでいいかな、という感じだ。

そしてここに晒すことによってマズイ所を指摘してもらえて改善できるのではないかと淡い期待をしているので、何か気付いたことがあったら教えていただけると嬉しい。

変数を簡易に表示する

デバッグをする際に組み込み変数を簡単に表示したい事があると思うのだが、わざわざ毎回

int hoge = 5;
printf("hoge:%d\n", hoge);

みたいなのを書いてたのだけど、"hoge:%d\n"は予測補完効かないし、毎回書くのは地味に面倒だなあと思っていたのでその辺を簡単に書ける関数マクロを用意してみた。

説明するのも面倒なので取り敢えず以下にコードを示す。

printInstant.h

#pragma once
#include<string>

//debug用マクロこっちをつかう。
//渡した変数が簡易に表示される
#define printInstant(print_var) PrintInstant(#print_var,print_var)

//debug用マクロこっちをつかう。
//渡した変数が簡易に表示される。
//デバッグ用に情報(std::string)を1つ埋め込める
#define printInstantInfo(print_var,info) PrintInstant(#print_var,print_var,info)

int PrintInstant(std::string var_name, int var);

int PrintInstant(std::string var_name, double var);

int PrintInstant(std::string var_name, std::string var);

int PrintInstant(std::string var_name, int var, std::string info);

int PrintInstant(std::string var_name, double var, std::string info);

int PrintInstant(std::string var_name, std::string var, std::string info);

printInstant.cpp

#include"printInstant.h"
#include<stdio.h>

int PrintInstant(std::string var_name, int var) {
    return printf((var_name + " : %d\n").c_str(), var);
}

int PrintInstant(std::string var_name, double var) {
    return printf((var_name + " : %lf\n").c_str(), var);
}

int PrintInstant(std::string var_name, std::string var) {
    return printf((var_name + " : %s\n").c_str(), var.c_str());
}


int PrintInstant(std::string var_name, int var, std::string info) {
    return printf(("(" + info + ") " + var_name + " : %d\n").c_str(), var);
}

int PrintInstant(std::string var_name, double var, std::string info) {
    return printf(("(" + info + ") " + var_name + " : %lf\n").c_str(), var);
}

int PrintInstant(std::string var_name, std::string var, std::string info) {
    return printf(("(" + info + ") " + var_name + " : %s\n").c_str(), var.c_str());
}

使用方法としては

#include"printInstant.h"

int main() {
    int hoge = 5;

    printInstant(hoge);

    return 0;
}

出力

hoge : 5

みたいな感じでprintInstant(変数);と書いてやる。

printInstantInfoは付加情報を付けたい際に使う。

#include"printInstant.h"


int main() {
    int hoge = 5;

    printInstantInfo(hoge,"test now");

    return 0;
}

出力

(test now) hoge : 5

まとめ

C言語のマクロをちゃんと知っている人ならすぐに思いつくのだろうが、僕はあまりそのあたりに詳しくなかったので最近思いついて書いてみた。

今回はprintfprintfDxに書き換えればDXライブラリにも移植がし易いという理由でprintfで描画したが、勿論std::cout等でもいいと思う

わかりやすさのためにグローバルとして宣言したが、本当はもう少し隠蔽について考えたほうが良いのではないかと思う。