ブックマーク / postd.cc (4)

  • C++11のスレッド、アフィニティ、ハイパースレッディング | POSTD

    背景と導入 何十年もの間、CやC++の標準規格は、マルチスレッディングや並行処理を「その標準の範囲を超えたもの」として扱ってきました。標準規格の目的である”抽象機械”の力が及ばない、”対象依存”という影の世界においてです。メーリングリストやニュースグループの質問には並行処理に関するものが山ほど寄せられましたが、それらにすぐに突き返された回答は「C++はスレッドには関知しません」という何とも冷淡なものでした。この件によって当時のことを思い出す人々は、今後も絶えないでしょう。 しかしC++11の登場で、そんな状況に終止符が打たれたのです。C++標準化委員会は、時代の流れに乗らないと、この先C言語が取り残されてしまうと悟ったのでしょう。彼らはスレッドや同期メカニズム、アトミック操作、メモリモデルなどの存在に、ようやく気付いたわけです。そして標準規格として、C++コンパイラやライブラリのベンダーに

    C++11のスレッド、アフィニティ、ハイパースレッディング | POSTD
  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
  • 2016年、C言語はどう書くべきか (前編) | POSTD

    (訳注:2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注:著者のMattより、「文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例: 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり

    2016年、C言語はどう書くべきか (前編) | POSTD
  • Railsの基本理念 : Railsの生みの親が掲げる8つの原則 | POSTD

    (訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基原則にあると考えています。 この基原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい

    Railsの基本理念 : Railsの生みの親が掲げる8つの原則 | POSTD
  • 1