以下のページでログインをお願いします。 [SSL(Secure Sockets Layer)プロトコルで入力いただいた内容を保護いたします] ■登録されているユーザーIDとパスワードをお忘れの方は,「日経BPパスポート」の「ユーザーID・パスワードのお問い合わせ」ページでご確認いただけます。 ■ITpro-News,ITpro-Reportなどのメール配信サービスをご利用の方も, Web上のコンテンツをご覧いただくためには,改めて登録をお願いいたします。
モバイルバッテリーとは呼べない。「ほぼポタ電」なコレ1台で有事の時もアウトドアも大活躍!【AmazonスマイルSALE】
ここ数カ月、ソフトウェア開発の話題で「かんばん」(英語でも「Kanban」)という言葉を目にする機会が増えてきました。かんばんとは何で、どのようなものなのでしょうか? 勉強がてら、いくつかのサイトを紹介していきましょう。 ビギナー向けの「Kanban101」 今年3月にかんばんビギナー向けのサイト「Kanban101」が立ち上がりました。このトップページがかんばんの特徴をよく表しています。 ソフトウェア開発におけるかんばんとは普通に日本語の「かんばん」のことで、誰でも見えるところに置かれて、ホワイトボードや黒板になっていて、記入したり、この画面のようにポストイットを貼って運用するのが一般的です。 かんばんの効果とは、このかんばんを模した画面に書かれているように「仕事のみえる化」「仕掛かりを減らす」「流れを見えるようにする」ということ。このサイトは英語ですが説明がとても簡潔で分かりやすいもの
まとめ 良い進捗報告とは、自分が行っている作業やプロジェクトを順調に進めるのに役立つ手助けが得られやすい報告である 教員にとって良い進捗報告 学生が行っている作業やプロジェクトが自分の研究のプロジェクトの一部であったり、研究室で取り組んでいるプロジェクトの場合とそうでない場合では教員にとって作業の進捗の意味がある程度変わる。前者の場合は、自分のプロジェクトの一環なので、作業やプロジェクトの進捗がそのまま自分のプロジェクトの進捗に反映されるので、より真剣に、場合によっては過剰に干渉して進捗状況を制御しようとする可能性がある。後者の場合は、学生が順調に卒業/修了できるかどうかが興味の焦点になるので、学生が援助を求めてきたならば援助しようという程度の干渉の可能性がある。ここいらへんは指導教員の性格による。 どちらの場合にしても、教員が知りたいのは「どこまで進んでいるか」と「援助は求められていない
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか? グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。彼らの考え方については、面接時に少しやり取りを行えばそれなりに見当が付くだろう。しかし、実際のプログラミング経験を推し量るのは至難の業だ。一部の企業では、さまざまなテストを実施することでこれを行おうとするものの、筆者の経験から言えば、こういったテストは近代的な開発環境では必要性が薄い知識(IDEのオートコンプリート機能や、F1キーの押下で表示されるヘルプ、インターネットといったものがあるため、ライブラリの知識は以前ほど重要ではなくなっている)の丸暗記能力を試すだけに終わることも多い。そこで本記事では、開発者を評価するうえ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか?」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル? システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
ダグラス・C. メリル, ジェイムズ・A. マーティン 早川書房 ( 2009-12 ) ISBN: 9784153200098 おすすめ度: 著者のメリルは現代を生きる我々が抱える課題をこのように表現しています。 p151 「日々、無数の情報が私たちのもとに押し寄せる中で、無視すべき情報、あとで使うためにデジタルや書面で保管すべき情報、脳に記憶すべき情報を、どのように見分ければよいのか」 まさにその通りです。情報は集めようと思えばいくらでも集められます。むしろ意図的に遮断しない限りありとあらゆる情報が私たちに向けて流れ込んできます。 そのような状況の中はで、「必要な情報はどれか」という判断を下す必要があります。そのような判断がなされなければ脳は即座にオーバーヒートしてしまうことでしょう。 メリルが実践してきた「えり分け」と「繰り返し」の原理を理解すれば、自分にあった整理術の構築に役立つか
最近よく耳にするようになった64bitと32bitのオペレーティングシステムのお話ですが、「きっと数字の多い方がいいんでっしゃろ?」という、大きいことは良いことだという哲学に基づく判断以外の部分で、この両者の違いが何なのかご存知ない方も実は多いのではないでしょうか。 あなたには64bitのWindowsが必要なのかどうなのか? そしてなぜ必要なのか、または、必要ないのかを説明してみたいと思います。32bitはすでに古いような気がしてしまう今日この頃、64bitのOSをインストールしているユーザの数は増える一方ですが、その2つの違いをちゃんと理解した上で64bitを選択しているユーザは少ないように思います。今回は64bitのOSにアップグレードした場合の利点(および欠点)を検証していきます(この記事はWindowsユーザを想定して書いています)。 4GBのRAMが本当に必要なのかについての過
1 :VIPがお送りします:2010/01/02(土) 01:25:41.74 ID:Ri+0XX8F0 とりあえず何でも答えます。面接、文化、無料ランチ、なんでもどーぞ。 (※以下、上記文字色が>>1さんのレスになります) 3 :VIPがお送りします:2010/01/02(土) 01:26:16.32 ID:6jqC+ovs0 金銭感覚と進学意欲をなくした天才なんだよね、俺 オープンソースコミュニティでハンドル有名になって、レジュメにそのハンドル書けばとりあえず面接には来れる。 4 :VIPがお送りします:2010/01/02(土) 01:26:34.16 ID:wQ6pgI0A0 無料ランチについて 日本のランチはオフィスで火を使えないため、ケータリングのビュッフェ形式。四半期に一回、寿司day がある。その時は板前さんがマグロさばくところからやってくれる。 ちなみに食堂の名前は「花の
やったことがないプロジェクトに取り組むときの大事なこと に関するライフレシピをご紹介します。nanapi [ナナピ]は、みんなで作る暮らしのレシピサイトです。はじめに サークルや友人とで楽しいイベントを企画する 会社で新規プロジェクトのメンバーになる 起業する お店を開く といった、やったことがない新しいプロジェクトに取り組まなければならない時があります。 ここではそんな「やったことがないプロジェクト」に取り組むときのコツを書いています。 やるからなにはできるだけ上手にやりたいですものね! 今回の内容は、主に「プロ野球チームを作る」というプロジェクトを実施した際の経験に基づいています。詳しくはnanapi内にある記事 誰でも簡単にできるプロ野球チームの作り方(新規編) に記載しましたが、プロ野球チームを作るというのは前例がほぼないため、書籍を参考にしたり経験者に教えていただくということ
こんにちは、kijimaです。先日深夜のスタジオでのドラム練習風景をUstreamで意味もなく生中継してみました。ええ、懲りずにまたやりますよ。 今回は、(特に大手クライアントの)受託案件で気をつけるべきポイントについてまとめてみました。 まんまと釣られた方、「そんなの当たり前じゃん」という方は、周りの新人さん(特に新人ディレクターとか)にも教えてあげてください。今回はFlashに限らず、制作現場みんなで気をつけていきたいポイントです。 制作規定・レギュレーションの有無について確認する今回紹介するポイントの中では、間違いなくこれが一番重要です。 ネット業界に限らず、誰もが知っている大手クライアントともなると、様々な部分にレギュレーションやルールが存在します。会社のロゴマーク表記に関するレギュレーションは特に細かく、たとえば「緑色のロゴマークに対して使っていい背景色は何色のみ」とか、「バナー
だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス
ブログでの告知がすっかり遅れてしまいましたが、マイコミジャーナルにて、ライフハックス心理学の佐々木正悟さんと対談連載を始めています。その名も「ライフハック・トーク」。 佐々木さんの「Google 世代の整理術『情報整理ハックス』」のあとを受ける形でスタートさせましたので、最初のあたりは「ライフハック」という感じよりは「情報整理」を主眼にした非常に濃い話から連載を始めています。二人の会話がある意味ブログ以上の濃さ! 連載第1回は「RSS の処理」という話題でした。日々大量の RSS を処理するのに1記事あたりの時間をおなじにして記事だけが増えたら当然読むためにかかる時間は長くなってしまいます。 でも「自分にとって面白いか」「今の自分が知りたいものか」という尺度で測れば、その判断は一瞬ですみますので、1記事あたりの時間を減らすことが可能になります。 ここにちょっとした勇気が必要になるのですが、
マネージャの仕事の中でも重要なものに、部下に適切に仕事を任せる、というものがある。英語では"delegating(権限の委譲)"という。仕事を丸投げしたり、介入しすぎたりしては部下も思い通りの仕事ができないことは容易に想像がつく。U.S.News & WORLD REPORTに「部下に仕事を任せる際の5つの間違い(原題: 5 Ways Managers Fail at Delegating)」という記事が載っているので紹介しよう。 1. 共通の認識を持たない 仕事が成功裏に終了した時のゴールは何かということを事前に部下と確認しなかったため、最後に出てきたものがあなたの期待したものと違っていたということはよく起こる。 2. 進捗管理をしない プロジェクトの最初に話をするだけで、計画通りに仕事が進む……なんてことはない! プロジェクトに関与し続け、チェックすることはマネージャの有効な武器だ。進
幸せ 平鍋: 1. 技術的な困難を達成。 2. お客様に感謝された。 最初は1だったけど最近は2。 まつもと: 理不尽な目に合わないこと。 思うようにツールが動かない→自分でつくる。 OSSは自分で手を入れられる。 平鍋: 自分一人の幸せじゃない。 プロジェクトが終わっても続く人間関係。 人のつながり。信頼。 まつもと: 通勤が3時間。理不尽→地方。 納得行かない変更が顧客から言われたくない 平鍋: エンジニアで不幸せな人へ。仕事は選べる。極端なこと言えば辞めればいい。 ワークライフ・バランス実現の戦略(例:地方に住むこと) 平鍋: 1995.子供を育てられるかを考えたときに自分の中での都会の価値がさがってきた。 田舎に帰ってから、世界のことを考えた。JUDE,アジャイルをやり始めた。 まつもと: 鳥取→つくば→島根 1997. OSSビジネスを始めようと声をかけてもらって島根へ。 理不尽
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く