OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
オブジェクト指向宗教史
OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT docomo Business Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
Javaなら「この書き方がベスト」と信じて書ける - きしだなおきに聞く、Javaのこれまでとこれから｜ハイクラス転職・求人情報サイト AMBI（アンビ）
ハイクラス求人TOPIT記事一覧Javaなら「この書き方がベスト」と信じて書ける - きしだなおきに聞く、Javaのこれまでとこれから Javaなら「この書き方がベスト」と信じて書ける - きしだなおきに聞く、Javaのこれまでとこれから Javaは1995年に誕生し、数多くのコミュニティや企業の影響を色濃く受けてきました。では、黎明期から現代に至るまで、Javaはどのように進化し、生態系を変化させてきたのでしょうか。Javaのスペシャリストとして知られる、きしだなおきさんに聞きました。 1995年に誕生した、オブジェクト指向プログラミング言語・Java。この言語の歴史は、数多くのコミュニティや企業の影響を色濃く受けてきました。 例えば、OracleによるSun Microsystemsの買収後、Javaのリリースサイクルは大きく変化しました。また日本においては、JavaカンファレンスやS
Rubyはどのように生まれ、世界へ羽ばたいていったのか？まつもとゆきひろさん講演会の全貌をレポート – NET BIZ DIV. TECH BLOG
どうですか？ Rubyって新参者のイメージがあると思うんですけど、実はJavaと同じぐらい古いんですよ。 ちなみに、World Wide Webの原型になるものが作られたのは1990年だったそうです。Rubyを作りはじめた当時の1993年の時点では、World Wide Web自体は存在はしていたのですが、世間一般にはほとんど認知されていませんでした。つまり、冒頭でも申し上げたとおり、Rubyはweb用に開発されたわけではなかったのです。 当時すでに先輩としてPerlという言語があったのですが、その代わりになるような言語を作りたかった。でも単にまったく同じものを作ってもしょうがない。その頃の私はオブジェクト指向に傾倒していたので、こう考えました。 「オブジェクト指向に基づいて言語をデザインすることで、既存のものよりも良い言語が作れるんじゃないか」 ―― それがRubyの始まりです。 国際色
null安全を誤解している人達へのメッセージ - Qiita
null安全を誤解している人達へのメッセージ 先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃ
フリーエンジニアのIT案件ならレバテックフリーランス
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
Rebuild: 158: Kill All The Threads (ko1, Matz)
Koichi Sasada さん、まつもとゆきひろさんをゲストに迎えて、Guild, Ruby 3 などについて話しました。(9/10 RubyKaigi 2016 にて収録) Show Notes RubyKaigi 2016 A proposal of new concurrency model for Ruby 3 Koichi Sasada: A proposal of new concurrency model for Ruby 3 (RubyKaigi2016) Global interpreter lock Ruby creator floats new concurrency model ギルド verse | RubyGems.org Rust: Ownership and Lifetimes Erlang -- Processes Racket: Places Soft
Python と Ruby と typing - methaneのブログ
うーん、structural subtypingとダックタイピングは同じものなんだろうか。— Yukihiro Matsumoto (@yukihiro_matz) 2016年9月8日 https://t.co/5Rv86piThC wikipediaによると似て非なる物のようですね。 https://t.co/VwIg39h5M0— INADA Naoki (@methane) 2016年9月8日 この話題について補足しておきます。なお、僕はTAPL脱落組なのであまり正確性は期待しないでください。 背景 Ruby Kaigi で Matz が Ruby3 に向けて考え中の静的型について話されたようです。 少し前から、 Python でも Guido が Dropbox での大量のコードベースを改善していくために type hinting がほしいということで PEP 484 を始めました
例外、エラー、異常、そして - Qiita
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
エラーハンドリング・クロニクル #nds41 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を
Martin Fowler's Bliki in Japanese - オブジェクト指向を学ぶにはどの言語がよい？
http://martinfowler.com/bliki/LanguageForLearningObjects.html オブジェクト指向を教えるとき、どの言語がよいか？ ここ数年、オブジェクト指向を覚えるときには、Javaが使われてきました。Javaを使うのには、いくつかの理由があります。 広く知られている C を基本とした文法（一般的なスタイルとなりつつあります） フリーで高性能な開発環境が利用可能である Javaの知識があれば仕事に就ける こういった理由から、私はJavaの使用をやめさせようとはしませんでした（C#にもこういった特徴があり、いずれC#が代わりになるだろうと指摘してはいたんですが）。ただ、Javaだけに任せようとは思っていません。Java、C#、C++はいずれも、オブジェクト指向プログラミングのある形を提示してくれていますが、誰かにオブジェクト指向を紹介するならば、選
一つのメソッドに上から下にずらっと全部書いてしまう現象の考察 - basyura's blog
とある機能を実装するとする。例えば外から Excecute が呼ばれてその結果を返すような場合。多いのが Execute メソッドの中に全部書いてしまって、何 10 行を超えて何回スクロールするんだろうになっているパターン。その際はレビューで以下のようにアドバイスする。 Execute にはシナリオを書いて、中身は別に書くと良いですと。僕の経験的にこの方が良かった、という深い根拠のないものではある。けど、間違った考えとも思わない。自然だろうと。private なメソッドではインスタンス変数を直接扱うのはやめて、public なめそっどから引数で渡したほうがいいとか細かいところもあるけど、そのへんはすっ飛ばしてまずは上記のようにいう。 そんな考えを持っているので、レビュー依頼されたものやコミット済みの資源をなにかの機会で見たときに、上記に反するものを見かけると気になってしまう。 もうちょっと
Pythonのwith文とJava7のtry-with-resourceとC#のusingの比較 - 西尾泰和のはてなダイアリー
http://nhiro.org/learn_language/with_statement.html Java7は名前の通りtryと抱き合わせになっている。C#とPythonは分離されている。なのでJava7でC#やPythonと同じ挙動をしたければ必要なくても空のfinallyを書くことになる。(追記: finallyやexceptを伴わないtryもOKでした。thanks id:nowokay) 本体が正常終了または例外を投げて異常終了した場合のどちらでも呼ばれる「後片付けメソッド」はC#だとDispose、Java7だとclose、 Pythonだと__exit__。しかしPython以外は引数を取らない。本体が正常に終了したのかどうかはどうやって知るんだろうか。知る必要はないという判断なんだろうか。追記: Pythonがどんな引数を取るのか他の言語の人には想像がつきにくいらしいの
言語女子会2: varは必要？/privateがない？ - 西尾泰和のはてなダイアリー
言語女子会: undefとnullは両方必要？の続編です。 varは必要なの？ とあるプログラミング言語が集う女子会にて: Python: JavaScriptちゃんってさ、なんでvarだらけなの？ JavaScript: えっ、変？ Python: varなんかいらなくない？私ぜんぜん持ってないよ？ JavaScript: えー、じゃあ変数をどうやって宣言するの？ Python: 宣言っていうか…「x = 1」みたいな代入文があれば変数xが必要なのって自明じゃない？宣言とか必要？ Ruby: 必要ないよね。っていうか変数宣言とか古臭くない？ JavaScript: そうかなー。 Python: 少しダサイかも。ほら断舎離ブームだし要らないものは捨てなきゃ！ JavaScript: 要らないかなぁ、変数宣言。Pythonちゃんは関数がネストしているときに外側のスコープの変数に代入するのって
JavaやC#の常識が通用しないRubyのprivateメソッド - give IT a try
衝撃を受けたできごと 最近Rubyを勉強しています。 JavaやC#でオブジェクト指向プログラミングの基本はマスターしてるから、Rubyもそのあたりは楽勝〜！・・・と思っていたら、JavaやC#の常識が全く通用しない振る舞いに遭遇してかなり衝撃を受けました。それは、 privateメソッドはサブクラスからも呼び出せる ・・・ということです！！がーん。 たとえば、JavaやC#だと自分のクラス内でprivateメソッドが使われていない場合、不要なメソッドとして削除できます。(リフレクションを使って呼び出される可能性はここでは無視ね) しかし、Rubyでは誰かがサブクラスを作って呼び出している可能性があるので、privateメソッドを削除する場合は注意が必要です。メソッド名を変更する場合も同様ですね。 また、知らずに親クラスと同名のprivateメソッドを定義すると、予期せず親クラスの実装をオ
PHPのinterfaceなめんな - なんたらノート第三期ベータ
はいタイトルは釣りです。 OOPのインターフェースはただの実装漏れチェック機能じゃないし、ましてや継承は差分プログラミングツールじゃないぞ。というのはわりと一般的な話だけど、Ruby(respond_to?でホントにいいの)とJava(インターフェースが自然すぎてユーザが意識しないのよ)が、PHPに対してOOPどうこうで偉そうに言うのはどうかなと思ったもので。まあそれと同時に、PHPの人自身がその意義を発見してるのかなという疑問もあったりしたんですけどね。 Rubyというのは「オブジェクト指向ってのはつまりメソッドに応答できるアヒルはみんなアヒルとみなせるよね」というレベルのダックタイピングで割り切った言語だと、個人的に認識しています。継承とミックスインにはis_aが応答するけど本質はrespond_to?のほうで、インターフェースを宣言してなくてもメッセージ送れたらいいあの感じ。 そんな
オープンクラスとはダイナミックスコープだという話。 - 言語ゲーム
http://blog.livedoor.jp/dankogai/archives/51507869.html を読んで、これは書かなきゃ！と思ったので、まだ考え途中だけどメモします。私のネームスペース理論で言うと、オープンクラスとはダイナミックスコープなのです。 まずオープンクラスとは何かざっと復習。Java 等の静的なオブジェクト指向言語では、クラスを定義する時に全部のメソッドを書く必要があるけど、Smalltalk や Ruby のクラスでは、あとからメソッドを追加したり書き換える事が出来ます。こういうのをオープンクラスと言います。オープンクラスの凄い所は、メソッドを変更する前にもともとあったプログラムの振る舞いまで変わってしまうと言う事です!これは柔軟であると同時に大変危険な諸刃の剣です。 次にダイナミックスコープとは何かをざっと復習。変数が使われている場所ではなく、処理の流れを元
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
良いコードとは
GitHub - cookpad/styleguide: Cookpad's coding style guides
