アジャイルサムライの次に読む技術書『アジャイルサムライ』の次に読むオススメの本 (プロセス系ではなく技術書) を Agile Samurai Base Camp TDDの部、講師 6 人で投票した結果の書影まとめです。 Apr 20, 2014 @ Agile Samurai Base Camp
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
ウェブサービス開発の現場におけるデザイナー不要論と5〜10年後の生存戦略 - 情報建築家 石橋秀仁
本稿では、まず「ウェブサービス開発の現場で、ウェブデザイナーの仕事はエンジニアに奪われつつある」という脅威を語る。次に、生存戦略を考えるヒントとして「分かりやすい生存戦略」を2つ提示する。「アートディレクター」と「フルスタックウェブデザイナー」という2つの生存戦略だ。 なお、「仕事を奪われていくプロセス」と「生存戦略を遂行するプロセス」について、5〜10年程度のタイムスパンをイメージしている。 ウェブデザイナーの仕事がエンジニアによって奪われつつある ウェブサービス開発の現場では、ウェブデザイナーの仕事がエンジニア／プログラマーによって少しずつ奪われつつある。とくに小さな組織や新規事業の現場では。 象徴的なのは「Bootstrapがあればデザイナー不要だよね」論。「もはや社員としてデザイナーを雇う必要はなくて、必要な時にランサーズで発注すればいいよね」「スタイルシートいじったり画像パーツ作
GitHub製フレームワークHubotの概要とインストール、チャットアプリと連携する基本的な使い方
近年、ソフトウェア開発を取り巻く環境が急激に変化してきています。ネットワークの整備や、コミュニケーションツールの進化に伴い、リモートワークやインターネット上での協業も盛んに行われるようになってきました。チームメンバー全員の住んでいる国が違う、といったこともあるかもしれません。 しかし物理的に離れた環境で働くと、今まで対面で行っていたコミュニケーションを別の手段で代替しなければなりません。SkypeやGoogleハングアウトなどのビデオ通話、HipChatやSlackなどのチャットアプリを利用することで仕事上必要なコミュニケーションは取れるようになりますが、ソフトウェア開発に関わる状況確認は別のツールを使う必要があります。 特にオペレーションは、いつ、誰が、どのような対応をしたか把握していたいですよね。 このような課題を解決する一つのスタイルとして、「ChatOps」があります。ChatOp
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ
Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Kent Beck氏がスタートアップのイベントに登壇し、素晴らしい講演をしたビデオを友人のタイムラインから見つけました。Startup Lessons Learnd: Kent Beck talks beyond agile programming アジャイルマニュフェストは10年が経過して、誰かの為にソフトウェアを作っていた時代から、スタートアップの時代に移行し、内容が一部古くなっていました。ところがこの講演でKentBeck氏は、それに対する素晴らしい回答をしてくれています。この内容が2010に行われているとは驚きです。
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902 This document provides an overview of the Plan 9 operating system developed at Bell Labs, including: - Plan 9 was developed starting in the 1980s as a successor to UNIX. - It uses a distributed kernel architecture with separate processes for file servers, window servers, and other functions. - Notable fe
昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど） - 未来のいつか/hyoshiokの日記
1990年代のインターネットというのは利用者も少なく閉じた世界観があって、自由というもののある種の見えない掟みたいなものがあった。あったのかもしれない。当時ネットニュースという掲示板みたいなものがあって、今で言うところの中二病をこじらせたいい歳をした大人たちが日夜あーでもないこーでもないと言い合っていた。 fjというネットニュースがあって、日々いろいろな話題が議論されていた。あなたの会社のエラい人も若い頃、そのネットニュースに書き込んでいたかもしれない。若き日の（15年前）まつもとゆきひろさんとかがいるよ。 たまたま、そのころのニュースを発見して、あまりの懐かしさにここに再掲することにする。若き日の、あの人やこの人の中二病時代の書き込みである。 編集解説はわたし。それ以外は、当時の誰か。 https://groups.google.com/forum/?hl=ja#!topic/fj.co
HtmlUnit – Welcome to HtmlUnit
Constantly updating and maintaining the HtmlUnit code base already takes a lot of time. I would like to make 2 major extensions in the next few months Add HTTP/2 support Replace the Rhino based JavaScript engine For doing this I need your Sponsoring. HtmlUnit is a "GUI-Less browser for Java programs". It models HTML documents and provides an API that allows you to invoke pages, fill out forms, cli
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the it
Principles behind the Agile Manifesto
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Busines
アジャイルソフトウェア開発宣言
アジャイル アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発の価値 プロセスやツールより人と人同士の相互作用を重視する。 包括的なドキュメントより動作するソフトウェアを重視する。 契約上の交渉よりも顧客との協調を重視する。 計画に従うことよりも変化に対応することを重視する。 原文 アジャイルソフトウェア開発の原則 最も重要なことは顧客を満足させること。早く、そして継続的に、価値のあるソフトウェアをリリースする。 開発の終盤においても要求の変更を受け入れる。アジャイルプロセスは顧客の競争力を優位にするための道具である。 数週間、数ヶ月の単位で頻繁に実用的なソフトウェアをリリースする。タイムスケールは短い方がよい。 プロジェクトの間中、毎日、顧客と開発者は一緒に働くべきである。 やる気のある人を中心にプロジェクトを構築する。環境と必要なサポートを与え、彼らが仕事を成し遂げると信じるこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デキるプログラマだけが知っているコードレビュー7つの秘訣（DevLove版）
はてなブログチームの開発フローとGitHub