vue+firebaseでwebサイトを作った話

この記事はcloud.config tech blogにマルチポストしています。

portfoliosite作ったった

目的は2つあって、普段業務ではバックエンドの開発ばかりやっているのでフロントエンドについて学習したいというのが一つと、そろそろ業務でもフロントエンド寄りのことがしたいと考えていて、それを伝える際に「業務に入るだけの実力と意思がありますよ！」ということを示すために使うというのがもう一つです。 また、アーキテクチャとしては以前社内向け決済アプリを作るチームの一員だった時に使っていたもので、今度は自分一人で何かしら作ってみたいと思っていたためアーキテクチャとしてはその時と同じくfirebase+vueで作ることにしました。 そういったいきさつの下で今回作ったポートフォリオサイトについて、どのように作ったか、何を参考にして作ったかをまとめていきたいと思います。

作ったもの

https://namuyu-s-portfolio.firebaseapp.com/ デザインで1週間、コーディングで2週間弱程度かけて作った静的サイトです。 大抵の時間をcssを調整するのに使っていたような気がします。

参考にしたサイト、教材

• VueとFirebaseの基本機能全部使ってぬるぬる動くポートフォリオサイトを作ったのでソースと解説

最初に参考にしたQiita記事です。 クオリティも高いです。 どんな機能を持たせようか考えるのに役立ちました。 firebaseの機能を一通り網羅して作られているので、それぞれの機能をどのように使うのかの実例や使い方を知ることもできます。

• Vue.js + Firebaseで自己紹介用の静的サイトを作ってみた 第1弾 環境構築編

vueのインストールからプロジェクトの作成、サイトのホスティングまで必要なものは一通り載っています。 vueでサイトを作ってfirebaseでホスティングする際に必要なことまとめられています。

• udemy 未経験からプロのWebデザイナーになる！ 400レッスン以上の完全マスターコース

udemyの教材です。 7月～9月の間、これを見ながらphotoshopでデザインしてhtml,cssに落とす方法を勉強していました。

• その他、実際に作られたポートフォリオサイトがいくつか 主にどんな内容をサイトに含めるか検討する際にいくつかの実例を実際に見ました。 国内だとあまり作例が見つからなかったので、「developer portfolio」等のワードで検索をかけて海外のデベロッパーのサイトをいくつか見つけることができました。 これを基にしてページをいくつかのセクターに分けて表現する形式を採用しました。

使った技術スタック

• html
• css
• photoshop
• vue
• firebase

やったこと

• 英語で表現

海外のデベロッパーのポートフォリオサイトを見ると大抵が英語だったので、海外からみられることを考えると自己紹介くらいは英語で書いておいた方がいいかなと考えました。 ブログの欄や資格の名称は日本語ですが・・・

• Componentのインポート

各セクターのタイトル(ABOUT~「Hi, I'm Namuyu.」の部分)は定型なので、纏めて別ファイルのコンポーネントにしました。言っても3つだけの要素ですが、これによってコードの重複を若干減らしています。

• レスポンシブ対応

参考にしたポートフォリオサイトでレスポンシブ対応をしたと書いていてざっと聞いた感じだと難しそうだなぁと思ったのですが実際にやることを調べてみると画面サイズで表示物に当てるcssを変えるというシンプルなものだったので挑戦してみました。 画面が大きいと要素は2カラムの左寄せ、画面が小さいとタイトルが中心寄せになります。

• firebase storageから画像を取得

画像の取得の方法としてはリンクを使用する程度ですが、画像の置き場所としてはfirebaseのサービスの一つであるfirebase storageを採用しました。

やらなかったこと

• ブログの動的な取得

はてなブログには記事一覧を取得するAPIがあり、それを利用してBLOGSのブログ一覧を投稿されている最新4本を表示しようとも考えたのですが、firebaseの無料プランでは外部APIとの通信が行えないことを思い出してやらないことにしました。 表示されているブログ記事はテキストと画像を直接htmlの形で書き込んでいます。

• 画像のurlの取得

画像のリンクはfirebaseのストレージのページで取得できるリンクをそのまま埋め込んでいます。 本来は画像のファイル名からfirebase SDKを使ってfirebaseから画像を取得する方法もあったのですが今回は表示する画像の数が限られているので使用しませんでした。 これによって本来はfirebase sotrageに接続するためのクレデンシャルをどこに保存するかといったことを考えずに済んだところはあります。

• ルーティング 1枚のページに要素は全部含めたので、別ページとのルーティングなどは特に作成していません。

詰まった部分

• firebase initでどのディレクトリをdeployするか

具体的なinit->build->deployの方法は他の解説に譲るのですが、そのfirebase initを行う際に、deployを行う対象のファイルが入ったディレクトリを指定することになります。 ここで、最初は元々index.htmlが入っていた"public"ディレクトリをデプロイするディレクトリに指定していたのですが、いざデプロイしてみると公開されたページには何も表示されていませんでした。 正しくはどうすべきだったかを先に言うと、npm run buildすると"dist"というディレクトリが作られるのですが、このディレクトリをデプロイの対象にする必要があります。 このディレクトリにはvueで書かれたコードをjava scriptなどブラウザが読める形に変換された完成形のファイルが入っています。 先のpublicディレクトリにはindex.htmlとfaviconくらいしか入っていないため、vueで書かれた他の表示物が表示されなかったのですね。

• faviconをどこで設定するか

今回主に編集を行ったのはメインのページのコードである"App.vue"というファイルでした。 いざfaviconをデフォルトのものから変えようとしたとき、そのファイルの中にfaviconを設定するタグは存在しないしやり方を調べても全く出てこないのでしばらくハマっていました。 正しくは先ほどの"public"ディレクトリ内の"index.html"にiconタグがあるので、これを書き換えてやればfaviconを設定できます。 デフォルトではApp.vueはどれだけ弄っても最終的にbuildされればjavascriptに変換され、index.htmlのAppというidが振られたdivタグの中に要素として動的に生成されるので、その元のindex.htmlがすべてのベースになります。 当然metaタグやiconタグもそこにあります。 フロントエンドエンジニアリングの基礎的なところな気もしますが、そこが分かっていないとここでハマるよと言われたような気分です。 今度は一度その基礎的な部分から学んでみたいと思います。

一番力を入れた部分

小さいことですが、一番上のカラーバーは力作です。 これ、色が変わる一つ一つhtmlが割り当てられていて5色でループさせています。 いくつかのサイトでこれを見たときこれはお洒落だと思ったのでマネすることにしました。 要素の数はウィンドウサイズを大きくしたり小さくしたりすると裏で動的に要素が消されたり追加されたりしています。 このページで唯一の動的に生成、消去される要素でもあります。

これから追加するとすれば

• CONTACTの追加
• svgのアニメーションとかさせてみる
• Unityで何か作ってUnity roomの欄に追加
• コードを公開される形にしてGithubの欄に追加
• スマホで見るにはサイズが大きすぎるので調整
• その他何か作ったらどんどんCREATIONの欄に追加していく
• UnitTestの追加

おわりに

今回は初めて自力でwebページを作成したのでその際に参考にしたことや気付いたことをまとめました。 これから初めて自身のwebページの制作をやりたいと思った方やfirebase、vueといった技術が気になる方の参考になれば幸いです。

香川でGo言語の勉強会に参加して地元の技術コミュニティの活発さを知った回

はじめに

この記事はcloud.config tech blogにマルチポストされます。

年末ですね。 私の方でも27日に仕事納めをして、次の日の28日には朝一で飛行機に乗って地元の香川に戻ってきました。 そしてその日の午後にはその地元香川で開催されている技術勉強会に参加するという強行軍を敢行したところです。 参加した理由は主に2つあって、一つは新しい言語を触ってみたいというのと、もう一つは地元の技術コミュニティの様子を知っておきたいというものです。 技術コミュニティはどの地方にもありますが、都内ほどエンジニアが分布しているわけではない中で、どんな人たちがどんな風に技術コミュニティを築いているのか？ということを知りたかったのです。 自分も時々1週間単位で休暇を取得して実家に帰ってきたりしているので、その時に何かしら参加できるコミュニティはないかと探して、今回その手始めにこの勉強会に参加した次第です。

香川Go言語 わいわい会

• connpassのイベントページ

今回の勉強会の主なテーマは、Go言語で2Dゲームを開発できるライブラリの「Ebiten」でゲームを作ってみよう！というものでした。 形式としてはもくもく会で、基本的には作業中は教え合ったり作業したりして、最後にちょっと今日やったことを発表しようねというものでした。 また、それと同時にGo言語の初心者向けにGo言語の基礎編の講座も開かれていました。 今回の参加者の中には、中学生、高校生で参加していらっしゃる方もおり、この年齢でconnpassで勉強会イベントを知ってそこに飛び込んでくる勇気と積極性には参加者も主催も驚いていました。 ぜひプログラミングや何かしら作ることを楽しんでいってもらいたいものです。 自己紹介を聞いていると経験のある言語の一つとしてどちらの方もPythonを挙げており、今時プログラミングを始める方はやっぱりPythonから触るのが鉄壁なのかなぁと感じたりもしました。

勉強会の様子

本日の様子です！
中学生の方にもご参加いただきました。#gdgshikoku #golangjp pic.twitter.com/ocMaOyJEcC

— GDG Shikoku (@GDGShikoku) 2019年12月28日

本日の「はじめてのGo言語教室 in 香川」の授業風景。(終わった後にやってもらってる感を出して頂いたところ) #gdgshikoju #golangjp pic.twitter.com/d7kE3bfo7x

— Ryuji Iwata (@qt_luigi) 2019年12月28日

やったこと

私は以前go言語の記事を書いたくらいにはGo言語を触っていたのですが、だいぶん内容を忘れていたので基礎編に参加しました。 資料は主催者様のGithubにまとめられていて、次回開催時の資料の改造編もここから見られます。 内容としては、コマンドコンソール上で動く簡単なタイピングゲームアプリを作ろう！というもので、goのコードの走らせ方、変数、配列、if文、for文、入力、出力・・・といった基礎的な内容をカバーしていました。 やっているうちに内容を思い出してきて、余った時間で手元で出題をランダムにしてみたり配列の扱い方をもうちょっと調べたりしていました。

イベント会場あるある？会場の設備ネットワークに翻弄される参加者たち

イベント会場で使っていたPCは電源を落とすと保存したデータが消えてしまう仕様だったのでデータをgithubに上げておこうと思ったのですが、どうも手元でリポジトリがクローン出来ませんでした。 なぜかgithubに接続できないようです。 また、後ろではEbitenでゲームを作る組が「go getできない・・・(ライブラリが取得できない)」と頭を抱えていました。 おそらく施設のセキュリティの都合上、ネットワークの設定か何かでアクセスが遮断されている様子です。 自前のPCとモバイルルータを持参していた方々はおそらくあまり影響を受けなかったと思いますが、私はPCは設備のがあると聞いていたのでそれを使えばいいやと考えていたため、モロに影響を受けました。 一応書いたコードはgoogle driveに上げて持ち帰りました。 主催の方々も想定外だったらしく、次回開催時の課題として解決策を考えるそうです。

・・・帰ってから後で思いついたのですが、こういう時こそ自分が推している（推している？）visual studio onlineのユースケースの一つなのかもしれません。 開発環境をAzure上でホストしていればその環境でライブラリのインストールやgithubとの間のやり取りを行う際にローカルのネットワークの都合の影響を受けないのでは・・・？ これはまだ思いつきでしかありませんが、試して動きそうであれば一度提案してみるのもアリかも？

地元の技術コミュニティはかなり活発だった

会の最後に、香川で活動している技術コミュニティの紹介がありました。 なんと、それらをまとめたサイトもあるそうです。 それを見ると、思った以上に多くのコミュニティががこの地域で活動していることが分かります。 はじめはconnpassで「香川」などで検索をかけて出てきた結果をざっと眺めて「２つか３つくらいかな・・・」等と考えていたのですが、実際にはそこで見られるものだけで12もの団体があり、毎月5つ、6つの勉強会が開催されているようです。 県における技術コミュニティの活発さで言うと、connpass上でも県の人口に対するイベントの頻度としては上位に入るらしく、自分の地元である香川県の技術コミュニティはかなり活発なんだなぁと感じました。 また今度帰省した時にも何かしら参加したいと思います。

おわりに

今回は年末の帰省して早々に参加した勉強会でGo言語を学び、香川県の技術コミュニティの活発さを知ることができました。 主催者の方々、参加者の方々、どうもありがとうございました！

AzureにRedmineを立ててgithubと連携する方法

なぜやろうと思ったのか

社内で使っていたredmineでタスクの内容とgithubのコード変更を結び付け、トレースできるようにするため。 本番環境でいきなり試すわけにはいかないのでDockerを使ってみたり色々試したのち、AzureのVMでやるとうまくいったので。 「redmineとgithubの連携を試したいけどどんな環境でやればいいの」という人に使えるかもです。

できるようになること

gitのコミットメッセージに「refs #〇〇」という文字列を含めることで、対応した番号のissueからこのcommitの情報や変更内容を参照できるようになる。 commit毎の変更内容が確認できるのでどのIssueでどのような修正をしたかが分かる。 また、リポジトリから対応するissue番号にリンクすることもできる。

前提

• gitはローカルPCにインストール済みであること。 コマンドラインからGitを使う（for Windows）
• 自前のazureのサブスクリプションがあること
• 自前のgithubアカウントがあること

方法

1.AzureにVMを建てる。DNSを設定する。

Azureポータルからリソースの作成ボタンを押し、検索欄で「bitnami redmine」を入力して検索する。

検索結果から「Redmine Certified by Bitnami」を選択して、作成ボタンを押す。

仮想マシン名は適当に設定し、管理者アカウントはパスワードにして、ユーザー名とパスワードを設定する。 ここで設定したパスワードはVMへのログインに使用する。

デプロイが終わったら、作成したVMのメニューを開く。

DNS名の欄の「構成」ボタンから、DNS名の欄のの構成の設定を行う。DNS名ラベルの欄に任意のDNS名を入力して保存する。

2.VMにgithub_redmine_hookプラグインをインストールする

VMのメニューを開いて「接続」ボタンを押す。右側の画面で「SSH」タブを選び、「VMローカルアカントを使用してログインする」欄の右側のコピーボタンを押してコピーしておく。

Cloud Shell（以下Shell)を開き、コピーしたログイン用コマンドをペーストしてVMにログインする。Shellにペーストする際はCtrl+Shift+Vでペーストすること。

redmineのプラグインを保存するディレクトリに移動し、gitからそこにプラグインをダウンロードしてくる。

cd ~/apps/redmine/htdocs/plugins
git clone https://github.com/koppen/redmine_github_hook.git

3.プラグイン内の一部コードを編集する

プラグインのファイルの中の「github_hook_controller.rb」において、4行目の「skip_before_filter」を「skip_before_action」に書き換える。 以下のコマンドを実行したらiキーを押して編集モードにして編集し、編集がおわったらエスケープキーを押してから「:wq」を入力して保存する。

vi ~/apps/redmine/htdocs/plugins/redmine_github_hook/app/controllers/github_hook_controller.rb

4.VM再起動してredmineにログインして確認

VMのメニューに戻り、再起動ボタンを押してVMを再起動させる。

再起動が終わったら、DNS名の欄の横にあるコピーボタンを押してDNS名をコピーし、ブラウザの別のタブのURLにペーストしてアクセスする。

右上のログインボタンを押してログインする。ログインIDは「user」、パスワードはShellでパスワードが保存されているファイルを見て確認する。

cat ~/bitnami_credentials

redmineの右上のAdministrationメニューから、Pluginsに移動する。

Redmine Github Hook pluginという名前のプラグインが追加されていれば成功。

5.daemonになってssh認証鍵を作成

ssh認証情報が保管されるディレクトリを作成し、所有権をdaemonに渡す。

cd /usr/sbin
sudo mkdir .ssh
sudo chown daemon .ssh

ユーザーをdaemonに変更する。

sudo -su daemon

daemonでrsaキーを作成する。 キーの名前、パスフレーズを聞かれるが内容は空白のままでよい。

cd .ssh
ssh-keygen -t rsa

6.configファイルを作って編集

configファイルを作成する。

touch config
vi config

作成したconfigファイルの中身を編集する。 編集がおわったら:wqを入力して保存する。

Host github github.com
  HostName github.com
  IdentityFile /usr/sbin/.ssh/id_rsa
  User git

7.githubの自分のアカウントに公開鍵を登録

自分のgithubアカウントでgithubにログインする。

右上のアカウントアイコンのメニューから「Settings」に入る。

左のメニューから「SSH and GPG keys」を選ぶ。

「New SSH key」ボタンを押してキー追加画面に入る。

Titleにはわかりやすい名前を、Keyには作成したrsaキーの公開鍵の内容をペーストする。 公開鍵の内容は以下のファイルからコピーする。

cd /usr/sbin/.ssh
cat id_rsa.pub

8.VMからgithubへの接続のテストを行う

daemonの状態で以下のコマンドを実行する。 「hi [自分のgithub上での名前]！ ~~~」と出れば成功。

ssh -T git@github.com

9.テスト用リポジトリを作成

github上で何かしらのプライベートなリポジトリを作成する。

10.VMでリポジトリをpull

作成したリポジトリのページに行き、「Clone or download」ボタンをクリックする。

出てきたポップアップの「Use SSH」を押し、Clone with SSHがタイトルに出てきたら、そのurlをコピーする。

Shellに戻り、作成したリポジトリを置くための適当なディレクトリを作る。 作ったら、そのディレクトリにリポジトリをクローンしてくる。

git clone --bare [コピーしたurl]

11.redmineでプロジェクトを作ってリポジトリを割り当て

redmineの画面右上「Projects」を開き、その中の右上にある「New project」をクリックする。

わかりやすいプロジェクト名を入力して「Create」を押す。 なお、このときにIdentifierの欄に入力した項目は後で使うのでコピーしておくこと。

12.リポジトリのwebhookを設定

再びgithubのリポジトリのページに移動する。タブの「Settings」を開き、左のメニューからWebhooksに移動する。

Webhooks画面の右上「Add Webhook」ボタンを押し、webhookを追加する。Payload URLには以下の内容を入力する。他の項目はそのままでよい。

http://[redmineを立てているVMのDNS名]/github_hook?project_id=[作成したredmineのプロジェクトのIdentifier]

13.issueを一つ作成

redmineのプロジェクト内、Issueタブを開き、右の方にある+ New Issueボタンを押す。

内容は適当に設定し、保存する。

14.ローカルPCにリポジトリをcloneしてくる

githubの作成したリポジトリのページに行き、「clone or download」ボタンを押し、今回はClone with HTTPSで表示されているurlをコピーする。

ローカルPCの適当なディレクトリに、先程コピーしたurlを使ってリポジトリをcloneする。

git clone [コピーしたurl]

15.git initする

cloneしてきたリポジトリがあるディレクトリに移動し、そこでgitを初期化する。

git init

16.何かしらファイル作って「refs #1 fix」というコメントでcommit&pushする

何かしらのファイルを作成し、それをステージングファイルにaddする。

touch file
git add file
git commit

git push

17.確認

redmineのIssueを確認する。先程作ったIssueのページにそのIssueと結びついたcommitの情報が表示されていれば成功。

参考

Azure上にRedmineを立てる [AWS（Bitnami）上のRedmineとGitHubを連携させる] (https://qiita.com/ao89exb/items/c67a20e5dbc559297104) ↑AWSを使用しているもののVM内での操作はAzureでも同じ。

それは置いといて今週末応用技術者試験受けます。

namyusql.hatenablog.com

 それは置いといて。

今週末10/21はIPA情報処理推進機構の試験の日だ。

その中でぼくは応用技術者試験を受ける。

先週までは統計検定1級の勉強ばかりやってたけれど、もっと前の段階で午前問題は合格点に乗っていたし、午後問題も手に負えていたのでまあ大丈夫だろう、ってところである。

とはいっても試験前の一週間くらいは追い込みかけようってことで、今週はこれまでに過去問を1周解いて、これから試験日までにあと１～２周回そうと思っている。

ぼくのレベルは

過去の記事にも書いたとおり。 

namyusql.hatenablog.com

 情報系の専門教育は受けていない。

ただただ経済学部でウェイできなかったコンピュータが友達の人。

一通りのコンピュータの使い方は分かるし見られたくない履歴は消せるしフリーズしたら電源ボタンを押して強制終了させたりはするし程度のリテラシーはある。

ネットワークとかハードウェアのあれこれについては基本情報技術者試験の時に一通り理解している感じ。

どこが難しい？

試験概要とか過去問とかあるいはほかのブログを見てきたなら知ってるだろうけど、午後問題で記述式で答える点が基本情報と応用情報の試験の大きな違い。

とだけ聞いてもその言葉だけだと具体的なレベルが分からなくて想像の上だけで「難しそうだなー」とか思いがちになる。実際僕もそれでしばらく過去問の午後問題に手が出せなかったし。

けど実際のところ、午後問題の数のうち６割くらいは基本情報の時と変わらないような選択問題で、その中に特定のものを示す単語を答えよとか理由を答えよといった内容が加わる。

理由を答えるのは20-40文字とかそこそこの分量は要求されるが、それでもその程度である。1文で答える範囲である。

単語を答えるのが選択式じゃなくなるのは痛いが、それでも案外覚えていたりする。

覚えてなかったらご愁傷様。

けど、難しいのはそのくらいで、午前の問題は心持ち範囲が増えたらしい？（基本と比べてどれくらい内容が増えたか忘れた）って程度なのでそこまで難しくなった気もしない。

何読んで学習してるの

一応応用技術者試験向けのテキストは一冊買っておいた。

ぼくが買ったのは確か青表紙で中は緑色メインの本だったと思う。ちょっと探したけどそれっぽいのが見当たらなかった。

選び方として、基本情報を勉強するときは絵での説明がなかなか好みだった北見隆二さんの本で勉強していた。

けれど、これからあと目指しているデータベーススペシャリストとかプロジェクトマネージャーとかの参考書を見ると絵面が地味な本が殆どで、そういったものにも慣れなきゃなーと思って絵面が地味目、内容が網羅的なものを選んだ。

特にそういったことを考えなければキタミ式が一番わかりやすい気がする。 

キタミ式イラストIT塾 応用情報技術者 平成30年度 (情報処理技術者試験)

 あとは過去問。試験サイトの過去問の解答は解説がないので。

平成30年度【春期】【秋期】応用情報技術者 合格教本 (情報処理技術者試験)

 勉強用に読んだ本はこれくらい。

割と余裕があったのであとはデータベーススペシャリストのテキストとかセキュリティスペシャリストのテキストとか読んでいた。

勉強法は？

テキストを何周か読んで、自信がついたら過去問解いて、分からないところがあったらテキストに戻って読み直す。

過去問を解いて覚えなきゃいけなさそうで現状覚えていないものについてはメモして覚えていこう。といった感じ。

他にできることが思いつかない。

午後問題については、特にデータベースの問題についてはINNER JOINを扱う問題が頻発していたので、そこについてはクエリを勉強し直した。

けれども、ほかの問題についてはこれといった対策が思い浮かばない。

損益計算書や貸借対照表を扱った問題もあり、ある程度それに関する知識がある人はそういう問題を優先して解いたりそこに関する知識をおさらいしておくと勉強になったりするのかもしれない。

あとは必答のセキュリティに関してはあまり手の付けようがないし、アルゴリズム関連についても勉強してどうにかできることがあまりない。

せいぜいどの問題が得意か把握して、本番ではこれ解こうかなーとか優先順位をつけておくくらいはしている。

勝算は？

7-8割くらい。午後問題は過去問解いて丸付けしても採点ができないので、そこに関する不安はある感じ。

まあ合格しなくても来年の春はデータベーススペシャリスト受けるし、秋にはプロジェクトマネージャーを受けようと思ってはいる。

統計検定1級を受験します。

ぼくは来月の24日に、統計検定の1級を受けようと考えている。

それにあたって、これまでも統計検定関連のブログはいくつか見てきたけど、割とレベルが高い人が多くて「そりゃ合格するだろ」と感じていた。

一方で自分はというと大学で統計学の講義は受けたけど期末試験は計算系の問題、他にゴリゴリ数学の証明問題を解くような経験はなく、統計検定2級は計算のやり方を覚えて合格をした程度のレベルである。

つまり、一級でメインになるような「～を示せ。」だとか、「～の式を～を用いて表せ。」みたいな問題について、現状どう答えたらいいかすら分からない。

なので、そんなレベルでどうにかこうにか統計検定1級レベルの統計力（ぢから）を手に入れようとして現状やっていることと目指すものを整理しながら、同程度の人の参考になるような情報を纏めておきたい。

参考書、サイト

どのブログでも書籍紹介をしているしそれを見るために統計検定受けましたブログを見てるところがあるのでここでも紹介していく。

日本統計学会公式認定 統計検定 1級・準1級 公式問題集[2016〜2017年]

日本統計学会公式認定 統計検定1級対応 統計学

公式テキスト＆過去問。

基本的に資格試験の過去問と解答は公式サイトで手に入るものだが、解答は略解で「細かい解説が欲しかったら過去問本買ってね」というスタイルである。

なので買った。

現代数理統計学の基礎 (共立講座 数学の魅力)

これは下記のブログでも紹介されてて重要そうなので買った。

hawkingh.hateblo.jp

この本は、内容は理解できるけど章末問題が解けなくて行き詰った。

解答も略解なので、元々数学ができてないと問題の形式や解き方のセオリーみたいなのが分からないのかもしれない。

今ブログを読むと、

解説→演習問題という、よくあるタイプの参考書形式。だが、とにかく説明が分かり易い。「いや、その分かり易いって分かり易くないだろ」っていうのはコミュニケーションを解さない数学書あるあるだが、これは本当にそんなことはないと思う。というより、これにある数式が理解できないときは、数学の理解に穴がある状態なので、立ち戻った方が良い。

とあったのでぼくは立ち戻った方がいいかもしれない。

なお、紹介されているマンガで分かる系の書籍は全部一通り読んでいる。

最近は機械学習編が出てた。表紙の子かわいい。

他にも統計学テキストは何冊か持っているが、直接勉強に使っているのはこの3冊。

公式テキストで広く浅く、細かいところは久保川統計、問題集は公式のもの、といった組み合わせ。ただし、最近はどっちかというとネットのサイトを見ることが多い。

主にみているのは以下。

data-science.gr.jp

to-kei.net

「〇〇分布　期待値　導出」とか「〇〇分布　モーメント　導出」あたりで検索出てくるとほとんどこの二つのサイトが出てくる。

導出方法を纏めたいときはここを見てる。

今やってること

一番参考にしているのはこれ。

qiita.com

実際、試験問題は確率分布に関わるものと分析手法にかかわる部分の二つに分かれている。

なので、まずは確率分布の期待値、分散、モーメント母艦数を自力で導出できるようになるのを目指している。

上記サイト辺りを参考にしながら、曼荼羅と導出をまとめたものをこれまでに作ったのでそれを覚えようとしている。

作ったもの

それが終わったら統計手法（たぶん社会統計で受けると思うのでR関連）あたりを問題を解きながら勉強していく予定。

ただ、ここまでやってもまだ問題を解けるところまでは進んでいない。

実際にはほかに尤度関数だとか知識として足りないところもあるし、式変換など数学の基礎的な部分をもっと鍛えなければならない。

要するに「数学の問題を解く」というスキルが別に必要であるのだけど、これに関しては自力で問題を解いてもそれが合っているかどうかわからないので、誰かに教えてもらわなければならない。

ので、教えてもらいに行くことにしている。

展望

統計検定1級の問題は計算ができるだけでも特性値が出せるだけでも解けない。

もっと細かい知識も必要だし、逆にもっと基礎的な数学の能力も必要になってくる。

けど、どちらを学習していくにしても定期的に問題を読み直しつつ、「何が分かっていたら解けるか」辺りを考えながら見ている。

そのうちどこのどういう知識を使って解けばいいかわかるようになれば、もっと学習が進みそうな感じがする。

合格点は全体の6割なので、そこを越せる程度にはなっておきたい。

ボイスコッド正規形について自分用まとめ その２

namyusql.hatenablog.com

 前回はボイスコッド正規形について、特徴、メリット、作り方といった基礎的な内容について書いた。

今回は、その補足的なトピックとして、ボイスコッド正規形を作る際に気を付けるべきことと、ボイスコッド正規形で起きうる問題について取り扱う。

ボイスコッド正規形を作る際に気を付けるべきこと

第三正規形からボイスコッド正規形にしようとしてテーブルを分けるとき、それがボイスコッド正規形になっていない例が前回も紹介した書籍に挙げられている。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

ボイスコッド正規形にするための正しいテーブルの分け方は社員ID-チーム補佐、チームコード-チーム補佐であった。

しかし、もし社員ID、チームコード、チーム補佐の例で、社員ID-チームコード、チーム補佐-チームコードでテーブルを分けていたらどうなっていただろうか。

この本の中では、その結果起きることとして「元のテーブルに戻すことができない」ということが強調されている。

間違ったテーブルの分け方をすると、正規化する際に必要なことである可逆性がなくなったりして問題が起きてしまうので、正しい形で分割しようねということである。

「元のテーブルに戻すことができない」とは

勉強会の中でも、まちがったテーブルの分け方をすると「元の形に戻せなくなる」という言い回しで説明されたが、初めはこの言葉がうまく理解できなかった。

けどいくつかページを見て回ったりしてどうにか理解できるようになってきたのでまとめておく。

ここでいう「元のテーブル」とは、つまり第三正規形まで正規化した形のテーブルである。

 章末のコラムに

正規化 によって 分割 さ れ た テーブル は、 いつ でも 非 正規化 テーブル に 復元 する こと が でき ます。

とあるように、ボイスコッド正規形に正規化されたテーブルは、分割されたテーブルを結合することで正規化する前の形に戻すことができる。

例の中では、チームコードをキーにしてテーブル結合することで、社員ID-チームコード、チーム補佐-チームコードのテーブルを社員-チームコード-チーム補佐の形に戻すことができる。

これが「戻すことができない」という例として、社員ID-チームコード、チームコード-チーム補佐で切り分けた場合を考えてみる。

この場合、2つのテーブルをチームコードをキーにしてテーブルを結合しようとすると、一つのチームに複数のチーム補佐がつく場合があるので、その社員につくチーム補佐の人が誰なのか一意に求まらず、社員とチーム補佐が1対1で結び付けられた状態に戻せない。

このことが、「元のテーブルに戻すことができない」ということである。

こうならないために、テーブルを分割する際は、ボイスコッド正規化する場合だけに限らず、この分割の結果から元に戻そうとしたときそれができるかを考えたり、試したりしなければならない、という話である。

ボイスコッド正規形にしても起きる問題

前回説明したとおり、ボイスコッド正規形にすることで厳密に従属関係を分割することができる。

しかし、これによってデータベースのテーブル設計における全ての問題が解決できたわけではない。

社員ID、チーム補佐、チームコードの例に戻る。

この例においては要件として、一人の社員は一つのチームに所属することになっている。

しかし、ボイスコッド正規形に正規化したテーブルには、同じ社員と別のチーム補佐のペアを追加することによって、別のチームを掛け持ちしていることになる可能性もある。

なぜなら、チーム補佐はそれぞれ一つのチームと1対1で結びついているので、別のチーム補佐をキーにして結合すると同じ社員が別のチームと結び付けられるためである。

これを防ぐにはテーブルに入力する際に同じ社員に二人以上入力しないようにするなどの処理をプログラムの側で書かなければならないことになる。

この点がボイスコッド正規形においても残る問題とされる点である。

まとめ

• 正規化は失敗するとテーブルを正規化する前に戻せなくなるので気を付ける。
• ボイスコッド正規形にしてもテーブル設計の問題が全部解決されるわけではないので設計する際は気を付ける

今回は、ボイスコッド正規形について前回書ききれなかった内容を自分なりにまとめてみた。

いくらでも内容を濃くはできなかったが、要約はできたと思う。

ボイスコッド正規形について自分用まとめ その１

この間行ってきた勉強会でボイスコッド正規形の講義があり、自分でもこれまでよく理解できなかったので自分なりにまとめてみる。

ボイスコッド正規形とは（定義）

「非キーからキーへの関数従属をなくした形」

達人に学ぶDB設計より。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

ボイス-コッド正規形は、すべての関数従属(X->A)において、Xがテーブル全体のスーパーキーであるということだ。 

 プログラマのためのSQLより。

プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに

ボイスコッド正規形にすると何がうれしいのか

テーブルをボイスコッド正規形にするにあたっては、前提としてそのテーブルが第三正規形を満たしている必要がある。

この第三正規形においては、推移的関数従属（例えば、Aを決めるとBが一意に決まり、Bを決めるとCが一意に決まるがAを決めるとCも一意に決まってしまう状態）がない状態とされるが、厳密にはまだ残っている場合がある。

例えば、AとBを決めるとCが一意に決まるが、Cを決めるとBが一意に決まってしまう場合である。

この時、AとBを決めるとBが一意に決まる（当然と言えば当然）ので、推移的な関数従属が生じてしまう。

こうなると、C->Bの関係に変化が生じたとき、その変化に応じて書き換える行の数が増えてしまうなどの不具合が生じる。

ボイスコッド正規形にすると、この問題がなくなり、一通り関係の変化に対応できるテーブルとなるのがこの正規形にすることのうれしい点。

一般的に、第一、第二、第三正規形を作ってボイスコッド正規形まで作れば実務に耐えられるテーブルになるという話もある。

ボイスコッド正規形の作り方

前述のA,B->CとC->Bという関係がある場合、このC->Bの関係を別テーブルに切り出す。

達人に学ぶDB設計の例

社員ID	チームコード	チーム補佐

ここでは社員IDがA、チームコードがB、チーム補佐がCの関係なので、

社員ID	チームコード

これと

チーム補佐	チームコード

これに分ける。

これによって、チーム補佐が担当チームを変える時は下のテーブルを書き換えるだけで上のテーブルに反映される。（一時的に社員につくチーム補佐がいなくなることもある）

また、まだ誰も所属していないチームにチーム補佐を割り当てることもできる。

 これにてボイスコッド正規形が完成し、テーブルの中から厳密に推移的な関数従属を取り除くことができた。

まとめ

今回はボイスコッド正規形について、定義から作り方、メリットまでをまとめた。

• ボイスコッド正規形は第三正規形まで正規化されたテーブルから作られる。
• ボイスコッド正規形にすると推移的関数従属を完全に取り除ける
• これによって関係の追加や削除の際に起きる問題を取り除ける

次回予告

ボイスコッド正規化のためにはテーブルを分ける。

その際、分け方が悪いと問題が生じるので気を付けようねというトピックについて。

また、ボイスコッド正規化してもまだ起きる問題はある、というお話。

この辺りについて次回。