【Python】【予約フォーム】AWS上でなるべく安くwebサービスを作ってみる

概要

AWS(Amazon Web Service)を始めようと思ったけど料金体系とサービスが複雑で分かりづらい！と思ったので、安く始めるために調べました。実際に筆者もまた新たにサービスを作るので、筆者の場合のプランについて説明します。

AWSについては

qiita.com

qiita.com

このあたりに分かりやすくまとまっています。

正直、公式HPを見ても情報が多すぎる上にあまりまとまりがないように見えて、そこだけですべて理解するのは難しいです。。せっかく分かりやすく解説してくれているサイトがあるのだから、実際に利用する前によく読み込んだほうが良いでしょう。

無料期間について

何と言ってもAWSの利用意欲を注ぐのがこれ。他は当然初月からしっかり請求されるので、月額の計算で萎えちゃったりします。

プラン的にも有料後も無理なく使えるものが揃っているので、無料期間終了後も長く使っていくのにも適していそう。

AWSのHPに載っていた無料期間については下記(16/11/13時点)。

無料期間は1年間も続くのでこの時点で破格なのですが、それでもやはり調子に乗って使っていると、有料期間ともなると馬鹿にならない請求が毎月来ます。シミュレーションで見れば一目瞭然...

制作物(予定)

とある予約フォームを制作します。

簡単な入力、確認、完了画面とメール送信機能だけしか作りません。

実際に利用する機能

たくさんの機能が有る中で、今回実際に利用するのは下記。

AWS Lambda

今回の記事の中で非常に重要。EC2ではなくこちらを使うのには大きな理由があります。

• 金銭的にリーズナブル
• 小規模な申込みフォームを作る程度なので、データ転送やストレージに大した規模を求めない(数百万数千万単位のアクセスが来ることがわかっていればこの限りではない)
• プライベートネットワークは不要

↑とは逆にすでに大規模サイトを運用している、という場合はそもそも収入が相当あるでしょうから、まともにEC2のインスタンスを立てて24時間稼働をしても問題なく運営出来るかもしれませんし、そもそもそれだけ金が使えるならAWSでなく自前で用意したっていいですよね。筆者はそうではありませんので...

Lambdaについては

AWSでAPI Gatewayから非同期でLambdaを起動してS3にファイルアップロードしようとしたらハマった話。 from Takehiro Suemitsu

www.slideshare.net

この説明も役立ちました。今回は非同期ではないしNode.jsは使いませんけどね。

Amazon S3

要するにストレージ。料金体系は公式サイトよりも

qiita.com

を見たほうが分かりやすいです。こういう時本当にQiitaは頼りになります。

Amazon API Gateway

これとLambdaの組み合わせによってサーバレスなアプリケーション制作が可能になっちゃいます！

今回、下記で詳しく書きますがpythonを使うので

qiita.com

dev.classmethod.jp

この辺を参考にすると良いでしょう。

DynamoDB

フォームの入力データを保存するために必要。

qiita.com

ここが分かりやすかったです。

NoSQLだかなんだかにビビる必要はありません。要するにデータの保持の仕方がMySQLとかとはちょっと違うだけ。

Amazon CloudFront

所謂Amazon版CDN。とは言え今回は主に独自ドメイン+SSL設定のときにお世話になります。

Amazon SES

ここが分かりやすくまとまってました。

qiita.com

これと別でSNSを利用してもいいのですがそちらはモバイル端末へのPush通知用だということに対して作ろうとしているシステムはPCでも受け付けていること、内容的にどちらかと言うとメールに記録として残したほうが良いと思ったのでSESにしました。

言語は？

Pythonを利用します。これは言語のシェア率が低くなく、Lambdaで使える言語の中では学習する価値が一番高いと感じたので。

Pythonを使ったことがない筆者が1からやるのはちょっと骨が折れるかと思いきやそうでもありません。確かに色んなライブラリに手を出すとしたらきついのですが、今回はやりたいことが明確なので使用するライブラリも限定します。

サーバレスなのでBottleやDjangoは使わず、Lambda functionとしての部分に記述するだけです。

そして忘れずに、契約後にはこれを絶対しましょう!

qiita.com

1年間ずっと残り期間を見るわけにもいかないでしょうから、期限切れのときに気づかずに使い続けて利用費が跳ね上がるという悲劇を防ぐために重要です。

開発の流れ

ここは少し規模が肥大化しそうなので別記事としてアップします。本記事には概要だけ載せます。

前提の知識をつけたところで、やっと製作開始。前置きが非常に長くなりましたが、早速やってみましょう。

ちなみにまだ何もない真っさらな状態から始めるので、バックアップは取りません。

登録

まだAWSのアカウントがない前提ですのでアカウントを作成します。Amazonのアカウントとは別扱いです。

登録完了後はこんな感じのページが出ます。

登録が終わったばかりであればまだ請求額が$０のはず。念のため確認しましょう。

IAM Role/User, Groupの作成

qiita.com

IAMってなんのこっちゃ、という人はサーバでいつも使うユーザとかroot権限を思い浮かべれば分かりやすいです。

最初、AWSアカウントを解説したばかりで何もRole設定しないうちはroot権限と同等になっています。

16/11/16時点では日本語ではサービス→セキュリティ・アイデンティティをクリック→アカウント設定から入ってください。

グループを作成、次にユーザー作成です。

日本語では左メニュー「ユーザー」をクリック。

どういう条件か知りませんが、時々Create UserするときにThe request is invalidと出るときがありますが、その場合は何度かF5してやり直してみるとうまくいきます。

無事作成できると上記画面になります。 

パスワードの管理へは下記のように辿ります。

次はログイン。そこまで無事にできたら、ひとまずサインアウトして今度は「ルートアカウント認証情報を使用してサインイン」からデフォルトのアカウント情報でサインインし直しましょう。

adminはRoleとして強すぎるのでpythonサービス制作用に最低限のアクセス権限を持ったRoleを別途用意します。

サービスの選択

AWSのサービス群から必要な物を選びます。今選べるのはこんな感じ。

制作

CloudFrontでのSSL証明書登録、S3へのコンテンツ配備、APIの作成からメール設定などやることは盛りだくさん。ココに書ききるには狭すぎるので、別記事でアップします。

テスト

本当はここも書きたいのですがAWSでのデプロイやテストの自動化について1からやる流れについては後ほどまとめて記事を出したいと思います。

リリース

所謂デプロイ。とは言ってもS3やDynamoDBへのデータ登録やSSL設定は先にやってしまうので、API Gatewayのデプロイのことを指します。

どちらかと言うと制作に含まれてしまうので、ここで単体で書くことはありません。

(少し長めですが)総括

webサービスは便利なツールですがそもそも自分がやりたいことが明確でないのにwebサービス作ろう、とはならないはずなので、後はそんな人に必要なのは頭を使うことだけだと思います。今や様々なサービスとかツールが出回っているから、どれを使ったら自分に合うのかを設計前の段階に洗い出す。そしてそれらツールのうち料金プランとスペック的に無理のないものを選んで、必要なら乗り換えたりプランを変更したり、後から柔軟にやりくりするだけ。言ってみれば単純ですがそのためにはたくさん情報を得る必要があって1から自分だけで勉強するのは大変なので、今度はそのために情報を分かりやすくまとめてくれているQiitaやDevelopers IO、企業の開発者ブログ、はてなブログの一部の記事あたりを探っていく感じですね(ググった結果たいてい良記事はこのあたりに落ちていることが多いです)。

逆に一番ナンセンスなのは、トレンドというか新しいから大丈夫だろう使っちゃえというパターン。最新の技術だとサポートが行き届いていなかったり、ドキュメントが不十分だったりもします。そして本当にそれが自分たちに合うのか考えもせず取り入れるのは甚だ疑問です。せっかく参考書やネットで調べ放題なんだからそういった財産をフル活用して本当に役立つものを限定的に使っていく。

かつ知識がないとそもそも選定しようがないので、最新情報には触れていく。役立つなら取り入れる。この繰り返しです。筆者もそうしていくし、きっと世の中の”出来る”エンジニアと言われている人はこんなスタンスで仕事しているに違いない。限られた時間内で目的を達成するためには必然的にそうなるから。

本記事はAWS学び始めの初心者が理解したこと、実際に使ってわかったことを自分用メモ&なるべくこれから触る人向けに分かりやすくまとめたつもりですが、間違いもあるかもしれません。作っていっておかしいな？と思ったら後から随時修正を入れていきます。

【ドメイン移管】初心者向けサイト移行例

どうも。

最近、とあるサイト移行とドメイン移管についてお手伝いしたので、せっかくなので実際にやる流れについてまとめました。

より簡単に一通りを済ませるために行ったので改善点はたくさんありそうです。

※これはあくまで移行例に過ぎませんし、そこまで小難しいサイトでもありません。ものによってはこれより遥かに面倒な手順が必要だったりするかもしれません。

---

やったこと

• サイトデザイン変更(実際にはWordPressで一新までしました)
• ドメイン移管

サイトの種類

会社のHP + お問い合わせフォーム

移行前

• HPビルダー(月額千数百円)で運営
• ビルダーインストールPCでのみ作成可能

移行後

• WordPress上で運営(サーバはロリポップのものです)
• ネットが使える全てのPCで作成可能

今回のキモ

DBを使わずJSなどのロジックもろくにないので、サイト構築自体は大して難しくありませんでした。修正したとしたらデザインも見た目を大幅に変えるわけでなくビルダーでどうしても解決できない表示崩れを直したり少し見やすくする程度です。

ただしドメインを変えずにサイトの見た目と稼働サーバを変えるので、前のサービスを終了するタイミング、切り替えるタイミングを間違えると大変です。順を追って説明していくと、

1. 新契約(ここでいうロリポップ)を完了させる
2. WordPressインストール、編集
3. ムームードメイン(お名前.comでもOK)でドメイン移管(この時点ではドメインはビルダー側のサーバを向いてる)
4. ネームサーバ変更(ここからドメインはロリポップを向いてる)
5. 前の契約(ここでいうビルダー)を解約←これはもうすぐ完了

※ネームサーバが完全にロリポップに変わるまで最大1日以上かかりました。。。

上記でいう3まではビルダーで作られたサイトが表示されています。4で徐々に新サイトに切り替わっていきます。5はすべて切り替わったあとで実施しましょう。詳しいやり方はビルダーなら購入したパッケージの説明書、レンサバなら運営HPを見れば必ず書いてありますので、そこを参照すればOK。

仕組みは下記の説明でわかるはず。

itpro.nikkeibp.co.jp

webのリテラシがない人がいきなり勉強するのは酷かもしれませんので、ある程度単語くらいは理解できるようになってから実施したほうがいいかもしれません。

！！ロリポップ仕様上の注意点！！

今回一度実は大きなミスをしていて、全く同じフォルダにEC-CUBEを入れてしまったことでURLがEC-CUBEのものに上書きされてしまう事件が発生しました。

そんなときは上書きされたファイルがどれかを特定しているうちにそもそもアクセスすら出来なくなっていることに気づき、結局全全消しして同じディレクトリ構成で入れ直しました。ファイルはバックアップをとっておいたので割と早く復活出来ましたが、入れる前の説明文はちゃんと読んでおきましょう。特にディレクトリ周りはミスすると危険です。

まとめ

サーバ選定、プラットフォーム選定は大事です。今回はロリポップを選んだわけですが、正直なんでも良かったので、試しにって感じですね。クラウドってテもあったし、さくらのレンサバでも良かった。しかしいろんな要件を満たす必要があるなら、それで一番安く済むのはどれか、必要な機能を満たしてくれるものがどれかを選びます。

そして、手順は書きはしましたが、ドメインを新たに取得する場合や自前でサーバ構築する場合など場合によって手順は変わってきますので、適宜本を買うなりQiitaを見るなりして調べる方が良いと思います。

今後の予定

• ネットショップ開通
• 予約フォーム作成
• Google Analytics導入

ということで順を追ってでき次第これらも記事にしていこうと思います。これで素人がサイトづくりをする一連の流れが見えてきますね。

wordpressでそれっぽい企業用サイトを作るために

WordPressを用いて1からサイト作りをしたので、企業用HPのサイト作りをするための流れを書きます。

初期状態

WordPressをインストールしたばかりの画面はこんな感じ。

※画面の背景がちょっと変わってますが気にしないでください。

ここから余計な項目を削って必要な項目を出し、更に修正を効率的にするためのアレンジも施します。

※テーマは標準のTwenty Sixteenを用いるものとします。

見た目の修正

コメント欄を消す

WordPress - コメント欄停止・コメント削除

の通りにやれば出来ます。

サイドバーを検索欄以外全て消す

www.nxworld.net

の通りにやるか、もしくは

この画面でサイドバーにある検索以外(検索が邪魔なら検索も)をクリック→削除とします。ここで自分でサイドバーをカスタムしたいなら、テキストを入れてそこにulタグを入れて作りましょう。

タイトルを消す

プラグインで消してもいいですが、CSSで消したほうがスマートです。

.entry-header h1.entry-title {
  display: none;
}

フッターを修正する

フッター部に「Proudly powered by WordPress」と出ているのが気になると思います。当然邪魔になるので、消しましょう。

wordpress999.info

ココの通りにやれば大丈夫です。そのままCopyrightを記載しても良いでしょう。

ナビゲーションバーの配置

固定ページの一覧をナビゲーションバーとして配置します。先に固定ページを作成します。まずはデフォルトの余計なページの削除から。

ダッシュボード→固定ページ→固定ページ一覧

を開き、

ここのサンプルページを削除します。ゴミ箱へ移動でOKです。

そのうえで、必要なページを追加します。

wordpressを入れ直してバックアップから戻す場合は、wp_postsにinsertすればOKです。事前にSQLは準備しておいたほうがいいですね。

すべてのページが用意できたなら、次は外観→メニューをクリック。

このような表示になっているはずです。

設定方法は

WordPressのナビゲーションメニューを設定する方法

を参考にどうぞ。 

お問い合わせフォーム

企業ならお問い合わせフォームは必須ってことで、手っ取り早く用意したいなら。

www.adminweb.jp

親切なことにデザインはデフォルトで当たっています。個人事業主の方であれば特段フォームもメール本文も修正要らずですぐに使えるのは嬉しいところ。

逆に金融関係などセキュリティにチョ～厳しいフォームであればプラグインでなく自分でしっかり作り込んだ方がいいです。その場合はそもそもWordPressよりサイト自体を自前にしたほうが合っているんですけどね...安く作ると、どうしてもセキュリティは甘くなりがちです。

デザインの追加(style.css)

ダッシュボードから外観→テーマの編集

独自のCSSを使う場合はフォローしません。やり方はググれば見つかるはずです。

WordPressでは見て分かる通り、normalize.cssをデフォルトで適用しているようです。その他WordPressのデフォルトのデザインがいくつか当たっているので、もしセレクタ書いても効いていないのであれば、デフォルトの記述を疑ってください。

画像フォルダ整理

wp.8jimeyo.info

ここで紹介されているプラグイン「Media File Manager」を入れましょう。

ちょっとしたレスポンシブデザインに。

このままだとブラウザのサイズが変わったりスマホから見たときに画面崩れが起こってしまいます。それを対策します。

まずプラグインでAdd Code To Headを入れて有効化します。

すると

このように設定欄にAdd Code To Head項目が追加されるのでクリックして、

<meta name="viewport" content="width=1000"> ※必要ならminimum-scaleも。

と入力して(上記widthはサイトのサイズに合わせて適宜変えること)、変更を保存。

スマホからアクセスした時に崩れてなければOK。PCで見たときと同様の画面になっているはずです。

それでも崩れる場合は

webcre8.jp

の他の項目も試してみると良さそうです。

設定の修正

自動brタグ挿入禁止

webkikaku.co.jp

のやり方が良いです。ただし、これをやるとビジュアルで修正するときにも改行を入れたはずなのに改行されない問題が発生しました。普段HTMLを書かない人にはあまり向かないかもしれません。

aタグのhref属性に記載するURLを相対パス化

www.will-hp.com

のやり方が良いです。毎回絶対パス書くのは手間と見づらさの点でスマートではありません。

imgタグのsrc属性に記載するURLを相対パス化

www.warna.info

のやり方が良いです。相対パスのほうが良いのは上項目と同様。

検索対策

Just another WordPress siteを消す

作ったばかりの自分のページをググると、↑の文言が検索結果についてます。これではWordPressで作ってますよーと公言してるみたいでちょっと格好悪いですね。なので消しましょう。

crowd-logic.com

が分かりやすいです。

付録1:設定をいじりすぎてわけがわからなくなった挙句、ダッシュボードにもアクセスできなくなった時

特にWordPress アドレス (URL)をミスって変えた時によく起こります。それだけならググれば対処法は出てきますが、誤って重要なファイルを消しちゃったりいじっちゃいけないファイルをいじくり回して結局復活できなくなるときも稀にあるでしょう。

そうなったら予めバックアップをとったうえで(ここ超重要)、おとなしく今使っているwordpressのディレクトリごとrm -rfしましょう。そして再インストールし、設定はダッシュボードから同様に行ったあと、下記の一部のファイルをまるまるコピペして動作確認しましょう。

wordpressをインストールしたディレクトリ/wp-content/themes/twentysixteen/functions.php

wordpressをインストールしたディレクトリ/wp-content/themes/twentysixteen/style.css

wordpressをインストールしたディレクトリ/wp-content/themes/twentysixteen/footer.css

ただし、固定ページだけはファイルでなくwp-postsというテーブルに保存されているため、その中身が生きていれば大丈夫です。間違っても、DBの中のデータは消さないように注意すること。

付録2:JSについて

企業HPにてJSを使うことは考えづらいですが、もし使うのであれば独自のJSを用意してそれをfunction.phpを編集して読み込めるようにするか、必要なページにだけscriptタグを書いてそこにべた書きするか、によります。後者がおすすめです。

付録3:SSLについて

お問い合わせフォームにSSL導入の話ですが、

問い合わせフォームのセキュリティ対策は不要か？実はSSL対応はほとんど意味が無い件 | affiliate.ks-product

にある通り、不要だと思います。入力内容によりますが普通は氏名とアドレスと問い合わせ内容のみ。

SSLやってるところはやってるけど、だから何？って感じ。

スパムメールはSSLありのところでしか入力してなくなって、来るときは来ます。というかSSLあり/なしで明確に差が現れた、と研究結果もしくは統計が出ているから完全にSSLなしはOUTだ！と言うソースでもない限り、SSLを必須だと言うに値しないでしょう。

携帯のアドレス、番号などを知らない誰かに教えているはずもないのにどこからか漏れていてスパムメールが大量に来る経験は多くの人が経験済みです。つまり、SSL化したから安全、ではないです。それならやる意味もないでしょう。もしDBで管理するよ、という場合は話が変わって来ますが...

これがカードの契約番号とかクリティカルな情報なら暗号化した上で保存、などSSLだけでなく更に強固にするべきですね。

長くなりましたが、WordPressの本を買わずにサイト1つを作れるくらいプラグインや情報がネットには充実しているので、まずは調べて、自分で色々試しましょう！

excelは保存用ドキュメントにしないほうがいい

概要

あくまで個人的な意見ですが、Excelが使いづらいと感じることが多いので、書きます。

一言で言うとExcelは糞です。

頻繁にロックされクラッシュし、大事な中身がおじゃんになることはざら。
重いし、いちいちカネを出して買う程のものでもないと感じます。今はもっと便利なツールが有りますし。
そもそも、大半のメモはテキストレベルで十分だし、企業に提出するレベルならPDFの方が良さそう。これはこれでAdobe Acrobatが必要ですけど...
スケジュールだってAtlassianのJIRAとかConfluenceを使えばいいです。今やexcelの出番ほとんどないはず。

テストケースやマトリクス形式のデータがほしい場合なら代替ツールを。

どうしてもexcel使うなら、共通ファイルを自分のローカルに持ってきて見れば共有とかしなくても良いので、見やすいです。Excelに固執する意味が全くないと思います。

代替ツールは？

殆どはテキストエディタで十分。

テストケースや表がほしいなら、OpenOfficeがあります。個人で何かドキュメント作成するなら、ローカルのhtmlにしたっていいし、googleのスプレッドシートを使うこともOKです。もしくはAWS等を用いてプライベートネットワークを構築してそこでドキュメントを共有し合うのも良いでしょう。

優れたツールもそのうち置き換わる

確かに一昔前はまともに資料作りをするとなったらOffice製品を使おうと思いましたが今はもっと便利なツールは間違いなくあるので、そっちに乗り換えればいいです。せっかく買ったんだからなどとお馬鹿なことを言わずに、効率を上げるツールを選ぶべきだと思います。

金銭的にも、PC1台ごとに必要なツールよりもネットに繋がっていればどこからでも触れるツールのほうが今時便利で結果的に安上がりにならないでしょうか。会社の規模にもよりますが。

そして筆者が前に味わった、共有フォルダが容量MAXでアクセスできない事態とも無関係です。その代わり、サービスが落ちれば何も見れなくなるリスクは有りますが。しかしデメリット以上にメリットが馬鹿でかいです。

まとめると

Excelについて書いたのですが、別にExcelに限ったことではなくて、使いづらいツールはもちろん、より使いやすく便利なツールが出たのならとっとと乗り換えたほうが仕事の効率が良くなります。

新しければ良いとは言えませんが、既存に使いづらい不満があるのであれば、一度試しに使ってみるくらいはしても良さそう。ネットでどんな感じかは調べることが出来るので、あまり評判が良くなければ乗り換えないでもよし。検討すらしないのは勿体無いです。

はてなブログを有料にするかどうかの判断について

概要

はてなブログを始める前に有料か無料かを選ぶことですが、筆者がはてなブログPro - はてなブログに載っている情報をもとに判断する時のポイントを書いてみました。

メリット

デメリットは、毎月数百円かかることだけ。なので、簡単にメリットとなる項目を書きます。

• 独自のブログを作れる(ブログの自由度が増す)
• 余計な表示を消せる
• 容量を気にしないで作れる

大きく分けてこのあたりでしょう。

判断材料

実際には上記リンクにあるような有料会員のみの特典というのは、全てが役立つするわけでもありません。特にこれは絶対有料じゃないとできない、というものを説明します。

独自ドメイン

これはさすがに有料じゃないとだめです。どうしてもURLのドメインにhttp://blog.hatena.ne.jp/をつけたくないなら、

キーワード自動リンクオフ

これも有料じゃないと消せませんね。しかし記事の文中、そこらじゅうの文字リンクがつくわけでもありませんし、初心者向けの記事を書くときは逆に自分でリンクを貼らなくても勝手にリンクが貼られることで逆に手間が省けるという考え方もできます。ということで、これはメリットとしては小さいですね。

記事URL引き継ぎ

これは、引き継ぎ元の記事数が多いときに有効です。1, 2記事程度であれば無料で始めてから文字をコピペするとかすれば対応できます。文字の装飾は面倒ですが...

逆に、以下は大してメリットと感じない程度の項目を書きます。

複数ブログ

これはあまり要らないかなと。。そもそも3つもブログを持ったところで更新が大変過ぎます。むしろ無料の3ついっぱいまでを書こうとしましたが、どう考えても多い..今2つを運営していますが、それでも手間です。よほど書くことが多すぎてしかもジャンルがあまりに別々になりすぎるなら、必要かもしれません。あとでそうなってから有料に切り替えたっていいです。

広告非表示

広告については、ブログを一切マネタイズしないんだ！という決意のある人には必要だと思います。しかし筆者のようにアドセンスを貼る、などどこかのアフィリエイトリンクを貼る、という人の場合には結局、広告で多少汚れることにはなります。そういう人は広告を表示しないことよりも、表示の仕方(位置、大きさ)を意識するほうが良いです。そこは課題です。

ブログメンバー

ブログを複数人で共有するのなら、その記事を書きたい人にアカウントを教えてあげればいいだけです。

ヘッダとフッタを非表示

デザインCSSで

#globalheader-container, #footer {
    display: none;
}

と入力すれば消せるので不要です。

消したあとの空白が気になる場合もCSSで調整すればいいです。

写真アップロード容量追加

これは全く気になりませんでした。毎日記事を書いてそこに複数の画像をアップしていくとしても、容量overすることはまずないでしょう。よほど容量の大きい画像を大量にアップし続けることでもない限り。

そしてそんなに画像だらけにするのであれば、外部のpinterestやinstagramを利用して外部リンクをつければ済む話。そっちにも文字は書けるし。文字が多すぎるなら、載せきれない画像だけ外部へ分けて文字だけはてぶの記事とするか、もしくはそもそも記事をシリーズ化して複数回に分ければいい話です。画像が多ければ質が高い、見やすいかというとそうでもないですし。工夫次第でどうとでもなります。

アクセス解析

Google Analyticsを入れましょう:)

まとめると

ということで、一通りの有料の項目について自分なりの考えをまとめました。どうしたらいいかは人によるとはいえ、この考え方は大抵の人に当てはまると考えています。もし有料にするのであれば先にアドセンスを貼ってある程度の収入が見込めるようになってから切り替えてもOK。

今までいくつかの質の高いなと思う記事を読んできましたが、これははてなブログっぽくないか？と思ってよくよくURLのドメインを見てみると、普通に無料会員のままだったりすることもあります。無料会員だから記事の質が下がることはありません。無料会員でもCSSの心得があれば自分で外観を整えることも出来ます。

なんにせよ調べて自分の頭で考えてどうするかを決めるのが一番大事ということですね。

【Ruby】レンサバ契約中のプランのせい！？ロリポップで起きた現象

ロリポップでRuby作業していたところ、ちょっとした問題が起きました。

魅力的なgemを見つけた時、以下のコマンドを使うはずです。

gem install gem名

これが使えなかったとしたら、どう思いますか。そしてそれが解決不能だったなら...?

昨日起きた問題

sinatraを

github.com

からgit cloneして頑張ろうとしたところで、

-bash-4.1$ gem install sinatra
/usr/bin/gem:8:in `require': no such file to load -- rubygems (LoadError)
        from /usr/bin/gem:8

rubygemが使えない。

仕方がないのでrubygems自体をインストールしてみよう。しかしここで、

-bash-4.1$ ruby setup.rb
./lib/rubygems.rb:9:in `require': no such file to load -- rbconfig (LoadError)
        from ./lib/rubygems.rb:9
        from setup.rb:33:in `require'
        from setup.rb:33

rbconfigがない

stackoverflow.com

FFS!!

これも詰んだξな。せっかくsinatra習得のチャンスだと思ったのに;-(

昨日出した下記の記事

notwodaily.hatenablog.com

と合わせて、実はここでwebサービス開発が難しいのではないか、と思ってしまった次第です。もっとお高いプランなら、他のコマンドも使えるのでしょうか（そんなことは、どこにも記載ないんですけどね:-O）？

それとも、レンサバとしてはそこまでオススメでもなかったとか..?まぁ使ったことなかったから、こういうことが起きるまでは分からないんですけどね。体験レポートを書けることくらいはメリットとして挙げておきましょうｗ

というのは冗談で、wordpressやEC-CUBEを一緒に使えることは間違いなくプラスなので、その辺にメリットを感じるのであれば契約してみるのも良いと思います。

で、結局どうするのか？

こうなったら、たぶん他のフレームワークでも同様に詰んでしまうことが想像できます。だから、フレームワーク使わずに作るしかありません。普段なら絶対やらないことですけど、今回作ろうとしているフォームは幸い規模が小さいのできっとなんとかなるでしょう。

教訓

何事もそうですが事前に説明をよく見ても分からないことはあります。実際に使ってみて始めてわかる体験って、今までに知らず知らずのうちに何度もしてきた気がします。不運な事故に見舞われても立ち上がる方法を考えておくことは必要不可欠といえるでしょう。何かにチャレンジした時に不測の事態なんてのは付き物なので、そこでくじけないこと（自分にも言える）！

【PHP】【注意！企画倒れ記事です！役立ちません！】ロリポップでサイト開発する方法

ロリポップ上でサイト開発するには、そのサイトの種類にもよりますがEC-CUBEを用いる方法やWordPressを用いる方法、直接FTP経由でファイルを置く方法等あります。今回は申し込みフォーム開発ということでサーバに入って開発する方法を選択しました。

外部リンク多めですがすべてをここに書き出すと記事がとんでもない長さになるので仕方ありません(；´∀｀)

先に言っておくこと

私自身、普段はruby使いのためrails等を使いたいのですが、ロリポップではrailsは対応していませんとのこと。

lolipop.jp

ruby使いたいならこっちかな？この辺はまだ詳しくないです。。

sqale.jp

ロリポップでも頑張って自分で無理くり入れることもできそうだけど、サポート外のことで後で何か起こっても困るので今回は使わないことにします。代わりに、ロリポップではPHPが使えるので、使用経験のある言語ってことでPHPを使ってみます。

そこで、せっかくならやっぱりフレームワークに頼りたいよねってことで、今回はCakePHP。なぜか？私自身の経験のためにです。そもそも今回作るのは簡単な申し込みフォーム数ページ分なので何を使っても大した差はないのですが。

SSH設定/Teratermインストール

下記でSSH設定をしてから、

lolipop.jp

Teratermをインストールします。これはググってインストールページを見つけてください。

接続設定は

lolipop.jp

を見ればわかります。

アクセス後はこんな感じ(見られたくないサーバ名等は消しています)。

環境をチェック

無事アクセス出来たところで、自分が使っているOSを確認したところ、64bit linuxでした。

-bash-4.1$ uname -m
x86_64

他には、使える言語とバージョンの例としては

こんな感じ。

CakePHPを入れてみよう

archiveをダウンロードして解凍って書いてあるんですが、CakePHPのインストール方法にどう見てもコマンドでやれと書いてあるので、そっちに従うことにします。

CakePHP installation

ここの

Create a CakePHP Project

のコマンドまで成功したら、次。

lolipop.jp

ここの作成した『cake』フォルダにファイルをアップロードするまでが完了した状態なので、生成されたファイルの置き場所(ディレクトリ名)を確認して、気に入らなければ今のうちに変更しましょう。

※サイトに表示されるルートディレクトリは/webなのでこのディレクトリ以下に配置してください。

その後、当然ながらブラウザ上のFTPのディレクトリにもファイルが反映されます(ブラウザの表示に反映されるまで少し時間差があるみたいで、一応URLを直叩きすれば作られていることはわかります)。

そして実際にアクセスしてみましょう。

FTPの画面的にはこうなるはずです。

この状態で、サイトの初期状態にアクセスしてみましょう。

http://ロリポップで取得したドメイン/プロジェクトのディレクトリのパス/

では入れます。下記の様な表示が出れば1段階はクリアでしょう。 

ついでに、CakePHPのバージョン確認してみましょう。

cat ./vendor/cakephp/cakephp/VERSION.txt

とすると、最後の行に、私の場合は3.3.7と出ました。

3系統確定。

CakePHPのDB接続設定をしよう！

次は、データベース接続の設定をするから先に進みます。

まだデータベース接続設定をしていないため、上記画像で

Database

の欄がCakePHP is NOT able to connect to the databaseと表示されていることでしょう。これを修正します。

上記の方法でインストールした人は、ファイル名の違いに注意してください。

app/config/database.php.default

ではなく

config/app.default.php

です。ファイル名変更は、指示通りdatabase.phpにすれば良いでしょう。

次は『core.php』の設定値を変更するですが、

app/config/core.php

ではなく

config/app.php

です。

内部の設定はsaltよりも下記をいじりましょう。

    /**
     * Connection information used by the ORM to connect
     * to your application's datastores.
     * Do not use periods in database name - it may lead to error.
     * See https://github.com/cakephp/cakephp/issues/6471 for details.
     * Drivers include Mysql Postgres Sqlite Sqlserver
     * See vendor\cakephp\cakephp\src\Database\Driver for complete list
     */
    'Datasources' => [
        'default' => [
            'className' => 'Cake\Database\Connection',
            'driver' => 'Cake\Database\Driver\Mysql',
            'persistent' => false,
            'host' => 'localhost',
            /**
             * CakePHP will use the default DB port based on the driver selected             * MySQL on MAMP uses port 8889, MAMP users will want to uncomment
             * the following line and set the port accordingly
             */
            //'port' => 'non_standard_port_number',
            'username' => 'my_app',
            'password' => 'secret',
            'database' => 'my_app',
            ...

この設定も、app/config/core.php同様にdatabase設定を合わせます。

更にエラー内容でfind grepした結果、対象箇所は

-bash-4.1$ ls -l ./vendor/robmorgan/phinx/docs/configuration.rst
-rw-r--r-- 1 XXXXXX(伏せたつもり) LolipopUser 8546 Mar  7  2016 ./vendor/robmorgan/phinx/docs/configuration.rst

の194行目付近(私の場合)にある、下記の設定が問題だったことが発覚。 

    environments:
        default_migration_table: phinxlog
        default_database: development
        production:
            adapter: mysql
            name: production_db
            user: root
            pass: ''
            unix_socket: /var/run/mysql/mysql.sock   ←ココ！！！
            charset: utf8

このうちunix_socketのパスの通りに、mysql.sockを配置すれば設定は完了となります。

ところが散々findしてみた結果、mysql.sock的なファイルがサーバ上のどこにもないことがわかりました。そのせいか、手元でmysqlコマンドを打っても

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

などと出る始末。これは参りました。

最悪手元のは動かなくてもMySQLAdminで動くからまあいいやということで、該当するディレクトリをひとまず準備して、そこにmysqlを置いてみましょう。

-bash-4.1$ ls -l /var/
total 8
drwx--x--x 3 XXXXXXX(伏せたつもり) LolipopUser 4096 Nov  5 08:37 run
drwx--x--x 3 XXXXXXX(伏せたつもり) LolipopUser 4096 Nov  5 08:37 spool

見て分かる通り、/var/libからありません。しかも、./var/以下には、権限の問題で自分のユーザでは書き込みが出来ません。これを手詰まりと言います。

今までの苦労はなんだったのでしょうか？

というわけで、やるだけやった結果何も出来ませんでしたという落ちでした。

誤解のないように言っておくと、自分でサーバを設置したりWindows上で開発する場合はmysql.sockを用意すれば普通にこの続きをやってうまくいきます。参考になれば幸いです。

一方私は手元に何も残りませんが、しかし何も作れない、というのは流石に許されないため、次は別のフレームワークで試してみます。