Rubyをはじめて学んで調べたところ
はじめに
Ruby on Rrailsの起動まではうまくいきました。 実際のプログラミングに入りたいと思いますが、まずRubyの基礎を勉強していく中で謎だったものご紹介したいと思います。
moduleとは何者か
これははじめ何者か...と思いました。 class持っていたりmethod持っていたり、そういう立ち位置のものかと理解はしました。
調べると、正確にはインスタンス化できないものです。 そして、それをincludeすることでmixinを実現するという流れです。
class SearchProduct < Product include ProductModules def price @price = 1000 end end
attr_reader, attr_writer, attr_accessorとは何者か
これはどうしてこういう仕様になったのかちょっとわかりませんが、アクセスを制御するような関数なのでしょうか。
attr_readerならgetterのみ、attr_writerならsetterのみ、attr_accessorなら両方というかんじだと思います。
イミュータブルなクラスを作るにはどうしたらよいのでしょうか。
何やら参照先で hoge= Hoge.new.freeze
みたいなおまじないをするとイミュータブルになるようです。
initializeをオーバロードできない
このあたりも言語の仕様的に初期化は1つであとは、代入的なものはメソッドでやってください、という明示なのでしょうか。 下記のようにfactoryメソッドを作って、newして代入していくという形になるっぽいです。
def self.create(price, tax) price = self.new price.value = price price.tax = tax return price end
まとめ
はじめに疑問だったところはこれぐらいで、あとは他の言語やオブジェクト指向の経験があれば雰囲気わかるかんじでした。 それだけRubyが簡潔な言語なんだなと実感しました。 ただ、DB操作やmixinや並列処理、APIの実現などもう一歩入ったところは次回取りかかれればと思います。
Ruby on Railsをはじめて環境構築してみた
はじめに
Ruby on Railsのアプリケーション開発をしようと思い、インストール〜起動をしようとしました。 いくつか苦戦したところがあったので、ちょっとメモしていけたらなと思います!
構成
苦戦したところ
インストール
rubyとrailsのバージョンがあっていなかったようです。 あと、RubyMineで最初に設定したrubyのバージョンも違ったりbundleというものにバージョンも違ったり、 色々うまくいっていなかったので起動できなかったというのがありました。
下記、インストールメモ。
rbenv install -l rbenv install -v 2.6.6 rbenv rehash rbenv global 2.6.6 sudo gem install rails rbenv exec gem list | grep bundler gem install bundler -v 2.1.0
BundlerとGem
yarnやnpmかと思いきやbundleというものがいて、 bundleがgemの依存関係を管理しているようなイメージでしょうか。 そのあたりの理解はできるのですが、やっぱりこのあたりは言語を学ぶときに壁になるところだよねあと思いました。 オープンソースが進んだ現代では致し方ないといいますか、必須知識にすらなる部分なのでしょう。
path設定
pathの設定がMacのデフォルトのほうを向けていました。 そのせいで、railsのインストールが全然できないということがありました。 pathにはbrewでインストールした場合、下記を設定しないといけなかったです。
export PATH=${HOME}/.rbenv/shims:...
pgがない
ネットを調べるとposgresqlがないとインストールできないような状況らしいです。 どれかのライブラリが依存していたのでしょうが、pgではわからないので、はっきりとposgresqlと出てほしいところです。
構成理解
railsの構成については、他のMVCパターンだったり、Webアプリケーション開発をしている人なら大方理解できるかなという感じに思いました。
- app
- アプリケーションに関するモジュールを置く。ここがメインになるのでしょう。
- bin
- 起動シェルなど。ここでお決まりのおまじないから、プロジェクト独自のおまじないいろいろシェルに書いていくのでしょう。
- config
- 設定ファイル系。configuration系なので、アプリケーション起動に必要なものは全てここに配置すると思われる。
- config.ru
- db
- lib
- 不明
- log
- ログを出力する。
- public
- 静的ファイルを配置する。
- test
- テストを配置する。
- vendor
- サードパーティを配置する。
- Gemfile(Gemfile.lock)
- ライブラリの依存関係を記述したもの。
- Rakefile
- コマンド的なことを記述していける場所っぽい。どこかでrakeコマンドを叩くと効率いいタイミングってあるのかな。
- .ruby-version
- rubyのバージョンを記載するだけっぽい。gemファイルにあるしいらないのではと思うが、そうではないのであろう。
まとめ
バージョンについては苦戦した。ここで脱落していく人もいるのかなと思います。 Pathの設定や謎コマンドの打ち込みなどを乗り越えて、ゴールかと思ったらエラーになり先に進めない...となるケースも多いかなと思いました。 ここはネット情報で乗り越えるべきところかなと思いました。
ただ、おそらく私は説明書を読まない&Mac環境をごにょごにょいじっていたりするので、しっかりネットにあるインストール方法を読み、プレーンな状態からのスタートの場合はうまくいくというケースもあるのかもしれません。
でもバージョン周りで苦戦すると構成について理解が深まるのでそれはそれでOKと割り切りが必要かなと改めて思いました。
現場で実際に使うGitコマンド
はじめに
Gitコマンド使っているでしょうか。 現在だとSourceTreeやGitHubDesktopなど数々のGUIがありますが、現場ではコマンドを使うことが多いかといるかと思います。 でも、便利なGUIがあるのに使わない理由とは何なのでしょうか。 おそらくですが...
とかでしょうか。けっこう最後のかっこ悪いを意識している人もいますね。
コマンドで何ができるの?
では、Gitコマンドで何ができるのって話ですが、GUIでできていることほとんどできます。 GUIのほうが便利なシーンもありますが、それは稀なので、稀なときにGUIを使って、普段はコマンドで十分用をなします。 では、コマンド見ていきましょう。
ほとんどこれだけ
git init
GUIだと連携しているGitHubプロジェクトから簡単に持ってこれるので何も意識しないでしょうが、 コマンドだと、まずgit initしないとその場所にgitプロジェクトを展開できません。 まずこれをおまじないとして実行します。
git clone git@github.com:userName/repositoryName.git
こちらもGUIだとただポチっとするだけですが、コマンドでは、cloneというものを実行します。 これでそのリポジトリを持ってこれます。
ここまでは、確かにGUIでやってもいいですが、慣れるとコマンドほうがスムーズにいくことも多くなると思います。
git checkout -b feature/hogehoge
ブランチの作成&チェックアウト同時にします。
- ブランチ ... その親ブランチ(masterやdevelopといったもの)から枝をはやします
- チェックアウト ... 現在あなたがいる居場所を移動します。
git branch feature/hogehoge
でもブランチを作れますが、そのあとそのブランチに自分の居場所を移動する必要があります。
それを同時にしてくれるのがこれです。
git status
現在の状態を見ます。 変更点の確認で多投すると思います。
git pull
リモートの状態と差異があるとき、ローカルを最新にしたいです。そのときはこれ。 pullはfetchとmergeというものを一気にしてくれるコマンドで、ほとんどこれだけで用をなせます。 ここの中身の仕組みは知っておくと理解が深まるかと思います。
git add .
変更したファイルをインデックス(コミットされる情報)に追加します。
git reset HEAD git reset HEAD core/src/main/resources/application.properties git reset --soft HEAD~ git reset --hard #コミットid
resetは色々取り消すときに使います。
- 1番目は、インデックスを取り消します。addをミスしたので全て取り消したいときなどに使うことが多いです。
- 2番目は、特定のファイルのみaddを取り消します。これも変更不要なファイルをaddしちゃったときによく使います。
- 3番目は、コミットの取り消し時に使います。変更している内容は残るので安心コマンドです。
- 4番目は、コミット、インデックス、変更内容もすべて取り消します。コミットidはログから追えます。git revertという便利コマンドでもできますがログが残らないので注意です。
HEADとかHEAD~の仕組みは知っておくと理解が深まるかと思います。 HEADは現在地、HEAD~は現在地から1つ前、HEAD~2なら現在地から2つ前、といった意味です。
git commit -m "fix: refactoring shopping cart controller"
そしてコミットはこれ。 これでようやく、ローカルリポジトリに反映されます。 まだリモートリポジトリには反映されていません。
git commit --amend
コミットがいくつもできるとログが見にくくなります。 同じ領域の修正なら1つのコミットで集約するべきです。 そんなときにはこれ。これで、1つにコミットに集約できます。
git push
番外編
git stash
あまりstashは好まれない傾向のようですが、急ぎのときは私も使います。 ちょっとした調査が入り、修正前の状態にすぐにブランチ切り替えたいときに、stashです。 一時的に保存しておき、調査が終わったら戻すかんじです。 本来はcommitですべて補えますので、stashは本当にそんときの気分次第かもしれません。
git branch -d feature/hogehoge
ローカルブランチの削除です。 よく使うわけではないですが、ブランチが増えてきての削除のときに使います。 または、どうしてもブランチが元に戻せないなど、困ったときはこれでチャラにしたりも数年に数回あるかもしれません。 あるなら、hotfix的な対応が入ったときや、複数開発が動いているとどうしてもブランチ管理が複雑になるときがあり、そういうときはあるかもしれません。
git log --graph
コミットのログを見たいときはこれ。 このあたりはいろいろプロパティあるので、もっと見やすくできたりします。 ログに関してはGUIが勝っているので、そちらを見るのがいいと思います。 ちょっと見たいぐらいならコマンドでいいのではないでしょうか。
まとめ
他にもrebaseやconflictマージなど難しいものもありますが、それは多投するわけでもないので今回は省略します。
あと、gitコマンドをaliasに登録することで、毎回長ったらしいコマンドを打たなくてよくなります。
git log --graph
は glg
など。
でも、現場開発での8,9割はここにあるコマンドで開発できちゃうのが現実です。 Gitの1,2割しか使っていないのではないでしょうか。やはり、プログラミングでも実際によく使われるのは2割です。 現実はそんなものなんだ、となってもらえればと思います。
フリーランスの優位性
はじめに
フリーランスには以下の3つが有利かなと思っています。
- 鮮度抜群
- 人間関係
- 実力主義
鮮度抜群
鮮度抜群というのは、より最新の技術に触れる機会を自ら作りやすいということです。 IT業界は1〜3年で新しい技術に入れ替わる世界。その中で、1社にとどまっているとどうしても古い技術をやらざるを得ないときが多いです。エンジニアはマンネリ化してきます。新しい機能追加をしているのだが、技術は古いまま。エンジニアとしてはスキルが低下してしまいます。フリーランスは、より自由に職場の選択が可能です。
人間関係
人間関係とは、煩わしい人間関係を気にする必要がないということです。 会社とは気の合うやつもいれば、受け付けないやつもいるのが現実です。正社員となると、その中でストレスを抱えながら社内の無駄な権力闘争に巻き込まれたり、お酒の席では愚痴ばかりということを経験している方も多いかもしれません。しかし、フリーランスとなれば、そういったものは限りなく最小限に抑えることも可能です。自分の一緒にいたい人とだけコミュニティを作ればいいと思います(ここで言う一緒にいたい人とは、ただ好きな人というわけではなく、自分を成長させてくれる人という位置づけが大きい)。
実力主義
実力主義とは、実力がなければ切られる、うまくやれば重宝されるということです。これは非常にわかりやすく、フリーランスはそこをまず見てもらって評価してもらえるのがいいところです。正社員では、年功序列、在籍年数、肩書...いろいろな要素がまだまだ優先されてしまうかと思います。
まとめ
日本でフリーランスという形態が今後増えるという予想ですが、その中で本当のフリーランスの良さを活かしていける人になれるよう努力する必要が今後は必須かなと思います。
現場で使える!? エンジニアが必ず覚えておきたい3つの法則
結論
ここでご紹介する3つの法則を意識して開発しているだけでも結論から言うと、
- 開発の品質は向上します
- 実際にマネージャやクライアントからの信頼も高くなります
ということが得られると思っています。 3つとも非常に有名な法則ですが、実際現場では何をやればいいのか...とかちょっとわかりにくいところもあるので、 実際に現場レベルではどういう話になるのかを落とし込んでみたので、ご紹介します!
ブルックスの法則
遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである。
この法則のテーマは、MVPを考える大切さです。
たとえばアプリ開発が大幅に遅れており、5機能ぐらいやってもらえる人材を追加したいとします。 「はい!5機能やってもらう人探します!」は思考停止です。 その5機能が本当に必要か...その他タスクでいらないものはないか...モリモリ状態(やりたいことが詰め込まれている)ではないか...。 遅れているプロジェクトです。冷静に縮小を考えてみてもいいのではないでしょうか。
MVP(Minimum Viable Product)という考えを持つと下記のようなことが考えられます。
- スケボー:5機能のうち3機能はいらない。必要な2機能について簡易実装版を出す。 (これなら現状の人員でできる!)
- 自転車:必要な2機能について改善版を出す。
- バイク:不要だった3機能について、簡易実装版を出す。
- 自動車:必要な5機能すべて揃う!
ソフトウェアの7,8割の機能はほとんど使われないと言われています。いらない機能です。 いらない機能をあぶり出し、本当にいるものだけをリリースするという癖を組織としてつけることが開発というか仕事のミソでしょうか。
ハインリッヒの法則
1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する。
この法則のテーマは、リファクタリングの大切さ。 1つの重大なバグの背後には29の軽微なバグが存在し、軽微なバグの背景には300のコーディング上の問題がある(不適正なコメント、わかりにくい命名、重複コード、スペルミス...)。
大切なのはそういったコードを見過ごしている意識、環境であると思います。 そういったコツコツ系の小さな仕事でも大切にするエンジニアがシステムを守っているということを忘れてはいけません。
プログラミングだけではありません。システム開発でもこの法則が頭にあるのかはすごく大事です。 7payのセキュリティ問題も、推測ですが、組織体制・コミュニケーション・納期・リーダースキルなどの異常・軽微な不具合があり、インシデントにつながったと思っています。 組織のトップの方の記者会見やその後のインシデント対応などを見ていると、やはり背景には異常が多く存在していたのではと疑いたくなります。
コンウェイの法則
ソフトウェアの構造(アーキテクチャ)は、それを作った組織を反映したものになる。
この法則のテーマは、ソフトウェアを作るのは人だということです。
例えば...
技術力のあるリーダーの意見が第一で、メンバーは考えてもあまり採用されない、というチーム。言わば独裁的な場合です。 (リーダーほうが口が強く諦めたり、リーダーが頑固だから呆れたり...けっこうあったりするんですよね...) その場合、土台はリーダーのものになりますが、詳細な設計・実装についてはガタガタです。 メンバーも表ではしっかり開発しているように見えますが、裏では組織の粗探しを始めたり開発は二の次になります。
逆にリーダーがなかなか力を発揮できない、そこを疑問視したりボスマネジメントすることもなくメンバーはひたすら開発をするだけ。言わば、レームダック状態です。 その場合、土台がないので、どれだけしっかりした設計でも、仕様の漏れ・手戻りでの不満などガタガタです。
やはり会社・働くひとがみんな、○○さんはどういう人かをまず理解する。何が好きで何が嫌いで、どういう思想があって...。 そして、どういう役目を果たすと最高のパフォーマンスを発揮するのか。 そして、現状チームの人員配置や人間関係のどこに問題があるかを把握し改善する。 チームを知り、人を知り、改善していくことがソフトウェア開発である といって過言ではないと思っています。
まとめ
どうでしょうか?基本的なところに落とし込んでみました。 最後にさらっとまとめますと...
- 無駄なことはするな。MVPだ。
- コツコツ改善(リファクタリング)をしろ。
- ソフトウェア開発は人だ。
こういう基本的なところってやっぱり皆意識できなかったり、そもそも知らなかったりします。 こういったことを意識している姿勢を見せるだけでも...
- 他と違ったやつだな
- いろいろ気づく人だな
- チームのこと考えているな
- 常にMVP意識していて助かるよ
とか色々喜ばれると思います!
現場でできていない!?スクラム開発でやるべき3つのこと
ユーザーストーリーマッピング(ユーザーストーリー駆動)
スクラム開発を行うと日々の開発、日々のポイント消化に追われます。毎スプリント、バックログからノルマが決定しそれを終えることが目的となっていきがちです。 しかし、スクラム開発の目的はそこには当然ありません。そんなときに、ゴールを見失わず示してくれるツールがユーザーストーリーマッピングになります。
対象となるユーザがどのような行動を取るのかを定義し、本当にユーザに届けるべき機能・優先順位を見える化します。 開発は必ず間違った方向に進むときが来ます。何もなくうまくいく開発などありません。 それを察知し、チームで何を作っているのかを共有し軌道修正することができます。
これは継続が必要です。多くのチームでは、開発初期に数回行ってお蔵入り...となりがちです。ユーザーストーリーマッピングは、常に改善していくものです。それをやらないと、やはり日々の開発に囚われるだけになり良い製品を生み出すことは難しくなります。
www.slideshare.net
バックロググルーミング
スプリントを開始した当時を思い出して見ると... プロダクトオーナーもスクラムに注力し、皆やる気があり、バックログもきれいに管理されているかと思います。 しかし時は経ち、プロダクトオーナーもチームの掛け持ち、経営層との打ち合わせ、顧客折衝...etcに追われスクラムは手抜きになっていきます。 よって現実の開発では、バックログには雑草が生え、優先度、ゴールが見えづらくなっていきます。
これはほとんどのチームで起きます。 必ず出てくるならこれを何とかする開発手法はないのか!!(心の声) バックログ(庭)の雑草を掃除する作業が必要になります。 それがバックロググルーミングです。
バックログをチームで整理する時間にスプリントの5%を割くことが大切と言われています。 1sprint=2week=8h*10dayの場合は、4hをバックロググルーミングに割けばいいということになります。避けない時間ではありません。
ただし、これをやれる時間のあるチームは少ないです。これこそがスクラム開発が失敗する所以で、スクラムの成否を分ける分岐点だと思っています。
レトロスペクティブ(KPT)
Kepp、Problem、Tryを出し、Keepでともに喜びあいモチベーションを保つ。Ploblemでは現場の問題を全員、そしてプロダクトオーナーが把握する。そして、今やるべきことや将来のためにやっておいたほうがいいこと、開発者のモチベーションを保つためにTryを次のスプリントでいくつかこなす。 これがよくあるKPTかと思います。これはやって損はありません。ただし形骸化しやすので注意が必要です。 スプリントが進むと破綻することが多いと感じています。 KPTが出てこない。出てきても少ない、同じ人しか出さない。
KTが出ないというのは、チームが衰退、マンネリしているということ。ファシリテーションする立場のスクラムマスターが疲弊しているとき(チームをうまく回せていない)と思っています。 そんなときこそ開発者が舵をきるときです。開発者には、リーダー層が見えない様々なチームの小さな貢献者が見えます。残念ですが、多くのリーダー層はメンバーのことを知ろうとしません。 そういった貢献を全員で見落とさない努力をしなければなりません。小さな評価の積み重ねこそ、開発者のやり甲斐です。
過去のKPTは資産です。その中にやるべきことやチームの状態があり、見えてくる場合があるので、うまく使うことができるとチームは強くなります。
まとめ
3つとも完璧ではありません。 しかし、やってみないとわからないという精神でこういった手法をやってみるのが大切だと思っています。 失敗して当然、すべての現場に合うものはありません。
やるべき3つのことというので書きましたが、こういった手法をどんどん導入して失敗〜改善していく(+楽しさを知る)ことこそが スクラム開発でやるべきたった1つのこと なのかもしれないです。
現場で使えるエンジニア引き継ぎ資料の作り方
概要
アジャイル開発が中心となっているこのご時世、エンジニアは引き継ぐことが非常に多くなってきています。 そんな中で、引き継ぎ資料作成は何のためにやるのか。そしてどうやって作成するのか、をまとめたいと思います。
引き継ぎで喜ばれることは
引き継ぎは無駄になることが非常に多いです。 もちろん途中になっている仕事を口頭で引き継ぐことで役に立つこともあります。 しかし、今までの知見を資料として残すものは結局役に立ててもらえない...ということが多いと感じます。 では、引き継ぎをやるモチベーションはどこか...
その資料あってよかった〜と言ってもらえることです。
引き継ぎ資料作成の軸
引き継ぎ資料作成は形骸化しやすいランキングベスト10に入ると思っています。 ですので、引き継ぎの目的、軸を認識するのが大切かなと思っています。
軸は主に3つ
自分しか知らない情報を資料に残す
次の開発に役立つ情報を資料に残す
現状をしっかり資料に残す
この3つを意識することで、あってよかった〜につながるはずです。
軸について
自分しか知らない情報を資料に残す
これは、知らない情報で業務に支障をきたすと判断されるものは残すべきです。
当然といえば当然ですが、漏れやすいものです。
漏れないテクニックは、1つしかありません。
常日頃からメモを取っておく...です。
次の開発に役立つ情報を資料に残す
引き継ぎでけっこうあると嬉しいのは、その開発のアドバイスです。
ここが肝でこうこう対応すると良いと思います、といった辞める人の意見・方向性があると良いです。
その意見が採用も良いですが、さらに良いのがその意見があることで違うB案,C案と考えが広がる軸を作れたというのがさらに良いことだと思います。資料を残す側も、別に採用されなくてもいいや、という気持ちで残すぐらいでいいと思います。
現状をしっかり資料に残す
引き継ぎによくあるのが、引き継ぎ内容はたくさん書いてあるのだが...「で?」というものです。
引き継ぎ資料で知りたいのは、現在の状態であることが多いです。
あとは何をやるべきなのかを残すのがメインです。
引き継ぎページをリンクのみ
引き継ぎ資料を作るとき、その資料1つに壮大なものを作ることがあります。 それは、ただただ見にくい、読みにくい、読みたくない...となります。
引き継ぎ資料と呼ばれるものはリンクのみでOKだと思っています。 簡単に言えば、索引(インデックス)を作るのみです。
では内容はどうするのか?
内容は社内資料
内容は社内資料の中に埋もれさせましょう。 埋もれていいのか...私はいいと思っています。 理由は明確に1つあります。
資料はその資料と関連性がある箇所に置くのが良い
というのも、引き継ぎ資料として1つの資料に残すと、それを見にいくという意図がない限り、そこには辿り着けないからです。検索すれば偶然辿り着けることもあるかもしれませんが、関連しているところから辿り着くほうが全ての人が発見することが可能です。これはプログラミングでいうなら 集約 です。その資料が関連するコンテキスト内に配置し、凝集度を高めることで、変更容易性・保守性を高めるといった感じでしょうか。 前述していますが、引き継ぎは形骸化します。引き継ぎの資料は誰も見なくなるものという認識を持つことで、集約について考えることができます。
まとめ
- 引き継ぎ内容は軸を意識する
- 引き継ぎ資料は索引(インデックス)を作るのみ
- 引き継ぎ内容は関連性の高いところに残す