開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->blog;
今回はドキュメントの場所をどうやって気づかせるかという話を書く。 ドキュメントがあるときの問題 以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;に書いたとおり、僕の意見としては 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う というものだった。 基本的には一番近いコメントにすると、見つけやすさ・更新しやすさともにある程度担保することが出来る。しかし、メインの部分が明確に決まらない*1いろんなパーツが関係しあう機能の場合は、ドキュメントを書かないと全体の概要が分からないということもある。このような時、ドキュメントを書いても結局そのドキュメントに気づかれないし、そのため更新されないとい
最近の本の読み方 - $shibayu36->blog;
最近はいろいろな本を読んでる。でもぼーっと読んでるだけでももったいないので、ある程度どんな本を読むのかとか、読む時はどうするのかとか、読んだあとどうするのかというのを決めて読んでる。 どんな本を読むか 大学の時は時間もあったせいかとにかく乱読が好きで、適当に本屋に行って、新書コーナーをひと通り歩きながら10冊くらい気になった本を買って、それを二週間位で読むみたいなことをしてた。最近はそこまでやる時間もないし、もうちょっと読む本を絞って読んだりしてる。 最近意識してるのは、今経験していることに関連する本を読むみたいな感じ。例えば自分のチームでペアプログラミングがあんまり有効に活用できてないなーと思ったらペアプロの本を読んだり、なんかスケジュールがきつきつでしんどいなーと思ったら見積りの本を読んだり、コードレビューするときにクラス設計についてうまく言語化出来ないなーと思ったらオブジェクト指向の
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
cron周りのベストプラクティス読んだ - $shibayu36->blog;
WEB+DBのPerl Hackers Hubで書かれていた「cron周りのベストプラクティス」を読んだ。かなり参考になった。 経緯としては読みたいって呟いたら感想よろしくと言われたので慌てて読んだ。 @shiba_yu36 「読んだ」なら言ってもいい— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジに謝られても…— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジになって感想エントリを書いてください。— songmu (@songmu) 2014年2月24日 特に参考になったこと batch.pl batch.plは非常に良いと思った。というのもcronとかのスクリプトで非常に簡単な事をやっている場合は適当にplファイルを作っちゃって登録するんだけど、得てしてそういうのはテストが無くてバグってて、しかもcronのロ
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog;
最近Dockerとか、serfとかその辺りのツールが流行ってる。その中でとりあえずDockerはテスト環境やCIでは使えるかもしれないけど、実際にwebサービスが動いているものに使えるかどうかはまだわかんないねーという流れになっていた。 まあでもとりあえず動いているwebサービスをDockerでやったらどうなるかというのを知りたいというのがあって、いろいろ機会があったので4人で3日くらいやってプロトタイプ実装というのをしてみて試した。 結局出来たこと 結局以下の様なものが実際に動くところまで行った。 AWSのような環境がなくてもDockerさえ動けばブルーグリーンデプロイ出来る VPSだろうが自宅サーバだろうがなんでも ボタンだけで「本番用環境構築」「本番前の確認」「本番切替」が出来る web n台くらいを一セットとみなした環境をボタンひとつで簡単に作れる Docker imageのビルド
インフラのOrchestration? - $shibayu36->blog;
Orchestrationやっぱりよく分かってなくて、色々話聞いてた。まだまだ分かってないけど、今のところをまとめるので、ここは違うとか指摘してください。 http://iiirc.org/snippets/321 Orchestrationに二つの意味が混ざっている？ という話になった。一つはmizzyさんも言っていたインフラの動的な部分という意味で、一つはnaoyaさんやstanakaさんが言っていたサーバ同士がうまくコミュニケーションしあって統制するという意味っぽい。 それぞれの役割やツールへの対応としては インフラの動的な部分 あるサーバの状態に合わせて、実行する内容を動的に変える capistrano, fabric, MCollectiveなどが該当 サーバ同士が相互的にコミュニケーションして統制する serfなどが該当 インフラの動的な部分としてのOrchestration
ターミナル版anything的なpercolをzawの代わりに試してみた - $shibayu36->blog;
emacsを使っているとterminalでもanything的にいろいろやりたくなるんだけど、そういう時にこれまでzawというツールを使ってきた。 https://github.com/zsh-users/zaw zaw.zshで最近移動したディレクトリに移動する - $shibayu36->blog; zawを使って最近更新したブランチをチェックアウトする - $shibayu36->blog; zaw結構便利なんだけど問題点もある。 読み込む行数が増えてくると遅くなる 履歴検索で10万行とか行くと動かないので致命的 zshに完全に紐付いてしまって、気軽には使えない で、この前YAPCでid:moozさんと話してて、percolという便利ツール作ってると聞いたので、試してみた。 percolとは 紹介記事などがあるので、それを参考に。 https://github.com/mooz/pe
vagrantでCentOSのVMを立ちあげて、ネットワークが遅い時に試すこと - $shibayu36->blog;
最近PrePANのcarton 1.0化を進めるため、vagrant、chef、knife、AWSなどにはまりまくっております。今回はその中でvagrantにchefを適用しようとしたら全く終わらなくて、それについて調べたことについて話します。 PrePANの開発環境でvagrantを使っていたりするのですが、そのVMに対してchefを適用してみたところ、固まってしまって動かない(厳密に言うとすこしずつしか動かない)という状態になりました。そこでいろいろ調べてみると、IPv6とDNSの関係でネットワークの疎通が遅くなっていたという事がわかりました。 詳しくは Slow networking (due to IPv6?) on CentOS 6.x · Issue #1172 · hashicorp/vagrant · GitHub を見てもらうと分かると思いますが、IPv6で名前解決に行く
vagrant upの実行が終わらない話 - $shibayu36->blog;
最近AWSとかvagrantとかchefとか勉強していて、vagrantを使っていたのだけど、はじめからハマったのでメモ。 起こったこと vagrant upすることでVMが立ち上がるのだけど、以下の様なところまで言って全く起動しなくなった。 [default] VM already created. Booting if it's not already running... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set ne
zawを使って最近更新したブランチをチェックアウトする - $shibayu36->blog;
仕事でgit使っていてレビューとかしていると、どうもgitのブランチ切り替えがだるくなってくる。それで、zawで更新日時順でブランチが並んでいて、選択するとgit checkout出来ればすぐにブランチ切り替えが出来て便利ではと思いやってみた。 bindしたキーを押すと、更新日時順でブランチが表示されて、Enterを押すとチェックアウトする。更新日時順なので数回キーを押すだけで、チェックアウトしたいブランチに辿り着けることが多い。zawを使っているので絞り込みも出来る。 インストール zawを使っていれば、導入は簡単。 まずzawのsourceのディレクトリに以下のファイルを置く。もしくは適当なところに置いて、zawのloadの後にsourceを使ってloadする。 https://github.com/shibayu36/config-file/blob/master/.zsh/zaw-
「capistrano設定の共通化(+ Tips集)」についてKyoto.rbで発表してきました - $shibayu36->blog;
Kyoto.rbがあったので、Rubyのことはよくわからないながら、capistranoの話をして来ました。設定の共通化についてと、思いついたTips集を発表して来ました。サンプルはhttps://github.com/shibayu36/capistrano-deploy-sampleにおいてあります。 130207 kyotorb from Yuki Shibazaki capistranoとは デプロイ用ツール コマンド一つでアプリケーションのデプロイが出来たりする 特にRailsに特化してる capistrano設定を社内などで共通化したい 共通化しないとprojectごとでdeploy方法が違って死ねる とはいえ一つのファイルで管理していると破綻する 最近の共通化の方針 やりたいことごとにファイルを作って共通化する default設定, deploy用, cron, perlbr
MySQLをさらに理解するために読んだ記事まとめ - $shibayu36->blog;
最近MySQLの勉強をしていました。実践ハイパフォーマンスMySQLを読むべきという話を聞いていたのですが、かなり網羅的に書かれていて、今の知識ではどれが重要なのかわからない状態でした。そこで色々調べてみて、参考になる記事をいくつか見つけたので、少しまとめてみようと思います。 今回まとめた記事を読んで、大体以下のことが理解できました。 インデックスの使われ方とその構造(MyISAMとInnoDB) EXPLAINの詳しい使い方、見方 InnoDBの特性 ALTER TABLEの特性 レプリ遅延 まず最初に Webエンジニアのための データベース技術[実践]入門 (Software Design plus)posted with amazlet at 12.06.02松信 嘉範 技術評論社 売り上げランキング: 9767 Amazon.co.jp で詳細を見る 松信さんの書いた「Webエンジ
補足 - Web Applicationをきれいに設計するためのMVACという考え方 - $shibayu36->blog;
Web Applicationを綺麗に設計するためのMVACという考え方 - Dive into the Tech World! では、様々な意見をいただきありがとうございました。コメントを見る限り、うまく伝えきれていないなという部分がいくつかあったため、補足としてまとめたいと思います。 前提 前回の記事は一応前提として、以下のようなものがあります。 Web Application設計の新しい手法を提案したわけではない 昔からある手法の理解が自分の中で深まったので、まとめてみたわけです もらった意見とその補足 MVCにおけるMの定義がおかしいのでは Mの定義がおかしいから、Aがある データモデルがMと思うと失敗する これに関しては、「MにSkinnyを」などというように、記事の書き方が少し良くなかったのではないかなと思いました。Mに関しては、DBへのインターフェイス、オブジェクトの層、ロジ
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
