Index 0 - 言語非依存 アクセシビリティ オープンソースエコシステム ガベージコレクション グラフィックスプログラミング グラフィックユーザーインターフェイス セキュリティ その他の話題 ソフトウェアアーキテクチャ ソフトウェア品質 ソフトウェア開発方法論 データベース ネットワーキング 並列プログラミング 機械学習 正規表現 理論計算機科学 組み込みシステム Android AppleScript AWK Bash C C++ Clojure CoffeeScript Common Lisp Coq D Elixir Emacs Lisp Erlang Git Go Groovy Gradle Grails Spock Framework Haskell iOS Java JavaScript Angular.js Backbone.js jQuery Node.js React
Garbage Collection ( ) (endo@logos.t.u-tokyo.ac.jp) 6 : Jan 27, 2005 1 Garbage Collection ? 2 (1) (2) ( 1) C C++, Pascal ML Java, Perl C malloc (allocate) free ( malloc Java/C++ ML tuple record ) C ( / free) 12 ML tuple record garbage collection(GC) GC • UNIX (1995 ) emacs GC • Java web Java 0.5 / ( )black box GC GC ( 1) Java Sun HotSpot VM (Ver. 1.4.2) GC 3 generational GC (6.2 ) ( ) copying GC (
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
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
Javaの検査例外の仕組みは理解はできるけど、結果的にはあまりうまくいかなかったかなというのが個人的な見解です。理由は例外をcatchさせても無視されることが多いから。 下記の本にもそれに近い見解が述べられていた気がするけど忘れた。 Java: The Good Parts 作者: Jim Waldo,矢野勉,笹井崇司出版社/メーカー: オライリージャパン発売日: 2011/02/24メディア: 大型本購入: 3人 クリック: 148回この商品を含むブログ (37件) を見る 僕がSIerにいた頃は、開発者に例外をcatchさせてはいけないと言われたものでした。 共通チームが共通部品やフレームワークを整備して、他チームがそれを使って開発することが多いわけですが、その場合に個々の開発者が例外をcatchする必要がないように整備するのが一般的でした。 例えばStruts 1のActionのex
時によってプログラマは文字列から不要な文字を取り除きたい場合があります。例えば、テキストの一部からすべての行の末尾文字を削除したいとします。 その時、全スペース(‘ ‘)や改行コード(‘\n’および‘\r’)を削除する問題を考えてみましょう。 効率的に実行するにはどのような方法がいいのでしょうか。 size_t despace(char * bytes, size_t howmany) { size_t pos = 0; for(size_t i = 0; i < howmany; i++) { char c = bytes[i]; if (c == '\r' || c == '\n' || c == ' ') { continue; } bytes[pos++] = c; } return pos; } 上記のコードはUTF-8でエンコードされた文字列で動作します。UTF-8がASCII
はじめに 最近、ansibelなどの設定書式で用いられる記法「YAML」について、紹介します。 YAMLは、箇条書きのように記載できるため、大変わかりやすいフォーマットです。 YAMLとは? 概要 YAML Ain’t Markup Languageの略で、構造化データの表現する記法になります。 主に以下のような用途で利用されます。 設定ファイル データ保存 データ交換 XMLとの違い XMLとYAML大きな違いは、表記方法が異なります。 XML = 開始、終了タグ()を利用した構造化データを表現。 YAML = タグの代わりに、インデントを利用した構造化データを表現。 XMLと比べ、人が見る場合に非常にわかりやすい構造で表現することが可能となります。 以下、XMLとYAMLを比較すために、サンプルを記載します。 例) 書籍の一覧を表現する場合 [XML] <books> <book> <
You can find discussions on Hacker News and Reddit I’ve seen a bunch of articles lately which promote the Go language’s latest garbage collector in ways that trouble me. Some of these articles come from the Go project itself. They make claims that imply a radical breakthrough in GC technology has occurred. Here is the initial announcement of a new collector in August 2015: Go is building a garbage
この記事は 第2のドワンゴ Advent Calendar 2016 の8日目です。 日付を跨いでいる? またまたご冗談を、DST(ドワンゴスタンダードタイム)ではまだ8日ですよ。 ちなみに前日は…なんと誰も参加登録をしていませんでした! 結構な勢いで埋まってたんですけど、唯一の空きですね。 前々日はdaneko0123さんでした。 一昨年のアドベントカレンダー記事が「関数型プログラミングとは結局何なのか」、去年の記事が「オブジェクト指向プログラミングとは結局なんなのか」ということで、3年目ともなると記事の方向性が固まりつつある雰囲気が漂いつつ、ネタ切れの空気も漂いつつあります。 そもそも去年の時点で既にドワンゴ社員ではないのにアドベントカレンダーには参加し続けている、というのもアレな話ですが。 なにを書くか考えたのですが、最近null安全に関する記事が話題になり、その中で「型」と「安全性
2017/3/1追記 : Pythonの説明がやや不正確だったため追加の記事を書きました → 参照についてもう少し詳しく ~PythonとJavaを例に~ ありきたりな話題ではあるけど、値渡しとか参照渡しとか、変数を関数に渡した時の挙動について自分もまとめてみることにした。 #はじめに、プリミティブ型について ほとんどの言語では、プリミティブ型とそれ以外で挙動が違う。 言語によって若干異なるものの、プリミティブ型は概ねこんな感じ。 整数 浮動小数点数 文字 ブーリアン 参照 or ポインタ それ以外の配列、クラス、構造体などをここではオブジェクトと呼んでいる。 #値渡し 関数に渡した際にその値をコピーした新しい変数が作られ、それが仮引数になる。 関数内で仮引数を変更しても呼び出し元の変数は変化しない。 C++、Java、Pythonの例。
構文解析はプログラマなら誰しも一度はやったことがあると思います。しかし、構文解析には独自の用語がたくさんあります。 そこで、初心者に向けて用語の解説をしたいと思います。「非終端記号って何?」「トップダウンとボトムアップはどう違うの?」と疑問に思ってる方は必読です。 終端記号と非終端記号 終端記号、非終端記号とは、「置き換えが」終わった記号、終わってない記号のことです。まだ何のことかわかりませんね。wikiの例をみてみましょう。 S→Ax A→a A→b この3行はそれぞれ「矢印の左側の記号を右側の記号へ置き換える」という構文を表しています。この「記号」たちの種類が「終端記号」「非終端記号」です。 この構文では、SとAは置き換えが起きていますが、aとbは置き換えが起きていません。だから、SとAが非終端記号、aとbが終端記号です。 構文解析の種類 構文解析したい文字列(入力)は終端記号の羅列で
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Book description Don't engineer by coincidence-design it like you mean it! Filled with practical techniques, Design It! is the perfect introduction to software architecture for program
Find PI to the Nth Digit - Enter a number and have the program generate PI up to that many decimal places. Keep a limit to how far the program will go. Find e to the Nth Digit - Just like the previous problem, but with e instead of PI. Enter a number and have the program generate e up to that many decimal places. Keep a limit to how far the program will go. Fibonacci Sequence - Enter a number and
SpringでField InjectionよりConstructor Injectionが推奨される理由を調べてみたメモです。 (2016/12/30) サンプルコードにfinalをつけるように修正 (2017/03/29) Immutabilityについて追記 --- 家でも会社でもIntelliJを使って開発しているのですが、 Spring Bootで@Autowired(@Inject)を使うと下記のような警告が出るようになりました。 警告内容を見てみると、フィールドインジェクションは推奨されません、とのこと。 「Field injection is not recommended.」 警告の詳細を見てみると下記のように書いてあります。 「Field injection is not recommended. Spring Team recommends: "Always use
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く