単一責任原則 - Strategic Choice
The Single Responsibility PrincipleUncle Bob単一責任原則ロバート・C・マーティンどういうこと？良いデザインの基本原則を、強いて１つ選ぶとすれば、それは「単一責任原則（SRP：Single Responsibility Principle）」です。変更する理由が同じものは集める、変更する理由が違うものは分ける。これはつまり、１つのサブシステムやモジュール、クラス、関数などに、変更する理由が2つ以上あるようではいけない、ということです。たとえば？ルール、レポート、データベースに関わるメソッドを持つクラスがあります。 public class Employee { // ルール：給与計算 public Money calculatePay()... // レポート：作業時間報告書 public String reportHours()... // デー
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
コーディングに最適な日本語対応の等幅フォントSource Han Code JPとは – ICS MEDIA
コーディング向けの日本語対応の等幅フォント「Sourceソース Hanハン Codeコード JPジェイピー（和名：源ノ角ゴシック Code JP）」が、2015年6月4日に公開されました。「源ノ角ゴシック Code JP」は、プログラミングやHTML/CSSのコーディング、ターミナルでのテキスト表示など、和欧表示用フォントとしての利用を想定されたフォントです。 ダウンロードはこちらから Release Fonts (OTF, OTC) · adobe-fonts/source-han-code-jp · GitHub ※このフォントは無償でダウンロード可能です。OTCとTTFの両方のフォーマットで配布されているので、Windows/macOSともに簡単にインストールできます。 ※上記リンクの「Fonts version ［バージョン番号］ (OTF, OTC)」となってい箇所の［Sourc
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
Elastic tabstops - a better way to indent and align code
Intro - the status quo sucks Since the days of the character mapped display, programmers have argued over whether tabs or spaces should be used to line up text. While both strategies can be used if all of a project's programmers can agree on how many spaces wide a tab should be, experience has taught us that this is not always the case. Even if all of the programmers working on a project are dilig
1文字変数 - ( ・ω・)ノ＜しすてむ開発。
たまに見かける。 おいらはこれが嫌いだ。 コーディング規約を作る際に心がけていることがある。 「ネコにでもわかりやすい」 変数一つにしてもどんな役割か、どんなスコープかがわかる。 オブジェクトにしてもどんな役割か、どんなスコープかがわかる。 コメントが無くてよいはずは無く、 データ格納型の変数に至ってはその型をも表すようにしたい。 メソッド名もまた然りである。 それらを決める際には「どんなのがわかりやすいか」 「どうあれば親しみやすいか」 「どうやったら言語に触れたての人にもっつきやすいか」 等などを考慮する。 追加人員が来たときに必ず取られる教育期間を1分1秒でも短くするためである。 *1 そして慣習で作られているネーミングに至っても、 「それを行う事のメリットはどこにあるか？」を考慮する。 「開発時」、「保守時」、「仕様変更時」の三つを考慮材料に入れ、 原則として「開発時」のみに有効な
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
- 設計の終焉?
設計の終焉? (原題: Is Design Dead?) マーチン・ファウラー チーフサイエンティスト , ThoughtWorks エクストリーム・プログラミング(XP) をかじってみて、多くの人がこう感じ ただろう。XP は「ソフトウェア設計など消え失せろ」と言っているのではな いか、と。というのも XP では、多くの設計作業が 「料金前払いのデカい設 計("Big Up Front Design"」などとからかわれているばかりか、UML、柔軟な フレームワーク、そしてパターンまでもを含む設計技法が、ぞんざいな扱い を受けているか、完全に無視されているからだ。 実際には、XP にもたくさんの設計作業が含まれている。しかしそれを、既存 の設計プロセスとは違うやり方で行っているのだ。「進化的設計」という考え 方がある。XP はこの考え方を、「進化」を実行可能な設計戦略へとに変換す るプラク
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
英語でコミットを書こう
ࣗݾհ • ϙʔϧ (@pwim) • Ͱ • Tokyo Rubyist Meetupͷओ࠵ऀ Sunday, July 29, 12
オープンソース実践特論(プログラム開発実践特論)
現代の情報技術開発において基盤的位置付けを占めるまでに成長したオープンソースソフトウェア（OSS）に関する基礎的な要素技術と、その開発の仕組みを、具体的な演習を交えて学習する。本講義においてはOSS開発に欠かせない関連技術動向を学習し、最新技術をキャッチアップできるようになるためのスキルを身につける。 レッスン１：開発の流れとツール OSSに関する典型的な開発の流れと、開発で利用する各種ツールの概要について学ぶ 清水 浩行 （株式会社三菱総合研究所 情報技術研究センター） レッスン２：ソフトウェア開発環境の概要 OSSによる代表的なソフトウェア開発環境について学ぶ 清水 浩行 （株式会社三菱総合研究所 情報技術研究センター） レッスン３：ソフトウェア開発環境の概要 ソフトウェア開発環境について、より詳細にその内容を掘り下げる 清水 浩行 （株式会社三菱総合研究所 情報技術研究センター） レ
リーダブルコード ――より良いコードを書くためのシンプルで実践的なテクニック (Book4873115655 - MemoWiki v5)
読書メモ 書籍情報 リーダブルコード ――より良いコードを書くためのシンプルで実践的なテクニック -Amazon.co.jp： リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice): Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典: 本 --http://www.amazon.co.jp/exec/obidos/ASIN/4873115655/nilabwiki-22/ref=nosim/ --->内容紹介 --->「美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ」(本書「はじめに」より)。 --->コードは理解しやすくなければなら
コーディングのスピードを上げる為の6つの方法
2017年7月25日 Webサイト制作, 便利ツール 今より少しでもコーディングを早くできれば、細かいデザインや機能にも時間をかけて取り組めそう…という事で今回はコーディングのスピードを上げるためにできる事を紹介します。便利なツールを使ったり、ちょっとやり方を変えるだけでより早くコーディングができるようになると思います！ ↑私が10年以上利用している会計ソフト！ 1. コーディング手順を簡略化する これは自分のコーディング能力を高めて手順を省く、便利なツールを使って手間を省くという事です。例えば私は昔このような手順でコーディングを進めていました。 CSSのレイアウトをノートに書き出す レイアウト部分（ヘッダー・メイン・サイド・フッター）のHTMLマークアップ CSSでレイアウト部分のスタイリング 表示確認 うまく表示できない箇所の修正 ヘッダー内のHTMLマークアップ CSSでヘッダー内の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tabs or Spaces
良いコードとは
「いつソースを読むのか」
ターミナルのログにコメントつけるときは「##」をつけるとそれっぽくなる。「#」はスクリプトの中で使われてたりするから。 / Linuxでうっかりrm -rfしちゃったけど復活出来たよー＼(＾o＾)／ - y-kawazの日記 (2013-12-29)
nilab - Qiita
Sign PDF Documents | DocHub
英語コミットコメントに使えるオシャレフレーズ集
