Conceptual Contexture
前回はRDBMSの使用が引き起こすモジュール性の低下について議論したが、その根拠を具体的に示さなかった。その補足ということで今回は小さな例を１つ示したい。 また、関数プログラミングが副作用の多い状況に対して弱みを持つ、と書いたのは乱暴であったのでお詫びして訂正したい。 正しくは、副作用を含むロジックに対しては、注意深く抽象化を行う必要があり、副作用・外部入出力の種類が違えば、そのたびごとに抽象化のモデル・実装について熟慮して抽象化を行う必要があるということである。 これはうまい抽象化が不可能だということではないので、それを弱みと呼んだのは間違った一般化であった。 しかし、ありがちな抽象化の方法では、クエリーの発行がモジュール性の低下を引き起こしかねないということを小さな例を使って示したいと思う。この例は手続き的な擬似コードによるものだが、RDBMSを抽象化するfunctionalなDSLで
Reactive Manifestoではないほうの本当のReactive Programming？ - xuwei-k's blog
タイトルにわざとReactive Manifestoを入れたのは、まずこちらのtogetterご覧ください pokarimさんのReactive Manifestoに関する印象 あと、タイトルの最後に、はてなマーク入れたのは、自分がReactive Programmingに詳しくなく、色々自信ないからです。 間違いあったらツッコミください さて、Reactive Programmingとはそもそもなんなのか？厳密に定義できるのか？は、詳細に議論できるほどの知識を持ち合わせていないので逃げます(おい まずは、話のとっかかりとして、上記のtogetterの主役となってるpokarimさんの過去の記事(4年近く前！) を結構長めに引用してみます。(はてぶが600以上ついてる・・・) なぜリアクティブプログラミングは重要か。 まず次のような定義を行います。 a = 1 b = a * 3 そしてa
技術的負債 - Qiita
この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。 たとえば、省略可能なプロセスを飛ばす事で開発の高速化を行う事があり、初期開発を高速に行う開発者の中には意識的・無意識的問わずこれを行っている事例が多々存在する。このようにして抱えられた技術的負債は長期的に見た場合に問題を引き起こ
GOTO Aarhus 2014 Conference
Thanks for making GOTO Aarhus 2014 a success! GOTO Aarhus 2014 was the last GOTO Conference held i Aarhus. In 2015 we will combine GOTO Aarhus and GOTO Copenhagen into one awesome conference: GOTO Copenhagen 2015, October 5-8, 2015. Hope to see you next year! Who do you want to see at GOTO Denmark in 2015? Please submit your speaker and topic proposal for GOTO Denmark 2015 via this online form. Th
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://extempore.moso.com.au/extras/cmj-2013.pdf
https://www.twitterflight.com/
