旧gaaamiiのブログ

間違ったことを書いている時があります。コメントやTwitter、ブコメなどでご指摘ください

作業が遅い問題

どうしたもんか。。

開発環境

  • 工夫はしてるつもりだけどファイル検索とかタグジャンプがいまいち
    • これはすぐ改善できそう

考え方など

  • 一つの問題に集中できてない(問題を適切に分割できていない)
  • 機能とコードが頭のなかで結びついていない
    • ちゃんと記憶すれば解決
    • 製品を開発・保守する者として、記憶する義務があると考えるくらいがちょうど良さそう
  • アプリケーションコードの層分けがどうされているのかなど抽象的な理解が足りない
    • 新しい機能を実装するときに、そのコードをどこに書くか(なんとなくではなく)明確に決められるべき
    • 理解ができていない時に、関係ないところまで含めてコードをコピペしてしまうようなことがある

作業効率を上げるためには、記憶が割と大事なんじゃないかと思ってきた。

検索すればわかる、調べればわかるというのは大事なことで、ドキュメントやらコードやらをそういう状態に保つのはもちろん大事。

だけど、開発している製品について万事が「検索すればわかる」状態だと、作業の効率は向上しない。

ネット上で英語でできそうなことリスト

英語でインターネット読み書きできたらどんなに楽しいだろうなと思う。現状は読みの方でしか利用できておらず、とても歯がゆい。今の自分でも頑張れば英語でできそうなことを挙げてみる。

OSS関連

  • 自分のOSSを出して目につきやすいような工夫をする
  • 自分が使用しているソフトウェアに関して

掲示

  • redditでコメントする
  • Stackoverflowで回答をする

スクリーンキャスト

  • 作ってみた系など

情熱があればいつかできるかもしれない

  • 英語記事の著者にコンタクトを取って翻訳に取り組んでみる

作業計測について

日報をその日の終りに雑に思い出して雑に書くの良くないので、作業時間と作業量を測りたいと思った。

作業時間

現職の開発フローで、作業時間を測れそうな対象を粒度が粗いものから並べるとこんな感じになる。

  • チケット
  • 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.nethttp://codepen.io などといった、フロントエンドエンジニアのお絵かきサイトみたいなものがあることを知りました。ここで検索すれば、(そこそこ人気のあるライブラリなら)何かしら自分のニーズに合ったものが見つかりそうです。

f:id:shgam:20160806124829p:plain

jsfiddle.net

http://codepen.io/codepen.io

参考

qiita.com

転職3週間振り返り

転職して3週間が経ちました。少し振り返ります。 Twitterでは転職したいけど迷ってるという方も見かけるので、こういうことを(会社の迷惑にならない範囲で)こまめに振り返って伝えていきたい。

前職から変わったこと、感じてること

  • 自由が増えた(開発環境や勤務について)
  • 開発が速い(新機能の企画からリリースまでが1〜2週間とか)
  • 製品に対する反応がダイレクトに分かる
    • 一夜の障害がAppstoreのレビューに如実に現れたりする
    • 良い反応も見れる。(自分はさておき)サービスが社会のお役に立ってる感がある。
  • テスト自動化へのモチベーションが高い
  • 同僚のエンジニアのレベルが高い

個人的な課題

個人的な課題たくさんあるので技術的なこととそれ以外でまとめる。

技術的なこと

技術的なこと以外

  • アウトプット少ない
    • 自分の存在価値みたいなものを出せていなくて焦ってる
    • 明らかにこうした方がいいと思うということは共有したりプルリクで投げたりしていきたい
  • 立ち位置
    • 何エンジニアになろうとしているのかが自分でも不明瞭。
    • 正直何でもできるようになりたいけどそれでは中途半端なことになりそうでもある
  • 既存機能のデータをどこでどう持って、どのように出し入れしているのかを把握できていない
    • これがわかっていないとディレクターの方にマスタデータのcsv渡すときなんかに時間がかかる
  • 砂場を準備できていない
    • 業務で扱う技術領域で趣味プロダクトみたいなものを作って、壊せるオモチャとしてプライベートで運用していきたい( nekobito.github.io のリニューアル考えてる)
  • 時間の感覚が鈍い
    • いつまでに何ができるかという判断力が貧弱。
  • 仕様理解
    • ミーティングなどで、話についていけなくなる瞬間がある。おそらく自分でもっとアプリ使った方がいい。

関連

(他のエンジニアの方の転職その後エントリみたいなやつ大好物です)

SOAP全盛時代に何があったんだ???

http://r7kamura.hatenablog.com/entry/2014/06/10/023433r7kamura.hatenablog.com

これを見てすごい良いなあと思ったんですが、ブコメを見るとSOAP時代とやらになにがあったんだ?という疑問が浮かびました。何があったんだろう。

fish 使うぞ

fishshell.com

補完はあった方がいいよなあと思って。brew install fish して使い始めた。まだなにもいじってない。

zshでも良いんだろうけど補完使うのに.zshrcへの設定が必要っぽかったしfishの方が後発で人気も上昇してそうなので、fishを使うことにした。

転職しました

中規模のシステム開発会社から、学習支援アプリを運営するベンチャー企業へ転職しました。前職では新卒入社から1年と2か月お世話になりました。

感じていることなど

前職のWord, Excel, Outlook, ファイル名に日付でバージョン管理というような環境から、Qiita Team, Slack, Github という今時の環境になりました。勤務の仕方や開発環境の作り方など、前職では考えられなかったほどの自由が与えられています。夢見ていた環境なので、きちんと成果を出していきたいです。

転職の際にはいろんな方にお世話になりました。会社の話を聞きに行って人生相談させてもらったり、言語の勉強会なのに転職体験談を聞かせてもらったりしていました。WantedlyやForkwellのように転職支援の便利サイトやネットに転がる数々の転職エントリがあっても、実際に転職に踏み切るのはけっこう重い決断でした。そのため、生身の人から聞く助言がありがたかったです。本当にありがとうございました。

今後

今後勉強しなければいけないことは凄まじく多そうです。知っていることはQiitaに、知らないことは会社のSlackや自分のTwitterなどに投げて人様の力を借りたりして、効率よく学んでいきたいです。

まとめ

頑張ります!!!

キーボードを HHKB Lite2 for Mac にした

f:id:shgam:20160626164928p:plain

以下の様な理由から、HHKB Lite2 for Mac を選びました。

  • キーボードの配列を変える必要は今のところ感じてない
  • 高価なものは買いたくない
  • 小さめのキーボードがいい
  • Instagram にあげてオシャレ気取りたい

キーボード変えて何か変わりそう?

今のところ、「ちょっと気持ちよくなった」程度なので、これが思い込みなのか実際に指が喜んでいるかというのはよくわかりません。ただ、新しいものを手に入れてわくわくしている間はとても良い気分で過ごせそうです。

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熟練者が書いたコードをたくさん読んでいきたいです。

なにかいろいろ物足りないのでちょこちょこ書き直します。

参考リンク

参考書籍

メモ

ツールはいろいろあるけれど、それが解決している問題とかアイデアに注目すると立ち向かえそうな気がしてくる。一つ一つのコマンドを覚えるとつらいけど、もっと大きい枠組みで見ていくと楽しい。技術がわかると、普通に使っているものが、どうやって実現されているのか理解することができて楽しい。ただ頭が悪いので、時間止まればいいと思ってる。

もっとも楽しいのは、普段使っているものをバラバラに砕いて理解できたとき。なので、例えば以下の様なことについて、上から順に疑問を潰せていけると楽しい。

  • プログラムを書いてから実行されるまで
  • リンクをクリックしてからページが表示されるまで
  • git clone でプロジェクトが手元にコピーされるまで
  • cd hogeディレクトリを移動するときに起きていること

1年職場でソフトウェア開発に関わってみてわかったのは、余計なことを自ら知ろうとしないと、ツールを使う手順にばかり精通してしまって内側については何も習熟しないということ。普通に使ってるツールをいつでもバラバラに解体したり仕組みを説明できるようになりたい。