読者です 読者をやめる 読者になる 読者になる

production.log

ピクスタ株式会社でエンジニアのリーダーをやっている星直史のブログです。

Fitbit Charge HR™を購入して一年経過したので使用感をまとめてみる

その他

概要

Fitbit Charge HR™を購入して一年経過したので使用感などをまとめてみようと思います。

Fitbit Charge HR™とは

ワイヤレス心拍計 + 活動量計リストバンド ChargeHRで生活のリズムを感じよう。手首に巻くだけで継続的・自動的に心拍数とアクティビティをトラッキング。心拍数は1日中記録。トレーニング中のより正確な消費カロリーを知り、目標トレーニング強度の達成をサポート。トレーニング時間を最大限に活用できる。歩数・距離・消費カロリー・アクティブな時間・階段を使って上った階数を記録。OLEDディスプレイで目標への進捗状況や同期中のスマートフォンへの着信をリアルタイムで確認。一日の終わりには睡眠中の動きを自動で計測。朝にはサイレントアラーム(バイブレーション)でやさしく起こしてくれる。ワイヤレスでスマートフォンやパソコンと同期して、目標達成へのモチベーションをアップ。健康な体は心から。

ごっそり引用してきましたが、Fitbitをつけると下記のことがトラッキングされます。

  • 時間
  • ストップウォッチ
  • 脈拍
  • 消費カロリー
  • 歩数
  • 歩行距離
  • 登った階段の段数
  • 睡眠傾向

またダッシュボードでは下記の項目などを可視化してくれます。

  • 摂取カロリー
  • 睡眠の傾向
  • 運動量推移
  • 摂取水分量

ここは良かった事

1年使用して良かったところを紹介していきます。

電池の持ちが良い

購入時に色々なウェアラブルバイスと悩んだのですが、電池の持ちが良いのはかなり大きいと思います。 公式ではフル充電から5日間使用可能とありますが、だいたいあっています。 これは1年経過した後もバッテリーの劣化などは感じられず、気になったら充電というレベルです。

また、5日間はお風呂以外の時間は寝ている時間も含めて装着できるので、めんどくさがりには最適だと感じました。

ストップウォッチが結構便利

Fitbitについているボタンを長押しするとストップウォッチになるのですが、この機能を使うシーンが結構ありました。 スポーツをしている時はもちろんですが、 たとえば、ミーティング時に「3分考える時間をとります」というシーンでも使えるので、結構便利でした。

1万歩歩くと謎の達成感がある

1万歩歩くと、バイブレーション機能が作動し、ブルブル震えて"Congratulations"と表示されます。 ただそれだけの機能ですが、結構嬉しかったりしますw
ちなみに、1年間で1日の最高歩数は3万歩でした。

ここは使ってるうちにやらなくなった事

購入当初はやっていたのですが、次第に使わなくなった機能などを紹介します。

摂取カロリーの入力

ダッシュボードで食べたものを入力すると摂取カロリーがわかるので、消費カロリーと合わせて、カロリー収支を教えてくれる機能があるのですが、 食べたものを入力するのが物凄くめんどくさくてやめてしまいました。

食品データベースや、入力補助機能自体は結構優秀なのですが、 さすがに1日に食べる食品数が多すぎて途中で入力を諦めてしまいました。

同様に、水分量の入力もめんどくさくてやめてしまいました。

Fitbit装着による運動のモチベーションが上がらない

最初はモチベーションがあがってました。 運動開始時にストップウォッチスタートして、心拍数とか計りながらランニングする...とか。

が、数ヶ月もすると、電気毛布にくるまりながら、ポテチ食べてネットをする毎日になってしまいました。

購入時の運動系機能に対する動機が興味でしかなかったので、今はぶっちゃけ時計の機能しか使っていません。 次に腕時計を買うなら機械式とかのアナログ時計を買います。

ここは悪かった

1年間使っていれば、悪い面も見えてきたのでそれも紹介します。

壊れた

購入から11ヶ月目にいきなり壊れました。 5分に1回再起動し、時間が同期されず、1時間に7分もズレが生じる有様でした。

ただ、サポートに連絡したところ1時間後に新品を送ってくれる旨の連絡がきました。 今手元にあるやつはそのままで良いとのこと! しかも、最新バージョンを送ってくれるとのこと!

サポートは神対応でした!

外装が剥がれてくる

ウェアラブルバイスだと思いますが、基盤を隠蔽するためのシリコン素材が剥がれてきます。 単純に経年劣化だと思いますが、知り合いのFitbitも同様の問題があったので、1年でこれは結構チープな作りなのだなぁと思いました。

瞬間接着剤を使えば元通り問題なく使えるのですが...。

睡眠のトラッキングがあてにならない

自分は寝返りをよくうつタイプなのかわからないのですが、 実際は7時間寝ていても毎晩3時間程度しか眠れてないようなトラッキングになってしまいます。

こればかりはよくわからないのですが、「よく眠れていますか?」とFitbitから聞かれると、余計な御世話だ!!と思ってしまいます。

装着してなくても消費するカロリー

Fitbitは消費カロリーもトラッキングしてくれます。 購入当初は、脈拍、歩数、階段、移動距離から消費カロリーを算出してくれているのだと心底感動していたのですが、 ある日、装着を忘れて1日を過ごし、帰ってきてから同期をしたら、装着していないのにもかかわらず、1,800kcal消費したことになっていました。 基礎代謝の分かもしれませんが、これにはがっかりしました。

まとめ

振り返ってみると、ネガティブな印象の方が多いなぁといった感じです。 運動系のトラッキング機能について、興味本位で買ったのですが、あっという間に飽きてしまいました。 おそらく、どのウェアラブルバイスを使ったとしても、すぐ飽きるのではないかと思います。

ただ、トラッキングの精度があまり良くないと感じたのと、作りがチープで購入1年以内に壊れているので、 長くは使えない事を念頭に置いた方が良いかと思います。

@t_wada さんの「Mac の開発環境構築を自動化する (2015 年初旬編)」をAnsible ベストプラクティスに則り書き換えてみた

Ansible Mac インフラ周り

概要

t-wada.hatenablog.jp

Ansibleでmacの環境構築する際、id:t-wada さんの上記の記事を参考したのですが、 Ansible Best Practicesに沿っていなかったので、書き直してみました。

Ansibleを動かすまで

こちらは、t_wadaさんの記事のままです。

sudo xcodebuild -license
xcode-select --install
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew doctor
brew update
brew install python
brew install ansible

どこを直したのか

twada/macbook-provisioning

hoshinaoshi/macbook-provisioning

本家とforkしたリポジトリを比較しながら、修正した点を挙げていきます。 階層構造も修正しています。

【本家】

.
├── LICENSE
├── README.md
├── hosts
├── localhost.yml

【修正後】

.
├── LICENSE
├── README.md
├── ansible.cfg
├── group_vars
├── hosts
├── localhost.yml
├── roles
│   ├── homebrew
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   ├── tasks
│   │   │   └── main.yml
│   │   ├── templates
│   │   └── vars
│   │       └── main.yml
│   ├── homebrew-cask
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   ├── tasks
│   │   │   └── main.yml
│   │   ├── templates
│   │   └── vars
│   │       └── main.yml
│   ├── oh-my-zsh
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   ├── tasks
│   │   │   └── main.yml
│   │   ├── templates
│   │   └── vars
│   └── ricty
│       ├── defaults
│       ├── files
│       ├── handlers
│       │   └── main.yml
│       ├── meta
│       ├── tasks
│       │   └── main.yml
│       ├── templates
│       └── vars
└── site.yml

*1

site.ymlを作成し、localhost.ymlをinclude

ベストプラクティスではsite.ymlをmaster playbookとします。 また、プロビジョニング対象の役割(production, stagingなど)ごとに実行するroleをまとめたplaybookも作ります。 今回はlocalhost.ymlのみですね。*2

これらのファイルはroleをincludeするだけに留め、ここに細かいタスクを書いていくことはしません。(後述)

ロールの割り振り

元々のlocalhost.ymlのタスクは大きく4つの処理をしています。

  • homebrew
  • homebrew-cask
  • oh-my-zsh
  • ricty

今回はローカル環境のみが対象ですが、複数のプロビジョニング対象があった場合に、個別に差し込めるようにするため、 これらのタスクをrolesディレクトリ配下にそれぞれの役割ごとに分割します。 directory-layout

loclhost.ymlに列挙された変数を各ロールに振り分ける。

loclhost.ymlにhomebrew_taps, homebrew_packages, homebrew_cask_packagesの3つが定義されていましたが、 これらはhomebrewとcaskで使用するので、

  • ./roles/homebrew/vars/main.yml
  • .roles/homebrew-cask/vars/main.yml

に記述します。

./roles/hogehoge/vars/main.ymlに変数を記述すると
./roles/hogehoge/tasks/main.ymlの実行時に自動で変数を読み込み、タスク内で使用することができます。

localhost.ymlに記述されているhandlersはricty用なので、ricty/handlers/main.ymlに移動

localhost.ymlに記述されているhandlerは、よく見るとRicty用の処理であるため、Rictyロールのhandlerとして定義します。 こちらは、varsと同様にhandlerも同role内のhandlerディレクトリに記述していれば、notifyをした際に呼び出されます。

- name: run fc-cache
  shell: fc-cache -vf

localhost.ymlでtasksとして記述された内容をroleに任せる。

これらのファイルはロールをインクルードするだけに留め、ここに細かいタスクを書いていくことはしません。(後述)

ここまでの書き換えで、各ロールにvars, tasks, handlerを分けることができたので、 localhost.ymlではロールをインクルードするだけにします。

---
- name: Setup my MacBook
  hosts: localhost
  connection: local
  gather_facts: no 
  roles:
    - { role: homebrew,      tags: [ homebrew ] }
    - { role: homebrew-cask, tags: [ homebrew-cask ] }
    - { role: oh-my-zsh,     tags: [ oh-my-zsh ] }
    - { role: ricty,         tags: [ ricty ] }

だいぶスッキリしましたね。

また、tagを切っておくと、指定したタグだけ実行 / 指定したタグをスキップなどができるので、追加しておきます。 ansible-playbook site.yml --tags "homebrew,ricty" ansible-playbook site.yml --skip-tags "oh-my-zsh"

playbook実行時の引数を極力減らせるように設定

HOMEBREW_CASK_OPTS="--appdir=/Applications" ansible-playbook -i hosts -vv localhost.yml

実行時にhostsの設定をしたり、HOMEBREW_CASK_OPTSを設定したりするのはめんどくさいので、

ansible.cfgを作成し、デフォルトの動作を設定をします。

[defaults]
hostfile = ./hosts

環境変数については、homebrew-caskのタスクの一部として実行するようにします。

- name: HOMEBREW_CASK_OPTS設定
  shell: export HOMEBREW_CASK_OPTS="--appdir=/Applications"
...後続の処理がずらずら〜

ここまでの設定で、実行時のコマンドが HOMEBREW_CASK_OPTS="--appdir=/Applications" ansible-playbook -i hosts -vv localhost.ymlansible-playbook -vv site.yml となりました。 シンプル!

まとめ

以上でAnsible ベストプラクティスを適用した、Mac の開発環境構築を自動化する (2015 年初旬編)です。

"mac ansible"などで検索すると、localhost.ymlにtasksがばーーーーーっと書かれたplaybookをよく目にする印象があります。

複数のプロビジョニング対象が存在する場合は、ベストプラクティスが有効だと思いますが、 構築する対象がローカル環境のみで、処理(や、ロール)が少ないのであれば、1ファイルにゴリゴリ書いても良いのではないかと感じました。

ただ、実際は、開発スタートをするまでにrbenvの設定をしたり、ミドルウェアの設定をしたりなんだりすると、localhost.ymlが肥大化してしまうのではないかと考えられるため、早め早めにロールだけでも分けて記述するのが落とし所かと思います。

こちらにコードを置いておきます。
https://github.com/hoshinaoshi/macbook-provisioning

今回Ansibleを初めて触ってみたのですが、ymlで書くのが地味に楽でした。
Ansibleの処理も「Ansible {{やりたいコマンド}}」で検索 => 1つ目の記事ではい理解〜というような感じでした。
自分は、初めての技術に触れるときは、初心者用の書籍を購入して、一読するのですが、Ansibleにおいては下記の書籍を買いました。

*1:中身が空のディレクトリは削除しても良いかも

*2:通常は複数のサーバーに対して行うので、若干無理矢理感がありますね

Rubyで使われるコロンの意味を調べてみた

Ruby

概要

Rubyを初めて触ったときに、(当時の自分が触っていた)C#JAVAではコロンが使われておらず、 これはどのような意味なのかがよく話からたかったので、まとめてみました。

:symbol
"symbol"

こちらの違いについてまとめます。

Rubyにおけるコロンの意味とは?

Rubyにおけるコロンは、シンボルといいます。

:symbol 一見文字列と同種に見えるが、内部的には数値として扱われます。 そのため、比較や検索などの速度面が文字列と比べると高速になります。

  • ハッシュのキー
  • メソッドの引数として渡すクラス名、メソッド名、変数名、定数名

などについては、はシンボルを使用したほうが良いでしょう。

リファレンスでは

リファレンスを引用します。

Rubyの内部実装では、メソッド名や変数名、定数名、クラス名など の'名前'を整数で管理しています。これは名前を直接文字列として処理するよりも 速度面で有利だからです。そしてその整数をRubyのコード上で表現したものがシンボルです。 シンボルは、ソース上では文字列のように見え、内部では整数として扱われる、両者を仲立ちするような存在です。 名前を管理するという役割上、シンボルと文字列は一対一に対応します。 また、文字列と違い、immutable (変更不可)であり、同値ならば必ず同一です。

文字列と見せかけて、内部の実装では整数として扱っている。といったところでしょうか。

検証してみた

> Rubyの内部実装では、メソッド名や変数名、定数名、クラス名など の'名前'を整数で管理しています。

つまり、メソッド名や変数名、定数名、クラス名を定義した瞬間にシンボルができるという意味です。 実際にやってみましょう。

class SymbolTest
end

symbol_var = 0

SYMLBOL_CONSTANT = 0

def symbol_method
end

p Symbol.all_symbols.include?(:SymbolTest)
=> true

p Symbol.all_symbols.include?(:symbol_method)
=> true

p Symbol.all_symbols.include?(:symbol_var)
=> true

p Symbol.all_symbols.include?(:SYMLBOL_CONSTANT)
=> true

見事に全てtrueを返しましたね。

> これは名前を直接文字列として処理するよりも 速度面で有利だからです。

文字列と数値なので、そりゃ高速になるだろうと反射的に思いましたが、こちらも検証してみます。

benchmarkというモジュールを使用して計測してみます。 実際のやり方はこちらを参考にしました。 Ruby でベンチマークを取る方法 - Qiita

require 'benchmark'

Benchmark.bm 10 do |r| 
  str = "0123456789"
  str_hash = { "0123456789" => 1 }
  r.report "String" do
    9999999.times { str_hash[str] }
  end 

  sym = :"0123456789"
  sym_hash = { "0123456789" =>  1 }
  r.report "Symbol" do
    9999999.times { sym_hash[sym] }
  end 
end

                 user     system      total        real
String       1.190000   0.000000   1.190000 (  1.190577)
Symbol       0.810000   0.000000   0.810000 (  0.815450)

文字列に比べて、シンボルは30%前後早くなっていますね。 すごいぞシンボル。

> 名前を管理するという役割上、シンボルと文字列は一対一に対応します。 また、文字列と違い、immutable (変更不可)であり、同値ならば必ず同一です。

同じ名前のシンボルであれば、いくつ生成してもオブジェクトIDが1つという意味ですかね。

hoge1 = "hoge"
hoge2 = "hoge"
puts hoge1.equal?(hoge2)
=> false

puts hoge1.object_id
=> 70281989413340

puts hoge2.object_id
=> 70281989361520

sym1 = :hoge
sym2 = :hoge
puts sym1.equal?(sym2)
=> true

puts sym1.object_id
=> 539048

puts sym2.object_id
=> 539048

こちらもリファレンス通りですね。

まとめ

冒頭でも書きましたが、Rubyにおけるコロンは、"シンボル"と呼びます。 一見文字列と同じように見えますが、内部的には整数と同様に扱われます。 そのため

  • 文字列と比較すると処理が高速
  • 同じ値であれば、生成されるオブジェクトは1つ。

また、クラス、メソッド、変数、定数を定義すると、その名前のシンボルも生成されます。

文字列とシンボルの使い分けとしては、

  • ハッシュのキー
  • メソッドの引数として渡すクラス名、メソッド名、変数名、定数名

などは、文字列ではなく、シンボルを使用したほうが良いでしょう。

こちらの本はRubyについて、今でもリファレンス的に使用している本なので、オススメします。
※今回のシンボルについては、ここまで詳細には書かれていませんが、全範囲を網羅的に書かれています。

homebrewでinstallしたcurlがbrew cask install時のTLS1.2ではOSX標準のcurlが邪魔をしてうまく反映されなかった時の対処法

Mac インフラ周り

概要

homebrewでinstallしたTLS 1.2 接続できるcurlbrew installでTLS1.2接続しなければならないパッケージのinstall時に、OSX標準のcurlを見に行ってしまい、うまくinstallできなかったので、その対処方法を書きます。

具体的には、brew cask install sourcetreeをした際に、curl https://downloads.atlassian.com/software/sourcetree/SourceTree_2.3.2.zipを叩くのですが、 そこでssl handshake failedとなり失敗していました。

手順

homebrewで最新のcurlをinstallしOpenSSLを使用するように変更

確認に使用したコマンドなども含めつつ説明していきます。

まずは、curlでTLS1.2で接続していないことを確認します。

$ curl --dump-header - https://www.example.com --tlsv1.2 --verbose 
*   Trying nnn.nnn.nnn.nnn...
* Connected to www.example.com (nnn.nnn.nnn.nnn) port 443 (#0)
* SSL peer handshake failed, the server most likely requires a client certificate to connect
* Closing connection 0
curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect

次に、最新のOpenSSLでTLS1.2が使用できることを確認します。

$ openssl s_client -connect www.example.com:443 -tls1_2
CONNECTED(00000003)
...

既存のcurlにOpenSSLが使われていないことを確認します。

$ which curl
/usr/bin/curl
$ curl --version
curl 7.43.0 (x86_64-apple-darwin14.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets

上記の通りOpenSSLが含まれていません。

homebrewで改めてcurlをinstallします。

$ brew install --with-openssl curl
$ brew link curl --force

OpenSSLが使用できているか確認します。

$ which curl
/usr/local/bin/curl

$ curl --version
curl 7.51.0 (x86_64-apple-darwin14.5.0) libcurl/7.51.0 **OpenSSL/1.0.2j** zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets 

OpenSSL/1.0.2jが適用されていることが確認できました。

念のために、TLS1.2で接続できるかも確認してみます。

$ curl --dump-header - https://www.google.com --tlsv1.2 --verbose
* Rebuilt URL to: https://www.google.com/
*   Trying 216.58.200.196...
* TCP_NODELAY set
* Connected to www.google.com (216.58.200.196) port 443 (#0)
...
...
* Curl_http_done: called premature == 0
* Connection #0 to host www.google.com left intact

問題なくTLS1.2接続できていますね。

シンボリックリンクを張る

この時点で、brew cask install sourcetreeを実行してもssl handshake failedになります。 前回の記事同様パスの影響を受けているのではないかと考えましたので、 brew cask installで見ているcurlシンボリックリンクで無理やりbrew installしたcurlを参照させます。

$ sudo mv /usr/bin/curl /usr/bin/curl_back
$ sudo ln -s /usr/local/bin/curl /usr/bin/curl
$ brew cask install sourcetree
==> Caveats
Cask sourcetree installs files under "/usr/local". The presence of such
files can cause warnings when running "brew doctor", which is considered
to be a bug in Homebrew-Cask.

==> Downloading https://downloads.atlassian.com/software/sourcetree/SourceTree_2.3.2.zip
Already downloaded: /Users/user_name/Library/Caches/Homebrew/Cask/sourcetree--2.3.2.zip
==> Verifying checksum for Cask sourcetree
==> Moving App 'SourceTree.app' to '/Applications/SourceTree.app'
==> Symlinking Binary 'stree' to '/usr/local/bin/stree'
🍺  sourcetree was successfully installed!

うまくいきました。 シンボリックリンクで無理やり変更しているので、ワークアラウンド感がハンパないですね。 うまいやり方があれば是非教えていただきたいです。

homebrewでinstlalしたOpenSSLが反映されず、OSX標準のOpenSSLが使用されてしまう場合の対象方法

Mac インフラ周り

概要

OSX標準のOpenSSLが古く、tls1.2で通信できず、curlが失敗する事案が発生してしまいました。 対処方法を調べても、

`brew update
brew upgrade openssl
brew link openssl --force

で治りました^^

という記事が多かったのですが、上記の対応でもopenssl versionが古いままだったので、その対処方法を書きます。

手順

手順は下記の通りです。 - homebrewで最新のOpenSSLをinstallし、リンクを張る - OpenSSLのパスを確認 - 環境変数の設定

homebrewで最新のOpenSSLをinstall

この記事にたどり着いた人は、既に実行済みかつ、5,000万回は同じことを見ていると思いますが、 念のため記載しておきます。

$ which openssl #opensslのパスを確認 /usr/bin/openssl となってるはず
$ openssl version #バージョンの確認
$ brew update #brewのアップデート
$ brew list #opensslがインストールされているか確認
$ brew info openssl #最新版の情報取得
$ brew upgrade openssl #アップグレード
$ brew link openssl

OpenSSLのパスを確認

だいたいの記事では、これで治りました報告が多かったのですが、自分の場合は、 この時点でopenssl versionをやっても古いままでした。

今一度、パスを確認してみると

$ openssl version
OpenSSL 0.9.8zg 14 July 2015

$ which openssl
/usr/bin/openssl

$ brew info openssl
openssl: stable 1.0.2j (bottled) [keg-only]
ずらずら〜〜
/usr/local/Cellar/openssl/1.0.2j (1,695 files, 12M)

OSX 標準のOpenSSLのパスが/usr/bin/opensslだったのに対して homebrewでinstallしたOpenSSLが/usr/local/Cellar/openssl/1.0.2jなのが分かります。

環境変数の設定

これまでの結果から、読み込まれる順番が問題なのではないか?と推測し、 $PATHの設定を疑いました。

$ echo "export PATH=/usr/local/Cellar/openssl/1.0.2j/bin:$PATH" >> ~/.bash_profile
$ source ~/.bash_profile
$ which openssl
/usr/local/Cellar/openssl/1.0.2j/bin/openssl
$ openssl version
OpenSSL 1.0.2j  26 Sep 2016

予想通りでした。 brew link opensslだけでは正常に反映されておらず、基本的なパスなどの確認を怠っていたがために小一時間ハマってしまいました。

AWSアカウント開設直後 & EC2インスタンス立ち上げ直後に最低限行うべきこと

概要

以前からクラウド破産クラウド破産と耳に入ってはいたが、個人で利用しているAWSアカウントはほぼノーガードでした。
また、ピクスタの来期AWS予算を策定していく中で、こんな金額がいきなり身に降りかかってきたら生命保険に入ることを考えてしまうだろうと思ったため、
個人のアカウントも最低限セキュリティ対策をすることにしました。

やったこと(IAM & Billing)

  • MFA導入
  • IAM設定
    • グループ、ユーザー、IAMユーザーに対してのMFA設定
  • コストエクスプローラーのの有効化
  • アカウント設定
    • 秘密の質問など
  • CloudTrailの有効化
  • Trusted Advisor チェックの実施

ここまで箇条書きにしてみたものの、クラスメソッドさんの記事を参考にしました。

個人で使用する分には、IAMグループでAdministratorAccessを設定するのは、やむなしかと思ったのですが、 組織で使用する場合には、適切にグループの権限設定をした方が吉だと思いました。

やったこと(EC2)

アカウント全般もさることながら、EC2インスタンスもAmazonLinuxのAMIをまんま使用していたので、
稼働中のインスタンスに対してもセキュリティ向上のために下記を参考に諸々実施しました。

大きくは、

  • ec2-userの削除
  • sshdのLISTENポート変更
  • git-secretsの使用

がセキュリティ上、有用ってところでしょうか。

特に自分の場合は、個人で開発を進めているとアクセスキーとシークレットキーを誤ってcommitしてしまう事案が多発しているので、
git-secretsは入れておくべきだと感じました。

まとめ

実際にやってみて感じたのは、項目は多少多いものの、設定自体は簡単でした。 今更ながらですが、デフォルト設定のままだと不正利用された時に何も言えなくなるので、最初に締めべきとこは締めた方が良いと思います。

酒豪伝説飲んで飲み会に参加したら逆に酔えなくてハングオーバーしてしまう話

その他

今回は、酒豪伝説という、飲み過ぎ/二日酔いを予防する魔法のアイテムを実際に使ってみた感想を書いていきます。 ※二日酔いになりたくないなら飲むなよ!というツッコミはなしで。

酒豪伝説とは?

ただ、ウコンの粒と薬草を粒にしたものが、5,6粒入っている小包でした。 ブログで、結構有名だったり、沖縄にいけば必ず目に付くものだったり、1袋200円と高価なので、 開けた瞬間は少しがっかり?しました。

飲んでみた結果

何はともあれ、効果があれば問題なし! ということで、酒豪伝説を摂取して飲み会に参加してみました。

これ、意外に効いている気がします!

なんだろ、表現するのが難しいんですが、 アルコール処理限界が10段階あったとして、10を超えると二日酔い確定ラインが感覚としてあるのですが、 何杯飲んでも、何を飲んでも7~8くらいで止まっている感じです。

つまり、酒に酔ってハイになっている状態を継続し続けることができます。

そして、翌日に二日酔いになる確率は結構低いです。 さすがに、朝5時とかまで飲むとダメなんですが、1次会で終わって帰宅した場合は余裕です。

飲みすぎてしまった後でも、飲んだ後に摂取すると二日酔いの症状が緩和されていたりしたので、 飲んだ後でもある程度効果があると思います。

副作用

酒豪伝説自体に副作用はありませんでした。

が!

酒豪伝説を過信して、ハードリカーを調子に乗って連続して飲んだりすると、当たり前ですが、二日酔いになります。 また、酒豪伝説を飲むと、酔い難くなります。 なので、必然的にお酒の摂取量が増え、会計が大変な事になります。

意味ねぇ!!

まとめ

酒豪伝説二日酔いを抑制する効果があると思いました。
ただし、酒豪伝説を飲んだ事によって、逆に飲みすぎてしまうと元も子もありません。

1袋はすごく小さいので、カバンに入れてもかさばりませんし、 飲んだ後でも効果はあるので、何袋か購入して家に置いておくのもオススメです。