RESTful#とは勉強会で公開レビューしてきました - Sweet Escape
2/22にヴァル研究所さんのオフィスで開催された「RESTful#とは勉強会13回」に公開レビュー企画のゲストとしてお呼ばれしてきましたー。 この勉強会自体は今回で13回目とそこそこ回を重ねた勉強会で、RESTful APIについてみんなで学び考える会となっているそうで。すみません、こういう勉強会があることは知ってたけど参加は初めてでした。 で、公開レビューとは何かというとヴァル研究所さんと言えば「駅すぱあと」なわけですがこの駅すぱあとのWeb版である「駅すぱあとWeb」の公開APIをRESTの観点でみんなの前でレビューするというチャレンジングな企画でした。 RESTful APIが何かについては以前に発表に使ったこのスライドを参照してもらえれば。 RESTful API 入門 from Keisuke Nishitani さて、今回のそもそものキッカケは、この勉強会の運営にヴァル研究所の
テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
酔っ払ってUXレビューをして学んだ10のこと | POSTD
フリーボーナスガイド：あなたはフリーランスのUXデザイナですか？ ビジネスの成長を加速するのに必要な全てがこの総合ガイドに詰まっています。 こちらからダウンロードしてください 。 こんにちは。このブログでは、一般的な記事のようにモノローグ的に書いていくのではなく、読者の方といきなり対話するような形で始めたいと思っています。私はRichardです。 The User Is Drunk（利用者は酔っている） を運営しています。The User Is Drunkは、クライアントのホームページが酔っ払いにどんな風に見えているか、というのを彼らに伝えるために、私が数カ月前に立ち上げたサイトです。 手順はこんな具合です。まずは私が酒を飲んで酔っ払い、クライアントのWebサイトを見ます。そして、どうやったらそのサイトがもっと良くなるかを、普通の利用者の視点で考えます。つまり、私の就業時間は通常は夜になり
組織における、エンジニアの情報共有について。あるいは、レビューや設計について。 - # TODO: タイトル決定
これは、「ドリコム Advent Calendar 2015 その2」の、8日目の記事になる。 7日目は、middlemanとGitHub Pagesでブログを5分で開設！ほか盛りだくさん！ | いくら寝ても眠たい だった。 私は、ドリコムでエンジニアをしている matsusaki (@misoobu) という者だ。 ここでは、最近考えることの多い、組織におけるエンジニアの情報共有と、そのあるべき姿について書く。 また、それに関連して、コードレビューや設計についても触れる。 内容は、エンジニア視点のものになる。 情報共有は、組織にとって極めて重要だが、簡単なことではない。 本記事が、再考するきっかけとなれば、幸いである。 情報共有とは 情報共有を失敗するとどうなるのか 様々な情報共有 プロジェクトの状況や方針 作業内容とその状況 プログラムの設計やコード レビューの目的 レビューをするとき
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
「TWE-LiteのArduino化」のコピー本を作った話 - Qiita
これはなに？ 前回アップしたステマ記事が 割と好評でしたので、その元ネタとなったコミックマーケット88で頒布したコピー本を 原稿ごとgithubに上げておきました。 PDFはこちら。https://github.com/soburi/jn5164-twelite-guided-tour/raw/master/publish/jn5164-twelite-guided-tour-publish.pdf 前回の記事の方では、TWE-LiteをArduino化して使う方法を紹介させていただいたのですが、 コピー本の方では、その「Arduino化」の方法、Arduinoのマイコン部分のソースを 他のアーキテクチャ(TWE-Lite)に移植する方法をハンズオンで紹介しています。 ということで、読者として以下のような層を想定した記事となっています。 オレオレArduinoを作成したい方 Arduino
品質におけるコメントの役割。あるいは、レビューとコメント - きしだのHatena
昨日のエントリでも書いたきょんくんとの会話なんだけど、なんとなく、コメントとテストは同じように扱えるんではないかという認識のもとで話がすすんでた。もちろん、コメント書けばテスト書かなくていいとかそういうのではなくて。 テストは、書きやすい対象と書きにくい対象がある。関数的に計算を行うコードの場合はテストが書きやすい。一方で、関数的ではなく副作用のあるコードはテストが書きにくい。データベースを扱ったり通信したりUIがあったり。 そして、そのようなテストを書きにくいときに、コメントはテストのように品質のために使えるんではないか。 で、問題は、どのように品質のために使うかということなんだけど、コードレビューのときの指針として使えばいいんじゃないかなと思った。 コードレビューのとき、コードだけを見ていると、名前付けとかコードの順番とか条件文の使い方とか、体裁的なものだけのレビューになりがち。そこで
JS自動レビューツール"jswatchdog"を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。kintone 開発チームの天野 (@ama_ch) です。すっかり春らしくなりましたね。 少し前に JS の自動レビューツール jswatchdog をオープンソースで公開しましたので、こちらで紹介させていただきます。 使い方 https://kintone.github.io/jswatchdog/ 上記の URL を開き、左側のエディタに JS コードを貼り付けるだけです。 右側に修正が必要な箇所が表示されるので、適宜修正します。 特徴 バリバリの開発者じゃなくても使いやすい一画面完結の Web インターフェース lint ツールでお馴染みの構文チェックの他、知らずに脆弱性を作り込むことを避けるため、XSS の可能性がある箇所にも警告を表示 内部的には、JS の静的構文チェックツールとして ESLint と JSHint を組み込んでいます。 さらに XSS の可能性があ
Practical Lessons in Peer Code Review
Millions of years ago, apes descended from the trees, evolved opposable thumbs and — eventually — turned into human beings. We see mandatory code reviews in a similar light: something that separates human from beast on the rolling grasslands of the software development savanna. Nonetheless, I sometimes hear comments like these from our team members: “Code reviews on this project are a waste of tim
眼鏡なしのコードレビュー | POSTD
例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか? 家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか？ そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード 1 不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一
キック・アスなコードレビューを全てのチームに | Atlassian Japan 公式ブログ | アトラシアン株式会社
ソフトウェア開発では、複数のチームで共同作業をする場面がよくあります。チーム構成人数が 1 人、2 人、それ以上へと増えるにつれ、問題が生じて創造的なワークフロー体系に支障が出始めます。そして多様な人々からなるチームにおいて、カルチャーを維持することが難しくなります。コードは日常的に組織全体の多くの人々の間で共有されるため、コードを扱うエンジニアグループは特にその問題の影響を受けやすい傾向があります。コードレビューを行うことは、コード関連のナレッジとベストプラクティスをチーム全体に普及させるのに役立ちます。この記事では、コードレビューが重要な理由と、コードレビューの実践を最適化する方法について説明します。 コードレビューとは？ ソフトウェア開発は、個々人の作品をコラボレーションという 1 枚のキャンバスの上にまとめたアート作品のようなものです。各開発者は、コードがキーボードを通じてあふれ出
今のコードレビューのやり方 - $shibayu36->blog;
コードレビュー - hitode909の日記 この話。 大体こういう風なやり方をしてる。Diffだけを見るんじゃなくて手元でもコードチェックアウトしてて、それとDiffを行ったり来たりしながらレビューすることが多い。こういう方法のほうがかっこいいよねみたいなのは書くけどその通りにしてもらうことを強制はしないというのも賛同。 逆にcommitの中身*1はあえて見ないようにしてる。僕はレビューする時に、そのコードについての学習が行われていない状態で見たほうが良いなと思っている。commitの中身を１つずつ見ていくと学習が進んでしまって、少しわかりづらいコードもあっても、学習が進んでいるせいで無意識に目からすり抜けてしまうという経験があったので、あえてcommitみないということをしてる。 例外もあって、少し大きめなリファクタリングが行われた時はcommitを１つずつ読んでいくことが多い。少し大
iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary
日常的なコードレビューで気をつけていることリストです。GitHub会議(仮)で発表しようと思っていたのですが、日程の都合で参加できないので、書きためておいたメモを公開します。またどこかで発表するかもしれません。 AutoLayoutにできないか AutoLayout化した方がすっきりしそうならAutoLayout化する AutoLayout化できそうなものでやっていないものは、なぜコードで実装したか質問する 例えばUITableViewCell ちゃんと理由があれば別に良い。コードの方が良いことも多い UIAppearanceで解決できないか 各クラスの中にスタイルの指定が入るより、UIAppearanceでスタイル指定を分離して別クラスに書く方がデザイナーも弄りやすくて良い 3.5インチ端末が考慮されているか レイアウトが決め打ちだとここで問題が出ることが多い 着信ステータスバーが考慮さ
レビューで失敗しない8つのポイント
ソフトウェア開発の品質・効率向上に欠かせないレビュー。しかし、やり方を間違えているために、かえって逆効果になっているケースが多い。本連載ではソフトウェアレビュー研究の第一人者、森崎修司氏が豊富な現場経験と研究成果を基にレビュー成功のポイントを分かりやすくリアルに解き明かす。 なぜレビューがうまくいかないのか？ ソフトウェア開発の品質・効率向上が求められている今、ソフトウェアレビュー（以下、レビュー）の重要性はますます高まっています。商用開発では「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが行われていますし、オープンソースソフトウェアのプロジェクトでも、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 しかし、レビューは自由度の高い活動です。レビュー会議では本質的な欠陥や問題を指摘しても、欠陥
Hound
Review your Ruby code for style guide violations with a trusty hound. View the style guide Sign In with GitHub Activate Repos Tell Hound which GitHub repos to watch. Commit & Pull Request Code Write and commit code as you normally would then open a pull request to get review by Hound. View Hound Comments Hound will review your pull request and make inline comments on any style guide violations. Si
Hubotを導入したらレビューの敷居が下がった話 - yo_waka's blog
ウチの会社ではHipchatとGitHubを開発のコミュニケーションの中心にしている。 だんだん人も増えてくると、以前よりプルリクの数がそれだけ増えて、レビューで1日終わってしまう人がでてきた。 昔から仕様を知っている人にレビューが投げられがちで集中しやすいとかは他の会社でもよくある話しだと思う。 レビューは自分のタスクと同様に大事だけど、それで自分のタスクが全くできなくなったり、新しく入ってきた人がレビューする機会を失うのはあまりよくない。 というのもあって、Hubotを立ててみてプルリクのレビュアーをランダムで振れるようにしてみた。 Hubotというのはご存知Hipchatのbotとして動くプログラムで、botにコマンドを指定してリモート実行させたり、特定の文字列に反応させたりということがHipchat上でできる。 CoffeeScriptでスクリプト書けるのでとてもお手軽。 sush
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Code reviews still rule | Vallified
DataSpider Technical Network
GitHub - sable-virt/source-review-tool: LIGでかつてソースコードをリアルタイムに共有してレビューするために使っていたツール
