AKINOSUGI's diary

社内SEとしてやってきたことや学んだ内容を記載

統計学

『あたらしいPythonで学ぶ統計学の教科書』を読了。

 

各種検定までは何となく思い出せたけど、統計モデルの作成以降で

理論的につまづく。統計モデルって結局のところ、こんな感じ?

①事象を示す変数を設定し、複数の変数間にある関係性をモデル(関数)として表現する

②実際に"観測される"関係性は発生確率に応じてゆらぎがあるため、

 このゆらぎが発生する確率を確率分布に従っていると仮定。

 ※どんな確率分布を仮定するかはモデリングする人に依存する。

  ただし、統計モデルについてはある程度定型化されているので、

  確率分布の仮定については気にしない人もいそう・・・

③作成したモデルに実測値を当てはめて仮定した確率分布のゆらぎの中で

 発生しやすいのか、しにくいのかを確認して妥当であるか判断

(各検定のp値⇒帰無仮説の棄却 ※表現が微妙になってしまっている)

 

正直、確率分布が利用できるパターンと、各種分析手法の立脚している理論を

理解しないと正確な結果を読み解くのは無理だろうなぁ~。何となくの解析は

Pythonとかで結果だしゃできるだろうけど、何でそうなるの?って感じになりそう。

 

とりあえずは理論の勉強進めるとともに実データ利用してやってみることですね。

eStatとかはAPIだしてるからPythonAPIつついていい感じにデータ取得・クレンジングまで持っていければ分析に利用するデータにはできそうだけど果てしなくめんどくさそうではある。経済学と交えての分析ができるかやってみますか!

統計学

『あたらしいPythonで学ぶ統計学の教科書』を元に改めて統計学を勉強し直し中。

久々に確率密度関数とか、大数の法則中心極限定理、統計量の算出とか考えて感動!

日々の仕事だと社内調整とか、無理くりでも機能実装や運用案をひねりだしているだけなので、理論とかにしたがって整然としているのっていいなって思う。仕事ももっと整然とした内容とかだったらいいのに(直近だと軽減税率とか聞く人で対応方法違うし、ストレスでしかない。統一的な方針で誰かまとめてくれないものでしょうか・・・)。

 

Python統計学を学んでみてRで学んでたときのことを思い出しました。

当時はPythonとかまったく知らずにRでやってたけど、Pythonも全然遜色なさそう。ただまあ、Rの場合は論文とかでも利用できるレベルで実装内容について担保とられてたけど、Pythonはどうなんだろうか?機械学習のメインどころとしての認知も根強いものになっているし、十分なレベルのようには思うのだが・・・。

Rに比べるとPythonのほうが汎用性高そうではある。Rの場合ってあくまで分析の用途での利用ってイメージだけどPythonは拡張の結果として統計やら機械学習がでてきているので、アプリケーションの一部として組み込むとかは比較的楽なんじゃなかろうか?MicrosoftPythonを利用可能なように拡張してきてるし、基本情報処理技術試験とかでも対象言語にしてきているからもはやメジャーかな。

 

本書でPythonの統計的な処理をする場合に利用するライブリだけ下記に列挙。

・numpy

・scipy

・pandas

・matplotlib

・seaborn

 

このままだと

社内SEとして働き始めてはや数年。

気が付けば自分のスキルセットもむちゃくちゃです。

あくまで社内SEなんで特定の技術レイヤーだけ関わるわけじゃないんですよね。

その場その場で必要となることを浅く理解することが多い。

 

元々がマーケティングとか統計とか多変量解析とか機械学習とかしたい人だったので、ちょっと自分見直してみたい今日この頃。

『達人に学ぶDB設計 徹底指南書』

データベースについての『達人に学ぶDB設計 徹底指南書』を読了。

 

とっつきにくいデータベースについてかなり平易に記載されていた。

理論的な側面と実際の運用を想定した内容なので、実際に運用している身としては思わずうなづいてしまうことが多い。特に具体例として出てくるバッドノウハウとかグレーノウハウは現状利用されていたものもあった。

 

今後、著者のミックさんの『達人に学ぶSQL 徹底指南書』と本書でもよくでてきたジョー・セルコの『プログラマのためのSQL』を読むことにする。

Cobol

社内システムにCobolを利用しているものがあり、その担当となったので自分のPCに学習環境を作ってみる。

 

Cobolというと金融とか証券とかで利用されているっていう話しがよくありますが、私の勤務先は上記に当てはまりません。なんに使っているの?っていうと基幹システムです。勝手な想像ですが、Cobolの利用が多いのは汎用機を利用していたからでしょう。汎用機からOpen系への移行は汎用機の維持費やHWスペックの向上(Open系でも十分な処理速度が見込めること)を背景に行われてきたのでしょうが、どちらもHWレベルのコストが原因です。そのため、アプリケーションまで変えるっていう動きまでいかなかったんでしょう。アプリケーションレイヤーでもCobolは保守・運用コストが高い(言語仕様や開発者の不足・高齢化があります)んですが、内製化でどうにかすればいいって考えなんでしょうね・・・。この状況に陥っている会社は以外に多いのではないでしょうか?特に汎用機時代からガッチリ業務設計してそれにあわせたプログラムを作り込んできた会社ほどその傾向にありそうだって勝手に思ってます。

 

さて、本題ですがCobolの環境を作るって結構面倒です。厳密に言うとWindows OSで作成しようとするとMinGW入れてとか色々めんどくさそうです。有償だとVisual Cobolとかあるんですが、お金かけてまでCobol導入したくない(笑)。

なので、UbuntuにOpen Cobolをいれることにしました。とはいっても私のPCはWindows10なので、UbuntuについてはVirtualBoxの上にたてました。VirtualBoxのインストールとか、UbuntuへのOpen Cobolのインストールの方法とかはググればわかります。※Ubuntuでsudo apt install open-cobolとかでcobcが実行できるようになります。

 

ほんで、お次はCobol用のエディターにいいのがないかってことなんですが、正直ないです(笑)。よく見るのが、SAKURA editorなんですが、微妙。他の言語の勉強で利用しているVisual Studio CodeCobolの入力補完を入れて利用することにしました。

あとは、Visual Studio Codeのtaskにcobc を実行できるようにtask.jsonへの登録を実施。※基本的にはCOBOL Source colouriser for Visual Studio Codeのdetailsに記載のTask: Single file compile using GnuCOBOL/OpenCOBOL/COBOL-ITを参照しました。

引数に-x, -oを設定した感じです。

{
"version": "2.0.0",
"tasks": [
{
"label": "gnucobol - cobc (single file)",
"type": "shell",
"command": "cobc",
"args": [
"-x",
"${file}",
"-o",
"${workspaceFolder}/cobol/sh/${fileBasenameNoExtension}"
],
"problemMatcher": "$gnucobol-cobc",
"group": {
"kind": "build",
"isDefault": true
}
}
]
}

 

visual studio codeのworkspacefolderには/home/user/source/を指定していてその配下の

cobol/にソースファイルがあり、実行ファイルがその下のshにできるイメージです。

cobolのソースファイル開いて[ctrl] + [shift] +[B]でBuildされます。

 

これで実行ファイルの作成ができるまでの環境ができたので、実際にプログラム書いてみるって感じです。