第11回 カーネル/VM 探検隊
1801 – ジョセフ・マリー・ジャカールがパンチカードを使った織機によってタペストリーに"hello, world"と織り出す。しかしラッダイト (当時のRedditer) たちは、テールリカージョン、並行処理、大文字小文字の区別を欠いていたため、さほど感心しなかった。 1842 – エイダ・ラブレスが最初のプログラムを書く。彼女の努力は、プログラムを実行するコンピュータが実のところ存在しないというマイナーな問題のために頓挫した。後にエンタープライズアーキテクトたちはプログラムをUMLで書くために彼女のテクニックを再び学ぶことになる。 1936 – アラン・チューリングが存在しうるあらゆるプログラミング言語を発明するが、特許化する前に英国情報部員(後の007)によって抹殺される。 1936 – アロンゾ・チャーチも存在しうるあらゆる言語を発明しているが、より巧みに行った。チャーチのラムダ
Programming in Martin-Löf's Type Theory An Introduction Bengt Nordström Kent Petersson Jan M. Smith Department of Computing Sciences University of Göteborg / Chalmers S-412 96 Göteborg Sweden This book was published by Oxford University Press in 1990. It is now out of print. This version is available from www.cs.chalmers.se/Cs/Research/Logic/book. Table of contents in Postscript. The whole book (2
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
以下の2つの続き ScalaでFutureとEitherを組み合わせたときに綺麗に書く方法 FutureとEitherの話の続き(ApplicativeとMonadの違い) 上記の2つ(特に最初の方)を読んだことを前提で書くので、読んでない人は先にそちらを読みましょう。 なんだか少し関連する話(?)で盛り上がっていて、書かないといけない気がしてきたので 非同期プログラミングの難しさとScalaのFuture そのtogetterの議論について色々書きたいこと*1もありますが、それは置いておき、表題の「モナドによる同期/非同期プログラミングの抽象化」について書きます。というか、(非同期プログラミングの話より)便乗してモナドとモナドトランスフォーマーの便利さを話したいだけかもしれません(?) 前回2つは「Future使って非同期にしても、だいたい関数の本体同じでいけるよ」ということを書きました
Photo by Johan Bichel Lindegaard こんにちは。谷口です。 皆さんは、プログラミング教育が盛んになってきていることはご存知でしょうか? 日本でもすでに2012年の新学習指導要領により、中学校の「技術・家庭」において、従来選択科目であった「プログラムと計測・制御」が必修科目となっていますが、意外と知らない方も多いようです。 2020年には日本のWebビジネスの市場規模が2010年時点と比べて4.5倍に拡大すること、またそれによりWeb系企業の雇用者数も150万人増加をすることが見込まれています。(日本の成長を支える産業 「ウェブビジネス」P13、14) 業界が成長していく中で、より多くのエンジニアが必要とされ、その教育・育成は不可欠なものとなっています。 最近は、世界でも多くの国で早いうちからプログラミング教育が実施されており、少なからず国内企業の成長や利益拡大
The Communications Web site, http://cacm.acm.org, features more than a dozen bloggers in the BLOG@CACM community. In each issue of Communications, we'll publish selected posts or excerpts. twitter Follow us on Twitter at http://twitter.com/blogCACM http://cacm.acm.org/blogs/blog-cacm Mark Guzdial questions the practice of teaching programming to new CS students by having them practice programming
Photo by Linux Screenshots こんにちは。谷口です。 エンジニアの皆さんは、プログラミングをする際にどんなフォントを使用していますか? 「特にこだわりないからデフォルトのまま」という方も多いとは思いますが、プログラミング中は大量の文字を読んだり書いたりし続けるわけですから、なるべく可読性が高くてストレスが少なく、また自分の気に入ったフォントを見つけた方がよいのではないでしょうか。 そこで今回は、エンジニアの皆さんにお勧めの、プログラミングに最適な無料フォントを11個ご紹介いたします。 ■どういうフォントが見やすいの? フォントには、セリフ体というものとサンセリフ体というものがあります。 セリフとは、文字の線の端につけられる「ひげ」のような、線・飾りのことを言います。 例えば、上の図でいいますと、上のフォント(MS明朝)がセリフ体、下のフォント(MSゴシック)がサンセ
「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver) というイベントが開催された。 ぼくも会場係としてスタッフ参加。 「駅すぱあと」の歴史から技術、開発のマネジメント手法に至るまで、幅広い話が聞ける良いイベントだった。 いろいろな話が聞けたのだけれど、僕は特に佐藤さんの「『駅すぱあと』新しい開発基盤の研究」がおもしろかった。 まだ開発途中で、実際の駅すぱあとには組み込まれていないそうなのだけれど、佐藤さんは「駅すぱあと」の運賃計算のDSLを研究・開発しているという。 曰く、鉄道の運賃計算は泥沼である。単純に距離や、目的地までの駅数などで運賃が算出できればよいが、鉄道の運賃計算には無数の特例がある。 下記リンク先に、JRの運賃の特例計算が列挙されているので、ちょっと見ていただきたい。 ……お分かりいただけただろうか。現在の「駅すぱあと」では、これらの特例がすべ
Rich Geldreich's Blog: Things that drive me nuts about OpenGL Valve社員のRich Geldreichが、OpenGLの設計が古臭すぎることについて不満を爆発させている。 OpenGLについてムカつくことを脳内ダンプしてみる(これは個人的な件秋であって、Valveや同僚の見解ではない。あと、ここ数年、OpenGLと格闘してきたので、今日は機嫌が悪い)。これを投稿する理由はこうだ。GL APIには再設計が必要だ。というのも、思うに、MantleやD3D12がどうせ昼飯前にOpenGL APIを駆逐してしまうだろうから、この問題については、今考える必要があるのだ。 ここに見れば些細な問題もある。単にAPIのトレースの問題というのもある。しかし、それらの問題が積み重なって、他の開発者にGL APIという環境に飛び込むよう誘うのを躊
∗ 1 semantics of programming languages recursion ∗ 59 (2007), 180–191 1 2 2.1 fact(x) ≡ if x = 0 then 1 else x × fact(x−1) well-defined Z * Z Z * Z F : (Z * Z) → (Z * Z) F(f)(x) = 1 (x = 0) x × f(x − 1) (x 6= 0, f(x − 1) ) ( ) F F fact fact [[fact]] : Z * Z [[fact]](x) = ( x! (x ≥ 0) ( ) 2 F f [[fact]] F([[fact]])(x) = 1 (x = 0) x × y (x 6= 0, [[fact]](x−1) = y) ( ) = ( x! (x ≥
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
例外やエラー、それにまつわる各種言語の取り組み等を共有しましょう。 11月末までに書き手が集まらなかった場合は主催者による独りAdvent Calendarと化します。 集まらなかったので残念ながら独りAdvent Calendarと化しました。 追記 独りAdvent Calendarですが、以下の理由で頓挫しました。6日目以降はお好きにご活用ください。 http://qiita.com/Kokudori/items/3a953c00012408f76ab9#%E4%BE%8B%E5%A4%96-advent-calendar-2014%E3%81%AE%E7%B6%99%E7%B6%9A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
Password confirmation Required Password does not match. OK
なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか?画面にボタンが多いほど、マニュアルが厚いほど初めてのユー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く