2019年3日目: データベーススペシャリスト 午後対策(1)

ご挨拶

毎度ご覧頂きありがとうございます。Toshでございます。
ボチボチ過去問の午後問題を解いているので、表題のとおり午後の対策についてまとめようかと思います。

午後対策

1. 概要をざっくり読んで問題を選択する
2. 問題を読む
3. 概要を見直して、足りない部分や問われている部分を把握する

以上となります。

・・・これだけだと元も子もないので、もう少し掘り下げます。

データベース設計(ソフト寄りな設計)

大体出てくるのは概念データモデル、関係スキーマ(、ER図？)です。

概念データモデルはテーブルの関係を線で表すので、概要を見て足りないテーブルや線を追加していく感じですね。
書き方に関しましては「2019年2日目: 概念データモデル - 今日の知見」をご覧いただけますと幸いです。

関係スキーマはテーブルに必要な項目とキーを策定する部分なので、たいてい項目やキーの穴埋め、適切な正規化を行うことになると思います。
正規化はともかく、関係スキーマは当たり前すぎて記事に起こしづらい・・・orz

ER図は概念データモデルと関係スキーマを合わせたようなものなので、書き方さえ間違えなければ問題ないと思います（というか、業務ではER図をいやおうなしに使わされるので、こちらの方がなじみがありますね・・・）。

性能、実行時間(ハード寄りな設計)

こちらに関しても大体下記の項目を概要から読み取って素直に計算することになるかと思われます。
他に必要な項目があれば随時概要から拾っていきます。

1. データ行数、列数(データ容量)
2. キャッシュ(バッファ？)ヒット率
3. タイムアウト値
4. (その他、ネットワークの通信時間やAPサーバの処理時間を考慮するものがあるかもしれない)

この辺はトランザクション関連(デッドロックやロールバックなど)が絡んできそうなので、余裕があれば当ブログでも扱います。

最後に

プライベートな勉強だとどうしても集中できずに詰めが甘かったり、そもそもなかなか着手できなかったりして捗りません・・・orz

当ブログをご覧になっている方はきっとTosh以上に勉強熱心だと思われますので、そういったコツとかございましたらご教示頂けたら、と思います。

以上です。

2019年2日目: 概念データモデル

ご挨拶

お世話になっております。Toshでございます。
情報処理技術者試験が近いのにMHWが楽しすぎて過去問すらマトモに見れていない今日この頃ですorz

少しでも勉強してる感を出すため、本日はデータベーススペシャリストに絡んだ内容をば。

概念データモデル #とは

現実にある情報をまとめらたり分けたりして「これは○○だ」と一言で表せるものにした後、それらの関係を線で結んだもの・・・かな？
オブジェクト指向言語を扱ったことがある方には「クラス図みたいなもの」と伝えればわかりやすい・・・かな？
これを項目とかキーとか詳しく書いたものがER図になる認識です。

自己参照とかもろもろ省いてますが、とりあえず以下を見ていただいた方が早い気がします。

多重度

通販でよくある注文情報とかが分かりやすいと思います。

• 注文情報・・・注文番号、送付先や伝票番号など
  • 1回の註文につき1つだけ
• 注文詳細・・・注文した商品や金額、点数など
  • 1回の註文につき1つ以上

リレーション

このような場合、矢印の方向が「注文情報」→「注文詳細」と、矢印の向き先が1つ以上(多)のモデルに向きます。
更に「関連するデータがないかもしれない」状態を許可する場合は「〇」、必ずデータがある状態を表す場合は「●」を追加します。

※多対多だと矢印の向きが双方向⇔になっちゃいますが、正規化するにあたりこれは排除されます。
正規化についてはまたの機会にでも・・・

継承関係（スーパータイプとサブタイプ）

オブジェクトの継承みたいなものです。 上に大本となる抽象的なモデル（親）、下により具体的なモデル(子)を置いて「▲」の付いた線で表します。

排他的サブタイプ

上記の例は『「商品」には「単品」と「セット」のどちらかである』という状態を表したものです。 これを「排他的サブタイプ」というらしいです。

また『「商品」は「セール品」と「予約商品」があり、どちらも両立する』といった共存するサブタイプを表す場合は「共存的サブタイプ」として下記のように表します。

共存的サブタイプ

※「共存的サブタイプ」の親と子を1対1とすることで包含も表現できますが、「共存的サブタイプ」と絵面がほとんど変わらないので割愛させて頂きます。

最後に

こうやって文字に起こすと概念として頭に入っていても自分の理解が浅いことが浮き彫りになりますね・・・
しばらくデータベーススペシャリストのネタを続けようかしら←

以上です。
来年度もドタバタしそうですがご安全に。

2019年1日目: Tosh式(というほどでもない)デバッグ法

始めに

遅ればせながら、あけましておめでとうございます。
今年こそはブログを継続しようかと存じておりますので、何卒何卒。
※どうせ三日坊主なのでタイトルのナンバリングを変えてみました

ブログを再開した事の発端は業務中にメンバーから「(デバッガの使用方法などではない)デバッグ方法を教えてほしい」と言われたはいいけれどうまく答えられなかった・・・というものです。

なので、今回はToshが日ごろ行っているデバッグ手順を整理してみようかと。
経験者からすればごく当たり前のことと存じますが、お付き合いいただけますと幸いです。
(長くなりますので、「ノーサンキューだ！」という方は今すぐyoutubeにでも)

前提条件

Webフレームワークの使用を想定しておりますが、GUIのアプリケーション全般に応用できるように心がけます。

デバッガを使わないデバッグ法

正直無意識にやってますが、大体下記の手順を踏んでるかと。
デバッガがあれば変数の中身を調べる際にデバッグ用のコードを埋め込まなくてよく、
楽にステップ実行できるのですが・・・orz

1. エラーとなる箇所の直前にデバッグ用のコードを埋め込み、変数の中身を調べる
   • 慣れてる人はここで原因が判明する
2. 変数の中身から仮説を立て、整理する
   • この段階でおおよそ見当がつくようであればその部分を中心に調べる
3. 遷移先のページに対応する受け口となる処理を探す
4. 上記の処理からビジネスロジックに該当する処理への流れを把握する
5. ビジネスロジック上でデバッグ用のコードを埋め込み、変数の(以下略)
   • おおよそここで原因が判明する
6. ビジネスロジック上で原因が判明しない場合、遷移先のページを表示する直前にデバッグ用のコードを埋め込み(以下略)
7. それでも原因が判明しなければ画面上で何かしら処理しているはずなので、デバッグ用のコードを(以下略)

地道極まりなくて申し訳ございませんが、順を追って説明させて頂きます。

1. エラーとなる箇所の直前にデバッグ用のコードを埋め込み、変数の中身を調べる

まずはエラーなどの不具合が発生している箇所がどうなっているかを調べます。

具体的にはその部分で使用されている変数(ローカル変数、インスタンス変数、環境変数など)をつぶさにチェックします。

ここでしくじれば泥沼にハマるのでご注意をorz

2. 変数の中身から仮説を立て、整理する

変数名から変数の中身から「この部分にはこのデータが入るはず」などという仮説を立て、整理します。

慣れてる方であれば仮説を立てずにほぼ解決しますが、デバッグに慣れてない方は

1. 調査
2. 仮説 (← 今ここ)
3. 検証
4. 再調査

という流れを意識すると手早く正確にデバッグができるようになると存じます。

3. 遷移先のページに対応する受け口となる処理を探す

Webフレームワークでいうコントローラ、GUIアプリケーションでいうイベント処理を画面名やURLなどから判断し、デバッグ用のコードを埋め込みます。

もし埋め込んだコードが実行されなければやり直しですorz

4. 上記の処理からビジネスロジックに該当する処理への流れを把握する

3.の処理から他のメソッドやビジネスロジック(WebフレームワークでいうModel)などを読んでいるかと存じますので、メソッドの呼び出しや返り値の流れを大まかに確認します。

5. ビジネスロジック上でデバッグ用のコードを埋め込み、変数の(以下略)

エラーの原因の大半はビジネスロジック上で起きるので(※Toshの体感上)、ここでの変数の状態を確認すればほぼ解決します。

6. ビジネスロジック上で原因が判明しない場合、遷移先のページを表示する直前にデバッグ用のコードを埋め込み(以下略)

5.と同様ですが、ビジネスロジックが処理される気配がなければここは「ビジネスロジックに入る前に(以下略)」となります。

7. それでも原因が判明しなければ画面上で何かしら処理しているはずなので、デバッグ用のコードを(以下略)

5.や6.と同様ですが、具体的にはWebフレームワークでいうViewに相当する部分で行います。

最後に

慣れてなければ「どういったものが各々の変数に入るべきか」というものを判断するのは難しいと存じますが、こればかりは自分で場数をこなすか先輩方に伺うか以外の解決法を思いつきません・・・(;´Д｀)

あと、Toshは「ビジネスロジック→遷移先の画面」という流れでデバッグしますが、「遷移先の画面→ビジネスロジック」というやり方もあります。
その辺は好みによるかと。

ユニットテスト(xUnit)を自分で組むと変数の中身やメソッドの呼び出しを意識せざるを得ないので、
デバッグを手早く済ませたい方はユニットテストに触れてみることをお勧めします。

ちなみにToshはJUnitとPHPUnitを扱いますので、必要とあればどこかの機会にまとめます。

ではでは、ここまでお付き合い頂きありがとうございました(/・ω・)/

107日目: 近況報告とか勉強ネタとか

ご挨拶

かなりご無沙汰しております。Tosh でございます。
最近は「仕事は忙しくないものの芳しくない状況で、なんとかチームの負担にならないように本気出していたら帰る頃にはくたばっていた」という生活を送っておりましたが何とか生きております。
基本定時退社なのになんだこれ・・・

近況報告

上記のとおりブログ休止中は派遣先と家の往復でしたが、何とか下記は続けております。

• 運動
  • 腹筋ローラー楽しい。
  • ジョギングは仕事が忙しいと体力がもたないので休止中orz
• スキルアップ(気力があればやる程度、詳細は後述の『勉強ネタ』にて)
  • 英語
  • ネットワーク
  • データベース

運動はジョギングを除いて2ヵ月ちょっと続けてますが、体力がむしろ落ちてますね……。
仕事でちょっと本気出すだけですぐにばてるようになりましたし、何より不眠症が悪化しました(;´Д｀)
「仕事が詰むと回復ができなくなり、より仕事が詰まってしまう」というバッドステータスの対処法があればぜひご教示願いたいものですm(_ _)m
逆に言えば仕事が順調なうちは好調でより仕事がはかどりますので。

勉強ネタ

最近やってる勉強は上記に挙げた3点で、プログラマとしてのキャリアやスキルには直結しませんが、どれもシステム開発においては外せないものと認識しております。

英語

以前から StackOverFlow で情報を漁ってたのですが、最近は機器類の英語マニュアルやプロトコルの仕様書、GitHub の Issue を漁る頻度が増えた(というかほぼ毎日見てる)ので、短時間でより多くの情報収集をこなせるように英語を学習する時間を増やしました。
とはいっても English Upgrader とかでリスニングしながら他の作業を並行してやる程度ですがorz
TOEIC 330点程度でも苦にならないリスニング用のアプリのリンクを貼っておきますので、(有名どころで今更紹介すべきかどうかは悩ましいですが)ご参考までに。

スマートフォンアプリ｜English Upgrader＋｜TOEIC Program｜IIBC

NHKゴガク アプリ - NHKゴガク

ネットワーク、データベース

この2点は「システム開発はどれもデータありき」という認識のもと、最近本格的に手をつけ始めたものとなります。
業務上では下記3点のセンスを養わないと開発コストを下げられないことを痛感した次第です。
「カテゴリ分けが微妙」という突っ込みはぜひコメントか Twitter にて。

• データ構造そのもの
  • 業務フローに基づくデータベースの論理設計
• データの移送、保持
  • ネットワーク
  • ストレージ、メモリアクセス
• データの処理
  • アルゴリズム

このうちプログラマが意識するのは「ストレージ、メモリアクセス」「アルゴリズム」だと思います。
しかし私は「プロのプログラマ」ではなく「システム開発のために何でもやる雑用」みたいなポジションですし、このブログをご覧になってる方々と比べて何の専門性も持ち合わせていないので、この2点を突き詰めるのに限界を感じております。機械学習とか含めて決して諦めてはおりませんが。

あとは今のチームも私よりプログラミングが達者な方ばかりですので、そういう方向に進むよりは「プログラミング以外でプログラミングが楽になる方法」を模索する方がチームの生産性がより向上すると思った次第です。
ということで、スペシャリストには程遠いとはいえ、そういった方々と対等にお話できる程度のスキルを持とうという思惑でネットワークスペシャリストに申し込んでみました。

その辺のまとめは落ち着いてからやろうと思っております。
ほったらかしのネタもありますし……。

ではでは、本日はこの辺で。
生きてたらまたいつか更新致します。

56日目: Kotlin を味見してみた

ご挨拶

非常にご無沙汰しております。Toshでございます。
一念発起して始めたことがほとんど続いておりませんが、筋トレとジョギングと英語のリスニングは何とか続けております……orz
というわけで(？)今回の記事も有識者にとっては物足りないものとなります。

Kotlin #とは

どうやら JetBrains 社が作った“マルチプラットフォームで動くモダンな静的型付き言語”みたいですね。
C言語風味な感じがしますが、クラスベースのオブジェクト指向にも関数型チックにも書けるので、私にとってはとっつきやすい印象です(そのくせサンプルコードにえらく手間取ったり)。

というわけで、下記にサンプルコードを載せてみます。

fun main(args: Array<String>) {
    print((1..Integer.parseInt(readLine())).map({num ->
        when {
            num % 15 == 0 -> "Fizz Buzz"
            num %  3 == 0 -> "Fizz"
            num %  5 == 0 -> "Buzz"
            else          -> num.toString()
        }
    }))
}

みんな大好き FizzBuzz なので、解説は特にございません。
Java との大きな違いは Main クラスを定義せずに main メソッドを定義できるところですかね。
バッチ処理の実装が楽になりそう(小並感)。

というわけで、本日はこの辺で。
空いた分の埋め合わせはゆっくりとやりますorz

24日目: Vagrant で開発用サーバ構築 その1

ご挨拶

またまたご無沙汰しております。Toshでございます。
仕事のモチベーションを無理やり保ったり何やらでブログの更新が滞っておりましたorz
今はGW休暇中(5/1現在)なので、その間に「インチキせずに」穴埋めをやっていきます。
というわけで、今回のテーマは長くなりそうなので、何回かに分けますm(_ _)m

開発用サーバ構築に使用するものについて

Oracle VM VirtualBox(以下、VirtualBox)

まずは仮想環境用ソフトウェアがないとお話にならないということで、 VirtualBox を使用しようかと思います。
下記からダウンロード可能です。

Oracle VM VirtualBox - Downloads | Oracle Technology Network | Oracle

Vagrant は初期の頃は VMWare にしか対応していなかったそうですが、現在は VirtualBox にも対応しておりますし、無償の範囲での機能の制限が VirtualBox にはないという理由で選びました。
あとは Tosh 自身が VMWare をちゃんと使ったことがないからですね(´・ω・`)

Vagrant

次に、本記事のメインとして、仮想環境構築ツールは Vagrant を使用します。
下記からダウンロード可能です。

Download - Vagrant by HashiCorp

仮想環境の構築・複製・配布などは Docker も有名ですが、Vagrant は下記の点で Docker との違いがみられます(Docker は触ったことないので自信なし)。

• 利点
  • OS ごと切り分けられるので、VM のカーネルが1つ壊れても他の環境に波及しない
  • 設定ファイルは Ruby のソースなので、引数による設定の切り分けとかが楽
  • 簡単な設定なら Ruby の知識は不要
• 欠点
  • 設定が煩雑になりがち(な気がする)
  • VirtualBox 固有の設定を盛り込むならかなり面倒
    (設定の一部は 21日目に挙げております)
  • プロジェクト(環境)ごとに Box を作って OS を立ち上げるので、複数構築・起動はリソースを占有してしまう

Docker は共通の OS・カーネルを持ち、環境ごとに差分を持つので、AP サーバと DB サーバを分ける環境であればこちらの方がリソースを抑えて疑似的に再現できそうです。
今回は1つの環境でAP サーバと DB サーバを兼ねるつもりなので、Vagrant のほうが楽になる認識です。
※Docker についてはまたの機会にでもﾉｼ

Packer

仮想環境構築支援ツールとして、Packer を使用します。
下記からダウンロード可能です(ダウンロード後、Path が通っているディレクトリに中身の実行ファイルを配備してください)。

Download Packer - Packer by HashiCorp

Vagrant にも provisioner としての機能はありますが、割と貧弱で、何もしなければシェルスクリプトしか使用できません(多分そのはず)。
Chef を導入すればそちらに provisioner としての機能を移譲することも可能ですが、今回はあえて Packer に provision をさせてみようかと。
Packer の provision の使いやすさは Vagrant とそれほど変わりありません(JSON 形式で設定するから好みが分かれる)が、これが真価を発揮するのは環境ごとのゴールデン・イメージ(ある程度セットアップしたイメージ)を簡単に複製するところだと思います。
AWS などのクラウドサービス用にイメージを複製する場合などは Packer を使用する価値があると思います。
他の利点等については実際に触りながら検証していきます(;・∀・)

ではでは、今回はこの辺で。
次回は実際に構築しながら書いていきます。

23日目-2: Javascript で map とか

こんばんは。Tosh でございます。
今回はなんとなしに遊んでみたことを残してみようかと。

Javascript で map とか

事前準備

どうやら Javascript には range がないようなので、下記サイトを参考に range 関数を定義しておきます。
jsでrange関数をつくる - Qiita

map(写像)

配列の要素それぞれに関数を適用する、おなじみのアレです。
フィボナッチ数列を例としてやってみます。

var fib = n => n < 2 ? 1 : fib(n - 1) + fib(n - 2);
range(10).map(fib);

実行結果はこんな感じです。

filter(抽出)

読んで字のごとく、です。
偶数のみ抽出する処理を例としてやってみます。

range(10).filter(n => n % 2 === 0);

実行結果はこんな感じです。

reduce(畳み込み)

配列の要素を左から右へ適用して、1つの値に合体(？)する、こちらも割とおなじみかと。
階乗を例としてやってみます。

range(5).map(n => n + 1).reduce(fact);

実行結果はこんな感じです。

ちなみに、これの亜種で右から左へ畳み込むのが reduceRight だったりします。
しかし順序を考慮しなければならないケースといえば……

['a', 'b', 'c', 'd', 'e'].reduceRight((ac, cur) => ac + cur);

……なんかもっとマシなのなかったの？orz

flatMap(持ち上げ？)

これに関してはうまく説明できない(というか理解が怪しい)のですが、多重配列を平坦化した上で写像を行う、という認識です。
モナドを適用している値に関数を適用する bind と似たような感じですかね？

var fib = n => n < 2 ? 1 : fib(n - 1) + fib(n - 2);
[[0, 1], [2, 3], [4, 5], [6, 7], [8, 9]].flatMap(fib);
=> (10) [1, 1, 2, 3, 5, 8, 13, 21, 34, 55]

……となる想定なんですが、実験的な機能のため、どのブラウザでも動作しないようですorz

適当に遊んだだけの記事ですが、今日はこの辺で。