【2ch】ニュー速クオリティ:COBOLの利用は精神を損なう。COBOLを教えることは犯罪行為だ
1 毎日新聞配達(福島県)2008/09/21(日) 14:03:04.30 ID:cpGers0D0 ?2BP(3001) 株主優待 本家/.の記事より。チューリング賞受賞者エドガー・ダイクストラ曰く、 「COBOLの利用は精神を損なう。よって、COBOLを教えることは犯罪行為とみなされるべきだ」 http://developers.slashdot.org/article.pl?sid=08/09/19/2035223 ……とはいえ、このDr. Dobb's Journalの記事によれば、COBOLのしぶとさには度外れたものがあるらしい。 21世紀に入ってもCOBOLは最も広く使われている言語であり、今日のソフトウェア開発における最もホットな 領域のいくつかで重要な地位を占めている。あなたが次に学ぶべき言語はCOBOLかもしれないのだ。 1997年、Gartner Gro
Webエンジニア武勇伝 第35回 手嶋 守 氏 | 株式会社 手嶋屋 代表取締役
今回はOpen PNEの生みの親である株式会社手嶋屋の手嶋守社長にお話を伺いました。一見和風な雰囲気の「手嶋屋」の社名には、手嶋社長の仕事に対する熱い想いが隠されていました。パソコンとの出会いや株式会社手嶋屋の創業当時の苦労、SNSに特化した理由など手嶋屋本社で約１時間程お話を伺いました。 手嶋 守 氏 株式会社 手嶋屋 代表取締役 1979年、東京都生まれ。東京理科大学理工学部卒業。大学卒業後2002年3月に携帯関連のコンテンツの開発会社として「手嶋屋」を起業。 2005年に自社開発のSNSエンジンを「OpenPNE」としてオープンソース化し、日本で初めて「レシピを配ってレストランを開く（ソフトは無料・サポートは有料）」オープンソース・ビジネスを展開。現在、国際機能を搭載した「OpenPNE 3.0」を開発中。著書に「図解でわかるiアプリプログラミング」（日本実業出版）、監修書に「Ope
学び続ける意志は未来を切り開く - tomomii日記
大阪のジュンク堂でおこなわれたはてなCTO 伊藤直也さんによるトークセッション「私と技術書」を拝聴してきました。 ご自身の大学受験から現在に至るまでの「本を読むことと自分とのかかわり」について、90分もの時間濃ゆいお話をうかがうことが出来た。セッションでは、なおやさんの人生に深く関わった技術書が多数紹介され、どのようにその本と向き合ったかについて語られた。技術者の方にはモチベーションの上がる刺激的な情報だったと思う。わたしは技術者ではないし、プログラミングのプの字もわからず数字を見るとめまいがする人間なので、今日紹介されたほとんどの技術書は今後読むことがないかもしれない。おそらく、ない（事実 内容をメモすら出来なかった。宇宙語みたいで）。しかし技術書を通じ、なおやさんの人生をほんの少し垣間見せていただいたことで、自分の中で非常に感化されるものがあったのは確かで、お話の内容と自分に湧いた思い
SEは美しいドキュメントを作れ
SEは仕事上，開発計画書，提案書，システムの鳥瞰図や概要図，業務フロー，業務分担図などさまざまな資料を作る。打合わせ資料，進捗報告書やトラブル報告書などの類もある。そしてそれをお客様に提示する。そんな時，お客様から「この資料は良くまとまっているね」，「この図は上手いですね」，「凄く分りやすいです」などと言っていただけるといろいろなメリットがある。 ドキュメントは強力なコミュニケーション・ツール まず，お客様に「このSEはやるな！」と思っていただける。すると信頼を得やすい。新規顧客だとその瞬間に自分を売り込める。その効果は絶大である。 次に，顧客に自分が言いたいこと，訴えたいことをより的確に伝えることができる。すると顧客との間での，勘違いや早とちりなどの誤解が大幅に減る。システムの開発範囲や要件の範囲などの打合わせでは，その効果は少なくない。 即ち，ドキュメント力はSEにとっては強力なコミュ
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
プログラミングファースト開発は物神化に並ぶ人月商法脱却の解か - 雑種路線でいこう
プログラミングファースト開発と最初に聞いて、ソフト開発の手順としては当たり前過ぎて、最初は何が新しいのかさっぱり分からなかったんだけど、肝は如何に受託開発でそれを貫徹するかの交渉術や契約形態にありそうだということに合点がいった。人月に代わる値付けの方法、機能や品質に応じた対価を得る手法として、パッケージ販売やSaaSといった共通化と利用者拡大の他に、相対取引での値付けにも新たな道は広がるのだろうか。 実は世の大半の名だたるソフトウェアに厳密な仕様書などないし、受託開発でも設計書と呼ばれているものがコードと同期している可能性はかなり低い。これはソフトにとって役に立つこと、問題を起こさないことが、仕様書通りに動くことよりずっと重視されてきた結果であって、みんな心のどこかで気掛かりではあるけれども、マクロ的には合理的なトレードオフの結果であって必ずしも悪い話ではない。 恐らくプログラミング・ファ
ソフトウェア開発の「自由の悲劇」 : 小野和俊のブログ
クリエイティブな仕事というのはある意味で残酷だと思う。 なぜなら、 つくりあげたものが評価に値しないものだった場合に、 自由にできる環境があったのに、 この程度のものしかできなかったのかという批判が 本人に対して直接的に向けられやすいからだ。 というような話を耳にすることがあるのだが、 「誰でもいいからお金を出すので好きにつくってよい」 という状況はほとんど考えられないわけで、 もし本人の希望がかなった結果、 大したものを生み出すことができなければ、 自分には新しいものを生み出す才能がないのではないかという 悩みに直面することになる。 もちろん、中には自分自身でソフトウェアを次々と開発して、 ダウンロード数やアクセス数、メディアで取り上げられた記事などを印刷し、 この企画を会社の事業として採用しないか、 と持ちかけてくるような強者もいる。 だがそういう人でさえ、注目を浴びたソフトウェアの影
SI契約に変革迫る「進行基準」 IT業界に激震走る！：ITpro
この記事は会員登録で続きをご覧いただけます申込は簡単3分！ 今すぐ会員登録（無料） 会員の方はこちら 【8/20まで】今なら年額プランが2カ月分お得！ 詳しくはこちら ▼日経クロステック有料会員になると… オリジナル記事がすべて読める 専門雑誌7誌の記事も読み放題 雑誌PDFを月100ページダウンロードできる
作ることは、目的じゃなくて手段でしょ？｜fuuri.net
Tweet Check Category：[ つぶやき, 行ってみた ] Tag：[ CSS Nite | Web制作 ] 13日の金曜日に行われたCSS Nite Shuffleは、強烈な印象の残ったイベントでした。特に住さんと高木さんのトークセッションは、いろいろな思いを持って聞きました。どれだけ整理して書けるか分かりませんが、がんばって書いてみます。 お話を聞きながら、私はその場で「違う…」と思わずつぶやいていました。 いや、もう、「人種が違う」に近い感覚を持ちました。この人たちは、私と同じ世界に生きていない。「デザイナー」ではなく「アーティスト」だと思いました。 住さんは、セッションの最初にこうおっしゃいました。 「プロ野球選手は、野球が好きだからプロになるんじゃなく、プレイするのが好きだからプロになるんだと思うのです。みなさんも多分、なにかしら作ることが好きだからWeb屋をやって
スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記
少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし本当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が
予告.inをSaaSワールドの予告として見る - アンカテ
まず予告inについてのこの3つのエントリは必読。 予告inについて少し真面目に述べてみる : ロケスタ社長日記 デジモノに埋もれる日々: 総務省の「犯罪予告検知ソフト開発」の予算と「予告in」 - 対処は本当に可能なのか 犯行予告共有サイト「予告.in」が痛快だ。が… :Heartlogic 個人やこういった小さい会社でやる分には、素早く、すぐにリリースして、改善していくことができます。 しかしその分、クオリティに問題があったり、対応がこなれていない可能性もあります。全部を人力でチェックするほどのコストもかけられないし、そもそも人的リソースが足りない。 国家が数億かけてやるものとは、そもそも性質が違うんですよね。意外に思うかもしれませんが、彼らの作るものが無駄だとは思っていません。 ネットというかWeb2.0とかいわれる世界は、実はそういうアイデアで溢れています。 理想が100だとしたら、
小野和俊のブログ:続・プログラム・デザイナー宣言
前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点
はてなブックマークの作り直しについて - naoyaのはてなダイアリー
id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、本来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して
プログラマの心の健康
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
あるＳＥのつぶやき: フリーで使えるプロジェクト管理ツールまとめ
フリーで使えるプロジェクト管理ツールをまとめておきます。 ■ガントチャート 開発マイルストーン ガントチャートでプロジェクト管理できるExcelツール フリーとは思えないほど高機能 ガントチャートforExcel・・・シェアウェアになりました こちらもガントチャートでプロジェクト管理できるExcelツール スケジュールの表示期間を切り替えられるのが便利 OpenProj Java ベースでガントチャートでプロジェクト管理ができるツール Microsoft Project のフリーのビューワーとしても利用可能 フリーの高機能プロジェクト管理ソフト「OpenProj」を試してみました TaskLine Excelのアドインとして動作するプロジェクト管理ツール（saramiさん情報） Microsoft Projectのファイル(XML形式)をExcelで表示するProjectViewerもある
ブラック会社に勤めてるんだが、もう俺は限界かもしれない:ハムスター速報 ２ろぐ
1 ：以下、名無しにかわりましてVIPがお送りします。：2007/11/24(土) 21:38:07.44 ID:Jw+br6zA0 職業はプログラマ。この職業、マジでやばすぎる。 入社日での出来事。 パソコンを渡される→指示された通り、色々なものをインストール→設計書を渡される。 「これでおっけーと。んじゃ作れ」 「え？」 「いや作れって」 「あ、え？は、はい」 「みんな忙しいから、出来る限り自分で解決しろよ」 そう言って去っていくチームリーダー。 このまま悩んでてもしょうがない。とりあえず設計書を見てみるか。 フレームワークがどうのこうの、うんたらかんたら・・・。テストはどうのこうの・・・。 ワケわからんぞ 2 ： ￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣：2007/11/24(土) 21:38:20.38 ID:hhJr3lPT0 ／／
「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan
あるサイトで連載の話を進めていて、そのコンテンツを考えていた。目次を書き出しているときにふと「プログラマ35歳定年説」なるものを思い出した。 プログラマ35歳定年説とは、「プログラマは年齢を重ねて行って、35歳ぐらいになったらSEなりマネジメントなり、次に行かないとオマンマ食べられないよ」というものだ。 「そういえば、自分もそう言われてきたっけ・・・。若いころは「俺たちがシステム作ってんだ！実力があれば絶対に大丈夫。ふざけんな！」と思っていたよなぁ。」 ふと考えれば私は今36歳。その説によれば定年を迎えている年齢だ（笑）。年金はもらえないが・・・。 プログラマ、SE、マネジメント、経営の一通りを経験してきて、その説の私なりの考えを書いてみたくなった。 35歳プログラマ定年説は本当か？・・・私にとって かつては技術力に自信があったし、楽しいプログラマ人生を送ってきた。そんな私だが、今もし誰
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
Joel on Software - 射撃しつつ前進
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
