詳しすぎる詳細設計書 - SiroKuro Page
「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力： 「性別と身長のペア」のリスト 出力： 男性の平均身長」と「女性の平均身長」の差 処理概要： 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を１つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を１増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を１増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい
2010年版インスタンス生成考 - プログラマーの脳みそ
2010年現在のアクセスレベルの限界 - プログラマーの脳みそではpublic, protected, private, パッケージプライベートという４つのアクセスレベルではうまく行かない事例という視点だったけど、例に挙げたDIコンテナ云々というのはアクセスレベルの不備というよりも、コンストラクタの不備と捉えるべきだ。 コンストラクタを使わないインスタンス取得 Javaの場合、インスタンス生成はコンストラクタによって行われる。そのクラスの外部から、インスタンスを得ようとする場合の一番基本的なインスタンス取得方法は、new によってインスタンスを新たに生成する方法。 しかし、たとえばGoFデザインパターンのSingletonであるとか、あるいはFlyweightであるとか、返すインスタンスが常にnewされるわけではなく、既存のインスタンスを使い回して返すような作りに使用とした場合、コンストラ
IT業界の00年代を振り返る - プログラマーの脳みそ
00年代のIT業界というと、2000年問題に始まった。西暦を数字2桁で管理していたがために桁あふれするだなんて、今になって思えばなんとメモリをケチッていた時代だろうと思うところだが、当時のマシンスペックを思えば仕方無くもある。 2000年初頭のマシンスペック 2000年2月17日に発売されたWindows2000の要求スペックは、Pentium 133MHz以上、メモリ 32MB以上、ハードディスク 850 MB以上の空き容量であった。 1996年にリリースされたJavaは2000年5月8日をもってJ2SE 1.3がリリースされ、かなりこなれてきていたし、Java VMのパフォーマンスもほどほどだった。当時の19200kbpsほどのモデムではJavaAppletのダウンロードには時間がかかったし、当時のJREの起動の遅さもあってJavaといえば遅い、というステレオタイプが根づいていたが、ビ
正規表現を超える - あどけない話
まずは、Audrey さんが言った Haskell の殺し文句を思い出して頂きたい。 正規表現ベースのパーサはメンテナンスしにくいのに気づいた？ Parsec を使って 15分で Perl6 の完全なパーサを書く方法を勉強しましょう。 15分というのは誇張が入っていると思うが、正規表現が保守しにくく、Haskell の Parsec は強力で保守し易いのは事実だ。その理由を Perl と Haskell のコードを示しながら説明してみたいと思う。 Perl を愛する方に：この記事は Perl を攻撃するために書いたのではない。Perl を選んだのは、正規表現を広めた言語であり、僕がそれなりに Perl のコードを書けるためである。この記事の目的は、正規表現よりも関数型パーサー(Parsec)の方が優れていると示すことだ。 例題 この記事では例題として、IPv4 アドレスを解析する関数を書く
Webアプリで動的型付言語や開発管理が流行りIDEが流行らなかった理由などなど - きしだのHatena
考えてみた。 ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。 この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。 Webアプリケーションの構造 で、まずはWebアプリケーションの構造。 字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。 赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。 Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。 ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。 このとき、サーバー側のプログラム
SICP（計算機プログラムの構造と解釈）を読み終えて : Serendip – Webデザイン・プログラミング
最後のC言語での実装の2問が残っているけれども、一旦これで終了とする。 2008年の11月に開始したので約1年と1ヶ月ちょっとかかったことになる。 SICP を読む過程で得たもの 1章で scheme での基本的なプログラミングに慣れて、カッコの存在を忘れることが出来た。 弟子が尋ねた。「先生、私は先生がカッコをまるで魔術師のように扱っているのを常々敬服しています。どうすれば先生のようになれるのでしょうか?」 師「えっ?カッコ?あ、そうか。そんなものもあったな。いやあ、すっかり忘れておったわ」 このあたりでは、まだ再帰に慣れていなくて、末尾再帰の意味もよく解ってなかった。 また、高階手続きを普通に使えるようになった。 2章で抽象化の有用性やその導入方法を理解できた。 1章2章は数学的な知識が必要な部分も多く、その部分で苦労した。 2章のデータ抽象や3章の環境モデルでオブジェクト指向の舞台裏
なぜ関数プログラミングは重要か
John Hughes, Institutionen för Datavetenskap, Chalmers Tekniska Högskola, 41296 Göteborg, SWEDEN. rjmh@cs.chalmers.se この日本語訳は原著者の承諾を得て山下がここに公開するものです。 この訳文についての、御指摘などは山下伸夫(nobsun .at. sampou.org)までおねがい いたします。 翻訳最終更新日 : 2011-09-17 原文 "Why Functional Programming Matters" 日本語訳PostScript この論文は1984年以来何年ものあいだChalmers大学のメモとして回覧された。 1989年と1990年に幾分か改訂をしたのが[Hug89]と [Hug90]である。この版はもとのChalmer大学のメモ のnroff原稿をもとに
自分の書いたソースには過去の自分の見識しかなく、先人の書いたソースには先人の見識がある - 神様なんて信じない僕らのために
このように数多くのプログラマが「車輪の再発明」の罠に悩まされているのですが，車輪の再発明（より正確に言うと，車輪の再実装）にはそれなりに意義もあります． 車輪の再実装 - Life like a clown id:tt_clownさんの反応に対してですが、 まず、自分も「車輪の再発明」ではなく「車輪の再実装」はすべきと考えます。 既にある機能を実装する事を「車輪の再発明」といって嫌う話もありますが、 実際にそれは「既にあるものを発明（新たに考える）する必要はない」という意味で 「既にあるものを実装する必要がないわけではない」と考えています。 自分は「車輪の再発明」と「車輪の再実装」は完全に異なると考えていて、 「車輪の再発明」で無駄に頭を悩ませる必要はないですが、 寧ろ「車輪の再実装」は非常に重要だと考えています。 ただ、「車輪の再実装」は習作でしかないことも多く、 習作は習作だということ
「俺のソースだから」というプログラマは死んだらいいのに - 神様なんて信じない僕らのために
最近こんなやりとりがあった。 「Cって標準のコンテナ（双方向リストや可変長配列など）がなくて不便。 Cのプロジェクトってコンテナ自体ないこともあるし、コンテナがないとプログラムって書きにくいよね。 その点C++はSTLが(ry」 ... 「コンテナ？ STL“も”いいけど、自分で書きたい」 正直、自分は「え？ 何を言っているんだ？」と思った。 STL“も”いいけど、“自分で書きたい”だって？ その人はプログラマとしては十年選手だが、C++に関して、特にテンプレートに関しては稚児に等しいレベル。 で、どうして「自分で書きたい」ということになるんだろう？ それを使わされる人の苦労はどうなる？ それともプロジェクトに同一の事をするための複数のコンテナが存在するのか？ 俺俺コンテナを書きたい理由はなんだ？ 要するにここにおいて「自分で書きたい」はSTLがよく解らないので、 機能や動きを隅々まで把握
プログラマが好きそうな読み物100
► 2025 (2) ► 9月 (2) ► 2022 (2) ► 10月 (1) ► 2月 (1) ► 2021 (51) ► 11月 (2) ► 10月 (2) ► 9月 (4) ► 8月 (4) ► 7月 (4) ► 6月 (4) ► 5月 (3) ► 4月 (10) ► 3月 (7) ► 2月 (4) ► 1月 (7) ► 2020 (155) ► 12月 (7) ► 11月 (10) ► 10月 (8) ► 9月 (8) ► 8月 (11) ► 7月 (21) ► 6月 (19) ► 5月 (14) ► 4月 (20) ► 3月 (13) ► 2月 (10) ► 1月 (14) ► 2019 (293) ► 12月 (11) ► 11月 (12) ► 10月 (24) ► 9月 (29) ► 8月 (27) ► 7月 (36) ► 6月 (40) ► 5月 (24) ► 4月 (3
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
マクロを組んで作業するのは実力ではないですか？(1/5) - OKWAVE
私の職業は一般事務（派遣）ですが 少しVBAがわかるのでルーチン化できるものはマクロを組んでいます。 そうすることによってエクセルで1時間かかる作業が1分で終わることがあります。 なので職場では「仕事が早い、仕事ができる」と評価されることがありますが 先日先輩に怒られました。 内容は ・VBAを使うのはずるい ・それは実力ではない ・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。 ・マクロを組むのはズルとしているのを同じ と。 確かに手作業で行なえば周りの人と同じくらいの速さなので 周りと同じ環境であれば（マクロを組まなければ）仕事が早いとは言えないかもしれません。 しかし業務をどう効率よくして作業をするかを考え実践するのも仕事のうちだと思うのですが 私の考えは間違ってますか？ 入力ミスもチェックするコードを書いたので、ミスはありません。 「マクロを組んだ方が
アルゴリズムの紹介
ここでは、プログラムなどでよく使用されるアルゴリズムについて紹介したいと思います。 元々は、自分の頭の中を整理することを目的にこのコーナーを開設してみたのですが、最近は継続させることを目的に新しいネタを探すようになってきました。まだまだ面白いテーマがいろいろと残っているので、気力の続く限りは更新していきたいと思います。 今までに紹介したテーマに関しても、新しい内容や変更したい箇所などがたくさんあるため、新規テーマと同時進行で修正作業も行なっています。 アルゴリズムのコーナーで紹介してきたサンプル・プログラムをいくつか公開しています。「ライン・ルーチン」「円弧描画」「ペイント・ルーチン」「グラフィック・パターンの処理」「多角形の塗りつぶし」を一つにまとめた GraphicLibrary と、「確率・統計」より「一般化線形モデル」までを一つにまとめた Statistics を現在は用意して
final について？ - ぐるぐる～
final 周辺について。理想論？いや、理想論大事。 OCP (Open-Closed Principle) 開放閉鎖原則とも。 簡単に言うと、モジュール (ここでは class) は拡張できるべきだが、修正は行うべきではない、という原則。 これを原則に従うと、(もっと一般的な意味での) 修正が容易になる。 「拡張できるべき」と「修正は行うべきではない」を両立しないといけないので、一見、継承はこの原則を守るためには使っても良さそうなものだけど・・・ 実装の継承が OCP を破る例 例えば、 class Rectangle { int w; int h; Rectangle(int w, int h) { this.w = w; this.h = h; } int width() { return w; } int height() { return h; } void setWidth(i
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
codepad
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
Site Under Maintenance
Stack Overflow
