ウェブ開発ブームの終焉 | OSDN Magazine
読者の皆さんもご存じの通り、アメリカにおける昨年の金融危機に端を発して、世界は空前の大不況に突入しつつある。今後もそれなりに成長が見込めるということもあってか、IT産業の求人・雇用状況は製造業などの他業種と比べれば状況はややマシのようだが、それでも予断を許さないのは確かだ。首筋が寒くなってきた方もおられるだろう。 ITスキルの需要変化 ところで、調査会社Foote Partners LLCが最近出した発表によると、市場におけるITスキルへの需要に興味深いトレンドの変化が見られるらしい。というのは、プロジェクトマネジメントやITアーキテクチャといった分野のITスキルへの需要が増加傾向あるいは堅調なのに対し、ウェブ開発に関連したスキルへの需要はここ2年で減少傾向にあるらしいのである(Internet Evolutionの記事)。といっても、アンケート調査の対象はアメリカとカナダの1960社に勤
ジョー・マラスコ氏「21世紀のソフトウェア開発管理」セミナー報告 講演概要編｜オブジェクトの広場
［技術講座］ ジョー・マラスコ氏 「 21 世紀のソフトウェア開発管理」セミナー報告 講演概要編 ( 株 ) オージス総研 藤井拓 オブジェクトの広場 9 月号で「新・ソフトウェア開発の神話」[1]という書籍の紹介を行いましたが、その書籍の著者であるジョー・マラスコさんのセミナーを TPS ソフトウェア研究会様主催で 10/1 に名古屋、S-open 様主催で 10/2 に東京で開催しました。本記事では、そのセミナーで行ったマラスコさんの講演の概要と講演後の質疑の内容を 2, 3 回に渡って簡単に紹介したいと思います。 第 1 部 講演の概要 私は、大学で理系の教育を受け、物理学の研究者として道からソフトウェア開発の分野に移り、30 年間以上に渡りソフトウェア開発に関わる仕事を行ってきた。そのソフトウェア開発の仕事の中では、プログラマー、プロジェクトマネージャー、経営者を経験してきた。私が
2008年、ウェブのデザイナー・開発者がおさえておきたいリソース集 | コリス
2008年、ウェブのデザイナー・開発者がおさえておきたいデザイン、Photoshop&Illustratorのチュートリアル、ブラシやベクター素材、JavaScript、CSS、WordPress、タイポグラフィ、フォント、素材、リソースなどをnoupeのエントリーから紹介します。 2008 Most Popular Design posts, Tutorials and Resources デザイン関連 Photoshopのチュートリアル関連 Illustratorのチュートリアル関連 Photoshop&Illustratorのブラシやベクター素材 JavaScript関連 WordPress関連 CSS関連 フォント&タイポグラフィ関連 ツール&素材関連 デザイン関連 42 Awesome Business Card Designs 20 Beautiful HDR Pictures
The Best Cheat Sheets for Web Developers
Cheat sheet is a reference tool that provides simple, brief instructions for accomplishing a specific task. We have collated a set of best cheat sheets for web developers. It includes some of the popular programming language, e.g. jQuery, Mootools, Prototype, PHP, MySQL and etc… Please feel free to suggest some of the cheat sheets we did not mention. 1. jQuery Cheat Sheet 2. Mootools Cheat Sheet 3
livedoor ラボ「EDGE」 開発日誌 : 開発者募集中！「EDGE co.Lab」始動のお知らせ - livedoor Blog（ブログ）
EDGE担当の櫛井です、こんにちは。 ライブドアの持っている膨大なトラフィックやwebサービスにおける訴求力、今まで培ってきたノウハウで一般の開発者が抱える問題を一緒に解決していきたい！ そんな思いを抱き続けてきました。 念願かなって、このたび livedoorのラボサービスである「EDGE」の派生プロジェクトとして「EDGE co.Lab」をスタートすることとなりました。 さて、この「EDGE co.Lab」ですが 「せっかく面白いものを作ったのに、注目が集まらない」 「サーバが貧弱でいつもサイトが重い」 「一般層への宣伝ができない」 「サイト１つでは稼げない」 といった悩みを一般の開発者の方が持ち、結局はフェードアウトせざるを得ないという現状をふまえ、これらを打破し開発者を支援していくものとして位置づけております。 本サービスを通じ開発者の方は、livedoorを最大限有効利用し、さら
森崎修司の「どうやってはかるの？」 > 不毛な議論をなくすための仕組み 『大規模ソフトウェア開発を支えるGoogleのテクノロジー』から : ITmedia オルタナティブ・ブログ
講演をまとめたエントリ（ここ）のはてブが300超えそうだ。1時間半のプレゼンはあっという間に終わり、講演内容からはコミュニケーションオーバヘッドを減らすためのうまいしかけを端々に感じさせた。講演はGoogle工藤拓氏により奈良先端科学技術大学院大学情報科学研究科で行われた。 網羅的・キーワード中心の紹介は、はてなダイアリのほうにお任せするとして、ここでは大まかな話と私の印象をピックアップしたいと思う。ご講演はGoogleで実施されているプロセスや開発されたソフトウェアに関するものであり、以下の3つから構成されていた。 コードレビュー Protocol Buffersという通信用フレームワーク・ミドルウェア google-gflagsというコマンドライン引数解析のためのライブラリ いずれも大規模な開発における問題を解決するものであり、私の印象では、全てコミュニケーションオーバヘッドを減らす仕
ITゼネコンを倒す方法をみんなで考えよう - ひがやすを技術ブログ
クロスコミュニティカンファレンスの「ITゼネコンをぶっつぶせ」BOFですが、時間が参加しにくいという意見があったので、18:40分開始に変更しました。また、時間も90分に延長し、後半の4,50分は、会場の皆さんとのディスカッションにあてたいと思います。 ITゼネコンの問題点を指摘したい方、ITゼネコンを倒すアイディアがある方、是非、会場にお越しください。 http://www.java-users.jp/contents/events/ccc2008spring/sessions.html#BOF2 また、当日参加できない方でも、いろんな意見をお持ちの方がいらっしゃると思います。「はてぶ」や「はてだ」のコメントなり、トラックバックなりで、引き続きみんなで考えましょう。 「ISIDだってITゼネコンじゃん」と思う方もいらっしゃるでしょう。昔は、そんなこともありましたが、最近は違います。「丸投
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
Joelに聞く、「優れた開発者」の要件・心構え・努力すべきこと：CodeZine
世界的に認知されているソフトウェア開発プロセスのエキスパート。彼のWebサイトJoel on Softwareは、世界中のソフトウェア開発者に人気があり、30以上の言語に翻訳されている。ニューヨークにあるFog Creek Softwareを創業し、ソフトウェアチームのためのプロジェクトマネジメントシステムとして人気のあるFogBugzを作った。JoelはMicrosoftでExcelチームのメンバーとしてVBAをデザインし、Juno Online Servicesでは数百万人が使うインターネットクライアントを開発した。 優れた開発者の要件――まず、「優れた開発者にはどのようなことが求められるか」についてお聞かせください ああ、大変だ。それなら12箇条ありますね。(笑) まじめに答えると、見方が二つあって、ひとつは成功するチームを作る上で誰を選ぶかということです。私はそういうとき、頭がよく
新サービスを開発するときに気をつけてること : a++ My RSS 管理人ブログ
もう全然気合が足りないので、自分への戒めも含めて「新サービス開発」について思いつくままにメモ残します。 新サービスを開発するときには： コンセプト = メタファーを決める メタファーとは、「そのサービスって、つまり○○だよね」の○○に当てはまる具体的な言葉です。 どんなサービスでも「既存の言葉」に当てはめないと理解しにくいので。 「GPS機能で配送遅延から距離を感じられるオンラインメッセージングツール」じゃなくて「それって伝書鳩」みたいな。 これは知り合いに説明してみるとヒントが得られること多しです。 サービス名を決める ドメイン取るとかの理由もありますが、名前が決まっているかどうかで作業のはかどり方が全然違います。 アイデア ⇒ 開発 ⇒ 仕上げ の苦しみ度合いを理解しておく 実は開発する作業が一番楽です。厳しいのは仕上げ。途中で萎えないような工夫が必要だったりします。 時間をかけて悩ん
ウノウラボ Unoh Labs: ブラウザから使用できる仕様書を書くツールまとめ
こんにちはsatoです。Windows以外の環境で仕様書を書こうと思うと、なかなか良いアプリがなかったりまします。今回はブラウザから使用できる仕様書作成ツールをまとめてみました。 1) オンラインで配置図などを描く Gliffy 配置図などをオンラインで描くことができます。また 画像への出力なども対応しています。いわゆるVisioの代わりになるツールです。 2) pdfファイルをtextに変換する PDFTextOnline pdfをtextに変換することができます。pdfの内容をスクリプトなどで切り出して、データ化するときなどに役に立ちます。他にもいろいろな変換するサイトやツールがあるのですが、ここは日本語が正常に通って見た目通りに変換できます。 3) データベースのテーブル定義などを書く WWW SQL Designer オンラインでER図などが書けます。以前miyakeさんが紹介して
開発チームの姿とソフトウェアの姿は相似する － ＠IT
Web開発の現場ではウォーターフォール開発は死にかけている。Webの新しい技術やサービスを見ているとそう思う。ユーザーニーズに応じて製品、サービスをスピーディに開発、投入。要望に基づいて柔軟に機能を追加し、修正する。Googleが採ったベータ版サービスの提供と継続的な開発（完成は重視しない）という手法は、その象徴だ。 スピーディな開発を可能にする重要な要素はライトウェイト言語の採用だが、そればかりではない。RubyやPHPを採用していても硬直的な開発でユーザーニーズの変化についていけないケースは多い。 「開発チームの姿は、開発するソフトウェアの姿と同一」。米アドビ システムズのプラットフォーム事業部 シニアバイスプレジデント兼チーフソフトウェアアーキテクトのケビン・リンチ（Kevin Lynch）氏はこう語る。ソフトウェア開発が成功するかどうかは技術の問題ではなく、組織やコミュニケーション
10 Best Project Management Course: Price, Review, Rating [2024]
You are here: Home / Career Planning / 10 Best Project Management Course: Price, Review, Rating [2024] In this post, we are going to look at 10 Best Project Management Course with Price, Review, Rating in 2024. When I was working in an elearning company, many people used to ask me which is the best project management course, specifically to crack PMP®. While I was working there, I completed my PMP
![10 Best Project Management Course: Price, Review, Rating [2024]](https://cdn-ak-scissors.b.st-hatena.com/image/square/aeaedb88c52e3d3a491e5304a561780c258f8162/height=288;version=1;width=512/https%3A%2F%2Feasycowork.com%2Fwp-content%2Fuploads%2F2020%2F09%2F10-Best-Project-Management-Course.jpg)
ユメのチカラ: ソフトウェアの作り方を考える
「開発工程を別々に担当してはいけない」は思いのほか多数のブックマークを頂いた。コメントやブックマークを拝見しながらあれやこれや考えた。わたしの飛躍する思考というか雑な議論で辟易している方もいらっしゃるかとは思うがもう少しお付き合いいただければ幸いである。 わたしの経験は、このブログの読者の皆さんはご存知かもしれないが、ソフトウェア製品の開発経験に偏っている。米国系ハードウェアベンダーでコンパイラやRDBMS製品を開発していた。その後西海岸のソフトウェアベンダーに転職してそこでRDBMS製品の開発に従事した。そしてOSSの可能性を信じてミラクル・リナックスの設立に参加したのが約7年前である。顧客向けアプリケーション、例えば社内システム構築（人事、財務、購買などなど）の経験はない。 さて先の「開発工程を別々に担当してはいけない」ではいろいろな論点をごった煮風に突っ込んだものだから分かりにくくな
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
marsのメモ - 開発環境に関わるメモ
今月で今やってる仕事の契約が切れるので，ここで培ったノウハウなどをメモしておこうと思う。 しかし，今後この手の開発系の仕事ができるとは限らないってのが悲しいところ。 プロジェクトポータルまわり とりあえず，Subversion(SCM), Trac(ITS/Wiki), Hudson(CI)は必須。この３セットがないプロジェクトなんてうんこ。 とにかくTrac-Subversionの連携が強力なので，Subversion以外のSCMは無視していい。HudsonはCIつうよりプロジェクトダッシュボードとして使うのが吉（数あるプラグインを有効利用しよう）。 marsのメモ - Trac marsのメモ - MacroBazaar - The Trac Project marsのメモ - 角谷HTML化計画(2006-04-25) marsのメモ - trac-post-commit-hookが
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
ウノウラボ Unoh Labs: ベンチャー流Webサービスの作り方(開発チーム編)
尾藤正人(a.k.a BTO)です 前回はWebサービスを作るときの企画の部分について書きました (ベンチャー流Webサービスの作り方(企画編))。 今回はWebサービスを作るときの組織作りについて書いてみたいと思います。 僕がウノウに入って始めたのがフォト蔵の開発でした。 当初は開発が僕、ディレクションが代表の山田という二人体制でやってましたが、 組織が大きくなるにつれてだんだんと人数が増えていきました。 現在は僕も山田もフォト蔵からは離れて新しいチームで開発を行っています。 二人体制から始めて、少しずつ人数を増やしていって、 立ち上げメンバーが開発から離れるまでいろいろ経験しながら 自分が感じた事を簡単にまとめたいと思います。 ・最終決断は一人で 何をするのか、戦略はどうするのか、方向性は何なのか、最終的な決断はリーダーが一人で行います。 個人の主張を尊重しすぎて、各々が好きな事を始め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクトの進め方と各フェーズでの成果物についてまとめ
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist