ブックマーク / el.jibun.atmarkit.co.jp (23)

  • 『エンジニアのためのWord再入門講座』――メンテナンス性が高くてこそ、“良い開発ドキュメント”:晴読雨読@エンジニアライフ:エンジニアライフ

    エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方 佐藤竜一(著) 翔泳社 2008年5月 ISBN-10: 4798117137 ISBN-13: 978-4798117133 2310円(税込) Wordはワードプロセッサです。 Excelは表計算ソフトです。 残念ながら、Excel方眼紙にドキュメント作成ツールとしての地位を奪われた感があるWordですが、きちんと機能を理解して使えば、必ずエンジニアの役に立つはずです。「Wordは変な動作をするし、おせっかいな機能が多くて使いにくい!」とは、言わせません。 ■「より良いドキュメントを、効率よく作る」ための 「より良いドキュメントを、より効率良く、低コストで作成する」――これが書の目指すゴールです。この目的を達成するために必要なWordの初期設定、および理解しておくべき機能などが解説されており、

    『エンジニアのためのWord再入門講座』――メンテナンス性が高くてこそ、“良い開発ドキュメント”:晴読雨読@エンジニアライフ:エンジニアライフ
    gallu
    gallu 2011/07/11
    LaTeXのほうが、メンテナンス性よくない?
  • 『体系的に学ぶ安全なWebアプリケーションの作り方』――「安全」は開発のプロとしてのたしなみである:晴読雨読@エンジニアライフ:エンジニアライフ

    体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 徳丸浩(著) ソフトバンククリエイティブ 2011年3月 ISBN-10: 4797361190 ISBN-13: 978-4797361193 3360円(税込) ■われわれの生活に根付く「安全神話」 インターネットが生活の基盤になってから久しい。皆さんは今日もどこかのWebサービスにログインし、ユーザー名やパスワードといった個人情報、あるいはクレジットカードの番号を入力したかもしれない。 「生活の基盤」である以上、安全で安心して使えるものである、という前提で考えがちだ。しかし、インターネットの先で運用されているWebサービスは、人が作ったプログラムである。人間の仕事である以上、完ぺきであるはずがない。 これは当たり前の事実であるはずだが、毎日インターネットを使っていると、つい忘れがちだ。そして、何か大

    『体系的に学ぶ安全なWebアプリケーションの作り方』――「安全」は開発のプロとしてのたしなみである:晴読雨読@エンジニアライフ:エンジニアライフ
    gallu
    gallu 2011/06/30
    (Webアプリ)書くなら(この本を)読め。(この本を)読まないんなら(Webアプリ)書くな。
  • 人形つかい(4) 実現不可能な仕様を実現する方法:Press Enter■:エンジニアライフ

    ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 他人を評価する際、第一印象を重視する人としない人がいる。ぼくはこれまでどちらかといえば前者だったし、だいたいのところ、その方法は有効だった。公言したことはないが、人を見る目はそれほど曇ってないんじゃないか、とも思っている。ところが、エースシステム横浜第1開発室システムエンジニアさんと仕事をしていくにつれて、その自信が揺らいでいくことになった。 橋さんの第一印象は、真面目で仕事熱心な好青年、だった。技術的には不安要素があるものの、単なる経験不足でしかないと思えたのだ。ぼくのカンは、橋さんを「いい人」リストに追加していた。 橋さんが誇らしげに出してきた設計書を見るまでは。 東海林さんとぼくは、エースシステム社内に用意された小さな開発室で、数日前から開発作業を開始したところだ

    人形つかい(4) 実現不可能な仕様を実現する方法:Press Enter■:エンジニアライフ
    gallu
    gallu 2011/06/14
    「うちは設計するだけですよ。実装方法はお任せします」「それを考えるのはプログラマさんのお仕事じゃないんですか?」あたりが、露骨に「レッドカード」な発言。一目散で「案件をぶち壊さなければならない」レベル
  • 伸びないベテランエンジニア:半蔵門の社窓から:エンジニアライフ

    こんにちは。株式会社リーディング・エッジ社でAndroid開発を行なっている山昭弘です。私が新入社員だったころはアセンブラで開発をしていました。その後にC言語、Java……となり、現在はAndroidの開発を行っております。この業界で20年近くやっており、そろそろこの手の話をしても良い年齢になったのと経験をしたかと思い、書きます。 ■現状維持バイアスとは 皆さん、「現状維持バイアス」という言葉をご存知でしょうか? 現状維持バイアスとは、未知なもの、未経験なものを受け入れず、現状は現状のままでいたいとする心理作用のことです。つまり、過去の成功体験が忘れられずになかなか新しいことへ挑戦ができないことを言います。過去に実績がある人、年齢が高い人ほどいっそうこの「現状維持バイアス」がかかる傾向にあると聞きます。私の経験ですが、エンジニアの場合は過去に多大な努力をして得たスキルについても同様のよう

    伸びないベテランエンジニア:半蔵門の社窓から:エンジニアライフ
    gallu
    gallu 2011/05/17
    「今のスキル」じゃなくて「成長化速度」に対する現状維持バイアスをもってみてもいいんじゃないかと思ってみる。
  • 楽しいCSSこと「Sass」の3.1が異様な進化:Rails Hub情報局:エンジニアライフ

    HamlとSassのバージョン3.1が4月24日にリリースされました。元々両者は同じプロジェクトだったのですが、今回のリリースから別々のgemとなり、インストールも別にできるようになりました。 Hamlはインデントを使ってシンプルにHTMLを生成できるテンプレートエンジン。SassはHamlとセットで誕生した、インデントを使ってCSSをシンプルに書ける独自のスタイル指定言語です。CSSを書くのが苦痛じゃなくて、楽しくなるという触れ込みです。 Hamlのほうは、今回はSassの分離が大きなトピックである以外は変化はありません。変化が大きいのは「Brainy Betty」と名付けられたSass 3.1.0のほうです(brainyって脳みそが詰まっていて頭が良いという意味ですね。変な名前を付ける人たちです……。Sass自体も、生意気な女という意味で使われる「sassy girl」にかけているんだ

    楽しいCSSこと「Sass」の3.1が異様な進化:Rails Hub情報局:エンジニアライフ
    gallu
    gallu 2011/04/27
    「変数定義が可能で、関数定義や条件分岐もできるCSS」えと………ゴーストが「逃げろ」ってささやいてる orz
  • DECOLOGでのMySQL BlackHoleエンジンの使い方:DECOLOG TECH BLOG annex:エンジニアライフ

    こんにちわ、ミツバチワークス stoneです。 DECOLOGでは、データベースにMySQLを使用しています。 ストレージエンジンのメインはInnoDBなのですが、他にもMyISAM、BlackHole、Archiveエンジンを使っています。 今回は、その中でBlackHoleエンジンについて、DECOLOG内での利用方法をご紹介したいと思います。 BlackHoleエンジンについて BlackHoleエンジンは、何もしません。 insert、update、deleteを行っても、データは全く変更されませんし、selectをしても、データは何も返ってきません。 実際のデータファイルを見てみても、テーブル定義ファイルの.frm以外のファイルは作成されません。 /dev/nullと似ているイメージです。 が、BlackHoleのテーブルに対して発行されたinsert、update、delete

    DECOLOGでのMySQL BlackHoleエンジンの使い方:DECOLOG TECH BLOG annex:エンジニアライフ
    gallu
    gallu 2011/03/22
    「BlackHoleエンジン」ををすっかりと失念してた。
  • IT技能を習得するには:Go, Go, Go, in Peace:エンジニアライフ

    月刊「Windows Server World」の連載コラム「IT嫌いはまだ早い」の編集前原稿です。もし、このコラムを読んで面白いと思ったら、ぜひバックナンバー(2009年2月号)をお求めください。もっと面白いはずです。 なお、文中の情報は原則として連載当時のものですのでご了承ください。 Windows Server 2008が登場し、数年ぶりにOS学習のモチベーションが上がっているらしい。筆者もよく相談を受ける。今回はIT技能を習得するための勉強の仕方について考える。 ●通信教育では習得できない マンガ『あしたのジョー』で、矢吹ジョーは少年院だったか鑑別所だったかで、丹下段平からボクシングの手ほどきを手紙で受ける。ジョーは一種の通信教育でボクシングを習ったわけだ。しかし、一定のレベルに達したあと、丹下段平はひんぱんにジョーのいる少年院にやってきて実地トレーニングを始める。通信教育には限

    IT技能を習得するには:Go, Go, Go, in Peace:エンジニアライフ
    gallu
    gallu 2011/02/08
    このあたりは「リファクタリングウェットウェア」を読むとわかりやすいなぁ、と思ってみたり。
  • 年頭コラム 「作らない時代」にITエンジニアはどう立ち向かうか:Road To IT-Engineer / ITエンジニアの生きる道:エンジニアライフ

    エンジニアとしてどうあればいいのか、企業の期待とどう折り合いをつけるのか、激しく変化する環境下で生き抜くための考え方 企業における戦略的IT活用を推進していくIT人材の役割は、今後ますます重要になると考えられます。しかし、その能力向上を妨げる大きな問題が表面化している側面も明らかになりつつあります。 昨今のオフショア開発の拡大や、今後はクラウド・コンピューティングの普及が現実的なものになることから、「ソフトウェアを作らない時代」への急速なシフトが考えられます。 それに対応するIT人材の可視化や能力定義が喫緊の課題となっており、さらに作らない時代へのシフトから、OJTなどでの経験を積める環境が無くなる可能性が大きく、IT人材の能力向上策やキャリアプラン策定に、大きな障害になることが考えられます。 IT人材の将来は IT企業では、筆者の知る一番深い下請け構造は16階層でした。大手が請けて利益を

    年頭コラム 「作らない時代」にITエンジニアはどう立ち向かうか:Road To IT-Engineer / ITエンジニアの生きる道:エンジニアライフ
    gallu
    gallu 2011/01/07
    オフショア開発はトラブル話のほうが圧倒的に多いし。クラウドと「作らない」との間には関連性さえ見いだせない。
  • スキル依存症:101回死んだエンジニア:エンジニアライフ

    いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■高いスキルに高い仕事 SEでもプログラマでも、IT系の仕事に携わる以上、必ず必要になるスキル。スキルが高ければ高度な業務をこなせて、単価の高い案件が回ってきやすい。 ……というのが通説だ。 確かに、スキルが高いと言われる人には、高度で単価の高い案件が回ってくる。しかし、業務がこなせてるかどうかは別問題である気がしてならない。 ■スキルは魔法とは違う IT系の人と話していると、「スキルを高めれば何でもできる。だから、スキルアップに励んでいます」という話が出る。しかし、話を聞いていると、肝心なものが2つ抜けていることに気付く。 1つはスキルの深さについての思索、もう1つは「やろうとしてることが当に可能か」という判断だ。 私は、スキルを身に付けるのは「対象を知ること」

    スキル依存症:101回死んだエンジニア:エンジニアライフ
    gallu
    gallu 2010/11/23
    「仮に天才だったとしても、1人で書けるコードやドキュメントの量なんて、たかがしれている。」という時点で「本当に高レベルの人間」を見た事がないんだなぁとか思ってしまった。
  • PMが使った魔法の言葉:Wizardを目指して:エンジニアライフ

    お久しぶりです。Forsetiです。 随分と間が空いてしまいました。諸事情によってモチベーションを根こそぎ失い、このWebサイトも最近までほとんど見ることすらしておりませんでした。仕事中に初めて「無謀です」という返事を使ったのも、今回が初めてです。 私生活でもいろいろ変化があり、以前のような更新頻度を維持することは難しそうですが、できるだけ更新していければと思います。 ●魔法の言葉「何とかします」「何とかしてください」 ある進ちょく会での出来事でした。作業者Aさんは、2つの案件からそれぞれ1人日の作業を1週間分振られており、進ちょく遅れになることが明白な状態でした(この時点ですでに何かおかしい)。 わたし「Aさんに、1日2人日の作業が振られていますけど、進ちょくは大丈夫なのですか?」 PM「その件はこちらで何とかします」 翌週の進ちょく会にて……。 A「進ちょくが遅れています」 わたし「先

    PMが使った魔法の言葉:Wizardを目指して:エンジニアライフ
    gallu
    gallu 2010/10/30
    とりあえず。まず一番のボトルネックであるPMを「どうにかして」からが本番な気がする。
  • エンジニアは足りない?:@IT通信コラム BackNumber:エンジニアライフ

    2001年8月8日の「@IT通信」に掲載したコラムを紹介します。平成20年度の調査では、ソフトウェア業の従業員数は61万8519人でした。ほぼ10万人近く増えていることになります。いかがでしょう、現場のエンジニア数は足りていますか? ■□■ EngineerLifeフォーラムを担当してからずっと疑問に思っていることがある。それはエンジニアの数の問題である。取材先でよく聞くのが、「人(エンジニア)が足りない」という言葉だ。だがIT関連のエンジニアはいったい、どれほど不足しているのかを調べようとしても、これがよく分からない。さまざまな数字は出ているが、その根拠が分からないのだ。もちろん、ぼくの調査が甘いのかもしれないのだが……。 そもそも現在、どれほどのエンジニアがいるのだろうかと調べると、5年ごとに調査される「国勢調査」、厚生労働省の「賃金センサス」、それに経済産業省の「特定サービス産業実態

    エンジニアは足りない?:@IT通信コラム BackNumber:エンジニアライフ
    gallu
    gallu 2010/06/26
    「出来るエンジニア」は圧倒的に足りない。「出来ないエンジニア」は、そもそもいらない。
  • オブジェクト指向開発を理解した開発者に、設計書は不要:アジアのソフトウェア開発現場にて:エンジニアライフ

    シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト

    オブジェクト指向開発を理解した開発者に、設計書は不要:アジアのソフトウェア開発現場にて:エンジニアライフ
    gallu
    gallu 2010/06/07
    「設計書」って何だろう? とりあえずそこからかなぁ。
  • 炎上したのでまとめ:ベンチャー社長で技術者で:エンジニアライフ

    株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 炎上したので、論点を整理しておく。 1.業務系では効率がトレードオフできない必要条件 業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です(十分条件ではない)。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。 効率が必要条件にならない職業もあるけれど混同してはいけない。 2.SQLはオブジェクト指向言語の数十倍の効率 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十%も変わらない。 SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。 言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。ですから、できない人を対象に比べても

    炎上したのでまとめ:ベンチャー社長で技術者で:エンジニアライフ
    gallu
    gallu 2010/05/20
    なんか具体的な数字が出てるなぁ。全然具体的じゃないけど(笑 & 「大きく書い」た「例えばのイメージ」が理論値なんだw
  • 炎上したコラムについて:ベンチャー社長で技術者で:エンジニアライフ

    わたしが書いてきたことは「炎上マーケティング」と揶揄されても仕方がないと思っています。しかし、炎上して欲しいと思っていたわけではなく、激しく対立する主張が存在することを承知のうえで、衝突を恐れずに書いているだけの話。もっとも、文に沿わない明後日の方向のコメントから、明後日の方向へ燃え上がることも多く、それは予想も予防もしようがないのですけれど(苦笑)。 みながわけんじさんのコラムは、予想どおり炎上した。予想どおりというのは、@ITの読者層の大半は、反対のことを考えているのを知っているからで、言い掛かり的な部分が多いと思う。わたしが書くとさらに炎上する可能性が高いため控えていたけれど、収束したようなのでTwitterでつぶやいていた内容を少し。 そもそも論ですが、社内SEとSIerやソフトハウスのSEは、根的な職務が違います。 社内SEはコストセンターとして存在するため、できる限りコスト

    炎上したコラムについて:ベンチャー社長で技術者で:エンジニアライフ
    gallu
    gallu 2010/05/15
    「慣れた技術にしがみついている」一方で「不慣れな技術に対して勉強をしようとしない」、いわゆる老頭児の典型例。っつか、昨今の「NoSQL」の流れをどう捉えてるんだろうか? & オブジェクト指向ごとき、どれだけの
  • 実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ

    わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他

    実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ
    gallu
    gallu 2010/05/09
    「私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか?」どうにもならない、で終了。この文章を書いてしまった時点でなんていうか「完全終了」だと思う。
  • Googleの構造を想像して、KVSとRDBを考える:ベンチャー社長で技術者で:エンジニアライフ

    株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 Googleの内部を知っているわけではないのであくまで想像ですけれど、わたしが作るとしたらこんな風に作る。それって、RDBとそんなに構造が変わらないよね。って話です。Googleの構造はユーザーとして想像しているだけに過ぎないので、違っていたとしても、そこそこ効率的に動きますからその辺には突っ込まないようにね(笑)。 まずは、リクエスト処理サーバ群がリクエストを受けたところから考えてみましょう(番号は絵とリンクしていません)。 1.Googleは辞書を使う形態素解析という方式ですので、受け取った検索文字列を、辞書を使っていくつかに分割する。 2.分割したキーワードをキーワードライブラリサーバ群に投げます。このサーバ群には、キーワード毎のコンテンツ件数と、その内容

    Googleの構造を想像して、KVSとRDBを考える:ベンチャー社長で技術者で:エンジニアライフ
    gallu
    gallu 2010/03/20
    クラウド…というか、もうちょっとこなれた用語に変えると「分散処理」が理解出来てないんだなぁ、ってのが、よくわかった。
  • 顧客が欲しいのは「タイヤのブランコ」:ベンチャー社長で技術者で:エンジニアライフ

    コメントを返せなくて申し訳ございません。弊社サイトの焼き直しで更に申し訳ないですが、コメント代わりとして下さい。 前回、UIについてこそっと書きました。わたしがいいたかったのはこの漫画の内容です。 アメリカの自動車会社のフォードを作った Henry Ford も同じことを言ってます。 「もしわたしが顧客に、彼らの望むものを聞いていたら、彼らはもっと速い馬が欲しいと答えていただろう」 そう、顧客は「速く移動できる手段」が欲しいということを「もっと速い馬が欲しい」と表現するかも知れませんし、「タイヤのブランコ」が欲しいとき「三連のブランコ」と表現してしまうかも知れません。顧客がいった言葉そのものは、必ずしも正しくないのです。 さて、ここからものすごく細かくチープな話になりますが、日付入力について顧客側から「年を4桁入れたら、自動的にスラッシュを付加してくれないか」という要望が出てくることはよく

    顧客が欲しいのは「タイヤのブランコ」:ベンチャー社長で技術者で:エンジニアライフ
    gallu
    gallu 2010/03/14
    「相手の事を理解できた」と錯覚する瞬間が、一番危険です
  • 深夜番組のようなノリで、Twitter・KVSもろもろについて考える:ベンチャー社長で技術者で:エンジニアライフ

    Twitter 何カ月かやってみて何となく分かりました。これって、英語圏より日語(漢字)圏の方があってる気がします。昔からチャット特有の英語のスラングがあるけれど、それでも、英語では140文字では厳しそう。 Twitter音が出てしまうというのはそのとおりだと思います。ブログは多少いい格好はしてしまいますからね。 基的にはチャットの拡張版と見てしまう。チャットといえば Niftyで卒業したわたしですが、当時は、Windows3.1の時代。上海からもやっていて、ホテルで電話線の接続ポイントを外し強引にモジューラジャックに改造して、インターネット → CompuServe → Nifty とつないでいた。ノートPCは14.4Kbps、デスクトップは28.8Kbpsのモデムだった。 電話線を壊しているのを見て、中国の人に、「あなたはZビザを持った外国人なのですから、そんなことしてバレた

    深夜番組のようなノリで、Twitter・KVSもろもろについて考える:ベンチャー社長で技術者で:エンジニアライフ
    gallu
    gallu 2010/02/18
    「KVSに対してSQLのような汎用的なアクセス手段があるのでしょうか?」ンなもんあるわけないべ? 「Googleのように高機能を目指している向きもある」だからKVSってもん理解してないでしょ?
  • コメント代わりとして、「効率化」について語る:ベンチャー社長で技術者で:エンジニアライフ

    株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 しばらくとっても忙しいので、コメントが返せずすみません。遅れて返すとおかしくなりそうなので、コメント代わりに書かせていただきます。 基的にIT技術者というのは、効率のために存在しています。顧客は人間がやるよりも、コンピュータシステムでやる方が効率的だから、コンピュータシステムを導入するわけです。 「効率化すること」は最も重要な大原則です。「効率だけじゃない」と思う人もいるかもしれませんが、+αはいくらあっても良いので「だけじゃない」は正しいけれど、+αで効率を置き換えれると思うなら、顧客が見えてないでしょう。 例えばWeb(HP)であっても同じです。会社案内を配って歩いたり、TVでCFを流すよりも、24時間世界中に営業できることになり効率的なので採用されるわけ

    コメント代わりとして、「効率化」について語る:ベンチャー社長で技術者で:エンジニアライフ
    gallu
    gallu 2010/01/16
    「RDBMSを使う限りSQLを使うことが最も効率的です」えと…SQL以外の選択肢ってなにがあるのかなぁ? Tutorial D?w
  • 白熱(炎上)したのでまとめ。:ベンチャー社長で技術者で:エンジニアライフ

    株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 不意にも、一部のコメントを非表示にせざるを得ないほどの状態になったのは当に残念ですが、白熱(炎上)したのでまとめ。 前の記事はこの辺です。 常識のライン テレビのリモコンを孫の手で押すなって! オブジェクト指向言語で処理したら保守性が悪い! 自分で書いた1年前のモノも読み直してみると、これらとほとんど同じことを延々書いている。まぁ、10年前から同じことを言ってるし、成長がないな~。 一応、なぜ炎上したかというと、そもそもの「常識のライン」が合わない人がやってきたためです。初級シスアドというのは毎年1000人以上の高校生(高専や専門学校を入れたら10代の合格者は毎年数千人)が合格してきたぐらいのレベルの試験です。高校時代に合格するのは相当に努力とセンスが必要で

    白熱(炎上)したのでまとめ。:ベンチャー社長で技術者で:エンジニアライフ
    gallu
    gallu 2009/12/16
    どうでしょう「初級シスアドに合格した高校生」さんを雇ってみては。論調が正しいのであれば、きっと、お高い「プロもどき」よりもよいシステムを作ってくれるのでは?(念のため。あり得ないと思ってます私は)