友人が、物凄く絵が上手いんだけどさ。 でも最初は下手だったんだよね。たいしてうまくない自分より下手だった。 でも急激に成長してる。今はもうホントに上手い。絵で仕事もしてる。 2chのスレでもよくある、「上手い人見て凹んで描けなくなった」とかいうやつ。自分も上手い作家さんとか見たりするとああいう気持ちになったり、年下なのに上手いのとか見るとホントへ込むんだけど、どうやら友人はそういうのが無いっぽい。前その辺語ってて判明した。 「できない」って思わないみたい。なんか。 すごい人見ると、即座に「そうなるにはどうすればいいか」「自分に何を+すればそうなれるか」「そして+する方法は何か」を考えてる。 だからすごい人を見たほうがモチベーションとか上がる。みたい。 目標が目に見えて分かるから寧ろ嬉しいらしい。 年下で上手いとか見ても、考え方が根本から違う。自分は「年下でこんなに上手いとかマジ死ぬwwww
私たちは映像・ICT技術の進化を通じ、世の中のデジタルイノベーションに貢献します。 常に技術進化を捉え、開発から運用まで課題に合せたあらゆるソリューションをご提供し、お客様のハイエンドなデジタルコンテンツ制作をサポートいたします。 We contribute to digital innovation through advances in video technology and ICT. We are always at the forefront of technological evolution, providing solutions that solve issues in everything from development to operation, creating high-end digital content creation environments.
2011年02月02日18:00 カテゴリArt プログラミングいつまでに学ぶ?なぜ学ぶ? どちらもFAQ中のFAQなのだけど、いい機会なのでまとめて。 いつまでに学ぶ? 30位からだと流石に遅いですか?RT @dankogai: 何歳でも間に合います。むしろ「問題」を知っている分、後の方が有利な面すらある< @ryopon_jp: @dankogai 大学入って18からでもプログラミング間に合いますか?大学の勉強は卒なくこなし、英語とプログラミンless than a minute ago via Echofon金子豊 yyyutaka 私の答えは、こう。 ゲーテは70代で恋をしたというのにおまえらときたらたかがプログラミングで自分の年齢を気にするのか?> @yyyutaka: 30位からだと流石に遅いですか?less than a minute ago via HootSuiteDan
************************************************* このCIA★こちら映画中央情報局ですは、2017年4月1日に、コチラの CIA Movie News に移転しました!! ************************************************* 「バットマン・ビギンズ」(2005年)では、ケンさんの出番が少なすぎた…!!という反省から、ケン・ワタナベを「インセプション」(2010年)に起用したクリス・ノーラン監督は、「インセプション」ではゴードンの出番が少なすぎた…!!と、また反省したのかもしれませんね…!! 大ヒットSFパズラー「インセプション」で印象に残るシーンのひとつとして、必ず話題にあげられる無重力バトルを見事に闘ってみせた RegularJOE こと、(500)日のジョゼフ・ゴードン=レヴィットが、気に入
鬼無(きなし)は高松市北西部にある一地区で、高松市役所鬼無出張所の管内。鬼無町藤井、鬼無町是竹、鬼無町佐料、鬼無町佐藤、鬼無町山口、鬼無町鬼無の6町からなる。かつては全域が「香川郡上笠居村」(かみかさいむら)として存在し、1956年9月30日に高松市に編入された。 地区は高松市北西部に位置し、五色台と峰山と呼ばれる石清尾山塊に挟まれた内陸にある。人口は2010年時点で6033人(男2908人/女3125人)で、世帯数は2402世帯である[1]。面積は6.98km2[2]と高松市内の地区では平均的な広さで、人口密度は858.17人/km2で平均より低い。高松市中心部のベッドタウンとしての性格がある。 全域が高松平野の一部であるが、地区の北西側には標高364mの勝賀山が存在しており、かつて「勝賀城」が存在したことなどから地区のシンボル的な存在となっている。さらにその勝賀山は五色台へと連なってお
モバイルバッテリーとは呼べない。「ほぼポタ電」なコレ1台で有事の時もアウトドアも大活躍!【AmazonスマイルSALE】
自動車メーカーのスバルとアニメーション制作会社のガイナックスによるアニメプロジェクト「SUBARU × GAINAX Animation Project」の第1弾作品「放課後のプレアデス」が配信開始となりました。 作品は全4話、トータルで25分。YouTubeでの配信なので、ちょっとした時間に見る事ができるようになっています。 詳細は以下から。 SUBARU × GAINAX Animation Project http://sbr-gx.jp/ YouTube - 放課後のプレアデス 第1夜 YouTube - 放課後のプレアデス 第2夜 YouTube - 放課後のプレアデス 第3夜 YouTube - 放課後のプレアデス 第4夜 YouTubeでこうして新作アニメが公開されるというのはなかなか画期的。このような試みがどんどん広がると、アニメの地方格差もなくなって、全国のアニメファンが
新しい知識を身につけたいとき、どんな方法を用いていますか? ひたすら読む、メモにまとめるなど、様々なアプローチが考えられますが、自分の理解度合いをテストするのも有効な手立てだそうです。 米紙「ニューヨーク・タイムズ」では、科学雑誌「Science」でも公開された、米パーデュー大学(Purdue University)の心理学教授による、最近の研究結果を紹介しています。 この研究では、200人の大学生を対象に、筋肉組織といった、事前に知識のない科学分野に関するマテリアルの一部を与え、5分間読ませました。その後あるグループには、5分間のセッションを4回与えてマテリアルを読ませた一方、もうひとつのグループは、関連する事項を書き出して線でつなぎ、情報をマッピングさせてみたとか。そして、さらに別のグループには、覚えていることを10分間でエッセイにまとめるテストを実施。その後、マテリアルを読み直して、
2011年02月01日13:00 カテゴリ書評/画評/品評 Amazonアソシエイト決算2011.01 寒い… 冷え込みMaxですが、先月同様、今月もAmazonアソシエイト決算をおとどけします。 今年は何とかできました 毎年一月はどうも私の体調の底のようで、去年は2月との合算という形にしたのですが、今年は何とか単月での発表にこぎつけています。とはいうものの、記事数もいつもより少なめ。体調もさることながら実際忙しかったというのも理由です。 しかし年期というのはすごいもので、こういう時はこういう時でロングセラーが確実に売れてくれます。私は結構twitterなどで過去記事に言及することも多いのですが、こうした場合、本は文章(text)ではなく文脈(context)として機能します。ロングセラー化するかどうかは、「ソーシャル文脈化」するかどうかかも知れません。 文章ではなく文脈として自分の記事を
亨通光电结合“中国制造2025”及“互联网+”实施规划�������,全面开展 “工厂智能化�������、管理信息化�������、制造精益化”�������的三化融合智能企业建设�������。
[ その後の彼の人生を知っている我々だからこそ、この若書きといってもいい「人生のルール」がまばゆいですね。 このルールを紹介している The Happiness Project の元記事でも、「彼は幸せについてあまりにたくさんのことを書き、そして自分で立てた誓いを自分であまりにも破った人物だからこそ、その人生には魅せられる」と書かれています。 早く目覚めること(朝の5時) 早く床につくこと(夜の9時から10時) 飽食を避け、甘い物も避けること 目標をもつこと。人生全体の、人生のある段階の、そしてさらに短い段階と、一年、一ヶ月、一週間、一日の、毎時間の、毎分のそれを。そして程度の低い目標をより高い目標のために犠牲にする 女性を避ける 欲望は仕事で打ち消す 善良であれ。できれば誰にもそれを悟らせないように。 身の丈に対して倹約して生活するようにする たとえ十倍裕福になったとしても、生活のスタイ
組み込みソフトウェア/ハードウェア開発における技術力の向上、改善・最適化などを幅広く支援する“組み込み開発エキスパート”のための情報フォーラム
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」(Empirical Software Engineering、実証的ソフトウェア工学)です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は? マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer(の上司)の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL(の初期の)時代ならまだしも、少なくとも現在の開発環境にお
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
ソースコードリーディングワークショップ ハンズオン,オンラインハンズオン結果中間報告 1 (2010/11/8) 当ページはハンズオンにご協力いただいた方向けのハンズオン結果の報告ページです.当ハンズオンへの御協力,誠にありがとうございました. 当ページは,これまでに結果を送付いただいた方の結果を元にした分析結果を報告するものです. 当ページはソースコードリーディングワークショップ2010(共催 日本IBM、メディア協賛 @IT), オンラインハンズオン, ソースコードリーディングワークショップ in デブサミ2010(協力 日本IBM), その他ご協力企業の皆様により,実際にソースコードを読解いただき,その読解時間を計測したものです. ハンズオンの趣旨と流れ ハンズオンでは,保守・派生開発プロジェクトを模した形式でソースコードの読解を行って頂きました.既存システムにあたるバージョン1ソ
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与:奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月~11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守/派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
自分がC/C++で飯を食っていた 2001年ごろに某ゲーム機メーカでお手伝いすることなり、現場にいた外注メンバーもできる人ばかり。その同僚からデザインパターンとかって耳慣れない話を聞く。コンボジットとか、デコレータ作ってみましたとかいってるw 意味わかんねーよ的な迷い子w 帰宅後必死に調べる。そして、GoF本がしばらくバイブルとなり典型的なパターン厨となる。 新たな気づきとしては、オブジェクト指向言語の実装機能(カプセル化、継承、多態)を理解した程度では、複雑な要件を実装していくことは困難だと体感した。何が必要かというと、デザインパターンなどを加味した上でのオブジェクト指向設計の力。 設計と実装の両面での考え方が必要 実装力というのは、クラスのAPIをどのように使いこなすかであって、設計力というのはクラスの構造や関連をどのように構成するかを決める能力だと思っている。設計は戦略であり、実装は
食事を抜く、おざなりにする 朝食、昼食、夕食を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず食事をとること。食事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな?とあれもこれもと手を出すうちに2,3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか?QAやテストやドキュメントなどはいりませんか?誰に承認をえるのですか?これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。本当に足りないことはあ
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしている エンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への
プログラマが知るべきじゃない97のこと - Togetter を読んでいたら面白かったので,赤文字で強調されているものを抜き出して適当に並べ替えてみましたw ちなみに,元ネタは プログラマが知るべき97のこと です.類似ネタの プログラマの嫁が知るべき97のこと,プログラマが体験するべきではない50のこと も併せてどうぞ. サーバ室に祀られた盛り塩の存在意義 言語やエディタ、IDE を disる と勃発する聖戦 VSS Boost プリプロセッサ PHP brainf*ck Lisper の態度 他言語のプログラマの Lisp へのイメージ 人月計算 エクセル方眼紙 受注確定と同時に赤字が確定していた 受注時に営業が顧客に提出した資料 見積書に勝手に足された項目の意味 この仕様が誰の気分で決まったのか 今必死で実装しているその機能が実は PM の好みで追加された仕様であること 依頼されたア
あなたは以下の条件に従う場合に限り、自由に 共有 – 本作品を複製、頒布、展示、実演できます。 再構成 – 二次的著作物を作成できます。 あなたの従うべき条件は以下の通りです。 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。
先日のコメント欄より. JavaBlackさんすごくマッチョでカッコイイです…… http://d.hatena.ne.jp/JavaBlack/20101128/p1#c マッチョかなあ?どちらかというと頭脳派だと思うんだけど. それで思いだしたのがこの話.日本のIT業界は,今でもあまり変わってないね. 少しは、本や雑誌を読んだり、インターネットやパソコンネットなどを利用して情報を引き出したりすれば良いと思うのだが、初心者はどうもそういう方向へは行かないらしい。基礎もできぬ前から、作る決意だけが先行してしまう。*1もちろん、そういうふうにして作られたプログラムの品質は無茶苦茶に決まっている。 スポーツの世界、とくに伝統的スポーツでは「精神」が大切にされる。しかし、そういう世界では、実際に試合をする前に、延々と訓練をさせられる。スポーツでは、突然試合を行なったりすれば、怪我をするのは当り前
Technical debt最初のコードを出荷することは、借金をしに行くことと同じである。 小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは借金の利息としてとらえることができる。技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。 ウォード・カニンガムさんどういうこと?技術的負債とは、コードにおける「修正しにくい」「理解しにくい」といった、問題のある部分のことです*1。負債は、すぐに返済すれば、大きな問題にはなりません。しかし、長期間そのままにしておくと、利息が雪だるま式に膨らみ、もはや返済が不能なまでになってしまいます。技術的負債も同様です。問題のあるコードも、直ちに修正していけば大きな問題にはなりません。しかし、放っておくと、最終
Googleブックスの騒ぎを知って約1年。気づくと今そこには「読んでみたかった!」という本が数多く載せられていることを知りました。 さて、そこでゲーム開発にも応用できる知識を中心に私がチョイスしたのが以下の本たちです。もちろんGoogleブックスではこれら以外にもまだまだ多くの本を閲覧することができます。これらを読めば、本には本当に知識と情報がまとめられているということ、著者たちの努力を発見できると思います。 ゲームデザイン 「おもしろい」のゲームデザイン: 楽しいゲームを作る理論 シリアスゲーム デジタルゲーム学習: シリアスゲーム導入・実践ガイド ユーザビリティエンジニアリング原論: ユーザーのためのインタフェースデザイン 人はなぜ形のないものを買うのか: 仮想世界のビジネスモデル ゲーム理論の基本と考え方がよ〜くわかる本 ノベルゲームのシナリオ作成奥義 ライトノベル創作教室 すごい人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く