Macで秘密鍵と公開鍵を作成する
毎回ググっていたのでメモしておく。
- 秘密鍵と公開鍵を作成する
$ ssh-keygen -t rsa -b 4096 -C "account@example.com"
暗号化方式はRSA、 鍵長は 4096 にする。-Cオプションはコメントで、ここではメールアドレスにすることでなんの鍵かわかるようにしている。
※ 暗号化方式はRSA、ECDSA、Ed25519のどれか。鍵長は2048以上にする。
- 秘密鍵と公開鍵が作成されていることを確認する
$ ls -la .ssh/ id_rsa (秘密鍵)とid_rsa.pub (公開鍵)が表示される。
- 読み書き権限を付与する
$ chmod 600 .ssh/id_rsa.pub
- 作成された鍵の強度を確認する。
$ ssh-keygen -l -f ~/.ssh/id_rsa.pub 4096 SHA256:90FRF8tgbGec/iGRTgeg5ijDeeWEDGedRRgGG5VVlQU account@example.com (RSA)
暗号化方式はRSA、 鍵長は 4096 で作られている。コメントに指定したメールアドレスも確認できる。
- サーバー側に公開鍵を設置する
$ ssh root@192.168.0.1
※ 既に運用されているのであればインフラの方に公開鍵を渡して設置してもらう必要がある。
- 公開鍵を配置するディレクトリを作成する
$ mkdir -p /home/user_name/.ssh
- 読み書き実行権限を付与する
$ chmod 700 /home/user_name/.ssh
- ディレクトリと中身の所有者を変更する
$ chown -R user_name:user_name /home/user_name/.ssh/
- 公開鍵をローカルのMacからサーバーへ設置する
$ scp ~/.ssh/id_rsa.pub user_name@192.168.0.1:~/.ssh/authorized_keys
$ ssh user_name@192.168.0.1 -i ~/.ssh/id_rsa
参考
http://ponsuke-tarou.hatenablog.com/entry/2017/10/19/002727 https://qiita.com/suthio/items/2760e4cff0e185fe2db9 https://www.task-notes.com/entry/20150208/1423325535 http://www.atmarkit.co.jp/ait/articles/1503/20/news007.html https://qiita.com/reflet/items/0c338df07d9f6c6ef776
Macにgnu-sedをインストールする
sedを使ってファイルの先頭行に文字列を追加しようとしたら、LinuxとMacで挙動が違った。
- Linuxの場合は正常に処理が完了する
$ sed -i '1ihoge' test.txt $ cat test.txt hoge
- Macの場合はエラーになる。
$ sed -i '1ihoge' test.txt sed: 1: "test.txt": undefined label 'est.txt'
いろいろと調べているとMacではBSD版がインストールされていて、CentOSではGNU版のsedがインストールされているためだった。 BSDとGNUでsedの仕様違うのか…
普段の開発ではローカルのMacで開発後、Linuxで確認していたので、Macでも同じ挙動になって欲しい… どうやらGNU版のsedをMacにインストールできるようなので早速やってみる。
$ brew install gnu-sed
gnu-sedインストール時のメッセージでコマンド名の接頭辞にgがついてるとのことなので、コマンド名は gsed になっている。
The command has been installed with the prefix "g". If you do not want the prefix, install using the "with-default-names" option.
- sedコマンドで使えるようにaliasを追加して読み込む
$ vim ~/.zshrc alias sed='gsed' $ source ~/.zshrc
また、インストール時のメッセージにあるように、インストール時にwith-default-namesオプションつけることでMacのsedコマンドに置き換えてくれるのでaliasを使いたくない人はこっちでもよい。
$ brew install - with-default-names gnu-sed
これでMacでも実行することができました!
$ sed -i '1ihoge' test.txt $ cat test.txt hoge
sedはとても便利なのでこれからも積極的に使っていこうと思います!
参考
ReactNativeのビルドプロセスについてメモ
React Nativeのプロジェクトをビルドするため、以下のコマンドを実行する。
$ react-native run-ios
React Nativeはこのコマンドで次の2つのことをします。
NodeのWebサーバー(Metroバンドラー)をローカルに起動する。
Metroバンドラー(旧パッケージャー)がJSファイルをトランスパイルしてバンドルする。
ペイロードとして、
index.platform.bundle
ファイルをpublish(公開)する※ ペイロードとはデータ本体のこと
PureなNativeアプリケーションプロジェクトをビルドし、モバイル端末(実機 or エミュレータ)にデプロイする。
このNativeアプリケーションは、JSの実行環境である
JavaScript Core
を含み、1
のWebサーバーで配信しているindex.platform.bundle
ファイルをダウンロードする。※ iOSは既に内部的に
Javascript Core
をホストしているため、iOS用のNativeアプリケーションプロジェクトには含まれない。
iOSではJSの実行環境( JavaScript Core
)はiOSのオペレーティングシステム上にホストされているが、AndroidではReact Nativeと一緒にデプロイされる。また、エミュレータも同様にペイロード( index.platform.bundle
)ファイルにアクセスしている。
ReactNativeのBridgeの仕組みについてのメモ
React NativeはJavaScriptでiOSとAndroidのアプリを作成することができるネイティブアプリケーションを作成するためのフレームワークです。
React Nativeでは Bridge
という仕組みを使ってJavaScriptからNativeコードに処理を渡して実行することができます。
JavaScript実行環境である JavaScript Core
がOS上で実行されており、 Bridge
を通してNativeコードに解釈されます。
従来のWebアプリケーションは、ブラウザがHTML, CSS, JavaScriptをサーバーからダウンロードし、レンダリングします。 React NativeもWebアプリケーションと似ていて、モバイル端末がJavaScriptとReact Nativeのマークアップをロードします。
JavaScriptはそのままではモバイル端末上では実行できないので、Bridgeを使ってモバイル端末のプロセッサとやりとりするする必要がある。
そのためにはJavaScriptを実行するための実行環境である JavaScript Core
がモバイル端末には必要になる。
JavaScript Core
はオペレーティングシステム上で実行され、JavaScriptを実行するコード郡です。
また、JavaScript Core
は、JavaScriptを実行するNativeコードをロードしてから、モバイル端末のビルドプロセスへJavaScriptをロードします。
つまり、JavaScriptの実行環境内でReact NativeのJavaScriptコードが実行されます。
React Native実行環境についてメモ
React NativeはJavaScriptで書ける
iOS上とローカルのMacでは実行環境が異なる(2パターンある)
- JavaScriptCore 実機のiOS上で実行する場合は、JavaScriptCoreが使われる JavaScriptCoreはsafariブラウザのJavaScriptエンジンでもある iOSアプリにはiOS上のメモリへの書込みが許可されていないため、JavaScriptCoreはJITコンパイラを使えない。(モバイルのため、そこまでメモリを積んでいない) MobileSafari.appやApple謹製のアプリはJITコンパイラを使っているかも(?)
- V8 開発中に使うシミュレーターはWebソケット経由でGoogleが開発したV8上で実行される。 V8はChromeブラウザのJavaScriptエンジン。Node.jsのエンジンとしても使われている。
コンパイラについての補足メモ
JIT(Just In Time) プログラムの実行時に中間コードを機械語にコンパイルする。JITは最近人気のコンパイラで、有名なプロダクトでは、Javaや.Net等の言語で採用されている。Javaは以前、インタプリタを採用していたが、JITの方が高速にプログラムを実行できるため、置き換えた。 インタプリタも呼ばれた時にコンパイルされるが、毎回コンパイルをする必要があるため、パフォーマンスがよくない。JITは一度コンパイルされたプログラムの塊はキャッシュされるので、初回実行時のみのオーバーヘッドになる。
AOT(Ahead Of Time) JITと反対に、事前にコンパイルするコンパイラにAOT(Ahead Of Time)コンパイラがある。C言語やC++、C#で使われており、iOSとAndroidもAOTを採用している。JITコンパイルは部分的な最適化をするが、AOTコンパイルはどのプラットフォームに対して最適化を行うのか事前にわかっているため、プラットフォームに合わせたコード全体の最適化が可能になる。
参考
React Nativeをアップグレードする
初めてReact Nativeのアップグレード作業をした時、たくさんコンフリクトしてかなり焦った。次回アップグレードをする時にどうすればいいかの手順を自分なりにまとめた。 公式ドキュメントはこちら。 facebook.github.io
インストール済のreact-nativeのバージョンを確認する
既にreact-native-git-upgradeを実行していると、package.jsonのバージョンと異なる場合があるので、念のためバージョンを確認する。
※ node_modules以下のreact-nativeのバージョンを表示してくれる。
$ react-native --version react-native-cli: 2.0.1 react-native: 0.51.0
グレードアップするためのモジュールをインストールする
$ npm install -g react-native-git-upgrade
react-native-git-upgradeを実行する
- バージョンを指定してアップグレードする
$ react-native-git-upgrade 0.52.0
バージョンを指定しないと最新版がインストールされる。 一気に最新バージョンまで上げると、コンフリクトが大量に発生した祭に手間取るので、個人的には0.1.0刻みくらいでアップグレードするほうが好み。
実行後、特に問題なければそのままコミットして、完了!
コンフリクトが発生したらひたすらコンフリクトを解決する。基本的には古いものを新しいものに置き換えていくことが多い。 途中で迷子になったらReact Nativeのバージョン間の差分を確認できる、rn-diffを見る。 github.com
flowのバージョンも上げる
React Nativeのアップグレードをすると毎回flowのバージョンアップもある。 自動でアップデートされないので、flowの場合は、.flowconfigのバージョンを確認して手動でアップデートする必要がある。
$ npm install --save-dev flow-bin@0.57.1 $ flow
flowコマンドを実行し、エラーがなくなるまで修正すれば完了。
まとめ
初めてアップグレードした時は最新のバージョンまで一気にやってしまい、マジどうなっているんだろうと思いながらの作業だった。 一度経験してから、手順を見直すとそこまで大変じゃない気がしてきます。 flow次第ではプログラムの修正数が凄いことになりますが... アップグレードする前に一度rn-diffを見ると、どんな変更があるか簡単に把握できるので、とりあえずrn-diffを見ておくことがオススメ。