10年以上前の時代に戻るだけ - しんさんの出張所 はてなブログ編
http://d.hatena.ne.jp/nowokay/20100104#1262596755 Webアプリというものがたまたまはやっただけで、言語や開発環境としては異端。それがおいらの考えです。Webアプリしか勉強してこなかった人たちがいるとしたらものすごく怖いかなという感じで。 あと、WebアプリでIDEを使わないとか動的言語が当たり前という風にはおいらは捕らえていません。仕事で開発する場合、大概IDE等開発環境があるはずです。使っていない場合というのはまずほとんどお目にかかったことがありません。 個人的に思うのはWebアプリは他人の目に付きやすいという点です。社内システム等はほとんどのところは閉じた空間でしょう。どんなに使われていても目立つことは無いのです。ですが、Webアプリだとそれをさわって公開している人がすごく目立つ。個人的にはAccessやVBやC/S系のシステムなんてま
Webアプリで動的型付言語や開発管理が流行りIDEが流行らなかった理由などなど - きしだのHatena
考えてみた。 ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。 この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。 Webアプリケーションの構造 で、まずはWebアプリケーションの構造。 字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。 赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。 Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。 ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。 このとき、サーバー側のプログラム
ひがやすを「SIerは顧客の良きパートナーとなれ」 － ＠IT自分戦略研究所
「クラウド」や「内製化」で変わりつつあるIT業界。その中で従来型のSIerはどうなるのか。そこで働くITエンジニアはどうするべきか。講演やブログを通じてSIerやエンジニアについて提言を行ってきたひがやすを氏へのインタビューから、2010年の「自分戦略」を立案するためのヒントを探ろう。 第4回｜1 2｜次のページ 1週間にわたってお送りしてきた特集「SIerの未来、エンジニアの未来」。最終回は、システムインテグレータ（SIer）に勤めながら従来型のSIerに数々の提言を行ってきた、Seasarフレームワークの開発者ひがやすを氏に、SIerが今後どうなっていくのか、ITエンジニアはどうあるべきかを聞いた。 2010年のあなた自身の「自分戦略」を考えるうえで、参考になれば幸いである。 ■ 従来型SIerは崩壊する ―― 今年はSIerにとって苦しい年となりましたが、今後SIerはどうなっていく
選んだのは「内製回帰」の道――ひとり情シスの挑戦 － ＠IT自分戦略研究所
ITコスト削減によるユーザー企業の「内製化」の波が生まれている。SIerに外注するのではなく、自社のシステムを自ら作り出す。そうした「内製化」にこそビジネスとシステムの未来があると信じ、SIerからユーザー企業へと転身したエンジニアが、「内製化の可能性」と「やりがい」について語る。 第2回｜1 2｜次のページ 「GoTheDistance」というブログを運営している湯本と申します。簡単に自己紹介させていただきます。 2003年に、とあるユーザー系大手システムインテグレータ（SIer）に新卒で入社し、プログラマ、開発リーダー、プロジェクトマネージャ（PM）、コンサルタントというキャリアを歩んできました。 振り返ってみると、とても恵まれたキャリアを歩ませていただいていたと感じます。ですが、さまざまなユーザー企業さまのお話をお伺いしているうちに、システム開発は「内製」に向かうべきである、と感じる
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
プログラミングファーストには期待しています - GoTheDistance
やっと自分の見解がまとまってきたので、今頃この話題に足を突っ込む。 プログラミングファーストのメリット・デメリット 色々関連するエントリを見させて頂いて*1多分こういう感じだろうと思いました。ざっくりと。 主体者 メリット デメリット ユーザー 早期に最終成果物を共有できる 単なるコスト増になる可能性がある システム屋 エンジニアの能力・創造性を価値に変えられる 少数精鋭・内製志向に適したビジネスモデルの構築が困難 こういうお話は「ユーザー目線｣と｢システム屋目線｣に分けて考えるとわかりやすいと思います。 ユーザーにとってのメリットは早期に最終成果物を見ることができることだと思う。もちろん｢最終｣というまでには設計も必要だろうしテスト結果も必要なんだけど、｢実装してユーザに使ってもらう｣ことによるメリットは少なくない。システムって使ってみて初めて価値がわかるものだし、品質を決める基準はユー
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
泥の業界でも仕事は宝石なこともあるんだよ - GoTheDistance
id:wa-renさんの所でこれと同様の立ち位置のイベントが開かれていた。お疲れさまでした。 ネタ元 "第1回 泥カン"無事終了。まとめと一部スライド公開 泥カンについて一言 情報系学生のための交流企画「IT企業はほんとに泥のように働かされるのか」レポート ITギョーカイ俯瞰図 あの絵はポンチ絵だからあんまりマジで突っ込まれるとwa-renさんもちょっとツラいと思う。でも｢SI目線｣から見たらあの絵はいい絵だと思います。SIの｢S｣は業務システムの｢S｣なので仕事の単位が会社単位になる傾向が圧倒的に強く、id:amachangが疑問に思ってたBtoC市場の仕事はSIにはふってこないことが多いです。個人顧客用のWebサイト(通販とか)は大抵子会社に作らせているんじゃないかなってふと思いました。ツタヤにおけるツタヤオンラインとかね。 泥ってなんやねん それよりも何よりも、｢泥のように働く｣から
Teedaのメリット・デメリット - おおたに6号機のちゃかつかない話
Teedaのメリット・デメリットについて振り返ってみたいと思います. ■Teedaのメリット ・HTMLテンプレート まずはなんといってもHTMLテンプレートではないでしょうか。 レイアウトを確認するうえでは威力を発揮しやすいと言えます。 また前工程でユーザに確認してもらうために作成したモックをそのまま開発に 持ち込める点は良いのではないでしょうか。 ・設定ファイルレス 規約による設定ファイルレスはTeedaの中でも生産性に貢献する部分のひとつです。 簡単な規約を付与することで、設定ファイルに書くタグ＋設定内容を規約に 置き換える部分は効果はあったでしょう。ただしデメリットもあります。後述します。 ・POJOベースのPageプログラミングモデル POJOなPageクラスをHTMLと1対1でバインドするTeedaの方法は 役割としてはとてもわかりやすかったように思います。DoltengのHT
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの
スーツにはスーツの道がある - GoTheDistance
勢いで書く。 スーツ側の人は業務内容が密接にプロジェクトや会社の中の話と結びつくことが多いので、はてな界隈ではなかなかスーツ側の人はスーツ側の濃ゆい話を書くことが出来ないことが多いようだ。圧倒的にスーツ側の人間がはてなを始めとしたブロゴスフィア全体で少ないなぁとつくづく思う。QAも少ないけど。この辺をアツく語るブロガー出てこないかなー。 私は200X年に今の会社に入社して、数年間WEBアプリケーションの開発をやった。多くはJavaの案件だった。最後の案件は去年の夏ごろだ。前任のPMが逃げるように辞めていってしまい、非常に複雑なロジックを自分が担当することになった。1500行越えktkr。それを参考にして(これが大間違いだったんだよセニョールorz)２週間かけて作ってみたはいいものの、テストを繰り返しているうちにどんどんボロがでて、結局その当時のPMとパートナーさんに相談して設計からやり直し
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
