[B! 設計] cubed-lのブックマーク

長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方..

長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方とブラウザでの動作確認を軽く教えた次男も感化されたようで長男の真似をし始め、今は簡易な動作のHTMLファイルであれば作れるようになっているある日、二人の空気が険悪だった(大喧嘩したあとの空気だった) まずは長男に事情を訊いてみると、とあるプログラムの方針で対立したとのことそれは「じゃんけんゲーム」だった画面でグーチョキパーのいずれかを選びボタンを押すと、相手(CPU)の「手」と勝敗が表示されるというものだった次男はまずCPUの「手」を乱数で決定し、画面に入力された「手」と比較して勝敗(と引き分け)を決める、素直な処理だった長男はそれに飽きたのか、まずは乱数で「勝ち」「負け」「引き分け」を乱数で最初に決めてしまい、その後で結果に応じたCPUの「手」を決定するというロジックだった次男はこれが気に入

cubed-l 2020/07/28

それぞれにコードを書かせて比較させると良いんじゃない。確率を学んでいる年齢か否かで教え方は変わると思うが。

リンク

例外設計における大罪 - 契約

unassert - encourage reliable programming by writing assertions in productionTakuto Wada

cubed-l 2012/06/28

リンク

ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場

タイトルは煽り入ってますが。仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、

cubed-l 2009/12/27

CPUのパフォーマンスを活かして仮想化が進んでいるかな

設計

リンク

O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」

昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ

cubed-l 2009/10/13

リンク

Ruby on Railsの「えせMVC」の弊害

先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避

cubed-l 2009/10/13

リンク

はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

はてなグループの終了日を2020年1月31日(金)に決定しました以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記はてなグループ日記のエクスポートデータは2020年2月28