読者です 読者をやめる 読者になる 読者になる

エンジニアの箱

サーバ構築とか、Ciscoルータの設定とか、コーディングに関してのなにがしを書きます。

TypeCover4の英語配列を修理に出したら日本語配列になって戻ってきた件

放置しまくってたブログに久々に書くのがこれとは。まぁいいや。題名の通りです。

結論:泣き寝入りしかない

細かい経緯の方は後に書くとして、結論から書くと 日本では英語配列のサポートを受けられません。正確には、修理に出すと必ず日本語配列になって戻ってきます。残念ながら。理由は交換品として用意されているのが日本語配列しかないからだそう。 とりあえず下記経緯です。

経緯

TypeCover4のキーが一部反応しなくなる

3週間ほど前、TypeCoverを使っていたらキーが一部反応しなくなりました。一部です。トラックパッドは完全に無事、しかし数字の1とか2とかが入れられず、aやsなどは入れられる、みたいな状態に。TypeCoverは端子でつなぐので、端子部分が汚れていると反応しなくなることもあるそうで、アルコールを使って端子部分を掃除するもやはり治らず。

サポートへ電話、対応は○

ということで、交換してもらおうとサポートに電話。大体30分ぐらいかかったと思います。対応はとても丁寧でよかったです。いろいろやり取りをし、ゆうパックで送ることに。送るときはクッション性を高めて中身が壊れないように送らないといけないとのことで、プチプチで包んでAmazonの余っていた箱に詰めて送りました。

3日ほどで交換品届く、が…。

電話口では5営業日ぐらいかかるといっていましたが、発送してから3日ほどで受け取れました。対応としては割と早いのでは?と思います。が開けたら日本語配列っていう。まじかよ。

サポートに再度問い合わせるも…。

再度サポートに問い合わせるも、「交換品としては日本語配列のものしか用意していないようです。ごめんなさい。」みたいな回答が返ってきました。Microsoftの公式ホームページでも英語配列のものが売られている件について突っ込みましたが、結局回答は変わらず。正直ブチギレたかったですけどコールセンターの人は悪くないのでやめておきました。何回も調べさせてごめんなさい。代わりにここでキレます。

英語配列を購入した場合は、外れを引いたとき高くつく

これを覚えておきましょう。壊れた場合、買いなおす必要があります。私は残念なことに買いなおす財力が今現在はないので(2ヶ月ほど無職でした、のちのち記事に書きます)、日本語配列を代わりに使うしかないという感じ。ちなみにですが、いつも日本語配列のキーボードを使っている人には配列が違うとどうなるかいまいち伝わらないと思います。たとえるならば、利き腕と逆の腕で箸をもってご飯食べる感じです。ね?いやでしょ?

Microsoftさん、なんとかしてくださいよ!

これが言いたかっただけ系。公式で売るのであれば、サポートの方も体制を整えてほしいなぁと。公式で売るぐらいですので、ニーズはあるはず。特に私のような 形から入る変態にわかエンジニアは英語配列大好きな人が多いはず(ちなみににわかではなくガチの人では、Microsoftの中の人のちょまどさんがそうですね)。正直言ってしまえば、社会人で働いていたら2万ぐらいある程度融通が利く(ただしその月は冷や飯を食うことになりますが)ので別に大問題にはならないんでしょうが、それでもちょっと冷たい感じがしますよね。サポートセンターの人も、そもそも英語配列のキーボードが何かよくわかっていなかったようで、何度も調べさせてしまって本当に申し訳なかったです。しょうがないので今度は個人輸入でもして黒じゃない別の色のTypeCoverを買いますけど、なんだか納得は行かないですね。頼む。改善して。

最後に

頼む、改善して!って言ったらすぐ直るなんてことはまずないです。それなりに時間もかかるし、そもそもあっちこっちで声が上がらない限り、改善対象にはしづらいと思います(Microsoftはそのほかにも大量の仕事を持っているはずなので)。なのでこういうことを地道に書いたりレビューに起こすことが重要な気がします。以上です。

応用情報合格!やったね!資格が増えるよ!

雑記

キャァアアアアアアアアアアアアアアアアアアアアアアウカッタァアアアアアアァァアアアアアアアアアアアアアア!!

ということで応用情報受かりました!内訳はこんな感じです。

午前:78.75点
午後:72点

ということで、ビビってた割にはそこそこ余力がありつつ受かっているという。この。ちなみに今回受けるのは2回目です。

初めて受けたのはおととしの秋で、そこから1年半してようやくという。去年は受けたかったけど仕事が忙しすぎて受けられなかったっていうね。いやーほんとよかった。



以上

オブジェクト指向とは「抽象化」である

プログラミング オブジェクト指向

現在オブジェクト指向を再度勉強しなおしていて、「ああ、こういうことだな」っていう解を見つけた気がするので記事を書いています。なお、この記事は「プログラミング言語を用い、何か一つのアプリケーションを作り上げたことがある」人向けです。


タイトルの通り、オブジェクト指向とは抽象化を行なう概念です。我々は日々生活する中で無意識のうちに「抽象化」を行なっています。
例えば、漫画・技術書・文庫・雑誌、これらはすべて具体的な概念ですが、抽象的な概念に直すと「本」です。本の要素とは下記のとおりです。

  1. 開くことができる
  2. 閉じることができる
  3. ページめくりができる
  4. ページは紙でできている
  5. 文字もしくは絵(図)が書いてある
  6. 読むことができる
  7. 表紙がある
  8. タイトルがある
  9. 大きさがある程度限定される(大きさに種類がある)

こんなところでしょうか。これらの性質を持ったものを「本」と呼び、書いてある内容や大きさによって漫画・技術書・文庫・雑誌など呼び方が変わります。さらに、漫画・技術書・文庫・雑誌も実は抽象的な概念であり、実際は「ドラゴンボール」・「オブジェクト指向における再利用のためのデザインパターン」・「レ・ミゼラブル」・「日経ソフトウェア7月号」などが具体的な概念となります。これは階層的に表すことができます。


├漫画
│└ドラゴンボール
├技術書
│└オブジェクト指向における再利用のためのデザインパターン
├文庫
│└レ・ミゼラブル
└雑誌
 └日経ソフトウェア7月号

このように無意識のうちに抽象化を行ない、「ドラゴンボールがほしい」となればそれは本であるから本屋に行き、なおかつ本屋の中でも漫画コーナーを探す、という行為につながります。またドラゴンボールを読むときはドラゴンボールを開き、読み、ページをめくり…といった動作を行ないます。これはドラゴンボールでもレ・ミゼラブルでも同じことです。漫画と文庫は同じ本であるために同じ使い方をすることができます。

ここまではさも当たり前のことを書きましたが、実はこれがすごく重要です。抽象化されることにより、「漫画」の使い方を覚える必要がないということです。「本」の使い方さえ知っていれば「漫画」の使い方をいちいち学習する必要はありません。もっと言うと、「本」の使い方さえ知っていれば「ドラゴンボール」の使い方を覚える必要がないということです。技術書・文庫・雑誌においても同じことです。これこそが抽象化の威力です。もしも人間が抽象化という概念を理解できなかった場合、「ドラゴンボール」を購入したら「ドラゴンボール」の読み方を習得しなければなりません。そして「テニスの王子様」を購入したら「テニスの王子様」の読み方を習得しなければならないのです。


さて、ここまでは概念の話でした。これをプログラミングに落してみましょう。

public class Book
{
    // タイトル
    public String title { get; private set; }
    // 大きさ
    public String sizeType { get; private set; }


    // コンストラクタ
    public Book(String iTitle, String iSizeType)
    {
        this.title = iTitle;
        this.sizeType = iSizeType;
    }

    // 本を開くメソッド
    public void Open()
    {
        // 本を開く処理
    }

    // 本を閉じるメソッド
    public void Close()
    {
        // 本を閉じる処理
    }

    // 対象ページまで移動する(ページめくりを行なう)メソッド
    public void TurnPage(int pageNumber)
    {
        // ページをめくる処理
    }

    // 現在開いているページの内容をPageContentsオブジェクトとして取得するメソッド
    public PageContents Read()
    {
        PageContents pageContents = new PageContents();
        // ページの内容(PageContents)を取得する処理
        return pageContents;
    }
}

これが本オブジェクトですね。続いて漫画です。

public class Comic : Book
{
    // コンストラクタ
    public Comic(String iTitle, String iSizeType) : base(iTitle, iSizeType)
    {
    }
}

そして最終的に、インスタンス化しオブジェクトを操作します。

static void Main(string[] args)
{
    Comic DragonBall = new Comic("ドラゴンボール", "文庫版");

    DragonBall.Open();
    PageContents pageContents = DragonBall.Read();
    DragonBall.Close();
}

もうお分かりだと思いますが、Bookクラスの使い方さえ分かっていればDragonBallオブジェクトの使い方はおのずと分かるわけです。もちろんコーディングの仕方によってはその関係を壊すこともできます。ですが、基本的にはスーパークラスがBookクラスである以上、DragonBallオブジェクトはBookクラスの使い方に準拠されるわけです。つまりDragonBallオブジェクトを抽象的にBookクラスとして理解してコーディングができるというわけです。


私自身オブジェクト指向について勉強中ということもあり若干「?」な部分もあるかと思いますが、言いたいことは「抽象化」です。コーディングをする際にメソッドに処理を切り分ける行為も抽象化ですし、定数を作る行為も変数もデータ型も抽象化の一種です。その抽象化をより極めたのが「オブジェクト指向」であると言えると解釈しています。「もの」という最も抽象的な概念からどんどん具体化していって…ということであるからオブジェクト指向なのでは、ということです。よく巷にある「現実のものに即したほげほげ」みたいな説明は私にとってはいまいち分からず、どこが現実のものに即した考えなのかさっぱりだったのですが、最近この考え方をするようになってからかなり腹に落ちた感があります。恐らく「現実のもの」という指向ではなく、本当に「もの」指向であるということなのでしょう。ちなみにですが、「メッセージ」の概念については割愛しました。メッセージでやり取りをするという話も結局はメッセージという抽象的なインターフェイスによりオブジェクト間のやり取りを行なうって話なので、まずは抽象化について理解できていないとメッセージのやり取りっていうのも「?」って話になるので。カプセル化とか継承とか多態性も結局のところは抽象化の話だと思ってます。すべては抽象的にものを捉えるために、です。



最後になんで抽象化がプログラミングに取り込まれたのか、背景的なものを類推したので考察まで。プログラマないしSEであれば、コーディングを行なう機会は多いでしょう(特にプログラマはそれが生業ですし)。コーディングには絶対に起こりうる事態として2つあります(もっとあると思いますが代表格を書きます)。1つ目は仕様変更です。2つ目は同じようなコードを各所に実装することです。1つ目については、プログラムと言うのは全体の整合性を考えて書かれるものであるために、途中で仕様変更を行なうと必ず「ひずみ」が生じます。この「ひずみ」が大きくなることで、見通しの悪いコードができあがり、バグの温床となります。2つ目については、いわずもがな。コピペです。これは単独では問題がありませんが、1つ目が関わってくると最悪です。コピペで書いていた処理をすべて変更しなければならず、1つでも変更漏れがあろうものならたちまちバグと化します。これが小さなプロジェクトであればよいのですが、大きなプロジェクトでなおかつ実力がてんでバラバラのプログラマ・SEが関わっていると問題は複雑になります。
これらの問題を解決するためには、コードを抽象化し、上で書いたようなBookクラスを作るようにすればよいのでは、というのがオブジェクト指向誕生における経緯になるのではないかと思います。DragonBallオブジェクトに仕様変更があった場合、変更するのはBookクラスのみで済みます。さらに、他の箇所で使っているなにがしオブジェクトについてもBookクラスを変更すれば済む話です。これが抽象化の威力です。仕様変更に強くなるほか無駄なコードを埋め込む必要がなくなります。もちろん概念を正しく理解し正しくオブジェクト指向を使用していることが大前提にはなるほか、オブジェクト指向銀の弾丸ではないので100%の抽象化には至っていません(言語によるのかもしれません)。ですがこれを使用することでより我々の思考に近い形でコーディングを行なえることは間違いないでしょう。それが故にオブジェクト指向は誕生から40年以上も経過しているにも関わらずこれほど利用されている概念になっているのではないかと思います。

AWSのRDS for PostgreSQLにて設定できる項目と後から変更できる項目

AWS PostgreSQL RDS

なにが最初に設定できて、なにが後から変えられるのか一覧で見たいなーと思ったのでまとめました。
そのうちEC2もやりたいですが、EC2はいかんせん項目が多くて先になりそう。

新規変更復元
インスタンスの仕様
DBエンジン
ライセンスモデル
DBエンジンのバージョン ※1
マルチAZ配置
ストレージタイプ
ストレージ割り当て ※2
設定
DBインスタンス識別子
マスターユーザの名前
スターパスワード
ネットワーク&セキュリティ
VPC
サブネットグループ
パブリックアクセス可能
アベイラビリティゾーン
VPCセキュリティグループ※3
認証機関
データベースの設定
データベースの名前
データベースのポート
DBパラメータグループ
オプショングループ
タグをスナップショットへコピー
暗号化を有効
バックアップ
バックアップの保存期間
バックアップウィンドウ
モニタリング
拡張モニタリングを有効にする
モニタリングロール
詳細度
マイナーバージョン自動アップグレード
メンテナンスウィンドウ

※1 ダウングレードできない
※2 一度割り当てたら下げられない
※3 復元時には変更できず、必ず「default」に設定されます。つまり、復元後変更し忘れるとDBにアクセスできず無駄にはまる、なんてことも…。

それは究極のキーボード。

さて、究極のキーボードとは、なんでしょうか?

PFU Happy Hacking Keyboard Professional2 Type-S 白(英語配列)

PFU Happy Hacking Keyboard Professional2 Type-S 白(英語配列)

そうだね、HHKBだね。

HHKBHappy Hacking Keyboradは、

  1. 最上の打鍵感
  2. 最適化された配列
  3. 持ち運べるコンパクトさ
  4. ホームポジションから手を動かさずにフルサイズキーボードと同じ入力が可能

などから、一部のユーザから絶大な支持を集めているキーボードです。このキーボードを知らないプログラマはモグリである、といっても過言ではないこのキーボード。人気の理由はやはり、「打鍵感のよさ」と「最適化された配列」によるものでしょう。打鍵感のよさについては、同じく有名なキーボードである東プレのRealforceに使用されている「静電容量無接点方式」が使用されていて、折り紙付きの打鍵感です。そして最適化された配列。これにより、究極の使いやすさを生み出しています。

そんなHHKBですが、実は最近Bluetoothモデルが発売され話題になりました。ファン待望のBluetoothモデル。これは欲しい。欲しいぞ。Bluetooth化されたことにより、iPhoneiPadに使用できるようになった他、携帯性もより一層増し極上の使いやすさを発揮することでしょう。


プログラマにとってキーボードは命です。自分の使いやすいキーボードを使用するべきだと思います。生産性が全然変わります。決して回し者ではありませんが、せっかくBluetoothモデルが出たということなので布教せねばという記事でした。ちなみにBluetoothモデルの価格は29,700円だそうです。買えねぇ。

応用情報を受けてきたンゴ

その他 雑記

結論から言って、受かってそう。やったね!資格が増えるよ!(所有資格:MOS 2010 Word スペシャリスト、基本情報の2つ)
ちな、一回落ちてますw
まぁここは、受験日前日から書いていこうじゃまいか。

前日の夜

情けないことにテンションが上がって寝られない。御年24歳である。なんかわからないけど、寝られない。ううむ。


当日の朝

特にアラームはなっていないが目が覚める。ふと時計をみると、7時20分。7時にかけたはずのアラームが鳴っていない…!!おかげさまですっごく焦りました☆当然のことながら、朝飯を食い、地元のコンビニで昼食とチョコを購入し会場へ。

会場入り

場所を言ってしまうとなんというか身バレしそうなので伏せるが、最近の大学はすごいですね。私の出身大学も色々最近すごいですが、やはりどの大学もかなり設備を整えるもんですね。都内なのに広かった。前回の試験会場もべらぼうにデカかったですが…。

午前試験開始

何事もなく試験開始しました。が、俺氏あることに気づく。ペンを持ってる手が震えている。これは恐怖ではない。武者震いなのだ。

当然のことながら時間が余ったので途中退出。ここでテーブルとイスを確保できるかが、実は情報処理試験に受かる受からないのキモになっているのではないかと勝手に思っている。というのも、テーブルとイスを確保し、午後試験に向けて英気を養うことができるかできないかで、午後の頭の回転が全然違う。情報処理の試験は基本情報の試験を含め今回が4回目。基本情報2回、応用情報2回。一回目の基本情報の試験の時、過去問では80点以上取れていたので余裕で受かるやろーって受けに行ったら、昼飯を食いすぎたのとタバコ吸いに行っている間に席を取られまともに休息が取れなかったのとなどが相まって、午後眠くなり撃沈。この反省を生かし、昼飯はほどほどにして、エネルギーは甘いもので補うことにし、基本情報は2回目で受かりました。という経緯があったため、速攻でテーブルとイスを確保しに。幸いテーブルもイスも余っていたので、座ってゆっくり昼飯を食い、寝ました。こういうのも大事だと思います。ちなさすがに時間が余ったので、午前試験の答え合わせとかしてました。今回午前試験が難しかった印象があり(特にマネジメント・ストラテジ)、あまりに落しているようなら帰ってしまおうと思ったからです(なおこれも私の恒例行事です)。なんか取れてそうだったので、そのまま午後へ。

午後試験開始

いよいよ本番です。取った問題は、必須である情報セキュリティの他には、プログラミング、ネットワーク、データベース、情報システム開発です。プログラミング、ネットワーク、情報システム開発までは結構即決したのですが、データベースだけ決めあぐねてました。というのも、パッと見難しそうだったから(全然そんなことはなかった)です。

情報セキュリティ

a、b、c共に問題をまともに読まず解答。それぞれ(a TLS)、(b 踏み台)、(c ゼロデイ)と解答。この3問は自信があったのですが、解答速報を見るとaがSSLになっていますね、どのサイトも。これには私納得がいっていなくて、SSLはそもそも論としてネットスケープ社が開発した暗号化通信の方式で、「デファクトスタンダード」のはずなんですよ。その上SSLの最新バージョンであるSSLv3には深刻な脆弱性(POODLE)が指摘されており、脆弱性を回避するためにはSSLv3を使用せず、TLSv1.0以上を使用するしかありません。つまりSSLは事実上消滅したのと同義です。そしてTLSSSLを元にIETFが標準化を行なったものであり、問題文の「インターネット標準として利用されている(a)による暗号化通信を用いる。」に対する最適解はTLSのほかないと思い、TLSにした…んですが。これは本解答待ちですね。ちなみに、この問題を見て「えっちょっとまてよ、正確に書くならばSSL/TLSか?いやしかし4文字以下だから、じゃあHTTPS…あっ5文字だ、じゃあ上記の理由でTLSだな。」となりTLSと解答しています。他にTLSって書いた人はおらんのか…
他に迷ったところと言えば設問3の(1)ですね。これは解答速報も割れていますね。「Webサーバの構成情報の調査によって得られる、Webサーバを攻撃するために有用な、アプリケーションに関する情報を2つ挙げ、それぞれ7字以内」という問題ですが、1つは「バージョン情報」にしました。Apache然りTomcat然り、サーバのバージョン情報が割れると、そのバージョンに存在する脆弱性を突かれる恐れがあるため、インストールしてまず最初にバージョン情報を秘匿化しています。さらに、問題文に「アプリケーションに関する情報」とありますから、アプリケーションに関するバージョン情報ということで解答しました。2つ目なんですが…。実は全く答えが浮かびませんでした。というのも、「アプリケーションに関する情報」であることが前提で考えた場合、バージョン情報以外に思いつかなかったためです。「ソフト名」といった解答があったりするようですが、なんだか微妙な気がしますね。ちなみに真っ先に浮かんだもう一つの解答が「ポート番号」でした。ですが設問(2)でポートの件に触れているのでないかなーと思って除外してしまいました…。結局時間ぎりぎりまで空欄にし、迷った挙句もう分からないから適当に書いてしまえ、と「OS」などという斜め上の解答をしました。アプリケーションじゃねーじゃん。
結局自己採点でMAX16点、MIN12点に。情報セキュリティ、自信あったのになぁ…。

ネットワーク

冗長化の問題かぁ…ルーティングの問題よりましだけど、苦手だなーと思いつつ解く。ですが、ネットワークに関しては特にこれといってつまずく要素がありませんでした。特にどの設問でも悩むことなく自信を持って解答。
自己採点ではMAX、MIN共に20点。事前の午後問題の勉強ではかなり苦しんでいましたが(平均10点ぐらい)、今回は問題が簡単だったか?あとは多少なりともCISCOのルータを触ってたおかげで、VLANとか出てきてもテンパらず解くことが出来ました。

情報システム開発

なんというか、他に取れそうな大問が無くってですね…。残念ながらあまり記憶に残っていませんが、解きながら「あーこの大問多分10点ぐらいしか取れんわ」と思ってました。まぁ案の定…かと思いきや、こいつは振れ幅がありそうです。
自己採点ではMAX14点、MIN9点です。振れ幅があるのは、記述があってるかどうかってところですね。なんかあってそうな意味のことを書いた気がするけど正確には覚えてないです。あと、設問1のbで、確か「メールで顧客に商品の発送を通知する」って書いたんですが、大原の速報を見ると「画面で顧客に商品の発送を通知する」になっていたので、怪しいためMINの方は除外しました。ただこれに関しては、大原の速報が間違っていると思っていて、まず一般論として「商品の発送をWebサイトの画面上で顧客に通知する」というECサイトが無いと思っています。商品の発送はいつ行われるか分からない性質のものであることと、Webサイトはアクセスしなければ情報を見ることができないいわばプル型の情報発信形式です。一方、メールはプッシュ型の情報発信方式で、「いつ発送が行われるか分からないが、発送され次第メールで通知する」であればわざわざWebサイトを見る必要が無く、合理的です。Amazonもこの形式ですね。その上、問題の中の表3の「商品発送処理」の記述で「Webサイトは、配送センタに商品の発送を指示し、同時のメールで顧客に商品の発送を通知する。」とあります。このことより「画面」ではなく「メール」が正解になるのでは、と思っています。というか、発送されたかどうかわざわざWebサイトに見に行かないといけないってどないやねん…。

プログラミング

俺氏、全力でうなだれる。理由は2つ。1つ目は、ルールがようわからん。なんか結構難しいルールじゃないですか?これ。2つ目、例によって変数名がグズグズで、ソースコードがようわからん。aとかbとかcとかホント勘弁してください。本当はネットワークより先にプログラミング、情報システム開発より先にプログラミングを解く予定でしたが、以上の理由から後回しに。だってこれ難しいし…。と思いましたが、ちゃんと追ってみるとこいつ実は大したことがないと判明。一つずつ冷静に解答。というかあれだね。このライフゲームって普通に面白いね。
自己採点ではMAX20点、MIN18点でした。MINの方で18点になっている理由ですが、設問3のカで「temp[i]と1が等しい」みたいなアホ解答をしている可能性がある(記憶が無い)ため、引いてあります。多分、temp[c]って書いたはず…。

データベース

この時点で残り20分。ヤバい。でもデータベースも難しそう。(d)の解答ですが、おいおい、SELECT2つがFROMの中に入ってるぞ…。UNIONか?UNIONなのか?いやまて、過去問でUNION ALLとかもあったな…どっちだ!?!?!?とか勝手に混乱してましたが、普通にJOINでしたね。外側のSELECTでご丁寧にCOALESCE関数を使っているところを見ると、INNER JOINではないことが分かります。さらに、関数の中が(SS.日間販売数量, 0)となっているため、NULLになる可能性があるのは後ろにくっつけるテーブルの方だな、と分かるのでLEFT OUTER JOINでビンゴ。さらにAND句でつないでいる2つの(e)(f)は両社とも結合条件で、E-R図を見ると店舗IDと商品IDぐらいしかキーになるものがないのでこの2つと分かります。サービス問題でした。やらかしたのは、設問3です。売上年月にDESCつけ忘れたし…ざけんなし…平均在庫数量にはDESCつけたし…。時間が無かったとはいえクソみたいな凡ミスだったと反省しています。普段からSQL書いてないのバレるね。設問4の(2)は時間が無さ過ぎて書けませんでした。てきとーーーーーーーなこと書いた気がします。
自己採点ではMAX・MINともに15点ですかね。DESCの凡ミスさえなければ…。悔やまれます。

総括

Twitterで「俺、午後問題解き終わったら結婚するんだ…」などと盛大なフラグを立てていましたが、終わってみれば自己採点MAX85点、MIN74点の大健闘。時間が無くて問題用紙に解答を移せていないので記憶頼りなので怪しい点数ですが、まぁ大方70点ぐらいでしょう。あとは結果が6月17日らしいので、結果待ちですね。解答用紙に大問の○をつけ忘れたり、解答欄を1つずつ間違えたりしていなければ、受かっていると思います。ちなみに午前は78.75点で余裕通過です。こちらは問題用紙に答えを移している他、途中退出する前にマークシートの指さし確認をしているので間違いないです。
いやはや、1年目の秋に応用情報受けて撃沈、そこからまるっと1年間、実務が忙しすぎて勉強をする暇も試験を受ける暇もなく(申し込みして行けない系)。ですが、3月の胃カメラで萎縮性胃炎と診断され、大きな代償を支払って得た定時上がりを獲得。そして勉強し、臨んだこの試験。もちろんまだ油断はできませんが、受かっていそうで何よりです。正直この1年間要らん苦労をいっぱいしました。その結晶が胃カメラなんですけどね…。ですが諦めずコツコツと勉強していた甲斐がありました。本当に良かったです(フラグ)

書くことがなくなったZE☆

雑記

というのは本当は嘘で、書くことの内容自体はあるのですが、ついにIPAから赤紙(応用情報の受験用紙)が届きました。ということでブログを書いている場合じゃない。書いてるけど。応用情報受からないとなーと言いつつ普通に本読んだりするしホントなんて言うか勉強が嫌いです。まぁそんなこんななので、応用情報が終わるまで一旦休止しますよ。それまでにネタをあっためておきます。