タグ

engineerに関するytesakiのブックマーク (38)

  • 技術書の売上げから見る技術トレンドいろいろ | POP*POP

    Web2.0の提唱者でもあるTim O’Reillyさんがおもしろい分析をしていました。 技術書の売上げを図で可視化しています。前年度と比較して各テクノロジーが上り調子かどうかがわかります。業界内シェアの大きさもつかめますよ。 「これから何の言語を学ぼう?」など考えている人には参考になりそうです。 » O’Reilly Radar > State of the Computer Book Market, Q406, Part 2: Category Winners and Losers 面積と色でデータを表現するTreemapを使っていますね。面積がシェア、色が伸びをあらわしています。緑色のブロックが前年度と比べて伸びているところ、赤色のブロックが減ったところになります。 では、各業界を簡単に見てみましょう。イメージはクリックで拡大します。ではどうぞ! ■ プログラミング&システム管理 一

    技術書の売上げから見る技術トレンドいろいろ | POP*POP
  • 7つのアジャイル開発手法の実践ガイド(第1回):CodeZine

    多くの場合、開発者はコードを記述するだけでなく、コードがアプリケーション環境で適切なスケーラビリティを持ち、適切に動作することを保証しなければなりません。稿では、スケーラビリティテストとゴールテストの違いを取り上げ、手動テスト向けの擬似コードテストハーネスの例を紹介し、実際にQuest SoftwareのToadという自動テストインターフェイスを使用してOracleプロシージャのテストを行う例を示します。

  • http://www.linuxkungfu.org/images/fun/geek/project.jpg

  • JavaとLLをマッシュアップせよ from 丸レク (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 追記2:Groovyのサンプルをまたもや修正。矢野さんにコメントいただいたとおりです。 追記1:Groovyのサンプルにウソがありました。ごめんなさい。eachやinjectはListの拡張なので、[1..5]のRangeでは使えません。eachするとRangeそのものが取れちゃいます。ちゃんと試さずに書いちゃいました。ちなみにデモは[1,2,3,4,5]とやってのでうまくいきました。 ブログもアップできず当に情けない…。さて、昨日の第2回丸山先生レクチャーシリーズ で「混ぜるな危険!? JavaとLLをマッシュアップせよ」というタイトルで講演させていただきました。資料はこちらからダウンロードできます。 Java業界でもJSR223を機会にLLに対する取り組みが盛り

    ytesaki
    ytesaki 2006/12/17
    新車開発のようなものというのがわかりやす。
  • 目次:ITpro - 技術者視点のユーザビリティ考

    使いやすいサイトを作るのは,デザイナーだけの問題ではありません。エンジニアとしてサイト構築にかかわっている筆者が,日ごろぶつかった問題をネタにじっくり考えていきます。 ・第33回 リピーター増加を阻む「面倒くささ」の壁 あるウェブサービスを初めて使った人が「しばらく使ってみよう」と思ってくれても,「面倒くささ」の壁に阻まれて次第にサービスの利用から遠ざかっていくことはよくあります。ブラウザを利用しないものを含む,さまざまなインタフェースを提供することで,その面倒くささを乗り越えられるのではないか,という仮説のもと,いくつかの例を紹介します。 ・第32回 リダイレクトの正しい使い方とは あるページ(URL)にアクセスすると,自動的にほかのページにジャンプするリダイレクトは,ウェブサイトを構築するうえで非常に重要な仕組みです。しかし,ユーザーの知らないうちにページの移動を行うため,ユーザーを戸

    目次:ITpro - 技術者視点のユーザビリティ考
  • オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない!:selfup

    オブジェクト指向はしばしば,とっつきづらく難しい技術と言われます。その理由の一つには,対象とする分野が広く,それぞれに深みがあることが挙げられます。しかし,それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と,「もの中心」を意味するコンセプト自体の問題です。 そこで特集では,「オブジェクト指向という言葉をよく聞くけど,実際どんなものかよくわからない」という方のために,初心者/入門者が陥りやすい落とし穴を明確にしながら,オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ,オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお,オブジェクト指向プログラミング,デザインパターン,分析/設計といった個々の技術については特集2以降でそれぞれ解説

    オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない!:selfup
  • 必修講座100 < ITpro SkillUP : ITpro

    ITエンジニア必修講座100は,ITpro会員の皆様向けにお届けしています。 講座の全文をお読みいただくためには,無料のITpro会員登録が必要です。

  • 制約理論を読みほどく ― @IT

    今回は前回「セル生産方式+アジャイルという枠組み」のセル生産方式+アジャイルに続いて、制約理論+アジャイルという枠組みを考えてみる。参考にしながら読むのは以下の書籍だ。ただし制約理論に関してはこれ(「ザ・ゴール」)は代表的な1冊にすぎず、さまざまなトピックに関して多くの書籍が出版されている。 今回参考にするのは以下の3冊である。 「アジャイルソフトウェアマネジメント」(David J. Anderson(著)、宗雅彦(翻訳)、前田卓雄(翻訳)、日刊工業新聞社)(残念ながら原著のせいか、翻訳のせいか、はたまた読者たる筆者の能力不足のせいか、解読には若干の困難を伴う) 「ザ・ゴール――企業の究極の目的とは何か」(エリヤフ・ゴールドラット(著)、三木亮(翻訳)、ダイヤモンド社) 「目標を突破する実践プロジェクトマネジメント」(岸良裕司(著)、中経出版) 筆者は制約理論の専門家ではないので、記述

  • ソフトウェアの仕様書は料理のレシピに似てる(大阪弁バージョン):中島聡・ネット時代のデジタルライフスタイル - CNET Japan

    先日、経済産業省向けの仕事をしとる知り合いと事をしたのやけど、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月30万円ちうケースもあるちうわ。 こないな話を聞くとホンマに悲しくなる。まず第一に「プログラムを書く」ちう仕事は簡単な仕事ではおまへん。数学的な頭を持っておらへんとかなり辛いし、基礎がしっかりと出来ておらへんとろくなソフトウェアは作れへん。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日で一人月30万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしておるから給料が安い」ちう説明を聞いたこ

  • Rubyを仕事に使うべし! Part1 なぜ仕事で使うとうれしいのか:ITpro

    プログラミング言語Rubyが注目を集めています。Ruby関連の書籍が次々と出版され,2006年6月には国内初の大規模Rubyイベントである「日Rubyカンファレンス2006」が催されました。また,Rubyで書かれたWebアプリケーション・フレームワークRuby on Rails(以下Rails)が話題となり,Rubyの高い生産性が一般に知られるようになってきました。 Rubyの生産性はJavaの10倍とさえいわれます。なぜRubyは生産性が高いのでしょうか。それは,Rubyはいろいろな言語から優れた所を集めた「いいとこ取り」言語だからです。Rubyの特徴は「構文が強力なので,迅速な開発ができる」「人に優しい言語なので,楽しくプログラミングできる*1」「問題が起こりにくいように設計されているので,初心者でも簡単に安全に作業でき,熟練者は高度なプログラミングを行える」といった点です これらの

    Rubyを仕事に使うべし! Part1 なぜ仕事で使うとうれしいのか:ITpro
  • 「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ

    JTBの元取締役CIO(最高情報責任者)の方が、ITシステム開発が設備への投資であるかのような前提で書いていますが、この前提は間違っていると思います。 ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。 たとえば、新しいビジネスを実現するための、新しい店舗オペレーションや配送システムの開発は、ソフトウェアシステムの開発そのものです。 あたらしいビジネスを立ち上げるために、設計すべきものは、たとえば: ●迅速で高品質な状況対応を可能とする意思決定メカニズムの設計。 ●現場で柔軟な対応が出来、かつ、従業員の士気があがるような、責任・権限メカニズムと、それと連動した人事評価・報酬システムの設計。 ●現実的に調達可能な人材と、十分な投資効果の見込める従業員教育

    「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ
  • 真髄を語る 経営者がITを理解できない本当の理由

    佐藤正史 氏 JTB情報システム 代表取締役社長 当サイトにおいて、企業情報システムにかかわってきたベテランが引退する、いわゆる「2007年問題」について色々な議論がされております。私は1971年にJTBに入社して以来、ほぼ一貫して情報システムの仕事に従事してきました。私が情報システムに関係してきた期間は、日における約40年の企業情報システムの歴史と概ね重なっております。 2001年から取締役(情報システム担当)として、CIO(最高情報責任者)の仕事をし、現在はJTBの情報システム関連会社の社長を務めています。おそらく、あと数年で2007年問題の一方の主役として、この舞台を去ることになるでしょう。まもなく企業人生を終えようとする一介のシステム屋ではありますが、ぜひとも多くの方に申し上げたいことがあり、この場を借りて思うところを綴ってみます。 私は今、日ITを巡る状況に大変な危機感

  • ITPro: 基本設計におけるレビューの勘どころ

    どんなに基設計をしっかりやっても,その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し,進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「考慮していない外部システムとの連携が詳細設計で見つかった」,「仕様間の不整合が実装フェーズで発見された」――。どんなに基設計をしっかりやっても,その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し,進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが,基設計の成果物の品質を向上させるプロセスは,(1)設計作業を実施する,(2)成果物をレビューして欠陥を洗い出す,(

    ITPro: 基本設計におけるレビューの勘どころ
  • 【上級】失敗プロジェクトの共通項 第5回

    想定プロジェクトでは,多くのサーバーやミドルウエアが使われる。OS,Web/APサーバー,データベース,負荷分散装置などだ。プロジェクト内にこれらの製品のうちひとつでも利用経験者がいなければ,スケジュールは見直しを迫られる可能性が高い。使用方法を取得するのに多くの時間を要するからだ。多くの残業,休日出勤を招くことになり,納期にも影響を及ぼす。 スキルマップの整備が不可欠 プロジェクト技術者をうまくマッチングするには,社内での分野別スキル保有者リストが欲しい。スキル保有者がいなければ,社内からの協力を仰ぐといった運用が可能になる。 スキル評価の方法は,一般的には大分類から小分類へツリー構造で細分化していくのが使いやすい(図7)。 大分類としては「技術」「業務知識」「マネジメント」の3つが標準。技術なら「ハード」「ネットワーク」「OS」「開発言語」など中分類に分け,さらに開発言語なら「Jav

    【上級】失敗プロジェクトの共通項 第5回
  • 学校では教えてくれないエンジニアリング英語 #1: blog.bulknews.net

    学校では教えてくれないエンジニアリング英語 #1 ソフトウェアエンジニアリングの現場で使うような英語って、たまにクセがあったりしてわかりにくかったりすることってありますよね。年に半分程度US出張も含めて外資系で1年半やってきた経験から、エンジニアの日常会話で使う英語を解説していくシリーズを不定期連載してみようかとおもいました。 よく海外在住の日人ブロガーの方が同じような企画やってますが、エンジニアリングに直結したのは少ないかなとおもったので。あと当然ですが、僕はネイティブじゃなく、業務やら日常会話やらで覚えてきた内容をもとに書いているので間違いがあれば指摘は歓迎です。 第1回の今日は、記号の読み方。最初、結構とまどったんですよね。 "-" "-" をなんと読むか。日人だとハイフンが多いでしょうか。アメリカ英語では、"dash (ダッシュ)" と読みます。"minus (マイナス)" で

  • 第11回 プログラマが知らない,デザイナーの苦労

    今回は,デザイナーとして,世間やプログラマに対して言いたい放題書かせてもらう。どうか怒らずに最後まで読んでもらいたい。デザイナーの皆さんには,大いに賛同していただける内容になっているはずだ。 デザイナーだって,タイヘンなんだ! まず,デザイナーという仕事は,非常に誤解されやすい。例えば次のような誤解をうけて,暗い気持ちで日々の作業をこなしているデザイナーも少なからずいるはずだ。 1) デザイナーという職種に対する,先入観がある 世間(顧客やエンドユーザー)には,「すべてのデザイナー」=「技術に無知」だという先入観がある。「デザイナー」とは「Webページの配色とレイアウトをする人」だから技術を知らなくて当然,むしろ知らなくてよいとする傾向すらある。開発ツールが完全分業に向けて進化しているのだから,デザイナーはビジュアル・デザインのことだけ考えていればいいという意見を持っている人もいるだろう。

    第11回 プログラマが知らない,デザイナーの苦労
  • ウノウラボ Unoh Labs: 共同開発を効率よく行う方法

    尾藤正人です。 ウノウではおかげさまで順調にエンジニアの数が増えてきました。エンジニアが増えてくると、共同開発をいかに効率よく行うかが問題になってきます。n人の開発者がいれば開発スピードはn倍にはならず、n倍よりも落ちます。人数が多ければ多いほど、共同開発は難しくなり、ひどい場合には人数が増えたから開発スピードが落ちたということになりかねません。 ウノウでは共同開発を効率よく行うために様々な工夫を用いています。今回はウノウでどのようなステップで開発を行っているか紹介したいと思います。 subversion でソースコードを管理 ソースコード管理ソフトがなくては話になりません。ウノウではソースコードの管理に subversion を使ってます。subversion を使うことで過去の状態に簡単に戻すことができますし、個人の環境を完全に分離することができます。 subversion のコミット

    ytesaki
    ytesaki 2006/08/24
    そろそろsvn普及活動しようかなぁ
  • 増井俊之 (Toshiyuki Masui)

    ▼増井俊之 Wiki Wired POBox 富豪的PG 研究テーマ ▶ブログ/書評 ▶雑誌記事 ▶論文 ▶著書/訳書 ▶講演/講義 ▶Webサービス ▶システム ▶雑情報 ▶アイデア ▶インタビュー ▶趣味/パズル ▶旅行/写真 ▶意見/感想 ▶連絡先 ▶検索

  • Google Code Jam

    Put your coding skills to the test as you work your way through multiple rounds of algorithmic coding puzzles for the title of Code Jam Champ and 15,000 USD.

    Google Code Jam
  • IMJモバイル(アイエムジェイモバイル)CTO blog:システム構築の7W4H