ゲームエンジンや3Dソフトウェアを利用して高度な表現ができるこの時代でも、プリミティブな描画や動き、アルゴリズムから学べることは多い。それらをJavaScriptで書くクリエイティブコーディングという形で学べる手引書が本書となる。
ゲームエンジンや3Dソフトウェアを利用して高度な表現ができるこの時代でも、プリミティブな描画や動き、アルゴリズムから学べることは多い。それらをJavaScriptで書くクリエイティブコーディングという形で学べる手引書が本書となる。
私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は2時間かかるけど、3か月もしたら5分で終わるわよ。って言われたけど、いや、そもそも俺4時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。1からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど
アリス、ボブ、マロリーのイメージ図 アリスとボブ(英: Alice and Bob)は、暗号通信などの分野で、プロトコル等を説明する際に想定上の当事者として登場する典型的なキャラクター。"当事者Aが当事者Bに情報を送信するとして"のような説明文では、段階の増えた体系になるにつれ追いにくくなる。そのため、こういった具体的人名が好んで使われる。 暗号やコンピュータセキュリティでは、さまざまなプロトコルの説明や議論に登場する当事者の名前として広く使われる名前が数多くある。こういう名前は慣用的、暗示的で、ときとしてユーモアに富み、事実上メタ構文変数のように振る舞う。 典型的なプロトコル実装においては、アリスやボブのあらわす実体が自然人であるとはかぎらない。むしろコンピュータプログラムのように、信頼され自動化された代行者であることが多い。 この一覧のほとんどは、ブルース・シュナイアーの暗号技術大全[
第106回で、一般的な商品に付けられているバーコード(JANコード)の意味を御紹介しましたが、この他にもバーコードはいくつかの種類があります。 今回は、その中でも見かけることの多い、本に付けられたバーコードの意味を紹介します。まず最初に書籍のバーコードを解説した後、最後にさらりと雑誌についても見てきます。ちなみにこの他、と言いましたが、他には郵便バーコード、2次元バーコード、学生証のバーコードや、カラオケで歌を選ぶときのバーコードなどがあります。 それでは早速、書籍のバーコードを解説!っていきたいのですが、1つ前提となることを御紹介せねばなりません。 それは、ISBNってものです。本のバーコードは、このISBNの識別をすることになります。 じゃあ、これは何か。 世の中には膨大な出版物がありまして、どの国の、何と言う出版者&タイトルの出版物であるかを特定でき、容易に検索できる基盤となる番号を
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中!すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する(あなたはユーザではない)コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴(Yugui)さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント(=ソースコードに書かれている注釈やメモ)です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴(Yugui)さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴(そのだ・
普通のやつらの上を行け ---Beating the Averages--- 著者:Paul Graham Copyright 2001 by Paul Graham これは、Paul Graham: Beating the Averages を、原著者の許可を得て翻訳・公開するものです。 プロジェクト杉田玄白正式参加テキスト。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2001 by Paul Graham 原文: http://www.paulgraham.com/avg.html 日本語訳:Shiro Kawai (shiro @ acm.org) <版権表示終り> 文中、Eric Raymondの "How to bec
後輩くんから質問を受けたので公開する、こんな感じ 上から 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
自分用にまとめていたけどせっかくなので公開。 なるべくフロントエンドで完結してライセンスも使いやすいものを選択したつもり。 全部で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ダイアロ
弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について本人同意済み。弊社特有の部分は一部省いています。) ああ、なんという長い旅だったろう。この会社で5年間もセキュリティを担当していたよ(諸々の失敗は許してくれ) 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、
「プログラミングを学ぼうと瞬間最大風速的に意識は高くなるものの、一人でいると気がついたら一日ソシャゲして夕方頃に『また今日も勉強できなかった』と自己嫌悪。」モチベーションが続かない時の対策をはじめ、学び方、学べる環境の作り方をまとめています。
今どきっぽいというのは、各種JavaScriptライブラリを使うという意味です。ここでは、Bootstrapと、Knockout.jsを使ったサイトを作ってみます。 HTML Serviceの強化 @dz_ さんの記事のCheck! Google Apps Script - UIの実装は HtmlService + Polymer の利用が主流に?に書かれているように、Google Apps ScriptのUI周りに少し手が入ります。 今まではUi Serviceというのを使っていた。JavaとかC++のGUIフレームワーク的な仕組みで、サーバサイドでUIのパネルとかボタンとかラベルを作り、コールバックも定義してあげる仕組み。ただし、生成されるHTMLはHTML 3.2的なテーブルレイアウトだったりするのはご愛嬌。ただし、6/30で終了。 今後はHTML Serviceというものがメインに
@HIROCASTER さんの記事 プログラミング上達がはやいヤツの特徴10個 を騙されたと思って試し,9ヶ月経った今の気づきを書いておきます. ① 毎日コードを書く 始めた当初は楽しさがわからず,なかなか辛かったです. しかし入社した時に,5分でもとにかく「毎日」続けようと決めて,PCも常に持ち歩いて続けました. コードを書く 不明点が出て壁にぶつかる 調べる 解決 モノが動く 楽しい コードを書く ... 結論これです. 毎日続けると,様々なものがどんどん積み上がります. コードを書くスピード,品質が上がるのに伴って,コードを通して実現できることが増えます.そして,難しいことにも挑戦してみようと思うようになります. その結果,やっている内にどうしていいかわからないバグなどが発生し,一旦は壁にぶつかります.しかし,ネットで調べたり人に相談したりして解決できると,楽しくて,またさらに新しい
さて、まさかのMSの大鉈連発に、TL大騒ぎでございます。まさかOSS化まで入ってるとは僕も思ってなかった。MSクラスタですらもざわざわである。 んで、今回の決定が意味することをちょっと考察してみたいなーと。備忘録的にね。 あくまで 私的感想です。鵜呑みにしないように。 何が起こったのか 11/12日(米国現地時間),Microsoft Connect();というイベントの中での発表でございました。 詳しくは、Public Keyさんを参照するのが良いと思います。 [速報]マイクロソフト、サーバサイドの「.NET Core Rutime」と「.NET Framework」のオープンソース化を発表。C#コンパイラやASP.NETなど [速報]マイクロソフト、「.NET server framework」のLinuxとMacOS X用オフィシャルディストリビューションを発表。.NETアプリケーシ
完全に一致を作るための勉強法 たくさんのアクセスありがとうございました。 コメントもたくさん頂いてまして、それにお答えするのに「ブログでもつくろうかいな」とのぼせましたが、そんなテーマで続くわけもないので、やはりアノニマスダイアリーにしました。 【製作期間について】 まず、皆さん仕事しながらたった4ヶ月で!と褒めて頂いてますが、たったじゃないですよ。4ヶ月って。 仕事が終わって、毎日2~3時間。土日関係無くやると、多分300時間くらいになります。 専門学校の2年間の授業時間がこのくらいだったりするんじゃないですかね。結構長いです。 【モチベーションの維持について】 モチベーションを保つのがすごいというのも褒めてもらいましたが、私は一回やり始めると、意外に長く続きます。 コツがあるんです。 毎年、日々の単純作業が続かない新入社員が入ってきますが、そんな新人に言います。 「息をするように続ける
0-1. 前書き この世にはたくさんのプログラミング言語が存在します。Wikiepdiaのプログラミング言語一覧を見ると、実に200個以上というわけの分からない数の言語が並んでいたりします。 【参考URL】プログラミング言語一覧 - Wikipedia http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%... 200の中にはほとんど使われてない言語も混じってるので、実際に仕事でざくざく使われている言語は20とか30とかそういうオーダーなのですが、それでも1人の人間が把握するにはちょっと多過ぎる数です。 本記事では、そうした有り余るプログラミング言語の海の中で「どれを勉強したらいいの?」とか「どれを採用するのが適切?」という悩みをお持ちの方が「よし、この言語に決めた!」と自信を持って決断できるように背中を押すことを目的として書か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く