AWSCloud9でrailsサーバーを起動する

CodeStarを使って、AWSCloud9でWEBサービスを開発しようとしたところ、いきなりつまづいたのでメモ。rails serverで起動した後、実際のページにアクセスするためには、Preview→Preview Runnning Applicationsを押すと、タブで、ページが開く。AWSCloud9上のタブ画面には何も表示されないので、気づかなかった…

URLをコピーして、ブラウザのタブにコピペするとアクセスできる。

URLを見ると、こんな構成になってました。

【URL構成】

https://[cloud9インスタンス名の末尾].vfs.cloud9.[アベイラビリティゾーン].amazonaws.com/

ちなみに、インスタンス名の構成は以下。

aws-cloud9-[プロジェクト名]-[インスタンス名の末尾]

ローカルPCで環境作るのと比較すると、全然スピード違いますね。AWSすごい。

どんどん勉強しよう。

【Javascript】jsonオブジェクトの作り方

javascriptでjsonオブジェクトを生成したい時の書き方で、つまづいた際に、ネットで調べると、json文字列からオブジェクトへのパースの記事が多く、欲しい情報が得られず、自力でたどり着いたのでメモ。

var json = {};

これで空のjsonオブジェクトができる。

要素を追加したいときは以下のように書く。

json.tsuikadayo = "追加"

こうするだけで、以下のオブジェクトになっている。

{tsuikadayo: "追加"};

javascriptのjsonってかなり扱いやすいのね。

配列の追加なんかも上記の要領でやれちゃいます。

OSS-DB Gold 受験 合格体験記

OSS-DB Silverの合格から1ヶ月弱、2回目のOSS-DB Goldを2回受験し、遂に合格しました！！本当に長く辛い戦いだった。

＜受験概要/受験結果＞
受験科目：OSDBG-01 OSS-DB Exam Gold
受験言語：日本語
出題形式：単一選択、複数選択
合格点　：70点（30問中21問正解）
試験時間：90分（同意書・アンケート含む。試験は80分程度）
勉強期間：2017/8/1〜2017/8/25　勉強時間は、約50時間程度
勉強方法：独学
実務経験：大規模金融システムにて、業務AP開発を進める中で、SQLは深い知識あり。

	受験概要 1回目	受験概要 2回目
受験日	2017/8/21（月）	2017/8/26（土）
合　否	不合格	合格
スコア	60点（30問中18問正解）	90点（30問中27問正解）
運用管理	44%	66%
性能監視	77%	100%
パフォーマンス チューニング	66%	100%
障害対応	50%	100%

＜使用教材＞
以下４つを使用しました。

内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design plus)

LPI-Japan OSS-DB Gold 認定教材 PostgreSQL 高度技術者育成テキスト

https://www.istudy.co.jp/e_learning/istudy-for-oss-db技術者-oss-db-gold

＜勉強方法詳細＞
まず、内部構造の本を読み込み。ただ、この本には問題集がないため、力がついたのかどうか定かではありませんでした。ただこのとき、レプリケーションだけは、実体験が必要だと判断し、家のパソコン2台を使って、ちゃんと環境構築、動作確認を経て、勉強しました。自分の参画していた開発PJでもDB2でレプリケーションを組んでいましたが、他の誰かが構築したものだったので、手触り感がなく、ここは重要だと思って一生懸命勉強しました。

その後、公式教本で、勉強し、章末問題を2回ほど解きました。その後は、istudy→公式教本→公式サンプル問題→istudy...と無限ループを繰り返し、正答率90%が定着したところで1回目の受験。

結果、撃沈しました。あれだけ問題を解いたのに、頭が、真っ白になるような問題ばかりでました。istudyでは非対応が正解だったはずのチェックサムの問題がやたら出るし、聞いたこともない用語もでるし、一体どうなってるんだ、、、と思い、帰宅後、徹底的に分析しました。

公式に公開されてる試験範囲と、公式教本に記載されてる試験範囲を突合して、差分（公式教本に乗っていない試験範囲）を検証したところ、私が悶絶した問題のほとんどが、差分に該当するところでした。

そう、公式教本やistudyは、最新の出題範囲に対応してないのでした。
ということで、差分のところをマニュアルで調べて、徹底的に学びなおしました。
これは相当効果があったと思います。
その証拠に、たった４日間にちょろっと勉強しただけで、一気に９０点合格！
出題傾向が変わったわけではないので、対策効果ありということです。

OSS-DB Gold最大の参考書は、「試験範囲」です！！教本で一通り勉強して、試験範囲で弱点を分析し、しっかりマニュアルで押さえていけば、確実に合格できます！！

＜キーワード＞

OSS-DB Gold,ossdb,合格者,認定者,Gold認定者,Silver認定者,Gold合格者,Silver合格者

OSS-DB Silver 合格体験記

会社で昇進するためにも、社内認定資格が必要で、その社内認定資格の受験のために、各種資格が必要となるため、現在、OSS-DB Goldの取得を目標に勉強しています。

OSS-DB Goldを取得するためには、OSS-DB Silverを取得する必要があるという仕組みになっていたので、今回まずは、OSS-DB Silverを受験し、一発合格しました。

この資格を必要となったのは、2016年10月と2017年4月と、応用情報技術者試験に２回も落ちたためでした。１回目は、まったく勉強せずに行って、午前が１問たらず…午後は自己採点ですが、楽勝。２回目は、午前はしっかり勉強し、午後も過去問少し解いて、臨んだものの、今度は、午後が１問たらず…。

勉強しても応用情報すら合格できないような、こんな私が、OSS-DB Silverは合格できました！！バンザーイ！！

＜受験概要＞

受験日　：2017/7/30（土）

合　否　：合格

受験科目：OSDBG-01 OSS-DB Exam Silver

受験言語：日本語

スコア　：82点（50問中41問正解）

合格点　：64点（50問中31問正解）

出題形式：単一選択、複数選択

試験時間：90分（同意書・アンケート含む。試験は80分程度）

勉強期間：2017/6/27〜2017/7/30　勉強時間は、約50時間程度

勉強方法：独学

実務経験：大規模金融システムにて、業務AP開発を進める中で、SQLは深い知識あり。

＜セクション毎の正解率＞

一般知識：87％

運用管理：69％

開発/SQL：100%

＜使用教材＞

以下４つを使用しました。

OSS教科書 OSS-DB Silver

徹底攻略 OSS-DB Silver問題集［OSDBS-01］対応 (ITプロ/ITエンジニアのための徹底攻略)

ITトレメ OSS-DB技術者認定試験 Silver − ＠IT自分戦略研究所

＜勉強方法詳細＞

• まず、１週間ほどで、緑本を模擬試験以外制覇。運用管理関係のところは、実際にバイナリからインストールして、動かしながら覚えていきました。
• 黒本をゆっくり２週間ちょいかけて、模擬試験以外を１周制覇（この期間は、毎日勉強することはできず、最後の方に一気にやった感じです。）
• 最後の１週間で、黒本で弱かった科目を、緑本で復習した上で、もう一度解く。以下のような感じで推移しました。

  章	１回目	２回目
  第１章	72.8%	77.3%
  第２章	62.5%	50.0%
  第３章	40.0%	93.4%
  第４章	73.9%	-(2回目なし）
  第５章	63.7%	81.9%
  第６章	54.2%	91.7%
  第７章	47.7%	85.8%
  第８章	29.5%	64.8%
  第９章	20.0%	86.7%

• 通勤時間を使って、ITトレメの99問を全て解きました。（ちゃんと集計してないですが、8割くらい正答できました）
• 次に、黒本の模擬試験を実施。72.0％で合格ライン到達。間違えた問題を復習。
• 受験前日の7/29、公式サイトのサンプル問題を、全て解きました。間違えた問題を復習。
  

  一般知識	運用管理	開発/SQL
  100.0%	65.4%	68.5%

• そして、受験当日の7/30に、緑本の模擬試験を実施した結果、61.7％と、合格ラインを割ってしまいました…。正直冷や汗かきましたが、とにかく復習！！
• その後、今まで間違えた問題をひたすら復習しました。
• 会場に移動するまでの間、緑本の巻頭付録のチェックシートをひたすら読み込みました。

＜受験本番＞

緑本より、黒本よりの出題形式だったと思います。受験前に、緑本の心得は読んでいったほうがいいです。出題意図を踏まえると、どれが最も回答としてふさわしいかという観点で、消去法しないと解けないような問題が多かったです。

自信がない問題には、ひたすらチェックをつけて、最後解き終わった後に、数を数えると、15問ありました。ということは、合格ラインにはいってそうだ！と思ったので、そこから、15問をさらに熟考し、幾つかは回答を改めました。この時、多分いくつか正答が増えた気がします。

今回、どうしても今月中に受かりたかったので、最後の模擬試験がダメな状況で、受験しましたが、上記の勉強方法でやり、さらに、完璧な状態に持っていけば、まず間違いなく合格できると思います。

最後は、とにかく問題演習の反復あるのみ！！

＜今後について＞

次は、目標であるOSS-DB Goldの8月中合格を目指して、勉強します。

OSS-DB Silverでは、途中、勉強を全くしなかった期間が続いたので、今回は計画立てて、継続的に学習して、なんとか合格したいが・・・イケるのか？俺！

ちょうど、仕事も変化がある時期で、多忙ですが、頑張ります。

pythonのif文

pythonの文法を一切学ばないまま、pycharmで書き始めていたら、あるif文で、「Remove redundant parentheses」と怒られた。

if (row[2] == '数'):

ちゃんと英語が読めれば、即わかることなんだが、「不要な括弧を削除しなさい」というお叱りだったらしい。pythonでは、if文の条件に括弧を付けても動くが、括弧をつけるのは間違いということのようだ。

if row[2] == '数':

ちょこちょこ備忘を溜めながら、ある程度ノウハウがたまったら、文法を整理してみようかな。

Pythonで日時表現正規化のAPIを作りたい（環境構築編１）

APIを作ろうと思った経緯

2017年3月に、LINE BOT AWARDSに、秘書Botというスケジュール共有機能を提供するBotを作って、応募しましたが、見事に撃沈しました。笑

機能の概要としては、Botを含むグループトークで、スケジュール調整をした結果、最終的に、開始日時と終了日時、予定の名称を含む、発言をすると、Botが拾って、スケジュール登録をするか否かのお伺いを立ててきて、グループメンバの誰かが、OKボタンを押下すると、グループメンバ全員のグーグルカレンダに登録されるというものでした。

もともと、この機能で応募しようと思ったきっかけは、夫婦間でLINEを通じて約束した予定を、私が忘れてしまいがちで、よく迷惑を掛けていたので、それを解消するために作りました。ちょうど、仕事で、go言語を使っていた時期だったので、go言語で組んで、日時表現や予定の抽出のために、フリーのAPIを使っていましたが、日時表現については、なかなか自分の思い通りの結果を返してくれるAPIがなく、不満を持っていました。

そこで今回、日時表現正規化のイケてるAPIを自作して、秘書Botを賢くしたいと思いたちました。自然言語処理といえば、Pythonがよく使われてる様子なので、まずは、Pythonとmecabを入れて、いろいろ試して、作っていきたいと思います

Python3のインストール

まずは、Python3をインストール。osはmacで、homebrewが入ってる前提ですが、コマンド一発で終わります。

brew install python3

Pycharm(IDE)のインストール

PythonのIDEもいろいろあるようですが、go言語の時に使ってた、Goglandが結構気に入ってたので、IntelliJのPycharmにすることにしました。

www.jetbrains.com

Pycharmの日本語化

やっぱり日本語化されてた方が使いやすいので、日本語化しました。以下に詳しく手順が載っているので、そのまま実施。

qiita.com

mecabのインストール

これもコマンド一発。

brew install mecab-ipadic
||< 

インストール後は、ターミナルでmecabと打つと、mecabを使えるようになる。
>|sh|
$ mecab
これはテストです。
これ	名詞,代名詞,一般,*,*,*,これ,コレ,コレ
は	助詞,係助詞,*,*,*,*,は,ハ,ワ
テスト	名詞,サ変接続,*,*,*,*,テスト,テスト,テスト
です	助動詞,*,*,*,特殊・デス,基本形,です,デス,デス
。	記号,句点,*,*,*,*,。,。,。
EOS

こんなかんじ。

Pythonでmecabを使えるようにする。

Pythonでmecabを使えるようにするには、natto-pyって奴をインストールする必要があるようです。Python3をインストールした段階で、python用のパッケージインストールのためのコマンド（pip3）が使えるようになってるはずなので、これもコマンド一発でいける。

pip3 install natto-py

Pythonでmecabを使ってみる。

最後に、Pycharm上で、以下のコードを書いて、ctrl+Rで実行してみます。

# coding: utf-8
from natto import MeCab

mecab = MeCab()
text = "今週、金曜日"
print(mecab.parse(text))

結果は以下のとおり。

/usr/local/Cellar/python3/3.6.1/Frameworks/Python.framework/Versions/3.6/bin/python3.6 /Users/hoge/PycharmProjects/practice/practice1.py
今週	名詞,副詞可能,*,*,*,*,今週,コンシュウ,コンシュー
、	記号,読点,*,*,*,*,、,、,、
金曜日	名詞,副詞可能,*,*,*,*,金曜日,キンヨウビ,キンヨービ
EOS

プロセスは終了コード 0 で完了しました

これで、pythonでmecabが使えるようになりました。
思ったより、すんなり環境構築が出来ました。本当最近は、何でもコマンド一発でできて便利です。
この環境でいろいろいじってみて、APIのアルゴリズムが見えてきたら、続きを書いてみようと思います。

ソースコード自動生成やテスト自動化等の開発自動化を推進したPJほど、維持管理フェーズで生産性は飛躍できる！

僕が参画したPJは、大規模な金融系システムで、数十年ぶりの全面更改案件だった。設計書からソースコードを自動生成するツールを適用した開発や、テスト自動化の取組など、自動化を推進した先進的なPJだと評された。

ソフトウェア開発自動化は、ある程度大きいSIerなら、どこでも取り組んでいる施策だが、どこのSIerも期待通りの効果が得られず、パッとしないのが現実。でも適用したこと自体が、成果のように社内で報告されるため、その闇の部分には光が当たらず、名ばかりの自動化開発プロセスが、イタズラに作業を増やし、現場を圧迫し、維持管理フェーズに入ってからも、十分な利益が上がらないPJ運営が続く。案件を受ければ受けるほど、辛くなるという、最悪の状態になる。

でも、僕は、自動化開発プロセスを多く採用したPJは、維持管理フェーズで、ドル箱になるチャンスを大いに秘めている。それが開花しない原因は、「導入しっ放し」で終わらせてしまうことにあると考えている。

その問題点を明らかにしつつ、実際に取り組んできた改善と、今まさに取り組もうとしている改善について論じて行きたいと思う。自動化をやりきった感が蔓延るPJで、さらなる原価削減の使命をもつPMの方や、非効率な作業に頭を抱える現場のSEの方が、今を変える一助にきっとなるはず。

一般的に、自動化の生産性向上効果はないと言われる理由

ソースコード自動生成ツールの仕組は、設計書をインプットにソースコードをアウトプットする。というものだ。だから、設計書の情報をソースコードが吐き出せるレベルに詳細化し、ソリューションが解釈しやすいように、構造化する必要が出てくる。

担当者は、設計書の記述ルールを覚える必要があるし、ルールに沿って記述する必要が出てくる。結局は、「ツール専用言語によりコーディングするに等しい労力」が必要になる。ゆえに、普通にコーディング出来る技術者からすれば、鬱陶しい限りだし、プログラミングができないとキチンとした設計もできないので、誰でも出来るわけでもない。また開発期間についても、製造の作業が設計に寄るだけで、本質的な生産性向上には繋がらない。更には自動化といいつつ、実際は半自動化だ。業務ロジック部分はの設計は、ツールは解釈できない。完全に自動生成できるのは、DTOなどの構造化された設計だけ。その解釈できない部分は、人間が作業で補う。僕のPJでは、まさにツール専用言語があり、設計書の通りに、コーディングする作業がごっそり残っている、半自動化PJだった。そのため、設計書どおりに実装されていることを確認するUTレベルの試験も、全てやる必要がでてくる。はっきり言って、生産性向上への直接的な寄与はないだろう。

それでも、品質が重要な巨大PJでは選ぶ理由になる

自動化なのに、生産性向上に寄与しないなら、選択する意味がないじゃないか！というのが、よくある批判であり、直接的な生産性の観点では、そのとおりである。それでも現実に適用するPJがでてくることは、政治的理由もあるだろうけど、実質的な効果もあるからだと、僕は思う。例えば、自動生成は、自由度が低いため、設計思想からの逸脱した実装の防止や、コードの標準化を実現できる点は、評価できると思う。特に僕の参画したPJでは、言語のネイティブライブラリは介さず、FWのライブラリを使用することで、言語のバージョンアップ時の影響から保護しようという発想の設計思想だったので、こうしたライブラリの選択なども制限できていた。もちろん他にも方法はあるとは思うが、数百人規模の開発で、実装を標準化できた事実もあり、このこと自体は否定できない。大型案件の開発で、品質確保を実現することは、口で言うより難しい。金融系の重要なシステムであれば、通常レベルの生産性で、高品質を実現できるのであれば、効果あると言わざる得ない側面もある。日々、開発に勤しむSEの方はよくよくお判りだと思いますが。PDCAなどと言いますが、P（計画）はいい加減、D（実行）は人海戦術でのりきる、C（確認）は疎かゆえに、繰り返し、問題が生じた事後のA（対処）は、迅速。皆様もそんな現場なのでは？

ソース自動生成適用PJで、生産性が上がらない理由は簡単。ソースが自動生成されないからだ！

ソースコード自動生成ツールは、品質面での寄与しかないと言ったが、それは結果論。導入時には、PMが期待する主眼は、生産性の向上にある。そもそも、設計書を必要としない案件において、自動化適用した場合、設計書執筆は純増作業になるが、設計書が必要な案件においては、その増分は問題になるほどではない。では、問題は何かと言うと、ツールだけで100％自動生成できないことである。僕のPJでは、以下の手順で製造を行う。

1. 設計書をツールに食わせると、新たな設計書が生成される。
2. 元の設計書に記載された通りに、人間が業務ロジックをツール専用言語を使って、新たな設計書にコーディングする。

つまり、ツールが解釈できない設計書の内容があるから、結局は人間が作業を埋める必要がある。100％自動生成できず、人間の作業が入るので、UTも省略することができない。結局は、ちょっとした便利ツールの範疇の効果しか実現できてないツールになっている。基本的に、企業の本部施策の自動化ツールは、いろいろなPJに適用できるよう、汎用的に設計された上で、ある程度の個別カスタマイズができるようになっている。もちろんツールにJustFitするようなシステム、させられるシステムであれば、100%自動生成を最初から実現することもできるだろう。しかし、現実は、以下のような壁があり、開発中にリアルタイムに100%自動生成には持っていけない。

1. 新しいシステムを構築する場合、新しい設計思想が適用されており、実装が定まりきってない部分もあり、設計と実装を紐付けることが難しい。
2. 個別カスタマイズには、社内取引で、ツール開発部署の要員を雇って、進める必要があるが、その費用が捻出できない。
3. 仮に、費用が捻出できたとしても、ツール開発部署要員は、現場を知らない理論重視の頭でっかち。現場の課題を分析して、リアルタイムにカスタマイズを行うようなスピーディで柔軟な対応はできない。

このような感じで、自動生成が達成されることはなく、半自動生成にとどまる。だから生産性があがらないんだ。

ツール開発部署は、導入したら終わり。でも自動生成率の向上は、導入した後にこそ実現性が高まる！

 僕の会社のツール開発部署は、導入部隊だ。導入して、開発が終われば、PJから去ってしまう。しかも、ツール開発部署のサービスとして、アフターフォローのメニューもない。もともと、導入した後により良くするという概念を持たない組織が、ツールを開発してしまってる。その影響を受けて、PJ側も「自動化はやりきった」と勘違いしてしまう。でも、僕のPJで自動生成できない部分をどのように補っていたか思い出してほしい。「設計書に記載された通りに、ツール専用言語でコーディング」していたんだ。設計書に書いてあるのに、ツールが解釈できないので、人間が作業で埋めていたということだ。ということは、ツールが解釈できれば、人間の作業を排除できるんだよね。僕のPJの場合、製造／単体試験の工程が、全体の3割くらいを占めてるので、これを仮に100％自動生成にもっていくと、30％の原価削減、利益向上に繋がることになる。これだけ聞くと、理想論だと思われそうだけど、実際そうでもない。ソースコード自動生成を導入したPJの設計書は、かなり精緻だ。そして、維持管理フェーズでは、その設計書に対応するソースコードも全てある。設計書とソースコードを分析していけば、自動生成できるポテンシャルが相当量あることに、気がつくはずだ。この分析を徹底的にやって、今より自動生成の幅を広げることは、確実に出来る。ここを無理だと諦めず、リソースをつけて、しっかり検討することで、維持管理フェーズはドル箱パラダイスに生まれ変わることができる！！

今日はここまで。次回は、テスト自動化を題材に、自動化に関する問題点と、実際に僕がPJで実施し、効果がでた改善策を書いてみようと思います。