自作キーボードキットHelixPico
電池ってなんだろう
技術的な文章はかなり時間がかかるので、ここで地球や社会について思うことなど雑記として書いて行こうと思います。
最近ハマっているのが発電・蓄電です。
特に燃料電池にハマっています。
そもそも電池ってなんだろう？と
蓄電ってなんだろう？と
停電すると手も足も出ないじゃないですか。なんとかしたい訳です。
停電したらコンビニに電池を買いにいっても、争奪戦になる訳で、、、
だから、電池ってなんなのか知っておこうと思いました。
iPhoneとかにケーブルを繋いで充電すると、電気が溜まるわけで一日利用できるわけですが
これって実は電気っていうものが溜まっているわけじゃないんですよね。
ただの化学変化で、最近のスマホではリチウムイオン電池っていう最新のものが使われているわけだけど
これって、電池の中でプラス極とマイナス極が２つあって、その間をリチウムイオンが移動する事(酸化還元反応)で
電気を貯めたり、放出したりする現象を利用しているわけ
イオンって？引用します(
リチウムイオン電池の豆知識 - リチウムイオン電池の豆知識
)
イオンとは、電子の過剰または欠損により電荷を帯びた原子（または原子団）のことを言います。リチウムイオン（Li+）は、リチウム原子（Li）が電子（e-）を放出してプラスの電荷を帯びた陽イオンです。リチウムイオンが電解質を通して正極と負極を行き来するときに正極と負極を結ぶ回路に電子の流れ（電流）が発生するので、電池の充電・放電が可能になります。リチウム原子（Li）が電子（e-）を失ってリチウムイオン（Li+）となる反応を酸化、逆にリチウムイオンが電子を得てリチウムに戻る反応を還元反応といいます。
リチウムはすべての元素の中で最もイオン化しやすい（イオン化傾向が強い）元素です。
つまり電荷を帯びたリチウム原子をリチウムイオンっていうわけ。
で、電子が移動する事で、電流が流れるわけです。
で、リチウムイオン電池って最先端の電池なのでちょっと不安定かつ難しいんだよね。
そんなわけで燃料電池がわかりやすくていい
中学校の理科の授業で水の電気分解をやったと思うけど、その逆が燃料電池なんだよね。
だから本当に簡単で、この北ガスのサイトにあるように、家庭で自作できる！
えんぴつで燃料電池を作ろう！｜自由研究おたすけガイド｜北ガスキッズサイト それいけ！！エネルギー探検団
そんな訳で燃料電池を自作しようかと思っとります。
KUSANAGI@Conohaでオブジェクトストレージ設定のベストプラクティス
こんにちは、のすけです。
KUSANAGIを利用する理由として、今まで利用していたサーバーが遅いので
変えたいという動機が多いかと思います。
しかしながら、前回紹介して方法だと、WordPressをKUSANAGIに移行する場合
既存のメディアライブラリの画像などが上手く認識されないなどの問題が出てきました。
他の方法を模索したところ、別の手法を見つけました。
ConoHaオブジェクトストレージをマウントしてWordPressでのメディア保存先にする | サイト制作覚書
ただ、こちらの手法ですとディスクのマウントに失敗する事が多いため
あれこれと試し、最適な方法を見つけました。
まず、手順通り cloudfuseを入れます。
cloudfuseを入れる
yum -y install \
libcurl libcurl-devel \
fuse* fuse fuse-devel fuse-libs \
libxml2 libxml2-devel openssl-devel \
gcc gcc-c++ make git curl
git clone https://github.com/redbo/cloudfuse.gitcloudfuseというディレクトリができています。
cd cloudfuse .configure
jsonのエラーが出たのでjson-c-develをインストール
yum -y install json-c-devel .configure make make install cd ../ rm -rf cloudfuse
ホームディレクトリ以下に .cloudfuse というテキストファイルを作成する
cd nano .cloudfuse
内容
username=APIユーザ名 tenant=テナント名 password=APIパスワード authurl=https://identity.tyo2.conoha.io/v2.0 (Identity ServiceのURL) verify_ssl=True
Ctl(controlY)+X Y Enter
で保存します。
マウントテスト
cloudfuseを使ってマウントテストします。とりあえず /mntにマウントします。
cloudfuse /mnt df -h
大丈夫なようなら次に進みます。もし問題がある場合は「.cloudfuse」の設置値に問題があるので修正します。
自動マウント
それでは次に重要な自動マウント設定をやります。
私はここの検証にかなりの時間を使ってしまった。
最初は手順通り /etc/fstab を使って設定したのですがうまく自動マウントされなくてハマってしまいました。
その他、crontabの@rebootで、再起動後のスクリプトでcloudfuseコマンドを打ったりしたのですが、特定のユーザアカウントでは参照できるが
別のアカウントではドライブが参照できないなど、色々と罠に合いました。
結果的に、最初の「/etc/fstab」に設定を入れるのが最適だと判断しました。
ダメだった方法(crontab)
crontabの起動時に一度だけ実行される設定を追加してみました。
crontabに以下を追加
crontab -e
以下を最後の行に追記(xxxxxxのところはご自分のConohaAPIの設定値を入れてください)
@reboot /usr/local/bin/cloudfuse -o nonempty -o username=gncuxxxxxxx,tenant=gnctxxxxxxxx,password=xxxxxxxxx,authurl=https://identity.tyo2.conoha.io/v2.0,verify_ssl=True /home/kusanagi/rsel_terakoya/DocumentRoot/wp-content/uploads
結果、これでは特定のユーザしかディスクが参照できずダメでした。mountのオプション指定でなんとかなるのかもしれませんが、kusanagi
やnginxのユーザのアクセス権など混乱するので、結果的に諦めました。
/etc/fstabとは
OSを起動したときに、この/etc/fstabファイルが参照されます。そうするとそこに書かれている設定値でファイルシステムをマウントします。
例：
# cat /etc/fstab /dev/hda1 / ext2 defaults 1 1
・1列目：デバイスファイル名
・2列目：マウント場所
・3列目：ファイルシステムの種類(ext2,ext3など)
・4列目：オプション
・5列目：dumpでバックアップするかしないか。(0 or 1) ext2やext3は1を指定する。
・6列目：システム起動時にファイルシステムチェック(fsckチェック)する順番を指定 (0,1,2) 0の場合はチェックしない 。ルートファイルシステムは1にしないといけない。
cloudfuseを/etc/fstabに設定数する
という事で /ect/fstabを使っていきました
# cd /home/kusanagi/( kusanagi_provision_name )/DocumentRoot/wp-content/ kusanagi_provision_nameにはKUSANAGIをセットアップ下際のプロジビジョン名を入れます
次にupulodsに変わるマウントポイントとなるディレクトリを作ります。(ex: cos)
# mkdir cos # vi /ect/fstab
一番下の行に次を追加します
/usr/local/bin/cloudfuse /home/kusanagi/( kusanagi_provision_name )/DocumentRoot/wp-content/cos fuse username=gncuxxxxxxxx,tenant=gnctxxxxxxxx,password=xxxxxxxxx,authurl=https://identity.tyo2.conoha.io/v2.0,verify_ssl=True,auto,_netdev,defaults,umask=001,allow_other 0 0
説明：cloudfuseでcosをマウントします。
usernameやtenant,passwoed,authurl, verify_sslは.configureと一緒ですね.
あとは、autoでmount -aで自動マウントするように。_netdevでネットワーク接続語にマウントを実行するオプションを指定
重要なのは,umaskで001を指定する事で,chmodの776と同じくなります。003でも良いかもしれません。
設定したら、うまくいくか確認します。
mount -a
何も表示されなければokです。
dfコマンドで、マウントを確認します。
df -h
よければ再起動して、テストします。
reboot
再起動後、ログインしてdfで再度確認します。
df -h
こんな感じでマウントされて入ればOKです。
WordPressのメディアの参照先を変える
このままでは、「uploads」を参照してしまうので、作成した「cos」を参照するように変更する必要があります。
管理画面にログインし、URLを「/wp-admin」
から
「/wp-admin/options.php」に移動します。
するとWordPressのオプション設定画面にいくので
以下の設定を入れます。
WP options設定
upload_path wp-content/cos
upload_url_path https://object-storage.tyo2.conoha.io/v1/nc_(テナントID)
※upload_url_pathについては環境によって違うかもしれません。Cyberduckにアップロードしたファイルを選択して右クリックした際に、「URLをコピー」をクリックして取得したURLの最後のファイル名を除いたURLを設定します。
おまけ Cyberduckにアップしたファイルが参照できない場合
自分のPCのconoha-ojsをインストールします。
GitHub - hironobu-s/conoha-ojs: CLI-tool for ConoHa Object Storage
インストール後、認証して
conoha-ojs auth -u "gncuxxxxx" -p "xxxx" -t "xxxxxxx" -a "https://identity.tyo2.conoha.io/v2.0"
公開したいディレクトリを公開設定します
例：2017と2018を公開させる
conoha-ojs post -r ".r:*" 2017 conoha-ojs post -r ".r:*" 2018
ConoHaのKUSANAGIで追加ディスクやオブジェクトストレージを設定する
こんにちは、のすけです。
前回、conohaで高速WordPress実行環境であるKUSANAGIを動かす記事を書きました。
とても速くて快適なのですが、１つ問題があります。
それはディスク容量です。初期設定でルートドライブがSSD50GBになっており
多少、心もとないのが実情です。
そこで、cohohaのサービスを使ってその問題を解決します。
方法は２パターン
- 追加ディスクを購入してマウントする
- オブジェクトストレージを使う
それではざっくりと順番に説明していきます。
追加ディスク
conohaには追加ディスクと呼ばれるSSDを追加で利用する機能があります。
2018年10月現在 200GBだと 2,500 円/月 ( 3.5 円/ 時間 )で利用できます。
また、500GBだと4,500 円/月 ( 6.3 円/ 時間 )で利用できます。
作成方法
VPSの「ディスク」メニューから追加することができます。
「新規ディスク」を選んで、名前を適当につけて「追加」を押すだけです。
ちなみに保存したディスクイメージも利用できるようです。
そして、ディスクの画面から任意のVPSに接続させます。「接続先」の項目が未接続になっていると思いますので、そこを任意のVPSを選んであげます。
そうすると、VPSから認識可能になります。
追加ディスクのマウント
パーティションを初期化します
parted -s -a optimal /dev/vdb -- mklabel msdos mkpart primary ext4 1 -1
mkfs.ext4 /dev/vdb1
マウント先のディレクトリを作成します(ここでは/home/kusanagi/dataにマウントするものとします)
cd /home/kusanagi/ mkdir data
ここで、マウント先を/home/kusanagi/DocumentRoot/wp-content/uploadsみたいな感じに￥にすれば、ファイルのアップ先を追加ディスクにすることもできそうです。
(未検証)
マウントを実行します
mount /dev/vdb1 /home/kusanagi/data
確認します。
df -h
次のような結果になってれば成功です。
/dev/vdb1 197G 60M 187G 1% /home/kusanagi/data
オブジェクトストレージ利用
オブジェクトストレージとは
ConoHaのオブジェクトストレージは、インターネット経由で使用できるオブジェクトストレージサービスです。
容量無制限、転送量無制限、可用性が高いストレージサービスを、わかりやすい価格体系で利用できます。ConoHaのVPSサービスから利用することはもちろんですが、ConoHaを 利用していなくても利用することができ、APIを経由してウェブ上のどこからでもデータを保存、取得することができます。また、ConoHaオブジェクトストレージは、一般的なオブジェクトストレージの機能を満たしつつ、ConoHaのVPSからも簡単に利用でき、コントロールパネルが共通なため管理が簡単で、決済などもまとめることができます。
AmazonAWSのS3みたいなやつですね。違いとしてはデータ転送に課金されないのでConoHaの方がお得です。
オブジェクトストレージに適したデータは
- 画像ファイル
- 動画ファイル
- バックアップファイル
- ログファイルのアーカイブ
- 仮想マシンイメージ
なので、まさにWordPressのアップロードデータをオブジェクトストレージに突っ込んであげればいい感じになると予測できます。
ちなみに適していないデータは
オブジェクトストレージに適していないデータ
- リアルタイムに書き込みのあるログファイル
- 頻繁に更新のあるキャッシュファイル
では設定していきましょう。
Conoha APIの有効化
まずVPSの「API」メニューからConohaのAPIを有効にします。
そうすると、テナント情報、エンドポイントが書かれていると思います。
あとで利用するので覚えておきます。
WordPressのプラグイン「ConoHa Object Sync」を使う
有志の方がプラグインを作ってくれていますので、ありがたく利用させていただきます。
WordPressの管理画面からメディアを追加すると、自動的にオブジェクトストレージにアップロードを行います。オブジェクトストレージは容量無制限なため、空き容量を気にすること無くメディアファイルを扱うことができます。
また、このプラグインはメディアファイルのURLを変更し、オブジェクトストレージから直接配信するように設定します。これにより、WordPressを運用しているサーバに負荷をかけずに、メディアファイルを配信することができます
WordPressの管理画面から新規追加で「ConoHa Object Sync」で検索してインストール＆有効化します。
追加設定
KUSANAGIの初期状態だと、ファイルがアップロードできませんでした。
アップロードしよとすると「最大アップロードサイズ: 0 B」になっていました。
そこでWordPressのアップロード可能サイズを変更します
php系
vi /etc/hhvm/php.ini
次のように変更
upload_max_filesize = 400M post_max_size = 512M memory_limit = 512M hhvm.enable_zend_ini_compat = false
nginx系ファイル
(xxxxはkusanagiでプロヴィジョニングした名前)
vi /etc/nginx/nginx.conf vi /etc/nginx/conf.d/xxxx_http.conf vi /etc/nginx/conf.d/xxxx_ssl.conf
次のように変更
client_max_body_size 400M;
最後にKUSANGI(dbとかnginxとか)をリスタートして設定を反映させます。
kusanagi restart
そしてwordpressからアップロードしてみると次のようなURLでアップされました。
https://object-storage.tyo2.conoha.io/v1/nc_[apiのID]/[コンテナ名]/[年]-[月]-[ファイル名]
結構読み込み速度も速いのでこのURL直でもいいと思います。もし速度が必要ならCDNを間に入れればより速くなるのではと思います。
オブジェクトストレージはアクセス量の課金はないので安心ですね。いやぁ便利便利。
オブジェクトストレージは３TBまでサイズを変えることができるので、最初は100GB(450円/月)で設定して利用して行けば良いかと思う。
追加ディスクよりこっちの方が圧倒的に安いので、こっちの方が良いかと思います。
高速で動くWordPress環境を探して辿り着いた「KUSANAGI」に変えたら超速いし・安いし・データの転送容量制限ないしでかなり良かった
こんにちは、のすけです。
WordPress構築用のサーバーは各社から色々なものが出ていて
「WordPress おすすめ サーバー」なんて検索すると色々出てきます。
例えば有名どころだと、エックスサーバーやwpx
なんかは昔か速いと評判だったりします。実際速いです。
そのほか、速そうなのか「高速を追求したレンタルサーバー」と謳うヘテムルや
Lite Speed(なにそれ？)を使っているmixhostは速そうな感じです。
それでも、配信データ量の制限があったり、値段がちょっと高いという点があって躊躇します。
あとNodeサーバーも立てたいなとか。。
そんな時出会ったのが、こちら【Conoha】です。
レンタルサーバーも一応提供されていて
Conoha WINGは国内最速を謳っていたりします。が今回はVPSの方です。
公式キャラクターは「このはちゃん」
どうでもいいですねw。
で、このConohaですがなんと転送量に課金がありません。基本的にはいくらでも使えます。
さらに！！高速にWordPressが動作するサーバーイメージ「KUSANAGI for ConoHa」を提供しています。
このKUSANAGIは
WordPressの実行時間3ミリ秒台、秒間1000リクエストをページキャッシュ非使用で実現する世界最高速クラスのWordPress実行環境です
とのことで、かなり速そうな感じ。
早速使ってみました。
結果から言うと、Conohaの月900円の1Gプラン(推奨は4Gプランにもかかわらず)でかなり高速でした。
3秒と言うのはスマホで表示されるまでの時間なので、サーバ応答時間はもっと速くて
0.029秒とかなり高速な結果が出ています。
Conohaでサーバを立てる
基本的にはKUSANAGIの使い方｜VPSならConoHaのKUSANAGIの使い方を参考にすれば問題ないはずです。
Conohaのサイトに行ってアカウントを作成し、KUSANAGIのサーバイメージでサーバを１台立てます。
こちらConohaから「お申し込み」に進めばOKです。
KUSANAGI for ConoHaはメモリ4GB以上が推奨らしいのですが、それは高いし、あとあと変更できるので、まずはメモリ１Gでコア数２の月900円のプランでサーバーを構築しました。
あとでスペックを変更できるのもConohaの良いところです。サイトが重くなったらスケールアップできるので安心です。
そしたら、あとはrootパスワードを入れて「追加」したら数分でサーバーが出来上がりました。
ネームタグは適当に変更しています。クラウドなので、ここにWordPress以外にも色々なサーバを追加することができます。
KUSANAGIの初期設定をする
このサーバーイメージは、KUSANAGIはちょっと自分で初期設定をする必要があります。
この状態だとまだWordPressは入っていません。
管理画面のコンソールからrootでログインして
「KUSANAGI」の文字が出ればログインできています。
KUSANAGIの初期設定方法にしたがって初期設定をしていけばOKです。
最初にOSのアップデートで数分掛かります。
そのあと 次のコマンドを打つと初期設定が始まります。
# kusanagi init
URLの設定をする
下記リンクの手順通りに設定を進めます。
URL設定の方法にはKUSANAGIでは専用のやり方があって、その方法でプロビジョニングというものを行います。
次のように例えばkusanagi_testという名前で登録すると、そのディレクトリが作れられてWordPressがインストールされます。
# kusanagi provision kusanagi_test
注意することは、ホスト名(FQDN) を指定する場面で、とりあえずVPSに割り振られたグローバルIPを入れた方が良いです。
このホスト名で接続しにいく必要があるので、ここで適当なホスト名を入れると先に進めなくなってしまいます。
(そん場合はプロビジョニングをやり直す)
またLet’s EncryptでSSL証明書を発行するフェーズがありますがグローバルIPを設定している場合には、できませんので、Enterを2回押してスキップします。
あとで、グローバルIPをやめてドメイン設定をやり直したい場合には、またこのプロビジョニングをすれば良いのではないかと思います(※未確認)
KUSANAGIの設定
WordPressをインストールし終わり、管理画面にログインすると、自動的にKUSANAGIのプラグインが入っているのがわかるかと思います。
キャッシュを有効にするには次のコマンドを実行します。
# kusanagi bcache on
実行結果
[root@xx-xx-xx-xx]# kusanagi bcache on onにします。 完了しました。 [root@xx-xx-xx-xx]# kusanagi fcache on onにします。 Nginxを使用します。 完了しました。
自動的にWebサーバがNginxになるようです。
表示してみる
そして表示するとキャッシュが効いた状態で良い感じの速度が出ました！！
キャッシュがなくても速い、キャッシュを効かすともっと速い。
WordPressのテーマにサムネイルをサポートさせる
こんにちは、のすけです。
自分でWordPressテーマを作ると必要な機能のみ入れることができ本当に便利なのですが。
デフォルトの状態では投稿のサムネイルがサポートされていません。
そこでサムネイルをサポートする方法を記載します。
投稿のサムネイルサポートする
サムネイルをサポーとさせるには、functions.phpに設定を書き込みます。
add_theme_support( 'post-thumbnails' );
投稿サムネイル - WordPress Codex 日本語版
そうすると、投稿の編集画面で「アイキャッチ画像」メタボックスが投稿・固定ページ編集画面に表示されます。
もし表示されなければ、画面右上の表示オプションの中で「アイキャッチ画像」を有効にします。
一部の投稿タイプのみサムネイルをサポートする方法
例えばカスタム投稿タイプ「blog」と「kouza」にのみにサムネイルをサポートさせるためには、
add_theme_support( 'post-thumbnails', array( 'blog' ) ); // blogのみ add_theme_support( 'post-thumbnails', array( 'kouza' ) ); // kouzaのみ
テーマのテンプレートへの反映方法
サムネイルをサポートすると、次の関数を使うことで、投稿中にサムネイルが表示することができます。
// 投稿に投稿サムネイルが割り当てられているかチェックします。
if ( has_post_thumbnail() ) {
the_post_thumbnail();
}
the_content();
WordPressループの中で例えば、本文を表示するthe_content()の前で設定するなどできます。
has_post_thumbnail()でサムネイルが設定されているかを確認し、the_post_thumbnail()で実際に表示しています。
表示サイズを変える方法
次のように任意のサイズに変更することができます。
the_post_thumbnail( 'thumbnail' ); // サムネイル (デフォルト 150px x 150px :最大値) the_post_thumbnail( 'medium' ); // 中サイズ (デフォルト 300px x 300px :最大値) the_post_thumbnail( 'large' ); // 大サイズ (デフォルト 640px x 640px :最大値) the_post_thumbnail( 'full' ); // フルサイズ (アップロードした画像の元サイズ) the_post_thumbnail( array( 100, 100 ) ); // 他のサイズ
CSSクラスを設定する方法
Bootstrapなどでは画像用のスタイル指定などがあるため、任意のクラスを付けたいということはよくあります。
下記はクラス「img-thumbnail」を追加する例です。
<?php the_post_thumbnail( 'thumbnail', array( 'class' => 'img-thumbnail' ) ); ?>
ではまた！