眼鏡なしのコードレビュー | POSTD
例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか? 家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか？ そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード 1 不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一
Shill: Scripting with Least Privilege
The Principle of Least Privilege says that software shouldn't be executed with more authority than it needs to get its job done. Unfortunately, following this principle is hard; most operating systems are configured so that the scripts and programs you run can do anything you can. Shill is a shell scripting language designed to make it easy to follow the Principle of Least Privilege. Shill uses ca
Gura Programming Language
Gura Programming Language Download View on GitHub A programming language that comes with powerful operation on iterators. Gura is an iterator-oriented programming language that focuses on iterators with improved functions for calculation and data processing. The most poweful feature called Implicit Mapping enables you write a code of repetition without repeat control sequence. The code below is an
カーネルハッカー・小崎資広の「コードを読む技術」 | サイボウズ式
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回（毎週火曜日に掲載、これまでの連載一覧）。「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部） 文：西尾 泰和 イラスト：歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
APIデザインの極意 - ✘╹◡╹✘
APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る API設計は難しい "良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。 API設計を芸術的取り組みにしてはいけない API設計の
新装版 リファクタリング 既存のコードを安全に改善する | オーム社eStore
プログラムに潜む扱いにくい部分を見つけ出し、その動作を変えずに内部の構造を改善していくためのテクニックを整理したマーティン・ファウラー氏によるソフトウェア開発の名著『リファクタリング プログラミングの体質改善テクニック』（“Refactoring: Improving the Design of Existing Code”）が、オリジナルの訳者による丁寧な見直しと現代的なJava開発環境による「再リファクタリング」を施した書き下ろし付録を収録して再発行！ 旧版の価値を知るベテランはもちろん、これからソフトウェア開発に携わる新人にも必読の一冊です。
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
要約：iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い - Qiita
はじめに 社内勉強会の資料をSlideShareのUPしました。 iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い これについての要点をまとめます。 この資料はiOS/Androidのような クライアントアプリケーションにおける「Model」とは何か、という話です。 Modelとは何か？ Modelに「データやビジネスロジックを扱うコンポーネント」という役割を担わせるというのは多くの人がやっていることだと思います。しかし、サーバ側のWebアプリケーションとは異なり、クライアント側のiOS/AndroidアプリのModelには次の２つの振る舞いがとても重要です。 基本死なない（Singleton的である） 「通知」で変更を伝える（Callback的ではなく） そのようなModelがなぜ必要か？ この2点の役割を持つコンポーネントがなく、特に何も考えずにスマホ
可読性の高いコードの書き方
意識の高いエントリを書いてみる。 難解なコードを書く上でもっとも重視しなければならないのは、可読性である。カーネルのように、品質を重視される分野では、特に重要となる。 可読性について基本的なことは「リーダブルコード」という 本に書いてある。変数のローカリティは小さく！ガードを使って早く関数を終了させろ！など、プログラマにとっては当たり前のことがよくまとまっている点に価値がある。 以下では、可読性の高いコードを書く上で気をつけた方が良い二点を紹介する。 抽象度を一定に保つ可読性の高いコードは、物語を読むように頭に入ってくるコードである。物語を構築する上で大切なのは、一定の抽象度で書くということである。物語の中に、極端に抽象度の高い話が紛れ込むべきではないし、あまりに細かい話が見えるべきでもない。 例えば、パンを焼いて、バターを塗って、食べるという動作の中に、わけのわからない化学反応を書くべき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - artagnon/rhine: 🔬 a C++ compiler middle-end, using an LLVM backend
BestFreeCams.club - Only the Best Free Live Cams
GitHub - runekaagaard/snowscript: A language that compiles to PHP
Amazon.co.jp: APIデザインの極意 Java/NetBeansアーキテクト探究ノート: Jaroslav Tulach (著), 柴田芳樹 (翻訳): 本
GitHub - whitesmith/rubycritic: A Ruby code quality reporter
GitHub - troessner/reek: Code smell detector for Ruby
GitHub - cognitect/transit-format: A data interchange format.
GitHub - seattlerb/flay: Flay analyzes code for structural similarities. Differences in literal values, variable, class, method names, whitespace, programming style, braces vs do/end, etc are all ignored.
Inch CI
GitHub - Koruri/Kibitaki: [DISCONTINUED]![GitHub - Koruri/Kibitaki: [DISCONTINUED]](https://cdn-ak-scissors.b.st-hatena.com/image/square/0d1cb8ad153095f51c9413761e2ce156bfc04099/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2Fbc03ad43611a72dcc27628182489ce0c5fb8e856ade0b5b9303bdbba4989673b%2FKoruri%2FKibitaki)
