■ 新卒エンジニア向けに品質の話をした slideshare だと keynote から書き出した日本語が消えてしまうので speakerdeck で。 https://speakerdeck.com/hsbt/yatutemiyou-tqc ペパボでは新卒エンジニアの研修の一環で座学という形で60min何かを講義するという取り組みをここ数年続けているので、自分も品質というキーワードにまつわるあれこれを講義してきた。こういう話、社内では自分くらいしかしないだろうから丁度いいだろうというレベルで若干ふわっとした話をしてきた。 資料だけだと、「ちょっとこれは雑すぎない?」というのがあるとは思うんで、この辺もう少し詳しくということがあったら、是非ディスカッションしましょう → https://pepabo.com/recruit/pepaluncheon/ ■ Asakusa.rb 第368回
This document discusses testing code written for mruby, a lightweight Ruby implementation. It proposes using the mruby runtime itself to test code, rather than Ruby, by using the mruby-mtest library. This allows testing mruby code directly using the same binaries and libraries as production. Sample code shows how to structure tests and set up a test runner to execute tests against the mruby binary
■ Atom を使うようにしてから 1 ヶ月位たった emacs をずっと使っていたけど、Atom どうなんということで Atom を 1 ヶ月くらい使ってまあまあ使えるようになってきた。プロジェクト単位ということで複数のディレクトリ(rails/rails とか ruby/ruby とか)をまたがって何かをする、という開発にはとても弱いのでこの辺は慣れでなんとかすることにした。 やったこと atomic-emacs 入れて emacs キーバインドにした autosave を有効にしてフォーカスが変わる度にセーブ tab キーを indent に変更 linter, language を色々入れた これくらいで他は特にいじってないけど、Atom が emacs に見えてきたので大丈夫だと思う。後は起動速度さえなんとかなればなあ。
■ devise をあまりオススメしない理由 いまいち使うのに気が乗らない理由はこんな感じ コントローラレイヤ以降に作用する gem は inspect が物凄くやりにくい、params ないし、必要なコンテキストを全て揃えた上で、コントローラを new して action を呼んで、みたいなこと、考えただけでもだるい テストを書いていたとしても、環境要因、特にセッションとクッキーに影響して挙動が変わる箇所が多すぎるので、全ての環境で正しく再現することが難しい フルスタックすぎることから Rails よりも devise にロックインされることの方が多くなって負債化する そもそも devise で便利になることの多くは、自分で作ってもわけない物が多い 使うからには、devise のコードも全部読むし、PR も投げるしという前提かつ、上のようなことを全て乗り越えるつもりなら僕は止めません!
■ オブラブ 2012 収穫祭に参加してきた 前職の永和システムマネジメントが定期開催しているオブラブのイベントで、新卒エンジニアの研修をする側とされる側の取り組みであるとか考え方を発表するというのがあったので引率として参加してきた。最初は最初の1ヶ月の研修を担当した流れでオレかあんちぽさんが発表しようかと思ったけど、1ヶ月目以降はOJTの監督として毎日横についている @hiboma 軍曹にお願いすることにしたのでした。 ペパボはデザイナの鹿くんとエンジニアの黒くんに入社してから今日までにやったことであるとかどういう気持ちになって今を過ごしているかというのを発表してもらって、@hiboma 軍曹には教えていることやどういう方針でやっているかというのを発表してもらった。お疲れ様でした。 今日は他にも cookpad, DeNA, GREE, 永和それぞれの取り組みが聞けて良かった。弊社も含め
■ [Life] 永和システムマネジメントを退職しましたのお知らせ 永和システムマネジメント(以下 ESM)を4月30日をもって退職することにしました。今日が最終出社日です。 思い返せば、2009年の年末に kakutani に IRC で private message を投げて "ESM って中途採用していますか"と飛び込んだのがきっかけで2010年に北海道より上京してESMに入社しました。入社してからは昼に Ruby とアジャイル開発で良いとされている考え方がふつうの場所で働けるということを全力で楽しんで毎日を過ごしていました。 ESM では色んなプロジェクトを経験しました。半分くらいは MongoDB (のような RDB ではないデータストアの何か)を使わないと解決出来ないような問題領域のシステムを構築したり(残りの半分は PostgreSQL)、Backbone.js や Her
■ [work] 在宅勤務期間の開始 今日から2月末まで在宅勤務を選択できるようになった。最近はリモートでもほとんど作業できるような仕組みにしてあるので、インフルエンザが流行っていたり、この冬一番の寒さみたいななか頑張って会社に行く必要も無いのだよなあ。 開発に支障でないの? プロジェクトのコードは全て github 上にあるし、チーム内のコードレビューは pull request を通して行っているので横に座っていても在宅でも変わらない。チャット的なものはIRCで十分。 会社の方が作業環境が(ry ディスプレイのサイズもネットワークの速度も椅子の質も家の方が充実しているのであった。 会社の会議が 管理職じゃないので参加必須な(社内の)会議体は無い! でもお客さんとのやりとりが CI でオールグリーンになると即座にお客さんも触れるステージング環境にデプロイされるので動作チェックはそこでやっ
■ [git][github][tDiary] master ブランチで pull request していいのは小学生までってこともない GitHubへpull requestする際のベストプラクティス - hnwの日記を読んで感じたこと。 このエントリではmasterブランチで pull request していいのは小学生までと言われているけど、少なくとも tDiary ではどうでも良いからパッチ送れとしか思わないなあ。 具体的には master ブランチで作業したものを pull request しても別にコードの内容に問題がなければがんがん取り込むし、コンフリクトがひどかったり、なんじゃこりゃというのは差し戻すのでパッチを投げる側は気にする必要はない。繰り返すけど、Gitのお作法よりもコードの内容の方が重要ってことを頭に置いた方が良い。 もちろん、件の記事のようにちゃんと Git を
■ [ITS][PivotalTracker] Pivotal Tracker 最近、社内でプロジェクトで使う ITS を何にするかねーという話題が空前の大ブームになってて、オレのプロジェクトでは隣の隣に座っているチーフプログラマがオススメしてきた Pivotal Tracker というのを使うことにした。 http://www.pivotaltracker.com チュートリアルを見るとだいたいわかる。 http://www.pivotaltracker.com/learnmore 最初は Trac や Redmine のようないわゆる ITS も候補に挙がっていて、追加で Mantis や Retrospectiva も考えてみたんだけど、どれも"こちら側"でのチケットとリポジトリ管理が主な機能。これらは開発側だけで使うなら問題はないけど、顧客と story や goal の共有するこ
■ [Work]永和システムマネジメント入社のお知らせ 3月1日より永和システムマネジメントに入社します。勤務先は東京支社となります。 昨年、転職を考えた時に次に働く場所の条件は以下と決めていました。 OSSに関して後援や協賛等を通じて貢献している企業 ソフトウェア開発に真摯に向き合っている企業 エンジニアが力を発揮できる環境を用意できる企業 尊敬できるエンジニア(ロールモデル)が在籍している企業 条件を全て備えている候補企業を絞って面接をしていく中で、特に永和システムマネジメントのメンバーと共に働きたいという気持ちが強くなり、入社を決断しました。 今後はアジャイル開発の取り組みを枝から幹へと成長させて行くということを第一のミッションとして、ソフトウェア品質や顧客価値の探求、OSSコミュニティの活動等にもこれまで以上に関わっていこうと考えていますのでよろしくお願いいたします。 ■ [dev
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
