ゲームエンジンや3Dソフトウェアを利用して高度な表現ができるこの時代でも、プリミティブな描画や動き、アルゴリズムから学べることは多い。それらをJavaScriptで書くクリエイティブコーディングという形で学べる手引書が本書となる。
ゲームエンジンや3Dソフトウェアを利用して高度な表現ができるこの時代でも、プリミティブな描画や動き、アルゴリズムから学べることは多い。それらをJavaScriptで書くクリエイティブコーディングという形で学べる手引書が本書となる。
セガは6月15日、社内勉強会で使った線形代数の教材を、公式ブログで無償公開した。ページ数は150以上。ゲーム開発に必要な3DCGの技術的基礎となる知識を学び直すために使ったものという。 2020年に行った社内勉強会向け教材の一部をPDF形式で公開。全8部構成で、ベクトルや行列、3次元での回転を計算するときに使う「クォータニオン」について教える。ただし簡潔に分かりやすく学べるよう編集したため、用語の定義が一般的なものと異なる場合があるとしている。 ゲーム制作では、キャラや背景を3次元で回転させたり、ゲームエンジンそのものを作ったりするときに線形代数を使うという。セガは教材について「興味のある方は参考にしてほしい。“大人の学び直し”をしてみたい方はぜひ」としている。 関連記事 任天堂がSwitch向けにプログラミング学習ソフト 作ったゲームの共有機能も 任天堂が、Nintendo Switch
育児していて時間があまり取れない状況下で継続的に学習するために色々な方法を取り入れているんだけど、その中で最近めちゃくちゃ効いた3つのやり方を紹介。 やりたいことリストを作っておく 今日のTODOリストを作る 2分間コーディング やりたいことリストを作っておく 自分が学習したいことの一覧があると、優先度を決めやすくなり、またやりたいことが1つ終わった後すぐに次に取り組むこともできる。そこで僕はTrelloでリストを作り、とにかく少しでもやってみたいと思った開発や、読みたいと思った本などがあれば追加している。 今日のTODOリストを作る 時間が空いてから「今日はこれから何をやろうかな?」と考えていると、途端にやる気がなくなってダラダラしてしまう。そこで先に今日のTODOリストを作っておくということをやっておく。ポイントとしては 細かい家事やプライベートでやること、勉強すること全て含めて同じリ
私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は2時間かかるけど、3か月もしたら5分で終わるわよ。って言われたけど、いや、そもそも俺4時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。1からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
そもそもなぜSteamで公開するのか この記事ではSteamにフォーカスしましたが、実際はこのゲームはWeb上から直接遊べるし、WebViewでラッピングしてGooglePlayにも公開しています。 SteamとGooglePlayに出した最初の理由は、大きなプラットフォームの力を借りて集客するためです。 LPだけオープンして待っていたとこで誰も遊びに来てはくれないわけです。 なので正直、「Webブラウザで遊べるのに、集客のためだけにわざわざダウンロードしてもらうなんてアホくさいな」、と思っていました。 しかし今となっては、むしろSteam経由で遊んでもらいたい思いのほうが強いです。 Steamのストアに並ぶことは思っていたよりも嬉しくて、 例えるなら、小説を書いたとして、今まではコピー用紙に印刷してホチキスで止めたものを皆に配っていましたが、 今回はちゃんと本になって、カバーがついて、書
クリエイティブコーディングとは?メディアアート・インタラクティブアートなど音響・映像表現をする為のプログラミング環境のまとめ ナカジ(@cp_nakajun)です。 当サイトは、メディアアート・インタラクティブアートなどを「自分でも作ってみる」という人を多くしこの分野を盛り上げていけるような情報を発信したいと思っています。 とは言え、メディアアート・インタラクティブアートの作品作りには作品規模に大なり小なりありますが表現手法によっては幅広く、専門的な知識と技術が必要なことがあります。 そこでまずは多くの作品作りの「コア」になってくるプログラミングについて触れることが必要になります。 プログラミングと言うと理数系のエンジニアをイメージしたりしてハードルが高いように感じるかもしれませんが 今は「アーティストやデザイナーが、コンピュータ・サイエンスやプログラミングの知識がなくても簡単なコードを書
はじめまして、サーチサービス開発グループの松村です。 2016年3月に入社して以来、レストラン検索のサーバーサイドエンジニアとしてフロントや内部ロジック改修、データ連係などを担当しています。PHPフレームワークのLaravelを使い、文字でなく写真をメインにした検索結果一覧ページの作成や管理画面の開発も手がけました。 私が担当したプロジェクトでは、社内ツールと本番サービスの一部に社内で初めてLaravelを導入しました。そこで、社内ツールにLaravelを導入した際の話と、本番サービスに導入し稼働させた話を連載で記事にします。 今回は「社内ツールにLaravel導入した際の話」です。社内でLaravelを導入した際の苦労話と周りからの反響についてまとめました。 Laravelとは なぜLaravelを好きになったのか artisanはかしこい 布教のきっかけ Laravelで開発開始 既存
以前も少し書きましたが、いまペパボのフリマアプリ「kiteco(キテコ)」の API を Rails でつくっています(つい先日 Android 版をリリースしました) 古着フリマアプリ kiteco(キテコ)- 手数料無料キャンペーン中! で、少し前に新卒2年目氏がチームに加わったので「これ読んどくと良いよ」という本をチーム内で共有しようと思っていたのですが、クローズドな場所に書く理由も無いですし、せっかくなのでブログに書こうかと思いました。 Rails チュートリアル をやり終えて、"とりあえず動く" 動くコードは書けるようになった、という人が次に遭遇するであろう問題とそれを解決してくれる本をまとめます。 紹介する順番には、特に「この順番で読むべき」という意図はないです。まずは自分がいま抱えている問題の本を手に取ってみると良いと思います もくじ 問題 1. テストが書けない - 読むべ
GoFのデザインパターンとは、「プログラミングのベストプラクティスを体系化したもの」です。このベスト・プラクティスをしっかりと理解して設計すれば、ソフトウェア設計の効率を高めることができます。またデザインパターンが「プログラミングの思想」の共有をよりスムーズにしてくれます。先人たちの試行錯誤の結果を効果的に利用して、プログラミングをもっと楽しんでしまいましょう! 🐯 デザインパターンのポイントGoFのデザインパターンには下のプリンシパルがあります。 変わるものを変わらないものから分離する インタフェースに対してプログラミングし、実装に対して行わない 継承より集約 委譲、委譲、委譲 必要になるまで作るな(You Ain’t Gonna Need It./YAGNI) 🏀 デザインパターン一覧 アブストラクトファクトリ ビルダ ファクトリメソッド シングルトンパターン アダプタ コンポジッ
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中!すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する(あなたはユーザではない)コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴(Yugui)さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント(=ソースコードに書かれている注釈やメモ)です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴(Yugui)さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴(そのだ・
このサイトは田所淳の講義、仕事、日記、そのほか諸々の情報を公開しています。そもそもは、授業の履修者のために過去の授業の内容の記録を掲載するために始めたのですが、より多くの人に役にたてるのであればと思い、全てを公開することにしました。基本的にリンクはフリーです。どの階層のページにも勝手にリンクしていただいて構いません。また、リンクした旨を連絡をしていただく必要もありません。サイト内の全ての記事は、Creative Commons Licenseの条件に従う限り自由に利用していただいて構いません。記述の誤りご意見などありましたら、コメントもしくはメールにてお知らせください。 tadokoro[at]gmail.com
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
後輩くんから質問を受けたので公開する、こんな感じ 上から dev/asonas 自分のプロジェクトはだいたいここに入ってる。 asonasなのは僕の ssh key で pull, push できるもの。例えば会社にはいって fujiwara という名前で鍵をつくってそれを登録していたら dev/fujiwara というのを切ってその下に fujiwara で pull push できるコードを置くようにしてる。 dev/bin ~/local/bin みたいな役割 Macで ~/local みたいなディレクトリをつくりたくないから dev/ においやってる。 dev/blog ブログに関するものをおいてる。 最近はoctopressのコードもここにおいてる。 dev/gem Githubからcloneしてきたgemをおいてる。手元においておきたいコード(例えばrailsとかrspec-c
Go言語はシンプルさを念頭にデザインされた言語です。仕様は単純明瞭さのために小さく収められていますが、そのため表現力に欠けているとか、コードが冗長になるという印象を持つ人も多いでしょう。有名なところでは、ジェネリクスや例外といった機能が(今のところ)存在しないことが問題にされることが多いようです。 一般に、ソフトウェアエンジニアリングというものは書かれる言語だけに依るものではありません。視点を拡げてGoを取りまくツール群を含めて見てみると、go fmt や goimports といったツールが広く使われていること、また go generate コマンドの存在などを見ても、Goという言語には、人間のプログラミングを機械によってさまざまな面から補助しようという態度があります。
自分用にまとめていたけどせっかくなので公開。 なるべくフロントエンドで完結してライセンスも使いやすいものを選択したつもり。 全部で100個超。 1番目のURLが本家 or GitHubのページ、2番目のURLが比較的わかりやすいと思った日本語の解説ページになっています。 Node.jsのライブラリもまとめたので合わせて見るといい感じ accounting.js金額のフォーマットを行う カンマ区切りや小数点n桁までなど https://josscrowcroft.github.io/accounting.js/ ace.jsテキストエディタ ハイライト・文字列畳み込み・ショートカットキー 組み込むのが簡単で機能もひと通り揃ってる https://ace.c9.io http://qiita.com/naga3/items/1bc268243f2e8a6514e5 AlertifyJSダイアロ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について本人同意済み。弊
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く