クソレビューアだらけのレビュー会
体裁厨 「お♪ ここだけフォント違うくない? それからなんか間隔せまいし。」 用語統一厨 「"お問い合わせ"は"お問合せ"と表記することに決まってるので」 箇条書き過剰 「箇条書きにして。その方が分かりやすいよ。」 物忘れ激しい系 「こここんな仕様だっけ? え、設計書に書いてる? 作成者だれ? オレ? 決めた覚え無いけどなぁ…」 レアケース厨 「UUID? 100%衝突しないと言えない? じゃあダメじゃん。」 ショートカット厨 「Ctrl + Shift + T、Ctrl + Shift + T。あぁそれやるならCtrl + Shift + Rだ。」 遅れてくる系 「なんかここおかしくない? えっもう指摘された? ごめん、もう一回ちょっと説明して」 指摘曖昧系 「なんか分かりにくいなぁ。色付けたりするとかあんじゃん?」 寂しがり 「ちょっとなんか寂しいな。ここ説明書き足したら。いやこれだけ
明日また来てください、本物のExcel方眼紙をお見せしますよ - aike’s blog
「俺はェスァイ」 「SIって？」 「お客様のビジネスに最適なソリューションをインテグレートするんだ」 「でたっ、富士通っぽいことば！！」 「標準機能を組み合わせたパッケージは使いにくいからだよっ！！」 ドス、ドス、ドス、バッ 「この仕様書を作ったのは誰だあっ！！」 「Excelの文書がなにかございましたか」 「なぜセルをこんなに細かくした！！計算など必要のない連中がスプレッドシートを使うからだ。馬鹿どもにExcelを与えるな」 「ははっ」 「そんなことを言うからには、文字やフォームを任意のグリッドにレイアウトできて、顧客も当然のように文書ファイルを開けるソフトウェアがいろいろあるんだろうな」 「ぐぬう」 「Excel方眼紙は帳票デザインが大きな割合を占める日本の業態に即したものなんだ」 「とはいえ俺も一般的なExcel方眼紙が最良とは思わない」 「みなさん、明日またここに来てください、本物
「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
"BigData"では何が問題なのか？ - 急がば回れ、選ぶなら近道
”ビッグデータで奇跡が起こる” はいどうも。まず、個人的には楽天的な進歩史観には、まったく組しない。 従って、突然に新技術ができて、なんか凄い事になる、というのはさらにまったく同意しない。すべからくブレイクスルーは課題解決により起こると思っているので、問題意識のないところに、こんなものできました的な発想は、基本的にプラスにならないことが多いと思っている。現状のビッグデータブームは2011年の秋口現在は完全にハイプになっており、バブルと言ってもいいと思う。印象として、十数年前のナノテク・ブームに似ている。 とはいえ、過度の期待という側面を除けば、それなり効果もある部分もあり、”そこだけ”を見ていけばそれなりに効果はある（と思う）。大体において、今後は以下の二つのユースケース・カテゴリーに集約されると思う。すなわち、ビッグデータの拠り所はまずもって以下の２点だ。 1 Webのログ解析 というか
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
3回に1回出力するだけの簡単ではないお仕事 - やねうらおブログ(移転しました)
なんかさ、3回に1回出力するだけの簡単なプログラムのお仕事ってあるじゃん。 if ( (++counter % 3) == 0) printf("Fizz\n"); これって意外と難しいんだよね。 ……なんてことを言うと「おいおい、天下のやねうらお、ついに頭おかしくなったか」とか言われるだろうけど、これ実際うちの仕事であった話で、このコードが原因でお客さんと大きなトラブルになった。 あまり具体的には言えないので、ちょっと別のものに置き換えて話すけど、それは、ひよこの餌やりプログラム(仮)だったわけ。 上のプログラムは、3回に1回だけど、このソフトには、N時間に1回、餌をやるロジックが書いてあった。 if ( (++counter % N) == 0) printf("餌やるでー\n"); なんかこんな感じな。それでNの値は、UI(ユーザーインターフェース)で調整できる作りにしてあった。一度
オブジェクト指向による情報インパール大作戦 - camlspotter’s blog
えー、なんだか、(都合の良い)情報というのはそれを望んでいる人の所に自然に集まってくるようなのです。大変芳しいネタに行き当たってしまいました。(id:mzp さんどうも情報ありがとう。) まじめなオブジェクト指向論を繰り広げたく、少しづつ論考してはいるのですが、寄り道の誘惑に抵抗できません。 挑戦: 金融工学を駆使した先進的市場系システム開発に挑んだ精鋭たちの物語!、なのか？これが？ プロジェクトX型神話、と私が呼んでいる都市神話類型があります。場所や登場人物がころころと変わりますが、基本的なプロットはまず全て同じで、大まかに次の起承転結四要素からなっています: 挑戦: 優秀な人材が夢一杯に新プロジェクトを開始。 挫折: 予測もしていなかった難題にぶつかる。 打破: 社員の才能と努力で解決! 成功: 得られた教訓を語る、プロフェッショナル仕事の流儀 もちろんこの類型の大元はNHKの人気番組
第9回 逝去した巨匠への追悼 感激したあの言葉
このコラムで以前，世界的な建築家のレビューのすごさについて書いたが，その巨匠が逝去された。巨匠との仕事の中で，もう一つ強く記憶に残っていることがあるので追悼の気持ちを込めて紹介したい。 筆者のコンサルティングの仕事の中で，個人を相手にした仕事が一度だけある。もちろんITのコンサルティング会社を経営していると知人からパソコンやインターネットに関して相談されることは多い。しかし，それらは個人的なアドバイスであり，報酬をもらうような仕事ではない。ところが，巨匠の設計事務所から依頼された個人相手の案件は驚くべきものだった。 巨匠の作品は，都市，空港，美術館，複合施設など大規模なものが有名だが，ごく少数であるが個人邸もある。依頼は，ある資産家の新築邸のネットワーク導入だった。当初は軽く考えていたが，打ち合わせに出向くとちょっとした規模の企業からのオーダーと変わらぬものであった。施主の要望は，全部屋イ
ニッポンのSIが置かれている隘路と展望 - 雑種路線でいこう
まあ別に給与水準が下がれば転職すればいいし、それが産業のダイナミズムって気もするんだけど。ニッポンのSI業界が置かれている隘路って1990年代以降オープン化でハードの利鞘を稼げなくなったところに、開発生産性の劇的な向上と技術サイクルの短期化で生産性格差が劇的に拡大し、プロジェクトの失敗リスクが増大したことにある。かかる環境変化で、以前から潜在的な問題であった系列取引、重層的下請け構造、人月商法、人材の低い専門性といった課題がリスク要因として浮き彫りになった。 ブランド力が通用しない市場は、自然と価格競争になるわけですが、今のSIerは、どこも同じような重量級の開発プロセスだから、開発プロセスでは差がつかない。後は、下請けの単価を下げるか、自分たちの給料を下げるかになってしまいます。 つまり、SIerの給与水準は、今後少しずつ下がっていく。負けているわけじゃないけど、ジリ貧みたいな。 残念な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
