ConohaのVPSは512MBのプランを利用している場合のみ、スケールアップができない
そのため、512MBプランのみ
1. 利用中の512MBのイメージの保存
2. 保存したイメージでサーバーを構築
という順序になる。
まとめ
以上、終わり！
サーバーを移行してIPアドレスが変わった時のお名前.comの設定
サーバーのIPアドレスとドメイン名は、DNSレコードで紐づけて管理されている。
私の場合であれば...
| ドメイン名 | IPアドレス |
| fmbrain.work | 150.95.153.147 |
サーバーを変更すると、IPアドレスが変わる。
| ドメイン名 | IPアドレス |
| fmbrain.work | ???.???.???.??? |
変更後のIPアドレスをお名前.comで変える設定をする必要がある。
DNSレコードとは
DNSレコードはTYPEで分かれていて、それぞれ管理するものが異なっている。
TYPE:CNAME
あるドメイン名とあるドメイン名は、同じIPアドレスである、ということを管理している。
例えば、amazon.comのIPアドレスが176.32.103.205であるとする。
Amazonは、amazon.com以外にもドメイン名を取得していて、例えば、awake.comというドメイン名も取得している。
awake.comとamazon.comは、同じIPアドレスを参照する、ということをTYPE:CNAMEにて管理することができる。
他にもwww.amazon.jpとamazon.jpというようにwwwを同じIPアドレスに向けるということもCNAMEで管理する。
変える設定
サーバー移行して、IPアドレスが変わった場合は、極論、DNSレコードのTYPE:Aのドメイン名とIPアドレスの紐づけを変更するのみ。
| ドメイン名 | IPアドレス |
| fmbrain.work | ???.???.???.??? ← 新しいIPアドレス |
お名前.comのDNSレコード設定から、変更可能。
まとめ
特になし。
以上、終わり。
chart.jsをフロントのデザインに使う
chart.jsは、キレイな可視化が簡単にできるJavaScriptのライブラリですが、使い方を工夫すればフロントのデザインにも流用できます。
データ系を扱うWebサイトであれば、サイトイメージと一致したデザインになると思います。
私はこんな感じで使っています。
サンプル
4つの構成要素
グラフを数秒ごとに変化させるには、普通のchart.jsで描くグラフに4つの追加要素を入れます。
- グラフ化するデータ生成
- chart.jsのグラフのアップデート
- 数秒ごとのアップデートの実行
- グラフからX軸・Y軸などを非表示
基本的なchart.jsのグラフ描画の部分は省きます。
ここがわからない方はドットインストールで学びましょう。
https://dotinstall.com/lessons/basic_chartjs
グラフ化するデータ生成
数秒毎にグラフを変化させるには、数秒毎にグラフに使うデータを変化させる必要があります。（当たり前ですが...）
適当に乱数でデータを作りましょう。
関数化して、数秒毎に使える形にしましょう。
function generateDataSets() { var datasets = [] for (i=0; i<11; i++) { datasets.push(Math.random()) } return datasets }
chart.jsのグラフのアップデート
数秒毎のグラフのアップデートは、chart.jsの公式マニュアルにも使われています。
便利なことにグラフをアップデートをさせるための関数が用意されています。
myChart.update();
マニュアルにもちゃんと書いてあります。
Updating Charts · Chart.js documentation
使い方は簡単で、グラフを描画しているクラスのデータを入れ替えたあとに、myChart.update();するだけです。
グラフをアップデートさせるコードも数秒毎に実行させるので、関数化します。
function addData() { var data = generateDataSets(); myChart.data.datasets[0].data = data myChart.update(); }
数秒ごとのアップデートの実行
setIntervalで、先ほどのグラフをアップデートする関数を実行します。
setInterval(addData, 2000);
グラフからX軸・Y軸などを非表示
Y軸やら、マウスオンでチップが表示されるとグラフ感が出てしまうので、これらを非表示にする設定をします。
グラフに追加する設定は以下です。
- 凡例の非表示
- マウスオンしたときのチップの非表示
- X軸Y軸の非表示
- グリッド線の非表示
chart.jsはグラフに関する追加設定は、optionのところに書いていきます。
optionにこんな感じで書いていきます。
legend : {
display :false
}
面倒なので、グラフの描画の部分ごと貼ります。
optionの部分に注目です。
var randomDatasets1 = generateDataSets(); var label = ['1', '2', '3', '4', '5', '6', '7', '8', '9', '10']; var ctx = document.getElementById("background-chart").getContext("2d"); var myChart = new Chart(ctx, { type: 'bar', data: { labels: label, datasets: [{ label: 'random1', data: randomDatasets1, backgroundColor: "rgba(53,216,53,0.5)" // backgroundColor: "#FDD835" }] }, options: { legend : { display :false }, tooltips : { enabled: false }, scales: { xAxes: [{ display: false, gridLines: { drawBorder: false } }], yAxes: [{ display: false, gridLines: { drawBorder: false } }] } } });
ソースコード
<canvas id="background-chart"> </canvas> <script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.7.2/Chart.min.js"></script> <script> function generateDataSets() { var datasets = [] for (i=0; i<11; i++) { datasets.push(Math.random()) } return datasets } var randomDatasets1 = generateDataSets(); var label = ['1', '2', '3', '4', '5', '6', '7', '8', '9', '10']; var ctx = document.getElementById("background-chart").getContext("2d"); var myChart = new Chart(ctx, { type: 'bar', data: { labels: label, datasets: [{ label: 'random1', data: randomDatasets1, backgroundColor: "rgba(53,216,53,0.5)" // backgroundColor: "#FDD835" }] }, options: { legend : { display :false }, tooltips : { enabled: false }, scales: { xAxes: [{ display: false, gridLines: { drawBorder: false } }], yAxes: [{ display: false, gridLines: { drawBorder: false } }] } } }); function addData() { var data = generateDataSets(); myChart.data.datasets[0].data = data myChart.update(); } setInterval(addData, 2000);
VPSでサービスを運用していたら、エラーログにKilledが大量にはかれていた（解決済み）
エラーログを見ると...
サービスの定期実行のプログラムがうまく動いていなかったので、エラーログを見てみると...
killed killed killed killed killed
conohaのVPSを利用していて、nginxでWebサーバーを立てて、かつ、裏でpythonで複数の処理をしています。
大量にkilledされているのは、pythonのプロセスです。
killedのエラーの意味は？
リソースが足りず、強制的にプロセスがkillされています。
私の場合は、conohaの一番安いプランのメモリ500MBです。
そのため、単純に500MBのメモリじゃさばけない量のプロセスを走らせた、ということです。
解決策
1. メモリを増やす
2. 処理を軽くする
メモリを増やして、プロセスをさばけるようにするか、あるいは走らせる処理のメモリを食う量をへらすの2択だと思います。
メモリを増やす、というのはつまり、conohaのプランをグレードアップさせる、ですね。
メモリの使用状況を調べる
グレードアップさせてもメモリが足りるかわからないので、現状の使用状況を調べます。
Linux系であれば、freeコマンドで簡単に調べることができます。
hoge@fuga:~$ free
#freeコマンドは基本的にKB表示なので、読みにくいです。
#そのため、オプションコマンドの-hをつけて、人間に読みやすい単位で表示させます。
hoge@fuga:~$ free -h
total used free shared buff/cache available
Mem: 488M 363M 12M 5.6M 112M 65M
Swap: 2.0G 2.0G 0BメモリはMemの行。
totalがメモリの総量で、usedが利用中のメモリ量。
freeは、利用可能なメモリで、sharedは無視。
buff/cacheは、ファイルへのアクセスやHDDなどの記憶媒体へのアクセスのキャッシュをためているので、Linuxを使っていれば必ず溜まっています。
実質、利用可能なメモリです。
なので、利用可能なメモリとして利用可能な総量は、freeとbuff/cacheの足し算です。
ですが、ここは単純な足し算ではないようで（ここらへん理解していない
結果的にavailableを見ればOKです。
私の場合は、65Mしか利用可能なメモリが残っておらず、サービスの構成としてはnginxとpythonの処理です。
nginxのサーバーを立ち上げるだけでメモリは30~50MBは使い、アクセスがあれば、プラスアルファでメモリを消費します。
もちろんキャッシュの利用はしていますが、あまりにバッファが少ないですね。
ここでさらにpythonの処理をしていたため、メモリが足らずkilledされていた、ということです。
conohaは、一つグレードアップさせると1G使えるので、これでいけそう。
メモリはマックスの500MB使えるわけではない
ちなみにVPSのメモリは500MBあるのになんで100MBしかavairableが残っていなんだと。
OS動かしているだけでかなりメモリ食うんですよね。
windowsはもっと酷くて、4GBあってもデフォルトで2~3GBはメモリを消費していた印象です。
今、VPSで使っているのはUbuntuで、Linuxの中では重い方のOSです。
通常のメモリ消費が少ないのはCentOSあたりだと思っています。
ここらへんのインフラ周りはあまり詳しくないので、たぶん、ですが。
まとめ
メモリなんて意識してプログラム書いたことないので、killedのエラーは若干戸惑いました。
以上、終わり！
エンジニアの私でもサイトをデザインする時に最低限必要だったツールやサービス
あっぱれなほど私にはセンスがありません。
欠けているというよりは、もとよりそこにないって感じ。
ただ、悲しいことにサイトを作ったら、逃げて通れないのがデザイン...
pythonメインで使う私からすると、ここが本当に辛い。
そんな私でもデザイン頑張ってやって、そんな中でこれは必要！となったものは、きっと私のようにセンスない系の他のエンジニアがサイトをデザインするときは必要になるかと思います。
デザイナーのようにオシャレ度を高めるための高尚なツールというよりかは、本当に最低限必要だったツールやサービスをつらつら書いていきます。
ちなみに作ったのはこんなサイト。
参考サイトを見つけるウェブギャラリー
オシャレサイトが見れるウェブギャラリーです。
センスのない私は、自分のセンスで作るとまるで90年代に作られたかのようなサイトを素で作ってしまいます。
なので一切、自分のセンスは信じず、このウェブギャラリーにのっているサイトを徹底的にパクります。
ウェブの構成や色が似ているサイトを見つけてきて、ずーーーーーっとそれを見て、パクります。
センスのある人は、そこから自分の味を出していくそうですが、私は自分の味を出すと負けるので、徹底的にパクります。
きっとウェブのデザインをするときに一番心がけているのは、これですね。自分の味を出さない、パクる。
イメージカラーからもサイトを選べるので、自分が使っているメインカラーに合わせて参考サイトを見つけることができます。
かなり重宝しています。
気に入ったサイトに使われている色のカラーコードがわかるツール
FireFoxでも他のブラウザでも何かしら似たものはあるはずです。
基本的には、サイトの検証でCSS見たらいいですが、こっちほうが楽ですし、画像とかの色も拾えるので重宝しています。
自分の使いたい色と相性の良い色を見つけれるサービス
色には組み合わせがあるそうで、どの色とどの色を組み合わせるとオシャレになるかは決まっているそうな！
例えば、紫と緑は相性が良くて組み合わせるとオシャレになるそう！
たしかにエヴァンゲリオンとかそうっぽい。
正直、センスない私の理解の範疇を超えているので、自分で配色するのは自殺行為です。
この色を使いたいけど、もう一つ色を選ぶとすると何色が良いんだろうか、みたいな状況は、このサイトを使います。
配色のサービスはかなりあるんですが、自分が色をカラーコードで指定できるのはあまりない印象です。
なので、重宝しています。
ダサいサイトでもオシャレな画像使えば、ちょっと誤魔化せる説
freepikの画像を使っています、ということを明記すればフリーで使える画像サイト。
めっちゃオシャレな画像多い。
ここの画像使ったらダサいサイトでも、ちょっと誤魔化せる。
重宝する。
ダサいサイトでもオシャレなフォント使えば、ちょっと誤魔化せる説
Arial（←デフォルトのやつ）はセンスのない私でもダサいフォント認定をしています。
アルファベットだと、そこまで気にならないですが、日本語のデフォルトだと本当にやめてほしいくらいダサいですね。
せっかく頑張ってデザインしても、サイト中に散りばめるフォントがダサいと、頑張った意味半減です。
ブラウザに指定したら使えるフォントは、日本語勢は「游ゴシック」以外は、壊滅していると思っています。
しかも、なぜか「游ゴシック」はスマホからだと指定できないという謎の現象がおきます。
そのため、どうあっても、フォントをダウンロードするなりして、デフォルトのフォントからは脱する必要があるのです。
そこで見つけたのが、typesquareです。
1万アクセスまでなら、無料でオシャレなフォントが使えます。（モリサワのフォントもある！）
野良サービスには十分なキャパです。（1日300アクセスくらいまでなら耐えれる）
重宝しています。
Web開発フレームワークの王道「BootStrap4」
書くか迷うレベルでしたが...
今回のサービス開発で1年ぶりくらいにhtml、cssを書くことになったのですが、前にbootstrapを使った時はバージョン3でした。
4に進化していました。
また学習するの面倒だしbootstrap3を使おうかなぁと思ったのですが、保守な姿勢の自分に嫌悪して、bootstrap4を使いました。
これが大正解。めちゃいい。
bootstrap3派は、すぐに乗り換えるべき。
同じbootstrapなので言うほど変わっていませんが、個人的にはマージンやパディングの設定がしやすくなりました。
とっても重宝しています。
まとめ
まだまだサイトはオシャレ追求中です。
オシャレなサイトを見てから、自分の作ったものを見るとどうしても見劣りするので、ちょっとづつ見劣りする部分を修正していく所存です。
以上、終わり！
サービスリリースしました 「FmBrain」～投資のプロの判断を提供する～
サービスをリリースしました
「投資のプロの判断を提供する」というキャッチコピーでやってます。
投資のプロの判断とは、ファンドマネージャーのことで、ファンドマネージャーが「買い」と判断した銘柄と「買い」と判断した価格がわかる、という内容のサービスです。
対象ユーザー
投資経験あり、でかつ、中長期での投資をする人を対象にしています。
知ってます、めっさ対象狭いです。
ただ、こればかりは仕方がない気がしています。
中身のロジックをフルオープンにしていて、このロジックを理解できる人しか使えないからです。
サービスの内容
ほとんどFmBrainのサイトの中に書いていますが、サイトに書いていないところもプラスで書いていきます。
サービス内容は、これに尽きます。
投資信託が買った株式（国内株式）の現在価格が、その投資信託が取得したときの価格に近づいた場合(1%以内)に表示しています。
もう少し補足すると、投資信託は様々な株式・債券などに投資をしています。
これらは組入資産と呼ばれていて（そのまま組み入れている資産）、多くの投資信託は公開をしています。（これ以外と知られていないです。）
一般投資家からすると、中で何をしているのかイマイチわからないのが投資信託の特徴だと思います。
そこらへんの金融商品としての透明性というは考えられていて、投資信託が何を買っているか、というのはきちんと公開されているんです。（どこで公開されているかは後で書きます）
公開していいの！？なんて思う人は真っ当な考えて方で公開してない投資信託もあります
ここはファンドマネージャーの考え方が大きいのかなと推測しています、組入資産を公開することで投資家への安心感を大事にするのか、あるいは、買いロジックを秘密にしたいのか。
組入資産を公開するのは投資信託の義務のようです。
とにかく、投資信託が買った株式は公開されており誰でも、何を買っているか、1株あたり何円で買ったのか、というのは調べることができます。
有価証券報告書の中でこんな感じでのっている。
この情報を使って、投資信託が買った株式（国内株式）の現在価格とその投資信託が取得したときの価格を比較し、これが1%以内である株式をFmBrainで提供をしています。
そして、分析対象の投資信託は約40個です。
分析対象の投資信託もFmBrainのサイト内で公開しています。
この40個の全ての投資信託の組入資産の価格を毎日監視し、1%以内に近づくとすかさず表示する、というのがFmBrainです。
このサービスの何が良いの？
投資のプロであるファンドマネージャーが「買い」と判断した銘柄と「買い」と判断した価格がわかります。
ファンドマネージャーが買いを入れる、というのは端的に「伸びる」と判断した銘柄です。
そして、その判断の裏側には数多くのアナリストの業界調査や会社自体の調査、また様々な分析があります。
そのため、表示された銘柄を買うということは、アナリストやファンドマネージャーが汗水流して調査した結果のアウトプットだけを享受する、ということになります。
私自身の投資経験からも、「買い」と判断した価格、というのはとても大事です。
買いを入れる、というのは決してフィーリングではなく、様々な裏付けや分析の結果です。
「買い」と判断した価格、というのは深い意味があります。
ただ、伸びると思う銘柄でも、いつ伸びるか？というのは全くわかません。
1年後かもしれないし、5年後かもしれない。
それはファンドマネージャーでも同じで、時期まではわかりません。
ファンドマネージャーが「買い」と判断したけど、まだ上がっていない、という銘柄を選ぶために試行錯誤した結果、FmBrainが生まれました。
まだ上がっていない、というのをフィルタリングをかけるために表示するのは1%以内にしてます。
すでに値上がりしたものを表示しても仕方がないですからね。
情報の取得元
有価証券報告書です。
投資信託は、事業年度ごとに運用状況を開示する義務があります。
この開示する際に使われているドキュメントの名前が有価証券報告書です。（有報と呼ばれることが多い）
事業年度は、投資信託の種類によって違って、だいたい年1回か半年に1回が多いです。
中には毎日のものもあります。
この制度自体は、会社と同じです。
そして、有価証券報告書は電子データでの提出が義務付けられており、この電子データはEDINETという金融庁のサイトでダウンロードが可能です。
そのため、投資信託が運用状況を報告する度にEDINETに有価証券報告書がアップロードされます。
この有価証券報告書には、投資信託の組入資産が書かれているのでFmBrainは、この有価証券報告書の電子データを使っています。
ここから蛇足。
このEDINETがお世辞にも使いやすいとは言えず、どこのベンダーが作ってんねん、ほんと。
どこが作ってるかなんてだいたい想像つくけど。
しかも、電子データがXbrl形式という聞いたことのない規格。
それもそのはず独自規格っぽい。
しかもしかも、中身のデータ構造もグッチャグチャでデータの取得は困難を極めました。
電子データの構造がグッチャグチャだけならまだしも、投資信託によって構造が違うとカオス状態...
もうほんと、有価証券報告書からデータを取得するというだけでビジネス起こせるレベルです。
株式の方は、どこかの誰かがAPI化して情報が取得しやすいようなのですが、投資信託はされておらず、FmBrainを作る中で一番苦労したのが、このカオスな有価証券報告書の電子データから情報抜いてくるところでした。
思い
プロがどんな株を買っているかって知りたくありません？
私が個別株を売買していた時は、知りたかったので、取引内容を公開している投資ブロガーの人のブログをよく読んでいました。（今は金融系の会社ということもあり、個別株の売買はちょっとややこしくしていません）
情報としては開示されているので、プロがどんな株を買っているかを知ることはできます。
ただ現状、その情報へのアクセスは悪いです。
有価証券報告書もEDINETも、そもそもの認知度が極めて低いです。
私がこれらを知り得たのも金融系の会社で働いているからであって、普通にしていても決して出会うことはなかったです。
こういった情報へのアクセスの悪さや認知度の低さに優位性や独自性を感じたので、FmBrainを作りました。
ぜひアクセスして見てほしい
ここまで読んでくれた方はぜひアクセスして、FmBrainを使ってください。
中身のロジックだけじゃなくて、デザインもほんの少し頑張ったので、とりあえず見てみてください！
nginxとuwsgiを使っていてInternal Server Errorが発生したとき
Internal Server Error
nginxとuwsgiを使っていてInternal Server Errorがでたので、対処法をまとめておきます。
Internal Server Errorが発生している原因は、uwsgiの設定のミスと権限の設定のミスの2つでした。
エラーログを見てみる。
cd /var/log/nginx tail -n 100 error.log
以下、エラーログ。
connect() to unix:///tmp/uwsgi.sock failed (2: No such file or directory) while connecting to upstream,
uwsgi側でソケットが作成されず、uwsgi.sockが見つからない、というエラーっぽい。
uwsgi側に原因があると判明しました。
原因1
権限
公開ディレクトリの権限が正しくありませんでした。
/var/www/html
このhtmlの権限がrootになっていたので、書き換え。
chown -R www-data:www-data html
nginxはwww-dataユーザーが実行することになるため、www-dataがアクセスできる権限にしておかないといけない。
原因2
uwsgiの設定
uwsgiを立ち上げたときに、エラーがでている。
uwsgi --ini index.ini
以下、エラー。
ImportError: No module named 'app'
モジュールの呼び出しに失敗しているので、これはuwsgiでエラーが発生はしているが、python周りっぽい。
以下、uwsgiの設定。
[uwsgi] module = app callable = app master = true processes = 1 socket = /tmp/uwsgi.sock chmod-socket = 666 vacuum = true die-on-term = true
module = app、こいつが原因だ。
moduleには、アクセスがあったときに立ち上がるpythonファイルを指定する。
この場合だと、app.pyが立ち上がる設定になっている。
しかし、app.pyなんてファイルはないため、ImportErrorが発生している。
そういえば、app.pyではなく、index.pyという名前で作成していた。
module = appからmodule=indexに書き換えて解決。
うっかりミス。
まとめ
以上、終わり！
