日本語だとググっても出てこなかったのでまとめた
| 操作 | 計算量 |
|---|---|
| 添字アクセス | O(1) |
| 挿入(splice) | O(n) |
| 削除(splice) | O(n) |
| 削除(delete) | O(1) |
| 最後に追加 | O(1) |
| 先頭に追加 | O(n) |
| スワップ | O(1) |
添字アクセスがO(1)だったりするのは、JavaScriptの配列は連結リストなどではなく単なるインデクスをキーで持つObjectだから。
ちなみにdeleteを使った削除というのはspliceと違って要素がundefinedと交換されるだけのものなので後続要素への走査が走らないためO(1)になる。
参考: https://stackoverflow.com/questions/11514308/big-o-of-javascript-arrays
| 強整合性 | 結果整合性 | |
|---|---|---|
| データのロック | あり | なし |
| スケーラビリティ | 低い | 高い |
| 一貫性 | 担保される | すぐには担保されない |
結果整合性は必ずしも高度な分散システム固有の難解な技術ではなく、多くのモダンなRDBMSは同期・非同期レプリケーションのシステムが組み込まれている。同期的レプリケーションの場合にはレプリケーションの更新はトランザクションの一部として行われるが、非同期的レプリケーションでトランザクションログの伝播の前にプライマリーでのデータ更新が失敗すると、ノード間で一貫性のないデータが生まれることになる。つまり非同期レプリケーションはRDBMSにおける古典的な結果整合性のケースのひとつである。
データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理
ScalaでDDDなコードのアプリケーションを作ろうとしているときに UserId など値型はどうするべきか の記事を読み、「専用の値クラスを作る」のパターンでふと 「ここでケースクラスが AnyVal を継承する理由ってなんだ...？」 と思ったので調べた。
case class PersonId(value: Long) extends AnyVal case class PersonName(value: String) extends AnyVal case class OrganizationId(value: Long) extends AnyVal case class Person(id: PersonId, name: PersonName, organizationId: OrganizationId) // ...
AnyValを継承すると値オブジェクトになる。値オブジェクトを継承したクラスはひとつの値しかとれない。
// OK class Melo(val a: Int) extends AnyVal // NG class Melo(val a: Int, val n: String) extends AnyVal
AnyVal を使うことによって 実行時のオブジェクト割り当てを回避することができる ようになる。具体的には上の例でいうと Melo クラスはコンパイル時は Melo クラスだが、実行時は Int として解釈される（アンボクシング）
だが、パターンマッチングなどで型検査が必要になると、 Int としてアンボクシングされた値が再び Melo としてボクシングされることになるため、パフォーマンスに影響を与える。
雑に言うと AnyValを継承したクラスを使うとパフォーマンスが向上する っぽい。
個人的にはDDDにおける値オブジェクトをコードで表現するにあたって、もし 引数がひとつしかない のであれば、どんなケースでも AnyVal を継承しない理由がないように思える... というか、調べていて値クラスという名前がたまたまDDDっぽいだけであって、これならべつにエンティティの実装だって可能なら AnyVal 継承クラスでえんちゃうの、と思ってしまった。
ただ、例えばバリデーションロジックで 「〜文字以下かどうかをチェックする」 みたいなビジネスルールがあったとき、クラスの中に MAXIMUM_LENGTH みたいな定数を宣言するのは普通だが AnyVal を継承しているクラスの中で val による宣言ができないという制約がある。
コレに関しては、以下のようなメソッドを定義してしまえばいいのでは、という同期からのアイデアをもらったが、果たしてアリなのか...?
class Text(value: String) extends AnyVal { def MAXIMUM_LENGTH = 100 }
自分がOOPをそれっぽく学んだのは、サンディ・メッツの「オブジェクト指向設計実践ガイド」だが、この本だとダック・タイピングはバキバキにでてくる一方であまりポリモーフィズムについては詳しく書かれていない。thoughtbotのブログの記事、Rubyとポリモーフィズムによると、Rubyにおけるポリモーフィズムは「継承」と「ダック・タイピング」によって実装できるらしい。
オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
まずは継承のパターン。GenericParserというクラスを継承したis-a関係のJsonParserとXmlParserを定義し、parseメソッドをオーバーライドしている。
class GenericParser def parse raise NotImplementedError, 'Implementation required.' end end class JsonParser < GenericParser def parse # Jsonをパースする実装 end end class XmlParser < GenericParse def parse # XMLをパースする実装 end end parser = XmlParser.new parser.parse parser = JsonParser.new parser.parse
つぎにダック・タイピング。ダック・タイピングでは、各パーサ実装はなんのクラスも継承せず、とにかくparseというメソッドを持っているということだけが共通している。
class XmlParser def parse # Jsonをパースする実装 end end class JsonParser def parse # XMLをパースする実装 end end class GenericParser def parse(parser) parser.parse end end parser = GenericParser.new parser.parse(XmlParser.new) parser.parse(JsonParser.new)
XmlParser なのか JsonParser なのかが意識されてparseメソッドが呼び出されている。parseメソッドを呼び出すGenericParserは、そのメソッドを持つparserが何かを意識していない。ということが分かる。
継承によるコードは、それぞれのパーサが「誰なのか」（＝なにを継承しているか）が分かることによって、パーサに何ができるか（どんなインターフェースを持っているか）を判断できる。一方で、ダック・タイピングとはすなわち「誰か」ではなく「何をするか」によってオブジェクトを見分けるため、パーサがparseメソッドを呼び出せるということを期待するだけでインターフェースは意識しない。
「なるほど、ということはダック・タイピングはポリモーフィズムのサブセットなのだろうか？」 という疑問が湧いてくる。
これまで自分は、ポリモーフィズムとはis-a関係にある継承クラスが抽象クラスと共通したインターフェースで個々の振る舞いを特化したものに変えること、というような理解をしていた。なので、必ずしも共通したインターフェースが保証される関係ではないダック・タイピングはポリモーフィズムに該当しないと考えていたわけだ。だがWikipediaのポリモーフィズムのページによると、ダック・タイピングは動的ポリモーフィズム（英: Runtime Polymorphism）というものに該当するようだ。この意味では、ダック・タイピングは継承に並んでポリモーフィズムを実現するための手段であると言っても良いのではないかと思う。
とはいえ、Googleでポリモーフィズムとダック・タイピングについて調べるとStackoverflowの質問がそこそこヒットするが、回答者によってポリモーフィズムとダック・タイピングの関係をどう捉えるかというのは割れているように見える。ある人は 「ダック・タイピングはポリモーフィズムするための方法の一つで間違いないよ」 と言ったり、またある人は 「ポリモーフィズムはインターフェースによる明示性(explicitness)を必要をするものだからダック・タイピングは違う」 と言ったりしている。やはり、これに関してはもう少しOOPの原典的なものにあたったほうがいいのかもしれない。
/etc/hosts もDNSと同じ役割を持っている。
たとえばPCのブラウザで hogehoge.net へリクエストを送るまでの例
hogehoge.net を開く。/etc/hosts に該当するIPアドレスとの組み合わせがあればそれで解決hogehoge.net をDNSルートサーバに問い合わせる。hogehoge.net を問い合わせるhogehoge.net のドメインを解決し、IPアドレスである 123.45.6.78 を家庭用ルーターへ伝える。123.45.6.78 を伝える123.45.6.78 へリクエストを送ってデータを取得したりする。コネクションプーリングとかワーカスレッドの多重化とかやってないめっちゃ簡易版。
import std.stdio; import std.socket; import core.thread; void main() { Socket server = new TcpSocket(); server.setOption(SocketOptionLevel.SOCKET, SocketOption.REUSEADDR, true); server.bind(new InternetAddress(8080)); server.listen(1); char[1024] buffer; enum header = "HTTP/1.0 200 OK\nContent-Type: text/html; charset=utf-8\n\n"; string response = header ~ "Hello World!\n"; while(true) { Socket client = server.accept(); client.receive(buffer); writeln(cast(string)buffer); client.send(response); client.shutdown(SocketShutdown.BOTH); client.close(); } }
たとえばSPAにおいて 「あるカテゴリに紐づく記事一覧を取得する」 という実装があるとする
このような処理を実装するにあたっては、各レイヤによって知ってよいことと、知っててはいけないものが変わってくる。
例えばバックエンドが、RDBMSのようなIDによってデータを区別するようなミドルウェアを使っているのであれば、むろんAPIの呼び出しなどを行うデータアクセス・レイヤへアプリケーションが保持しているエンティティのIDがなんらかの方法で渡ることになるが、以下のように明示的にデータ構造がIDという属性を持っているということを期待している（＝知っている）ようなコードを書くのは良くないと思っている。
const articles = fetchArticlesByCategoryId(category.id)
const articles = fetchArticlesByCategory(category)
この改善によって、fetchArticlesByCategory はもう category のデータ構造を知る必要がなくなった。これは、 category のデータ構造の変更が発生したとしても fetchArticlesByCategory を使うレイヤは影響を受けない（＝変更に強い）ことを意味する。
fetchArticlesByCategory はその名前から分かるようにリポジトリ・レイヤの責務なので、リポジトリが category などの依存するドメイン・モデルのデータ構造を処理の中で知識として持っていることは問題ない。バックエンドの仕様が変わってIDの代わりにカテゴリ名でフィルタするようになりました！ みたいになっても、リポジトリ・レイヤだけ弄ればよいので、ドメイン・レイヤは変更から守られる。
もっと言うと、ドメイン・レイヤの中に id みたいなインフラ・レイヤを感じさせるような言葉が出てくるのがすでに危険信号のように見える。それとも id がインフラ・レイヤを感じさせる、というのは自分がRDBMSのことを考え過ぎなのだろうか...
ちなみにこの記事は書いててデメテルの法則だな〜と思った。
振り返ります
丁度大学の後期の期末試験を受けていた。2016年夏頃（後期）から大学に復帰したので、そのテストを消化してた。都市社会学のレポートを書くのに清澄白河をウロウロして写真を撮った記憶がある。ジェントリフィケーションについて書いた。それから、まだこの頃は教職課程のガイダンスなどがいくつかあって、このあとすべての努力が無駄になるとは知らずに頑張っていた。
初めて渋谷WOMBへ行って、Zomboyを生で見た。Zomboyもスゴかったが、ぎゅうぎゅう詰めすぎてびっくりした。 www.womb.co.jp
内定先の開発合宿に参加した。どこに行ったかは忘れたけど、すごく天気がよくて山のたくさんあるところに行った。
一年休学していた僕より一足先に大学の同期達が卒業していくので、サークルの卒業旅行でグアムへ行った。なんてことはなかったが、海で日焼け止めをちゃんと塗ってなかったせいで、全身大やけどを負い、赤く腫れて水ぶくれたような症状に僕を含めて男子三人がなった。死ぬかと思った。夜寝てても、歩いてても、何をしててもヒリヒリ痛い。飛行機はガタガタゆれるし椅子に背もたれがあるしで、痛くて痛くてしょうがない。帰国してから速攻で近くの皮膚科にいくと、コワモテのオネエの先生が優しく診て塗り薬を出してくれた。それからは少しづつ完治していったが、もう南国はこりごりだという気分になった。それでもグアムは基本的に気温も天気も最高で、場所としては申し分ない。でももうビーチで裸にはなりたくない。
この辺から内定先でAPJというものが始まる。これは技術職の内定者と総合職の内定者がチームを組んで、ひとつのAndroidアプリを作るというもの。基本的にコードを書かない側の人間であっても、技術に少しでも触れる経験をするというコンセプトらしい。僕らは、位置情報を利用したSNSのようなものを作ることにした。
Junction Asiaに参加した。会場は寺田倉庫だった。僕らは4人1組のチームで参加して、顔認証から悪質な訪問販売などをブラックリスト化するインターフォンのようなものを開発したが、惜しくも賞は取れなかった。久しぶりに1泊2日のハッカソンに参加したが、2日目の朝のあのしんどい感じはいつ経験しても慣れない。
1年生のころから少しづつ教職課程の単位を取りづつけていたが、取得単位の関係でこの年の5月ないし6月に予定されていた教育実習にいかせることはできないという通告を教職課程事務局から受ける。というのも、僕が1年間の休学をしていたことによって、卒業に必要な単位と教育実習へ行くのに必要な単位の講義が2017年度の授業予定で重複してしまったからだ。教職課程事務局はすでに僕がとっている単位から、必要科目として認定単位の振替をできるかもしれないとかなんとか言っていたが、それに関してはなんの処置も行われなかった。最終的には、教職課程を辞退する紙にサインをさせられ、それまでに取ってきた教職課程の単位をすべてフイにすることになった。武蔵大学には、休学をしようが留学をしようがまともに4年間で卒業ができるようなキャリアパスをしっかり用意してもらいたいと思う。
卒論のことを考え始める。
3月から始まったAPJの遠隔ミーティングを頻繁にし始める。
高校の頃に軽音楽部にいた後輩が意識の高い学生になっていて、ミクシィでインターンをしているというので渋谷で食事をした。話を聞いてみると、軽音楽部に所属していたまた別の後輩が、スタートアップ界隈で活動をしていて、それにいろいろと影響を受けたらしい。人間どこでどう変わるかわからないものだなと思う。
この頃からなぜか急に思い立ってStackoverflowでスコアを伸ばそうとし始める。5月の時点で303ポイントまで上げた。
内定バイトを始める。ReactNative+TypeScriptを本格的に触り始める。
卒業論文の題目を決める時期なのだが、こんなタイミングでテーマが決まるはずがなく、適当なテーマで提出する。アメリカのスタートアップカルチャーについて書きたいなと思っていたが、先行研究がなさ過ぎて頓挫する。
2015年夏のインターンの知り合いが東京の大学院に来たということで遊びに行ったが、そのタイミングで新たなプロジェクトがスタートする。
内定先の会社が上場する。東京証券取引所に行って鐘を鳴らす場面を生で見た。
軽井沢に旅行に行った
3月から本格的に始まっていたAPJが終わる。位置情報を利用したSNS的なもの、という感じでそれっぽいものを作ったが、あまりいい評価は得られなかった。我々の他には、社内の技術本を貸し借りするためのアプリや、成分表の写真を撮るだけでハラルフードを見分けられるアプリなど、いろいろなものがでてきてとても良さがあった。
家族で箱根に旅行に行った。小田急箱根ハイランドホテルといういい感じのところだった。コースのディナーを食べたり、ピーター・ティールのZERO TO ONEを読み終えたりした。 www.hakone-highlandhotel.jp
IndiegogoでGPD Pocketを買った。結局大学で卒論を書くのに大活躍してくれた。 izumisy-tech.hatenablog.com
Meguro.rbでROM.rbについてLT発表をした。初めてで緊張したけど、とてもエキサイティングでいい経験になった。
ダンケルクを見た。戦争色が上手く再現されすぎていて本当に戦争イヤだなと思った。死にたくない。ダンケルクに始まった話ではないが、20歳を過ぎたあたりから戦争映画を見ると涙が出てしまうことが多くなった。 wwws.warnerbros.co.jp
右下の親知らずを抜いた。1時間超のドリル採掘作業はほんとにつらかった。抜歯後の痛みはどちらかといえば中が痛むとかそういうのではなく、縫合の糸で歯茎が引っ張られて痛いというのが大部分で、それだけで食事のモチベーションを無くした。ウィダーインゼリーを大量購入していたが、ゼリーを吸う動きも口の中の筋肉を使うからか奥歯の部分の歯茎が疼いてキツかった。
9月末のMeguro.rbを筆頭に、思い立って4回のLT発表をした。 izumisy-tech.hatenablog.com
楽天テクノロジーカンファレンスというデカイLT大会もあったが、ネタが出てこず参加しなかったのは後悔している。
Jelly Proという小さいスマホを買った。LINE MOBILEで運用している。 izumisy-tech.hatenablog.com
10月末頃から急にまたStackoverflowの意欲が再燃し、323だったのを551くらいまで上げる。
卒論の提出が12月に控えているというのもあり、6月からやっていた内定バイトを年末までストップすることにする。教授も自分も焦りがでてくる。このあたりから毎日卒論のことが頭の片隅にあってすごくフラストレーションが溜まってくる。
最後の卒論題目提出期間（うちの大学は2度に渡ってテーマを決めるタイミングがある）だったが、結局大したアイデアも出ず、行き当たりばったりなテーマで提出する。
気分で髪を明るくし始めた。
なぜか卒論で忙しかったのにStackoverflowで人助けに精をだしてしまう。そのおかげかスコアは順調に551から771まで伸びる。
卒論の提出をした。結局最後の最後はギリギリまで教授にヘルプをしてもらいながらそれっぽいものが完成したので安心した。
卒論提出の直後に今度は左下の親知らずを抜いた。今度は歯茎が引っ張られていたいとかそういうものはなかったが、今度は歯茎の腫れがずっと収まらず、これをかいているいまも奥にしこりがあるような感じがして違和感がある。右の奥歯はほとんど全快したが、歯茎が完成していないせいで食べ物が挟まったりして困っている。早く治らんかな。
Slip.itというソーシャル機能の一切ないブックマーキングアプリを作ったので、公開した。 slipit.me
なんかまとまりのない一年でしたね。
グアム行ったのが今年だということを完全に忘れてました。来年もスノボ行きたい。
