近未来都市の幽寂

Webポータル事業の企画・構想から公開・運用まで。

403_PostgreSQL・Node.jsの導入

やったこと

PostgreSQLのインストー

LAMP環境(Linux+Apache+MySQL+PHP?)」という言葉にもある通り、WebのOSS・フリーRDBMSと言えばMySQLだというくらい、MySQL知名度は昔っから高かったように思います。
今でこそ、高速で堅牢なマルチスレッド型のRDBとか言われてますが、かつてはトランザクションすらサポートされておらず、商用の選択肢としては難しかったというのが実情ではないでしょうか…
加えて今でも、GPLとコマース用のデュアルライセンス方式、という煩わしい方式を採用しており、商用利用を検討している場合は避けて通るのが無難な気がします。

それに対し、PostgreSQLBSDライセンスなので、商用利用も可能でソース公開義務もありません。
また、最近ではスタートアップ界隈でも人気を博しているようで、確かherokuの標準DBとしても採用されてましたね。
なので、今回のDBはPostgreSQLを採用しました。
(NoSQLとかも流行ってるっぽいですが、今回は見送り)

assign-navi.jp


とりあえず、下記サイトを参考にしながら、PostgreSQLをインストールしました。
調べてみたら、バージョンは9.2.18でした。

www.server-world.info

# インストー
yum install postgresql-server

# 初期化
postgresql-setup initdb

# 起動
systemctl start postgresql

# 自動起動設定
systemctl enable postgresql

# バージョン確認
rpm -qa | grep postgres

ちなみに、MySQLPostgreSQLでは、そのアーキテクチャについて色々と差異はあるっぽいですが、僕にはよく分かりませんでした。

  MySQL PostgreSQL
サーバ
アーキテクチャ
マルチスレッド マルチプロセス
ストレージ
アーキテクチャ
更新型 追記型
拡張機能 ストレージエンジン エクステンション
Disc I/O ランダム シーケンシャル

2大OSSデータベースのMySQLとPostgreSQLの違い(前半) - SSSSLIDE」より引用

Node.jsのインストー

 フロントエンドを支えるJavascriptの技術ですが、近頃はサーバサイドで動くJavascript「Node.js」が色々と取り沙汰されてます。
Socket.ioとの組み合わせで、非同期通信どころか双方向通信まで実現しているんだから、Webの最新技術ってすごい…///

今回購入した参考書では、UIの改善としてCoffeeScriptを使用するらしく、そいつを動かすためにはNode.jsをインストールしなければいけないようです。
理屈は良く分かりませんでしたが、とりあえず騙されたと思って導入しました。
Node.jsのバージョンは6.10.3、npmのバージョンは3.10.10でした。

# EPELリポジトリの追加
yum install epel-release

# Node.js、npmのインストー
yum install nodejs npm

# バージョンの確認
node -v
npm -v

わかったこと

 Railsで使用するDBの設定

Railsでアプリケーションを新規作成する場合、

rails new (アプリケーション名)

とすれば、Railsというフレームワーク用のフォルダ一式が作成されるようです。
そして、Railsでは、上記コマンドで明示的にDBの指定を行わない場合、Railsの標準DBであるSQLiteを使用する設定になるみたいです。
SQLite以外のDBを使用したい場合、上記コマンド実行時、下記の通りのオプションを指定するらしい。

MySQLの場合

rails new (アプリケーション名) -d mysql

PostgreSQLの場合

rails new (アプリケーション名) -d postgresql

他のDBの場合も恐らく同様でしょう。

ターミナルはRLoginが便利

Linuxサーバにssh接続するターミナルといえば、やはりTeraTermPuttyあたりが出てくるのではないでしょうか。
特にPuttyは、キージェネ(秘密鍵の作成)機能も付属でくっついているので、尚更手放せない人もいるかも知れませんね。
僕も色々とターミナルを探しましたが、結局Rloginに落ち着きました。

nanno.dip.jp

 優秀なターミナルだと思ったのは以下の点です。

  • MDIと言うのか?タブ画面分割が便利
  • ウィンドウを半透明化できていい感じ
  • キージェネ(秘密鍵の作成)もできるよ!

まともなRloginのレビューは、murachi1208さんがQiitaの下記記事に書かれております。
ご興味がある方は、ぜひご使用されてみてはいかがでしょう。

qiita.com

つぎにやること

 上流課題がなかなか解消せんな…

402_Railsのインストール

やったこと

OSをCentOS7に変更

引き続き、環境構築中。
元々は「使えた方が後々役立つかなぁ」という思いから、Dockerを使ってスピーディーに開発をするつもりでしたが、下記の点を考えた末に、Dockerの使用を取り止めました。
(完全にド素人の個人的な見解です)

  • Railsをコンテナ化する旨みが分からない
  • 購入した参考書もDockerを使ってない
  • コンテナへの接続がなんかうまくいかなかった
  • なんとなくパフォーマンスが心配(別に大丈夫らしいけど)

最初はDockerを使う気マンマンだったので、Docker用に最適化されたと名高いCoreOSを使うつもりでしたが、その予定もなくなったので大人しくCentOS7をインストールしました。
なお、VagrantのboxはVagrantbox.esのCentOS7.2を適当にチョイスしました。
Vagrantbox.esは非公式boxファイル集なので、使用は自己責任です)

Railsのインストールまで

適当にプロジェクトフォルダを作成し、そこに移動して

vagrant init CentOS7.2(イメージ名)   #初期化
vagrant up   #起動
vagrant ssh   #接続

を実行。ひとまず、取得したboxファイルから仮想環境が構築され、sshで接続できました。
(ちなみに、Gitをインストールした際のGit Bashを使ってます)
VirtualboxGUIで確認しても、環境が実行中になっていることが分かる。

その後は、下記のQiitaの記事を参考にしながら、rootでログインし、とりあえずRailsのインストールまで完了しました。

qiita.com

# パッケージのインストー
yum install gcc-c++ glibc-headers openssl-devel readline libyaml-devel readline-devel zlib zlib-devel

# rbenvインストー
git clone https://github.com/sstephenson/rbenv.git /usr/local/rbenv
echo 'export RBENV_ROOT="/usr/local/rbenv"' >> /etc/profile
echo 'export PATH="${RBENV_ROOT}/bin:${PATH}"' >> /etc/profile
echo 'eval "$(rbenv init -)"' >> /etc/profile

# ruby-buildインストー
git clone https://github.com/sstephenson/ruby-build.git /usr/local/rbenv/plugins/ruby-build

# rubyインストー
rbenv install -v 2.4.1
rbenv rehash
rbenv global 2.4.1

# Railsインストー
gem update --system
gem install --no-ri --no-rdoc rails
gem install bundler
rbenv rehash

 わかったこと

Vagrantfileのネットワーク設定

通常、VirtualboxのゲストOSから、ホストOS経由でネットワークに接続する場合、デフォルトのネットワークアダプター(NAT)だけでなく追加アダプター(ホストオンリーアダプター)が必要です。

d.hatena.ne.jp

Vagrantで作ったインスタンスの場合、VirtualboxGUIからアダプターを追加しても、いざ起動してみるとまったく反映されず困り果てておりました。
これは、どうやらVagrantfileを直接編集して起動する必要があるみたいです。

Vagrantfile

# Create a private network, which allows host-only access to the machine
# using a specific IP.
config.vm.network "private_network", ip: "192.168.33.10" ← コメントアウトを解除する

 この設定で起動すると、無事にホストオンリーアダプターが追加され、ゲストOSからインターネットへ接続できました。しめしめ。

CentOS7以降のNICの名前

下記の記事にも書かれておりますが、どうもCentOS7以降、6までとNICの名前が変更になったようです。

eth0 → enp0s3
eth1 → enp0s8

d.hatena.ne.jp

これには少々戸惑いました。
(boxファイルがおかしいのかと思い、何度かboxを選びなおしているうちに気が付きました。ファック)
まぁ、CentOS7以降は、ifconfigがなくなっていたりcronの仕様が変わっていたりと色々差異があるので、まぁ慣れるしかないでしょうね…

Vagrantのrootユーザーのパスワード

これには本当に参りました。
なんせ、Railsをインストールする際はたびたびroot権限が必要だったわけですが、vagrant標準のvagrantユーザーにはroot権限がない。
そのため、sudoなどでちびちびやってましたが、echoでファイルに書き込む場合はsudoもまったく効かず、完膚なきまでに拒絶されてしまいました。

仕方なく、

su   #rootユーザーへの切り替え

を実行するも、パスワードが分からないから切り替えれない。
何度かアクセスを試みた結果、Vagrantのrootユーザーのパスワードは

vagrant

であることが判明。
マジかよ。脆弱すぎる。速攻でパスワード変えた。
(ちなみにvagrantユーザーのパスワードも同様でした)

つぎにやること

うーん、今は環境構築が楽しいので、構築系以外は後回しにするかも。
というか後回しにします。
環境構築編、まだまだ続きますよー

 

401_ローカル仮想環境の構築

やったこと

VagrantでCoreOSインストー

要件定義がダレてきたので、気分転換に環境構築をしておりました。

もともとVagrantの存在は知っていたけど、VirtualBoxがあれば普通に仮想環境自体は構築できるので、Vagrantの旨みって何?というところから始めなければなりませんでした。
その辺の情報は、下記サイトを参考にしました。

dev.classmethod.jp

mag.osdn.jp


実際の構築では、下記のサイトを参考にしました。

github.com


途中、何度もエラーで躓きました。
どうやら、VagrantVirtualBoxのバージョンに依るものらしく、Vagrantの最新バージョンを入れなおしたらあっさり直りました。

書籍の購入

僕にはWeb開発の実績が全くなかったので、「そもそもWeb開発ってどうやるの?」という、致命的な部分が分かっていませんでした。
それを理解するために、とりあえず下記の書籍を購入しました。

www.amazon.co.jp

www.amazon.co.jp

この書籍は凄くいいですね、僕自身も使う予定であるRailsをつかって、実際のWebサービス(顧客管理システム)を作る方法が、順を追って丁寧に解説されています。

ちなみに、Kindle版を購入しました。
これで、重い本を持ち歩かずに、PCでもスマホでも閲覧できます。素晴らしい。

ポータブルディスプレイの購入

元々外付けディスプレイを持っていたので、基本的に作業はデュアルでやっておりました。
が、先日外付けディスプレイの解像度をイジって遊んでいたら、突然画面が不気味に蠢き始め、死亡してしまいました。ヘタなホラー映画より怖かったです。
まぁ、日本橋で5000円で買った中古のモニターだったので文句は言えませんが…

その後は、PC机の隣に置いているTVをHDMI接続で使っていましたが、やはりTVはTVなので、普通にPC用の外付けディスプレイが欲しくなりました。

僕は基本的にコワーカー気取りで、よくカフェやコワーキングスペースで作業しているのですが、「持ち運びできる外付けディスプレイが欲しい」というのが正直な所でした。
そこで、値段やサイズを鑑みて、下記のディスプレイを購入しました。

www.amazon.co.jp

画面サイズは思ったより小さく、自宅で使用する場合はビミョーです。
が、ポータビリティは文句なし。
こっちとしてはKindleが見れればよいので、まぁよしとしましょう。

 

わかったこと

インフラストラクチャー・アズ・コード

正確には「少しわかったような気になった」だけです。
正直、vagrantの旨みは今一つ分かっていない。
ただ、vagrantfileに設定情報やらなんやらが書かれています。
このような情報は、単にVirtualBoxでISOイメージからOSをインストールする方法では閲覧できないようなもののような気がします。

Vagrantはインフラアズコードなのかー、と感心していると、次のような記事を見つけました。

simplearchitect.hatenablog.com

はてなの牛尾さんという方のブログです。
この内容を読んでもさっぱり分からない私は、牛尾さんよりも遥かにInfrastructure as Codeを理解していない、ということは間違いないでしょう。

サイトマップやラフデザイン作成は時間がかかる

本当にこれに尽きます。
既存のサービスを参考にしようと、様々なサイトを見ていましたが、まだまだ細かい所を詰め切れてません。
次のブログ更新時は、こちらの情報を書きたいところ…

つぎにやること

テンプレートの検討はもうちょい先かな…

102_技術要件

やったこと

使用技術の選定

プログラム言語 … Ruby
フレームワーク … Ruby on Rails
CSSテンプレート … Bootstrap
CIサービス … Shippable
資源管理 … Git + Bitbucket
課題管理 … TrelloまたはRedmine

サーバOS … CoreOS CentOS7
仮想化技術 … Vagrant + Docker
Webサーバ … NGINX
DBサーバ … PostgreSQL

検証環境 … VirtualBox
本番環境 … AWS(EC2)

とりあえず、ざっと選定してみました。
Ruby on Railsは以前から勉強したかったので、もはや絶対条件。
Githubのプライベートリポジトリは有料らしいので、無料で出来るBitbucketを使用しようと思ってます。
CIはJenkinsを勉強のために使おうと思ってたんですが、そのためにCIサーバを立てるのも面倒くさいので、ShippableというCIサービスを利用する予定です。
Trello・Redmineは正直使うかどうか、今のところは超絶怪しい…面倒くさくてやめちゃうかも。→やめましたw

WebサーバはApacheではなく、高速かつ軽量なNGINX。
DBサーバは商用利用が無償のPostgreSQLMYSQLはライセンス体系がややこしく、商用利用の場合はたぶんライセンス料が必要)。

本番環境として、レンタルサーバーVPSという選択肢はありませんでした(もう使ったことがあるので)。
HerokuにするかAWSにするか正直迷いました。というか今でも迷ってます。
勉強のためにはAWSがいいんでしょうけど、全ては料金シミュレーション次第ですな…

2017/6/28
Dockerの使用を取り止め(Railsをコンテナ化する旨みを感じなかったので)。
それに伴い、OSもCoreOSからCentOS7へ変更。
なお、技術要件は今後も予告なく変更する可能性があります。

非機能要件の見直し

以上を踏まえ、前回のエントリーの非機能要件について見直しを行いました。


機能性(合目的性やセキュリティなど):
セキュリティはAWSのS3まかせ。
せめてSSL証明書は購入する予定。

信頼性(高負荷に対するタフさ):
AWSでスケールアップするなりして、
適当にチューニングする。

使用性(使いやすさ):
可能な限りシンプルなデザインに。
もちろんレスポンシブデザインで。

効率性(スピード、ムダの無さ):
開発速度はRailsまかせ。
処理速度はチューニング次第かと。

保守性(修正・機能拡張のしやすさ):
Railsの力を信じる。
後は内部設計で配慮するか。

移植性(別環境への移しやすさ):
VagrantとDockerがあれば移植は容易かと。

障害抑制性(バグりにくさ):
Gitの資源管理をしっかりやれば…
これは実装する自分の実力次第かな…

効果性(システムの費用対効果):
収支を概算する必要があるが、
まだやってません。

運用性(運用の容易さ):
Shippable使ったことないから分らんが、
本番環境の管理は確かに課題になってくる気がする。

技術要件(実現方式や開発方式など):
上記の通り。


はい。

時間の無駄でした。

わかったこと

知らないことが多すぎる

非機能要件はさておき、選定した技術についてはほとんど全てが未知の世界。
正直、書きながら「これ本当に全部やるのか…」と感じていました。
しかし、今回の目的は趣味と勉強のためなので、やるっきゃない。
本を読んだり、プロトタイプを作ってポチポチ動かしてみたり、少しづつできる技術の幅を増やしていこうと思います。

最終的に必要なサーバは3つ?

検証環境はローカルの仮想環境で賄えるので常時稼働用のサーバは必要なく、本番環境のサーバが一つあれば事足りそうな気がします。
しかし、法人としてサービスを展開していくのであれば、

  1. 本番環境用のサーバ
  2. 社内管理用のサーバ
  3. 会社HP用のサーバ

という、最低でも3つのサーバが必要なのではないか、と朧げながら思案中。
まぁ、2と3は一つのサーバにまとめることが出来なくもないですが。

つぎにやること

101_機能要件・非機能要件

やったこと

機能要件

e-words.jp

www.sangyo-rock.com


本業であるSI業において、要件定義の工程は何より重視されています。
顧客の要求事項をもとに、その実現要否および実現方法を整理して合意形成していくプロセスですね。
この工程を疎かにしてしまうと、後続の工程で頻繁に仕様変更が発生したり、フタを開けてみると顧客の思いとかけ離れたシステムができあがってしまったり…。
炎上・デスマという泥沼の様相を呈する原因になりかねません。
僕が従事している会社でも度々見られる光景で、最悪の場合はリリースできずに訴訟沙汰になります。

なので、要件定義が重要だという話は身をもって知っているわけですが、自前のWebサービスとなってくると話は別です。
なんせ、あれこれ言ってくる顧客はいない。
強いて言うなら想定出店者および想定購買者ですが、実際に公開してみたところで、使ってくれるかどうかも分からないサービス。
であれば、上流であれこれ考えず、自分の好きなものを作ろうと思います。
(一応、実現したい機能は、何となしにまとめた)

非機能要件

e-words.jp

itpro.nikkeibp.co.jp

機能要件に大して、非機能要件の方は何かと手薄になりがちですね。
機能要件が「顧客の要望を要件として定義付けしたもの」であるのに対し、非機能要件というのは「機能面以外のすべて」を指す、非常に便利で厄介な言葉だからです。

JUAS(日本情報システムユーザー協会)の「非機能要件要求仕様定義ガイドライン」によると、非機能要件は下記の10種類に分類されるようです。

  • 機能性(合目的性やセキュリティなど)
  • 信頼性(高負荷に対するタフさ)
  • 使用性(使いやすさ)
  • 効率性(スピード、ムダの無さ)
  • 保守性(修正・機能拡張のしやすさ)
  • 移植性(別環境への移しやすさ)
  • 障害抑制性(バグりにくさ)
  • 効果性(システムの費用対効果)
  • 運用性(運用の容易さ)
  • 技術要件(実現方式や開発方式など)

なるほど。こいつは面倒くさい。
Webサービスを実現していくに当たって、どんな言語やフレームワークを使用するのか、どんな環境を使うのか、技術要件を詰めていくことで自ずと定義づけしていけそうな気がするので、その辺の話は次回に回すとします。

わかったこと

要件の重みのギャップ

「SIでは要件定義がすべて」これは真理だと思います。
ただし、自前のWebサービスの場合、要件定義がふにゃにゃしていてもそれほど怖くはありません。
多人数で開発する場合ならいざ知らず、自分一人で開発するだけなら仕様変更もリリース延期も怖くない、気楽なモンです。
そんなことよりも、早く作り始めたい。

でも技術要件(環境定義)は大事

今回は後回しにしましたが、どの環境でどういう風に作りたいか、その辺はしっかり詰めていく必要があるかと。
ただし、作っていく過程で「なんか違うな」とか「これじゃダメだな」とか感じる部分が恐らく出てくる予感がしています。
なので、技術要件はとりあえず決め打ちにして、何かあったら技術要件を変えてしまえばいいと思ってます。
やったことがない技術分野なので、トライアンドエラーになるのは防ぎようがないことですが、なるべく下調べをして、可能な限り手戻りの少ないようにしたいと思います。

つぎにやること

  • 技術要件の検討

001_コンテンツ企画

やったこと

コンセプトメイキング

そもそも、どんなサービスを実現して世の中に流布したいのか?
こいつがないとお話にならない。パターンとしては、

  • 現時点で存在しないもの
  • 現時点で存在するが不満があるもの
  • 組み合わせると凄くなるもの

なんかがあるかもしれない。
僕の場合は、

「ECモール」+「ITトレンド」

というコンセプトが割と最初からあったので、考えるのは楽ちんでした。
そんなもんコンセプトじゃねーよ、という声が聞こえてきそうですが、本当はもうちょっと具体的で、あえて意味もなくボカして書いてます。
というか、そんなに考えてません。

競合分析

同じようなことやってるサイトはあるかなー?とネットを徘徊していると、ありそうでないんですよね。なので、とりあえず作ってみようと思います。

なお、ECモールとしてはAmazon楽天市場、ヤフショ、ポンパレあたりが有名どころでしょうか。
こちらとしてはほとんど趣味でやるような感じなので、出店者のイニシャルコスト、ランニングコストはなるべく低く設定しようと思います。
せめてサーバー代くらい賄える利益があればそれでいいや。その辺は気分次第で変わるかも知れんけど。

ちなみに、中野翔太さんという方が、2017年度版のECモール比較をされています。
ご興味のある方は訪問されてみてはいかがでしょう。

nakano-ws.com

ペルソナの設定

smmlab.jp

正直、めんどくさいのでやってません。
本当はやった方がいいんでしょうけど。

わかったこと

スピードこそ我が人生

ずっと以前から構想はあったので、今はなるだけ早く形にして公開したいと思ってます。
上流こそしっかり詰めろ、とは本業でも痛いほど言われてますが、ここは僕の趣味の世界。
「完全を求める」のではなく「完遂を求める」という姿勢で、多少機能が不十分でも、絶対に公開までもっていきたいところです。
公開するのが大事だという事は、ランサーズの社長である秋好陽介さんもおっしゃっています。

www.web-20.net

ポータルサイトは難しい

聞き苦しい言い訳かもしれませんが、ユーザーが多数集まっていることが前提のポータルサイトは、ユーザーを集客するまでの期間、ユーザーに何を体験してもらうか?という部分が非常に難しい、と感じました(今回は一応考えています)。
僕が敬愛しているブロガーのmegamouthさんも、ブログの中でこういった記事を書かれています。

www.megamouth.info

非常に秀逸な記事で、webサービスを作ろうと、目を¥マークにして画策されている皆様は、ぜひご一読されることをお勧めします。

つぎにやること

  • 要件定義的なこと

901_当ブログについて

再開のお知らせ

はじめましての方ははじめまして。
大阪の某IT企業でSEをしているみうらです。

当初このブログは「悪鬼羅刹の技術録」というタイトルで、自身の勉強のために、色々技術録的なものを書いて行こうと思っておりましたが、公私共々忙しかったため完全に放置しておりました。
が、最近は時間が取れそうになってきたので、ぼちぼち再開しようと思います。
どうでもいいけど、タイトルも思い切って変えました。

投稿内容

「悪鬼羅刹の技術録」を書いていた時は、

と、曜日別に勉強する内容を分けてブログを書こうと思っておりましたが、そんな器用なマネができるハズもなく、結局ほとんど何も書けませんでした。

その時の反省を活かし、当ブログではとりあえずWebポータル事業の構想・設計から公開・運用に至るまで日々の作業とその苦悩を綴っていこうと思います。

投稿頻度については、「悪鬼羅刹の技術録」のルールと同じく、勉強が少しでも進んだ場合、または少しも進まず詰まった場合でも、とりあえず1行でも書くように心がけていこうと思います。

投稿ルール

カテゴリー

0_SP_企画構想
1_RD_要件定義
2_ED_外部設計
3_ID_内部設計
4_EC_環境構築
5_PG_製造
6_IT_検証
7_RL_移行
8_OP_保守運用
9_XX_管理など

記事タイトル

{カテゴリー番号}+{連番}+"_"+{記事概要}

見出し

  • やったこと(実施内容)
  • わかったこと(所感・随想)
  • つぎにやること(ToDo)

 

管理人について

経歴

大学・大学院で数学について学ぶも、一番の学びは「自分には数学の才能がない」ということ。
それまでプログラミングの経験は一切なし。

卒業後は大手SIerに就職し、業務アプリのエンジニアとして職務に従事。
入社2年目くらいで仕事に飽きてきたため、副業を模索した結果、不動産投資と暗号通貨投資、少人数私募債などの投資で日銭を稼ぐことに成功。
MLMや物販は向いていないらしい。というか嫌い。

そこそこの副収入ができたので仕事を辞めようか検討していた矢先、社則が副業OKとなり路線変更。
とりあえず会社員やりながら、兼ねてからの夢であるWebポータル事業を立ち上げようと画策中。

技術

仕事で使用していた言語は、COBOL、C、VB6という化石のようなレガシー言語のオンパレード。
オブジェクト指向フレームワーク?何それおいしいの?
一応Javascriptphpについては知ってる程度だが、総じて技術力は低い。

DBはOracleSQLserverMysqlを少々。
メインフレームではISAMという謎のファイルを使用。
CRUDできればいいんでしょ?DDL?知らねw

アプリエンジニアでありながら仕事の行きがかり上、JP1やArcserveなどのミドルウェア、はたまたネットワーク構築やサーバーラッキングまで手掛ける羽目になる。
インフラの味を占め、Linuxについて独習し、VPSで簡単なLAMP環境くらいなら作れるレベルになった、インフラ寄りのアプリエンジニア。
(むしろ今ではインフラの部署に行きたい)

 

おわりに

大した内容にはならないかも知れませんが、書いた内容が少しでも、技術者、またはWebポータルサイト構築を夢見る若者の目に止まる物になるよう頑張ります。
なので、どうか温かい目で見守っていただければ幸いです。