備忘録などいろいろ

イロイロ! 比較的Twitterの延長のノリで書くと思います。

AWS ElasticBeanstalk で Docker 動かすときの備忘録

単一コンテナ環境で何回かやってるんですが、dockerコンテナのデプロイ方法には2種類あります。この方法の選択についていつも忘れてしまうので備忘。

方法1: Amazon ECR などに事前に `docker build` したイメージを push しておいて、ElasticBeanstalk に Dockerrun.aws.json だけを食わせて ECR からpullしてきて起動
方法2: railsのファイルやらDockerfileやらを全部 zip にしてeb deployか何かでアップロードする

普通に考えれば、方法1は可搬性のあるdockerということだし手元で `docker build` してしまったほうがエラー対処の手戻りが少なかったり、EB上でbuildしなくていいのでEBのUpdating state時間が少なくなって楽なのだが、ある問題が生じる。

問題:
.ebextensions でdocker hostに関する設定のinjectionができない。
したがって(単一コンテナ環境では)awslogs (CloudWatch Logs) へのアプリケーションログのストリーミングを行う手段がない。
※方法1ではEBはDockerrun.aws.json というマニフェストに従って docker image のみをpullするので.ebextensionsが介入するタイミングが無いとかそういうやつ。

ということで、deployプロセスが冗長になりがちだが仕方なく方法2を使うのである。デプロイの時間はもちろん長くなるが、苦渋の選択です。

ハンコン G29 のペダルメンテナンス

ハンコン(Logitech G29)のブレーキペダルの調子が悪くなったのでメンテナンスしたら直った。

あんまりいないと思うが、万が一同じ症状で悩んでる方がいた場合のご参考として記しておきます。

症状:

ブレーキリリース直後、ブレーキに触っていないのにもかかわらず、入力値がピコピコ変動する(英: spike)

このため、レースシムなどで遊んでるとコーナーの立ち上がりがめちゃくちゃ遅かったり、不意に荷重変動してスピンしたりする

なお、ソフトウェア側でブレーキペダルの遊びを調整しても改善しない(入力値のノイズにけっこうな値のバラつきがあるため)

 

原因:

ブレーキペダルのセンサー部(可変抵抗器/ボリューム)の変位0付近における接触不良

 

対策:

1. 可変抵抗器をバラして接触面及びブラシ電極を掃除した(無水アルコールで拭いたが、もっと良いのがあるかも)

2. ブレーキペダル内の歯車の山をひとつ分ズラして、可変抵抗の変位0付近を使わないようにした。
2'. もしかするとソフトウェア側でブレーキペダルの遊び調整が必要かもしれない(自分の場合は不要でした)

参考:

www.gtplanet.net

この情報、日本語でググってもなかなか出てこなかったので情報格差を感じる。

読んでわからなかったらコメで聞いてください。

博多ラーメンについての地元民の一言への反論

「『博多長浜ラーメン田中商店』に長蛇を成して寒い中並ぶ意味がわからない。博多ラーメン食べたければ一風堂行っとけば十分。」と仰った(自称?)地元民がいたが、私はその言葉には断固として賛同しかねる。そもそも博多ラーメンと博多長浜ラーメンを混同している時点でナンセンスだ。歴史も方向性もぜんぜん違う。一風堂のような化学調味料風味の味が単独で十分うまいラーメンだと思っているならそれは狭い世界に住んでいる方なのかと思わざるをえない。

別に一風堂をこき下ろすわけではないんだが、あの言葉に対する強い反発と、同時に強い悲しさを感じたので勢い余って書いてみた。

【PUBG】思いつき次第書くその1【初心者向け戦術】

最近PCを新調したのをキッカケに、PUBG (PLAYERUNKNOWN'S BATTLEGROUNDS)遊ぶようになったのですが、ここ数日初心者とSQUAD組むことがあったので初心者向けの戦術的注意点をこのカテゴリで思いつき次第書いていこうと思います。

 

なにぶん初心者向けなので高度な戦術については書きませんがご容赦ください。

 

分隊で行動するときは付かず離れずの距離感を保つ。目安15〜40m程度(?)

移動中に敵に目視されたとき、分隊員が近過ぎると一度に全員の位置が把握されてしまう。ある程度距離を取った状態で移動することで、1人が発見されて射撃を受けても、他の分隊員が迎撃や制圧射撃などの反応を取ることで最初に発見された分隊員を生かす確率を上げられる。

ただし、距離を取り過ぎると反応までに時間がかかり過ぎて被発見者が一気に気絶→死亡させられたり、気絶状態から蘇生に向かうことができなかったりする。あくまで程よい距離感を保つべき。

 

★適切に制圧射撃を行う

初心者のプレイでありがちなのが、隠密を気にし過ぎて撃たないこと。反撃を恐れるあまり分隊どうしの交戦状態になっても、敵の姿を目視し確実に当てられる状況になるまで撃たない、かと言って積極的に有利ポジションに移動する気配もない「待ち」の時間が長いように見受けられる。ソロプレイのときはそれでも一向に構わないのだが、DUO/SQUADでそれをやられると堪らない。

有利ポジションでもない場所での「待ち」をしているプレイヤーは死んでいるも同然で、そうなれば4対4の戦いだったはずが仕事しない味方により数的不利を背負った味方分隊の残りは忽ち殲滅されてしまうであろう。味方が3名気絶した状態から撃ち勝って3名蘇生するのは、隠密を破って被弾しつつ撃ち勝つよりも遥かに難易度が高いことが多い。

味方が敵と全面交戦しているが自分は敵を目視できない状況の教科書的な立ち回りとしては、味方に敵の方位/距離を教えてもらい、その辺に弾をばら撒くことである。立場を逆転して考えてみれば、射手の正確な位置は分からないが自分の近くに撃ち込まれている状況は、そうでない状況に比べてかなり行動の自由が制限されるはず。この制圧射撃を利用して敵に有利ポジションを取らせないようにすれば、キルこそ取れないものの味方のサポートという意味で武器になる。

もしくは、自分の位置が敵に把握されていない、かつ味方戦線はある程度時間稼ぎ出来そうな状況であれば、回り込んで側面から敵を討つことも検討できる。

撃たない、しかも移動しない、という隠密行動を選択できるのは、味方全員の位置が誰にも把握されておらず誰も撃たれる事がない状況のみに限られる。

Hue買った

PhilipsのHueホワイトグラデーション スターターキットを買いました。
スンバラシイです。
フルカラーはたぶん必要ないし高いので、ホワイトグラデーション。

帰宅したときは、自動で点きます。温白色でメインライトを明るめ、ベッド脇のスタンドライトを少し控えめに。

夜寝る時間になったら、自動でメインライトはオフ。スタンドライトは電球色で、明るさはフェードアウトしていきます。

朝起きる時間になったら自動で調光。フェードオンで0%→100%へ。色は昼光色でさっぱりと目を覚ます。

外出したら、自動でライト全消し。

コントロールできるのは、ザックリ昼白色から電球色の色味と、明るさ。
HomeKit連携もできるし、独自アプリでの操作も可能。
電気をスマホでいじれるからって何が良いのか分かってなかったが、使ってみて初めて判った。色と明るさをシーンに合わせて自動で調整してくれると、生活にメリハリがつく。意志力が足りないときの起床を助けてくれる。目指せ、課金で生活習慣改善。

iOS 11 SafariのCORSに関する仕様変更点

iOSのアップデートをしました。iOS 11です。
純正ブラウザであるSafariにも公表されていない仕様変更がいくつかある模様です。
今回はそのうちの一部であるCORS処理について。
※ 雑な検証の上で判った(つもりになっている)仕様変更点です。

【変更点】
CORS (Cross Origin Resource Sharing)関連のレスポンスヘッダである
`Access-Control-Allow-Origin`ヘッダーにワイルドカードが使えない(または、使えない場合がある)。

これまでも、`xhr.withCredentials = true` ならば`Access-Control-Allow-Origin: http:///hoge.example.net` のようにワイルドカードでない値を返す必要があったが、`xhr.withCredentials = false` でもそのようにすべき、という事になりました。
バグかもしれませんが、新仕様かもしれません。

【追記】上記はもしかすると大嘘かもしれません。追加検証中ですが、safariのブラウザキャッシュがOriginヘッダの有無を考慮していないのが原因で現在私がトラブっているだけかもしれません。

【追記】大嘘でした。開発中のWebアプリケーション内で、Cross OriginなResourceに対するリクエストが「1. browser-nativeなloader経由」と「2. XHR経由」で重複して発生しているのが原因でハマってました。
1が先に起こる=Originヘッダなしリクエストに対してCORS関連ヘッダのないレスポンスが帰ってきてブラウザにキャッシュされる。
続いて、2のリクエストが起こる=CORSヘッダの無いブラウザキャッシュが返るが、その後段のcross originチェックで弾かれてxhrがfailする。
という流れです。前々から気になっていたことですが、やはりSafariはブラウザキャッシュの管理が雑すぎて時々ハマります。

【追記終わり】


by-nameでAccess-Control-Allow-Originヘッダを作る方法。
S3の場合、CORS設定のルールの中で

<AllowedOrigin>*</AllowedOrigin>


となっている部分を

<AllowedOrigin>http://*</AllowedOrigin>
<AllowedOrigin>https://*</AllowedOrigin>


と変更すれば良いみたいです。
Thanks to 

stackoverflow.com


自前appサーバの場合は自分でCORSヘッダーをうまく作ってください。


Google翻訳ってラテン語も翻訳できるらしい

Loremのイプサム
「それは痛みのニンジンであるため、また、それはそれ以上である、ミネアポリス、...取得したいです」
「それの後に追求し、それを持って望んでいる痛み自体を愛する誰もが、それは苦痛であるという理由だけで、ありません...」