The Art of UNIX Programming ∼UNIXという考え方∼ 1 12年2月22日水曜日 はじめに • Unix的思想は禅問答の様に普遍的な経験則の塊 である。 • コンピュータシステムだけに限らず、あらゆる 事象を��
The Art of UNIX Programming ∼UNIXという考え方∼ 1 12年2月22日水曜日 はじめに • Unix的思想は禅問答の様に普遍的な経験則の塊 である。 • コンピュータシステムだけに限らず、あらゆる 事象をより良くするための助けになる。 • 何の脈絡もない育児とUnixという2つの事柄を 例示してその「普遍性」が伝わったなら… 2 12年2月22日水曜日 まずはUNIXという考え方のおさらいを 3 12年2月22日水曜日 参考図書 と言うか、これを読んで閃きました。 4 12年2月22日水曜日 The Art of UNIX Programming • Eric S.Raymond (著), 長尾 高弘 (翻訳) • 大型本: 560ページ • 出版社: アスキー (2007/6/19) • 言語 日本語 • ISBN-10: 4756149480 • IS
各国プログラマーのステレオタイプ的分類 - himaginary’s diary
タイラー・コーエンが、なぜソフトウエアでは一物一価の法則が成り立たず、米国や日本企業は自国の高いソフトウエア技術者を使い続けるのか――香港やシンガポールや中国ではもっと安価で雇えるにも関わらず――という一読者の疑問をブログエントリ化した。それに対し250を超えるコメントが付いたが、予想される通り、ソフトウエア開発においては単なるコーディングだけではなく、発注元と発注先とのコミュニケーションが重要なウェイトを占めるのだ、という指摘が相次いだ。その中で、各国のプログラマをステレオタイプ的に寸評したコメントが少し面白かったので、以下に訳してみる： Well, while we are being rude let me speak… It’s not the individuals of course, but the culture. And culture is why Americans
例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
デメテルの法則 - Wikipedia
デメテルの法則 (Law of Demeter, LoD) または最小知識の原則 (Principle of Least Knowledge) とは、ソフトウェアの設計、特にオブジェクト指向プログラムの設計におけるガイドラインである。 このガイドラインは1987年の末にかけてノースイースタン大学で作成された。簡潔に言うと「直接の友達とだけ話すこと」と要約できる。基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 「デメテルの法則」という名前は、この法則がアダプティブプログラミングとアスペクト指向プログラミングに関する研究であるデメテルプロジェクトの成果であることに由来する。プロジェクト名は農業の女神であるデーメーテールにあやかっている。 オブジェクト指向における適用[編集] オブジェクト指向
【資料公開】ワンクリックデプロイ勉強会
2011年12月20日に品川の日本マイクロソフト本社をお借りして、ワンクリックデプロイ勉強会を開催しました。 当初内輪でやろうと思っていたのですが多くの方にご参加いただきありがとうございました。 また、もろもろセッティング頂いた@katzchangと日本マイクロソフトの長沢さんありがとうございました。 以下にセッション資料を公開します。 例によって短文での感想を。 セッション開始前にちゃんとRed Bullを飲んでおいたので元気だった最初の会場へのヒアリングで既にワンクリックデプロイをしている人がいるか調査したところいなかった。まぁWebサービス系でやっているところは増えては来ているもののまだ定着フェーズではなさそうな感じユニットテストやJenkinsはかなりの現場で使われている個人的な今日の名言は、「障害発生時に１日でリリースできるなら、普段のリリースも１日にできるはずだ」というやつ。物
31-状態だけでなく「ふるまい」もカプセル化する - やさしいデスマーチ
「プログラマが知るべき97のこと」の31個目のエピソードは、カプセル化とドメインモデルに関する話です。オブジェクト指向プログラミングの特徴といえば、継承・ポリモーフィズム・カプセル化の３点です。何れも効率良くプログラムを構成するための考え方であり、Javaを初めとしたオブジェクト指向言語では言語機能として提供されています。カプセル化を一言で言えば、情報を隠蔽することで外部に公開する範囲を限定し、内部的には修正の影響範囲を限定する効果を、外部的には内部仕様を意識する必要のないシンプルなAPIになる効果をもたらします*1。これはオブジェクト間の境界を定義する手法とも言えます。 このエピソードの初めの方では「クラス」に関するカプセル化について記述されています。クラスとは、状態と振る舞いを細かい単位でカプセル化したものです。そして、陥りがちな問題として「状態のみがカプセル化された」データクラス（レ
36-ハードワークは報われない - やさしいデスマーチ
「プログラマが知るべき97のこと」の36個目のエピソードは、プログラマの働き方に関する話です。プロのプログラマとしてどんな姿勢で仕事に臨むべきかについて書かれています。 神経を集中させる時間、製品を産み出すのに使う時間が醜に30時間を超えるようなら「自分は働き過ぎだ」と考えるべきでしょう。 働かせるのも働くのも大好きな日本人からしたら週30時間という数字は誤植に思えるかもしれません。出勤が週に５日とすれば１日６時間、残業時間が週に30時間というケースすら珍しい話ではないでしょう。そのような時間をかけてもプログラマの仕事は、本来報われるものではありません。 プロのプログラマであれば、集中してプログラミングを行います。人間が集中して作業できる時間はそれほど長くありません。せいぜい４〜６時間も集中して作業をすれば疲労困憊です。ペアプロを実際に行ってみると解るのですが、プログラミングをしている中で
開発者が知っておくべき、6つのUIアーキテクチャ・パターン - ＠IT
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
小野和俊のブログ:罪悪感駆動開発(zaiakukan-driven development; ZDD)
みなさんは罪悪感駆動開発(zaiakukan-driven development; ZDD)という言葉をご存知だろうか。私はつい先ほどまでこの概念を知らなかった。なぜなら先ほど自分で思いついたばかりだからだ。 仕事をしていく中で、やるべきことが山積みなのについネットサーフィンをしてしまい、「うわ、今日仕事全然進んでない、やばい」という罪悪感から、その後の仕事が妙に捗る、という経験をしたことがある人は少なくないだろう。 罪悪感駆動開発は、こうした危機感や罪悪感といった人間が本来持っている感情を引き出すことで、より高い仕事の成果を上げていくことを志向する。 罪悪感を感じるポイントは人によって個人差があるが、一般に仕事中に罪悪感が高まりやすい充填行為として、次のようなプラクティスが広く認知されている。 (a) 昼寝 (b) ネットサーフィン (c) ゲーム (d) タイピングソフトでランキング
良い相続人であるために - 世界線航跡蔵
翔泳社の「君のために選んだ1冊 ソフトウェア開発の名著」という企画に寄稿を依頼されて、以下のような文章を書いた。ブログ等で公開して良いとのことだったのでここに公開したいと思う。 この企画は他の人の分を読むのが楽しみだ。早く本ができあがらないかな。 ちなみに「 きっと何者にもなれないお前たちに告げる 一冊」というタイトルを最初に思いついたけれど、長く読み継がれる本であってほしいという企画の趣旨を鑑みて流行のネタを使うのは避けた。 yuguiがレガシーコードに絶望した人に贈りたい一冊 - 『レガシーコード改善ガイド』 レガシーコード改善ガイド (Object Oriented SELECTION) 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義出版社/メーカー: 翔泳社発売日: 2009/07/14メディア: 大型本購入: 45人 クリ
デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
What's New in SQL2016 CTP2 Release - MSDN Blogs
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
Rubyのendは美の観点から必要だ。END HELLは要リファクタへの警告である。メソッド分離、{ }、Guard、三項、ポリモーフィズムで回避せよ！ - hp12c
ブログを下記に移転しました。デザイン変更により移転先では記事が一層読みやすくなっていますので、よろしければ移動をお願い致します。 Rubyのendは美の観点から必要だ。END HELLは要リファクタへの警告である。メソッド分離、{ }、Guard、三項、ポリモーフィズムで回避せよ！ : melborne.github.com - Rubyのendは構文上の欠点だとされ 一部のRubyistから END HELLと忌み嫌われている その一方でRubyのendを愛し endを綴り続けることで 悟りの境地に達したRubyistもいる Rubyistは一日に何度もendと書くことで、 何事にも終わりがあることを日々確認しているのである by @nalsh*1 そしてこの私はというと 見習うべきRubyistの姿がそこにあるのに defと打つと私のエディタが勝手にendと補完するので 物事の終わりも
Startupで採択すべきプログラミング言語 - 続きはwebで
「どの言語を使うか」という問題は、実は当座の生産性の話だけではなく、会社のカルチャーやその後の採用に大きな影響を与えます。ですがーエンジニアが代表であってもーこの問題を意識している人は意外に少ない、というのが正直な印象です。今回は言語毎の特徴を踏まえつつ、どの言語を採択すべきかを考えたいと思います。※Web系に限定しています。 前置き (競合相手のうち)一番安全なのはOracleの経験者を募集しているところだ。 そういうところを警戒する必要は全く無い。また、JavaやC++プログラマを募集しているところも安全だ。もしPerlやPythonプログラマを 募集していたら、ちょっと気を付けたほうがいい。その企業の、少なくとも技術部門は本物のハッカーがやっている可能性が高いからだ。もし私がLispハッカーの募集広告を目にしていたら、きっとかなり心配していただろう。[1] YCのPaul Graha
「Java 7」とはどんなリリースだったのか、チーフアーキテクトが解説。JavaOne 2011
サンフランシスコで先週、10月4日から開催された「JaveOne 2011」。基調講演で最初の話題として語られたのは、7月に登場したばかりのJavaの最新バージョン「Java 7」についてでした。 Java 7とはどんなリリースなのか、基調講演の模様を紹介します。 「プランB」としてリリースされたJava 7 オラクル Java Platformチーフアーキテクト Mark Reinhold氏。 1年前、Java SE 7をどうすべきか、みなさんに質問をした。そのときには主に5つの大きな新機能候補と、そのほかに細かい新機能候補があった。しかもその時点ですでにJava 6から6年が経過していた。 この新機能候補のうち、いくつかは開発に時間がかかりそうなものがあり、それらをJava SE 7から分離してJava SE 8の新機能とした計画を「プランB」とした。これならJava SE 7が当初よ
安全なバッチ処理の作り方 - KAYAC engineers' blog
このまえ登り坂の途中でロードバイクのタイヤが破裂しました。ながたです。 今回はバッチ処理について書いてみようと思います。 バッチ処理？ Webサービスの処理開始条件は、大まかに次の2つに分けることができます。 ユーザーのアクションに起因するもの ユーザーのアクションに起因しないもの このうち後者の処理をバッチ処理が担当することになります。 バッチ処理の担当分はさらに、 特定の条件（時間やサービスの状態）で実行するもの 手動で実行するもの の2つに分けられます。 今回はこの「手動で実行するもの」について書きたいと思います。 バッチを手動実行するのはどんなとき？ バッチ処理を手動で実行するのは、十中八九イレギュラーな状況が発生したときです。 ルーチンワークや実行の条件が決まっているものは何らかの方法で自動化できるはずです。 そしてイレギュラーな状況のほとんどは不具合が発生したとき。 つまり 重
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
O'Reilly Media - Technology and Business Training
CleanCode第２章読書メモ - kidooom
サービス終了のお知らせ