Figmaの便利なショートカットを覚える(Mac)
Figma使っていて便利であろうショートカットを、自分も覚えるためにスクショつきでメモっておく(Mac用です)。
command + \
- Show/Hide UI
ctrl + c
- Color Picker
command + /
- Search
shift + r
- Ruler
option + 1
- Layers / option + 2
- Assets
Shift + 0
- Zoom 100% / Shift + 1
- Zoom to fit / Shift + 2
Zoom to selection
n
- Zoom to next frame / Shift + n
- Zoom to previous frame
PageDown
- Next page / PageUp
- Previous page
command + option + l
- Text align left / command + option + t
- Text align center / command + option + r
- Text align right
command + g
- Group selection / command + shift + g
- Ungroup selection
option
- Measure to selection
1
- Opacity 10% / 5
- Opacity 50% / 0
- Opacity 100%
command + [
- Send backward / command + ]
- Bring forward
command + option + ]
- Bring to front / command + option + [
- Send to back
option + a
- Align left
option + d
- Align right
option + w
- Align top
option + s
- Align bottom
option + h
- Align horizontal centers
option + v
- Align vertical centers
ctrl + option + h
- Distribute horizontal spacing
ctrl + option + v
- Distribute vertical spacing
画面共有先のMac MiniでMagnetがうまく動作しなかったのは競合していたから
夜は仕事部屋で過ごすのが嫌いです。リビングでまったりと過ごしたいのですが、メイン機のMac Miniが仕事部屋にあるのがちょっとした問題。
- 夜は仕事部屋で過ごしたくない
- リビングでまったりしたい
- Mac Miniは仕事部屋にある
- 夜な夜なMac Miniで試したいことがちょいちょいある
- リビングにMac Miniをいちいち持ってきたくない
- Macbook Airは持っている
- Macbook Airで開発はあまりしたくない
という要求があります。一時はMac Miniとモバイルディスプレイを仕事部屋からリビングまで運んでました。ギリギリやれましたけど、長続きしませんでした。
MacからMacへのリモートデスクトップ
Windows機に対してはRemote Desktopしたら割とそのまんまノートPCからメイン機に入って作業できたりします(マルチディスプレイも対応しててとても良い)。
apps.apple.comMacはどうしたものかな、と思って安易に「mac vnc clients best」でググってみたのですが、でてきた候補がどれもしっくり来なかったです。
もうちょっと真面目に調べてみたら、そもそもMacには標準で「Screen Sharing(画面共有)」というアプリがあることを知りました。Mac歴はそれなりに長いつもりでしたが恥ずかしながら初めて知りました...。
ということでリビングからMacbook Airを使って仕事部屋のMac Miniにあっさり接続できました。ショートカットが基本的にMac Mini側で動作してくれるので好感触でした。
- Command + Tabでのアプリ切り替えなどのショートカット
- Command + Shift + SpaceでAlfredが起動する(Macbook AirではなくMac Miniがちゃんと認識)
- クリップボードがMacbook AirからMac Miniに共有される
という感じで、TrackPadによるジェスチャーも「その他のジェスチャ」に該当するもの以外はMac Mini側が認識してくれている雰囲気があります。
イケてないものもあった
「これはいけるぞ!」と希望に満ち溢れていたのですが、問題に気づきます。個人的に愛用している「Magnet」というアプリがうまく動かないのです(ここにきてやっと本題)。
apps.apple.comこれは、フォーカスを当てているウィンドウの大きさをいい感じに左半分、右半分、全画面などに変えてくれるショートカットを提供してくれるMacの常駐アプリです。(WindowsユーザーならOS標準で備わっている機能です) この機能が使えないとそれなりに生産性に響きます。
「Ctrl + Shift + やじるし(←↓→↑)」を割り当てていたのですが、見事に全く反応せず。「Ctrl + やじるし」だったり、「Shift + やじるし」は別のアプリで反応しているので、もしや「Modifier(CtrとかShiftとか)が2つ以上あるとダメ?」と疑ってしまいました。
ただ、よくよく考えてみるとMacbook Air側にもMagnetをインストールしてるから「競合してる?」と思い、Magnetのオプションを見てみたところ、とてもそれっぽいオプションを見つけました。
「"画面共有"を無視する」です。Macbook Air側のMagnetに「画面共有のウィンドウは無視してね」って伝えることができます。
予想は的中!Mac Mini側でちゃんとMagnetもいい感じに動作してくれるようになりました。
ということで夜はまったりとリビングから開発なりなんなりをできているのでした。
まとめ
- MacからMacへのリモートデスクトップにはOS標準の画面共有アプリがいい感じ
- だいたい良い感じに接続先のマシンを操作できる
- ショートカットキーが競合するものもあるので、それは頑張って調査する
- Magnetは「○○を無視する」機能を駆使する
hooksの型推論が効かなかったのはTypeScriptのas constがわかっていなかったから
久しぶりにReactを触っているのですが、hooksを自作したら分割代入したときにTypeScriptの型推論が効かなかったマンです。
hooksの型推論が思うように効かない
下のようにAPIを呼び出して、結果を使うhooksを作りました。
import React, { useState, useEffect } from 'react'; import yelp from '../api/yelp'; import { SearchResult } from '../types'; export default () => { const [results, setResults] = useState<SearchResult[]>([]); const [errorMessage, setErrorMessage] = useState<string>(''); const searchApi = async (term: string) => { // 省略:検索の非同期処理 }; useEffect(() => { searchApi('pasta'); }, []); return [searchApi, results, errorMessage] as const; };
使う側でいい感じに型を推論してほしかったのですが、分割代入すると思うような結果にならなかったです。。
hooksの作り方が悪いのかなと思ったら普通にTypeScriptのことをわかっていないだけでした。
TypeScriptにおける配列の型推論
下のようなコードをTypeScriptで書いてみました。配列を作って、その配列から分割代入してます。
const ary = [1, 'hoge', true, () => 'moge', {a: 'a', b: 'b'}]; const [one, hoge, trueValue, mogeFunc, obj] = ary;
普通に型推論が効くかと思いきや、残念な結果に。。。
oneは 1
になってほしいところですが、以下のように「いずれかの型」という推論しかされません。
const one: string | number | boolean | (() => string) | { a: string; b: string; }
当然、この状態では加算だってできません。。。
以下にplaygroundを用意したので気になる人は試してみてください。
TypeScript: TS Playground - An online editor for exploring TypeScript and JavaScript
const assertions
この現象はTypeScript3.4に追加された「const assertions」についての理解が乏しかったせいでした。配列やオブジェクトなどに as const
をつけることでコンパイラに「中身は変わりませんよ」というのを教えてあげる必要があるのです。
ということで ary
に as const
をつけてあげることで、型推論がちゃんと効くようになります!
const ary = [1, 'hoge', true, () => 'moge', {a: 'a', b: 'b'}] as const; // ここに追加 const [one, hoge, trueValue, mogeFunc, obj] = ary;
hooksに関しても原因は一緒
冒頭のhooksに関しても、 return
するものに as const
をつけてあげることでちゃんと型推論が効きます。
return [searchApi, results, errorMessage] as const; // ここに追加
これでhooksの使う側も型推論が効いて心穏やかにコーディングできます。
CodeTourでCodeのTourを作ってみた
使ってみようと思いながらなかなか手をつけていなかったCodeTour。GWなので使ってみることにしました。
CodeTourって?
CodeTourはVSCodeのExtensionで、コードのウォークスルーをVSCodeでそのまま作れるツールです。文字で表すとわかりづらいのですが、以下の場合に特に活躍しそうなツールです:
- 新しくプロジェクトにJoinした新人にコードを理解してもらう
- 自分のためにコード内にメモを残しておく
NotionだったりConfluenceだったり、いろんなツールを使ってコードに関するナレッジを残す工夫を人それぞれやっていると思うのですが、「コードそのものに残せたら良いのに...」と思ったことがあるはずです。そんなときに使える優れものです。
この記事では基本的な使い方だけ紹介しますが、ExtensionやGitHubのリポジトリを見たら細かい機能まで説明が載っているのでぜひ読んでみてください。
さっそく使ってみた様子
百聞は一見に如かずとやらなので、一連の流れを動画に収めてみました。(書いてるコメントはしょぼいですけど、雰囲気は伝わるはずです)
基本的な使い方
使い方に関しては本家のページが詳しく載っているので、ここではどういうときに何を使うと良さそうかというのを紹介しておきます。
Tourを作る
Tourを開始する
Tourを保存する
リポジトリ内で作ったTourは .tours
ディレクトリに ツアー名.tour
ファイルとして以下のキャプチャのように保存されます。これをリポジトリ管理下に置いておくのが基本的な運用方法になりそうです。
が、必ずしもリポジトリ配下に置けるとは限らないですし、ちょっとしたメモレベルのものを作っておきたいと思うかもしれません。そんなときにTourを外部にエクスポートしておくこともできます。
Tourを開く
リポジトリ内のTourは自動でVSCodeで開かれるのですが、リポジトリ外のTourを開くこともできます。しかも、URLから開くこともできます。ちょっと何を言っているかわかりづらいと思うので、これも動画でとってみました。
何がすごい(?)かというと、ローカルにTourのコードが無くてもこのTourが再生できるということです。動画で使っていた .tour
のファイルを見るとわかるのですが、なんとTourで使われたコードがそのままJSONに入っているので、コードが無くてもTourが再生できるのです。
ory_keto_relation-tuple_parse.tour · GitHub
他にすごそうな機能
基本的な機能は上で述べた通りですが、他にもすごい機能があります。
- Tour同士をリンクさせることができる(Linking Tours)
- 状況に応じてTourを表示するか否か、JavaScriptで制御できる(Conditional Tours)
- デフォルトで
isLinux
,isMac
,isWindows
という変数が用意されてるので、プラットフォーム別に表示するTourを容易に制御できる
- デフォルトで
- Tourからシェルコマンドを実行できる(Shell Commands)
- Tourをコードとどのように紐付けるか指定する(Versioning Tours)
- TourをBranchに紐付けるのか、Commitに紐付けるのか、Tagと紐付けるのか等指定できる(コードとTourの同期をとるためにかなり重要)
- コードとTourの同期が取れてなさそうならCIで検知してもらう(Maintaining Tours)
おわりに
- CodeTourを使ってみた
- コードベースへのオンボーディングで重宝しそう
- コードに対して自分のメモ用としても強力
- メンテナンス性についてもかなり考慮されている
これからがっつり使っていって、CodeTour力を高めていきます!
なんだ、妄想していたのか / 「反応しない練習」を読んだ
アンガーマネジメントの本を買おうかと思ったらこの本がレコメンドされてて気づいたら買ってました。
「反応しない練習」
まず、タイトルが面白かったです。仏教とかブッダとか出てきてますけど、宗教的な要素はあまり感じず、割とスッと読めました。生きていく上で参考になる点もいくつかありました。かなりエモいですけど新しい気付きもあったので軽くまとめておきます。
目次
- 第1章 反応する前に「まず、理解する」
- 第2章 良し悪しを「判断」しない
- 第3章 マイナスの感情で「損しない」
- 第4章 他人の目から「自由になる」
- 第5章 「正しく」競争する
- 最終章 考える「基準」を持つ
他者との向き合い方
他者とどうやって向き合っていくか、というのはいつも悩みの種となるのですが、本書では「相手との関わり方の原理原則」として以下の5つが述べられています。
1. 相手のことを「判断」しない 2. 過去は「忘れる」 3. 相手を「新しい人」と考える 4. 「理解し合う」ことを目的とする 5. 「関わりのゴール」を見る
中でも1〜3には個人的に新しい気付きがありました。
相手のことを「判断」しない
ついつい何かがある度に相手のことを「判断」しがち。「良い・悪い」、「好き・嫌い」は全部「判断」であり、「妄想」の様です。
過去は「忘れる」
相手との「良いこと」も「悪いこと」も、過去のことは自分の記憶の中にある「妄想」の様です。
相手を「新しい人」と考える
「今日はこうだったけど明日からはああしよう」とか決意することがあると思います。そう決意したなら明日からの自分は、きっと今日の自分とは違います。ということを相手にも当てはめることができて、相手もまた日々アップデートしてると考えることができます。
昨日のあの人が、今日も同じあの人だ。と考えるのもまた「妄想」の様です。
その「妄想」を持ってしまっているがために、理解し合えるはずだった相手とのチャンスを自ら潰してしまう危険があると、本書では述べています。
相手のことを安易に判断せず、何かが起きたとしても明日には気持ち新たに、アップデートされたであろう新しいバージョンの相手と接してみよう
という感じに理解してみました。
ただ、僕は出家したわけでもないですし、そんな仏のような心を持てる自信もありません。その点については、「鬱陶しい相手からは距離を置く」ということについても本書には書かれているので、逃げることも大事なんだと理解しました。
妄想がダメというわけじゃない
「妄想」を上で連呼していますが、「妄想」が悪いというわけじゃない様です。大事なことは、「あ、妄想してる」と自分で気づくことだと本書は述べています。はっと、客観的に自分を見れるようになることです。うれしいことを妄想しているときは良いと思うのですが、つらいことが起きたときにはついつい自分の中に引きこもりがちになると思います。そういうときに、「あ、自分また妄想してるわ」と気付けるようになるのが大事な様です。
目指すゴールは「最高の納得」
「こうなってほしい」、「もっと理解されたい」、「あの人はすごいけど自分は、、、」ということはついつい考えてしまうことがあると思います。これに関連した「承認欲求」についても本書はうまくまとめていますので、気になる方はぜひ読んでいただきたいのですが、大事なのは「きっと納得に近づけると信じて、道を進んでいく」ことなのだと述べています。
「自分で納得して、人生ってこれでいいんだ」
って思えるような「生き方」、「考え方」、「心の使い方」を目指しましょう、という感じです。
まとめ
- 「反応しない練習」を読んだ
- 妄想している自分を客観的に見れると良さそう
- 仕事場でも、家庭でも実践できそうなエッセンスがつまっている
参考
この本を読んでいてGoogleの「サーチ・インサイド・ユアセルフ」が浮かびました。マインドフルネスとも通じるところがあると感じました。
サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法
- 作者:チャディー・メン・タン,一般社団法人マインドフルリーダーシップインスティテュート
- 発売日: 2016/05/17
- メディア: Kindle版
Visual Studio Codeで.NET Core開発をする(Mac)
最近C#を触ることが増えてきたのですが、さすがに2013年モデルのMBPでParallels+Visual Studioではいろいろと(特にビルド時間)つらくなってきたので、小規模な個人プロジェクトはVisual Studio Codeでやってみようと思い、環境を整えてみました。その記録を残しておきます。
まず、基本的には公式の以下ページの通りで比較的簡単に開発を始められます。
.NET Core SDKのインストール
若干つまづいたのは.NET Core SDK
をインストールしたあと、dotnet
コマンドが使えなかった点でした。
$ dotnet
zsh: command not found: dotnet
/usr/local/share/dotnet/dotnet
にバイナリは存在していたので、ひとまずシンボリックリンクを作ることにしました。
# dotnetコマンドの存在チェック $ ls -al /usr/local/share/dotnet/dotnet -rwxr-xr-x 1 root wheel 105872 3 19 07:05 /usr/local/share/dotnet/dotnet # シンボリックリンク作成 $ ln -s /usr/local/share/dotnet/dotnet /usr/local/bin/
関連するStackOverflowが以下のリンク先にありますが、執筆時点ではCatalinaが影響している可能性がありそうですね。
コンソールアプリの作成
dotnet
コマンドの準備もできたところでコンソールプロジェクトをさっそく作って、Visual Studio Codeで開きます。
# Consoleプロジェクト作成 $ dotnet new console # Visual Studio Codeで開く $ code .
すると、下図のように「いろいろC#用のアセットをインストールしますか?」って聞かれるので「YES」を選択します。
完了しましたらターミナルで実行してみましょう。ビルド状況を少し可視化しておきたかったので-v n
オプションをつけています。
$ dotnet run -v n # ...割愛 ビルドに成功しました。 0 個の警告 0 エラー 経過時間 00:00:01.63 Hello World!
いとも簡単に実行に成功してます。
ただ、いちいちターミナルから実行してたらDX(Developer Experience)が微妙なので、Visual Studio CodeのアクションでTasks: Run Task
を実行します。
そうすると、下図のようにwatch
, build
, publish
が用意されています。この中身は.vscode/tasks.json
でも確認することができます。
watch
を実行することでプログラムがコンパイルされて実行されます。
そして、名前の通り変更を加えて保存すると自動で再コンパイルして実行もしてくれます。
下図は「Hello World!」を「Hello 世界!」に変えた実行結果。
この時点で手軽さにかなり感動しました!Macでもすぐに始められます(ただし、本格的なアプリを作るのはまだこれから)
デバッグ
それでは、デバッグはどんな感じなのか試してみます。ブレイクポイントはエディタの行番号の横をクリックすることで赤丸がついてくれます。
左のメニューから「Run」を選択し、.NET Core Launch(console)
を実行します。
しばらくすると普通にブレイクポイントで止まってくれます。Step In, Step Out, Step Overなど当たり前にできますし、変数の中身も問題なく変えられます。
Visual Studioを使っていると当たり前なのですが、まさかVisual Studio Codeでここまで普通にできるとは思っていなかったです。
おまけ
せっかくなので他の機能もチェックしてみました。
リファクタリング
定数を抽出してから、その定数の名前を変更するリファクタを試してみました。
文字列"Hello 世界!"
を定数Value
に抽出するにはカーソルをあわせて豆電球をクリックするかoption+enter
で選択肢が表示されるので、実行したい変更を選びます。
また、このときにValue
という定数名が勝手につけられていて変えたいと思ったので、Value
にカーソルを合わせてF2
をクリックし、定数名の変更を実行してみました。
名前空間の追加とIntellisense
次に、不足している名前空間の追加もやってみました。例えばusing System;
が無い状態で、Console
と書いてみます。本来手動でusing System;
と追記しなければいけないところ、上の例と同様でこのときに豆電球が表示されるので、クリックするかoption+enter
を入力するとusing System;
という選択肢が表示されます。これを選択すると、自動的にファイルの先頭にusing System;
が追加されます。
さらに、Intellisenseもばっちりです。Console.
と、ドットと入力した時点で、メソッドの候補がずらっと並びますし、入力するにつれて候補が絞られていきます。
以上で、さくっとVisual Studio Codeで.NET Coreの開発を始めてみました。数年前の自分であればこんなにシンプルにC#での開発を始められるなんて(しかもMacで)想像もしていなかったです。
最近発表のあった、Codespacesが使えるようになったらさらに気軽にC#の開発ができるようになりそうなのでかなり楽しみですね。
これから本格的に個人プロジェクトもこれで作ってみようと思います。
まとめ
- Visual Studio Codeで.NET Coreの開発環境を構築した
- 特に複雑なインストール手順もなく、リファクタリングやIntellisenseなどの高機能が使える
- .NET Coreの開発が一昔前よりかなりハードルが下がっていると感じた
読書をマインドマップでまとめる / 「マインドマップ読書術」を読んだ
マインドマップ読書術 (トニー・ブザン天才養成講座) (トニー・ブザンのマインドマップ)
- 作者:トニー・ブザン
- 発売日: 2009/05/19
- メディア: 単行本(ソフトカバー)
数年前からマインドマップでいろいろな情報を残すようにしているのですが、ふとAmazonをブラウジングしてたときに気になる本があったので買って読んでみました。「マインドマップ読書術」という本です。100ページ弱の小型の本でサクッと読めちゃいますが、読んだ記録を残しておこうと思います。
目次
読み方の思い込みを捨てる
まず、この本ではマインドマップの「書き方」ではなく、マインドマップを活用した効率的な読書の方法(読書術)を紹介していることに注意する必要があります。
戦略的にプレビューする
プレビューで「先に・見る」ことに関して、3つのポイントが挙げられています。
- すでに知っていることとのつながりをつける
- インタラクティブに読む
- 探偵になる
中でも上2つのポイントが刺さりました。
1つ目は、本を読む前にその本の分野に関しての自分の既存知識をマインドマップにしておくというものです。なんとなくボヤッと頭の中にある既存知識をあらかじめまとめておくと、知っていることが整理され、本を読みながら答え合わせができます。
2つ目は、著者と会話をするように(インタラクティブに)読むべきだというものです。具体的には本の余白に質問やコメントを残したりすることです。読書の際、著者との会話は忘れがちで、気づくとだらだらっと数ページ読んでいて全く内容が頭に入っていなかったりします。本自体に質問やコメントを残すことを意識しておくことで、集中力を高めます。Inputだけでは眠くなってしまうので、定期的にOutputすることを忘れずに読書することが大事だと感じました。
読み方を工夫する
本を読むとき、1回読んで満足してしまいがちですが、上にも述べたようにほとんど知識として定着しません。ここ数年で僕もようやく定着してきたのですが、複数回読むほうが圧倒的に定着します。そのテクニックとして本書ではMMOST(Mind Map Organic Study Technique)が紹介されています。マインドマップの父であるトニー・ブザン氏が考案したテクニックのようです。
準備の4ステップ
応用の4ステップ
- 「概略」を読む
- 「要点」を読む
- 「詳細」を読む
- 「仕上げ読み」する
「丁寧に1回読む」ことをやめて、「複数回読む」前提で本を読む必要があります。MMOSTに関しては(英語になりますが)以下の記事でも紹介されています。
Mind Map Organic Study Technique (MMOST)destech.wordpress.com
まとめ
- 「マインドマップ読書術」を読んだ
- 本は複数回読む方が良い
- 「本を読むこと」自体を目的化しちゃいけない
余談ですが、下手なりにマインドマップをアプリではなく、Apple Pencilで書いたものが以下のとおり。
参考
Mind Map Mastery (English Edition)
- 作者:Buzan, Tony
- 発売日: 2018/03/15
- メディア: Kindle版
記憶術に関するUdemyのコース
マインドマップツール「MindMeister」(Mind Mapを横断的に検索できて良い)