Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
CodeIQ中の人、millionsmileです。 いろいろ経歴を積むと、「いまさら聞けない」ことが増えてきます。「オブジェクト指向」というのもそんないまさら聞けないものの一つでしょうか。 そんなわけで、いまさら聞けないことをイマサラ問題として出題してみました。 問題は、日本のITエンジニアの父と言いたくなるくらい温かみのあるフィードバックをしてくれることで好評な有限会社システム設計の増田亨さんからの出題です。オブジェクト指向設計について2問出題していただきました。総計65名もの方に挑戦いただきました! 問題の解説記事は、オブジェクト指向設計の3つのコツを中心に説明してくれていますので、読みやすいですし、頭にすっと入ってきます。 ではでは、増田亨さんによる解説記事をお楽しみください。 https://codeiq.jp/ace/toru_masuda/ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
前回Akka Frameworkのチュートリアルをやってみましたが、動作確認のみで内容を読んでなかったので、軽く読解してみました。チュートリアルというより、Akkaのコンセプトがはっきりわかる内容です。 Akka Projectの Tutorial: write a scalable, fault-tolerant, persistent network chat server and client の「Sample application」以降を読んでみます。サンプルの動作確認方法は、前回のエントリで書きました。 正確に翻訳できるほどの英語力はないので、コードやScalaの冗長な説明は省いて、重要と思われる点だけ、だいたいこんなことが書いてあるんじゃないか程度。間違ってたらごめんなさい。 システム間でやりとりするメッセージが不変(immutable)であることはとても重要。 Actor
この記事を読む前に、絶対に理解出来ないモナドチュートリアルに一度目を通してみてほしい。モナドを理解していく上で、とても重要なことが書かれている。 改めて言おう、モナドはモナドだ。コンテナだとかプログラマブルセミコロンだという説明では、モナドのすべてを正確に表せるとは言い難い。では、モナドを過不足なく説明できる、モナド以外の言葉はあるのか? 実は、モナドを表現し、かつモナドで表現される言葉は存在する。その一つは手続きである。手続き型言語の「手続き」だ。 手続きとは何か 手続きは結果を持つ おおよそすべての手続きは何らかの結果を持つ。Haskellの()、C言語のvoid、PythonのNone、Rubyのnilなども結果の一種だ。結果が出ないとしたら、そのプログラムは停止しないか、途中で異常終了するだろう。 手続きには最小単位が存在する 処理系が扱っている以上、手続きが際限なく分解できるとい
この記事の目的は、Applicative 信者による Applicative スタイルの布教です。 簡潔に結論を述べると、 foo = do a <- m1 b <- m2 return (f a b) のようなコードを書きたくなったら foo = f <$> m1 <*> m2 と書きましょうということ。 合い言葉は、「do と return をなくせ!」です。 FunctorとMonadの間 Functor を特殊化した型クラスがMonadで、Monadの方が強力です。なぜなら、メソッドが増えるからです。 Functorのメソッドはfmapです。fmapの別名を (<$>) といいます。(この記事では、(<$>) と liftM を同一視します。) そして、Monadのメソッドは、ご存知の通り (>>=) と return です。 FunctorとMonadの間にApplicative
Scala で圏論入門 https://github.com/scalajp/introduction-to-category-theory-in-scala-jp/wiki に移動しました。こちらは、ミラーとさせていただきます。 これは、Typesafe 社の Director Professional Services である Heiko Seeberger 氏による「Introduction to Category Theory in Scala」の翻訳文です。誤訳、誤記などがありましたら、 日本Scalaユーザーズグループの「圏論入門 レビューのお願い」トピックに投稿していただくか、@quassia88 にご連絡ください。 もし君が僕みたいに、以前はJavaディベロッパーで、Scalaのファンになったばかりなら、君は多分遅かれ早かれ、モナドやら関手やらの、圏論の分野からやってきた謎
全体目次: 第1歩:しりとりの圏 (このエントリー) 第2歩:行列の圏 第3歩:極端な圏達 第4歩:部分圏 第5歩:変換キューの圏 第6歩:有限変換キューと半圏 第7歩:アミダの圏 第8歩:順序集合の埋め込み表現 第9歩:基本に戻って、圏論感覚を養うハナシとか 付録/番外など: 中間付録A:絵を描いてみた 番外:同期/非同期の結合 中間付録B:アミダとブレイド 番外:米田の補題に向けてのオシャベリ 一部のプログラミング言語の背景として、圏論(カテゴリー論)が使われたりするせいか、以前に比べれば多少は圏論に興味を持つ人が増えたような気がしなくもないような。でも、安直な入門的文書はあまり見かけないですね。もちろん、シッカリした教科書や論説はあるんですが、どうもシッカリし過ぎているような。例えば、圏の例として「コンパクト・ハウスドルフ空間と連続写像の圏」とか言われてもねぇ(この例はいい例なんです
オブジェクト指向とは何か2002-10-03「オブジェクト指向とは何か」この根源的な問いの答えはなかなか難しいものです。ここではその難しく哲学的な問題に真っ向から挑んでみたいと思います。 「オブジェクト指向」という言葉は世の中に広く出回っていますが、「オブジェ クト指向って何?」という質問に的確な答えが返ってくる事は多くはありませ ん。「オブジェクトとは『もの』のことだよ」と言われても、正直言ってさっ ぱりわかりません。そしてそれ以上の事を聞くと「例えばJavaではねぇ……」 と特定のプログラム言語の話になってしまいます。 ここでは、「オブジェクト指向だとどんなメリットがあるか」でも「オブジェ クト指向言語の文法」でもなく、そのものずばり「オブジェクト指向とは何か」 について考えてみたいと思います。 目次オブジェクトとは何かオブジェクト指向とは自律とはオブジェクト指向の通説オブジェクトの意
1801 – ジョセフ・マリー・ジャカールがパンチカードを使った織機によってタペストリーに"hello, world"と織り出す。しかしラッダイト (当時のRedditer) たちは、テールリカージョン、並行処理、大文字小文字の区別を欠いていたため、さほど感心しなかった。 1842 – エイダ・ラブレスが最初のプログラムを書く。彼女の努力は、プログラムを実行するコンピュータが実のところ存在しないというマイナーな問題のために頓挫した。後にエンタープライズアーキテクトたちはプログラムをUMLで書くために彼女のテクニックを再び学ぶことになる。 1936 – アラン・チューリングが存在しうるあらゆるプログラミング言語を発明するが、特許化する前に英国情報部員(後の007)によって抹殺される。 1936 – アロンゾ・チャーチも存在しうるあらゆる言語を発明しているが、より巧みに行った。チャーチのラムダ
ホーム<ゲームつくろー!<衝突判定編 2D衝突編 その8 4分木空間分割を最適化する!(理屈編) ゲーム空間に置いたオブジェクトを総当りで衝突判定する事ははっきりと非効率だと言えます。ちょっと計算してみましょう。60FPSのゲームの1フリップ約16.6ミリ秒の内衝突判定に10%の時間余裕(1.66ミリ秒)を与えられたとします。もし1000回の衝突判定に1ミリ秒かかるなら(1000回/msec)、判定回数は1660回以下に抑えないと間に合いません。総当りだとこれは58オブジェクトくらいで限界です。判定時間が200回/msecならオブジェクトはたった18個で限界。これはどう考えても節約が無いとゲームになりません。 オブジェクトの全ての位置が決まった時、自分とぶつかる可能性があるのは自分の周りのオブジェクトだけです。遠い所にある物は判定する必要すらありません。そこで「空間をある程度制限してその中
前回 id:fits:20120828 に引き続き、今回も書籍「 すごいHaskellたのしく学ぼう! 」 のサンプルを Scalaz で実装してみる事にします。 今回は、リストモナドを使ったナイト移動 *1 の処理です。 Scalaz 7.0.0-M3 sbt 0.12.0 サンプルソースは http://github.com/fits/try_samples/tree/master/blog/20120912/ 3手先の位置 まずはお手本とする Haskell 版です。(本のサンプルそのままです) Haskell版 move_knight.hs type KnightPos = (Int, Int) -- ナイトの次の移動先を列挙 moveKnight :: KnightPos -> [KnightPos] moveKnight (c, r) = filter onBoard [ (c
超個人的なエントリで恐縮です。 先日完全ハッシュ関数に関して調査していたのですが、 perfect hash function(完全ハッシュ関数)の概要 そこで、GNU gperfというアプリケーションが完全ハッシュ関数の生成器として存在するって話を少ししだけれども、かくいう僕もgperfを使わせていただいておるのですが、実際にどんなアプリケーションやユースケースで使われているのかなあ、と興味を持ったので軽い気持ちで調べてみた。 gperfの本家のマニュアルを調べてみると確かに、それらしいことが書いてある。 gperf currently generates the reserved keyword recognizer for lexical analyzers in several production and research compilers and language proce
Welcome to Apache Commons Apache Commons is an Apache project focused on all aspects of reusable Java components. The Apache Commons project is composed of three parts: The Commons Proper - A repository of reusable Java components. The Commons Sandbox - A workspace for Java component development. The Commons Dormant - A repository of components that are currently inactive. You may also read our ch
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは?」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
あらすじ 人の綺麗なコードを読みまくると自分のコードも綺麗になっていくのに、イケメンを見続けても僕の顔が良くならないのは何故なの?? 2012-11-30 19:41:20 via web 今まであまり人のコードを読む習慣というか機会というかがあまりなかったのですが、最近になって、デスクの上がヨドバシのiMac売り場みたいと(僕の中で)話題沸騰中の@mitukiiiさんのコードを読む事があり、この人がまたすごく綺麗でスタイリッシュなコードを書くわけで、その時に、綺麗なコードというのはこういう感じに書くものなのかと結構な衝撃を受けたわけです。 またこれも最近なのですが、別の機会で、なんと言いますか、1つの関数が数千行あったり、しかもその内の大部分が共通処理として括り出せるような恐らくはコピペされたであろう部分が大量に入っていたりまぁ不可解な部分の多い、言うなればイケメンを見続けた僕みたいな、
原則について優れたオブジェクト指向開発のための指針。ただ、、、原則は原則。必ず守らなければならないのではなく、まずそれで考えることが重要。逸脱したとしても正当な理由やトレードオフが説明できればよい。一覧単一責任の原則(SRP)オープン・クローズドの原則(OCP)リスコフの置換原則(LSP)依存関係逆転の原則(DIP)インターフェイス分離の原則(ISP)参考アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技作者: ロバート・C・マーチン, 瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型本 Principles Of Object Oriented Designオブジェクト指向設計@Syboos.jpオブジェクト指向設計の原則@それはBooksオブジェクト指向設計原則@ディノオープンラボラトリオブジェクト指向の法則
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く