iPhoneをGenius Barに持って行く前にすること
Genius Barとは
iPhoneをはじめとするApple製品のカスタマーサポートで、各Apple Storeで専門スタッフが不具合をマンツーマンで聞いてくれるサービス。
私はiPhone5のWi-Fi接続不良、iPhone6の予期せぬ終了で計2度、お世話になりました。
前回持って行った時、スタッフと話していて勉強になったことを紹介。
予約する
当日行って受付するのもいいですが、予約してから行くとほとんど待たずに診てもらうことができる。当日だと予約できないことがあるので、2〜3日前に予約することをおすすめ。
診断する
予約時に診断することが強制されている。入力したメールに診断URLが添付されてくる。それを開くと診断が始まり、Appleに型番をはじめとするiPhoneのハード情報が送信されるため、店頭で設定を開いて型番などを教える必要がなくなる
DFUモードによる復元
バックアップをしてから実行してください。
PCにつなぎ、iTunesに繋いだ状態でホームボタンと電源ボタンを押し続けると、基盤レベルの復元モードになる。
店員さんいわく、「普通のリストアと違い、これでソフトウェアの問題なのか、ハードの問題なのかの切り分けができる。ソフトの問題ならこれで直る。実行後1週間くらい試験的につかってみてください」
また、急にアプリが強制終了するようになったり、動作がもっさりする場合もこれで直るケースが有るという。ただし、この方法は公にしていない。
フロー
したがって、持って行く前に
- DFUモードによる復元を行う
- 試験運用
- なおらなければ予約
- 診断
というフローをとれば、交換したい時だけお店にいけばいいことになります。
保証対象かどうかは、スタッフに尋ねないとわからないので、無償で交換できるか知りたい場合も行く必要あり。 対象外の場合はまるごと交換で3万4,5千円でした(2016/1/31時点のiPhone6 128GB)。
まとめ
- Apple Storeに持ってく前にやるべきはDFU復元、試験運用、予約、診断
- 保証対象かどうかはお店で知ることができる
- 保証対象なら無償、対象外なら3万程度かかる
- DFU復元は動作が重くなった、急にアプリが強制終了するようになったなどの場合にも直るケースがある
- DFU復元は非公式
iTunes Connectでアプリがレビューに入ったとか、リジェクトされたとかをslackに通知する
から、派生して作った。ヤマトはラインで見れちゃうのでいらない子になっちゃったしね。今まで、一部の人がメールを受け取った際にチームに共有してたのでタイムラグや共有し忘れを防ぎたくてつくった
今回もGMailを定期的にGoogle App Scriptで読み込んで、SlackのWebhookを叩くという流れ。
iTunes Connectからくるメールの件名はフォーマットが決まってるのでそれに応じて通知を変えたら見やすくなりました。
レビューが通った場合はこんな感じ
ステータスは全部で8つかな。
- Processing for App Store => アップロードが完了し、アプリの処理中の状態
- has completed processing => アップロード後の処理が完了した状態
- Waiting For Review => 申請が完了しました。レビュー待ちな状態
- Developer Rejected => アプリの申請を取り下げた状態
- In Review => レビューに入った状態
- New message from App Review => レビューアプリに対して、Appleより連絡があった状態。おもに仕様の確認やリジェクトの時
- Pending Developer Release => レビューを通過した状態
- Ready for Sale => 公開処理が完了し、ストア反映待ちな状態
特に、"has completed processing"は1時間で終わるときから1日位かかるときもあったので、見逃しがちだった。これで迅速な申請作業に移れそう。
ソース
Google App Scriptから直接Slackに通知
割と本気で家庭用Slack Botを作ってみた - 八発白中 がかなり、あついですね。
VPSはおもちゃ箱なんだなあと、ゆめがあるなあと感じます。
とはいえ、お金をかからない方法をとるという強かなスタンスもまた、アリです!
またまたやってみました。Google App Scriptの定期実行。
今回はヤマトからの未読メールかつ、不在通知メールがあれば、notificationチャンネルにメール内容を投稿し、さらにメールを既読にするGoogle App Script。
これをGoogle App Scriptのcron機能で1時間毎とかに実行する
フックをDocsやらCalendarの更新などにすれば使いみちはいくらでもあるので、テンプレとして今後使えそう。
以前、Spread Sheetの情報をマスタとしてゴミの日の前日にSlackに翌日がなんのゴミの日かを通知cronを実装した時の話を書きましたが
IFTTTを介さずともslackに通知できるし今後はIF GAS Then Slackスキームで行こうと思う。
ナプラケアテクトリペア
シャンプーとコンディショナーをリピート
fluentd(td-agent)でGoogle Cloud Storageにログをためる
初めてrubyを書いた。mixinとかいろいろ省略してかけるとかaliasをメソッドに貼るとか便利だなーというのが感想。
gemの公開もbundleコマンドでさくさく出来たのでこれは開発者にとってかなり魅力的なのでは。エコシステム?が素晴らしい。
さて、本題ですが、今、開発中のfluentdのoutputプラグインの使い方をメモ。Fluentd(td-agent)からGoogle Cloud Storageにログのファイルを直接置くという役割。
ルビー書き始めて2日なのでまだまだクソース&開発中です。まさかりまってます
gem
fluent-plugin-google-cloud-storage-out | RubyGems.org | your community gem host
github
モチベーション
Google Cloud Storage (以下、GCS)にとりあえずログを置く
GCSに置いとけばあとからBigQueryにインポートできるので、生ログをとりあえずここにためて置くと良さそう。
BigQueryにストリーミングインサートするとお金がかかるし、安定してなかった?という話もあったので、直接GCSに置くことに。
とはいえ、各ホストからログのアグリゲーションをするのもめんどくさそう。いっそ各々でtd-agentが動いてるのでそこから送っちゃおうという魂胆
さらには、オンプレミスで減価償却するよりもクラウドの値段が下がるほうが速いんじゃないのかな。GCSはとてもやすい。
一応既存のものはあったが
fluent-plugin-google-cloud-storage | RubyGems.org | your community gem host
というgemがすでにあったが、最新のGoogle Client APIや認証の形式についていっていないようだし、gem公開をしたかったのでw
使い方
インストール
よしなにgemで
Service Accountを登録し、認証情報(.json)をよしなに配置
GCSのAPI状態がEnableか確認して、鍵を作成。
td-agent.confを編集
<match *.log> type google_cloud_storage_out service_account_json_key_path /etc/td-agent/client_secrets.json bucket_id log-hangar path activity/%Y_%m_%d/${hostname}_%H%M_${unique} unique_strategy timestamp unique_format %S format json compress gzip buffer_type memory buffer_chunk_limit 100m </match>
- service_account_json_key_path 名の通り、jsonキーのパス
- bucket_id => bucketは現状は作成済みでなければならない
- path => GCS上のファイルパス。unique_strategyを設定する場合、
${unique}
をパスに含まなければならない。含まない場合はローテートされるまえにバッファのフラッシュが2回起きると上書きされてしまう - unique_strategy => [increment, timestamp, chunk_id]から選択。
${unique}
をどう置換するかの実装を選ぶ。- increment => 0, 1, 2, ...とカウンタが使われる
- timestamp => フォーマットに従って、バッファフラッシュ時のタイムスタンプに置換
- chunk_id => バッファのchunkのユニークIDに置換する
- unique_format => timestampの場合に使われる。
- format => デフォルトのfileアウトと同じ実装
再起動
よしなに.テスト時はバッファのmemory容量を10kとか低い値にするとテストしやすかった
参考にしたもの
- fluent-plugin-google-cloud-storage
- PRもいくつか送っているが、そもそもこれを参考に書きなおしている
- google-api-ruby-client
- gemを公開するまでの手順
- 数コマンドでクソースをパブリッシュできちゃう怖さ。
- 検索: fluent-plugin-redshiftとかたくさんある。GCS関連はまだ上述のものと私が書いたものの2つだけ。
展望
- ドキュメント
- ユニットテスト
- ストレステスト
- エラーハンドリング
- コードスタイルに合わせる
- 英語を良くする
まとめ
fluentdがプラガブルなので、素人でもとりあえず動くプラグインはかけた。fluentdすごい
slackと仲良くなる
まず、公式ドキュメントよめ
公式読まない人は何をやっても使いこなせないでしょう。と自分にいいきかせ読んでみたら、とても良かったので使えそうなやつをカテゴリ別にメモしていきます。
Hipchat → Slack移行なう
もともとHipchatを使っていて、先月くらいから移行中。複数のチームを共存できるのイイ。個人(家用)と会社用でつかっています。
個人のアカウントはIFTTT連携して、Google App Scriptから前日に翌日は「なんのゴミの日なのか?」をSlackに通知するために使ったり。
本格的につかうならショートカットとスニペットは覚えなくては
Hipchat使ってた時には⌘ + t
と⌘ + [
, ⌘ + ]
くらいしか使ってなかったのですが、公式に載ってるショートカットがなさすぎる。
それに対し、slackはチャンネル切り替えなどの基本動作だけで15個。スバラ!
設定
Display Options
✅ show times with 24-hour clock → 24時間表記(個人的にこっちがすきなので)
Advanced Options
✅ Whtn typing code with ```, Enter should not send the message → コードを入力しようとした時はEnterでメッセージを送らない。(対となる```で閉じたあとにEnterで送信は有効化される)
✅ List public and privte channels separately → 公開と非公開のチャンネルのリストを分ける
ショートカット
Chromeとショートカットが同じ or 似ていて覚えやすいショートカット
コンテキストスイッチが少ないのでありがたい。
Chrome | Shortcut | Slack |
---|---|---|
拡大/縮小/元の縮尺 | ⌘ + + ⌘ + - ⌘ + 0 |
拡大 縮小 元の縮尺 |
ブラウザフォワード/バック | ⌘ + ] ⌘ + [ |
1つ先/前に見ていたチャンネル |
カレントタブのリロード | ⌘ + R |
カレントアカウントのリロード |
N番目のタブを開く | ⌘ + [1-9] |
N番目のチームを開く |
次/前のタブを開く | ⌘ + shift + ] ⌘ + shift + [ |
次/前のチームを開く |
形式に合わせてペースト | ⌘ + shift + v |
スニペットペースト |
設定を開く | ⌘ + , |
設定を開く |
あまり使わないショートカットがあるにせよ、これだけで覚えやすい。
⌘ + ,
に限っては当然のごとく。
その他に積極的に使うショートカット
Shortcut | 動作 |
---|---|
Alt + ↑ Alt + ↓ |
上/下のチャンネルを開く |
Shift + Alt + ↑ Shift + Alt + ↓ |
未読がある上/下のチャンネルを開く |
Esc |
開いているチャンネルを既読にする |
⌘ + f |
開いてるチャンネルをターゲットに検索する |
⌘ + / |
ショートカットチートシート表示 |
Alt + messageをクリック |
そこから未読扱いにする。 後で読む的な使い方 |
⌘ + Shift + m |
自分へのメンションのリストを開く |
/
コマンド
コマンド | 動作 |
---|---|
/leave |
チャンネルから退出 |
/keys |
ショートカットチートシート表示 |
/who |
チャンネルにいる人をリスト表示 |
/search query |
検索 |
searchのクエリについて
どこのだれからか
in:[channel|user]
from:[user|me]
メッセージに含む
has:[link|star|:絵文字:]
いつ
befor:
after:
on:
during:
時間指定に使えるのは
- today
- yesterday
- week
- month
- year
- YYYY-MM-DD
ここは少し、わかっていないところ。
まとめると覚えるのでよい。
Vagrant公式ドキュメントを見るときに気をつけたい
VagrantのprovisionerにAnsible
Vagrantにはprovisionerが幾つか、用意されています。
メジャーなのはchef-client
やchef-solo
かと思います。vagrant-omunibusというプラグインがあるので、実行環境を整えやすいですし。
また、簡単なプロビジョニングであればshell
で済みます。
一方で、自分はよくAnsibleを使っています。最近Ansible熱があるというだけです笑
OSXの環境を整えるのもAnsibleでやったりしています。
話は戻りまして、Vagrant上にDockerのプロビジョニング環境を作るときにもprovisionerにAnsibleを使いました。
この時、公式ドキュメントを見ていて、設定項目がすくなくないか?と思ったのですがVagrantにはAnsibleとAnsible localの2種類があるため、共通のオプションは別ページとのこと。
Optionのリストだけを見ていて、説明をすっ飛ばしたので気づかなかった。。。
Ansibleの共通オプションはCommon Ansible Options - Provisioning | Vagrant by HashiCorpを見るべし。また、気をつけたいのがこのページはprovisionerのカラムからは直接飛べないので、一度Ansibleのページを開き、OPTIONSの説明の
This section lists the specific options for the Ansible (remote) provisioner. In addition to the options listed below, this provisioner supports the common options for both Ansible provisioners.
この部分のリンクを開かねばなりません。
副産物
説明がないものと思い込み、Vagrantのgithubのソースを読んでおりました。
この部分を読めば、オプションが書いてあります。また、他のprovisionerも同様です。
DocsへはPRできる模様
VagrantのDocsの右下にEdit this page
というリンクが有り、クリックするとgithub上で対応するページのドキュメントのソースに飛びます。きっと、PRを受け入れてくれるのでしょう。
https://github.com/mitchellh/vagrant/tree/master/website/docs
個人的にこういうスタンスになっている事自体が、すごいな〜と思いました。
壁美人をつかったという話
「C++初心者ならビルドはBazelでラクしちゃいましょう」の主役となったBazelや「100円でオフィスのデスクをスッキリさせたという報告。」でまな板たて使うというアイディアを教えてくれた、会社の先輩に年末に
「壁美人いいよ。特に賃貸だったら」
と言われ、我が家でも導入してみた。
壁美人とは
一言で言うと、画鋲や釘など大きな穴を開けずに壁にフックをつけたり、テレビを設置したりできるというもの。
画鋲でも穴がひどいと、壁紙張り替えになって敷金なくなっちゃう場合があるので。。。
パッケージがこれ
ホチキスでとめる
まさかのホチキス。家にあるので、工具も特別なものが不要なところがとてもありがたい。
試しにつけてみる
拡大してみる
比較用に画鋲も刺してみたけど、画鋲のあなは目立つ
ホチキス針は専用針
完全に憶測なのですが、ホチキスの芯はステンレス。なぜなら、文房具屋で売ってるものは鉄なのでさびやすいです。
サビで壁が赤くならないようになってるんですね〜
見た目が不格好じゃない?
自分もそう思いましたが、隠せました!
もっとリース飾りたいと言われたので、追加購入します