Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
バージョンの迷走はどう防ぐ？
CI環境とプロセス、ルールを整備し、適切なジョブの内容を記述し、効率的なビルドのスケジューリングを組む―。ここまでできれば、CIの導入はほぼ終わったようなものである。 しかし、実際にCIを導入した後にはまだ注意しなければならない点がある。それが、バージョンの迷走だ。 ソースコード管理ツールを使っていても生じる問題は三つある。まず、複数のメンバーがソースコードのブランチとマージを繰り返し、ソースコードが枝分かれしてバージョン情報が大量かつ複雑になるケースだ。 仮に同じソースコードを共有して開発を進める場合、ある開発者がチェックアウトして修正しているソースコードが別の開発者によって上書きされてしまうことがある。これが二つ目のバージョンに関する問題である。 三つ目は、共通部品を先行して開発している場合、「共通部品のバージョンが利用する開発チームによってバラバラになる」（今田氏）こと。仮に先行する
ドメイン駆動開発/DDD体験ワークショップに参加しました（PHPカンファレンス2013） - アークウェブシステム開発SandBox
前提：良いソフトウェアとは (P.6) † メンテ、テスト、コードが読みやすい 読みづらいコード (P.9のコード参照) 規約、長い、設計悪い 某WPなるメイン処理 処理関数が 7つくらいあるので一見シンプル！ …でも、register_globals()とか一目見て何を処理するか分かるかというと分かりづらい →読んでて気持ち悪い なんとなくなイメージとメソッド記述にズレがある …これが読んでて気持ち悪い ズレ＝メンタルモデル ”メンタルモデルとの乖離がないソフトウェア＝良いソフトウェア” どうしたらいいの？ 業務に関わる複数の人がどう理解してるか →メンタルモデルの共通化的な感じかな？ モデルを忠実に再現する メンタルモデルとの乖離・相違に気づく ↑ DDDってなんぞ？ (P.14) † DDD概要 実装方法、プロセス、OOPのテクニックじゃないよ 良いソフトウェアを作るための ガイドラ
mixiの新人研修トレーニングが非常にわかりやすくて実践的すぎる - Android Javascript iOS
mixiは新人研修用のトレーニングをgithubに公開しています。 公開していることは知っていたけれど、いざみてみると… とってもわかりやすく実践的！！！ 普通に参考書で勉強するよりも企業が公開しているものだから、より実践的という感じもします。 自分はこのAndroidTrainingをやっているのですが、最後に課題もあり、到達度や理解度もすごく把握できていい感じです。 READMEもかなり充実しており、一通りを学べるように工夫されています。 mixiに入社した方がこれを一通りやったと思うと、大変な印象ですが…だからこそやったときに達成感がありそうです。 開発環境の構築から書かれているので、ほとんどつまづくことはありません。 かなり詳しくわかりやすく書かれている印象を受けました。 ちょっと初めて学習するには、難しい箇所もありますが適宜ぐぐって補えばよいでしょう。 ・AndroidTrain
設計レビューに私情を持ち込んでいませんか？
設計・開発・運用業務に役立つ書籍をピックアップして紹介する新連載「情シスの本棚」。第1回は、システム開発の現場で働く多くの人が思い当たるであろう、設計レビューの問題点と方法論を解説した書籍を紹介する。 「システム構築プロジェクトでは、さまざまな会議が開かれます。そのなかでも、参加する際にとりわけ気が重いのは、ドキュメントの問題指摘を行うレビュー会議ではないでしょうか。長々と続くにつれてレビューアーがイライラし、ドキュメント作成者がつるし上げられたり、レビューアー同士で言い争いになったりする――。そんな状態だから、長い時間をかけた割に重大な問題を指摘しきれずに終わるケースが少なくありません」。「頑張るだけのレビューには限界があります」。「必要なのは、レビューのやり方を見直すことです」――。 本書、「間違いだらけの設計レビュー」は、レビュー方法論の第一人者である名古屋大学 大学院 情報科学研究
旧・Macの手書き説明書 - FC2 BLOG パスワード認証
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ https://mac-tegaki.comへ移転中 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
facebookアプリの作り方(PHP編) | PLUS
コンテンツへスキップ →web コメントコメントを残す コメントをキャンセルメールアドレスが公開されることはありません。 * が付いている欄は必須項目です コメント 名前* メール* サイト 次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。 Δ 先頭へスクロール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ダブル・ディスパッチ～ 典型的なオブジェクト指向プログラミング・イディオム ～
ドメイン・フレームワークのススメ(第1回)
ADO.NETとORMとMicro-ORM －dapper dot netを使ってみた