我が家最後の砦、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/