Phacility - HomePhabricator is a set of tools for developing software. It includes applications for code review, repository hosting, bug tracking, project management, and more.
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
JavaのString生成方法がボトルネックになっていた話 - WAF Tech Blog ｜ クラウド型 WAFサービス Scutum
はじめに 先日、私たちが開発しているクラウド型WAFサービス、Scutum(スキュータム)において、予想していなかった箇所の修正によってサーバの負荷が大幅に減るということがありました。原因はこのエントリのタイトルにもあるように、Stringクラスのインスタンスを生成する際の方法にありました。 Stringクラスのコンストラクタとcharset Stringクラスにはいくつかのコンストラクタが用意されています。我々が使っていたのはString(byte[] bytes, String charsetName)です。2つめの引数で、"MS932"や"UTF-8"のような文字集合(以下charset)を明示的に指定するものです。 ScutumのようなWAF(Web Application Firewall)は通常のウェブアプリケーションとは異なり、起動している間にさまざまなcharsetを扱うこ
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
ORMがアンチパターンである11の理由
サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。 I cannot overstate the degree to which ORM is a dangerous antipattern. — Laurie Voss (@seldo) June 9, 2011 ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。 当初は有益
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
文字コード地獄秘話 第1話：Unicodeにおける全角・半角 - ALBERT Engineering Blog
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
Glocalization 2013 #3 テキストのハードコーディングは痛い (精神/肉体/経済的に)
テキストハードコードするとどんなことがヤバイかを簡単にまとめました。 新人さんなどに説明するのが面倒くさい時などにご活用ください。Read less
ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想 JaSST'12 Tokyo
ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想 JaSST'12 Tokyo 先週、1月25日と26日に都内で行われたソフトウェアテストに関するシンポジウム「ソフトウェアテストシンポジウム JaSST'12 Tokyo」。2日目の招待講演では、ソフトウェアテストの過去を振り返り、将来を展望する非常に興味深い話を、東海大学大学院 山浦恒央准教授が行いました。 講演の内容をダイジェストとして紹介します。 （この記事は「ソフトウェアテストの30年前と30年後（前編）～テストの根幹は30年前に書かれた JaSST'12 Tokyo」の続きです） ソフトウェア製品の品質のレベル分けが行われる 30年後のソフトウェア開発技術とテスト技術について。予想というか、こうなってほしいという期待を交えた話をしようと思う。次の4つがその予想だ。 まず、各ソフトウェア製品がど
設計レビューに私情を持ち込んでいませんか？
設計・開発・運用業務に役立つ書籍をピックアップして紹介する新連載「情シスの本棚」。第1回は、システム開発の現場で働く多くの人が思い当たるであろう、設計レビューの問題点と方法論を解説した書籍を紹介する。 「システム構築プロジェクトでは、さまざまな会議が開かれます。そのなかでも、参加する際にとりわけ気が重いのは、ドキュメントの問題指摘を行うレビュー会議ではないでしょうか。長々と続くにつれてレビューアーがイライラし、ドキュメント作成者がつるし上げられたり、レビューアー同士で言い争いになったりする――。そんな状態だから、長い時間をかけた割に重大な問題を指摘しきれずに終わるケースが少なくありません」。「頑張るだけのレビューには限界があります」。「必要なのは、レビューのやり方を見直すことです」――。 本書、「間違いだらけの設計レビュー」は、レビュー方法論の第一人者である名古屋大学 大学院 情報科学研究
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
よいコメントの書き方入門（心構え編） - 新・日々録 by TRASH BOX@Eel
最近、会社でソースのコメントがらみで苦労して、ふと思った。 適切なコメントの書き方についての実践的な入門資料はないものか？ 『CODE COMPLETE 第2版 下 完全なプログラミングを目指して』の第33章や『Code Craft ~エクセレントなコードを書くための実践的技法~』の第5章では良いコメントについて結構なページ数を割いて詳しく論じているし、そこまで詳細でなくてよいのなら『プログラミング作法』の第1章で良いコメントの書き方の基本方針的なものが提示されている。参考になりそうな本はあるのだ。 ただ、ネット上でそれなりにまとまった資料となると、探し方が悪かったからかうまい具合に見つからなかった。本だと買って読んでくれる人が中々いないので*1、ネットで読めるものが欲しいのだ。 そこで、車輪の再発明であることを承知の上で、試しに自分で書いてみた。 対象読者は……そこまで考えていなかった。
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
Pythonを取り巻く開発環境（PyCon JP 2012資料 #pyconjp） - YAMAGUCHI::weblog
はじめに こんにちは、Python界の情弱です。情弱ながらPyCon JP 2012で1セッション持たせてもらえることになりました。予め資料を公開しておきますので、当日は色々と質問・意見して頂ければと思います。 各トピックは各トピックでの総論になっていますので、細かい部分は本文最後の参照にあるリンクを見るとより理解が深まります。 「なおここに書いてある内容は所属する団体とは関係のない、私個人の見解ですので、予めご了承下さい。」テンプレ終わり。 イベント PyCon JP 2012 発表日時 2012-09-16 11:00-11:45 作者 @ymotongpoo URL http://2012.pycon.jp/program/sessions.html#session-16-1100-room357-ja スライド （追記: 2012/09/16 23:50:00） 発表の24:00頃
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
お前自分ちのページャUIが本当に速いと思ってんの？
GitHub Flow (Japanese translation)
デスマーチが起きる理由 - ３つの指標
IBM Developer
