エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

githubのssh-keyの登録

きっかけ

いつも迷うから。

やることは大筋理解しているのだが、面倒で手軽な方向にばかり逃げてきたので、自戒のためにまとめる。

前提条件

githubに登録するので、前提条件としては、githubのアカウント/リポジトリがあることとする。
また、vi操作は、できるものとして話を進める。

環境

OS

$sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.6
BuildVersion:   18G87

mac前提です。
windowsだと、sshクライアントがデフォルト付いてないのが嫌なので、やっぱり開発はmacでってなってしまう。
cygwin入れればいいのだろうけど、インストールが面倒なんだよね。
時間もかかるし。

Git

$git --version
git version 2.22.0

毎回、git -v をやって怒られてしまう。
ailiasつければいいのだろうが、あんまりailiasに頼りすぎると、環境を一から作るときに苦労しそうなのでやめてる。
他の人はどうしているのだろう?
「そもそも、gitのバージョンなんて確認しねーよ」って人がほとんどだろうか?

やり方

道筋

大まかなやり方の方針を、まずはざっくり理解する。

  1. ssh-keyの生成
  2. 設定ファイルの作成
  3. githubに公開鍵を登録
  4. ssh接続のテスト

ssh-keyの生成

まずは、公開鍵と秘密鍵を作る。

$ cd ~/.ssh
$ ssh-keygen -t rsa -C <メールアドレス>

ディレクトリは、~/.ssh以外でもいいけど、指定があとあと面倒になるので、なるべくここにした方が無難。

ssh-keygenを実行すると、何回か質問される。
Enter file in which to save the key (/Users/<ユーザ名>/.ssh/id_rsa):は、他の場所に保存するかどうか聞かれる。
あんまり場所を移すと、あとあとどこに何をおいたのか分からなくなるので、デフォルトのまま、何も入力せずにenterする。

Enter passphrase (empty for no passphrase):は、見た通り、パスワード設定。
これを入力すると、確認のために、再度入力を求められるので、もう一回入力してenter。

そうすると、~/.ssh/下に、id_rsa/id_rsa.pubが出来上がる。
ファイルの内容は、下記の通り。
id_rsa : 秘密鍵
id_rsa.pub : 公開鍵

設定ファイルの作成

鍵の管理を容易化するために、設定ファイルを追加する。
なければ、新規作成。

$ vi ~/.ssh/config

下記を追記する。

Host github.com
  HostName github.com
  IdentityFile ~/.ssh/id_rsa
  User git

githubに公開鍵を登録

やっと登録。
まずは、githubにサインインする。
サインインできたら、右上のアカウントアイコンを押下して、Settingsを選択。

f:id:suzaku0914:20190816141755p:plain

そしたら、左のメニューから、SSH and GPG keysを選択。 SSH keysの右側にあるnew ssh keysボタンを押下。

titleは、適当に入力。
keyには、id_rsa.pubの内容をコピペする。
下記のコマンドで、クリップボードにコピーしてペーストすると、楽チン。

$ pbcopy < ~/.ssh/id_rsa.pub

入力が終わったら、Add SSH keyボタンを押下して登録。
そうすると、一覧画面に登録した内容が表示されているはず。

ssh接続のテスト

もろもろの登録が終わったので、ちゃんと動作するのかテストする。
失敗したまま進むと、何が問題か分からなくなるので、何事も一個一個、こまめに確認しながら進むことが大事。

下記のコマンドで、ssh接続してみる。

$ ssh -T git@github.com

Are you sure you want to continue connecting (yes/no)?って聞かれたら、とりあえずyes
Enter passphrase for key '/Users/<ユーザ名>/.ssh/id_rsa':って聞かれるので、ssh-keygenで入力したパスワードを入力。
通信が成功すると、Hi <githubアカウント名>! You've successfully authenticated, but GitHub does not provide shell access.って表示されるはず。

感想

やることは簡単なんだけど、やるとなると面倒臭く感じるのは、俺が怠惰だからかも知れない。
githubは、privateリポジトリが誰でも作れたりするようになったので、ssh-keyを作成する需要は上がるかもって思って、まとめ記事を書いてみた。
実際、何も見ないでssh-keyを生成・登録できる人って、少数だと思いたい。少なくとも、俺は無理。何回も調べちゃう。

sshの概念って、わかっちゃいるけど、いざやるとパニクる時代が懐かしいなと感じた。
まだ、IT初心者の頃は、知識としてsshは知っていても、いざ問題に直面すると、フリーズしてしまった頃があった。
今は、簡単に問題解決できるように成長した俺を褒めたい。

参考サイト

GitHubにSSH接続できるようにする方法 - Qiita

GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ - Qiita

giboの使い方とまとめ

きっかけ

gitの初回登録で、ソース管理の必要がないものを、よく追加してしまうので、何かgitignoreのよい生成方法はないかと探した結果を残す

環境

OS

$sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.5
BuildVersion:   18F132

Homebrew

$brew -v
Homebrew 2.1.9
Homebrew/homebrew-core (git revision 2548c; last commit 2019-08-11)
Homebrew/homebrew-cask (git revision 64623; last commit 2019-08-11)

git

$git --version
git version 2.22.0

gibo

公式サイト

GitHub - simonwhitaker/gibo: Easy access to gitignore boilerplates

インストール

githubのREADME.mdにある通り、Homebrewでインストールする。
Homebrewのインストールは、ここでは詳しく説明しないので、各自でインストール

brew install gibo

インストール成功確認

インストールがちゃんとできているか、バージョン情報の出力で確認。
こういうのを怠ると、あとあとで手痛い目にあうので、着実にできることは確認した方がよいということを、最近学んだ。

$gibo -v
gibo 2.2.3 by Simon Whitaker <sw@netcetera.org>
https://github.com/simonwhitaker/gibo

Fetches gitignore boilerplates from https://github.com/github/gitignore

Usage:
    gibo [command]

Example:
    gibo dump Swift Xcode >> .gitignore

Commands:
    dump BOILERPLATE...   Write boilerplate(s) to STDOUT
    help                  Display this help text
    list                  List available boilerplates
    root                  Show the directory where gibo stores its boilerplates
    search STR            Search for boilerplates with STR in the name
    update                Update list of available boilerplates
    version               Display current script version

上記のような出力になれば成功しているhazu.

使ってみる

基本的に使うコマンドは、gibo dump <BOILERPLATE>が主になってくると思う。
やっていることは、指定したものの.gitignoreの設定を標準出力に吐き出すというもの。
なので、.gitignoreに出力して作成するのが、主な使い方になっている。

BOILERPLATEには、複数指定が可能なので、使いたい環境に合わせて指定していく。
gibo -hのExampleだと、SwiftとXcodeで必要なgitignoreの設定を出力している。

BOILERPLATEに指定可能な値は、gibo listで確認ができる。

各コマンドの説明

dump

フォーマット

gibo dump [BOILERPLATE]

説明

BOILERPLATEに指定した環境のgitignoreをコンソール上に出力する。

help

フォーマット

gibo help

説明

ヘルプの表示

list

フォーマット

gibo list

説明

BOILERPLATEに指定できる値の一覧を表示する。

root

フォーマット

gibo root

説明

giboのBOILERPLATEを保存しているディレクトリを表示する。 BOILERPLATEを修正したい場合は、ここを修正すれば良さそう。(確認はしてない)

search STR

フォーマット

gibo search <STR>

説明

STRの文字列を含む環境を調べることができる。

$gibo search mac
Emacs
macOS

update

フォーマット

gibo update

説明

BOILERPLATEを更新する。

version

フォーマット

gibo version

説明

giboのバージョンを表示する。

所感

.gitignoreを手作りするのは、やっぱり無理がある。
一度登録してしまった不要なファイルを、消すのが面倒なので、なるべく手軽にgitignoreを作ることは、非常に大事だと思う。

制約が少なそうなツールなので、環境を汚したり、何かと競合するようなことは、少ないさそう。
なので、いまは、giboで落ち着いている。

基本的に使うのは、dumpとlistくらい。
というか、ほぼdump。
覚えるコマンドが少なくて済むのも、良いところだと思いました。

参考サイト

giboで簡単に最適な.gitignoreを作成 - Qiita

.gitignoreはgiboで自動生成しよう - にわとりプログラマーの備忘録

2019/07/29週 気づきと振り返り

業務こなしての問題・気づき

SwiftのレイアウトはLabel優先

入力しない項目は、テキストフィールドじゃなくてラベルで対応する。
複数行に渡るものも、Labelで出す。
テキストフィールドを編集不可とかで表示しようとすると疲れるだけ。

SwiftでLabelのテキストの垂直方向の調整

不可
理由は、分からない。 viewでラップして対応するのが無難そう。

Swiftのコードスタイル

作ってると、なんかネストが深くなりがちなのだが、回避する方法はあるのか?
if let で、ものすごくネストが深くなってしまう。

githubのデフォルトブランチ

githubでは、デフォルトのブランチは、masterになる。

なので、masterを消したりする場合は、defaultを変える必要がある。

Cocoapodsのバージョン固定

cocoapodsのバージョン違いによるエラーが発生する場合がある。
それを回避するためには、gemfileでcocoapodsのバージョンを固定するのがベター

swiftのtableviewでのdetail text label

ストリーボードで設定することができる。
StyleのRight Detailで設定可能。

コード上でも設定できる。
個人的には、動的に変わったりするので、コード上に設定するほうが無難だと思ってる。

2019/07/22週 気づきと振り返り

業務こなしての問題・気づき

macのterminalで、現在ディレクトリをfinderで開く

open .

基本的な使い方は、open <path>
たぶん、使うケースは、open . が多い気がする。
コマンドでやるとタイピングミスしそうって場合は、finderで操作したりしたい性分なので、たまに使う。

gitignoreをかんたんに作成する

giboでやると、ものすごく楽にできる。
どこかのタイミングでまとめるが、深く考えなくても、不要なファイルやパターンを出力できるので、初期開発のスタートダッシュができると思った。
インストールも、Homebrewでかんたんに入れられるのも、良かった。
もう、Homebrewはデファクトスタンダード化している気がする。
デフォルトインストールしないのかな?

TabBarControllerとNavigationController

ラップの順序が大事。 navi → tabだと、画面遷移する際の値渡しが、面倒。
たしか、self.super.~~~とか、書かねければ行けなかった気がする。

シンプルに使いたいのなら、tab → navi の順序でラップする。

雑記

最近、夜が眠れない。
悪方向に考えが言って、なかなか寝れないんだよね。。。。
そのうち、不眠症になったりしないか不満。
調べると、寝る前に悪いことを考えると、自己暗示にかかって悪い方向に行く的な記事を見かけて、かなりガクブル状態なんですけど。。。

寝付けないと、翌日の朝は、寝坊しちゃうんだよね。。。
その時は、急いで会社に行っても居たたまれないので、仮病使って、午前休にする。
そんでもって、余裕をもって出社する。
毎回使うと、流石に怪しまれるので、なるべく使わないようにはしている。

2019/07/15週 気づきと振り返り

業務こなしての問題・気づき

書こう書こうと思って、結局、一週間経ってしまった。。。

MacOSのウィンドウ切り替えショートカット

Windowsみたいに、alt + tab で切り替えられるわけではない。

以下の2つのショートカットで同じことができる。 - cmd + tab アプリ切り替え - cmd + F1 アプリ内のウィンドウ切り替え

おそらくだが、アプリが大量に立ち上がったりすると、 1つのショートカットキーだと切り替えが面倒になるからではないだろうかと思われる。
最初、ウィンドウ切り替えができなくて、そうとう悩んでいたが、グルーピングされているのだと分かったら、難なく使えるようになった。

info.plist

実行時に必要不可欠な構成情報を記入するファイル
カメラの使用許諾とか、マイクの使用許諾とかが必要な場合に記載したりする。

tableviewのregisterをstorybordでやる

SwiftのUITableviewで、セルのクラスを設定するのは、下記のようにコードでやっていた。

tableView.register(MyCell.self)

今やっている製品の取り込みで、サンプルを見たときに、どこにセルのクラス設定があるのか分からなかった。
コードのどこを見渡しても存在しなかったので、storyboardで設定しているのかな?と思って調べたら、ビンゴだった。
具体的に言うと、Attributes inspector にある Identifier で設定できる。

なんか、こういうのを見ると、やるせなくなる。
どっちかに統一しないと、どこに何があるのか、初見だとかなり困惑する。
個人的には、配置・レイアウト以外は、なるべくコードに書いてほしいと思う。
GUIでやれるのはいいんだけど、なんでもやり過ぎると、可読性が下がる気がする。
少なくとも、プロジェクトで取り決めをしておくものではなかろうか?と感じた。

雑記

雨が多くて洗濯物が乾かないのがつらい。。。
衣食住で、衣には、あまり金をかけない主義なので、着る物がなくなるのが怖い。
洗濯忘れとかすると、命取りだから、気をつけないとダメだな。

ビニール傘しか持ってなくて、全部、何かしら曲がってるから、新しい傘をかった。
3000円以上したいい傘。
新しいもの買うと、使いたくなる性分なので、結構、雨の日が多くても楽しんでる。
気分転換に、みんなも傘買えば、雨の日も楽しめるんじゃなかろうか?

2019/07/08週 気づきと振り返り

業務こなしての問題・気づき

Swiftのコードでレイアウト調整

JavaのSwingを弄ってる感覚に似てる。。。

イベント付与は、最初の頃、GUIでやってたけど、「今、何がどうなってるのだ?」が分かりにくくて、コードでイベント付与するようにした。
ここも、JavaのSwingを連想してしまう。。。

どこも、GUIが必要なものは、同じ苦しみを味わってしまうのだろうなと感じる。。。
HTMLライクなレイアウト調整だったら、既存の知識を活かせるから楽なんだけどな。。。

やっぱり、最初にやる苦痛は、歳を重ねるに連れて大きく感じるようになってきた感じがする。
おそらくだが、できたときの喜びの感情が、最初の頃より薄れて来ているのだろうなと思った。

extensionにプロパティ

Swiftにextensionというクラスの分割記法があるのだが、プロパティは、本体のクラスにしか持てない。

せっかくカテゴライズ・グルーピングしたのだから、プロパティも分けられるといいのだがな。。。
おそらくだが、変数が散らばることで、衝突するのが嫌だったから書けなくしたんだろうなと推測。

でも、このグルーピングの考え方自体は、嫌いじゃない。
イベント記述が多くなりがちで、クラスが肥大化するので、こういう記法でなるべくグルーピングするのが、可読性に直結するのではないかと思った。

雑記

KPTからYWTへ

こう見えても、チームのリーダーなの。
毎月、チーム内でKPTで振り返りしていたが、どうもやりにくくて辞めた。
代わりに、YWTを適用するようにした。

辞めた理由としては、何が身についたのか分かりにくい。
だから、助言がやりにくい、反省ベースになりがちになる状況だった。
あと、結果に対しては、KPTで振り返りでもいいんだけど、業務が現在進行系なので、KPTが適用しづらいってのもある。

まだ、YWTどういった効果があるかは見えてないが、話の進め方は楽。
「やったこと」→「わかったこと」の流れで話をするので、助言する側もある程度、知識とやっていることの推測ができるので、提案ベースの助言がしやすいと思った。
あと、人事考課の参考資料にしようと思ったので、分かったことが見えるのが、立場的に重要だったので適用した経緯がある。

新組織

配下メンバーが変わってしまった。。。
全員、新人ですよ。。。
しかも、IT関連ではない学部の人達ですね。。。
話が通じるのか、一抹の不安がある。

iOS

とうとうwindowsを卒業して、iOSの開発環境、つまり職場でMacを使うようになった。
元々、家でMacBook弄ってたので、操作は全然問題ない。

使ってて楽だったのは、Githubとのやり取り。
git標準装備のmacは、初動が早くて助かる。
あと、homebrewでライブラリ管理できるのは、やりやすい。
windowsだと、chocolateyがあるが、イマイチ流行ってない気がする。

mac bookデュアルディスプレイで開発しているのだが、chrome+vimium環境が最高だった。
トラックパッドで操作すると、どうしても移動がキツイ。
なので、xcode上にカーソル残したまま、ウィンドウ切り替えとコマンドで検索できる環境が、すごく快適だった。
たぶん、mac bookiは、仮想ディスプレイ使って開発するほうが多数派だと思うけど、デュアルディスプレイにするときは、なるべくコマンドで操作できる環境にしたほうがいいと思った。
firefoxは、何かしらアドオンありそう。edgeは、たぶん、ないでしょうね。。。

2019/06/24週 気づきと振り返り

業務こなしての問題・気づき

AARファイル

Androidプロジェクト用のライブラリをまとめたフォーマット。
zip形式で、Android 固有のアセット、リソース、AndroidManifest.xml などを含めることができる。
バイナリファイルも含めることができる。
なので、Androidのネイティブ実装(C++の実行ファイル)を入れられる。

グループ会社製品のネイティブ実装を複数件取り込むために、利用した。
最初は、本プロジェクトにNDKで入れようとしたけど、今後、製品のソースが手に入らないケースがあるかも知れないから、AAR作ったりしてた。

サンプルが動いて、俺の実装が動かない

Androidのサンプルプロジェクトを参考に、ネイティブ実装込の実装をしたが、動かないという事態に陥った。
原因がまったく分からなかったが、サンプルと俺の実装の成果物(ビルド後のapkファイル)の中身を比べて原因が特定できた。
原因は、改行コードが違ったから。
改行コードのために1週間近く悩んでいたのが、腹立たしい。。。

雑記

マジで何なの?windows
改行コードをLFで統一して欲しいわ。

原因に気づいたときは、俺って天才?って思ったけど、後々になって、段々と腹が立ってきている。

CRLFなんて存在しなければ、悩む必要なかったじゃん!って思うんだよね。。。

たぶん、この一週間で、髪の毛が随分抜けたと思う。
嫌だよ。。。。
剥げたくないよ。。。

今週で嬉しかったのは、ボーナス出たくらい。
働いてきた中で、一番ボーナスが出た気がする。
増税前に、nintendo switchでも買おうかな?
ゼルダやってみたい。
あとは、ポケモンの新作待ちかな?
Z技やメガシンカが廃止になるらしいから、復帰しようかと考えてる。
ただ、特定のポケモンが連れていけなくなるのはなぁ。。。。
データ容量の問題なのかな?
だったら、もうPS4で出したほうが良くない?