チェスタートン「なぜフェンスが建てられたのかわかるまで、決してフェンスをとりはずしてはならない」 - 発声練習
昨日、Twitterのタイムラインで「なぜフェンスが建てられたのかわかるまで、決してフェンスをとりはずしてはならない」という警句の出典が見当たらないというツイートが流れていた。 私がこの警句を知ったのはこちらのエントリーから。 d.hatena.ne.jp チェスタートンという方の警句らしい。Tumblerでチェスタートンの言葉を引用している本の紹介と該当部分の訳を載せているページがあった。 http://whym.tumblr.com/post/203118545/なぜフェンスが建てられたのかわかるまで決してフェンスをとりはずしてはならないwhym.tumblr.com 英語圏では当然有名みたい。en.wikipediaにそのものずばりのページがあった（しかも、Wikipediaの注意事項として。） Wikipedia:Chesterton's fence - Wikipedia 上記の
JavaScript engine for Internet of Things
JerryScript is the lightweight JavaScript engine intended to run on a very constrained devices such as microcontrollers: Only few kilobytes of RAM available to the engine (<64 KB RAM) Constrained ROM space for the code of the engine (<200 KB ROM) The engine supports on-device compilation, execution and provides access to peripherals from JavaScript. To learn more, please visit the project on GitHu
Smallest 32-bit ARM Cortex M0 Microcontroller - Silicon Labs
The EFM32™ Zero Gecko is part of our ultra-low power, energy-friendly, 32-bit microcontroller (MCU) portfolio. With a unique combination of the powerful ARM® Cortex®-M0+ core, innovative low-energy techniques, short wake-up time from energy-saving modes, and a wide selection of peripherals, the Zero Gecko is ideal for battery-operated applications and other systems requiring high performance and l
Android らしい Java - 2. 寿命
寿命、ライフサイクルのはなし。(Part.1 はここ) Android の中には、決められた寿命を持つ重要なオブジェクトがいくつもある。代表例は Activity. View も Fragment もプラットホームによって寿命が決められている。 Java は誰かに決められた寿命を扱うのがあまり得意でない。多くのオブジェクトは Java 自身の GC が寿命を決める。GC があるからプログラマは寿命について悩まなくていい。そんな態度が従来の Java にはある。C++ のように神経質な寿命管理は出番が少ない。 Java でも File のような OS の資源は GC でなくプログラマが寿命を決める。Socket なんかはもう一段厄介で、相手側から閉じられると勝手に死んでしまう。そして死んだオブジェクトを触るコードは呪いの例外に見舞われる。 勝手に死ぬ Activity や View の性質は
タイラー・コーエン 「水爆の原料は何だ？ ～アーメン・アルチャンが手掛けた世界初の（そして歴史の闇に葬り去られた）『イベントスタディ』をここに再現～」（2014年5月12日）
訳注；ちなみに、アルチャン本人は、この件について次のように回想している（“Principles of Professional Advancement” in 『The Collected Works of Armen A. Alchian（vol. 1）』, pp. xxv～xxvi）。「ひょんなことから、1946年にUCLA（カリフォルニア大学ロサンゼルス校）の経済学部に籍を置くことになった。その前年の1945年に、UCLAの近くのサンタモニカに、たまたまランド研究所が設立されたばかりだった。そして、UCLAの同僚のアレン・ウォリスが、ランド研究所の設立に奔走していたヘンリー・「ハップ」・アーノルド元帥とどういうわけだか非常に仲がよかった。私が（アレン・ウォリスにそそのかされて）ランド研究所で働くに至るまでには、こういった偶然の積み重ね――ゴルフでバーディーがとれるのと引けを取らないく
不確実さを受け入れる — A17Y (1)
ソフトウェア開発に関する認識で大きく変化したもののひとつは不確実性の扱いではなかろうか。古いソフトウェア開発が「複雑さ」を、Agile が「変化」を主要な難しさ、戦うべき敵とみなしたように、今日のソフトウェア開発は「不確実性」との戦いを大きなテーマに据えていると思う。プログラマが不確実性に向ける眼差しは開発プロセスに大小様々な影響を与えている。「達人プログラマー」とその世代は、この変化を捉えていない。 ソフトウェア開発には昔から不確実性がつきものだった。たとえば見積もりでは The Cone of Uncertainty なんて話をする。現代的なソフトウェア開発が昔と違うのは「不確実さは放っておいてもなくならない」ことを認めたことだと思う。The Cone of Uncertainty が象徴する昔のソフトウェア開発では、不確実性は一時的なもので目の前の嵐をやりすごせばいいと考える。極端に
週報仲間
仲間内で週報を送り合う Snippets メーリングリストをはじめてからもうすぐ一年経つ。仕事じゃなくて課外活動の話。 自分の勤務先では週報のことを Snippets と呼ぶ。(このへんにもうちょっと詳しい意見書がある。) ただし週刊とも限らず報告する相手も決まっていない。だからか weekly report とは呼ばない。 提出は義務でなく、書いていない人も多い。自分もながいことサボっていた。今は書いている。社内のしょぼい週報サイトにテキストを投稿するだけの素朴なもの。仕事の進まなさが直視できていい。他人の記録も読める。似たようなことをしている会社は多いと思う。 その仕事 Snippets の真似を課外活動でもやればいいと思い立ったのが今年のはじめ。友達に声をかけ、数人ではじめた。 毎週日曜の夕方、リマインドのメールが届く。そのメールに返信する形で各々が週報を送る。週ごとのスレッドができ
www.cablemap.info has a new home.
After maintaining the map for years, it has become difficult for me to find time to continue the work. Fortuantely, there is a team who is keen to take the project further and improve on it. The map and data will always remain free, and I'm confident the new custodians will do the project justice. The new home will be: https://www.networkatlas.org/ The map is available at: https://dev.networkatlas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Platform for Internet of Things with JavaScript