ぺい

渋谷系アドテクエンジニアの落書き

半年間の社会人生活で学んだこと

社会で生きてみた

VOYAGE GROUP、Zucksでの社会人の半年を振り返りをしてみた。

技術

がっつりとか、少しとか色々あるけど、本当たくさん経験が出来た。

  • Go
  • Scala
  • Lisp
  • PHP
  • Python
  • BigQuery
  • HTML
  • CSS
  • JS
    • React
    • Angular
    • Vue
  • AWS
    • Lambda
    • EC2
    • Batch
    • ECS
    • Fargate
    • S3
    • Dynamo
    • なんかもう色々
  • CI
    • CircleCI
    • Jenkins
  • Packer
  • Docker
  • Vagrant
  • なんか色々あった気がする

経験したこと

  • リリース作業
  • リバート作業
  • 設計
  • コーディング
  • ヒアリング
  • レビュー
  • ミーティング

配属当初は本当に色々あった

  • うまくコミュニケーションが取れずに手間取る
  • 設計の掘り下げが甘くて手戻り
  • リリース作業心労し過ぎて腹痛
  • 諸問題で何回もリバートしたりした
  • 体調バグりがち
  • リリース作業中エラー起きたらパニクる
  • 周りが優秀過ぎて、自分の意見に自信が持てない

変わったこと

  • リリース前に最悪のケースを想定する
  • コードを書く前に具体的な設計を練って、相談をして手戻りなくす
  • 結果を出すことに執着し過ぎず、多少時間かかっても、確実に終わらせることに集中する
  • しんどい時は、帰る
  • 起きた時にしんどい時は、諦めて寝る
  • 家で勉強する習慣をやめた(本当に必要だと思うものだけ勉強する)
  • 人が言ったことを鵜呑みせず、本当か?って姿勢で議論する
  • 頑張ってるという感覚までやるのをやめた(自分の場合、やりすぎになっている)

残りの半年間やっていきたいこと

いつも、最高のパフォーマンスで業務に臨める時間を作れるように、良い感じに生活する。

「するべき」というパワーワード

あまり強い言葉を遣うなよ

tikasan.hatenablog.com

以前アップした記事にあった「するべきこと」に対してのコメント @ 弊社Slackの個人チャンネル

f:id:tikasan0804:20181006135912p:plain

自分はあまり気にせず使ってしまっていたので、何故だろう?を考えてみた。

Abuse of “should“ or “shouldn’t” e.g. We shouldn’t have interruptions…”

参考資料として貼ってもらった記事を雑に翻訳。

medium.com

「するべき」または「すべきではない」の濫用。 例えば、我々は中断してはならない... 。

中身がなく意味がないレトリック。
「私達は皆、豊かでなければならない。」
「本当に?私達はより良い新しい車を持ってる必要がありますか?」

実は、私達が”すべき”を使う時、目の前の現実を受け入れていません。実際にシステムを見ていません。スタートが基本的な透明性が失われいる場合、どのようにして、効果的な変化を望むことが出来ますか?

”すべき”はいまの既存バージョンの理想郷の説明することが出来ます。それは私達が目指している場所の表現として良いかもしれません。Kataのアプローチは、”すべき”というシチュエーションを打ち消し、コーチングするのに有効なテクニックです。

Abuse of “should“ or “shouldn’t” e.g. We shouldn’t have interruptions…”

More empty rhetoric. We should all be rich, am I right? We should all have better, newer cars, ya get me?

The thing is, when we use the word ‘should’ we are not accepting the reality in front of our faces. We are not seeing the system as it really is. If our starting point lacks this basic transparency, how can we ever hope to be effective change agents?

‘Should’ can describes a utopian version of an existing scenario. That might be a good expression of where we want to get to. The kata approach can be a good technique to counter and coach these ‘should’ situations.

Kataとは、日本のTOYOTAの行っている型というアプローチのことらしいです。
わかりやすい記事があったので紹介させていただきます。

radiocat.hatenablog.com

  • 問題を取り上げる
    優先度の高い問題を見つける
  • 状況把握(行って見る)
    問題の発生点を見つけても台を明確にする…問題の発生点を見るけるまでは対策に入らない
  • 原因を調査
    5回の「なぜ」を行う
  • 対策をつくり試験する
    一度に1つしか変えない
  • フォローアップ
    ふりかえり

”すべき”というワードを使うことで安心をしていた

色々読んでわかったのが、すべきと言っておけば、それっぽいことしてる風に聞こえる。それが中身のないことだったとしても強いワードはパワーを持ってしまう。”すべき”はすぐに使わずに、実際に問題を直視し、見たものから状況から判断する。そうすることで、勝手にやったほうが良さそうなことが見えてくる。

”すべき” を使いすぎ。だめ絶対!

AWS Batch/ECS/ECR/Fargateについて調べた

コンテナコンテナコンテナ

業務でバッチ処理の一部をECS、AWS batchに移行しようぜって話になり。ついでに、Fargateやってみようぜってなったので、調べたことをメモがてらに記事にした。

コンテナ化について

Dockerfileでコンテナの定義書いて、ローカルで動かしたりするあれ

ECS

Amazon Elastic Container Service とは - Amazon Elastic Container Service

Amazon Elastic Container Service (Amazon ECS) は、クラスターで Docker コンテナを簡単に実行、停止、管理できる非常にスケーラブルで高速なコンテナ管理サービスです。Amazon ECS が管理するサーバーレスインフラストラクチャにクラスターをホストするには、Fargate 起動タイプを使用してサービスまたはタスクを起動します。また、EC2 起動タイプを使用して、現在管理している Amazon Elastic Compute Cloud (Amazon EC2) インスタンスクラスターにタスクをホストすることで、さらに強力な統制力を得ることができます。起動タイプの詳細については、「Amazon ECS 起動タイプ」を参照してください。

これを読む限り、ECSは実行可能なDockerfileさえ作れば、それをいい感じに実行出来る環境を提供してくれているものという感じ。
そのECSの実行環境、つまりインフラについては、FargateやEC2を使うということ。

EC2とFargateの違い

  • ECS on EC2 インフラレイヤーを考える必要がある。コントロールが出来るとも言えそう。
  • ECS on Fargate インフラレイヤーのこと考えなくて良い。

EC2上でやるより、Fargateのが若干コストが高い。
まあ、ただ、運用コストの人件費を考えたら、安いとも言える。

【AWS】AWS Fargateの利用料金を試算した #reinvent | Developers.IO

ECR

Amazon Elastic Container Registry とは - Amazon ECR

Amazon Elastic Container Registry (Amazon ECR) は、安全性と信頼性が高いスケーラブルな AWS Docker レジストリサービスです。Amazon ECR では、AWS IAM を使用してプライベート Docker リポジトリにリソースベースのアクセス権限が付与されるため、特定のユーザーまたは Amazon EC2 インスタンスからリポジトリとイメージにアクセスできるようになります。開発者は、Docker CLI を使用してイメージをプッシュ、プル、および管理できます。

AWSのコンテナを使ったサービスに使うイメージを管理してくれてるものがあるので、デプロイはここにする。身近なものでいうと、DockerHub。

AWS batchとは

AWS Batch とは? - AWS Batch

AWS Batch を使用すると、AWS クラウドでバッチコンピューティングワークロードを実行できます。バッチコンピューティングは、開発者、科学者、エンジニアが大量のコンピューティングリソースにアクセスするための一般的な方法です。AWS Batch は、従来のバッチコンピューティングソフトウェアと同様に、必要なインフラストラクチャの設定および管理に伴う、差別化につながらない力仕事を排除します。このサービスでは、送信されたジョブに応じてリソースを効率的にプロビジョニングし、キャパシティー制限の排除、コンピューティングコストの削減、および結果の迅速な提供を行うことができます。

AWS Batch は、リージョン内の複数のアベイラビリティーゾーン間で実行中のバッチジョブを簡略化するリージョナルサービスです。新規または既存の VPC 内に AWS Batch コンピューティング環境を作成できます。コンピューティング環境が稼働し、ジョブキューに関連付けられた後で、ジョブを実行する Docker コンテナイメージを指定するジョブ定義を指定できます。コンテナのイメージは、コンテナレジストリに保存され引き出されます。これは AWS インフラストラクチャの内にある場合も外にある場合もあります。

作成したコンテナイメージを使ってジョブを作成することが出来る。便利そう。
そして、今回やりたいのはバッチ処理は、CloudWatch EventでAWS Batchのジョブを定期実行するといった感じで、実現することが出来ます。

設定するものとしては

  • コンピューティング環境 どういう環境で動かす? Fargate?EC2?
  • ジョブキュー ジョブに依存関係つけたりしつつ、ジョブを投入できる
  • ジョブ定義 ECSタスクみたいな感じ

まとめ

  • GitHubなどにコードを上げておく
  • CIでコードからイメージを作成して、ECRへアップする
  • AWS Batchでジョブとして定義して、なにかをトリガーに実行する ※この時にどこで動かすか決める ECS on EC2 or Fargate

出来るエンジニアはサボる

ここ最近、実装するが人並みに出来るようになってきた。そして、いまはミニマムを作るを考えることに非常に悩まされることが多い。

どんな開発現場での文脈か

株式会社Zucksのエンジニアは、ビジネスサイドからやりたい雰囲気、またはやりたいお気持ちを感じ取って、それについてヒアリングして、どうやって作るか、そもそも作るか?というところから考え、最終的にはリリースからその後の保守まで面倒を見るというのが、普段の業務内容になります。とりあえず、実装っていうのは、この工程全体を指しています。

油断していると人間は作りすぎる

入社当初は、考慮すべきことが考慮されていないが、主な課題で、いまは、色々考慮しすぎて、設計がファットになりがち。本当に油断していると、考慮すべきでないことまで考えてしまう。
ただ、自分の場合、設計->相談->コーディングという手順を必ず踏んでいるので、ファット仕様は設計段階で指摘されるので、出来上がったものが、大ゴケするということは起きていないのが、不幸中の幸いという感じ。

出来るエンジニアはサボるのがうまい

悪いように聞こえるかもしれないけど、僕が思う出来るエンジニアは「サボる」のが非常にうまい。どうやったらそんな発想が出来るんだってくらいうまくサボる。ここで重要なのは、ただサボるのではなく、色々考慮した上で、サボるという点。最小限で作って、価値を作る。もし、問題が起きたら?は想定済みといった感じ。

やるべきことと、あったらいいよねを切り分ける。

早くサボれるようになりたい。

そして、するべきとかって問題じゃなかった問題。 tikasan.hatenablog.com

エッセンシャル思考 最少の時間で成果を最大にする を読んだけど、めちゃくちゃ良かった

とりあえず、読んでほしい

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

勤務先の同チームの先輩が読んでいたのをきっかけに、ポチってみたのですが、冗談抜きでめちゃくちゃ良かった。
この本の内容は、自分の中に留めておきたいことも非常に多かったので、今回わざわざ記事にしてみました。

この本を読むことで得られること

  • 本当に重要なことは何か?(家族や仕事、自分自身について)
  • 最も注力するべきことに注力するためには、どうすれば良い?

などが、色々な著名人の話を入れつつ、詳しく解説されています。自分の人生をどう過ごすか?について、考えさせられる内容となっています。

立ち止まって多くの選択肢を考えるが、本質的なものだけをやる

私達は、仕事をする上で、様々な課題に直面します。しかし、自分という人間は一人、やれる仕事の量には限界があります。全部やろうというのはやめる。何をいまやるべきなのか?それは本当に必要なのか?必要であれば、どうやってやるべき?どこまで?をしっかり考え抜く。必要そう、というものは切り捨て、本当にいま必要なことに注力し、最大の成果を出す。

全部をやると全てが中途半端になるし、思考を巡らせる暇がないので気持ちが忙しくなる

色々な仕事が飛んできて、それらを全て真っ向から受け止め続けると、「忙しい」が仕事を埋め尽くし、工夫をする余地がなくなる。これは本当に必要なことか?を考え、必要でなければ切り捨てる。

何事にもトレードオフが存在する。全部はやれない。何をやるべきかを考えて何かを捨てる

二兎追う者は一兎も得ず。仕事でも同じ。

遊びを作ることは不可欠。ストレス軽減にもなり、仕事も創造的になる

休日は徹底的に遊ぶ。休む。そして、業務時間中を最高に集中する。少し遊ぶくらいが、仕事に対するモチベーションを上げてくれる。

仕事ができる自信があるなら、目の前のチャンスを断って昼寝する勇気を持つ

これ以上、仕事を請け負うことは出来ないけど、大きなチャンスが目の前にあったとしましょう。もし、自分に本当に仕事が出来る自信があるなら、思い切って断って、休む勇気を持つ。そして、しっかり休息を取る。そして、本当に掴むべきチャンスを掴む。

睡眠は仕事の効率を高めてくれる

私達人間は、大半が1日8時間程度の睡眠取る必要があります(一定数ショートスリーパーという人達も存在しますが)。睡眠を取らずに仕事をすれば、成果を出せるというのはほとんど間違いで、望ましいのは、眠たい時にしっかり寝ることで、常に高い生産性を保つことができ、最終的には長く眠っている人の方が成果を出す。(ちなみに、寝不足は酔っ払いと同じくらい酷い状態らしい)

これだ!というもの以外はノーとする。90点ルール

様々な選択肢がある中で、「なんか必要そう」などで、採用するのはやめよう。そんなことでは、いつまでも本質に注力が出来ない。「これだ!」だけを選択することが、高い成果を出し続けることが出来る。(採用でも同じという話があった)

目的は完全に明確でなければ、人を動かすことは出来ない

目的が明確であれば、チームが向いている力の先も同じになり、大きな力を生む。逆に不明確な目的は勘違いやトラブルしか産まない。

達成が明確でないと、評価が出来ない

何を持って達成とするか?が分からないと、結果が評価出来ない。いま目標に近づいているのか、遠のいているのかが明確に見えることは、次の施策を考える上でも重要。

何をしたいの?が確定していないと意思決定が出来ない

結局、いま何がしたいのか?を明確にしなければ、強い自信を持って意思決定が出来ない。

ノーは上手に、きっぱり断る

やりたくないこと、出来ないことは、きっぱりと断る。中途半端に断ると相手に変な期待をもたせてしまうし、断るべき時に頼みを受けてしまうと、成果を出せずに相手の期待も裏切ってしまったり、自分の本来やるべきことに集中出来なかったりとお互い良いことがありません。断ったら嫌な気持ちになるかもしれないと思うなら、上手に断ろう。(別の提案投げてみるとか、適した人材紹介するとか色々ある)

やめるかやめないかを考える時は、1円も払ってない時でも、投資をするだろうか?で考える

何かに投資をしたり、何かを買った後に、失敗だったかもしれないと気づく時があります。しかし、人間は一度所有したものを手放すのが苦手な生物です。また、投資などはいつか成果が出るかもしれないと、どれだけ望みが薄いことでも、夢見がちです。そんな時は、一度、0ベースで考える。もし、同じものをもう一度買うタイミングがあったら、本当に買うだろうか?と、その時に買わないものは、恐らくさっさと手放すべきものです。

失敗は認めることで過去のものになる

あの時、失敗だったかもしれないと考えている間は、永遠に頭にそれが残り、集中を邪魔します。失敗はさっさと認めて、次に進もう。

やめてみたいことは、試しにやめてみる逆プロトタイプをすればハッキリする

何でこれやってんだろう?という疑問のある仕事や手続き。試しにやめてみる。本当に必要なら誰かが困り、催促が来るはず。

業務は複雑性は上がり続けるので、減らすことも大事

あることがきっかけで、ルールが増えたり、業務の工程が増えることがあります。それとは逆に必要でなくなったものは、減らすことも継続して行い。本当に必要なものだけを残す。

仕組み化することで、健全な状態を無意識に維持する

健康に過ごすためには、日々の努力が欠かせません。そういった努力は場当たり的に行うのではなく、毎日行うことが重要です。最終的には習慣化することで、健康を習慣にすることが出来る。

常に最悪のケースを想定する。そうしておけば、不測な事態も難なく越えられる。そのためには準備と計画には全力を注ぐ

なんとかなる。ではなく、どういう最悪がありえるのか?を想定することは大事。何かが起きたからでは遅いし、その対応にたくさんの労力を割くくらいなら、最初から計画を練って備えよう。

いま、この瞬間で最も重要なことに注力する。過去と未来は想像の中でしかない

私達の人生において、重要なことは、「いま」であり、過去や未来は想像の中にしか無い。いまこの瞬間に最も重要なことは何か?を考え行動することを続ける。

まとめ

上の箇条書きでは紹介はしませんでしたが、この本では、仕事のことも勿論ですが、家族とどう接するべきか?というトピックを要所々々で取り上げられていて、その度に、家族以上に重要なものはないという話が出てきます。娘の誕生日と重要な商談の日が被ったら〜とか、嫁さんとの時間の過ごし方とか、今後の家族との接し方についても、考えさせられる内容で、そこらへんも非常に良い話ばかりなので、ぜひ読んでみてください。

O/Rマッパーを使う理由

f:id:tikasan0804:20180805205507p:plain
※サムネがO\Rとなってますが、表記ブレです

記事にした経緯

私の所属するVOYAGE GROUPでは、技術力評価会という、エンジニアがエンジニアを評価する会があります。その発表の素振り、つまり、事前練習会みたいのが行われたりします。 そこで、O/Rマッパーを使っている部分の話になった時に、「O/Rマッパーって何が便利なんですか?なんで使うんですか?SQLを書いたらだめなんですか?」という質問が飛び出しました。

これは私に対して来た質問ではなかったのですが、確かに何で使おうんだろうねっていうのが言語化出来ていなかったので、まとめてみようと思いました。

O/Rマッパーとは

オブジェクト関係マッピング - Wikipedia
Wikipediaには、オブジェクト関係マッピングという名前で紹介されていました。そこに書いてある内容を要約すると・・・

データベースとオブジェクト指向プログラミング言語の間の非互換なデータを変換するプログラミング技法である。

つまり、オブジェクト指向とデータベースの考えの差分を吸収して、どっちでもいい感じに使えるようにする技法。

では、何故この技法が生まれたのかを理解していく。

登場した背景

オブジェクト指向言語で、リレーショナルデータベース(以下データベースとする)を使う時に、取得してきたレコードをオブジェクトにマッピングする作業が必要になります。わからない人向けに手動マッピングのコード例を貼っておきます。

※以下のコードはかなりいい加減なのと、適当にコピってきたなので、流し読みしてください

Connection conn = null;

try {
  conn = DriverManager.getConnection(url, user, password);

  Statement stmt = conn.createStatement();
  String sql = "SELECT id, first_name FROM users";
  ResultSet rs = stmt.executeQuery(sql);
  List<User> users = new ArrayList<User>();
  while(rs.next()) {
      User user = new User();      
      // usersテーブルのid を UserクラスのIdフィールドに入れる(マッピング)
      user.setId(rs.getString("id"));
      user.setFirstName(rs.getString("first_name"));
     users.add(user);
  } 
}catch (SQLException e){
  out.println("SQLException:" + e.getMessage());
}

こういったマッピングを毎クエリ書く必要が出てきます。これはオブジェクト指向言語が悪いとか、データベースが悪いという話ではなく、設計のズレ。これをインピーダンスミスマッチと言います。

  • リレーショナルデータベース設計: 検索や登録更新処理に最適なモデル定義
  • オブジェクト指向設計:データモデルを現実世界のモデルに即したものとして定義

そもそも、思想が違うので、どちらかの思想が合わせるといったことすると、不都合が起きることは当然ですよねっていうことはこの時点でわかる。それらの不都合を解決するために出てきたのがO/Rマッパーです。

O/Rマッパーがない世界感

SQLにはオブジェクト指向を考慮した設計はなされていないため、SQLを扱おうとすると、オブジェクト指向にある柔軟性のメリットが無に帰すわけです。どういうことか?

何かのSQL構築したいと考えた場合、オブジェクトに入れたデータをデータベースに保存するために、一旦オブジェクトからデータを抜き出し、SQLを構築する専用メソッドが必要があります。これだけでもだるい作業なのですが、もし、データベース側でカラム名、型の変更があった時に、SQL作成部分のコードは毎度実装修正する必要が出てきます。(再利用性とは・・・状態)

また、マッピングを書く処理は非常に単調で退屈なコードです。しかし、これを間違えると普通に事故ります。しかも、型が同じであればそれっぽく動いたりもするので、これを人間が手作業で全部やるのは辛い。(コードジェネレーターで解決するという手もありますが、今回は割愛)

使うことで得られるメリット

よくあるO/Rマッパーは、オブジェクトを作成して、データベースのデータを更新するメソッドに渡すだけで、あとはそのメソッド内で、クエリ作成に必要なマッピングを中でやってくれます。
もし、フィールドを増やしたい減らしたいといったことが起きても、updateメソッドに渡すオブジェクトに変更加えるだけで済みます。このメリットはレコードを取得する時にもです。

ちなみに、マッピング情報をxml形式で書いたり、アノテーションで定義をすることが多いです。面倒のように思えますが、そこさえ書けていれば、コードを書く時はオブジェクトを扱うように操作が出来るようになります。

User user = new User();  
user.setId(1);
user.setFirstName("hoge");

// いい感じに変換してくれる(型解釈や構文の構築など)
// UPDATE users SET first_name = 'hoge' WHERE id = 1
db.update(user);

SQLを考えなくてよくなる?

オブジェクト指向言語からオブジェクトをそのまま扱うような感覚でデータベースを扱うことが出来るようにしたのが、O/Rマッパーですが、だからといってSQLを知らなくていいというわけではありません。これはどういったクエリが発行されているのか?は理解しておかないと、「スロークエリ」や「N + 1問題」といった問題に対して何も出来なくなってしまうので、精通しているまではやらなくても、読めるようにしておくことは必須です。

そもそも、O/Rマッパーが登場した背景には、SQL理解しなくても使えるようにではなく、分かっていることを何度も書かないで済むようにしたいや、オブジェクト指向とリレーショナルデータベースのメリットを最大限発揮するために考えられたものなので、知らなくていいやという話ではないのです。

まとめ

世に出ているO/Rマッパーはマッピングだけではなく、付随して便利な機能を持ったものがたくさんあるので、ずばり何がしたいんだっけ?がブレブレだったので、学びがあった。

IntelliJ IDEA プロジェクト内移動を使いこなす

f:id:tikasan0804:20180729133436p:plain

案外ちゃんと使いこなせていないソースの行き来機能

IntelliJ IDEAと言いつつ、スクリーンショットはGolandでやっています。

わりと規模大きめの開発が多くなってきて、様々なファイルを行き来することが増えてきて、結構ファイルを探すという無駄な時間が発生していることに気づいたので、今回は費用対効果高そうだったので、プロジェクト内移動のNavigation機能についてまとめたいと思う。

この記事に書いていることは以下の本に大体書いています。

ショートカットも基本的にわかる範囲で紹介します。(ideaVimを普段使っているのでわかる範囲で書く) また、私は相変わらずショートカットの記号が覚えられないので、ここではAltやCtrlと書きます。

macOS Sierra: メニューに表示される記号

コードジャンプ系

シンボル定義箇所へジャンプ

定義されている変数や関数の定義元にジャンプする。

  • ideaVim Ctrl + ]
  • Mac Command + B
  • Win Ctrl + B

一箇所しかない場合は、一発でジャンプしますが、複数定義箇所がある場合は、ポップアップが出てきます。

f:id:tikasan0804:20180729121021p:plain

シンボルの利用箇所の一覧

  • Mac Option + F7
  • Win Alt + F7

何かのシンボルにカーソルを合わせて、使うと、その定義箇所から利用箇所が一覧で見れる。

f:id:tikasan0804:20180729120802p:plain

ジャンプを戻る

ジャンプ先から戻る

  • ideaVim Ctrl + t
  • Mac Command + [
  • Win Ctrl + Alt

ジャンプ先に戻る

  • Mac Command + ]
  • Win Ctrl + Alt +

クラス間の移動

子クラスから親クラスへ移動。(Javaとかの継承)

  • ideaVim クラス名に合わせて、シンボルへのジャンプで同じことができる
  • Mac Command + U
  • Win Ctrl + U

親クラスから、子クラスや実装クラスを見ることもできる

  • ideaVim クラス名に合わせて、シンボルへのジャンプで同じことができる
  • Mac Option + Command + B
  • Win Ctrl + Alt + B

ファイル系

直近のファイルを開く

Ctrlを押したまま、Tabを押した回数だけ前のファイルに戻れます。

  • Mac,Win Ctrl + Tab

f:id:tikasan0804:20180729123422p:plain

直近のファイル一覧

上のTab を何度も押す形式は正直だるいので、開きっぱなしにできるこっちのがおすすめ。

  • Win Command + E
  • Mac Ctrl + E

f:id:tikasan0804:20180729123752p:plain

ディレクトリ系

ナビゲーションバーを使って移動

ナビゲーションバーを開いて、矢印キーEnterとかをつかうと、ソースを開く事もできます。

  • Mac Command + 1
  • Win Alt + 1

f:id:tikasan0804:20180729125325p:plain

ナビゲーションバーの操作型

新規ファイル作成

  • Mac Command + N
  • Win Alt + Insert

ファイル名変更

  • Mac,Win Shift + F6

現在開いているファイルにフォーカスを当てる。

  • Mac Command +
  • Win Alt + Home

現在開いているファイルをナビゲーションバーと同期させる

いま開いているファイルってソースどこ?っていうのが案外わかりにくかったりするので、自分は同期させたりしています。
※上に出てる階層表示でわかるっちゃわかりますが

f:id:tikasan0804:20180729130537p:plain
f:id:tikasan0804:20180729130541p:plain

検索

Search Everywhere

色んな検索をサクッとできる。

  • Mac,Win Shift 2回押す

f:id:tikasan0804:20180729131305p:plain

種別付き検索

ファイル名検索

  • Mac Command + Shift + O
  • Win Ctrl + Shift + N

クラス名検索

  • Mac Command + O
  • Win Ctrl + N

シンボル名検索

  • Mac Option + Command + O
  • Win Ctrl + Shift + Alt + N

シンボル・検索除外

Excludedに指定すると検索対象として出なくなる。
よくあるケースとしては、jsのdistフォルダ出てくるなあああああ!とか。

f:id:tikasan0804:20180729131715p:plain

TODO一覧

FIXME TODO をコード上で書くと、一覧して見ることが出来る。

  • Mac Command + 6
  • Win わからなかった

f:id:tikasan0804:20180729132637p:plain