プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
自分流Elasticsearch入門 - $shibayu36->blog;
【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。 高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者:Ｒａｆａｌ
良いビジョンとは何か - ザ・ビジョンを読んだ - $shibayu36->blog;
以前、1分間顧客サービス という本を読んで、「顧客中心のビジョン」を作ることが、熱狂的なファンを作るために必要と書かれていた。チームを自分で率いている以上、チームがどういう価値を提供するのかを示すようなビジョンは必要だと感じた。 チームのビジョンを立てようとは思ったものの、以下のような疑問が出てきた。 良いビジョンとは何なのか ビジョンをどう伝えるか これらの疑問を解決する手助けになると良いと思い、「ザ・ビジョン」という本を読んだ。 ザ・ビジョン 進むべき道は見えているか 作者:ケン・ブランチャード,ジェシー・ストーナーダイヤモンド社Amazon この本は1分間マネジャーシリーズを書いた、ケン・ブランチャードによって書かれた本である。良いビジョンとはなにか、どうやってそのビジョンを作っていくか、などについて、お馴染みのスタイルである小説形式を用いて教えてくれる。ページ数は200ページ強とそ
「シバソン」という名の何も準備しないイベント - $shibayu36->blog;
最近、シバソンという名のほぼ身内でやっているイベントを開催している。シバソンとはシバハッカソンの略で、なぜか適当にハッカソンしますと会社で呼びかけたら自然とシバソンという名前になっていた。今日は勉強会について簡単に書きたいと思う。 Kyoto.pm 以前自分はKyoto.pmというperl界隈のイベントの主催をしていた。このイベントは最初もっといろいろな人にアウトプットする場を提供したいという気持ちで始めたイベントだった。有名な東京のperl hackerを呼べたり、東京からはるばる来てくれる人が何人かいて、けっこう面白いイベントに出来たと思ってる。 ただ問題点がいくつかあった。 一つ目は主催者が開催のために前準備(スピーカー集めとか)をするコストが非常に高かったこと。発表会形式にすると、特に関西ということもあって、全然スピーカーが集まらないということがよくあった。そのたびにいろんな人に声
ターミナル版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
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog;
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ この辺に書いたとおり、id:wtatsuru, id:y_uuki, id:hagihala と一緒に、DockerやMesosなどを利用してBlue-Green Deploymentのプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog;
最近Dockerとか、serfとかその辺りのツールが流行ってる。その中でとりあえずDockerはテスト環境やCIでは使えるかもしれないけど、実際にwebサービスが動いているものに使えるかどうかはまだわかんないねーという流れになっていた。 まあでもとりあえず動いているwebサービスをDockerでやったらどうなるかというのを知りたいというのがあって、いろいろ機会があったので4人で3日くらいやってプロトタイプ実装というのをしてみて試した。 結局出来たこと 結局以下の様なものが実際に動くところまで行った。 AWSのような環境がなくてもDockerさえ動けばブルーグリーンデプロイ出来る VPSだろうが自宅サーバだろうがなんでも ボタンだけで「本番用環境構築」「本番前の確認」「本番切替」が出来る web n台くらいを一セットとみなした環境をボタンひとつで簡単に作れる Docker imageのビルド
serfとDockerでクラスタを組んでみる - $shibayu36->blog;
最近Serfというツールも気になっていたので、とりあえずクラスタを組んでイベントハンドラの設定をしてみるところまでやってみました。 Serfとは http://www.serfdom.io/ https://github.com/hashicorp/serf Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant. Orchestrationという層を支援する軽いツールみたいですね。これをうまく使うことで、クラスタにjoinしたweb serverを自動的に配下に加えるHAProxyとかを実装したり出来ます。参考: Serf+HAProxyで作るAutomatic Load Balanc
Dockerで立てたコンテナにsshで接続する - $shibayu36->blog;
最近Dockerをちょっと触っていて、とりあえずDockerでコンテナを立ててsshでつなぐということをやってみた。 Dockerを入れる macだとDockerが入っているvagrant環境があるのでそれを落としてくる。 http://docs.docker.io/en/latest/installation/vagrant/ $ git clone https://github.com/dotcloud/docker.git $ cd docker $ vagrant upこれでDockerが動くvagrant環境が出来た。今後の作業はこのvagrantにsshした状態で行う。 $ vagrant ssh sshdが起動したコンテナにつなぐ http://docs.docker.io/en/latest/examples/running_ssh_service/ この辺を参考に。 まず
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
チームで開発する際に自分が心がけていること - $shibayu36->blog;
最近結構大きめなチームで開発しているのだけれど、そこで気をつけていることをちょっと書いてみる。 チームを開発していると 自分がメインで開発している機能 自分以外がメインで開発している機能 の二つが必然的にできてくる。チームがある程度大きくなってくると、自分がメインで開発している機能は自分が一番詳しくなるし、自分以外がメインで開発している機能に関しては自分がいちばん詳しいわけではなくなる。 そこでこの二つについて自分が心がけていることを書いてみる。 自分がメインで開発している機能 この時考えているのは、 自分一人だけの知見では見逃すことも多いので、出来るだけ早めに意見を集める 他の人の意見に左右され過ぎない 動くものが必要な場合は最小工数で作る それは全て捨てる気持ちで作る これらを考えて、僕は自身では以下の様なプロセスで機能開発をしていっている。 その開発に関する調査をする その機能に関す
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;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
