Crafting Interpreters
Ever wanted to make your own programming language or wondered how they are designed and built? If so, this book is for you. Crafting Interpreters contains everything you need to implement a full-featured, efficient scripting language. You’ll learn both high-level concepts around parsing and semantics and gritty details like bytecode representation and garbage collection. Your brain will light up w
Drop Documents Contents
公開中の内容・構成については、変更されることもあります。現在のDrop 2.0Betaの作成状況を下記のマークで示しています。 .....完成かな？ .....もう少しです .....まだまだ 現在も相変わらず修正中です。 みなさんからのご意見は、以下のDrop Q&A;にてご紹介させていただきます。 はじめに Dropの読み方・使い方 LastUpdate: 3.11 コンセプト編 第１章 Drop構成用語集（オブジェクト指向用語編） LastUpdate: 2.15 第２章 Drop構成用語集（開発プロセス編) LastUpdate: 2.15 第３章 オブジェクト指向開発の考え方（映画撮影のように) LastUpdate: 2.15 第４章 Dropの目指すもの LastUpdate: 3.11 プロジェクトチーム構成編 第５章 プロジェクト構成の問題 LastUpdat
Literate Programming
Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99. I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming." Let us change our traditional attitude to the construction of programs: Instead of imagining that our
tadyjp/readable-code-for-web · GitHub
README.md まえがき この文書は「リーダブルコード」にリスペクトされて書いている、「Web開発者向けのリーダブルコード」です。 以下、「リーダブルコード」と表記した場合は、参考にしている「リーダブルコード」のことを指すこととします。 ある程度まで全体像が見えてうまくいきそうなら、著者の Dustin Boswell氏、Trevor Foucher氏、訳者の角征典氏、出版社である株式会社オライリー・ジャパンなどへ連絡していきたいと考えております。 本文書内で「リーダブルコード」を引用する場合には、 ここは引用です と表記します。 法律・権利的なご指摘や、内容についてのご感想・ご指摘などございましたら、 私、多田雅斗a.dat.jp@gmail.comまでご連絡ください。 また、プルリクエストも随時歓迎しております。 はじめに 対象者 この文章の対象は、「Web開発者」としていますが、
Javadoc ドキュメンテーションコメントの書き方 - Qiita
出展: プログラム内のコメントの書き方 | 天才まくまくノート はじめに（モチベーション） こんな話があります。あるソフトウェア企業が一人の技術者の採用を決めました。その決め手となった理由は、「公開しているオープンソースソフトウェアのドキュメントが素晴らしかったから」です。彼らは、作成されたドキュメントを見ただけで、その人には技術力がある、一緒に働いて欲しいと判断したのです。 ある国の言語を学ぶために読み書きの練習が必要であるのと同様に、コーディング技術をつけるには、多くの良質なコードを読み、多くのコードを書くことが必要です。設計ドキュメントを書くのも同じことです。日頃から分かりやすいドキュメントを書く鍛錬を怠らず、長年の経験を積んでいかなければ、良質なドキュメントを書く力は身に付きません。今日からドキュメンテーションコメントをバリバリ書いて、ドキュメンテーション力を付けていきましょう。
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
Multi-Paradigm Language TAO
国産 Lisp 専用マシン ELIS のマルチパラダイム言語 TAO について．共立出版 bit に連載したもの．
4 月にエンジニアとなった人たちに知っておいてもらいたいこと
個人的な経験を書きますが、ぼくはエンジニア生活 10 数年で 5 社を転職して渡り歩いています。そして、その 5 社すべてでなにかしらの勉強会なり研修なりといったものをやってきました。 そして、それが仕事であろうとなんだろうと自分がエンジニアに研修なり説明会なりをするときは、自分がもらったものを返すつもりでやってきました。そのときそのときは当然所属している会社があるわけですが、その会社のため (だけ) にやったことは一度もありません。プロジェクトによって参加している人の立場も発注元だったり受託開発の常駐エンジニアだったり様々だったので、あくまで一人のエンジニア同士として自分が伝えられることをなるべく伝わるような言い方で伝えるということをやってきました。その中では所属会社へ都合の悪い話も出たりしますが、これは所属会社へのコミットメントとは別の話です (PHP 使ってる会社で PHP の悪い点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Design and implementation patterns - Cloud Design Patterns
PrismEdu/07.EventAggregator at master · runceel/PrismEdu
GitHub - jbt/docker: Documentation generator
書いたもの