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

血便がでた

昨日の夜になんかお腹の調子悪いな〜ってトイレ行ったら血便が出ていた。血便にも色々あるのだが自分のは鮮血で、痔とかじゃなくて腸がやばそうな感じがしていた。

allabout.co.jp

これを読むと良くて痔とか腸炎で、ヤバいと癌らしいので戦々恐々として病院に行った。

検査入院とか言われたりしたけど、結論から言うと癌とかではなく普通に食中毒的なやつなので何事もなく明日からも行きていける、良かった。

診察の流れ

オフィスビルの病院で診察

1. 痔じゃないか確認する

肛門に指を入れられて確かめられる、たぶんなんか変な声出た。

触診の結果「入り口すぐのところに膨らみがありそれが痔っぽいですけど念のため午後に大腸にカメラ入れる検査もしますか」という流れになる。

2. 採血

ヘモグロビンの量を測りたいので血を取ります、と言って血を抜かれる。しかし血便ですでにかなりの量を出血していたせいか採血後に失神して、起きたら知らない天井だった。

3. 大腸カメラ準備

下剤をひたすら飲む、10 分間に 200ml 飲むのを9回繰り返して 1800ml 飲まねばならない。しかし下剤はアクエリアスみたいな味がして全然飲めた。

下剤を飲み始めて 30 分後くらいにトイレに行き、やっぱり血便なのだが、それを看護師さんにみてもらう。なんか看護師さんが「こりゃ痔じゃない、大腸だわ…」みたいな空気を醸し出すも下剤は飲み続けろと言われる。

4. でかい病院に行くことになる

主治医っぽい人が「便を見ましたがこれは痔じゃなくてもっとヤバいやつなので、今からでかい病院を紹介するのですぐに検査入院してください。タクシーでいけますか?救急車乗りますか?」といきなり言ってくる。いきなりすぎて少し混乱したが、救急車ってほどヤバい体調じゃないのでタクシーで行く。

5. タクシー

乗車10秒で酔った。5分しか乗らなかったけど病院ついた時は吐きそうだしトイレ行きたいし最悪な気分だった。

でかい病院で診察

6. 採血・CTC検査

また採血した、今度は失神しないよう寝ながら採血してもらった。CTC で大腸のレントゲンもとった。

7. 大腸内視鏡検査

肛門からカメラ入れて、大腸でおかしいところないか確認するやつ。人生初浣腸をした。
カメラ入れながら腸を広げるために空気も入れるので、お腹が張ってめちゃくちゃ辛かった、お腹もずっとギュルギュルいっていた。

カメラでみてると大腸の奥の方に数カ所の出血があった。

8. 診察完了: 食中毒

カメラでみた感じ癌とかではなさそう、というか普通に食中毒じゃないですかねと言われた。おととい電子レンジで生の鶏肉をレンチンして食べたんだけど、それっぽい感じだった。レンチンなので、局所的に火が通ってなかったりとかあったのかもしれない…。

ちゃんとした病名はナントカカントカ腸炎だったけど忘れた。

9. 支払い

21000円だった、高い…。自炊なんかして適当に飯食べるより外食した方が安全で安上がりなのでは?

血便が出たらどうすべきか

  1. メシを食べない
    • 大腸内視鏡検査をするためには腸を綺麗にしないといけない
    • 血便が出た以降は診察を受けるまでメシを食べない
  2. ちゃんと病院にいく
    • 気合いと根性で治るやつと、治療しないと治らないやつがある
    • それは診察しないとわからないので安心感得るために病院にいけ

人生

癌かも?とか思った時にちょっと人生について考えて、やっぱパン屋さんいいよなというのを昔から思っている。パン屋さんというか接客業をやってみたいのかもしれない。

迷走にも書いたけど、ソフトウェアエンジニアじゃない職もやってみたい。人生長いようで短い気がしているのでやるなら今なのかもしれない。

見たくない画像を置換する Chrome Extension を作った

chrome.google.com

Image Switcher という、指定した画像を別の画像に置き換える Chrome Extension を作った。

仕事で GitHub とか Google とか使うじゃないですか、それに自分の見たくないアイコンを使っている人がいるじゃないですか、でもその人に「そのアイコン嫌いなんで変えてもらえますか」なんて言えないじゃないですか、だから自分でなんとかした。

設定画面で from: に見たくない画像の URL を指定して、 to: で新しく表示する URL を入力する。to: はデフォルトで Image Switcher のアイコンが指定されるので、実際は from: だけ指定すれば良い。

Extension の中身は何をやっているかというと、 img.src を書き換えているだけ。

しかしこれには問題があり、

  1. "run_at": "document_idle" のタイミングで実行しているので一瞬元の画像が表示される
  2. SPA とかで DOM を後読みされると document_idle が発火せず置換されない
  3. background-image: url(image/hoge.gif); に対応していない

というのがあるが、まあ今のところ利用に支障はないのでいいか、となっている。面倒だしたぶん自分しか使わないだろうし。

Chrome の拡張を作ったのは2年半ぶりだったが、大きく仕様が変わっているわけでもなさそうでサクっと作れた。

ソースコードも公開している。
starhoshi/ImageSwitcher

他にも作りたい Chrome Extension あるしやっていきたい。

Xcode で A valid provisioning profile for this executable was not found. が出た時の対処法

f:id:star__hoshi:20170518165343p:plain

実機インストールしようとしたらなんじゃこりゃ、というエラーが出た。ググってみると iPad 側にインストールされた証明書が悪い、などと出たのだが自分の場合はどれも違った。

Debug ビルドなのに Adhoc 証明書を使おうとしてた

のが原因っぽい。

ダメな例

f:id:star__hoshi:20170518170104p:plain

問題ない例

f:id:star__hoshi:20170518170019p:plain

Development 証明書を使うと

問題なく実機インストールできました。

よく考えればなんで開発環境で Adhoc の使おうと思ったんだ自分は、それが間違っていた。

「強いチームはオフィスを捨てる」を読んだ

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

リモートワークいいぞという内容だが、むやみやたらとリモートワークを導入しろと言っているわけではない。

ちょうど リモートワークへの努力とは何なのか - axross.io という記事が話題になっており、この本と同じようなことを言っている。

リモートワークをするためには情報がオープンでなければならない、これは必須である。しかし、これはリモートワークに限った話ではないと思う。

働き方に関わらず情報はオープンであるべきだと思う。オフィスにいたとしても裏でこそこそ動いている案件があるべきではないし、チームが違うからといって情報にアクセスできないなんてのは良くない。口頭で会話したけど議事録も何もないというのはオフィスで働いていたって起こる。

大切なのは、必要な資料や情報を、いつでもみんなの手の届くところに置いておくことだ。

これらを普段からやっていない会社がリモートワークをやるとリモートワークがうまく機能しないのは当然で、そもそもこれができてないとオフィスで働いててもストレスが溜まると思う。

弱いチームはオフィスを捨てられないのである。

「小さなチーム、大きな仕事」を読んだ

小さなチーム、大きな仕事 働き方の新しいスタンダード (ハヤカワ文庫NF)

小さなチーム、大きな仕事 働き方の新しいスタンダード (ハヤカワ文庫NF)

書籍の名前は聞いたことあったけど読んだことはなかったので読んでみた。 題名の通り少ない人数(例えば一人)であっても大きな仕事が可能だからやろうぜ、現に俺たちは少ない人数で大きな仕事をやっているよ、という内容。1つの章が3ページくらいになっててサクサク読めて良い。

無駄なことはせず、小さく始め、顧客のために良いプロダクトを作ろう、という話が中心となっていて、当然のことを当然のようにやることが大切であると言っているように感じた。最近いろいろな本を読んでるけど他の書籍でも同じことを言っていて、やっぱりこういうことをするべきなんだなという感じ。

また、個人アプリ開発者なので身にしみることがたくさんあった。弱小デベロッパは広告会社なんて使えないから Twitter で拡散したり口コミなど草の根でやっていくしかない。そういうやり方でいいからやっていこうぜと書かれていて勇気付けられる。

いくつか心に残る点があったのでメモ:

失敗は成功の源ではない

失敗しないならその方が良いし、成功する人は成功する。
おっしゃる通りだ…。

量より質

中途半端な完成品より、機能を半分にした良い製品が良い。

おっしゃる通りだ。

今すぐ世に出すべき

商品が最低限の要件を満たしているなら、いますぐ世に出すべきだ。

MVPだ、リーンスタートアップだ。

見積もりを間違ったタスク

最初に2時間で見積もったタスクが全然終わらず、16時間かかると判明したとする。 もともとは2時間予定だったそのタスク、16時間かかるとわかったらやるだろうか?途中でやめる方が有益か考えた方が良い。

ひとりきりモード

コミュニケーション依存症からの依存。インスタントメッセージ、電話、メール、会議を断念しよう。

最近読んだどの本にも書かれている。

競合相手

競合相手は製品はパクれるかもしれないが、製品の中にあるあなたまではコピーできない。だからあなたが信じていることで戦おう。

これは口で言うのは簡単だが実際にやるのはかなりの勇気がいると思う、けどその勇気を出してサービスを作っていきたい。

文化

文化は作るものでなく自然と発達するもの。

弊社、文化を作ろう?みたいな働きがあってだいぶエモい気持ちになる。

ビジネスで絶対に使ってはいけない四文字言葉

need(必要), must(しなければ), can’t(できない), just(ただ), only(だけ), fast(早く・速く)。

弊社オンパレードだって思った。

「Web API: The Good Parts」を読んだ

Web API: The Good Parts

Web API: The Good Parts

仕事で API は書いてないけど API は使うのでベストプラクティスを知りたい、と思って手に取った。(「えっ!?アプリエンジニアが読んだのにサーバサイドエンジニアが読んでいないだって!? 」という煽りができるのも良い。)
電子書籍版もある ので、そっちを買って mobi を Kindle に送って読んだ。

美しい APIAPI に必要な HTTP メソッドや Status Code の考え方、エンドポイント名、フォーマット、エラー、キャッシュ、HTTPヘッダ、セキュリティなど網羅的に書かれていて、Twitter や FB などで現実に動いている API などが参考にあがってて大変良かった。
と言いつつも本を読む前からすでに理解していたことが多く、どちらかというと自分の考え方は間違っていなかったと自信がついたのが一番良かった。

HATEOAS

以前、会社のパイセンと HATEOAS どうすかね?という話をしたので自分の考えを述べておく。HATEOAS とは詳細は省くが、下記のように json のレスポンスに関連する URL をのせるものである。

   "user": {
    ....
   "links": [{
        "rel": "roles",
        "href": "http://awesomeapi.com/users/1/roles"
      }]
  }

HATEOAS の利点として、「クライアント側が取得したいデータに対しエンドポイントを知らなくて良い」「サーバ側でエンドポイント名を変更できる」があるのかなと思っている。(違ってたらツッコミ入れて欲しい)

  1. クライアント側が取得したいデータに対し URL を知らなくて良い
    • URL は知らないけどレスポンスマッピングはするから、エンドポイントの名称( roles )を元にクライアント側で API を実行する必要がある
    • サーバ側でエンドポイント名を変更されると、クライアント側のソースコードと整合性が取れずに気持ち悪い(クラス名をエンドポイントと同じにしていた場合などズレが生じる)
  2. サーバ側でエンドポイント名を変更できる
    • エンドポイント名を変えるというのはそもそもが破壊的な変更
    • 変えたいなら古いエンドポイントを生かしつつ新しいエンドポイントを作成するべきでは

エンドポイントを知らないで良いというメリットがあまりしっくりこず、私は HATEOAS 否定派である。正直に言うと、HATEOAS を使いこなせずクライアントのコードが煩雑になってしまう気がしている。

オーケストレーション

これはめっちゃ良い。クライアントのエンジニアが、複数の API などを 1 つにまとめたりレスポンス量を調節したりできるようにする仕組み。サーバは細かい API を提供して、クライアントエンジニアがそれを束ねた API を開発できるようにするような感じ。

BFF と近いものを感じていて、細かい調整などをサーバの人にお願いするのもだるいのでこう言うのあるとすごく良い。しかし、これを用意するのは結構な労力がかかるのでコスパは悪そう。
Netflix でやってるらしい。

書いて欲しかったこと

残念なことが2つあって、 JSON Scheme への言及がないことと、クライアントサイドで扱いやすい JSON 形式という視点がなかったこと。

JSON Scheme で仕様を表現するのは賛否あると思うが、そういう方法があるのは述べてて欲しかった。

また、アプリエンジニアからサーバサイドエンジニアへの JSON オブジェクトに関するお願い - Qiita という記事を前に書いたが、レスポンスオブジェクトの形式には気を配って欲しい。


以下、 wikihub 日報 の雑メモ。


読み始めた、1/3 読んだ。 これを読むことで「えっ!?サーバサイド API 実装するのに読んでないんですか?クライアントサイドの人が読んでるのに!?」という煽りができる。

今のところ知ってることが中心、 Rails 書いてたり他のサービスの API 使ってると染み付くようなことが言語化されてる感じ。

  • そのサービスのコアの価値のある部分を全て API として公開し提供しよう。
  • 設計の美しい Web API は使いやすい、変更しやすい、頑強である、恥ずかしくない
  • 仕様が決まっているものは仕様に従い、そうでないものはデファクトスタンダードに従う
    • 他の API 真似たりとかする
  • 美しい URI 設計
    • 短く入力しやすい、人間が読んで理解できる、大文字小文字が混在してない、改造しやすい、サーバ側と切り離されている、ルールが統一
  • POST は新しい情報を登録し、完全に上がいて修正は PUT, 一部修正は PATCH
  • アンダーバーかハイフンで迷ったらとりあえずハイフン

2/3 まできた。明日読み終える。 いい本なんだけど、知っていることばかりという感じ。いままでで API 開発の基礎は身についていたということだろう。

  • Chatty API (おしゃべりなAPI)
    • 1つの作業を完結するために複数回アクセスしないといけない API
  • エンベロープ
  • JSON レスポンスで直下に配列があると JavaScript としても解釈できてしまうので、オブジェクトを返した方が良い
  • JSON はアンダーバーなどではなくキャメルケースが良い
    • レールズがアンダーバーにしちゃうからアンダーバー派だわ…
  • 配列は複数形、それ以外は単数形
  • エラーが配列で変えるのは合理的、複数エラーにも対応できる
    • アプリの場合、配列でエラー返ってきても割と困るんだよなあ
  • メンテナンスは Retry-After でいつ終わるのか示そう
    • 知らなかった
  • Vary ヘッダ
  • Content-Type はちゃんと実装してテストもちゃんとしよう

読み終わった。だいたい知っている内容だったけど、 API 開発マンは絶対に読んでおいた方が良いと思う。 JSON ハイジャックやセキリュティなども述べられていて大変良い、そこらへんおろそかにしがちなので気をつけないと…。

  • 同一性生元ポリシー(Same Origin Policy)
    • 違うhostの API を実行できないやつ、むかしこれでハマった、懐かしい…。
  • クロスオリジンリソース共有(CORS: Cross-Origin ResourceSharing)
    • 異なるhostでアクセスする
  • オーケストレーション
  • HttpOnly 属性は JavaScript などを使ってもアクセスできない
    • WKWebView で Cookie 取得できないのはコレか?

iOS Simulator で壁紙を設定する

実機 iPhone だと 設定 > 壁紙 から壁紙を変更できるが、シミュレータだと壁紙や Wallpaper の変更画面が表示されない。

しかし、写真アプリからなら壁紙設定画面にたどり着ける。
手順としては以下。

  1. Photos(写真) アプリを開く
  2. 壁紙にしたい画像を選ぶ
  3. Action ボタンをタップ
  4. 画面下に選択肢が出てくるので、 Use as Wallpaper を選択
  5. 壁紙を Set !

f:id:star__hoshi:20170507133409g:plain