2016/07/15の「Growth Hack Night 〜エンジニアが語るプロダクトの立ち上げとグロース〜」の発表資料です。 http://d-cube.connpass.com/event/35259/
個人開発と徳
2016/07/15の「Growth Hack Night 〜エンジニアが語るプロダクトの立ち上げとグロース〜」の発表資料です。 http://d-cube.connpass.com/event/35259/
DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
APIファーストで開発する - ワザノバ | wazanova
http://blog.pop.co/post/67465239611/why-we-chose-api-first-development POPは、簡単にビジネス/アイデアをかたちにするために、1分でドメイン/スタートページ/メアドを用意できるサービスとのこと。彼らが、「APIファースト」で開発しようとした理由を紹介してます。 1) 将来APIを提供できるように 機能を追加する都度、APIが既に準備できているかたちになるので、将来APIを第三者に提供するときもスムーズ。 2) フロント/バックエンドの分離 バックエンドのテンプレートコードがフロントエンドのクライアントビューとやり取りしない仕様にすることで、将来の開発に負の資産を残さない。 3) スケーラビリティ フロント/バックエンドそれぞれを独立してスケールさせることができるので、将来的にメリットがでるはず。 4) 開発言語のバリア
qnypではHipChatでどんなふうに開発を快適にしているか | qnyp blog
こんにちは、あさくらです。 みなさんHipChatってご存知でしょうか？ HipChatは企業やチームのためのホスティング型プライベートチャットサービスのことで、継続的に使えるチャットルーム、チャット履歴の保存、外部サービスとの連携に便利なAPI、などの特徴を持ちます。 キュニップでは社内開発用のグループチャットとしてHipChatを利用しているのですが、先日HipChatの利用事例を発表する機会があり、その際に使用したスライドを公開しました。 外部サービスとのAPI連携と、内製のHipChat専用ボットqubot（キューボット）について紹介しており、HipChatを使ってどんなふうに開発を快適にしているのかがかいま見れる内容になっています。 HipChatを使い始めたけれどもう一歩便利にしたい、そんな開発者さんに見てもらえると嬉しいです。
永和システムマネジメント アジャイル開発支援事例｜株式会社ネクスウェイ
ネクスウェイ システム推進室 松森正彦 氏、小田切一成 氏 に、永和システムマネジメントのアジャイル開発支援サービスを採用した経緯と評価について詳しく聞きました。 第一部： 「アジャイル開発指導を取り入れて、ヒット商品の開発に成功」 第二部： 「NEXLINK BASICがヒット商品になった本当の理由」 第三部： 「『開発を一度ストップする』という決断」 第四部： 「プロジェクトマネージャーは知っておいた方がよい、アジャイル開発の影の部分」 ネクスウェイについて ネクスウェイは、ソフトウエア、FAX、メールなどを通じてBtoBマーケティング支援する企業です。主な商品は、NEXLINK、eオンデマンド便サービス、e帳票-FAXサービスなど。年商249億円、取引法人 約8000法人、従業員数249名、創立は2004年10月。 NEXLINK BASICについて NEXLINK BASICは企
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
Scala の開発に学ぶコードレビュー体制とプロジェクト開発 - xuwei-k's blog
コードレビューについて Oh, you `re no (fun _ → more) より引用 単に普段の開発で使っている VCS でそれを行なっていました。 つまり、コードの中にコメントの形でレビューを書き、それをコミットする。 そしてそこから派生する議論も全てコード上のコメントで行います。 (もちろん複雑な話になった場合は直接の議論を行い、合議の結果だけを記しておく、なども当然あるでしょう。) レビューをソースコードのコメントとして直接書き込むのは、GHC の開発でも時々見かけますね。例えば、新機能の開発 branch を作って、新しい機能を開発している時とか。 2012-08-14 18:44:19 via OpenTween まあ、主に入った変更に Simon Peyton Jones が（ソースコード上で直接）コメントしそれに従ってソースコードを修正する形なので、レビューと言えるほ
「開発者のためのリーン・スタートアップ」「リーン・キャンバス入門」の資料を公開します - Kentaro Kuribayashi's blog
隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
新しい何かに取り組むプログラマさんたちへ | y_matsuwitter's
桜の季節が近くなってきましたね。 春といえば出会いと別れの季節です。 我々プログラマも、ともすると４月から就職して新しいプログラミング言語やプロジェクトに出会うのではないでしょうか。 僕は１月に戦場を移動した関係で、１月から初めてRubyに取り組みました。 またObjective-cも書き始めています。 何かの参考になればと思い、今回の経験から僕なりの新しいプログラムへの取り組み方の定石みたいなものを偉そうに書いてみようと思います。 Kiai Driven Development 新しい言語やプロジェクトに出会ったとき、KDD（気合駆動開発）信奉者の僕が気を付けている点が３つ有ります。 それを一から紹介します。 Githubをとにかく巡れ！ 新しい言語に取り組むとき、僕はまずGithubのその言語に関するwatchやfolkのランキングを見てます。 ランキングは、Github上部のExpl
フリーランスとか大手とか言ってないで『ソニーの開発18か条』を今こそ振り返ってみよう！|ガジェット通信 GetNews
今回はshogo_shibusawaさんのブログ『Onigiri.blog』からご寄稿いただきました。 昨日、人生の先輩に当たるお二人と恵比寿にて焼き鳥＆ビール♪ メンターの大切さ、ソーシャル～な話、新卒の就職活動、大手企業の話、色々とお話をするなかで『SONYの開発18か条』というものの存在を教えてもらいました。自分にとってものすごく示唆に富んでいたので皆さんにもシェアさせていただきます。 これは、『ウォークマン』の開発に携わった大曽根さんという方のチームで唱えられていたものだそうです（出井さんCEO就任前に）。まずはご覧ください。 ソニーの『開発18か条』 第1条：客の欲しがっているものではなく客のためになるものをつくれ 第2条：客の目線ではなく自分の目線でモノをつくれ 第3条：サイズやコストは可能性で決めるな。必要性・必然性で決めろ 第4条：市場は成熟しているかもしれないが商品は成熟
ソフトウェアをつくるための３つの役割〜アジャイルに外部設計は必要か | Social Change!
ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で
＠IT：WCR Watch [6] 人・チームが成功の鍵となるリッチクライアント
最新トレンドやキーワードをわかりやすく解説 WCR Watch ［6］ 人・チームが成功の鍵となるリッチクライアント 宮下知起 2005/8/4 株式会社セカンドファクトリーは、デザインとシステムのコラボレーションをWebやキオスク端末などのリッチクライアント構築を通じて手掛けてきた異色のWebインテグレータだ。業界の評価は高く、最近ではJALのFlash版航空券予約サイトの構築も手掛けたことで知られる。今回は、リッチクライアント開発の経験が豊富なセカンドファクトリーに、リッチクライアント開発（本稿では以降「RIA：リッチ・インターネット・アプリケーション」と略す）を成功させるための人とプロジェクトとチームの理想像について聞いた。 Webアプリケーションが抱える生産性低下、顧客満足度低下の課題は、RIA技術を採用しさえすれば解決するものではない。RIAの開発は、ユーザーに使いやすいデザイン
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
ソースコードの品質向上のための効果的で効率的なコードレビュー
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub
Good night, Posterous
アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～
[Studying HTTP] HTTP Header Fields