Mac の環境構築手順を整備した

今までも dotfiles と Brewfile を Github に置いて環境構築手順を整えていたが、 dotfiles は homesick、 Brewfile は homebrew-file というのを使っていたため管理がややこしくなっていた。

しかもそれらは全然 commit してなくて古くなってしまったため、エイヤで色々整えることにした。

Brewfile

homebrew-file を使うのはやめ、素の Brewfile を Github で管理するようにした。
下記コマンドで Brewfile を吐き出すことができる。

$ brew bundle dump --force

次回 brew のセットアップをするときは下記コマンドでいける、はず(試してないので本当にいけるかわからない…)。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ git clone git@github.com:starhoshi/Brewfile.git
$ brew tap Homebrew/bundle
$ brew bundle --file=Brewfile/Brewfile

dotfiles

必要な設定ファイルをレポジトリ管理するようにした。karabiner, hammerspoon の設定ファイルは実際には dotfile ではないかもしれないが、難しいことを考えるのはやめた。

これらの設定ファイルは↓のコマンドで install できる、はず。
zsh がすでに install されているのが前提なので、 brew の後に実行する必要がある。

$ git clone git@github.com:starhoshi/dotfiles.git
$ ./dotfiles/install.sh

dotfiles の設定では Deploy と Initialize を分けろとあるが「そこまでガチ勢じゃないしこのままでいいか」と思い, install.sh すればいい感じになるようにした。

まとめると

次回のセットアップでは、

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ git clone git@github.com:starhoshi/Brewfile.git
$ brew tap Homebrew/bundle
$ brew bundle --file=Brewfile/Brewfile
$ git clone git@github.com:starhoshi/dotfiles.git
$ ./dotfiles/install.sh

これで環境が整うようになった。

レポジトリ

参考

Swift2 から Swift3 への移行がだるすぎて諦めた

1年前くらいにリリースしたアプリ があるのだが、動かなくなったというレビューがきたので修正しようと思ったのだがだるすぎる。
何がだるいかというと、 Swift3への対応が一番だるい。ライブラリを更新して、マイグレーションして… ってやらないといけないけど、そもそもライブラリがSwift3対応してなくて諦めた。

だるさ

  • Swift3移行がだるい
  • Swift3対応していないライブラリがある
  • xml, html の parse がだるい
  • 過去の自分のコードがイケてなくて読むのがだるい
  • 利用者があまり多くないので作り直してもメリットが小さい
    • レビューで「動かなくなってつらい」ってきたので利用者はいる

結局

Xcode 7.2.1 をダウンロードして、Swift2 で修正することにした。
いつまでも Xcode7 で修正できるわけではないし、Swift3の移行はだるすぎるし、そのうちこのアプリは死ぬだろう。

悲しいが、 Apple 様の進化に追従できなかった者の末路である。しょうがない。

英語の五文型

中学・高校6年間の英語をこの1冊でざっと復習する

中学・高校6年間の英語をこの1冊でざっと復習する

本を読んで英語の勉強を始めた。英語めっちゃ苦手なので、とりあえず中学英語から学び直している。

1章は五文型なんだけど今まで雰囲気でやっていたので全く理解できていなかったし、本読んでもあまり理解できていない。
なので思考の整理も兼ねてまとめてみる。

本の例文など引用しているが、引用しすぎな気もする。問題があれば消します。

文型

S, V, O, C らへんのはなし。

第2文型

S + V + C (主語 + 動詞 + 補語)。

  • である(be動詞)
    • He is a singer.
  • になる(become, get など)
    • She became a doctor.
  • のように見える[聞こえる、感じる などの五感が中心]
    • She looks young.
  • の(状態の)ままである
    • I kept quiet.

第5文型

S + V + O + C (主語 + 動詞 + 目的語 + 補語)。
目的語と補語の間に「主語 + 述語動詞」の関係がある。目的語と補語の間に be 動詞を入れてみて意味が通れば良い。

  • 〜を…にする
    • He made me happy
  • 〜を…と呼ぶ
    • He calls me Micky.
  • 〜に…するよう要求する
    • I want you to go there.
  • 〜を…にしておく
    • Keep your room clean.
  • 〜が…だと思う
  • 〜を[に]…させる(使役動詞)
    • You made me happy.
  • 〜が…するのを見る[聞く、感じる]
    • I saw him walking.

第3文型

S + V + O (主語 + 動詞 + 目的語)。

補語 / 目的語

補語は He is a student. のように、 He と student がイコールで結べる。
目的語は He wrote a letter. のように、 He と letter はイコールで結べない。

自動詞 / 他動詞

目的語は動詞の動作の影響を受ける語。
他動詞は目的語が必要で、自動詞は目的語が不要。
I went. だと「私は行った」で意味わかるが、 I play. だと「私はした」で訳がわからんので I play baseball. など目的語が必要。

第4文型

S + V + O + O (主語 + 動詞 + 関節目的語 + 直接目的語)。
第4文型の順番を入れ替えると第3文系にすることができる。
とりあえず O + O は 人 + 物 というふうに覚えておくのが良さそう。

I’ll give you a pencil. -> I’ll give a pencil to you.

第1文型

S + V (主語 + 動詞)。
第一文型 にあるように、完全自動詞のみのは少ない。

There is ~ . は S が後ろに来たりする。

古い iOS アプリが Apple に削除された

www.itmedia.co.jp

これの対象になったようで、4年くらい前にリリースしたけど全くアップデートしていなかったアプリが削除された。

削除されたアプリは Anison Tube というやつで、AppStore ではもう見れなくなっている。

作ったアプリがアプリストアに14個並んでるんですよ〜って言ってたけど、13個になってしまった。

削除されるまでの流れ

2017年5月6日

Your app, Anison Tube (733552119), does not comply with one or more App Review Guidelines.

For details, or to directly contact the App Review team, go to the Resolution Center on iTunes Connect.

というメールが届く。

ああ、ついに自分のアプリも粛清対象になったのだなと感慨深い思いになる。

Apple に抗議をするかアプリを更新するかが必要のようだ。しかしこのアプリは動かないと言っても過言ではないし、まあ消えてもしょうがないという思いだったので放置した。

2017年6月10日

前回のメールから1ヶ月とちょっと後に、削除に関する2通のメールが届いた。

1通目

削除したよって内容。

Your app, Anison Tube (733552119), has been removed from the App Store due to an unresolved issue.

2通目

アプリのステータスが変更されたという内容で、これはよく見るメール。

The status for the following app has changed to Removed From Sale.

App Name: Anison Tube
App Version Number: 1.0
App SKU: com.anisontube
App Apple ID:733552119

iTunes Connect

iTunes Connect の該当アプリを見ると、 ストアから削除済み というステータスになっている。なんとかしてステータス変えようと思ったが無理そう。再度アプリをストアに出したいときは新しいバージョンを出すしかない。

価格および配信状況 > 配信可否は「すべてのテリトリで配信可能」になっているので、ここをいじってもダメだった。

どんどんやってくれ

自分が開発したアプリがストアから消されるのは悲しいことなんだけど、ユーザから見たらノイズでしかないようなアプリが消えていくのはいいことである。

Apple はどんどんやっていってほしい。

寂しさ

しかし 32bit アプリも消えていくのだろうな、と思うとちょっと悲しい。
web だと00年代のサイトとかまだ全然動いてるし、そういうサイト見ると懐かしさが込み上げてくる。ネイティブアプリはプラットフォーム依存だししょうがないけど、やっぱり悲しい。

血便がでた

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

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 取得できないのはコレか?