TypeScriptで関数のthisの型注釈をする

はじめに

vueを使ってTypeScriptに入門しているときに以下の問題にあたった。

forum.vuejs.org stackoverflow.com

そもそもthisの型注釈の機能を知らなかったので、公式ドキュメントを読みながらthisの型注釈についてインプットすることにした。

• 型注釈によって関数のthisの型を指定することができる
• thisの型注釈が必要なケース

型注釈によって関数のthisの型を指定することができる

Functions · TypeScript

以下のようなコードを考える。

class C1 {
  name: string;
  constructor(name: string) {
    this.name = name;
  }
  say() {
    console.log(this.name)
  }
}

say メソッドの中で呼ばれているthis の型はthisになり、C1 のサブクラスでも辻褄が合うような扱いになる。 ただし、以下のような形でthis の型を明示することができる。

class C1 {
  // ...
  say(this: C1) {
    console.log(this.name)
  }
}

C1 を指定した場合は挙動は問題なさそうだが、void などを指定するとコンパイルエラーになる。 なぜこのような機能があるのか。

thisの型注釈が必要なケース

noImplicitThisを有効にしている場合に必要になることがある。 以下のようなコードを考える。

const execCallback = (fn: () => void) => {
  fn()
}

class C1 {
  name: string;
  constructor(name: string) {
    this.name = name;
  }
  say() {
    execCallback(function() { console.log(this.name) })
  }
}

say メソッドの中で console.log(this.name) を呼ぶ関数を execCallback に渡しているが、関数式で定義した関数のthisは実行時に決まるため、sayメソッド内で見ているthisはany型になってしまう。結果としてnoImplicitThisに引っかかるのである。警告を外す方法としてはsayメソッドの中のfunction() { ... }をfunction(this: any) { ... }とすれば警告を解除できるが、残念ながら実行時に落ちてしまう。。。結局 function は使わず。アロー関数を使うのが今回の正解だ。

ただしアロー関数を使えないケースもある。「はじめに」の中で書いたvueのmethod内で _.debounce を使う例がわかりやすい。（この例もアロー関数を使えるのかもしれない。） vueのforumにもあるように、このケースは妥協してanyを使うのも良さそうだ。

まとめ

TypeScriptに入門していたところ早速本に出ていない内容が出てきたが、ちゃんとvueのforumやstackoverflow、そして何より公式ドキュメントにthisの型注釈について書いてあったのが良かった。

私の考えるスーパーエンジニア

はじめに

これはポエムです。自分が目指すエンジニアとはなんなのか向き合いたいと思い書いてみました。殴り書きです。

スーパーエンジニアの振る舞い

• スーパーエンジニアは誰よりも早くリリースができる。機能のヒアリング、要件定義、設計、開発などひっくるめて誰よりも早い。
• スーパーエンジニアはプロダクトを作るための技術を知っている。インフラ、DB、サーバサイド、フロントエンド、モバイルを、完全なできではないものの一通り一人で作ることができる。
• スーパーエンジニアはビジネスサイドの人間と会話できる。作りたいものを一緒に考えられる。
• スーパーエンジニアはネガティブでない。常に自分の力で状況を前に進められる。
• スーパーエンジニアは最新技術をキャッチアップしている。枯れた技術と最新技術の選定のバランスが良い。
• スーパーエンジニアは適切な設計ができる。場合によってそれなりな設計ができる。変な設計や必要以上に凝った設計をしない。
• スーパーエンジニアは体力がある。いざというときにハードワークできる。
• スーパーエンジニアは家族を大切にする。それによって自分が仕事に集中できる状況を作ることができる。
• スーパーエンジニアは人に仕事を任せることができる。人を信頼し、エンパワーし、適切なフィードバックを与える事ができる。
• スーパーエンジニアは問題解決をする。やり方は問わない。

参考

自分の尊敬するエンジニアの振る舞いを元に、以下の記事をみながら書きました。

medium.com

soudai.hatenablog.com

まとめ

スーパーエンジニアになるため、１歩１歩進んでいきたい。

ブログ名変更&https対応した

内容

長らく迷っていたブログ名を「ITの勉強をいろいろやってみたブログ」から「blog.waterlow.work」に変更しました。
はじめは資格試験の勉強などをアウトプットしていく予定でしたが、2014年転職したりなんやかんやで方向性が変わりました。
それから長らく名前は放置していましたが、この度思い切って。 ブログ名はurlっぽいけど、叩いても何も出ません。

（https://waterlow.work/ は今はHetlifyでGatsbyをうごかしてます。）

ついでにurlをhttps化しました。混在コンテンツも全部https対応or削除しました。

最近いろいろもんもんとかんがえていることがあって、いろいろ吐き出していきたい。

今年触った技術

はじめに

もう10月末となり、今年触ってきた技術を列挙してみようと思います。
結論言うと、思った以上にいろいろ触ってきたものの、あんまり身になっている実感がないという感想。
基本的に趣味で、本番投入はしていません。
（普段のおしごとではrailsのサーバサイドを担当しています。）

インフラ編

docker, Kubernetes

railsをk8s化しました。特にこれといったことはありません。。。社内勉強会と自宅学習を合わせるとかなりの時間触っていると思う。

GitHub - waterlow/docker_sandbox_qdqgrstwtz

ミドルウェア編

opencv

名刺サービスに携わっていて、多少なりとも画像処理ができるようになりたいと思ったため。
docker向けにコンパイルするのがひたすら難しく、結局挫折してしまいました。。。
vpsのcentosでpython(flusk)画像の矩形を切り取るサーバーを書くところまで。

GitHub - waterlow/opencv-sandbox

mongo, spark

「ビッグデータを支える技術」の本の中でバックエンドとして扱われており、dotinstallをやってからsparkをさわりだけつかってみました

PAAS編

Netlify

技術書店で本を買っていろいろやってみました。かなり高機能。
NetlifyCMS、hosting、CIを試しました。

Firebase

主にfirestoreとfunctionを触っています。railsに続く自分の武器になる予定。予定。 firestoreの設計（というかNoSQL）にはRDBとまたちがった感覚があり、苦戦中。

AWS Lambda

cloud watch eventと合わせるとcronをサーバレスで実現できるということで、試してみた。 serverless frameworkでやろうとしたけど、functionだけ書いてcronは手で入れちゃっている。

GitHub - waterlow/cron-job

ssh接続を許可するipリストの管理をするのにも使用。
slackからのwebhookを受けられるようにAPI Gatewayと連携している。

IFTTT

これは含めていいのかわからないけど、会社の勤怠を自動化するために、GPSで会社の出勤退勤をspreadsheetに記録するために使用。

Amazon Athena

友達にデータ分析を試してみたいと相談され、まず一番手軽なところからということで使ってみる。
都道府県ごとの郵便番号のデータをzipのままS3において、そこに対してSQLで集計をかけられるという体験はすごい。
後述のredashにも接続できる。

インストール系

redash

データ分析の文脈で、athenaのデータをビジュアライズ。docker化したい。

wordpress

友人の相談でメディアサイトを作りたいと言われ、ちょっとだけ触ってみる。
docker-composeで立ち上げられるようにしてみた。 webアプリとセッション共有をしたいと言われるも、php詳しくなく断念。。。

フロントエンド編

mobx

reactの状態管理のライブラリ。reduxよりもライトに使えるというか、ルールがきつくない。 reduxのサイトにあったtodoをmobx& firebaseで作ってみた。

GitHub - waterlow/mobx-todo

vue

rebuild.fmのshownoteをフィルタリングするwebアプリをvue2系&webpackerで書き直した。

GitHub - waterlow/rebuild-search

nuxt

勉強中。firebaseと合わせてtwitterみたいなものを作っている。まだ理解できていない。

GitHub - waterlow/nuxt-sandbox

gatsby

Netlify文脈でさわってみた。とりあえずデプロイしてみた程度。

JAMStack

Javascript、API、Markupの略
SSRするHTMLを先に生成してCDNに乗せておけば、SSRより爆速になるという考え方。
技術的にはあまり触っていないものの技術書典の本は1冊読んだ。

ReactNative

WEBDBに載っていたお天気アプリをつくってみた。
（やったと言えるのか。。。）

まとめ

いろいろやりすぎ！！！と思った。
深掘りというか、ちゃんと手に馴染むところまで持っていけてないのが残念。
nuxt, firebase, redashあたりは手に馴染むところまで持っていきたい。

OKR本を読んだ

はじめに

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKRの本を会社から支給されました。大事なことは原典を読んでいただくのが良いですが、気になったところを書いてみます。

スタートアップでもミッションを掲げるべき

どんなに夢のあるようなビジネスでも、マネタイズしなければ意味がないというのが自分の考えでした。しかし「お金がほしいなら、ウォール街のコンサルティング企業に入社するほうが遥かに安全だ。」という言葉をみてなるほどとおもいました。マネタイズは大事だけど、同じくらいミッションというか使命みたいなものが大事だと思います。

自信度の変化のトラック

今の会社でもOKRを取り入れていますが、自信度の変化をトラックしていません。はじめは50%でも自信度は刻々と変化していくため、OKRを振り返るためにも自信度の変化は重要であると考えました。

健康、健全性

これは、「利益に走りすぎて、エンゲージメントを失う」とか「締切を守るあまり、メンテナンス性の低いコードをリリースしてしまう」といった状況への抑止になると感じました。KRを達成さえすればそれでいいというような状況はなくなりそうです。

まとめ

OKRについて、まだまだ知らないことがあるなということと、これを遂行するにはメンバーのメンタリティも重要のように思いました。 あと、これとは別に「仕事はたのしいかね？」という本も読んでいてうーーーんという感じでした。

そもそもRailsでカスタム例外を定義すべき機会は少ない

はじめに

今仕事でRailsアプリケーションの運用をやっているのですが、いろいろなところで例外が定義されていて「これ必要なくね…」となんとなく思ったことが多々ありました。 しかし、effective rubyには「raiseにはただの文字列ではなくカスタム例外を渡そう」という章もあり、この違いはなんだろうと思いました。 なんでそう思ったのか整理して、今後自分のプログラミングに生かして行こうと思います。まとめると以下になります。

• カスタム例外を自分でraiseしてrescueするな。戻り値で判断しろ。

よく見るコード

Resourceモデル

class Resource
  Error = Class.new(StandardError)
  def write
    # 何かの処理
    result = false # 何かの処理の結果falseだったと仮定
    raise Error, '保存時にエラーが発生しました。'
  end
end

Resourcesコントローラ

class ResourcesController < ApplicationController
  def create
    Resource.new.write
    redirect_to '/', flash: { notice: '作成されました' }
  rescue Resource::Error => e
    redirect_to '/', flash: { error: e.message }
  end
end

よく見るコードがあまり良くない理由

• 処理の成功失敗を例外で返すようにすると、使いたいところで毎回例外処理を書かないといけないといけない。
• モデル側での処理が複雑になった場合に、大きい範囲をrescueする形になる。
• railsでは習慣的に、例外ではなく戻り値で判断する。
• 詳細はjnchitoさんの記事がわかりやすいです。
  • プロを目指す人のための例外処理（再）入門 / #rubykansai 2018-01-13 - Speaker Deck
  • Railsアプリケーションにおけるエラー処理（例外設計）の考え方

汎用性も可読性も低い。一般的でもないということですね…。

どうすればいいか

Resourceモデル

class Resource
  def write
    # 何かの処理
    false # 何かの処理の結果falseだったと仮定
  end
end

Resourcesコントローラ

class ResourcesController < ApplicationController
  def create
    if Resource.new.write
      redirect_to '/', flash: { notice: '作成されました' }
    else
      redirect_to '/', flash: { error: '作成されませんでした' }
    end
  end
end

カスタム例外は必要なくなりましたし、表示用のメッセージがモデルに縛られなくなりました。

結局カスタム例外は必要ないの？

必要ないとは言いませんが、単体のRailsアプリケーションを書いている場合、自分でraiseしようとしている例外はそもそもシステムエラーではなく業務エラー（日常的におこりうる）であることが多いように思いました。 もしそれがシステムエラーならば、rescueして握りつぶしては検知できないですし、そうなるとrescueしないんだからカスタム例外ではなくてもいいよねという話になると思い、最終的に独自例外いらないよねということになるんじゃないかなと思います。。。

gemなど不特定多数の人が使うものに関しては積極的に定義していくべきだと思います。gemから返ってくる例外がRuntimeErrorだとつらいですしね。

まとめ

やっぱりRailsでカスタム例外を定義すべき機会は少ないし、少なくとも自分はめったにやらないかなと思いました。

プロジェクトの立ち上げ時に入れてよかった/入れなくてもよかったgem

はじめに

ここ最近趣味でrailsアプリを複数人で開発しています。
自分以外Railsは初心者 で、rails newしてgemを入れてDB初期設計やってはじめのコントローラ（API）をつくるまで位を自分でやったのですが、その後入れてよかった/入れなくてもよかったと思うgemがあり、多少は他の人や未来の自分にも役立つだろうということで書き留めます。

入れてよかった

onkcop(rubocop)

コーディングスタイルについて揉めたり、議論したりすることがなかった。
自分が設定して満足できた。

bootstrap

本デザインが当たっていないサンプルの状態でも、まあまあいい感じに見せられる。素のHTMLを見ることによるテンションの落ちがない。

gimei

後述するseed-fuでのサンプルデータ作成に役立った。

ridgepole

migrationファイルの記法がほとんど使えるため学習コストが低かった。ちょこちょこスキーマを修正するのにいちいちmigrationを作らなくてよかった。（古いmigrationファイルを直せばいいというのもあるけど、ほんの少し罪悪感がある。）

seed-fu

サンプルデータをはじめに整備しておくことで、いろいろイメージが付きやすかったり、たたき台にできたり。

shrine

本番ではS3を使うのだが、developmentではローカルにファイルを置くとか実装を切り替えれたのが便利。初めてつかったけど carrierwave をちゃんと使ったことがあればある程度は動かせた。 他の人を見ていると学習コストは高めだった。

capistrano-*

よくわからんままとりあえずgit pullでデプロイとかしなくてよかった。快適

入れなくても良かった

active_model_serializers

これを使いこなすためには きれいなAPI設計 がおそらく必要なのだけど、それがネックだった。 APIが汚いとserializerも汚くなる。 controllerでの手動よびだしとかするといまいち。 jbuilderや、素のhashを返すpure rubyのクラスを作って自前でas_jsonをしていくほうが、コスト低くある程度の規約ができてよかったかもしれない。

devise

自分が知っていたので立ち上がりは早かった。ただ、自分が入れてjwtなどの設定もしたので、自分が全部面倒見る感じになってしまった。 管理画面には積極的に使えばいいとおもう。

rspec

実際は「テスト各時間を取れなかった」という感じになる。作るものもよくわからないし、教える時間が満足に取れない状況ではどうしてもテストは後回しになってしまった。

まとめ

すべて学習コストとリターンのバランスかなという感じがしました！