「技術を持っている」と言う事と「技術を使っている」と言う事の違い

エンジニアの世界では

よく、○○の技術を持っている、経験しているから大丈夫だろう、と言う想定の上で採用活動をする。

だけど、技術を持っている、と言うのは、現在進行形ではない場合もあり、その場合は作業者としては使えるけど、開発チームのリーディングには向かない可能性が高い。

何を言いたいかと言うと、技術の鮮度の問題で

例えば、Rubyであれば、Rubyの最新バージョンが現在2.4で、Railsが5です、と言う時にRuby経験あり。Ruby1.8、Rails2やってました。といった人が来てもある程度は作業は出来るかもしれないけど

Railsの2から5になるまでにどんな変更が入っていて、それによってどんなコーディングをしたらいいのかと言うのが理解出来ていないので、採用をしても最新環境をキャッチアップするまである程度時間がかかる。

と言う話と、過去にRailsをやっていて、なんらかの別のプロジェクトに入り、疎遠になった状態の場合、またRailsをやる環境へ戻ってくるまでの間に、
Railsの最新のキャッチアップが出来ていない=Railsに対するモチベーションが低い
という事が言える。

これが技術を持っている、と言う表現。

技術を使っている

と言うのはそのままで、今現在その技術を使って何かしらやっています、という事。

仕事上のメインのプロジェクトで使っていなくても、常にキャッチアップしており

いつでも使えます、鮮度保ってます、という状態。

少人数のチームで採用をする場合、

特にこの、技術鮮度が新鮮な、「技術を使っている」人材を選ぶ事が重要。

プロダクトには共感があり熱意があるけれど、採用している技術要素についての熱意がなければ

そのプロダクトはエンジニアリングがうまく回らなくなっていく可能性が高い。

若手を採用する場合にも、ポテンシャルの中に、技術要素に対する熱意が持てる人材であるか?というのを含める必要がある。

リソースに余裕があれば、別の技術要素を選定して、といった話もあるかもしれないが、それは別の機会に。

 

野良猫と飼い猫(エンジニアの話)

エンジニアの世界での野良猫と飼い猫の話

どちらが幸せなのか?と言うのは人によってそれぞれだとは思うのだけど、
と言う断り書きをしつつ、ちょっとエンジニアを猫という生き物にたとえてみる。

野良猫(フリーランス・ベンチャー・起業・独立系)

エンジニアの世界だと野良猫はフリーランスや、ベンチャーに勤める、いわゆる大企業ではないところで働くエンジニアだと思っている。

ポイントは

  • 自由(リモートOK)
  • 挑戦が出来る(言語選定・技術選定etc)
  • うまく立ち回ればすごく贅沢が出来る

当然、リスクは多い

  • 車に轢かれることもある(大手競合に目を付けられてフルボッコにされる)
  • ご飯に有り付けないこともある(赤字)
  • 行き倒れる事も多々ある(倒産)

環境としては

mac指定とかはあったりするけれど

それ以外は、プロダクトにコミット出来るのであればなんでも構わない、といった環境が多い。

 

飼い猫(中〜大企業・大手)

飼い猫はエンジニアの世界で例えると、中〜大企業や、大手、Sierなど。

こちらの場合のポイントは

  • 家の中は快適
  • ご飯病院通い完備(保険、福利厚生)
  • 大きな挑戦は出来ない
  • 遊びたくて走り回ったりすると怒られる
  • じわじわと去勢される
    最悪、家に入るときに去勢される(社畜化)
  • 変なタイミングでおやつもらえたりするから、太る(怠ける)

こちらの環境としては

割とwindows指定が多く、さらに開発環境も固定され(java, eclipse only など)、新技術要素を検証するにもネットワークにプロキシがかかっており流行りのサービスや技術を試すためにいらぬ努力をしなければいけない。部門外の技術要素検証とかしようとすると、な、それってどこに必要なんですか?と聞かれる。結果、平のエンジニアは作業員として飼いならされていく。

飼い猫が家の外に飛び出す時

最初から飼い猫の場合、外の世界を知らないので、自分の周りの環境が自分の中の全てだと言う認識のまま生活する事が多い。

飼い猫が突然外に飛び出したくなる理由は、
挑戦して見たい事が出来た・リモートワークって楽そうだけど・起業って憧れる〜・などなど

でも、今のまま、ここにいては何も出来ない。環境を変えなければ!と思い立ち、外の世界に飛び出したりするわけだけど

リスクがあることはあまり意識していない場合があったりする。

リスクを知らないのと、野良猫の世界の厳しさを知らずに飛び出すものだから

野良猫流の立ち回りが出来ずに苦労することになる。

フリーランスは当然繋がりがなければ仕事を探すのにも苦労するだろうし

起業はそもそも会社の運営もしなければいけないので大変。

ベンチャーもリスクは付きまとう。

野良猫を拾った場合(スカウトして社員化)

逆に野良猫をいい子だから、という感じで飼い猫にしようとすると

家の中で退屈すぎてその猫にとっては死ぬほどつまらない人生になるかもしれない。

それが性に合う猫もいるかもしれない。

常に扉とか窓の前で外に出してよ〜と鳴き続けるしかない。

カーテン(プロキシ)がかかってたりしたら、外も見れなくて、
もう飼い主の言う事を聞いてる事がなくなる。

全てがこれに当てはまるわけでは無く・・・

当然飼い猫でも野良っぽくやらせてもらえるところもあるし

その逆もあったりするし

一概にこの2種類でまとめきれるものではないと言うのは理解しているつもり。

今は、そこそこの規模の家(企業)で、野良っぽくても良いよ、と言うところがちらほら出てきた。

これは、半飼い猫のように、たまに家に帰ってきて飼い主と遊び、またどこかへ出かけて外で遊び、と言うように

両者のいいとこ取りが出来る環境も少しではあるが出来つつあるように思う。

願わくば、そのような良い環境に自分も収まりたいと思うばかりである。

まとめ?

最近、両者の環境にほぼ同時に触れる機会があり

その事で、より自分がどちら向きかを肌で感じた。

新技術要素の検証とかは家でやれよ、とか言う意見がありそうだし、プロキシはセキュリティのために仕方ない、とか各言語ごとの特性があるゆえ、特性に合わせた環境を採用している、といった話とか十分承知の上で、それでも描いて見たくて書いてる次第。

野良猫寄りの人間から見た、エンジニアの世界の話。

 

 

gooseをdockerイメージにした話

gooseというgoで書かれたDBマイグレーションツールがあり、これだけを含んだDockerイメージを作った。
hub.docker.comにアップしてあるので
でという感じで実行出来る。

heroku にデプロイした環境をLet’s EncryptでSSL化して、自動更新までしたいの

Overview

herokuにデプロイしたサービスをSSL化するのに、Let’s Encryptを使いたいけど
なかなか面倒に感じてしまうところがあると思います。
そこで、herokuにデプロイするアプリにはLet’s Encryptのチャレンジレスポンス用のエンドポイントだけを作り
そのエンドポイントに環境変数でキーを渡すようにすれば、ある程度外部から自動化出来るのではないかと思い試してみました。
環境はRuby on Railsです。

今回使うツール

今回試してみた事

RailsのプロジェクトにLet’s Encryptのチャレンジレスポンス用のエンドポイントを作成

routes.rb に以下の行を追加します。
#config/routes.rb
controllerを作成します。
#app/controller/letsencrypt_controller.rb
これで、アプリ側の対応は終わりました。
マージしてデプロイしておきます。

certbotのインストール

certbotのインストールをします。
基本的には https://certbot.eff.org/ に従ってインストールすると入ります。

certbot-herokuのインストール

certbot-herokuは、heroku用に作られたcertbotのプラグインになります。
こちらも、基本的には https://github.com/gboudreau/certbot-heroku の内容に従ってインストールします。
インストールが終わったらプラグインが入ったかを確認します。

herokuコマンドのインストール

こちらも基本的に https://devcenter.heroku.com/articles/heroku-cli の内容に従ってインストールします。
入ったら、一応herokuコマンドで環境変数が操作出来ることを確認して置きます。

環境変数の一覧が表示されれば問題ないです。

ログインを催促されたりしたら、herokuのアカウントでログインしておいてください。

certbotコマンド実行


このコマンドで実行されること

  • ドメインの認証開始
  • ワンタイムトークン取得
  • herokuの環境変数[LETS_ENCRYPT_CHALLENGE]にワンタイムトークンを設定
  • ワンタイムトークン認証
  • 証明書の発行
  • heroku certsで証明書の設定

heroku上でドメインの設定

herokuのDomain Nameのリストに今回のドメインを追加してします。

確認


こんな感じに設定されていれば、OKです。

DNS設定

DNSにCNAMEで今回のドメインを設定します。
どのエンドポイントを設定するかというのは
以下のコマンドで確認します。

ここの、EndpointというところをDNSに設定します。

ここまで作業したところで、実際にSSL化した状態で参照出来るかを確認します。

SSLの自動更新について

Let’s Encryptは、有効期限が短く、3ヶ月で切れてしまうため、更新作業を自動化しておくことが重要となります。

とはいえ、ここまでの作業を全て自動化する必要はなく、更新だけされれば良いので、certbotをcronなどで叩ける環境が構築出来れば問題ないです。

ということで、cronで実行するコマンドですが

を実行すれば良いです。

自動的にheroku certs:updateをしてくれます。

まとめ

今回はheroku上では完結しないやり方となりましたが

heroku上のアプリのSSLを自動更新させる方法としては

ありなのではないかと思います。

自宅などに、更新用のVMをどこかに立ち上げて、cronを仕込んでおくだけで

あとはheroku上のSSLが更新されるとか

素直に、年間10000円くらいのSSL買ってしまう方が管理の手間は省けるのかもしれないですが、それでも更新の手間はあったりするので、個人の環境はしばらくはこのやり方で対応しようかと思っています。

これで解決!Docker for macのディスク容量を小さくしよう(ベータ)

先日、Docker for macでDocker.qcow2というファイルが肥大化する件というのを書かせていただきましたが、こちらの件、Docker for macの最新版ベータにて、ある程度自動で解消されるような処理がマージされたようです。

New Data Management commands #26108
https://github.com/docker/docker/pull/26108

Docker for mac のベータチャンネルにも降ってきましたので、試してみました。

今回ベータチャンネルで降ってきた内容は多いのですが、その中でReclaim disk size on rebootというのが今回の対応になってそうです。

DataManagement commands周りの主な対応内容としては、VM内のdfを表示するコマンド(docker system df)と、お掃除用のコマンド(docker system prune)が出来たといった感じでしょうか。

というコマンドで、今現在のVM内のディスク使用状況が以下のように表示出来ます。

RECLAIMABLEという列が、再利用可能な容量、といったところでしょうか。

早速、実際にpruneしてみます。

このような確認事項が表示されて

[y]を選択すると処理が始まります。

という感じにログが表示され、4.931 GB空いたようです。

prune後にDockerを再起動

メニューからrestartを選択すると再起動します。

起動したら、先ほどのdfを確認してみます。

docker system df

再利用化出来たようです。

実際のVMのサイズの変化は

prune実行前は

という巨大なVMになってしまっています。

prune実行後は

約2GBほど縮小されたようです。

これが正式版に入れば、VMのコンソールに入ったり

ディスクの変換をかけたりする必要がなくなり、dockerのコマンドで解消出来るので良さそうです。


追記

後日、何度かDocker for macを再起動してたら、さらにサイズが小さくなってました。

断片的に縮小していく感じなのかもしれません。

Reclaim disk size on rebootという位なので、もしかしたらDocker for macの再起動のたびに不要な領域が解放されていく、という事なのかもしれません。

そろそろ、自分のdocker-compose.yml周りを公開

docker便利ですね。

最近そんなことばかりしか言ってない気がします。

自分がdockerを使い始めた頃は、dockerってなんなのかわからない人が多く

話すと便利そうだけどプロダクションで使う想像がつかないとか

環境がめんど臭いとか

色々言われていました。

今現在は、開発環境として使うのであれば

docker for macというのがあって、これ入れるだけでかなり簡単にdockerが試せるようになりました。

環境を作るのが簡単になったのであれば、使えるdockerfileとかdocker-compose.ymlとかも

そろそろテンプレ的な何かがあった方が良いかな、と思い

今自分の手元でよく使っている構成でdocker-compose.ymlを公開してみます。

まずは、作りたい環境ですが

サーバサイドとしてRuby on Railsを使うことが多いので、Ruby on Railsを立ち上げる

という前提で行きます。

必要なコンテナとしては

  • Ruby on Railsが動くコンテナ

このコンテナの中には

/productsというディレクトリを作って、この中にRuby on Railsのプロジェクトを置くようにします。

  • mysqlが動くコンテナ

この二つが最低限なので、この構成を作って行きます。

まずは手元にRuby on Railsのプロジェクトを適当に作ります。

docker-compose-templateの中に入ってDockerfileを作成します。

主な構成ですが、プロジェクトのファイル以外に以下のようなファイルが追加になります。

それぞれのファイルについて中身とその解説をして行きます。

#Dockerfile

FROMのベースになるイメージは、officialのrubyにRuby on Railsで良く使うパッケージを追加したものを使用しています。

あと、特徴は

entrypoint.shという物を作成しており、ここで毎回コンテナ起動するたびに実行したい処理などを入れておきます。

#entrypoint.sh

bundle、db:migrate、pidファイル削除などを毎回起動時に行う

#Dockerfiles/mysql/conf.d/default.cnf

mysqlのコンテナで、新らし目のコンテナだとsocketの置き場所が変わったりしているので

後ほどdocker-compose.ymlでmysqlのバージョン指定はしますが、今回はdockerのofficialのmysql:5.5.54を前提に書きます。

#Dockerfiles/mysql/docker-entrypoint-initdb.d/init-user-db.sh

mysqlインスタンスの初回起動時に実行されるスクリプトになります。

これはofficialのmysqlで、コンテナ内の

/docker-entrypoint-initdb.d

というディレクトリに置かれたシェルはインスタンスの作成時に実行される

という仕組みがあるので、そこにファイルを置くように設定します。

(あとでdocker-compose.ymlでファイルを指定します)

最後、docker-compose.yml

#docker-compose.yml

ここまでで、docker-compose.ymlでRuby on Railsを起動するために必要なものは完成しました。

プロジェクトを起動するには

とやると、mysqlを起動して

init-user-db.shによってデータベースが作成され

その後にmainコンテナが起動して

entrypoint.shで初期化されて

プロジェクトが起動します。

init-user-db.sh

は、色々とカスタマイズすることで、すでにマイグレーションされたmysqlのダンプを置いて

それを初期データとして投入したり出来ます。

そうすると、

とするだけで、データベースの初期化が完了します。

また、entrypoint.shで細工しているので

の時はdocker-compose.ymlに指定したcommandが実行されてプロジェクトが起動します。

railsコマンドを叩きたい時は

とやると、コマンドが実行出来るようになっています。

なるべくシンプル構成でなるべく便利に使う想定で、今回このテンプレートっぽいファイルを作ってみました。

参考にしていただけたら幸いです。

一応githubリポジトリ

https://github.com/gendosu/docker-compose-template

 

Docker for macでDocker.qcow2というファイルが肥大化する件

Docker便利ですね。

Docker for macが出てからは、もうmac上には環境を作らない
なんて運用も可能じゃないかというくらいです。

実際、サーバサイド系の環境はほぼ全てDockerで運用してます。
gulpとかでブラウザのオートリロードとかしたい場合は
さすがに難しいので、そこはmac上に環境を作っておりますが。

ということで、ハードにDocker for macを使っていくと
ディスク容量が日々減っていくのが実感出来るかと思います。

これは、Docker for macも実体はVMであり
VMのディスクとして仮想ディスクがあり
この仮想ディスクが
~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux
に作成されています。

単純に考えると、docker imagesで表示されるイメージで容量を消費しているならば、docker rmiでイメージを消したら良いのでは?と思うのですが
そこはVM、仮想ディスクは一度領域を広げたら、通常運用では領域を解放してくれません。

ですので、この仮想ディスクを手で小さくしてあげないといけないです。

一番簡単な方法は

メニューバーに表示されているDocker for macのアイコンの中の
Preferancesからresetを開いてReset factory defaultsを選ぶこと。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-12-15-9-52-06

この仮想ディスクをクリアするコマンドでは、今までpullしたイメージや起動させたコンテナなども消してしまいます。

Dockerの運用ではあまりないかとは思いますが
コンテナにその場限りではあるけど変更を持ってて
コンテナとかを消したくない、といった場合はこの方法をとると
大切な変更が失われてしまいます。

そこで、仮想ディスクをshrinkする方法をとることで
現状を維持したまま
仮想ディスクを小さくする、といったことが可能になります。

方法ですが、
brewが入っている前提ですが

でqemuというツールをインストールします。
このqemuというのは、仮想マシンの一種になります。

仮想マシンで有名なところですと
VirtualBoxとかVMwareあたりになると思いますが、これらと
似たソフトウェアになります。

で、Docker for macで使用している仮想ディスクのフォーマットは
このqemuのディスクイメージフォーマットを採用しております。
なので
仮想ディスクのファイル名が
Docker.qcow2
となっています。

さて、qemuのインストールが完了したら
このツールの中の
仮想ディスクを操作するコマンドがあるので
そのコマンドを使って
Docker.qcow2
を変換かけます。

変換をかける前に、考慮する部分があり
通常ディスク上でファイルを削除した場合にはインデックス上で削除したという情報を管理して、実体は消えていない状態ですが
通常の場合だとそこに上書きすることになるので、容量があるという見え方になりますが、仮想ディスクはそのインデックス上では削除されているけれど、実体がある場合も、ディスク容量として消費していることになります。
この削除されているけれど実体がある部分を綺麗にしてから
変換をすることで、効率よくファイルを小さくする事が出来ます。

ということで、実際に変換するためのコマンドは
以下のようにします。

これを実行する際に、いらないコンテナ、イメージは全て削除しておくことをお勧めします。

で一覧表示されるコンテナの中からいらないものを全て削除します。
次に

で表示されるイメージで不要そうなものを全て削除します。

続いて、Docker for macの本体になるVMにログイン

仮想ディスク内で削除されているファイル群を削除します。

この方法の欠点は、ディスクフル(Docker.qcow2のディスクサイズ上限 or macのディスク上限)になるまでゼロ埋めファイルを作ってからそのファイルを消すということをやるので、macの容量が少ない場合は結構難しいです。
自分の場合は、ddでサイズ指定(例えば、Docker.qcow2の現在のファイルサイズの半分くらい)をして、消してます。

screenから抜けて

Docker for macを停止します。
Docker for macの停止の仕方は自分がまだ分かってないので、アレなのですが、
Docker for macのPreferenceから、Start Docker when you log inをoffにしてquitしてmacを再起動してます。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-12-15-9-59-53

それから仮想ディスクファイルをshrinkします。

実行時間は、そこそこ長いです。

実行が終わると、
Docker.qcow2.new
というファイルが出来上がっていると思います。

半分位になりましたね。

出来上がったら、一応ですが古い方はリネームしておいて
新しいものに差し替えます。

差し替えた状態で、Docker for macを起動します。
無事に起動して、dockerコマンドが通るようになれば、問題なくshrinkが完了しました。
古い方のDocker.qcow2を削除しましょう。

これで、溜まりに溜まったDocker.qcow2のディスクが綺麗になりました。

我が家最後の砦、VAIO Z の Windows10 アップグレード

VAIO Zの5年くらい前?機種は

DYNAMIC HYBRID GRAPHICS SYSTEM

という仕組みで、バッテリーを長持ちにさせる代わりにグラフィックをIntelのチップセットのもを使うようにしたり、ハイパフォーマンスにしてNVIDIAを使うようにしたり、という設定がスイッチで付います。

DSC_0222_switch

※Windows 10にアップした後に撮ったので、LEDが点灯してないですが、本当はスイッチの向いてる方向のLEDが点灯します。

これのおかげでモバイル用途もOKでゲームも楽しめるという贅沢な機種でした。

ですが、やはりメーカーのサポートというのは長くはなく、

Windows 10対応のドライバ類は提供されず。

という状態で、Windows 10 アップグレードのダイアログは出るものの

ディスプレイドライバが対応していません。(正式には忘れてしまいましたが)というワーニングが出るので

自動アップデートはかけられない状態でした。

で、いろいろと調べていると

NVIDIAのドライバをちょっと細工してインストールする事で

Windows 10にしてもNVIDIAを使う事が出来そう、ということで

意を決してアップグレードしてみました。

DSC_0218

やったことは

VAIO Z VPCZ1 のグラフィクス機能を Optimus Technology を用いて動かす。

このページを参考にさせていただきました。

ただ、現在のNVIDIAの最新のドライバだと若干違う部分がありました。

簡単にですが、アップグレード手順は

Windows 10のISOイメージを取得する

DVDにイメージを焼く

エクスプローラからDVDに焼いたところのアップグレードファイルを起動する

Windows 10アップグレードが始まる

適当に進めてアップグレード完了

ここからWindows 10で起動する訳ですが

普通にIntelのグラフィックドライバで画面が表示されるので

見た目的には問題なさそうな感じがします。

NVIDIA使いたいので、インストーラをダウンロードして

参考にさせていただいたページのようにドライバの情報を書き換え、

さらに起動オプションでドライバ署名無効にして

インストール。

半信半疑のままやってみたわけですが、一応使えるようにはなったみたい。

ただ、ドラクエベンチ流したらカクカクで何でかな〜と悩んだ結果ですが

NVIDIAのコントロールパネルで、使うドライバがIntel になっていて

そこをNVIDIAのに変えたらうまくいきました。

P.S.

少し雑ですが

明日でWindows10 アップグレードネタの賞味期限が切れる気がしたので

急いでインストールして、急いで記事アップしましたw

ssh2のキーが見たことないフォーマットだった時の対処の仕方

ある日、委託の方にサーバへのアクセス権を付与するためにSSHのキーをくださいと言ったら
以下のようなフォーマットで送られてきた。

SECSH形式?という解らない形式のものらしい。

と思ってよくよく調べたら

本来のSSHキーはこのような形式のようだ。

(本当か??)

今までOpenSSHに慣れすぎて来たという事なのかな。

というのは良いとして

これを普通のSSHのauthorized_keyに格納するには

としてやれば良い。

git cloneするときにブランチ指定して–depth指定する

よくチュートリアルのなどで

なんて感じでcloneして使うやり方を書いてあったりするけども

普通にgit cloneすると
他のブランチの情報とかも管理ディレクトリに持ってきている状態なので
ディスク容量も食うし、cloneする時間もかかる。

そこで、特にgit的な操作は以後しないのであればgit shallow cloneするのが良い。
やり方は

こうすると、ブランチの最新のリビジョンだけを持ってきてくれる。

今年の夏は暑い!そして、スマホも熱くなる!そんなときはこのタオルでサッと熱をとるといいかも

今年は暑くてたまらないですね。

そして、スマホライフも熱との戦いとなりそうです。

ゲームをするとさらに熱くなること間違いなしですね。

機種によっては熱によってすぐに機能停止になったりするのもあるようです。

また、ゲームなど割と長時間プレイする場合はバッテリーがもたずに充電しながらのプレイになるときも多々あるかと思います。

自分もそうです。

そして、充電しながらだと、非常に熱くなって持っているのもしんどくなるので、

スマホの両端をつまむようにして持ちながらプレイしてたりします。

そんなスタイルがちょっと辛かったので

なんとかして熱を取る事が出来ないか?と考えておりました。

扇風機に当てるのも良いけど

もう少しなんかさっと取れたりするといいなぁと。

で、ある日

冷感敷きパッドというベッドに敷くタイプの安眠グッズがあり

そこでスマホをスリスリしてみました。

そうしたら、驚くほどスマホの熱が冷感敷きパッドに吸収されて、スマホの体感温度がすごく下がりました。

それ以来、充電しながらスマホでゲームする場合は、冷感敷きパッドの上でスリスリしながらプレイしてます。

でも、外に出たときにも少しスリスリしたいなぁ。。。

ということで、今度はタオル状の冷感グッズを探してみました。

こんなのを見つけました。

これは、見たところ冷感敷きパッドと同じタイプの素材で作られているようなので

早速ぽちって見ました。

DSC_0212

※弱めのLEDスポットライトの部屋なので、色が変です。

このタオルは、表が普通のタオル生地になっていて、裏側が冷感素材になっていました。

なので、こいつの裏側で、熱くなったスマホをスリスリ。スリスリ、スリスリスリスリスリスリスリ。

た、確かに熱は取れてる。

スマホ持っても熱くない!

でも、一つだけ欠点を見つけてしまった。

タオルでスリスリしながらゲームプレイしてると、ゲームに実が入らない。。

まぁゲーム中以外でも発熱してきた場合に、このタオルでサッと熱を吸熱してスマホを冷ます事が出来るので

発熱でバッテリーが心配、なんて感じるときは使ってみるといいかも?と思いました。

あと、さすがに冷感敷きパッドのように広大な面積がある訳では無いので

瞬時に吸熱出来る熱量も冷感敷きパッドには負けます。

それでも試してみたい!という方は試してみてもいいかも?

以上

関連リンク

herokuでMemory Quota Exceededと言うのが出るようになったので、puma_worker_killerを入れた話

最近、herokuで稼働させているRailsのアプリが「Memory Quota Exceeded」と言われる事が多くなり、定期的にワーカーの再起動をしたいと思ってました。

memory_quota_exceeded

見る限り、swapも出てしまい、レスポンスも遅くなっているようです。

このような場合、heroku以外だと、unicornを使うので、unicorn_worker_killerを入れるのですが

herokuだとpuma推薦なのでpuma使っていました。

で、pumaもuniconのようにworker killer系の物があるのかな?と探してたところ

puma_worker_killerがあるようなので、使ってみました。

https://github.com/schneems/puma_worker_killer

herokuでの使い方は、「Turn on Rolling Restarts」というのを使うのが推薦のようなので

その設定で行ってみました。

デフォルトだと6時間ごとに再起動ということになるので、ひとまず様子見で3時間に設定してみます。

以下が、3時間でリスタートがかかるようにした設定になります。

こちらを設定したところ

memory_quota_exceeded_after_config

ピーク時は少しswapが出る時もあるものの、割と落ち着いたのかなと思います。

しばらくはこの状態で様子見をし、アラートがまた増えるような感じであれば再度調整という事にしようと思います。

ベンチャー・中小企業における開発チームの維持

ベンチャー・中小企業における開発チームの維持と言うことで、またいくつかキーワードを挙げてみます。

経営の視点から考えたとき、開発チームとして維持したい事は

収益性のある機能について継続的に改修、機能追加が出来る事。

将来に備えてスケール出来る仕組みを常に考えられるようにする。

経営判断での急な対応も出来る。

といったあたりがとくに重要となる。

開発チーム視点から考えたときは、上記に加え

メンバーのモチベーション維持。

技術的負債の解消。

新技術・新バージョンへの探求心。

技術共有。

あたりが重要となりそうです。

今回は開発チーム視点中心に少し考えてみます。

モチベーション維持、これはメンバーそれぞれに異なるやる気スイッチが有るように思います。

テストが得意、機能をとにかく早く仕上げられる、複雑なロジックがくめる、インフラが得意etc

開発リーダーとしては、

理想的なのは、その得意領域にそれぞれ割り当てするのがチームとしては最も効率が良くなります。

サービスが軌道に乗るまでは、俗人化するのはある程度許容する事で、コミュニケーションコストが下げられ、本人はやりたい領域の事が出来、効率は上がります。

前回も書きましたが、逆にモチベーションが下がる要因というのを排除していく事も重要となります。大きく影響するのはやはり人間関係で、信頼される事で大きく貢献出来るようにもなるし、本来以上の力を発揮出来ることもありますが、信頼されない状況があると、周囲にも影響があるので、ここは出来るだけ改善するようにしたいところです。

技術的負債。

これはおそらくどこの会社でもある問題ではあると思います。少しずつ改善していくのか、ある時期に一気にリプレースするのか。これはどちらかが良いというのは、おそらくなくて、プロジェクトの状況や会社の収益なども影響してくると思います。

そこがクリアになったとしてもチームとして技術的負債を改善していく空気が無ければ進まないので、日頃から少しでも改善していくための時間を作ったりTDDの意識をメンバーに持たせるようにするなりをしていく必要があります。そのための時間が必要と言うことをチーム外にも理解してもらう努力も必要です。

新技術・新バージョンへの探求心

新技術への挑戦や、新しいバージョンへのアップグレードが推奨される環境は、新しいことがやれている、という気持ちが持て、そこから社外にも知見共有などによってモチベーション維持とともに開発チームの技術力の底上げに貢献する事になります。

技術共有

知見の共有は、メンバーへの刺激になるとともに、自身の習得レベルの向上にも繋がるので推進したい所です。

公式エンジニアブログなどは、上記に加え、会社としての技術のアピールも出来、意識の高いエンジニアが応募してくる可能性は上がるかもしれないため、将来の投資にもなりそうです。さらに、技術領域が公開されるため、スキルのミスマッチもある程度防げそうな気がします。

 

 

Docker for Mac bata(1.12)とpowが共存出来ない

Docker for Mac bataがリリースされ、早速インストールしてみました。

docker-app-icon

アプリケーションディレクトリに入れて、このアイコンをダブルクリックするだけで

Dockerの環境が自動的に構築されるようです。

docker-menu-iconメニューバーにはDockerのアイコンが表示されるようになります。

1.11以前にDocker ToolboxでDockerを使っていた場合、この初回の起動時に

既存環境を新しい環境で使えるように変換が行われます。(yesにした場合)

今回は、全く新しい環境にインストールをしているので

変換も何もなく、すぐにインストールが終わりました。

変換した場合には、既存環境に応じて、それなりのディスク消費があるので

ディスクの空きが少ない場合は要注意です。

さて、Dockerの環境としては、まだこれから試してみる事はたくさんありそうですが

ここで出てきた問題が、タイトルの通り

powと相性が悪そう、という点です。

powは、Rackサーバで、ローカルでバーチャルホストを提供します。

なので、test-appというプロジェクトであれば、http://test-app.devでアクセスができるようになりますが
test-app.devは127.0.0.1になるので、localhostです。

一方、Docker for Macもポートを80番で指定してコンテナを起動したりすると

http://localhost/でアクセスができるようになります。

Docker for Macは、今までのDocker toolboxとは違い

Mac上でネイティブにハイパーバイザーを使って環境を構築しているようです。

ですので、標準の設定のままだと、これらが衝突し、Dockerのコンテナにアクセスできない、といった状況が発生します。

自分でもこのあたりが今出来る設定で回避可能なのかどうかは、調査中ではありますが

覚書として書いてみました。

 

関連情報

http://pow.cx/

https://www.docker.com/

https://github.com/docker/hyperkit

http://bhyve.org/

Evernoteが値上げ!今ここでOneNoteと比較してみる

Evernoteが値上げ&無料のベーシック版にさらに制限がつくようだ。

4DB6FE35-C1FA-440B-89C0-8A5AEC88076A

Evernote ベーシックを無料で入手するか、プラス版またはプレミアム版にアップグレードできます。 Evernote

ここで、今一度、自分なりにEvernoteとOneNoteの無料版の比較をしてみたいと思う。

1ノートごとの保存容量

Evernote OneNote
1ノートごとの保存容量 1記事25MB 無制限
全体の保存容量 なし? OneDriveにファイル作成のため、OneDriveに依存
アップロード容量制限 60 MBの月間アップロード容量 無制限
ウェブクリップ機能 各ブラウザにプラグインを追加して使用
ページ全体・選択範囲・ブックマーク
※オリジナルに近いスタイルのままノートに保存可能
Chrome拡張にて確認
クリップの意味合いが違うようで、
ページ全体のスクリーンショット
選択範囲のスクリーンショット
となるようだ
ノート内の画像編集 以前あったSkitchというアプリの機能がEvernoteのアプリに取り込まれているので、
Evernoteアプリ内で簡単なドローツールやコメント追記などが出来る。
画像などの編集はOneNoteアプリ上では出来ないようだ
編集端末 2台 制限なし

ここまで見て、個人的にはもうEvernoteしか無い訳ですが

有料版になってくると少し違った考え方になる必要がありそうだ。

Evernoteの有料版は、2種類あるが、プレミアムを想定して考える。

特に有用な機能を上げてみると

PDF内の文字を検索

Office文書の文字を検索

ノートの履歴閲覧

など。

過去にミスってノートの中身を消してしまったことがあったが、履歴から戻せて事なきをえた経験から

この履歴閲覧は必須と思っている。

OneNoteの方はどうか

こちらは、OneDrive自体の有料プランというより、MicrosoftのOneDriveのプランと言った方が良いが

今現在(2016年6月)OneDrive プラン

無料 5GB 無料
基本 50GB 170円/月
OneDrive + Office 1TB 1274円/月

いずれにしても月間の通信量制限はない。

Office 365 soloを契約することで、OneDriveが1TB付いてくると言う脅威のパフォーマンスが発揮される。

1274円/月でOfficeとOneDriveが1TB付いてくるのであれば、これはお得だと思う。

Evernoteの優秀なウェブクリップ、簡易画像編集、を取るか

OneNoteとOfficeとOneDrive 1TBを取るか

両者どちらか一方だけを選ぶことが出来ず、自分の場合は両方選んでしまった。

ウェブクリップ、通常のメモ用途としてのEvernote

Officeや1TBのオンラインドライブとしてのOneDrive

比較対象にあげたOneNoteは結局使っていない。

以上。

 

Bash on Ubuntu on Windows のアンインストールについて

https://github.com/Microsoft/BashOnWindows/issues/29

lxrunというコマンドがコマンドプロンプトでたたけるようになっているようで、これでオプションにuninstallを付ければ

Bash on Ubuntu on Windows のサブシステム一式が削除出来るようだ。

試しに消してみた。

キャプチャ6

 

Windows 10 Insider PreviewをONにしてみた

最近、MacとWindowsの両方で似たような環境を作って作業することが多くなった訳ですが、どうもMacと比べると色々とWindowsの場合は開発環境といった面では劣る部分が多いというのを改めて感じました。

ただこれ、Windows10は開発用途以外の場合、結構使いやすいOSだと思っています。

自分の場合はノートPCでタッチ画面付きのものなので、マウスが無くても、サッと画面をタッチできたりして便利です。

ブラウジング用途でも手でスクロール出来る&拡大縮小が出来るというのは使ってみるとかなり便利な部分です。

ブラウジングの操作がスマホでなれているというのもあるかもしれません。

そこでMacを触ると、ついつい画面に手が行ってしまいがちです。

あ、タッチ出来ないのか。。と思いつつタッチパッドをスルスルする訳です。

少し話がそれました

Windows 10を開発環境として見た場合に、圧倒的に足りないのがコマンド操作周りだと感じました。

昔はCygwinやらCoLinuxからVirtualPCやVMwareなど、仮想環境は結構手を出してきていましたが

シームレスな環境というのはなかなか見つかりませんでした。

最近はDockerを入れてコンテナ起動ですが、結局は裏でVirtualboxが起動しています。

そんななか、Windows 10 Insider Previewで、Bash on Ubuntu on Windowsなる環境が試せるという話を聞き、これは入れるしかない。

と思いつつも要はベータなので、最悪環境が吹っ飛ぶかも?というところで躊躇してましたが

ふっきれました。

キャプチャ

ONにしちゃいましたよ。

というのも、最近Windowsがブルースクリーンになることが多く、どっちにしろリセットするなら、という気持ちが強くなってきました。

あとは純粋に試したい!という事で。

ついさっきONにしたわけですが、しばらく待たないと入らないようなので、続きはまたしばらく待ったあとにアップしたいと思います。

追記

やっとWindows Updateとして降ってきました。

キャプチャ

入れたらまた別途追記します。

追記2

早速bashをONにしてみます。

キャプチャk

Windowsの機能の有効化または無効化というのをクリックして

キャプチャ2

Windows Subsystem for Linux (Bata)

というところにチェックを付けてOKを押します。

ここで、一度再起動します。

コマンドプロンプトでbashと入力してリターンです。

キャプチャ3

そうすると、インストールするかどうかを聞かれるので、yと入力します。

キャプチャ4

アカウントとパスワードを最初に入力すると、文字は化けますが正常にインストールされたようです。

これで、スタートメニューには

キャプチャ5

このようにBash on Ubuntu on Windowsという項目が出来ています。

これを起動するとbashが使えるようです。

 

Dockerfileを作っている最中にデバッグするときの基本的な手順

Dockerfileを作っている最中に動作確認中に途中で落ちてしまって、その状態でイメージの中身を確認したい時とかが多々あるかと思いますが
今回はそんなやり方、定番かもしれないですが書いてみようと思います。

まずは適当なDockerfileを作ってビルドします。

このビルド時にエラーが出てイメージの作成が止まったという想定です。

docker buildで失敗すると・・・

docker imagesには

というイメージが出来ています。
こいつは

Dockerfile上のタスク(RUNとかADDとかの単位)で正常に処理が完了した状態が一時的にイメージ化されているものです。
で、docker buildで失敗した状態というのは
docker ps -aで表示される停止しているコンテナが持っています。
なので、このコンテナに入ることが出来れば、失敗の原因を調べる事ができそうですね。

コンテナ状態だと、
例えば

こんな感じの表示にある通り、実行コマンドとして/bin/sh -c 〜〜〜〜というのが書いてあり

普通にdocker startしてしまうと、このコマンドが動いて終わるので

このコンテナを一時的にイメージにしちゃいます。

さらに、イメージ化したものをdocker runします。

これで、docker buildで失敗した時点のコンテナに入る事が出来ました。

consulとstretcherによるデプロイの検証

概要


consulのevent発行=>event watchの機能をフルに使ったデプロイになります。
event watchで起動されるデプロイツールがstretcherになります。

前提条件


オートスケーリングをする
ソースgzとかしてS3においておく
各サーバがS3からソースをダウンロードして展開する(stretcher)
オートスケーリングの仕組みは別途あるものとする

検証


consulの基本的な設定
webの場合
#/etc/consul.d/web.conf

/etc/consul.d/event.conf

インスタンスの作成時

サーバの起動スクリプトに以下を仕込んでおく
/usr/local/bin/stretcher s3://example/manifest.yml
アプリのリリース時
s3にリリースするソースファイルをアップしておく
s3のmanifest.ymlを更新しておく
consul event発行

クラスタリスタートさせる場合

/etc/consul.d/web.confに定義出来る

  • name
  • service
  • tags

の設定で頑張る事でなんとかなりそう。
具体例
/etc/consul.d/web.conf(クラスタ1のグループのサーバ)

/etc/consul.d/web.conf(クラスタ2のグループのサーバ)

クラスタ1のリスタートイベント発行

クラスタ2のリスタートイベント発行

1台だけ新しいソースにして動作確認する

これはサーバイメージの更新の時もありうるので
オートスケールの最低台数を+1する想定だけど
新しいmanifest-prerelease.ymlとかを作成して
/usr/local/bin/stretcher s3://example/manifest-prerelease.yml
として手で叩くでも良い。
それか、例えば、nginx.jsonに以下のような設定を入れ
サーバ1

サーバ2

サーバ3

サーバ4

consul reloadしてから

とすると、サーバ1だけにイベントが飛びます。

とすると、サーバ1とサーバ2にイベントが飛びます。

とすると、サーバ3だけにイベントが飛びます。
/etc/consul.d/nginx.jsonを、直接いじりたい場合(例えば、一台だけprerelease機にしたい場合)に
直接入ってファイルをいじって、consul reloadすれば、設定が更新されます。
その後に

とすれば、1台だけリリース可能。

全台デプロイ完了の検知

全台デプロイを検知する仕組みとして
consulの持つKey/Valueの仕組みを利用すると実現可能。
手順
deployイベント発行時にデプロイスクリプトであらかじめ

をしておく。

渡すmanifestファイルを以下のように

としておく。

としておく。
デプロイ時のスクリプトなどで
consul event〜〜
発行後

を監視。
keysがなくなれば全台デプロイ作業完了
最後に

を取得し
エラーがないことをチェックしてデプロイフローの完了となる。

感想

という事で、イベントを送る先をtagsで良い感じに制御出来ればconsulとstretcherによるデプロイは良さそうな気がします。
全台デプロイ完了の検知は、consulのイベントとかステータスとかだけでやりたかった。けど、なかなか上手くいかない。
引き続き良い方法があれば調べたい。
manifest.ymlはデプロイスクリプト(capistrano?)で自動で更新されるようにしたいため、ここにhook処理が羅列されるのは嬉しくない。
ソースを固めてs3に上げてmanifest.ymlを作るという部分はまだ考慮しきれていない。
各サーバでserviceにcheckという設定(このページではconsulの基本的な設定のweb.json)を付けると、指定したチェックが通るまではserviceとしては追加されないので
ロードバランサにぶら下げるときにも
consulのヘルスチェックを見てゴニョゴニョ出来たらいいのかと思ったりしました。

補足

イベント発行のAPI