miyatsu's blog

なんか勢いでかいてます。

1ヶ月たちました。

ポエム 転職

こんにちは。みやつです。

先月の4/1に転職して、今日でちょうど一月がたちました。 区切りが良いので当時の感じとか最近の感じとか、1ヶ月たってどうだったかなど記しておこうと思います。

理由

いろいろありますが、一言でいうと「アンマッチ」だと思う。 方向性とか、動き方とか。そういったところが徐々にずれていっているのはうすうす気づいてたけど、なんとかなんじゃねーのと気楽に構えていたのが良くなかったのかも。

合わないんなら合うように努力をする必要があるよね。 それでもちょっとは行動してたし、（gaien.rbとかね）何もやってなかったわけじゃないので まぁ、しょうがないかな。自分の会社じゃないし。

組織ってのはそこに属している人たちによって形造られているわけで、気づいたら自分が異端になってたって感じ。コントロール可能なタイミングで何かできればよかったのかもだけど。 一社員ができることなんてたかがしれてるし。何もしなかった自分が悪い部分も大いにあると思う。何ができたかなぁ、って今思うと、採用にもっと口出ししとけばよかったのかも。 やっぱり人ですよ。人。小さな会社で安定を求めるのはちょっと違うんじゃないのって思うわけです。と、ちょっと愚痴っぽくなるのでこのくらいにしとこう。

今の職場

さて、1ヶ月たち、仕事にも大分慣れて、人間関係もうっすらと見えてきて思うこと。 「どこにいってもその場その場で問題はあるんだなぁ」ってこと。 隣の芝生は青く見えるもので、転職すればすべて解決！なんて甘いことはなく、解決すべき課題はやっぱりあるわけです。 とはいえ、コンテキストが変わったので、この新しい課題に関してはすんなり受け入れることができちゃうのが面白いところ。さぁ、解決していくぞ！って気分で仕事に取り組んでます。 ただ、今度の職場はこの課題解決に関して積極的な人が多いイメージ。何か新しいことやるにしても「やったらいいじゃん」ってみんな言うし、実際やっちゃってる人もいるから自分もやっちゃおうって気になる。前職ではこういうの自分が引っ張らなきゃいけない立場だったのにできなかったので申し訳ないけど、やっぱり引っ張ってもらうのは楽だ。そのうち引っ張れるように頑張るぞっと。

何が変わった？

で、結局何が変わったかといえば、職場が変わって環境が変わったのももちろんなんだけど、一番でかいのは自分が変わったこと。

会社かわってもレガシーコードはやっぱりあって、「こんなクソコードメンテなんてしてられっか！」って昔は思ってたけど、今はそれほど思わなくなった。「歴史的経緯があるんだろうなぁ」って勝手に納得してる。

前職にいた頃は周りの会社はみんなモダンな開発やってて、技術的負債なんてないんだろうなぁ。って妄想してたけど、多分そんなことはなくて、スタートアップの会社じゃない限りどこ行っても大なり小なりあるんじゃないか、って今は思う。これは転職活動中にいろんな会社に面接いって、ここぞとばかりに興味あること聞いたところ、どうもWEB+DB PRESSに載ってるような会社は一握りなんじゃないかって印象を受けた。

いろんな会社のことを聞いて知識が増えたことによっていろんなこと納得できるようになった。 これはなかなか良かった。

あと、人に期待してもしょうがないってことが分かった。所詮他人は他人なので、自分の思い通りには動いてくれないし、動くはずない。どうも前職では動かなきゃおかしいって頭おかしいこと考えてたふしがある。 今の職場に来るときに、30にもなって転職だと即戦力を求められるだろうし、期待されるのは自分であって、他人に期待するのおかしいよねって考えたから、人に期待するのってどうなの。ってなった。これも環境が変わることで自分が変わったわけだよね。

おわりに。

と、だらだらと書いてみたわけだけど、特になにが伝えたかったわけでもなく、転職したら自分が変わったよって話だったわけです。 ということで、自分を変えるために転職してみるのもいいんじゃないかな。 ま、変わる必要がなければそのままでいいけどねー。

テストの話

test

こんにちは。みやつです。

一ヶ月ほど更新をさぼっていましたが、ふとデスクトップをみたらSonicGardenStudyでテストの話をしたときのメモが残っていたのでこれはちょうどいいという事でブログにアップしておきます。

テスト

SonicGarden Study Test

ツールの使い方ではなくて概念的なお話 盲目的にテスト書いてるだけになってない？ テスト書く前にプログラマとして考えることあるんじゃないの？

  1. テストの限界とは?(テストでは何ができて何ができないのか)
  2. テストを書くのはなんのため？
  3. テストだけで大丈夫？

テストの限界とは 網羅率も限界の1つ あまりにも条件分岐が多かった場合にもれたりする。 テスト書いただけでバグがなくなるのかな。

ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことを証明できない。

仕様の検討をして、実装していない場合は拾えない。 欠陥とは実装のバグではなくもっと広義のいみ 間違った仕様を頑張って実装してテストしてもそれは欠陥

すべての欠陥を取り除くことは不可能 バグの出ない期間を長くすればするほど、コストが天文学的に増えていく。

カバレッジ100％を目指すとシンプルに書いていたとしても大変

テストを行う目的が大事 なんのためにかくの？ 盲目的に書くのではなく、何のために書くのか意識する必要がある。

テストを書くのはなんのため？ ソフトウェアが落ちるようなバグを防ぐため。 テストによって何を守りたいかは、プロジェクトや会社などコンテキストによって異なる。 はやぶさとwebサービスでは違う

SonicGerdenの場合 納品のない受託開発 お客さんと一緒のチームになってひたすら作る

普通の納品型と違って絶えず機能拡張が発生する。 いつでもサービスが動いている。 そうなった時に何を守るべきか？

安定稼働＆継続的な改善

継続的な改善 機能を追加 機能の微調整 終わりがないということはrailsもupdateしていく 技術的負債を残さないようにリファクタリングも随時行う必要がある。

どう守るか？ テストするのはコストが掛かる。 どの程度コストをかけるのかを考える必要がある。

どれだけ頑張ってもバグは発生する テストのやり過ぎはコストがかさむ

テストをやりすぎて機能追加ができなければ本末転倒

そこで！ 不具合を許容するという考え方 不具合０を目指すより、発生した際にどれだけ早く直せるか

早く直せないのであれば０を目指してもいいのでは？

コードがどれだけ綺麗に保たれているかがとても重要 汚いコードだとバグの修正は大変

「何のために」を考えることで 「どうするべきか」が見えてくる

そのプロジェクトにとってどこまでやるかを考えていかなきゃいけない。 答えがないので考え続けなきゃいけない。

テストだけで大丈夫？ バグには習性がある

発見されずに長い間残った欠陥は、修正にも長い時間がかかる。

どういう経緯でそのコードになっていたかをみんな忘れている。 バグを前提に動くように組んでいた場合そのバグを直してしまうと他に影響がでてしまう。

欠陥を見つけるのが早いほど、欠陥の修正も安価になる。

バグを早く見つけるには

高価で遅いテストによって多くの欠陥が残る。 頻繁なテストによって費用と欠陥が削減できる。

どう立ち向かう？ バグを早く見つけて潰してしまう。 定期的にチェックする。

リリース前のコードレビュー＆週次でリリース フィードバックがいっぱい貰える

自分で書いたコードは抜けてる 自分以外の第三者が見ると早期に発見できる。

テストだけに頼らない！ 足りない部分は仕組み化してしまう。

テストに向いている分野でテストに頑張ってもらう。 そうでない場所は組織の力で守っていく。

1.テストではバグがないことは証明できない。 2.テストの目的を掘り下げて考えることが大事 3.テストだけに頼らない

まとめ 目的もなく盲目的にテスト書いてませんか？ テストがなくとも品質を上げる努力が大事 そこまで考えるのがプログラマーの仕事です

掛けるべきコストをちゃんとかんがえましょう。 テストを書くってのはコストがかかる。

納品型のビジネスモデルであれば不具合０を目指すのはは正しい

テストの得意なところ railsのupdateとかgemのupdateとか

インテグレーションテストは正常系を、異常系はユニットテストでするって話してる。

rails先輩

ruby rails gaien.rb

こんにちはみやつです。

先週と、今週とブログはすぐ書けませんでしたが、社内勉強会のgaien.rbは毎週開催しております。粛々とrailsチュートリアルの写経を進めております。

この２週間で第６章と第７章が完了しました。 すこしスピードアップ。 ということでやった事のおさらいとまとめをしておきます。

has_secure_password

第６章を終えるとユーザモデルを作って、ユーザの作成ができるようになります。 ユーザといえば認証処理ですね。 認証処理といえばdeviseが有名ですが、このチュートリアルではhas_secure_passwordを利用しています。このメソッドはRails3.1から導入されたもので、次の２ステップですぐに使えます。

  1. usersテーブルにpassword_digestカラムを追加する
  2. bcrypt-ruby gemをいれる

その後、has_secure_passwordメソッドをモデルに記述します。

class User < ActiveRecord::Base
  .
  .
  .
  has_secure_password
end

これだけでなんと次のことができるようになるのです。

  • password属性を追加し、存在の要求
  • password_confirmation属性を追加し、存在の要求
  • authenticateメソッドでユーザ認証

railsすごい。

認証機能なんてありふれた機能な訳で、いちいち実装するなんてあまりにナンセンスな気がする訳ですが、こういうのはフレームワークさんがよろしくやってほしいと思っていたんですが、railsさんはこういうところやってくれるんだからなぁ。

これからはrails先輩と呼ぼうかと思ってしまう。

第７章

６章のまとめはこのくらいで７章について。 また今度書きます。

gaienrb#13を開催しました。

gaien.rb ruby

こんにちは。みやつです。

先週は肉の日ということもあり、焼き肉を食べにいっていたのでお休みしていたgaien.rbですが、今週はまじめに開催しました。

やったこと

今日はrails tutorialの6.2.5をやりました。 mail addressの一意性検証ということで、Userモデルのmail addressにバリデーションを追加しました。

class User < ActiveRecord::Base
    :
    validates :email, presence: true, format: { with: VALID_EMAIL_REGEX }, uniqueness:true

end

最後のuniqueness:trueがポイントですね。

これだけでアプリケーション側で一意制約をつけることができるようです。便利。

ただ、これだと真に一意性を保証したことにはならないとのこと。

どういうことかというと、例えばユーザ登録の際に登録ボタンをすばやく２回押してしまった場合に、同じmail addressを持つレコードが２つできてしまう場合があるようなんですね。

それをさけるためにはテーブルのカラムにインデックスを張って一意を保証しましょう。という話がのってました。

多分フロント側でも２重送信は抑制するし、モデルの中でも抑制するし、DBでも抑制しますよね。 こういう検証は過剰なくらいがちょうどいいんでしょうかね。

手を抜いてどこか１つにしてしまいそうですが、ちゃんとやれってことでしょうね。

はまったこと

つらつらと写経をしていたんですが、bcrypt-ruby gem をインストールするところでこけてしまいました。

Installing bcrypt-ruby (3.1.2)
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
:
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

こんなエラーがでるんですが、よくよむとMake fileが作れないとかいってる。 なんでかなぁと考えてみると最近macのOSが新しくなってたのでその影響だろーと疑って、xcodeのコマンドラインツールを入れてみたらうまくいきました。

このコマンドラインツールのインストール方法がちょっと今までのやり方と違っていたので以下にメモりました。よかったらみてやってください。

MavericksでCommand Line Tools for Xcodeをインストールする

おわりに

macのOSアップデート怖い。

gaienrb#12を開催しました。

gaien.rb ruby

こんにちは。みやつです。

ブログもサボっていて更新にだいぶ間が開いてしまいましたが、本日gaien.rb#12を開催しましたので久しぶりに更新です。

学生さんが来た

今回の開催では初めて学生の方が参加してくれました。最近の学生は勉強会とかにとてもアクティブですごいですね。自分が学生のころなんかそもそも機会がなかったように思います。良い時代になったもんだ。

さて、来てくれた方も初心者ということで、初心者どうしrails tutorialをすすめることにしました。 ただ、彼は僕らよりも先に進んでいたので、どうしようかなということになりましたが、エラーで困っているというのでそこをみんなで一緒にみて解決して、各自もくもくしようという方針をたてて進めていきました。

エラーメッセージを読むのは大事

最初に困っていたエラーを見せてもらいました。

Failures:

  1) User pages signup page should have content "Sign up"
     Failure/Error: it { should have_content('Sign up') }
       expected #has_content?("Sign up") to return true, got false
     # ./spec/requests/user_pages_spec.rb:10:in `block (3 levels) in <top (required)>'

  2) User pages signup page should have title "Ruby on Rails Tutorial Sample App | Sign up"
     Failure/Error: it { should have_title(full_title('Sign up')) }
       expected #has_title?("Ruby on Rails Tutorial Sample App | Sign up") to return true, got false
     # ./spec/requests/user_pages_spec.rb:11:in `block (3 levels) in <top (required)>'

spec/requests/user_pages_spec.rbの10行目で意図していない結果となっていることがわかります。それでuser_pages_spec.rbを見せてもらいました。

require 'spec_helper'

describe "User pages" do

  subject { page }

  describe "signup page" do
    before { visit signup_path }

    it { should have_content('Sign up') }
    it { should have_title(full_title('Sign up')) }
  end
end

signup_pathにアクセスすると「Sign up」という文字列が含まれていることを期待しています。 signup_pathは以下のようにroutes.rbにかかれています。

  match '/signup',  to: 'users#new',            via: 'get'

usersコントローラのnewアクションが呼ばれます。ここにはメソッドが定義してあるだけなので、viewを確認してみました。

<h1>Users#new</h1>
<p>Find me in app/views/users/new.html.erb</p>

確かにSign upはないですね。

ということで、エラーはviewが意図したものではなかったために起こっていました。 エラーメッセージから原因を特定することは慣れてくると当然のこととしてやっていますが、最初のころはメッセージなんて読まなかったよなぁとしみじみ考える出来事でした。

やっぱりエラーメッセージって大事なんですよね。 自分でエラーを設計するときもメッセージはわかりやすく意味のあるものにしなきゃいかんですね。

今日の進捗

ということで、みんなでエラーの原因を特定したりしながら進めた今回ですが、結果的には6.2.4フォーマットを検証するまで終わりました。やったことは

  • Userモデルを作る
  • Userモデルを検証する。
    • nameの存在確認および、長さの検証
    • emailの存在確認および、フォーマットの検証

と、モデルの定義とバリデーションです。 これでモデルも作れるようになりました。

JSLoverに参加しました。

js 勉強会

こんにちは。みやつです。

10/2にDevLOVEのJSLoverに参加してきました。ちょっと時間が開いてしまいましたが、参加してきた感想をまとめておきたいと思います。

どんな会？

まずはじめにDevLoveの紹介から始まりました。 ざっくりいうと

  • DevLoveというのはいろんな開発現場のhubになろうということで活動している。
  • 開発に関係あることならなんでもやっているコミュニティ

というコミュニティのようです。 とてもよいポリシーだとおもいます。以前から何度かDevLoveには参加しています。別の会だと結構人と話すことが多い印象でしたが、今回はjsの話をみんなで聞こうという会でした。25分お話を聞いて5分質疑応答という形での進行。

発表資料

今回話しをしていただいた方々の資料はそれぞれ公開されています。あとで見直せるので公開されるのは嬉いですね。

感想

会に参加した感想をつらつらとメモがてらまとめておきます。

「JavaScriptで出来る、あんなことこんなこと」

フロントエンドアーキテクトの@kumura_m_29さんによる発表。まず肩書がかっこいい！ 発表のなかで以下のような発言がありました。

様々な分野でjsが使われているので読めたり書けたりすると世界が広がるよ。

こういうこと言われると勉強しないわけには行かないですよね。自分の仕事としてはあまりガッツリjsやること少ないんですけど、今後は積極的に手を上げて機会を掴んでいこうと思いました。 あと、全体的にとてもjsが好きなんだなぁという印象を受けました。

「JavaScript とのつきあい方」

次の発表は@shogoggさん。jsの困ったところとどう向き合うのかをお話してくれました。 変数はどこで宣言しても関数の先頭で宣言したものと同じ動作になることを変数の巻き上げっていうんですね。動作そのものは知っていたけど名前付いてるの知らなかった。これでいつでもぐぐれます。

TypeScriptをすごい押してました。確かに型安全に書けるの嬉しいかもですよね。classとかinterfaceとかあるとますますjavaっぽいので、javaっこの自分にはとっつきやすいかもなぁとか思いました。 shogoggさんとは会が終わった後にtwitterで少しお話させてもらったんですが、

個人的にはcoffeeは書くのが気持ちいいから好きで、テストとか保守を考えるとTypeScriptですね。

みたいなことをおっしゃっていました。 確かに大人数でやったりするとそうなのかもなぁ。

「複雑でリッチな Web UI を楽しく構築するために 〜Sencha 流アプローチの紹介〜」

最後は@kawanoshinobuさんによるSenchaのご紹介。

Senchaってすごいなぁ。使ってみよっかな。という感想。Senchaそのものが結構大きいのでandroid2系だと動かないこともあるそうです。2系はそろそろなくなってほしいなぁ。というのは個人的にも同意。

htmlにはbodyタグしかなくてDOMが動的に作られる動きをするそうで、urlはハッシュフラグメントになるとのこと。push stateはサポートされてないんですねぇ。ただios7にはバグがあってハッシュフラグメントうまく動かないらしいです。（ここちゃんと聞いときゃよかったなぁ。記憶が薄くなってしまった。）

あとandroid4.0/4.1系ではpush state動かないって話も聞きました。

まとめ

つらつらと感想を書いてきましたが、まとめとしては行ってよかったな。という感想です。普段なじみないこととか、知らないことを知れるのは勉強会の醍醐味ですね。 今回質問を結構することができたので、得るものがちょっとだけ多かったように思います。

とても勉強になったし楽しい会でした。

DevLOVE開催ありがとうございました！