キャッシュと向き合う、キャッシュと共に生きる / cache patternPHPerKaigi 2024の登壇資料です。 https://phperkaigi.jp/2024/ - https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching - https://soudai.hatenablog.com/entry/cache-strategy
まるで詩のような日本語で書いたプログラム - 実際に動きます - Qiita
はじめに 日本語プログラミングの議論が続いていますが気分転換にこんな奇抜なプログラムはどうでしょうか。 経緯 木村 明さん 1 の傑作かつ芸術的な日本語プログラムに「ポエム（Poem）」があります。 1986年に作られました。当時はPC-9801やFMRなどMS-DOS環境のPCが全盛で、このプログラムもPC-9801向けに書かれていました。プログラムは大変面白いのですが、そのような事情で現在では実際に動かすことはできず長いこと眠っていました。 一方で、Mindのほうは長らく開発していたGUI版が動き始め、Poemが使うグラフィック描画もできるようになったことから、Poem を実際に動かしてみたくなりました。9801グラフィックの互換処理を差し込むことでなんとか動かすことができました。動いたときは「ああ、こんなプログラムだったな」とちょっと感動しました。 公開について 氏の許可を得てソース
Nimで知る「オブジェクト指向をする/しない」ということ
Nim は、「もしアラン・ケイがオブジェクト指向と言わなかったら」という歴史の if を感じさせてくれる言語だと思った話をします。 私自身は Nim 初心者です。細部の「こいつ慣れてないな」感はご容赦ください。この記事は、この言語については初心者だけれど、プログラミング言語とパラダイムを考えるうえでとても価値があると思った気付きがあったのを、図々しくも記事にしました。複数のプログラミング言語を歴史的な観点で評価するうえで、Nim を通して 70 年代以前の言語と 80 年代以後の言語、具体的には、C with classes と C++ の境界線を見つめ直すことができるんじゃないかと思います。 ズバリ言うと、Nim はアラン・ケイのオブジェクト指向が通じない言語です。 Nim の言語標準には class キーワードがありません(マクロを作れば語句の拡張は可能ですがオプションです)。が、そん
プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生：DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム
2で割ることと3で割ること - Qiita
この記事でお題にするのはCPUレジスタ上の整数除算です。以下、単に除算とも書きます。 除算は非常に高コストな演算なため、コンパイラは最適化によって、できるだけ整数除算を別の計算に置き換えようとします。 最適化ができる場合の一つとして、割る数が定数である場合があります。頭のいいコンパイラは、除算を乗算とビットシフト等を駆使した演算に置き換えます。この記事では、そういった最適化の背景にある理屈を部分的に解説します。 計算機環境としてはモダンなx86 CPUを仮定します。したがってレジスタは32/64ビットであり、負数は2の補数表現になっています。ある程度は他の命令セットでも通用する話になっているかもしれません。 そもそも整数の除算とは プログラミングにおける整数の除算の定義について確認します。整数$n$を整数$d$で割るとき $$ n = q \times d + r $$ が成り立つように除
(解説) はてなブックマークにおけるアクセス制御 - 半環構造に基づくモデル化 - Hatena Developer Blog
こんにちは、シニアアプリケーションエンジニアのid:taraoです。この記事ははてなデベロッパーアドベントカレンダー2015の10日目です。昨日はid:tapir320によるはてなの組織開発についてでした。 先月開催されたWebDB Forum 2015で、「はてなブックマークにおけるアクセス制御: 半環構造に基づくモデル化」というタイトルの発表をしました。 はてなブックマークにおけるアクセス制御 - 半環構造に基づくモデル化 from Lintaro Ina 発表資料には多くの方に興味をもっていただけたようですが、わかりにくい点も多かったのではないでしょうか。スポンサー企業としての技術報告セッションとはいえ学術会議での発表なので理論面と独自の工夫点にフォーカスした内容であったり、口頭での発表のしかたに大きく依存したスライドの遷移方法になっているので、この資料だけで細かいところまで理解しよ
2008/10 b ネットと匿名について
s-e-l-f n-a-rr-a-t-i-v-e. /01 [6] (08:35) oya、ゆうべはパソコニの電源を切らずに眠ってしまったらしい。 よくないこった。 /31 [5] (08:02) ああ、シメキリが…。(本来は締切ではなくて、納期というべきであ) けさも寒いね! (23:17) わざと? わざと。 さて、きのうはまた自分が書いたコードで、 やたらと原始的なバグを発見してしまった。だいたい、以下のようなコードである: typedef struct _buffer { char* ptr; int size; int len; } buffer; /* バッファbufの末尾に nバイトの文字列を追加する。 */ void append(buffer* buf, char* s, int n) { if (buf->size < buf->len+n) { /* バッファが足りな
マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi
シングルスレッドではもう遅い。 以前にマルチコア時代の高速サーバーの実装で、「ネットワークIOはマルチスレッドで動かすが、その他の部分はシングルスレッドで動かす」というIOアーキテクチャの実装（mp::iothreads）を紹介しました。iothreadsはロジック部分をシングルスレッドで書けるため実装の手間を抑えることができ、ネットワークIOがボトルネックになるプログラムには特に適していると思われます。 しかし実際にiothreadsを使ってプログラムを書いてみると、非常に負荷が高い状況でシングルスレッドの部分の処理速度がボトルネックになってしまうことがありました。 そこでマルチコアCPUの性能を引き出すために、徹頭徹尾マルチスレッドで動かすIOアーキテクチャを実装してみました。 1つのスレッドが、ある時はepoll_wait()し、ある時はread(2)を行い、ある時はイベントを処理す
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
Martin Fowler's Bliki in Japanese - 言語ワークベンチ
以下の文章は、Martin Fowler による 「Language Workbenches: The Killer-App for Domain Specific Languages?」 の日本語訳である。 ソフトウェア開発における新しい考えの多くは、実は古い考えの新しい組み合わせ方です。この記事では、その新しい組み合わせ方のひとつ、私が「言語ワークベンチ(Language Workbenches)」と呼んでいるツールについて説明します。これは、現在広まりつつある考え方で、たとえば、Intentional Software、JetBrainsのMeta Programming System、MicrosoftのSoftware Factoriesなどが例として挙げられます。これらのツールは古い開発スタイルを採用しており、私はこれを「言語指向プログラミング(language oriente
クラスっぽいJavaのコンポーネントとパイプっぽいDelphiのDBアクセス：Allegro Barbaro：オルタナティブ・ブログ
最近Delphiのコンポーネント開発に関する記事を翻訳していて、JavaとDelphiのコンポーネントの違いを改めて感じています。EJBがはやり始めた頃、Javaの世界では、コンポーネントの流通を活性化するとかいろいろ試みがあったけれども、どうも当初の意図したところには到達していないように思っていたのですが、そういえば当時も、「そもそも、コンポーネントの部品としての立ち位置に違いがあるんじゃないの？」と感じていたのでした。 コンポーネントを簡単に言うと「プログラム部品」なのですが、大抵の場合、その実体はクラスの一種です。では、クラスとコンポーネントの違いは？と言われると、なんとなく「コンポーネントのほうがより抽象化されている」とか「部品として独立性が高い」とか、分かったような分からないような回答になってしまいます。 Delphiに代表されるようなビジュアルRADツールは、フォームと呼ばれる
型システムの理論の影 - プログラマーの脳みそ
プログラムにおける型システムってのは数学・論理学の型理論を基盤にしていて、抽象的なもやもやとした代物。この型システムの理論を現実に実装したものとして、多様なプログラム言語が存在するわけだ。 鶏と卵という話だとどっちなんだろう。実装が先でそれを理論としてまとめたって感じなのか、理論がまず考えられてプログラム言語が実装されたのか…。最初のプログラム言語というと1954年に登場したFORTRANで、IBMのジョン・バッカス氏*1によって考案された。FORTRANにはいくつかの数値型がある。この頃に型システムの体系的な理論ができていたとは思えないから多分、実装が先行なんだろうな。 理論としての型、そのJava実装のクラス 型システム(type system)でいう型(type)は型理論に基づくわけで、数学的な抽象概念に近い。例えば僕らが日常生活で数学的概念である1/3という値を厳密に使うことはない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
404 Error - File Not Found
数理科学的バグ撲滅方法論のすすめ---目次 | 日経 xTECH（クロステック）
言語ワークベンチは究極的には完全にプログラミング方法を変えるかもしれない