書籍制作ワークフロー シリーズ 【書籍制作ワークフロー】ReVIEW 入門 #09 – config.yml について 記事 2013年12月10日 山田 直樹 11 config.yml - ePUB 生成向けの設定ファイル ReVIEWからePUBを生成するにあたって、様々な設定を定義するのがconfig.ymlというファイルです。ePUBのファイル名はもちろんのこと、奥付に表示さ […]
書籍制作ワークフロー シリーズ 【書籍制作ワークフロー】ReVIEW 入門 #09 – config.yml について 記事 2013年12月10日 山田 直樹 11 config.yml - ePUB 生成向けの設定ファイル ReVIEWからePUBを生成するにあたって、様々な設定を定義するのがconfig.ymlというファイルです。ePUBのファイル名はもちろんのこと、奥付に表示さ […]
背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
愛知県でシステムエンジニアとして働く友人のMは、プロジェクトメンバの書くJavaのクソコードに苦しめられているそうです。Mはリードプログラマとして、プロジェクトメンバがあげてくる成果物（ドキュメントとコード）のレビューをする立場にあるらしく、提出されてくる数々のクソコードをTwitterでつぶやいていました。 Mを救うことはできるのでしょうか？ もし、クソコードをすばやく見つけることができたら救えるのであれば、救える見込みはあるかもしれません。 コードの問題を見つける静的解析ツール クソコードとは、おおむね次のような問題のあるコードをさすようです。 潜在的バグ バグの可能性があるコード。 重複 機能追加やバグ修正を困難にしがちなコードの重複。 設計上の問題 クラスやパッケージ間の依存関係、多すぎるメソッド引数など。 慣習違反 プログラミング言語やライブラリの慣習、コーディング規約などに違反
クッキー・クリッカーについて
昨日、筆者はクッキー・クリッカーなるゲームを体験した。このゲームは、ゲームの本質を非常によく抽象化している。ここではそのゲームについて述べるが、読者には実感のため、並行してゲームを行なってもらいたい。 このゲームのプログラムはHTML/CSS/JavaScriptと、その他のリソースで構成されていて、ストールマンの自由四原則に合致する自由ソフトウェアではないが、一応は、制限的ながら、forkや改変を許諾している。このプログラムを動作させるには、まともなブラウザーが必要である。 Cookie Clicker まずみると、左に素晴らしくうまそうなクッキー、中央によくわからない列、右によくわからない小物が並んでいる。操作方法がよくわからない。まず、左にこれみよがしに配置してある、うまそうなクッキーをクリックしてみよう。 +1 なんと、クッキーが一枚得られた。続けてどんどんクリックしていくと、数十
1. RESTful Web アプリの 設計レビューの話 和田 卓人 (a.k.a id:t-wada or @t_wada) July 23, 2012 @ sendagaya.rb 3. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社 取締役社長 4. 私と REST (input) • WEB+DB PRESS vol.32「REST アーキテクチャスタイル入門」 • はてぶ設計議論 • DHH の RubyKaigi 2006 Keynote • WEB+DB PRESS vol.38∼「REST レシピ」 • 『RESTful Web Service』
*本ブログは Atlassian Blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2012 年 9 月 27 日、Sten Pittet 投稿 “Reviewing code on any hosting service with Crucible” 開発チームが一定のサイズに達すると、きれいなコードレビュープロセスを持つことが難しくなります。リモート開発者がペアリングできない、レビュー待ちに並ぶチェンジセットが多すぎる、レビューに携わる人々が多すぎる、など。そのプロセスを合理化する方法、そして見る必要があるすべての変更を追跡する方法が必要です。 Crucible (クルーシブル) は非同期型ピアコードレビューという方法を提供することによって、これらの問題を解決します。ブロッカーになっている人々を見つけたり、未完了のレビューを閲覧したり
最近はどうもJenkinsとかTravisCIとかいうのが話題みたいなのだが、使ったことがないのでよくわからない。だがどうも漏れ聞く話を見ていると、こういうのは継続的インテグレーション(CI)と呼ばれていて、だいたい自分の社内プロジェクトでも似たようなことをやっているらしい。そこで、Chromiumがどういう環境でCIしているか、ということを簡単にまとめてみたい。あらかじめ書いておくと、名前が違うだけでだいたい普通です。 BuildBot Chromiumは普通のクライアントプログラムなので、ビルド環境の想定がけっこう複雑だ。Windows/Mac/Linux/ChromeOS(最近はAndroidなどのモバイル環境)のようにプラットフォームは多岐にわたるし、同じプラットフォームでも様々なビルドコンフィグレーションがある。テストも数が多く、ローカルに走らせておくのは時間がかかる。 Buil
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
コードレビューについて Oh, you `re no (fun _ → more) より引用 単に普段の開発で使っている VCS でそれを行なっていました。 つまり、コードの中にコメントの形でレビューを書き、それをコミットする。 そしてそこから派生する議論も全てコード上のコメントで行います。 (もちろん複雑な話になった場合は直接の議論を行い、合議の結果だけを記しておく、なども当然あるでしょう。) レビューをソースコードのコメントとして直接書き込むのは、GHC の開発でも時々見かけますね。例えば、新機能の開発 branch を作って、新しい機能を開発している時とか。 2012-08-14 18:44:19 via OpenTween まあ、主に入った変更に Simon Peyton Jones が（ソースコード上で直接）コメントしそれに従ってソースコードを修正する形なので、レビューと言えるほ
この本は、Haskell の入門書として、超お薦めです。 「木を見て森を見ず」という言葉がありますが、従来のHaskell入門書というか、言語の入門書は 「木」の解説ばかりで、「森」を見失っていたのではないかと思います。 今まで何冊ものHaskell入門書を読みながらモヤモヤとした気分のままだった私も Haskellに 一歩近づけた気がします。 プログラミングHaskell 作者: Graham Hutton,山本和彦出版社/メーカー: オーム社発売日: 2009/11/11メディア: 単行本（ソフトカバー）購入: 14人 クリック: 503回この商品を含むブログ (117件) を見る Haskell は 参照等価、遅延評価、パターンマッチ、モナド・・・ など、C、Java、Ruby ... とは大きく異なるプログラミング言語です。 Javaを理解している人がRuby を学ぶ際には 「木」
機能要件の合意形成技法WG の成果として、「発注者ビューガイドライン」 （2008年7月に公開）を改訂し「機能要件の合意形成ガイド」を公開します。 開発者が設計書を記述することのみではなく、発注者と開発者がシステム像をいかに共有し、行き違いなく合意形成を行うかに注目して、有効と思われる事柄を「コツ」としてまとめました。 「発注者ビューガイドライン」では画面、システム振舞い、データモデルの3つの技術領域、187のコツを掲載していましたが、「機能要件の合意形成ガイド」では、外部インタフェース、バッチ、帳票の3つの技術領域を追加するとともに、発注者視点のコツも充実させ、278のコツを掲載しました。 なお、初めて利用される方は、概要編を読んでいただくことをおすすめします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: ソフトウェア・レビュー技術: 基礎から実践までのノウハウ: 織田巌: 本
Amazon.co.jp: ピアレビュー: Karl E.Wiegers, 大久保雅一: 本
