再・続・GitHubに再入門した

前回(続・GitHubに再入門した)、前々回(GitHubに再入門した)の続きである。いいかげん今回で終わらせる。

やったこと一覧

# GitHubのアカウントを作る
これはすでに作成済み & 記録が残っていないのでスキップ。というかそこすらもわからないならGitHubの利用は諦めたほうが良いと思う。とりあえずWebページのあっちこっちを触っていればなんとかなる。

# SSH鍵を登録する

  1. 画面右上プルダウンからSettingsを選択
  2. 画面左側メニューから、SSH keys を選択
  3. SSH鍵をアップロード(テキストボックスに貼り付け)

セキュリティを要求されるのは更新系の処理だけなのだから、そんな頻繁にGitHubにアップロードしない僕としては、そこはパスワード認証でも良い気もするのだけど、今回は鍵を登録してみた。

ちなみに、過去挑戦しては挫折した名残として、当時使用していたSSH鍵が、"unverified due to lack of use"という形で、verifyするまでは使用できなくなっているようだった。

# ローカル環境でgit の初期手順を済ませる
我が家は

の2つがある。ここからはFedora でやったであろう作業を、history コマンドを元にLubuntu で実行しながら書いていく。

git の初期手順としては、
必須

$ git config user.name "僕の名前(書式は自由っぽいので、"MYOUJI, Namae"で記載した)"
$ git config --global user.email "僕のメールアドレス"

オプショナル

$ git config --global core.editor エディタ(貴方のエディタは? 私はvi!)
$ git config --global color.ui auto

GitHubへの接続確認(GitHubはシェルによるアクセスを想定していないのですぐ切断される)

$ ssh -T git@github.com
Hi kwy8791! You've successfully authenticated, but GitHub does not provide shell access.

だったと記憶している。「必須」の2つも実はなくても大丈夫じゃないかな? 別の機会に試してみよう。

# Web からのリポジトリ作成
これも記録が残ってないのでスキップ。やっぱりGitHubのWebページからやったはず。

# ローカルマシンへのgitリポジトリのコピー
GitHubのWebページを舞台とするなら、その舞台裏、設備の修正やらなにやらをやるのがローカルマシン上のリポジトリ、と理解している。それを作るためのコマンドが以下だ。

## GitHub のファルをローカルと同期する「鈎」を作る

$ git remote add origin git@github.com:kwy8791/system_tools.git

## GitHubリポジトリをローカルに引っ張ってくる

$ mkdir -p ~/mydev/github_working
$ cd ~/mydev/github_working
$ git@github.com:kwy8791/system_tools.git
$ git clone git@github.com:kwy8791/system_tools.git

## 中身を確認してみる

$ pwd
/home/kwy8791/mydev/github_working/system_tools
$ ls -lad .git
drwxrwxr-x 8 kwy8791 kwy8791 4096  118 13:29 .git
$ ls -la .git
合計 52
drwxrwxr-x 8 kwy8791 kwy8791 4096  118 13:29 .
drwxrwxr-x 3 kwy8791 kwy8791 4096  118 13:29 ..
-rw-rw-r-- 1 kwy8791 kwy8791   23  118 13:29 HEAD
drwxrwxr-x 2 kwy8791 kwy8791 4096  118 13:29 branches
-rw-rw-r-- 1 kwy8791 kwy8791  264  118 13:29 config
-rw-rw-r-- 1 kwy8791 kwy8791   73  118 13:29 description
drwxrwxr-x 2 kwy8791 kwy8791 4096  118 13:29 hooks
-rw-rw-r-- 1 kwy8791 kwy8791  264  118 13:29 index
drwxrwxr-x 2 kwy8791 kwy8791 4096  118 13:29 info
drwxrwxr-x 3 kwy8791 kwy8791 4096  118 13:29 logs
drwxrwxr-x 4 kwy8791 kwy8791 4096  118 13:29 objects
-rw-rw-r-- 1 kwy8791 kwy8791  107  118 13:29 packed-refs
drwxrwxr-x 5 kwy8791 kwy8791 4096  118 13:29 refs

利用者が意識することはないだろうけど、この".git"ディレクトリの情報でバージョン管理をしているようだ。それにしてもUnix系のツールは".hoge"という隠しファイルや隠しディレクトリで設定情報を管理したがることが多い。何かルールでもあるのだろうか? それともただの慣習なのだろうか? 有識者がいたら伺いたいものである。

## ファイルを修正/追加した後、アップロードする

$ git add post_install_OS.sh 
$ git commit -m "ad func to shorten msg output"
$ git push origin master

## もう一台のマシンに戻って、GitHubに加わった変更をローカルマシンのファイルに適用する

$ git pull

今のところはこれだけしか知らないし、これだけで足りてる。また知らない機能を使う場面に遭遇したら、昨日挙げた本などを参照して、使えるようになっていきたい。

あ、wikiは便利そうなんで早速使った。

以上、3回にわたって長々と書いた割りには内容の薄い記録である。

続・GitHubに再入門した

前回(GitHubに再入門した)の続きである。今回こそ、前回書きたかった作業メモを書く。 → 無理だった。今回は本の紹介。ほんの紹介。

手を動かす前に本を読んだ。

小学生のドリル、中高生の問題集のような感じで、本を呼んでは手を動かす、の無限ループをするのが手っ取り早いかなぁ。と思ったのだが、過去それでGitHub入門できなかった & 未読のGitHub本が手元にあったので、まずはその本に手を出した。

結果、「その本は、手を動かしながら読む本ではなかった」と言うだけの話である。

以下、読んだ & 読んでいる本を紹介する。

1冊目:『Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール』
Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール

GitHubとGitは、JAVAとjavascriot程にではないが別物、という認識もあったので、GitではなくGitHubの本から入ることにした。この本は、たまたまtwitterで追いかけていた人が著者の一人に名を連ねていたからという理由で買ったまま積んでいた。僕は割と、こういう「こっちが勝手に知ってる人の本だから、今は必要ないけど買ってしまおう」という購買行動を取りがちなのだが、今回に関してはその性向が幸いすることになった。

そしてこの本だが、「本を読みながら手を動かす」タイプの本ではなかった。ケーススタディ集とでも言えば良いのだろうか。「GitHub利用時につまづく所あるある集」と言った内容で、GitHubの利用ケースをイメージ出来て、とても参考になった。

一応Amazon アソシエイトのリンクを貼った(とは言え収入は僕ではなく、はてなにいくのだけど)ので、ふと買ってみたくなった人のために注意点を書いておく。

  • 前述の通り、実際に手を動かしてみる類の本ではない
  • 近くにGit/GitHub有識者がいる前提(Git / GitHubの機能詳細については触れられていない)

あくまでも、「GitHubを利用したWeb制作の雰囲気を感じる本 / GitHubの使いやすいところをつまみ食いする本」であり、GitHubガリガリ使い倒す人向けの本ではないと感じた。

(個人の感想です)

2冊目『GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)』
GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

文体は硬いけど内容の濃さには僕の中では定評のある「WEB+DB PRESS plus」シリーズ。こちらはまさに「手を動かしながら読む」タイプの技術書だった。

ただし僕にはこの書籍の全内容を手を動かしながら読むのは無理だった。とりあえず通読 → 頻繁に使いそうなコマンドだけ覚える → 分からないところが出てきた時にリファレンスとして利用する。という形で利用するのが僕に向いた使い方では無いかと思っている。(一応通読までして、今は頻繁に利用しそうなコマンドを覚えている所)

この本は、1冊目の逆で、「GitHubガリガリ使い倒したい人向けの本」なのではないかと思う。

3冊目『アリスとボブのGit入門レッスン』
アリスとボブのGit入門レッスン

アリスとボブのGit入門レッスン

GitHubに関してイメージが掴めてきたと感じたので、Gitそのものについて学ぼうと思い、今はこの本を読んでいる。

まだ読了していない。が、内容としては1冊目で紹介した『Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール』のGit版という感じだ。この本を読み終えた後、リファレンス的に使える本を読む、と言う形で学習を進めていきたい。


今日も本の話だけで結構長くなってしまった。実際に手を動かした内容については次の記事で書く。今度こそ書く。

GitHubに再入門した

再入門というか、過去何度か挑戦しては挫折してたので、懲りずにまた挑んでみた。ってのが正しい。年度初めのNHK ラジオ語学講座みたいなものと思ってもらえれば良い。


実は、RCS / VCS(それぞれ"Revision Control System" / "Version Control System"の略。要はファイルへの変更管理をやってくれる仕組み。以後はVCS と表記する)を使ったことが殆ど無い。IT屋さんを十年以上やっていてそれはどうなの? という意見には黙って土下座するしかないのだけど、実際のところ使わなくても仕事が回ってしまったのだからしょうがない。信じられないかもしれないが、本当にVCS に触れる機会が無かったのである。もっとも、正確には二度ほどVCS を使ったことがある。古い方から順に言うと、WinCVSを、2003年頃に半年ほど、SVN(僕が使ったのはTortoiseSVNというWindows用のGUIソフトウェアだった)を、1年ほど使用した。共にあるSIer(本社=首都圏、職場=首都圏、親会社=いる、下請け=やる、元請け=やる、客先常駐=やる、販社=やる、自社サービス=やらない)に所属していた頃である。


推敲もせずに思いつくままに書き連ねていくと、WinCVSを使った理由は、「所属していたチームが、誤ったファイルをライブラリ管理チーム(昔はいたのだ、こういう「みんなから預かったファイルを本番/試験環境に配置する、今で言うデプロイを専門にする部隊が)に渡してしまう」という、まさにVCS の導入例に出てきそうな理由だった。この時、元請けに出した再発防止策に「VCS を使ってリリースするファイルを間違えないようにします」という一文があったのだ。

そんな状況の下、大人たちの思惑が交差した結果、2000年問題による好景気の残り香にまぎれて、夜間文学部から会社に入社した役立たず(=僕)が、チーム内の変更管理担当を拝命することになったのである。

この時は各担当者の端末からWinCVSサーバーになる端末にアクセスさせる設定やらに悩んだ(多分ネットワークかリモートアクセスの問題だったと思う。どうやって解決したかも覚えていない)りしたが、まぁなんとかCVS が動く環境が整い、利用され、そのうち忘れ去られ、使われなくなっていった。当時のSIにおいて、運用フェーズのシステムで、VCS 使わなきゃならない程の頻度での変更は発生しなかったのである。ちなみに僕がいたのは「共通チーム」という、今で言うソフトウェア寄りのインフラチームで、ミドルウェアの提供するAPI を呼び出す関数を作成し、「この関数経由でしかこのミドルウェアの機能は呼んじゃダメ」と言いながら開発チームに関数を提供するチームだった。そりゃOS / ミドルウェアの更改でもなきゃ、ソースの変更なんてないわな。実際、バグフィックスか、設定ファイルの更新くらいしかなかったと記憶している。むしろOS / ミドルウェアの設定ファイルの更新のほうが多かったし、その場合は手順の中で「本番のファイル / 本番の設定値(動的に設定が変更されている可能性を考慮) / 更新ファイル」の比較が、ファイル更新前後に組み込まれていた。


同じような形で、SVN を使った経緯について書くと、これはシステム開発ルールとして、SVN の利用が強制され、かつ、Windows端末所持者にはTortoiseSVNの利用が推奨(ここは確か強制では無かったはず。ただ、TortoiseSVNに関しては導入手順書とかが整備されていた。多分元請けの推奨環境だったのだろう)されていたからだ。この時は運用フェーズではなく、システム更改フェーズ(しかも担当会社も変わる、プラットフォームも変わる)だったので、VCS が結構役に立った。当時所属したのはやっぱりインフラチームで、管理用のシェルスクリプトガリガリ書いていた。コンフリクト(複数人が同じファイルに変更を加えて、ファイルをどう更新したらいいかVCS が判断できなくなること)もこの時初めて経験した。とは言え、インフラチームは開発チームに比べて圧倒的に人数が少ない(開発数百人に対して、インフラは4人。うち1人はリーダー=折衝担当、もう1人は半も浮きのヘルプなので実質2人)ので、コンフリクトが発生しても、「○○くん、このファイル更新できないんだけど、なに変えた?」「あぁ、ここいじったよ」「了解」なんてやり取りで済んだ。ここまで書いて思ったけど、ここ変更内容の確認はVCS の機能で済ませとけよ。まぁ、つまり、当時便利だったのは「ファイルの変更履歴 / 内容を確認できる」ことだったのだろう。


その後、10年に10日足りないくらいの年数の間勤めたSIerを辞め、とある大手Web屋に転職したのだが、やっぱりVCS を使用することはなかった。svn などのコマンドを叩くことはあったのだが、それはデプロイ作業の一環として叩いているだけで、ただのオペレーター、変更内容を理解しての作業では無かった。


これまでSVNを利用してこなかった理由だが、これはやはり「チーム開発経験がない」「大規模開発経験がない」ということに尽きると思う。個人で小さなスクリプトをちまちま作るだけなら、「.日時」拡張子を使うだけで十分だし、それをUSB メモリに入れるなり、VPS やブログなどに書いておくだけで十分に用は足りる。っていうか、今でもそうじゃないかと思う。


じゃぁなんで今回またGitHubに手ぇ出そうと思ったの? と言われると、そりゃぁもう「RubyPythonが悪い」と答えるしかない。

ChefだのAnsibleだのCapistranoだの、果てはRHELの深いところまでPythonが浸潤して、多分もう取り除けないレベルにまで来ちゃってる。こいつらを追っかけないと、ソフトウェア寄りのインフラエンジニアは死ぬ。もう小型特殊免許と電験取って、サーバー(設置)エンジニアになるしかない。「冬場はラックに除湿剤入れて搬入しないと、結露してショートしてサーバーが死ぬんだぜ」とか言ってドヤるしかない。

しかしまぁ僕はコンソールの前に座るインフラエンジニアでいたい。じゃぁRubyPython読めるようになって、インフラ側に降りてきた開発言語と、その中身を理解するしかない。これがGitHubに手を出そうと思った理由である。


なんか本題のGit と関係ない話だけで長くなっちゃったな。続きはまた今度。実際になにしたのかを書く予定。

(ついでに「昔話」ってカテゴリー作って付けた)

いつまでも新技術をキャッチし続けると言うことの難しさ

先日twitterで、「昔はすごいエンジニアだと思っていた人だったのに、最近の技術を信用できてなかったり、いまだに古い道具使ってる、哀れだ」みたいな投稿を見かけて、ちょっと反論したいな、思ったことについて。引いた文と言及は前後するが、それは僕が思った順番に書いているためなので勘弁して欲しい。

「いまだに古い道具を使っていて哀れだ」 → 道具至上主義に陥ってないか?

最初に思ったのがこれ。あるいはマズローの「金槌を持てば全ての問題が釘に見えてくる」ということを最初に思った。思うに「いまだに古い道具を使ってる」と言うところに反応したのだと思う。別にgit使うとsvncvs, SCCSを使ってる人より偉くなれるわけではないと思う。まぁいまだにSCCSを使っているのはさすがに想像しがたいが。

「最近の技術を信用していない」 → 最近の技術を必要としない場で一生を終えるつもりでは? / 言うほど新しい技術ってあるか?

こっちはまぁ順番に

  • 最近の技術を必要としない場で一生を終えるつもりでは?

消えろとか消えるとか言われたCOBOL はまだまだ生きてるし、これまでの野良ライブラリもあって、FORTRAN もなんとか生き延びてるらしい。「らしい」というのは、伝聞であって僕が実際に体験したことは無いからだ。なにはとまれ、一旦産まれるとなかなか消えないものというのは少なからずあるし、本人が「いまさら新しい技術を覚えるより、習得済みの技術を磨いたほうが価値を残せる」と思っている可能性もあるのかなぁ。などと思った。

  • 言うほど新しい技術ってあるか?

こりゃまぁ完全に主観だけど、僕世代から見ると、DB 技術は関係DB が親で、NoSQL というのもでてきたけど、それも関係DB からメリットを抜き出す代わりにデメリットを押し付けているものに見える。仮想化だって、実現方法の違いはあれど、メインフレーム時代からあった概念だと記憶している。価格や処理能力の点で驚いたことはあったが、技術的な面で、根幹を揺るがされるほどの衝撃を受けたことはない(僕の情報感度が鈍い可能性も否定出来ないが)。
もちろん「できたら良いな」が「できる」になったことは素晴らしいし、「できる」となったら手を出したくなるものだけど、やっぱり「習得するまでの時間」と「自分の賞味期限」を天秤に書けてしまう部分はあると思う。
あれ? 結局一つ目と同じことを言ってるのかな?


まぁとりあえず、そんなことを書き捨ててみる。僕もおっさんになって、「いつまで新しい話題についていけるか」が不安になったということか。
将来見直した時に赤面しないといいな。

 これまで、技術ネタのメモ帳としてここを使ってきていたが、この一年、休職するという状態(厳密にはその前にもやはり一年近く休職している)になり、あまり実践的なことは書けそうにない。
 そこで、一旦「技術ネタ」という縛りを外して、ただの「ネタ」になりそうなことについて書いてみようと思う。書くことの訓練にもなるだろう。



 (これだけ書くのに30分かかるほどに衰えた)