ToKyoto.jsでScala.jsについてLTしてきました。 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
自分の発表について speakerdeck.com もう3日前のことになりますが、ToKyoto.jsでLTしてきました。Scala.jsの話です。スライドにあるし、このブログでも何度か取り上げていますが Scala.js 普通に実用性あります。とはいえ「実用性がある」と「使うべき」の間には高い壁がそびえているわけですが……。 ちょっと補足的な話をしておくと、ReduxやVuexが提供する状態管理パターンのよさはいくつかあって、 Single source of truth が守られる 参照系と更新系が強制的に分離させられる 以上の二点により、プレゼンテーション上でのデータの分割構造とロジック上のデータの分割構造が分離される ヘッダーで使う情報とメインコンテンツで使う情報が互いに関連するみたいなやつが、おなじデータソース見るの簡単とかそういうこと 自分でデータの変更をobserveしなくて
「オブジェクトをイミュータブルにしろ」って言うけど、それってたとえば状態が変わったらオブジェクト作り直すってことでしょ、ちょう非効率じゃん。って思ってたんだけど、 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
オブジェクトの内部の値がイミュータブルであれば、今後もその値は変更されないことが保証されているので、新しい状態を持った新しいオブジェクトの内部の値のうち、変更のない部分(つまり値のうちのほとんど)は古いオブジェクトの値をそのまま参照すればよく、コピーする必要がないということを @takkkun が言っていて(正確には、イミュータブルなリストに新しい値を追加した新しいリストを作るときには、中身をコピーする必要ない。変更されないことが保証されてるから、という話だった)目から鱗が落ちたのでここに記して置こうとおもった。 で終わろうと思ったんだけど、もう少しちゃんと書く。 ミュータブルな世界では同一性の問題がある。 たとえば playerA と playerB の HP がたまたまおなじ 10 であったとしても playerA と playerB の HP 変数が同じ数値オブジェクトを参照していた
エラーハンドリング・クロニクル #nds41 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
