wordpressのサイトをhttpからhttpsへとSSL化する手順（保存版）
こんにちは、筋肉めがねです。
先日、クラシックのハウスコンサートにおいて、譜めくり、というものを体験させて頂きました。この経験により、クラシック音楽というものがグッと身近になったので、その過程をシェアさせて頂きます。
友人、家族にクラシック音楽に精通している人がいる、という環境ではないところで育った僕にとって、クラシック音楽、というのは、例えば茶道のような、何となく奥深いものではあるんだけれども楽しみ方が分からない。そういう対象でした。
そんな中、とある御方のご好意で、幾度かクラシック音楽のコンサートに行く機会に恵まれ、オーケストラの迫力、指揮者の熱意など、少しづつではあるけれどもクラシック音楽を楽しめるようになってきている。最近はそういう状況でございました。
そして譜めくりでございます。
譜めくりをさせて頂ける、というお話をいただいてネットで情報を集めました。譜めくりスト、と呼ばれる方達がいる、と。そして譜めくりはとても責任重大な仕事である、と。
いつかこちらの映画も鑑賞したいですね。
![譜めくりの女 デラックス版 [DVD]](https://images-fe.ssl-images-amazon.com/images/I/41NlmL9MMeL._SL160_.jpg "譜めくりの女 デラックス版 [DVD]")
本番で失敗しないために、事前に曲を聴きながら譜面を追っていくんですよね。何度も何度も聞くんです。そうすると、不思議なことに、次第にその曲に対して愛着が湧いてくるんです。高校時代に何度も聞いた平井堅の「楽園」のように。
この曲に対して愛着が湧いてくる、という感覚を覚える事が、クラシックを知らない人間がクラシックに興味を持ち始める上でとても大事なんでしょうね。そんな事を感じた体験でございました。
そして、先日、とあるコンサートを客として鑑賞したのですが、本物の譜めくりストは別格でございました。譜めくり、という技術が素晴らしいだけではないのです。演奏が終わり、奏者が立ち上がり、お客様に礼をする。その時、譜めくりストは、ただ動かずに椅子に座っているのでしょうか。違います。奏者と共にサッと立ち上がり、お客様からは全く気づかれないような気配で持ってピアノの後ろへ移動するのです。
譜めくりは奥が深い。
何はともあれ、こんなに貴重な機会を与えてくださった方々には感謝でございます。
さて、冒頭で譜めくりについて書きましたが、本日は、これ以降、ワードプレスのSSL化手順について書いていきましょう。
- AWS EC2, php, MySQL, apache2
- FileZilla, Sequel Pro
- wordpress
- Route 53
- Elastic Load Balancer
- Certificate Manager
先ずは、AWSでEC2をセットアップし、そこにphp, MySQL, apache2を導入しますが、これらの手順、そしてFileZilla、Sequel Proのセットアップ方法、およびwordpressのイントール方法は以下の記事に書いております。
それでは、wordpressをインストールした、という前提で、これ以降の手順を書いていきます。
- .htaccessファイルの有効化
- .htaccessファイルの作成
- Route53でDNS設定
- Certificate ManagerでSSLを取得
- Load Balancerの設定
- CSSの問題、リダイレクトの問題を解消する
- Mixed contentのbug fixを行う
.htaccessファイルの有効化
.htaccessファイルとは、ざっくり言うと、WEBサーバーをコントロールするための設定ファイルです。例えば、サイト内の、あるURLにユーザーがアクセスしてきたときに、別の特定のURLにリダイレクトさせるために.htaccess内にリダイレクト処理を記述させる事ができます。
そこで先ずは、.htaccessファイルを有効化させる必要があります。
.htaccessファイルを有効化するには、apache2.confファイルを編集する必要があります。
/etc/apache2/フォルダ下にapache2.confファイルが格納されております。そのファイルを開けて、<Directory /var/www/>の箇所を見つけ、その中のAllowOverride NoneをAllowOverride Allに変更します。
それでは、.htaccessファイル自体はどこにあるかというと、僕の場合は、デフォルトでは作られていませんでした。ですので、新たに作る必要があるんですね。
もう一つ、.htaccessファイルを有効化するための手順として、mod_rewriteをインストールしておく必要があります。
terminalから、ec2へsshでアクセスし、root直下で以下を叩きます。
インストールが完了したら、apacheサーバーを以下でrestartしましょう。
これで、.htaccessの機能を有効にする事ができます。
.htaccessファイルの作成
textエディターファイルで、新しくファイルを作り、中身に以下を記述します。そして、ファイル名を.htaccessとすれば出来上がりですね。
そして、.htaccessを/var/www/html/直下へ格納します。
これで、.htaccessの設定は完了です。
Route53でDNS設定
AWSのRoute53で新しいHosted Zoneを作成します。
Domain nameには、 既に他のDNSサービス（GoDaddyなど）で取得したdomain nameを記入し、Typeはそのままで、"Create"ボタンを押します。
Hosted zoneを作成すると、デフォルトで、type NSとtype SOAのレコードが設定されています。ここで表示されているNS (Name Server)のvalueを、ドメインを取得したDNSサービス側で登録してあげる事でドメインとroute53を紐づける事ができます。
例えば、GoDaddyを使用している場合、取得したドメインの"DNS Management"のページを見てみると、デフォルトでいろんなレコードが設定されております。
ページを下の方にスクロールしていくと、Nameserversの設定のところで"Change"ボタンがあるので、それを押し、先ほどRoute 53のHosted Zoneで表示されたName serverを一つ一つ設定してあげるんですね。
これで、Route 53のhosted zoneと自分で取得したドメインを紐づける事ができます。
Certificate ManagerでSSLを取得
SSLとはSecure Socket Layerの略で、ざっくり言うと通信を暗号化するために使用されている技術です。
このSSLのcertificateについては、各DNSサービスで有料で取得する事はできますが、AWSでは無料で取得できるんですね。
AWSのCertificate Managerで"Request a certificate"ボタンを押し、ガイダンス通りに必要事項を記入していきます。
進めていくと、validationの方法をDNSにするか、emailにするか、という質問があるので、そこはDNSにしましょう。
Certifacateを作り終わると、Validation statusのところに、"Pending validation"という文字が表示されます。
ここで、もう一度Route53に戻り、先ほど作成したHosted zoneの中で、上で表示されているCNAMEというレコードを設定してあげる必要があります。
NameとValueについて、Certificate Managerの画面で表示されているところからコピペで、そして、タイプはCNAMEを選びます。
TTLというのは、保存後にどれぐらいの時間で設定が反映されるかを決めるものです。60秒にしても良いですね。
Route 53でCNAMEを設定後、60秒程度経ったのちに、先ほどのCertificate Managerに戻り、先ほど設定したドメインのstatusを見ると"Issued"と表示されています。
これで、Certificate Manager上での設定は完了です。
Load Balancerの設定
続いて、Load Balancerの設定です。Load Balancerとはざっくり言うとサーバーにかかる負荷を軽減してくれるものです。
AWSのEC2のページで、Load Balancerを選択します。
そして、Application Load Balnacerを作成します。
先ずは、Load Balancerの名前を決めます。
そして、Listenersについて、デフォルトではHTTPのみ作成されておりますが、SSLを導入するためにはHTTPSを追加する事が不可欠でございます。HTTPSを追加し、Portはデフォルトの443を使用します。
Availability zonesは選択可能なものを全て選択しましょう。
Tagsは未設定で問題ありません。
ACMですが、ここで先ほど作成したCertificateを選択します。
Security policyはデフォルトの設定でOKです。
Security groupの設定は、今回使用しているEC2に紐づいているSecurity groupと同じものを選択します。
RoutingのConfigurationについては、target groupのNameを設定してあげて、残りはデフォルトの設定で結構でございます。
ここで、SSLの設定をする、つまりHTTPSの設定をするんだ、というにも関わらず、HTTPをprotocolとして使用していることに、違和感を感じる方もいらっしゃると思います。
その理由について、以下のブログから該当箇所を抜粋しましょう。
A little more explanation: by default Apache is installed to use HTTP (port 80), therefore all configuration for this protocol was taken care of for you when your originally setup your server. Importantly, inbound traffic originating from the ELB also is traveling over HTTP as per the diagram above and thus we a) should continue to listen on port 80, and b) we should continue to use HTTP all the way to our WordPress server. Now then, to provide an end-to-end HTTPS connection for our users we’ll need our WordPress server to return all web pages over HTTPS rather than over HTTP.
要は、ユーザーがhttpsとURLを指定してサイトを見にいくときに、ELB (Elastic Load Balancer)がその処理をHTTPに変換してEC2 instanceへ信号を送る、という事なんですよね。
もしも、Load Balancerを使用してのSSLの設定がどうしても上手くいかない、という人がいらっしゃったら、この部分をきちんと理解する事に時間を使うと、だいぶスムーズに問題を解決できる事と思います。僕自身Load Balancerを使ってのSSLの設定が1週間弱できず、どうしようか途方にくれておりましが、順を追ってLoad Balancerの役割、信号の流れを理解する事で、その後1日でSSLの設定ができた、という経緯がございます。
そして、紐づけるEC2 instanceを選択し、Load Balancerの設定は完了です。
続いて設定したLoad BalancerをRoute53のHosted zoneと紐づける必要があります。
先ほど、設定したRoute53内のHosted zoneを選択し、新しくレコードセットを設定します。A typeを選択後、AliasをYesとすると、先ほど作成したELB (Elastic Load Balancer)を選択する事ができるので、それを選択し、Createボタンを押します。
これで、Load Balancerをドメインに紐づける事ができました。
この時点で、
http://xxxxxx.comにアクセスすると問題なく動作しており、
http://xxxxxx.com/wp-adminにアクセスすると、それも問題なく動作しています。
しかし、
https://xxxxxx.comにアクセスすると、cssがきちんと動作していない状態で表示されており、また、
https://xxxxxx.com/wp-adminにアクセスすると、http://xxxxxx.com/wp-adminにリダイレクトされる、という問題があります。
ちなみに、SSLの設定において、httpsにアクセスしているにも関わらずhttpへリダイレクトされる、もしくはその逆にリダイレクトされる、という問題が発生する事があると思いますが、その時に、どういうフローでリダイレクトされているのかトラッキングできるサイトがあるので、参考に以下に載せておきます。
それでは、cssの問題、リダイレクトの問題を解決していきましょう。
CSSの問題、リダイレクトの問題を解消する
先ずは、httpsで、wordpressの管理画面にログインできるように設定をします。
wordpressのルート直下（/var/www/html/）にwp-config.phpファイルがあります。そのファイルに以下を記述します。記述する場所は、define( 'DB_NAME', 'xxxx' );の上としましょう。
続いて、.htaccessファイルの一番上に以下を追記します。
そして、最後にwordpressで設定されているsiteurl, homeのURLを変更します。
この時点では、ブラウザから管理画面には入れないと思いますので、Sequel Proからwordpressのdatabaseへアクセスします。
すると、database内のwp_optionsというテーブルの中に、以下2つのoption_nameがあるため、それぞれの値をhttp://xxxxxx.comからhttps://xxxxxx.comに変更します。
siteurl
home
ここまで終えて、サイトにアクセスしてみると、幾つかのページでサイトがSSL化されていない事があります。これは、サイト内で使用されているjavascriptファイル、およびimageファイルの中に、httpsではなく、httpで読み込まれているファイルがある、という事が原因ですね。
そこで、最後のbug fixを行います。
Mixed contentのbug fixを行う
サイト内の問題のページに移動して、google chromeのdeveloper toolsを開くと、mixed contentというエラーを表示しており、そしてエラーの原因である問題のファイルを表示してくれます。
僕の場合は、webの、とあるページに使用している画像がhttpで読み込まれている事が問題でした。そこで、wordpressの管理画面から、一旦、問題の画像を削除し、そして改めて同じ画像をアップ、先ほどのページに貼り付ける、という処理を行う事で、画像がhttpsとして読み込まれました。これで、webの全ページがhttpsで表示されました。
以上で、wordpressのSSL化が完了しました。お疲れ様でございました。特段webのセキュリティを気にかけたり、SSLという技術を気にしなければ、web pageがhttpであってもhttpsであっても気づくところではないかもしれません。それでも、googleが正式に、"httpよりもhttpsを優先して上位に表示する。"と名言している以上、可能な限りSSL化しておきたいところですね。
それでは、本日は以上でございます。
Python, Flaskを使ってweb appを作るプロセス
こんにちは、筋肉めがねです。
ドイツ銀行が大量のリストラを発表しましたね。2022年までに、フルタイム従業員の約2割に相当する約18,000人のリストラを実施するという事です。幾つかの記事を読んだところ、今回のリストラの引き金となった事が大きく二つあるようですね。一つはコメルツ銀行との経営統合が破断になった事。合併すると約30,000人の雇用削減を行う可能性がある、という事から、労働組合からの大きな反発があったようです。結局、破断となったため、自社で経営を再建する道を選ぶしかなかった、という事ですね。ドイツ銀行のPLには、2018年のcost/income ratioは92.7%とあります。少し古い資料ですが、S&Pが2016年にまとめたレポートに掲載されている数値と比較するとだいぶ高い事がわかりますね。ドイツ銀行は、収益に対するコストが高い、という体質を抜本的に見直し、2022年までには同指標を70%まで落とす、という見通しです。
もう一つは、 低金利の長期化が理由、という事です。銀行からお金を借りたい事業主や、お金を借りたい一般消費者からすると、銀行の金利が低いことは嬉しいですし、消費を促し経済を循環させますね。一方で銀行側からすると、金利が低いと、その分借主から入ってくる利息が小さくなり財政が悪化するんですね。
それでは、本日はPython, Flaskを使ってweb appを作るプロセスについて書いていきましょう。
以前、Kaggleの物件分析competitionから派生してドイツの物件情報を分析しました。この時はじめてスクレイピングという技術を学び、10,000件を超える物件情報を取得しました。この技術を使用して、ひとつwebを作っていきたいと考えています。
まずは、どういう技術を使うか、というところですが、スクレイピングにはpythonを使用し、webフレームワークとしてflaskを使用します。サーバーはherokuを使用します。それらを使ってドイツの物件情報をユーザーに届けるwebを作りたいのですが、いかんせんどうアプローチして良いのか、知見がありません。という事で、素晴らしいチュートリアルがあるので、そちらを使用してwebアプリを一つ作って見て、知見を得ましょう。
基本的にはチュートリアル通りに進めていけば問題はありませんが、僕の場合は、幾つかスムーズに進める事ができなかった箇所があるので、その時の解決策を主に書いていきましょう。
はじめに、成果物はこちらでございます。
top-tweets-kinnikumegane.herokuapp.com
Pythonの開発環境をMac terminalで構築する
アプリを作り、deployした際に、一発で思惑通りにアプリが表示されないという事がありますよね。それはいろんなチュートリアル、ブログを参考にして開発環境を作ろうとして、最終的に必要のないものがインストールされたり、pythonのバージョンが複数存在するようになる事が原因となっている事があります。
今回も、アプリをdeploy後、そういう状況になり、数週間なかなか前に進めなかったので、はじめにどのように環境を構築しておくべきか書いておきます。
環境はmacOS Sierra Version 10.12.6です。
まず、terminal上で以下の2つのコマンドでpyenv-virtualenvとpyenvをアンインストールします。
つづいてbrewおよびbrewでインストールされた全てのパッケージをアンインストール。
一旦、環境のクリーンアップを終了、ここから構築します。
homebrewのインストール。
pyenvのインストール。
環境変数の設定など。
そして、python 3.6.3をインストール。そして、python 3.6.3をglobal（システム上のデフォルトのpython）へと変更します。
この時点で、pyenv versionsと打つと、
なるほど、環境構築に複数のブログ、チュートルアルを参考にしてきた弊害が出てきましたね。一旦、python3.5.1とpython3.7.3を削除します。
もう一度、pyenv versionsで確認すると、
不要なpythonが削除されましたね。
ここで、python --versionと打つと、python 3.6.3と表示される事を確認しました。
大事なことは、pyenv versionsでglobal設定されているpythonのバージョンと、python --versionで表示されるpythonのバージョンが同じである事ですね。
これで環境構築は終了でございます。
ローカル環境でweb作成
ここから、一気にDaiさんのチュートルアルに沿ってwebアプリを作っていったわけですが、終盤まで頭を悩ませた事は仮想環境の構築でした。結局、仮想環境を作らなくともアプリを実現できるわけで、仮想環境は結局使わなくても良い、という事ですね。pythonの、あるバージョン限定でしか機能しないライブラリを使用する場合など、用途が複数ある場合には仮想環境を使う事が有効ですが、今回のように一つのアプリのみを作成する場合、rootで実施しても問題ありません。もちろん、実用的ではありませんが、今回はroot下で進めていきましょう。
さて、top tweeetsのアプリを作る上で、幾つかつまづいた点があったため、補足事項を書いていきます。
terminal上でpython3 app.pyと記述し、runするわけですが、その際幾つかエラーがでてきました。例えばpandasがインストールされていないとか。その場合、top-tweetsのフォルダ下で、pandasをインストールしましょう。
また、flaskがインストールされていない、tweepyがインストールされていないとエラーがでる事がありますので、それぞれインストールしましょう。そしてpipのバージョンをアップグレードする事も大事なようです。pip install --upgrade pipでバージョンを19にアップグレードしておきました。
この時点で、terminal上でrun（python3 app.py）するとようやくアプリが表示されました。ちなみにまだローカル環境上ですね。ここまで2週間ぐらいあーだこーだトライしてもエラーがばかり出ていたので、アプリが表示された時は感慨深いものがありました。
そして、テキストボックスにidを入れてボタンを押すと、、、、またしてもエラーでございます。
コーディングする上でついてまわるのはbug fixですよね。
以下のコードをapp.pyに埋め込む事で、エラーが起きた後にterminal上でerror logを表示させる事ができます。
エラーの原因はどうやらhtmlにあったようです。
チュートリアル通りに進めると、twitterへ連携するcreated_atという項目とtweepyで使用するcreated_atという項目が同じ名前であるため、システムが混乱している、というエラーがでます。
よって、以下のように変更を加えました。
以下は変更。
こちらは変更なし。
created_at_in_columnsへ変更するのは、app.py内に幾つかありますし、そして、index.html内にも幾つかあるので、必要な箇所は全て変更する必要がありますね。
ここで、改めてローカル環境上でrunし、idを入れてボタンを押すとようやく動きました。
Herokuへdeploy
最後にherokuへのdeployでございます。
deployする前に3つのファイルを準備しますが、その前にgunicornをインストールしておきます。
そして、以下3つのファイルを作成し、herokuをインストール、そしてherokuへログインします。
requirements.txt
runtime.txt
Procfile
terminal上でログインしたいので、--interactiveとしましょう。
もちろん、heroku上でアカウントを作成することは事前に実施しておく必要がありますね。
そして以下の5つのコマンドをrunすると、
できました！
世界のKeisuke Hondaのツイッター情報が綺麗に表示されましたね！
それでは、本日は以上でございます。
はじめてのバレエを鑑賞して
こんにちは、筋肉めがねです。
メイ首相が辞任しましたね。元々3月29日に予定されていたBrexitが、10月末に一旦延期する事となった状況で、離脱協議案を野党と合意するための舵取りを行なっていた方の辞任であり、状況は混沌としてきているようですね。メイ首相は、2016年7月にキャメロン首相から首相の座を継いだ当初、離脱反対派ではございましたが、国民の意思を形にすべく、円滑な離脱へ向けて仕事を進めていたのですね。
先日のブログでも触れましたが、もしも「合意なき離脱」となった場合、UKのお客様相手に商品を販売している企業は大きな打撃を受けます。例えばEURを財務会計上の主要通過としている製造業においては、UK相手のお客様に対してはほぼほぼGBP建てで契約を結んでいる事と思います。その場合、GBPの対EURの価値が下がった暁には、全く対策をしていなければ、損益計算書上の販売額が大幅に痛みますね。そういうリスクを鑑みて企業は四半期に一度ぐらいの割合で外貨を購入しています。リスクを適正に見積もって、次回の購入額を決めないといけないでしょうね。
さて、本日はKaggleでも筋トレの話でもなく、生まれて初めてバレエを鑑賞してきたので、しかも、ある御方に全体の通し稽古を見学させていただく機会をいただきましたので、その感想を書いていきます。
今回見学させて頂いたのはAnna Karerinaというトルストイの書いた小説を題材にしたバレエでございました。トルストイと言えば、オードリーヘップバーン主演で映画化された「戦争と平和」を書いた方ですね。
これまでバレエというものに全く触れる機会がなかったので、バレエを鑑賞する、という事になり、どういう気持ちで臨んで良いのか全く分かりませんでしたが、通し稽古という事で、良い意味でリラックスできた状況でございました。
前日の夜にAnna Karerinaの話をざっくりと予習していた事がとても役に立ち、どの役者が誰役なのか、という事がほぼほぼ理解できた事も、今回楽しめた要因の一つでございました。
音楽、舞台照明、セットなど楽しめる要素が幾つもありますが、はじめて鑑賞するバレエでしたので、全ての事を冷静に享受するには気持ちに余裕がございません。
そんな中、特に今回感動したのはバレエダンサー達の洗練された体、そして動きでございました。背中がぱっかりと開いている衣装を着ているダンサーの背中を見ていると、とても細かい筋肉がびっしりとついているんですよね。ジムで筋トレをしてつける筋肉と比較をすると、バレエでつける筋肉はとても柔らかそうなんです。筋肉をつける事を意識してつけた筋肉ではなく、バレエを通して自然とついた筋肉なんですよね。そんなダンサー達の動きといったら、つま先から指先まで「すっ」としていますよね。
無駄がない。
例えば空手で「形」というものがあります。この「形」をする時には、初動に力を入れて、そして、突きなり蹴りなりを止める時にも力を入れます。そうする事で、機微のある動きを表現するのですが、バレエの動きは空手の「形」とは違った力の入れ方をするのでしょうね。
ダンサー達の洗練された体をみるにつけ、自分の食生活、私生活を今一度見直す必要がある、そんな事も考えさせられた時間でございました。夜ご飯の炭水化物を少しづつ減らしていこうと。
それでは、本日は以上でございます。
「会計の世界史」を読んで
こんにちは、筋肉めがねです。
3月29日に予定されていたBrexitは、イギリス議会が離脱協定案を3度にわたり否決した結果、EUがBrexitの期限を10月31日まで延期しましたね。先日UKに出張に行き、現地の方とお話する機会があったのですが、現地の方達は、期限を延期したところで、ま与与野党が揉め「合意なき離脱」となるのではないか、と懸念しておりました。
一方で、企業においては、Brexit特需という言葉もあるようで、3月末に「合意なき離脱」が起きると想定していた企業は、その時期に混乱したであろう物流網がもたらす悪影響を減らすべく、先にUKへ仕入れる在庫を増やしておく、という措置を取ったとの事です。例えばUKにおける飲料販売会社が、海外の飲料メーカーへの注文を少し前の時期に増やしたようですね。飲料メーカーはBrexit特需の恩恵を受けたようです。
10月31日に果たしてBrexitが起きるのか、目が離せません。
さて、積読していた「会計の世界史」をようやく読みきりましたので、久しぶりに読書感想文を書いていきます。
会計の世界史 イタリア、イギリス、アメリカ――500年の物語
- 作者: 田中靖浩
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2018/09/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
10数年前の春、無事に就職活動を終えた時期に、周囲の方から勧められて簿記を勉強していた事がありました。簿記を勉強しておくと会社に入ったら役に立つぞ、と。そんな簿記でございますが、一体全体どういう背景でこの世に出てきたのか、そんな疑問を解決してくれる良書が「会計の世界史」でございます。簿記が世に出てきた背景だけではなく、財務会計が発展してきた経緯、管理会計が必要となってきた時代の流れ、そしてコーポレートファイナンスが台頭してきた近代に至るまで、その時々の世の中の状況を分かりやすく説明しており、とても面白い読み物でございました。
中でも幾つかのポイントをピックアップして、以下書いていきます。
今から約500年前、経済の中心はイタリアであったそうです。当時、東方のインドや中国からの品々がイタリアへ運ばれ、そこからヨーロッパ各地へと運ばれた、という事です。イタリアは絶好の立地にあったわけですね。そんなイタリアのヴェネツィアではガレー船を使った商売が発展していました。
ガレー船という大きな資産を手に入れるためには、銀行から借入しないといけません。それで、当時銀行の先がげであった、バンコと呼ばれた金貸業がイタリアで生まれました。船を使った商売では、同業である他の商人たちと一緒に商売をすることもあったそうです。ですので、「儲けの分配」を明確にする必要があったんですね。
また、各地にネットワークを広げたバンコもまた、融資や回収、為替手形の発行や決済といった取引記録をつける必要に迫られた、ということです。
これら二つを満たすために簿記は生まれた、とのことです。つまり、簿記をつけるメリットは儲けの分配をできる事と対外的な証拠の役目を果たす事（つまり対外的なトラブルを減らす事）にある、ということです。
時代は1800年代中盤、イギリスへと移ります。当時、鉄道建設ラッシュが起こっていたイギリスですが、当の鉄道会社には大きな問題がありました。それは事業を始めるための初期投資が大きすぎることです。列車、線路はとてつもなく大きい固定資産です。それら手に入れるのも容易ではありません。大きな資金を手に入れる、という問題がたちはだかりました。イタリアでガレー船による商業が栄えていた頃、株主といえば、家族・親族でした。それを、イギリスの鉄道会社は、株主の枠を一般の株主へと大きくひろげ、 桁違いの資金を得る事に成功した、とのことです。しかし一つ問題がでてきました。例えば、初期投資を行った年に株主であった場合、初期投資による大幅な支出により配当がもらえる事は皆無でしょう。そして、二年目、三年目に株主となった場合、明らかに一年目に株主であった場合よりも、配当は多くもらえます。つまり、株主であった時期の違いにより「儲けの配分」に大きな差がでてくるのです。
これは困ったぞ、と。
そこで考案されたのが「減価償却」という概念、という事です。なるほどですね。
「減価償却」がすでに行われた支出を後から計上する方法であれば、その逆もあるんですね。「引当」です。将来発生する事が確実である支出を前もって費用計上しておく事ですね。
これらの考え方が発展してきた背景は鉄道会社の勃興という事です。
舞台はアメリカに移ります。アメリカで鉄道建設ラッシュが起きていた頃、移民とともに、投資マネーもイギリスからアメリカへと流れてきます。そうすると投資家は、投資する対象の経営状況を分析する必要が出てきます。この当時、19世紀後半には「経営分析」ブームが起きているようです。流動比率の分析などですね。それらの分析を行うには、決算書が必要となってきます。こうした背景があり、財務会計が発展してきた、という事です。投資家に対する財務状況の開示ですね。
事業の規模が拡大してくると大量生産をする必要がでてきます。アメリカの鉄鋼業では大規模生産のできる工場がでてきました。複数の部品を複雑な工程を通して作る大型の工場の場合、さまざまなコストをどうやって製品原価まで落とし込むかの手順を考えなければなりません。このための仕組みが「原価計算」なんですね。原価を計算しない事には売価を決定できませんよね。この「原価計算」が管理会計の始まりだそうです。財務会計が外部に対する情報の開示に必要な仕組みだとしたら、管理会計は会社内で利用するための仕組みですね。例えば限界利益や損益分岐点は管理会計の代表的な指標です。
そして、さらに舞台は現代へと移ります。
20世紀後半、産業は工業から情報へと次第に移ってきていました。同じような時期に、それまでには考えられなかったモノが、次第に資産としてみなされるようになります。例えば、「独自のノウハウ」やら「ネットワークの強み」やら。アメリカでは、それら「隠れ資産」を狙って買収してくる輩が現れてきたわけです。では、どうやって「隠れ資産」を持つ企業の価値を算定するのか。そこで登場してきたのがコーポレートファイナンスです。将来のキャッシュフローを元に、現在価値に割り戻すんですね。ここで生まれた「企業価値」という概念がファンドやM&Aを後押ししていくんですね。
イタリアでは、簿記を理解して帳簿をつける事が、数字の力でした。そして、産業革命が起きたイギリスでは会計の大事なポイントである「減価償却」「引当」という概念が生まれ、アメリカでは投資マネーの流入から財務会計が確立され、大量生産が台頭してきた事により管理会計が作られ、投資マネーの拡大によりコーポレートファイナンスが発展してきたんですね。
とても面白い読み物でございました。
それでは、本日は以上でございます。
Kaggle 銅メダルへの道（9日目）
こんにちは、筋肉めがねです。
定期的にジムに行っているのですが、最近まつぼっくりちゃんが一緒にジムに行ってくれる、という事を言っております。とても嬉しいですね。筋トレをする目的は人それぞれではございますが、先ずは怪我をしない事、そして筋トレというものを楽しんでくれたら、それが一番でございますね。
それでは、久しぶりにKaggleを進めていきます。
本日は、以下のCompetitionです。
Competitionの内容は、映画に関するものです。映画館で上映されている各々の映画が、世界中の映画館で累計どれだけの売りをあげたのか、トータルの販売額を推定する、というものです。
それでは、Kernelを参考にしながら早速進めていきましょう。
参考にしたKernelは以下でございます。
House Price competitionの時と同様に、Google Colaboratory上のGPUを使用します。
先ずはデータの数を見てみましょう。
前処理
続いて、前処理です。
以下、8つのカラムについては、複数のデータがリストとしてカラムに格納されています。それらのリストから必要な情報のみを抽出して、新たなカラムとしてテーブルに追加します。オリジナルのリストが格納されていたカラムは削除します。
# from this kernel: https://www.kaggle.com/gravix/gradient-in-a-box dict_columns = ['belongs_to_collection', 'genres', 'production_companies', 'production_countries', 'spoken_languages', 'Keywords', 'cast', 'crew']
例えば、genresというカラムを見てみると、複数のgenresが一つの映画に紐づいている事が分かりますね。
ちなみに、どういうgenresが良く使用されているか、というのを可視化してみましょう。
Drama, Comedy, Thrillerが多いようですね。
これらのgenresのうち、top15のgenresについては、それぞれのgenreの名前を冠した新たなカラムを作り、各映画に対して、そのカラムにフラグを立てていきましょう。
他にもKeywordsというカラムがありますが、そこにもリストが格納されております。ちなみに、その中のキーワードにどういったものがあるのか、可視化してみましょう。
データの確認
続いて、扱うデータ群の確認をします。
Competitionで扱うターゲットは販売ですね。
例えば、ホームページが準備されている映画とそうでない映画の売り上げを比較して見ますと、ホームページがある映画の方が断然売り上げが高い事が分かります。映画を見る方はホームページを確認すると、映画館へ行きやすくなる、という事ですね。
他にも映画で使われている主要な言語と売り上げの相関を見てみますと、言語の違いによって売り上げが変わる事はなさそうです。
どんな単語が頻繁にタイトルに入っているのか、見てみましょう。
データの確認はここまです。
次回の記事では、 モデリングを進めていきます。
それでは、本日は以上でございます。
AWS EC2、php、mysql, wordpressを使ってブログの環境を作る手順
こんにちは、筋肉めがねです。
長い長い冬も終わり、ドイツはようやく暖かくなってきました。4月から5月にかけてのこの時期が、一年を通して一番過ごしやすい季節のような気がします。
ここ数週間、とある事がきっかけである御方のブログを作るというお手伝いをしておりました。数年ぶりにwordpressに触れ、とても懐かしくそして楽しい時間を過ごせております。
先日、ようやくキリの良いところまでブログ作成が進んだので、このタイミングでブログ作成に必要な環境設定の手順を備忘録として書いていきます。
それではスタートでございます。
AWS EC2 instanceの設定
先ずは、AWS上でEC2 instance serverの設定をします。以前、以下の記事でEC2 instanceをターミナル上から作成する方法を書きましたね。
今回は、AWSのwebから作ってみました。AWSのpageから「Launch Instance」を選び、手順通りに進めていきます。
Serverはubuntuを使用しましょう。デフォルトで選択されているオプションで全く問題ないので、基本的には、ガイダンス通りに進めていけば特に大きな問題はありません。デフォルトではt2 micro instanceが選択されているので、これを使ってサーバーを立ち上げます。
WordpressはMySQLを使用しているので、Security groupの設定において、inboundの項目の一つにmysqlを設定してあげる事は一つポイントですね。また、後にwebの信頼性を高めるために、SLL certificateを取得する予定のある場合は、inboundの項目の一つにhttpsを設定してあげる事も大事ですね。
そして、Key pairを新しく作りますが、これは必ず保存しておきます。
Apache2, mysql server, php7のインストール
t2 micro instanceの設定が終わったら、続いてMacのターミナルから先ほど準備したAWSのサーバーへ接続し、必要なパッケージをインストールしていきます。
ターミナルからEC2 instanceへつなぐには、以下のコマンドで接続できます。
EC2 instance上へのインストールについては、以下の動画がとても参考になります。
Apache2は、webサーバソフトウェアで、先ほど準備したt2 micro instance serverから、各コンピュータへhtmlやら画像やらを送る手伝いをしてくれるものです。そして動画ではphp5のインストール、という説明がありますが、php5は既にサポートされておらず、代わりに、今回は以下のコマンドでphp7をインストールしました。
また、mysql-serverのインストール、と動画ではありますが、その方法は使わずに、mysqlを以下の手順でインストールしましょう。その際に設定するパスワードは、必ずメモしておきましょう。
How To Install MySQL on Ubuntu 18.04 | DigitalOcean
Filezilla, SequelProの設定
Filezillaは、File Transefer Protocolと呼ばれるソフトウェアの一つで、ローカルで作成したファイル（e.g. php file）をEC2 instanceへ容易にアップロードする事ができる様になります。
Sequel Proは、EC2 instance上のmysql serverへ接続し、データベースを管理するために使用します。
MySQL host: EC2, public DNS
Username: デフォルトはroot
Password: MySQLをEC2上に設定した時のパスワード
SSH HOST: EC2, public DNS
SSH User: ubuntu
SSH password: t2 micro instanceをたちあげた時に作成したkeypairですね。
Wordpressのインストール
続いてwordpressのインストールです。wordpress orgからファイルをダウンロードし、FTPを使用してEC2へアップロードしましょう。格納するパスは、デフォルトでは"/var/www/html/"です。
続いて、Sequel Proを用いて、ec2へ接続し、DBを1つ作りましょう。
後々、wordpressでブログを書くときは日本語で書く可能性があるため、UTF-8を選択しておきましょう。
この時点で、ec2のpublicアドレスへアクセスすると、以下のようなページが表示されます。
ガイダンスの通り、wp-config.phpファイルに必要情報を入力し、Filezillaを使用してec2へアップしましょう。
そして、もう一度ec2のpublicアドレスへアクセスすると、以下のページが表示されます。
それぞれに項目に必要な情報を入力すれば、晴れてwordpressがEC2 instance上へインストールされる事となります。
Happy Blogging.
それでは、本日は以上でございます。
「超 筋トレが最強のソリューションである。筋肉が人生を変える」を読んで
こんにちは、筋肉めがねです。
楽しく充実したバケーションもとうとう終わりを迎えました。美味しいものを沢山食べ、アクティブに行動した結果、少しだけ体調を崩してしまいました。
これまでにも、定期的に筋トレをしているにも関わらず一年に2, 3回体調を崩すことがあったのですが、自分でもその原因が良く理解できなかったんですよね。
その原因をようやく突き止めてくれた本に出会うことができました。「超 筋トレが最強のソリューションである。筋肉が人生を変える超科学的な理由」でございます。
ということで、本日は書評を書きます。
皆さんご存知の「筋トレが最強のソリューションである」シリーズです。今回の本は、筋トレが最強のソリューションである理由を科学的に説明しよう、という内容です。
筋トレ界隈に生きている端くれとして、書評を書かないわけにはまいりません。
先ずは、先ほどの疑問に対する答えから書いていきましょう。
激しい運動をしている人は、その運動をした後に、風邪などにかかるリスクが一時的に2-6倍になる、というデータがある、という事です。Pederson et al (1998)にて、紹介された内容ですが、この一時的に免疫能力が低下する時間帯をオープンウィンドウと呼ぶそうです。
例えば以下の論文では、免疫応答で重要な役割を果たすリンパ球について、その量を激しい運動の前後で測定しており、運動前と比較すると、運動後約2時間後には、リンパ球の量が80%程度にまで減少している事が確認できた、という事です。
http://eir-isei.de/2010/eir-2010-119-article.pdf
なるほど。これが原因ですね。これからは、がっつり筋トレをした後には、きちんとした栄養を取り、ゆっくりと休むことを意識していきましょう。
さて、オリジナルの「筋トレが最強のソリューションである」で紹介された内容を、今回の本にて、データで裏付ける、という立ち位置となった良書でございますが、オープンウィンドウ説以外にも、とても興味のある内容が多々ありましたので、幾つか以下に紹介します。
- 筋トレによって分泌される代表的なホルモンは以下のようなものがある。
- テストステロン
- これは、言わずもがな、男性ホルモン。
- 効能としては、骨や筋肉の強度の維持、動脈硬化やメタボリックシンドロームの予防、やる気や闘争心の向上。
- 続いてセトロニン、幸せホルモンと呼ばれる事もある。
- 効能としては、心を安定させる、落ち着かせる。
- 脳を最適な覚醒状態にする。痛みの調整をする。
- 最後に、ドーパミン、βエンドルフィン、ノルアドレナリン
- 効能としては、多幸感や気分の高揚、興奮など。
- プロテインの語源
- 古代ギリシャ語で、プロティオス、という言葉があり、「最も重要なもの」を意味する、との事。
- なるほど、最も重要なものであるプロテインを摂取しない手はなさそうですね。
- 大腿四頭筋の筋力が1に対して、ハムストリングの筋力が6- 0.7ぐらいがベスト。
- ふむ。
- アメリカでは、スポーツという授業の時間に筋トレを選択できる、という事。
- ほうほう。
- 筋トレのアンチエイジングへの効果として、骨への効能がある。
- 筋トレは、スクレロスチン、という骨形成を阻害するたんぱく質が減少し、骨形成を促すIGF-1の分泌量が増加する。
- なるほど。
- 筋トレは、スクレロスチン、という骨形成を阻害するたんぱく質が減少し、骨形成を促すIGF-1の分泌量が増加する。
- 古代ギリシャ語で、プロティオス、という言葉があり、「最も重要なもの」を意味する、との事。
- テストステロン
中でも興味をそそられたのは「食事誘発性熱産生」という言葉ですね。
僕ら人間は、食事から栄養を摂取する際に、つまり栄養を吸収する際にも、カロリーを消費するんだそうです。例えば、100k calのものを摂取した場合、それがたんぱく質であれば、100k calのうち30k calは、吸収するときに消費する、との事。つまり、30%のカロリーについては、消化の際に消費される、という事です。これが、脂質と糖質では約7%との事です。同じ満腹感を得られるのであれば、消費カロリーの高い高たんぱく質のものを食べた方が、脂肪として体に溜まりにくいんですね。
科学的に証明する、とは言え、本書にもところどころにtestosterone氏の語録が散りばめられております。
筋トレで増すのは「希望」と「筋肉」、減るのは「ネガティブ思考」と「贅肉」、との事でございます。
それでは、本日は以上でございます。
