そういえば、Gitに飢えている

いま、スクールでGitの勉強をしているが、簡単ではない。簡単にプロジェクトのファイルをいじれるので壊すことも容易である。さまざまなケースを想定して動かさないといけない。いざ現場に入る前に覚えることがたくさんある。

リモートとローカルで別々にログやファイルが管理されるのも難しい。それらを同期するルールも難しい。履歴も細かくいじれるので、そのぶんやり方をたくさん知っていないと対応できない。現場によってどの機能をどのように使うかは違うと思うので、その場その場で対応するにはしっかりした基礎力が求められる。

Gitめんどくさいなー。とばしちゃおうかなー。そう思っていた私は、"はた"と、ある思いに至る。

そういえば私はGitに飢えている。

ファイルのバージョン管理はプログラミングに限らず、あらゆるオフィスワークに付きまとう問題と思う。毎日エクセルの資料ばかり作る事務職だった時、バージョン管理はファイル名でおこなっていた。「管理表200117.xls」「管理表200117_2.xls」「管理表200118_最新.xls」とかいうやつ。

やり方は属人的ルールに基づいているので、ファイル名をみたところで、どれを印刷したり改変したりしていいのかはわからない。ファイルを作った人に聞くしかない。最悪の場合作った人もわからないので、中身を見て判断するなり、細かい内容を一つ一つ確認しなければいけない。

ITエンジニアはGitという便利なバージョン管理ツールを使っている。一つファイルに対し、ツールが変更履歴をつけてくれる。フォルダごとに管理され、どのファイルをだれがいつ作ったもわかるし、テキストのどの位置を修正したかもわかる。だれか偉い人に改編の許可をもらうときもメールでいちいち説明キャプチャを張り付けたエクセル資料を作ってzip化してパスワードと別々に送信する必要もなく、直接改変のリクエストを送るシステムが備わっている。

私はプログラミングを勉強してITエンジニアを目指したとき、このGitさえあればいままでバージョン管理にかかわる大きな手間や失敗、試行錯誤などが一切必要なくなることに大きな期待をしていた。しかしいざエンジニアとして業務を始めると、この界隈でもGitを使わない会社がたくさんあることを知る。それも誰でも知っているような超大手メーカーのソフトウェアベンダーでもそうだった。いやむしろ、たぶん超大手だからこそGitを使わないのだ。Gitを使わない理由は知らない。比較的新しいものだから導入に踏み切れないのか、全員に強制的にやらせるのが難しいのか。

そのような現場体験を通して私はGitに飢えた。

それらの現場では、同じファイルを複数人がいじらないようにするというルールを基本としている。ただしこれも誰が何をいじっているかを何らかの書類で管理する必要があるし、工期が迫っていたりして一緒にいじる必要性が出てきたりする。その場合その時々で様々なルールが作られる。ファイルを細々と分割したり、色分けしたり、ファイル名で分けたりする。出たとこ勝負でなんとなく最終物ができる。マージを行う際にも各人が同じルールで作成していなかったりして、結局そのプロジェクトや人間間だけで特有の問題に対処するスキルが磨かれる。少なくともバージョン管理に関してはスキルアップしているとはいえない。

大きな問題は「デグレ」である。プロジェクトの途中でサーバ名が変わるとする。サーバ名を指定する箇所を修正する。同時にテスト工程が進んでいる。そのために最新のコードがテスト環境に送られる。そこで、一行だけ古いサーバ名のままだと判明する。その場で直して、テストは無事終わる。別の機能が追加される。別のテストが行われる。あれ?古いサーバ名が更新されていないほうのファイルで追加の機能が実装されているようだ...。次のテストでも同じところでプログラムが止まる。このような問題が、あとからあとから複層的に積み重ねられていく。テストを何度も繰り返すことはできない。テスト仕様書をながめながら、怪しいところを目視したりしてチェックする。おっともう納期が来た。えい、リリースしてしまえ。こんな感じである。

Git以外のツールを使ったこともある。Subversionというソフトだ。これを初めて使ったとき、デグレ地獄の現場から移ったばかりだったので正直感動した。みんなで同じファイルをいじっても大丈夫。どこの部分をいつだれが変えたかわかる。しかしこれは組織の問題だが、Subversionはリリースしたもののみを置く場所だという運用がされていた。開発中のファイルをアップロードしてはいけないのである。????なんでそんなことになっているのかわからない。過去に、開発中にリポジトリが全部消えたとか、何か障害があったのだろうか。しかしそのルールすら徹底していなかったので、チーム内でこっそりSubversionをつかっていたので開発はスムーズだった。ただし、そんな状況なのでIDをきちんと割り振られていない。みな同じIDを使いまわして開発していた。これはこれで問題がある。

さて、そんな状況だったのでGitをちゃんとつかっている現場というものに対する強い憧れが募っている。Gitに飢えている。

なんかめんどいので、適当におさえて現場で経験を積めば何とかなるかー、という怠け心をぐっとおさえて、そういえば自分はGitに飢えているのだったと思い返して、丁寧に勉強せねばと思い返す。

でも、多くの会社で浸透しないのは単純に難しいからなのかなー???

 

 

Fjordブートキャンプはスパルタではなかった

以前Fjordについて調べた時、ハチャメチャにスパルタで毎日泣きながら頑張らないといけない、という記事があった。正直その記事にかなりびびっていて、無料期間の3日のうちにやめるのはありうる、と思っていた。

自分は開始時12月31日にブログを始めて2日で止まってしまったから、3日でやめたかのように見えるので、そうじゃなかったことをここに書き記しておかなければならない。

現状、BootCampのカリキュラムは毎日こなしている、HTMLをやり、CSSをやり、Linuxを導入したサーバを立てた。

始めは恐る恐るであったが、そしてまだ1週間ちょっとやっただけなので、全容は分からないが、すでにメンターの方々や生徒間の交流はあって、小規模ながら非常に活発なコミュニティであることがわかった。

しかしながら、スパルタという形容はまったく当たらない。確かにカリキュラムは簡単ではないが、初歩の段階を一歩出たくらいで、プロになるにはそのくらいは当然できることを教えているだけの、そんな難易度だ。

自分は、形はどうあれシステム周りで2年仕事をしてきているので、そのくらいのハードルがちょうどよかったというのは確かにあるとは思う。かなり心地よく勉強できる環境だという感想だ。

質問をするとこれでもかという丁寧な答えが返ってくる。積極的な書込が称賛され、コミュニティのクオリティを高めることになるので、とお礼まで言われる。

課題はドキュメントにあふれていて、一から情報をすべてかみしめていると終わらない。しかし、すべてのドキュメントを頭に入れる必要はない。自分が欲しいものだけを取り入れて、成果物さえできてしまえばよい。

他のプログラミングスクールも検討していたが、少なくとも数10万円とられるようなスクールに入るくらいなら、Fjordブートキャンプは月3万円くらいでかなり高度なウェブアプリのカリキュラムが受けられる&積極性があればコミュニティに入って行って界隈の仕事につきやすいというメリットがある(はず)と思う。スクールに迷っているならためしに1か月でも(3日でも)Fjordをやったほうが確実にためになると思う。

ブログで書くことの列挙

Fjordブートキャンプは最初にSNSへの登録を推奨されて、Slackで自己紹介をするという課題がある。そういうきっかけがあって、はてなブログを始め、twitterの新規アカウントを作り、Facebookを10年ぶりに開き、ついでにGmailも新しく作った。

 

なるべくアウトプットをすることが学習を能率的にするというので、このブログを定期的に更新したいとは思っているけれど、これは継続できるか個人的にかなり怪しい。

 

何か書くことがあるかなー、と思い、とりあえずトピックだけまとめてみる。

・エンジニアとしての略歴

・エンジニアの前にしていたこと

・WEBとWEBじゃないエンジニア

N予備校の勉強(日々)

・Fjordの勉強(日々)

とりあえず、5日以上は持つかも...。

 

Fjordブートキャンプ開始

Fjordブートキャンプは難しいという評判があったので、とりあえず、自分にとってふさわしいハードルの高さかどうかを見極めるのが初めの課題。

 

3日の無料期間、1ヶ月目を当面の節目として今後の目標設定をしていきたい。