作業が遅い問題
どうしたもんか。。
開発環境
- 工夫はしてるつもりだけどファイル検索とかタグジャンプがいまいち
- これはすぐ改善できそう
考え方など
- 一つの問題に集中できてない(問題を適切に分割できていない)
- 機能とコードが頭のなかで結びついていない
- ちゃんと記憶すれば解決
- 製品を開発・保守する者として、記憶する義務があると考えるくらいがちょうど良さそう
- アプリケーションコードの層分けがどうされているのかなど抽象的な理解が足りない
- 新しい機能を実装するときに、そのコードをどこに書くか(なんとなくではなく)明確に決められるべき
- 理解ができていない時に、関係ないところまで含めてコードをコピペしてしまうようなことがある
作業効率を上げるためには、記憶が割と大事なんじゃないかと思ってきた。
検索すればわかる、調べればわかるというのは大事なことで、ドキュメントやらコードやらをそういう状態に保つのはもちろん大事。
だけど、開発している製品について万事が「検索すればわかる」状態だと、作業の効率は向上しない。
作業計測について
日報をその日の終りに雑に思い出して雑に書くの良くないので、作業時間と作業量を測りたいと思った。
作業時間
現職の開発フローで、作業時間を測れそうな対象を粒度が粗いものから並べるとこんな感じになる。
- チケット
- Issue
- Pull Request
そして、それぞれ関係性がある。
- チケットとIssueとPull Request は多くの場合1対1対1になる。
- チケット無しでIssueとPull Requestが作られる場合はバグ修正や途中で気付いた改善点など、元々はスケジュールに無かったもの。
なので、1日の作業を計測するとしたらIssueごとの作業時間を測るのが良さそう。作業時間を測るのには、toggl buttonというChrome拡張があるのでそれを使えばいい。
作業量
では、作業量の計測対象はなんだろう。
- Issue(閉じることができたやつ)
- Commit
- URL
閉じたIssueやCommitはコーディングの成果そのものなので、これを作業量として見るのは違和感ないと思う。
目に見えなくなりがちなのがコーディングする以前の調査量だ。何か作りたいけど実現方法どうしようか。よし調べるぞ。〜〜1時間経過〜〜。みたいなのはよくあると思う。コーディングはもちろん、調査も作業だと考えていいはずだ。
ではこれはどうやって測ればいいのか、と考えてみると、URLというのが計測対象の1つになり得ると思った。論文や本の参考文献リストのように、その日の作業量を表すものとして参考URLが並んでいれば、なかなかやった感があって気持ち良さそうだ。
作業時間 Issue#56 4時間00分 Issue#57 3時間30分 Issue#58 1時間30分 作業量 Issues: 2 commits: +355 −39 URLs: 38 - http://example.com/fieoajfi - http://example.com/hgoehoge - http://example.com/fioawjio - http://example.com/fiaojwfie - http://example.com/goe - http://example.com/iofjeai
こういう数値をまとめて出せるようにしておくと、いろいろ学びがありそう。ただ、この数値で同僚のエンジニアと比較されるみたいなことになるとストレスが高まりそうなので良くなさそう。自分の作業時間見積もりの不正確さやざっくりとしたパフォーマンスを知る目的に確認するのであれば良さそう。
ライブラリのサンプルをCodePenやjsfiddleで検索すると捗る
転職して1ヶ月は内製のサポートツール周りなどを触らせてもらっていましたが、8月からはウェブフロントエンドの方にコミットさせてもらっています。Angularのデータバインディング周りに何度もハマっていて楽しいです。
フロントエンドの開発作業で、新たな機能をつくるときにはまずそれ相当のライブラリがあるかどうか調査することが多いと思います。しかしそれが見つかったとしても、僕のように頭が弱く英語力が低い人間にとって、ライブラリの扱い方をGithubのREADMEからすぐに把握するのはなかなか大変です。そのため、さっと動くサンプルを見つけることがとても重要。
そこで、http://jsfiddle.net や http://codepen.io などといった、フロントエンドエンジニアのお絵かきサイトみたいなものがあることを知りました。ここで検索すれば、(そこそこ人気のあるライブラリなら)何かしら自分のニーズに合ったものが見つかりそうです。
参考
転職3週間振り返り
転職して3週間が経ちました。少し振り返ります。 Twitterでは転職したいけど迷ってるという方も見かけるので、こういうことを(会社の迷惑にならない範囲で)こまめに振り返って伝えていきたい。
前職から変わったこと、感じてること
- 自由が増えた(開発環境や勤務について)
- 開発が速い(新機能の企画からリリースまでが1〜2週間とか)
- 製品に対する反応がダイレクトに分かる
- 一夜の障害がAppstoreのレビューに如実に現れたりする
- 良い反応も見れる。(自分はさておき)サービスが社会のお役に立ってる感がある。
- テスト自動化へのモチベーションが高い
- 同僚のエンジニアのレベルが高い
個人的な課題
個人的な課題たくさんあるので技術的なこととそれ以外でまとめる。
技術的なこと
- Railsのデフォルト機能を使っていない部分についての理解
- RESTとJSON Schema
- RSpec
- 一度Qiitaなどにまとめたい。
- DDD
- まず基本概念だけでも理解しないと議論に参加できない。
- git
- まだぎこちない
- 障害対応
- サーバーの負荷が大きくなってアラートが発生したときに、障害対応を眺めていたが今後は自分もできるようになっていないとまずい。
- DBのクエリを特定 -> 発行しているアプリケーションコードを特定 -> Issue化 -> プルリク までできるようになりたい。
- DBの知識がとにかく大事。今日はこの辺読んだ。
技術的なこと以外
- アウトプット少ない
- 自分の存在価値みたいなものを出せていなくて焦ってる
- 明らかにこうした方がいいと思うということは共有したりプルリクで投げたりしていきたい
- 立ち位置
- 何エンジニアになろうとしているのかが自分でも不明瞭。
- 正直何でもできるようになりたいけどそれでは中途半端なことになりそうでもある
- 既存機能のデータをどこでどう持って、どのように出し入れしているのかを把握できていない
- これがわかっていないとディレクターの方にマスタデータのcsv渡すときなんかに時間がかかる
- 砂場を準備できていない
- 業務で扱う技術領域で趣味プロダクトみたいなものを作って、壊せるオモチャとしてプライベートで運用していきたい( nekobito.github.io のリニューアル考えてる)
- 時間の感覚が鈍い
- いつまでに何ができるかという判断力が貧弱。
- 仕様理解
- ミーティングなどで、話についていけなくなる瞬間がある。おそらく自分でもっとアプリ使った方がいい。
関連
(他のエンジニアの方の転職その後エントリみたいなやつ大好物です)
ぜんぶPryでやりたい気持ち
これを少しずつ更新してる。今後は自作コマンドからいろいろやりたい。
SOAP全盛時代に何があったんだ???
http://r7kamura.hatenablog.com/entry/2014/06/10/023433r7kamura.hatenablog.com
これを見てすごい良いなあと思ったんですが、ブコメを見るとSOAP時代とやらになにがあったんだ?という疑問が浮かびました。何があったんだろう。
転職しました
中規模のシステム開発会社から、学習支援アプリを運営するベンチャー企業へ転職しました。前職では新卒入社から1年と2か月お世話になりました。
感じていることなど
前職のWord, Excel, Outlook, ファイル名に日付でバージョン管理というような環境から、Qiita Team, Slack, Github という今時の環境になりました。勤務の仕方や開発環境の作り方など、前職では考えられなかったほどの自由が与えられています。夢見ていた環境なので、きちんと成果を出していきたいです。
転職の際にはいろんな方にお世話になりました。会社の話を聞きに行って人生相談させてもらったり、言語の勉強会なのに転職体験談を聞かせてもらったりしていました。WantedlyやForkwellのように転職支援の便利サイトやネットに転がる数々の転職エントリがあっても、実際に転職に踏み切るのはけっこう重い決断でした。そのため、生身の人から聞く助言がありがたかったです。本当にありがとうございました。
今後
今後勉強しなければいけないことは凄まじく多そうです。知っていることはQiitaに、知らないことは会社のSlackや自分のTwitterなどに投げて人様の力を借りたりして、効率よく学んでいきたいです。
まとめ
頑張ります!!!
RubyのブロックとProcとlambdaとMethodについて
RubyのブロックとProcとlambdaとMethodについて書きたいけど自信がないです。容赦のないマサカリやツッコミをお願い致します。
ブロック
ブロックははじめてRubyを触ったときから慣れ親しんでいるものです。
%w(:Yoshida, :Tanaka, :Suzuki).each do |name| puts "Hello, #{name}" end # または %w(:Yoshida, :Tanaka, :Suzuki).each { |name| puts "Hello, #{name}" }
do と end というキーワード、あるいは波括弧{}
で行いたい手続きを囲みます。
yield
yieldは渡されたブロックを実行します。 例として、「誰かに何かする」というメソッドを定義してみます。
def do_for(name) yield(name) end do_for(:Tanaka) { |name| puts "Hello, #{name}" } do_for(:Suzuki) { |name| puts name.upcase }
Proc
1回きりならdoとendで囲んどきゃいいけど、その手続きを変数に入れたりして保持したいこともあります。 Procクラスのコンストラクタに同じブロックを渡せば、その処理をいつでも呼び出せるようになります。
hello_proc = Proc.new { |name| puts "Hello, #{name}" } hello_proc.call :Nishikori %w(:Yoshida, :Tanaka, :Suzuki).each { |name| hello_proc.call name }
lambda
「ラムダ」と発音します。Procとほぼおなじですが、違いもあるようです。ただlambda式を実行して返ってくるものはProcクラスではあります。
hello_lambda = ->(name) { puts "Hello #{name}"} hello_lambda.call :hoge hello_lambda.class #=> Proc
Procとの違い
「Procとほぼおなじ」というからには、何か違いがあるわけですね。コメントを頂きましたのでそれをここでも共有させていただきます。
引数チェック
# Proc は引数チェックしない hello = Proc.new { |name| "Hello, #{name}" } hello.call :Tanaka, :Suzuki #=> "Hello, Tanaka" # lambda は引数チェックする hello_lambda = ->(name) { "Hello, #{name}" } hello_lambda.call :Tanaka, :Suzuki #=> ArgumentError
returnの処理
[TODO: サンプルコード]
Method
自信が無いのでドキュメントそのまま引用します。
Methodとは、
Object#method によりオブジェクト化され たメソッドオブジェクトのクラスです。
メソッドの実体(名前でなく)とレシーバの組を封入します。 Proc オブジェクトと違ってコンテキストを保持しません。
とのこと。
まとめ
利用の場面を経験しないとなんとも言えない感じがするので、Ruby熟練者が書いたコードをたくさん読んでいきたいです。
なにかいろいろ物足りないのでちょこちょこ書き直します。
参考リンク
- Ruby の Proc オブジェクトと Method オブジェクトの違い (proc, lambda, ブロック, メソッドについて) - vivid memo
- Ruby block/proc/lambdaの使いどころ - Qiita
- Procを制する者がRubyを制す(嘘)
- Ruby のキーワード一覧 - Secret Garden(Instrumental)
- Ruby の Proc オブジェクトと Method オブジェクトの違い (proc, lambda, ブロック, メソッドについて) - vivid memo
参考書籍
速さを測りたい
とりあえず http://yomomo.net をたたき台にしてやってみたい。何から始めたらいいんだろう
参考
メモ
ツールはいろいろあるけれど、それが解決している問題とかアイデアに注目すると立ち向かえそうな気がしてくる。一つ一つのコマンドを覚えるとつらいけど、もっと大きい枠組みで見ていくと楽しい。技術がわかると、普通に使っているものが、どうやって実現されているのか理解することができて楽しい。ただ頭が悪いので、時間止まればいいと思ってる。
もっとも楽しいのは、普段使っているものをバラバラに砕いて理解できたとき。なので、例えば以下の様なことについて、上から順に疑問を潰せていけると楽しい。
- プログラムを書いてから実行されるまで
- リンクをクリックしてからページが表示されるまで
- git clone でプロジェクトが手元にコピーされるまで
- cd hoge でディレクトリを移動するときに起きていること
1年職場でソフトウェア開発に関わってみてわかったのは、余計なことを自ら知ろうとしないと、ツールを使う手順にばかり精通してしまって内側については何も習熟しないということ。普通に使ってるツールをいつでもバラバラに解体したり仕組みを説明できるようになりたい。