Request(PR)を投げてレビューしてもらうようにしています。ローカルでもブランチを切れるのは便利なのですが、それ以上に、開発フローに必ずレビューが入ってきて、そこにコメントを残せるというのがかなり絶大なのかなと思ってます。今はサーバサイドエンジニア二人で開発してますが、そこではfeatureブランチから更に子ブランチを切って、featureブランチにマージする時にPRを投げて互いにレビューしてます。マージする手間が増えてるのが気になるところ。・JRebelの利用JavaのWebアプリ開発で一番ストレスなのってTomcatやJettyなどを立ち上げる時の遅さ。大きなものになればなるほどかなり響いてきて、アプリを立ち上げる時は90秒以上かかってます。これを毎回やるとリズム悪くなるので、生産性が落ちるのですが、JRebelを使うといわゆるHotdeploy的なことをやってくれるので初回だけ我慢すればOK。完璧ではないのですが、サーバを再起動する回数はだいぶ減ったはず。・社内のMockツール使い始めた公開してないので名前とかは伏せるけど、サーバとフロント側のデータのやりとりにMockツールを使ってます。サーバ側がYAMLでデータを定義して、それをフロント側がFTLに組み込む形で進めてます。コメントにリクエストパラメータとか書いて、そのレスポンスをYAMLデータとして定義すると、情報が散乱せずに便利。JiraおそらくはJiraをちゃんと使いこなせていない(Jiraのルールに乗れていない)ことが理由。本当は使いはじめるときにある程度使い方を決めること(どういう単位でチケットを切るか?とか)が大切かと思いました。これは経験則なのですが、1ヶ月〜2ヶ月ぐらいの開発期間であれば、チケットの積み上げ=ガントチャートになるのが情報が集約されていいのかなと感じてます。(もしくは細かい単機能であればチケットのみとか)新規立ち上げや大規模開発は大線表としてWBSからガントチャートを作って、そこを更に落とし込んだものがチケットにしたほうが回るはず。理由としては進める上で気にする単位が違うから。HipChatいまのところあまり変わってないかなーと。Macのクライアントが立ち上がってない時にメンションが来るとモバイルの方へ通知が来るのは便利だったけど、誤字を修正しにくいとか部屋が探しにくいとか、タスク付けれないとか課題はたくさん。前に正式版が出てきたidobataが後発サービスだけあってよくできてる印象。コミュニケーションは書きたいことがまだあるので、後日書く。・属人性をなくす◯◯機能だったら△△さんだよねーというのはチームとして危険なので、メインは△△さんだけど、ある程度わかるよという状態を作りたい・テスト書こうなんかこればっかり書いてるとテスト至上主義者に思われるけど違っていて。大きな理由としては、プログラム修正して確認するたびにアプリケーションサーバ立ち上げるのは非常に非効率でリズムが悪い昔書かれたプログラムが想定している動きをしているか判断する基準になる・大きい開発の時にどうやって段階レビューしていくかGHEでWIPのPR投げつつみたいなことができればいいけど、そのスタイルが正しいかどうかが不明。本来Jiraとかのチケット管理でやってもいいのかなぁと思いつつ...・守備(運用周り)大切に毎回思うけど守備下手なので攻めと守りのバランスをよくしたい。感覚でやるとなんだかんだで5:5とか6:4になってそう。イベントやガチャデータを投入する作業にエンジニアが参加してるのが非常に微妙。手間増えるし、エンジニア頑張るのはそこじゃないし。プランナーがデータ作る→GitへUP→Jenkinsのボタン1つでデータ投入→確認→Jenkinsボタン押すと本番へデータ投入みたいな形に持って行きたい。GHEでdiffがうまく取れれば、誤字とかも見つけやすいのかなーと期待。Rollupをつくったhttps://github.com/hachi-eiji/flyway-rollup仕事でFlywayを使...2014-06-08GitHubEnterpriseをどうやって仕事に使っているかで、GitHubKaigiから1周間も経ってしまったのですが書いておき...2012-02-20MongoDBのSharding機能で遊ぶMongoDBを使っているので、自分でも組めなければと思い勉強中。10twitterはてなブログをはじめよう!hs_hachiさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。