サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
見積りとは何か | プログラマが知るべき97のこと
見積りとは何か著者: Giovanni Asproni 自分の担当業務に関して見積りを行い、見積り結果をマネージャや同僚、ユーザなどに伝えるのはプログラマの義務です。彼らはその見積り結果を踏まえ、目標達成のために時間やお金、機器等のリソースがどのくらい必要かを判断します。見積りが正確でなければ正しい判断はできません。 正しい見積りをするためには、当然のことながら、そのための方法を学ぶ必要があります。しかし、それよりも先にまず知らなくてはならないのは「見積りとは何か」そして「見積り結果はどう利用すべきか」というごく基本的なことです。実に不思議なのですが、プログラマやマネージャの中に、この2つを正しく理解している人はさほど多くないのです。 それは、たとえばプロジェクトマネージャ(PM)とプログラマの間で、次のような会話が交わされることが決して珍しくないということからもわかります。 PM「機能x
ゲームクリエイターが知るべき97のこと
ゲームクリエイターが知るべき97のこと大人気の書籍『ゲームクリエイターが知るべき97のこと』のエッセイを無料で公開中！すべてのゲームクリエイターにおすすめの本がウェブで読めるようになりました。 エッセイ一覧「勝手にテコ入れゲーム企画」を考えよう！誰でもできることから始めるプログラマの「ゲーム作り」への情熱ゲームクリエイターは何でもできた方がいい君は反省し続ける事ができるか？お宝と燃料を同時に手に入れよう！私たちは誰のためにゲームを作っているかピグライフをつくるときに考えたことムダなムダを徹底的に切り捨てる面白さには旬がある理論を軽視しないこと限られたリソースの中で～サーバ運用の現場から～神は細部に宿りたまう面白くならなくてもいいから、短時間で作ってみようゲーム創りを楽しむための3つのポイント多様化するアニメーターの役割明日を創るゲームテクノロジーへの挑戦運命のドアチケット駆動開発と自動化テ
「第1回 プログラマのための数学勉強会」開催しました！（動画＆資料つき） - 34歳からの数学博士
どうも、佐野です。 昨日「第1回 プログラマのための数学勉強会」を開催しました。朝からの大雪にも関わらず多くの方にお集り頂き、濃厚なセッションの数々をお送りすることができて大変嬉しく思っております。 以下、各セッションを動画・資料と共に、簡単に内容のご紹介をさせて頂きます。 1. 「プログラマのための線形代数再入門」 - 佐野岳人 [資料] トップバッターとして発表させて頂きました。線形代数は3Dプログラミングをはじめ、画像処理や機械学習など多くの分野で必要になる数学の分野です。「行列の積はなぜこんな複雑な形をしているのか？」から「行列は線形変換・アフィン変換の定量表現である」という話をしました。 次回は中編として「行列式・逆行列とその実装」、後編で「座標変換と固有値・固有ベクトル」を発表してみたいと思います。 2. 「明日話したくなる「素数」のお話」 - 辻順平 [資料] 日曜数学者 i
ゲームプログラマーという職業はもうありません。 - teruyastarはかく語りき
暴言なのは分かってますが、 学生の頃ゲームプログラマーを目指した昔の僕に そのまま言ってやりたいセリフ。 こんな記事を見つけたので。 プログラマ、ＳＥ、ゲームプログラマについて - Yahoo!知恵袋 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1438427284 自分は将来、プログラマ、いずれはＳＥになりたいと考えていましたが、 最近では３Ｄも学んで、ゲームも作ってみたいと思うようになりました。 長時間労働、低賃金といわれていますが、やってみたいんです。 そこで、本題なんですが、 上記の仕事で働くには、今、どんなことをすればいいんでしょうか。 プログラマとして、働けるのは短いとか、 ゲーム業界は就職倍率高いとかは分かっています。 自分がやりたいのは、ＢＧＭとかグラフィックではなくて、 企画、制作、プログラムという部門
なぜプログラマを難問奇問・一風変わったテストなどで雇ってはいけないのか？
By Iron Man Records 「なぜ我々はプログラマを難問・APIクイズ・不可解な演算・その他の面接トリックで雇わないのか？」というタイトルで「Ruby on Rails」「Basecamp」など、積極的にウェブ上の開発を行っている人々の間では一度は聞いたことがある小企業「37signals」が自身のブログ上でエントリーを出しており、その中身が非常に考えさせられる内容となっています。 Why we don't hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks - (37signals) http://37signals.com/svn/posts/3071-why-we-dont-hire-programmers-based-on-puzzles-api-qui
そして何が残る？ - mooz deceives you
長い間，ぼくは選択肢の多さに悩まされてきた．いや，惑わされてきた，と言った方が適切かもしれない．そして，最近ではそんな選択肢の多さに憎しみすら抱くようになった．以下は，とりとめもなくつづられた，そうした選択肢に対する呪詛の言葉だ． あまりに多い選択肢はプログラマを悩ませる 良く言われることに「あまりに多い選択肢は消費者を悩ませる」というものがある．イヤホンを新調する時のことを考えてみよう．あなたは電気屋へ車を走らせ，イヤホンコーナーへと向かう．すると，そこにはずらりと並んだイヤホンがあなたを待ち受けているのだ． 「一体全体，どれを選んだら良いのだろう」 あなたは途方にくれることとなる． ぼくの中に，ここ半年ほどもやもやと渦巻いていた考えがある．これをどう表現したものかと思っていたのだが，つい先ほど，冒頭の文での「消費者」という単語を「プログラマ」という単語で置きかえることで，すっきりと表現
プログラマならいつかは読んでおきたい(と言っておけばかっこいい)本10冊 - 2010-11-26 - きしだのはてな
昨日の技術力をあげたいプログラマが読んでおかないと話にならない本10冊は本自体にはあまり意味がなくでその技術分野が大事で、あとエントリーレベルのものが多かったので、今日は読み甲斐のある本を。 本棚に飾っておくとかっこいい本です。あと、本屋でまとめて買って持って帰れるなら、値段的にも重さ的にも、尊敬します。 ぼくが持ってない本や持っててもほとんど読んでない本がかなり含まれてます。「この人こんな本も読んでるんだー」などと無用に尊敬したらダメですよ。むしろ、そのように誤解させて尊敬させるための本です。 アルゴリズムデザイン 作者:Jon Kleinberg,Eva Tardos共立出版Amazon読んで面白いし、アルゴリズムカタログじゃなくて設計方法の解説が多いので、とてもいい本です。途中までは読んでるので続きを読まねば。 あとアルゴリズムの本としてはアルゴリズムイントロダクションが定番ですが、
なぜ優秀なプログラマは人を雇わないか - 人生を書き換える者すらいた。
僕の知っている範囲だと、優秀なプログラマはフリーランスか小規模な法人のオーナー社長であることが多い。人を雇っている場合でも、ほんの数人である。もちろん僕もその一人。そりゃまあGoogleやMicrosoftの本社には凄いプログラマもいるだろうけど、日本人だと本当に一匹狼系の人が多い。 僕もフルタイムの従業員を雇って１年以上経ち、人を雇うと何が起きるのかについてけっこう分かってきた。なので、なぜこのようになるのかについて考えてみた。 なんと金銭的な面「だけ」でも、合理的な理由をつけることができる。僕を含めた何人かを平均したモデルで例を出してみよう。すごく単純化しているけれど。 いま一人の優秀なプログラマがいて、平均的な会社でサラリーマンとして働いても年俸1000万取れる実力があるとしよう。この人が独立した場合、「好きなプロジェクトを選べるのでやる気が出る」「独立していることについてのリスクプ
こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい
プログラマはプログラミングをしていないという現実
フロリダのRubyプログラマのSteve Clayさんがブログに投稿した「プログラマーはプログラミングをしている、はずが実際はそうでもない」という記事が話題になっていました。 神話：プログラマは一日中、プログラムを書いている。 現実：多くのプログラマは下記の事に多くの時間を費やしている。（順不同） 外部のプログラマーのMLへのメールやテックでない人へのメールを用心深く書く ミーティングに参加、モックアップやDBスキーマの作成、要求された機能へのパフォーマンスの心配 バグレポートを書く、過去のバグを検索 複雑なシステムの障害の原因を何ギガもあるログを探索して調べる ダウンタイムについてユーザーや上司への説明 他人の問題の解決へ協力 ドキュメント、本、ブログ、リリースノート、脆弱性アナウンスを読む 必要な既存の名前の分からないようなコードを探す 見つかったコードが自分の環境に互換性がありライセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラマと付き合う
not found
TechCrunch | Startup and Technology News
not found