コミュニケーションが生まれるツイートまとめツール
コンピュータ・アーキテクチャにおける分岐予測（ぶんきよそく、Branch Prediction、ブランチプレディクション）とは、プログラム実行の流れの中で条件分岐命令が分岐するかしないかを予測することにより、命令パイプラインの効果を可能な限り維持し、性能を高めるためのCPU内の機能である。 2方向分岐は一般に条件分岐命令で実装されている。条件分岐は、分岐せず (not taken) に分岐命令直後に続く命令の流れをそのまま実行し続ける場合と、分岐して (taken) プログラム内の異なる位置に分岐してそこから命令実行を続行する場合がある。 図 1: 4段パイプラインの例。色つきの四角形が命令を表している。 条件分岐命令が分岐するかしないかは、分岐条件を計算し、条件分岐命令が実行ステージ（図1の Stage: 3）を過ぎるまでわからない。 分岐予測を行わない場合、条件分岐命令が実行ステージを
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー プログラミング言語(C#，VB，PHP，C/C++，Python，Java，Ruby，JavaScript，Objective-C)やHTMLのコーディングスタンダードを集めたリストを発見しました。日本語訳があるものはできるかぎり探し出して，括弧のなかに併記して補ってあります。微妙に古いのが混じってるかな。Rubyは日本発のコーディング規約がある気がする(まつもとさんの日記を見つけた)。 元記事にPerlのスタイルガイドがなかったんだけど，モダンなPerlスタイルガイドがあったら教えて欲しいです:-)。 PythonにはPEP8というコーディングスタイルガイドがあってよく読まれることは
1. わかる !Java バイトコード ― 30 分でわからない ?Java バイトコード入門 筑波大学大学院 システム情報工学研究科 博士後期課程 水島宏太 2. 自己紹介とか Twitter: @kmizu はてな : id:kmizushima github: http://github.com/kmizu/ 大学院生 構文解析の研究とかやってます 特に Packrat Parsing Scala 好き Scala の布教活動をあちこちでやったり JVM 好き JVM 上で動作する言語処理系 Onion を開発 3. Agenda プログラミング言語としての Java バイトコード マシンモデル 型システム 命令セット クラスファイルベリファイア ベリファイアがはじく操作の例 簡単なプログラムを javap で逆アセンブルする 役に立つかもしれない javap のオプション解説 クラ
最近，他人が自分のコードを読んだり修正したりする機会が増えてきたので，意思疎通のために自分のコーディング規則をメモしておきます．CLX C++ Libraries も（たまにブレてますが）ここに挙げる規則に従って書いているので，コードを読む際の参考にでも． 尚，以下は基本的に自分が守っているだけで，他人は（単一プロジェクト内のコード間で整合性が取れる範囲で）自分の信念に基づいてコーディングしていけば良いんじゃないかな，と思っています． 名前空間 グローバル名前空間には，クラス/関数を（極力）定義しないようにします．通常は，プロジェクト毎に適当な名前空間を考えて，その名前空間内に各種クラス/関数を定義します．ただし，ユーザに使用されることを意図していないクラス/関数に関しては，使用する名前空間の中でさらに detail 名前空間を定義して，その中で定義します． クラス設計 クラスは， x.i
プログラマ、ＳＥ、ゲームプログラマについて 自分は小さいころからコンピュータが好きで、よく触っていました。 中学生のころに、ホームページを作ろうとおもってhtmlというものをはじめて知ったとき、 コンピュータに引き込まれるような衝動を覚え、JavaScriptを結構楽しんでやっていました。 受験と同時にＰＣ禁になってしまったために、プログラミングには触れていたものの、 まだhtmlと出会って数ヶ月の厨房のまま、高校生を迎えました。 高校入学と同時にＰＣが戻ってきましたので、早速ホームページ（東方）のを作っていたのですが、 そこで、初めてプログラムというものを意識するようになりました。 この東方も、プログラムで動いているんだな・・・・・と感無量な気持ちになり、おれもやりたい！！と、プログラミングの 勉強に取り掛かったのですが・・・・ 本当に何も知らなかったのです。無知でした。安易でした。 本
「コンピュータが理解できるコードは誰でも書ける。優れたプログラマが書くのは、人間が理解できるコードだ」 リファクタリングはコードの保守をする中でとっても大切なことは分かっているけど、原理原則を持っていない。原理原則が欲しいので、書籍「リファクタリング：Rubyエディション」を読んで、原理原則を手に入れようとしている。まだ読んでる途中だけど、アウトプット。書いてあるコードを丸写しするのではなく、自分なりにコードを書き直す事で理解した。 原理原則の前に大切なこと リファクタリングでは、テストが命綱になる。リファクタリングが成功するかどうかは、よいテストが用意できているかどうかによって左右される。テストは、後でプログラムを書き換えなければならなくなった時の安全弁になるので、十分に時間をかけて作って良い。そして、テストは自己診断テストでなければならない。リファクタリングでは、プログラムを少しずつ変
The document discusses C++ and its history and features. It describes C++ as an extension of C with object-oriented features like classes. It provides information on the creator of C++, Bjarne Stroustrup, and the evolution of C++ since its introduction as a way to add object-oriented programming to C. It also includes sample C++ code demonstrating the use of arrays and includes from the Boost libr
画面をダブルクリックで縦書きと横書きを切り替えることができます。要素を指定して縦書きにしている場合は、次回アクセス時に同じ表示が引き継がれます。 どんなサイトでも縦書きにするブックマークレット。 ↓右クリックで「お気に入り」に保存するか、リンクをドラッグしてブックマークバーにドロップします。 「縦書きにする・iPhone 用リンク」 「縦書き可能にする・iPhone 用リンク」 「段組み縦書き可能にする・iPhone 用リンク」 iPhone に登録するには？ とりあえずこのページを共有ボタンからブックマーク。 iPhone 用リンク を長押ししてコピー。 ブックマークを開いて、追加したブックマークを「編集」。 名前を「縦書き可能にする」などに変更し、URL 欄に上記コードをペースト。 最初の「http://」を削除。 注意！ やや動作が重いです！ うまく変換できなかったときは、画面をダブ
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
ガベージ・イン／ガベージ・アウト： 善き人々が悪しきプログラムに手を染める時 Henry G. Baker hbaker@netcom.com http://linux.rice.edu/~rahul/hbaker/home.html Copyright (c) 1997 by Henry Baker. All rights reserved. 日本語訳：Shiro Kawai (shiro@acm.org) プロジェクト杉田玄白協賛参加テキスト これは、ACM SIGPLAN Noticesに掲載されたコラム Henry G Baker： "Garbage In Garbage Out: When Bad Programs Happen To Good People" を、原著者の許可を得て翻訳・公開するものです。原文は下記のURLから入手可能です。 原文の転載は原著者の許可を得て下さい
今AngelBeats!見てます。天使ちゃんマジ天使でいいと思います。 で、だいぶ前に作ったScala版のちょっと草植えときますね型言語 Grassを改造して、プログラミング言語 「天使ちゃんマジ天使」とプログラミング言語 「ブブゼラ」を作ってみたよ。 Grassは、id:uenoB 作の型無しラムダ計算がベースをした関数型言語らしいです。(6/22追記) ちょっと草植えときますね型言語 Grassについてはこちら。 世界で最初のGrassプログラム - Garage uenoB ちょっと草植えときますね型言語 Grass プログラミング言語 「天使ちゃんマジ天使」 ちょっと草植えときますね型言語 Grassの派生言語というかまんまです。 Grassで使用する文字(ｗ，Ｗ，ｖ)をそれぞれ(天使, マジ, ! )に置き換えただけです。 wを出力するプログラム: 天使ちゃんマジマジ天使天使ちゃ
HQ9+はクリフ・ビッフルによって作られたジョーク向け難解プログラミング言語である。実用言語ではない。 HQ9+は4つの命令だけで構成されており、それらは'H'、'Q'、'9'、'+'という単一の文字で示される。HQ9+はチューリング完全ではなく、プログラミング言語としては不完全であるが、プログラミングの例題としてよく取り上げられるいくつかの問題に対しては極めて効率的である。 Hコマンドは文字列"Hello, world!"を出力する。 Qコマンドはプログラムのソースコードを出力する（参考:クワイン (プログラミング)）。 9コマンドは『99 Bottles of Beer（英語版）』（アメリカの数え歌で、プログラミングの例題でよく利用される）の歌詞を出力する。 +コマンドはアキュムレータをインクリメント（1だけ増やす）する。 HQ9+のプログラムは、例えば次のようになる。 HHQ+HQ+
しばしば、「○○というプログラミング言語は△△に比べて安全だ」「Webプログラミングの分野において最も安全な言語は何？」といった主張が繰り広げられることがある。これに対しSecurity Ninjaが「どの言語を選択しても関係ない、（なぜなら）それらは等しくセキュアでないからだ！」と反論している。 記事ではWhite Hat Securtyの統計レポート を元に、「どの言語も脆弱性がある入力の割合は大差なし」「かつて重要な脆弱性があったWebサイトの割合はどの言語でも70～80％台」「現在でも脆弱性があるWebサイトの割合はどの言語でも50～70％台」といったデータが示されている。このデータではPerlで実装されたWebサイトについて若干脆弱性が多いように見えるものの、結論としては「どの言語も等しくセキュアでない」とのことで、「セキュアなコードはセキュアな開発プロセスや開発者に対するセキュ
なんかVelocityもJSPもスクリプト言語より遅いという事実は、Java屋さんはあんまり知らなかったみたいだね。しかも、遅い原因の考察が的外ればかりで笑ってしまう。 「Javaの文字列操作は遅いから」とか「UTF-16の変換に時間がかかるから」とか、そんなのまるで関係ないですから。Javaの文字列操作は十分速いし、UTF-16の変換も主要因ではない。 ＃つうかさ、「Javaの文字列操作は遅い」とか、Javaに対して失礼だろ。 VeocityやJSPが遅いのは、単に動的な独自言語を導入したから。はっきりいって、これはアーキテクチャ上の間違った選択。せっかくJavaが静的であるのにその特性を利用せず、わざわざ動的言語を導入しているのだから、何考えてんだろうと思う。いつもJava屋さんが主張しているような、「コンパイル時にエラーを発見できる」「IDEでの補完が効きやすい」「リファクタリングが
システムの多機能化により、プログラムの内容が複雑化している。テクマトリックスの『Understand』は、プログラムの構造を可視化することで、ソースコードの解析時間を大幅に削減できる開発支援ツール。今回は同社の福永一寛氏に、Understandの機能や特徴について聞いた。 システムの多機能化により、プログラムの内容は複雑化している。既存コードの改修や多人数での開発における情報共有のためには、プログラム構造の理解が必須だが、ドキュメントと実装内容とが乖離している場合も多く、解析自体に工数がかかることもある。テクマトリックスの『Understand』は、プログラムの構造を可視化することで効率的なソフトウェア開発をサポートするソフトウェア開発環境。「組込みシステム開発技術展（ESEC）」にて、同社の福永一寛氏にその特徴を聞いた。 ソースコードの解析作業時間を大幅に削減する『Understand』
MVCの典型的な相関図 Model-View-Controller (MVC、モデル・ビュー・コントローラ) はUIを持つソフトウェアに適用されるソフトウェアアーキテクチャの一種である。 MVCはソフトウェアを処理/Model・表示/View・入力伝達/Controllerの3要素に分割し、ソフトウェア内部データをユーザーが直接参照・編集する情報から分離する。プレゼンテーション（View・Controller）とドメイン（Model）を分離しまたユーザー入力（Controller）と表示（View）も分離することでソフトウェアの保守性・開発生産性を向上させる。 1979年: パロアルト研究所にてトリグヴェ・リーンスカウクが考案[1][2]。長い間、Smalltalk-80の実装のみが公開され、MVCに関する公開情報はなかった 1988年: 最初の論文「A Cookbook for Usin
なんか、はてなブックマークとか見てると残念なコメントが多いよなー。『こんな比較は意味ない』とか『できることがまったく異なるテンプレートを並べて比較されても』とかいうやつ、何なの？「言語の速度 != アプリの速度」という主張を示したベンチマークなんだから別におかしくないじゃん。主旨がまるで分かってもらえてない。ネットワークやデータベースの処理まで含めて計測したら、「言語の速度 != アプリの速度」という主張がより鮮明になるだけじゃね？ 反論する人があまりに残念な反論しかできないようなので、かわりに自分で「高速な言語を使う理由」を説明する (一人マッチポンプ状態じゃねーか)。 ・ ・ ・ ・ 言語が速いことによる本当の利点は、採用可能なアーキテクチャが広がることだと思う。新しいアーキテクチャを思いついたので採用したいが、スクリプト言語ではどうやっても満足な速度が出せなかったのが、Java
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
