パイプライン指向JSON処理プログラミング言語 jq - 檜山正幸のキマイラ飼育記 (はてなBlog)
jq（https://stedolan.github.io/jq/）の紹介では、「JSON処理のワンライナー〈一行野郎〉としてめちゃくちゃ便利！」とアピールするのが定番です。もちろんそれは本当で、「めちゃくちゃ便利！」です。が、実は jq は、ワンライナー記述にとどまらない、かなり本格的なプログラミング言語です。 JSON処理のためのDSL〈Domain Specific Language | 領域特化言語〉なので、汎用言語ではありません。しかし、汎用言語が備えている言語機能の一部（関数定義、モジュールシステムなど）を jq も持っています。また jq は、独特で楽しいプログラミング・パラダイム -- “パイプライン指向”に基づいて設計されています。 この記事では、ワンライナーを超えた jq の使い方と、プログラミング言語としての jq の特徴を紹介します。長い記事になってしまったので、一
メイヤー先生の偉大さとCommand-Query分離 - 檜山正幸のキマイラ飼育記 (はてなBlog)
バートランド・メイヤー（Bertrand Meyer）先生は、とにかく偉大です。局所的には、無理筋な例え話や強引な主張で僕らを笑わしてくれるのですが、全体としては実にまったく正しいことを言っています。 メイヤー先生の主張のなかでも、僕がもっとも影響を受けて、はてしなく役立っているのは「Command-Query分離の原則」です。オブジェクトやシステムのインターフェイス＆実装を「CommandとQueryに分けろよ」という提案。Commandは値を持たず、副作用（つうか、主作用だけど）だけを持ちます。Queryは副作用を持たず値だけを返します。 Commandとは何であるか、Queryとは何であるか、副作用を持つ／持たないとは何であるか -- これらの概念は、日常直感に頼るだけではなくて、正確に定義することができます。 Queryが副作用を持たないことから、同じQueryを二度発行すると、同
どうやら人間のようだ - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日の記事「奇妙なコメント、人が書いてる？自動生成？」の『縮約（縮退）自然数』さんは、ワードサラダ生成器やソフトウェア・ロボットではなくて、生きている人間である可能性が高いですね。 『縮約（縮退）自然数』さんのコメントは、検索で容易に見つかります。独特の、しかし安定した文体で書かれています。 2019-02-07 https://blog.goo.ne.jp/mh0920-yh/e/bc8148f070619f642e828884f2c0e567 あたまから、【西洋数学の成果の超越数（［ｅ］）と円周率（π）と無限（∞）と虚数（ｉ『動的作用を持つ』）】と【１ ０】の［数学的思考］（身体化された心）との6つのシェーマ（符号）を受け入れて、【［桁表示］の［０ １ ２ ３ ４ ５ ６ ７ ８ ９］による十進法】の言葉（言語）が生まれ、何の矛盾もないことが【数そのモノ】の「言語」（数学概念）であり、
誰も書かないCoq入門以前の話 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「WindowsへのCoqのインストール」： 事情があって、AgdaかCoqを触ってみようか、と。 事情というのは、個々の命題の証明（確認）は割と簡単そうだが、命題がイッパイあるのでウンザリな状況のことです。家計簿の計算が筆算だと面倒だから電卓を使いたい、という状況と同様です。 それでCoqのインストールは済んだのですが、処理系の使い方が分からない。個々の操作は覚えていけばいいのでしょうが、そもそもCoq処理系が何をするものなのか？ が理解できないのです。Web上にCoqの解説は幾つもあるのですが、「いやいや、そうじゃなくて、それ以前のことがサッパリわからんのですけど」という感じ。スタートラインに立てない。 それで、「Coqの解説」じゃなくて「Coqの仕様」を読んだほうがいいのかも、と https://coq.inria.fr/distrib/current/refman/ （リファレンス
クロージャなんて貧乏人のオブジェクトだろ - 檜山正幸のキマイラ飼育記 (はてなBlog)
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html ： closures are in fact poor man's objects (in his opinion). ...snip... A closure is an object that supports exactly one method: "apply". Christian Queinnecは、 closures are a poor man's objects と言っている、一方、Norman Adamsは、 objects are a poor man's closures と言っている、と、そんなことみたいです。「クロージャはよく知らないがオブジェクトなら知ってる」という人は多そうなので、「クロージャとは、貧乏人のオブジェ
gulp問題ひきずり：ウォッチがまたおバカ過ぎる - 檜山正幸のキマイラ飼育記 (はてなBlog)
「最近のビルドツールって何なの？」において、gulpは「腕力はあるが知性を持たない」、ゴレライ的というかゴライアス的というか…、そんなツールだと述べました。二、三、後から思ったことがあるので追加します。 内容： プロジェクトは肥大しちゃうことがある ウォッチをいちいち手で書くのかよー OMakeと比較してみる ウォッチはこうでなきゃ じゃ、OMakeがいいのか？ プロジェクトは肥大しちゃうことがある 「そもそも大した事はしないのでシンプルなツールgulpでも十分」ということなら、「そうですよね」と同意して話はオシマイです。でもね、gulpを使うプロジェクトが、ほんとに小さくて簡単なものなんでしょうか。 目の前に、10種のプログラミング言語が混じった2000ファイルのソースコード群がいきなり与えられたとき、「よしっ、gulpを使おう」とはならないと思うのですが、小さなプロジェクトが（良くも悪
最近のビルドツールって何なの？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
TypeScriptでは、コンパイルが必要です。プログラムをブラウザーとNode.jsの両方で使おうとすると、さらに加工が必要です。ミニファイだの文書も作るだのすると、ちょっとしたビルドプロセスとなるので手作業では辛くなります。 今更Makeでもないよなー、と思い、最近のビルドツールを試してみました。 内容： 流行りすたりが激しすぎる gulpを使ってみる：こんなサンプル gulpのビルドスクリプト タスクランナーってのはビルドツールとは違うのか？ ビルドツールは進化したのか 参考資料： 例題のファイルとコマンドの一覧 ソースファイル 追加の話： gulp問題ひきずり：ウォッチがまたおバカ過ぎる 流行りすたりが激しすぎる 「確かGruntってツールがあったよな」と、インストールと使い方を調べていると、やたらにgulpって単語が目立つんですよね。Gruntのライバルの新興勢力らしいです。 「
実例で見る JSONスキーマ vs Catyスキーマ - 檜山正幸のキマイラ飼育記 (はてなBlog)
http://return0.info/note/2014-11.html#id2014-11-26 ： 俺は今でもCatyスキーマが今のところ世界でもっとも使いやすいスキーマ言語だと思っている Kuwataさんや僕がこういうことを言うと手前味噌なわけですが、実際のところCatyスキーマより書きやすいスキーマ言語は見当たらないです。 実際に仕事に使ったスキーマ記述の例を挙げましょう。WebサイトでWebフォントを使う状況で、フォントに関するメタデータをJSONファイルに保存しておくことにします。そのJSONファイルのデータ形式を定義するものです。 スキーマ記述ファイルは次のコメントから始まります。'/**' から始まるドキュメンテーション・コメントは、単なるコメントではなくて、処理系に認識されてヘルプやマニュアルの生成などに使われます。コメント内はWiki記法が使えます（以下の例ではこれと
WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記 (はてなBlog)
分散バージョン管理システムの利用は拡大しています。そのなかでも最も人気のあるツールはGitでしょう。しかし、GitをWindowsで使うのはなかなか困難でした。 Windows向けのGitであるmsysGitは、bashのコンソールを出して、最小限のUnix風コマンドライン環境を提供するものです。これは使いやすくありません。もう一つの選択肢であるTortoise Gitは、Windowsのエクスプローラー（ファイルマネージャ）に統合されたGUIツールですが、僕は「なんか違うな」と感じてました -- これは個人の感性の問題ですが、ファイルマネージャに横付けすることが、分散バージョン管理システムへの良いUIを提供するようには思えないのです。 ところが、最近は事情が大きく変わっています。使いやすいGUIツールとして、2013年6月に正式公開されたSourceTree for Windowsが存在
目で見えるだけじゃなくて、機械可読なデータをくれー！ - 檜山正幸のキマイラ飼育記 (はてなBlog)
奥村先生の論説『「ネ申 Excel」問題』の指摘には強く同感・同意します。僕も、2011.3.11東日本大震災のとき、Web上の情報が目視でしか確認できないもの（画像やPDF）があり困惑しました。この話は、災害時だけのことではなくて、Linked Open Dataの文脈でティム・バーナーズ=リーが叫んでいた「Raw Data Now!」にも通じます。 僕自身に関わる話をしましょう。 僕の今の事務所は低地にあるので、目黒川が氾濫すると浸水の危険があります。次のURLにアクセスすると、目黒川の水位をほぼリアルタイムにグラフ表示してくれます。 http://dim2web09.wni.co.jp/megurocity/obssuii/40220043600000248_suiigraph10.html たいへんにありがたい情報なんですが、水位は画像なんです。次のURLの画像が定期的に更新される
メイヤー流の契約となんでもケーキ屋さん - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日の記事の補足。 メイヤー流の契約とは、ホーアの表明の変種に過ぎません。しかし、それを提供者（業者）と顧客のあいだの約束事という比喩を使った点がメイヤー先生の秀逸なアイデアです。そもそもメイヤー先生は比喩が大好きで、ときに牧場の牛だのカタマラン・ヨットだのと無理筋になってしまうこともあるのです。 今日は僕もメイヤー先生にならって、提供者にとって契約がきびしくなることについて、かなり強引な例え話をしてみます。 入力は持ち込みの素材、出力はケーキ すこし前に野菜を使ったケーキが話題になりましたが、柿沢安耶さんのお店はウチの近くです。例え話として、いろんな素材からケーキを作ってしまう架空のお菓子屋さんを考えます。 お客さんが何かしら素材を持ってくると、それからケーキを作ってしまう、というサービスがあるとしましょう。このサービスの要点をメイヤー流の契約で書けば、fがケーキを作る作業だとして re
絵で分かる！ 主キー／外部キーのアホらしさ - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日と同じ話題を繰り返します。しかし今日は、誰にでもわかるように絵解きで説明します。 デイヴィッド・スピヴァックのデータベース理論の特徴を僕は「驚嘆すべき単純さだ」と言っていますが、圏論を使っているというだけの理由で、「関係データモデルのほうが分かりやすいんじゃないの？」と思っている人はいるでしょう。いいえっ、関係データモデルは複雑で難解です。いったんスピヴァック理論に慣れてしまえば、関係データモデルが無駄に晦渋だったことが分かるでしょう。この記事は、その無駄な晦渋さ＝アホらしさを 絵を使って解き明かします。 若干あおり気味の口調なので、より理論的な背景は昨日の記事で確認してください。 内容 例題：勤務先の電話番号を知る スピヴァックのモデルでは 関係データモデルではどうなる 主キー／外部キーはハードウェアのメモリ番地のようなもの デイヴィッド・スピヴァックのこと 例題：勤務先の電話番号を
関手的データモデルをどう説明するか？ 考えてます - 檜山正幸のキマイラ飼育記 (はてなBlog)
http://d.hatena.ne.jp/m-hiyama/20130128#c1359767497 : データベース技術者が「これを知らないのは不幸」と思えるので、（可能な範囲で）紹介はしようかな、と。 「これ」とはもちろんスピヴァックの関手的データモデルです。「データベース技術者」つうより、データベースに多少とも関わるすべての人にとって関手的データモデルは福音となる可能性があると思っています。RDBに限らず、現存するほとんどすべてのデータベース的システムに対して、極めて単純で統一的な記述を与えてくれます。データマイグレーションのように、これまでは途方に暮れていたような現実的な問題を鮮やかに解いてくれます。 「これ」を紹介する／説明する価値は十分にあります。僕自身が、すぐにでも実務的に使いたいと思っています。しかし、スピヴァックの論文群を要約したら関手的データモデルの説明になるかという
URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、ソフトウェアシステムの構造や処理の流れを絵で描くのが大好きです。 つうと、「UML図か」とか思われそうですが、UML図には気力が湧きません。 理由1：ナントカ図、カントカ図といっぱいありすぎる。 理由2：オブジェクト指向設計の影響が強すぎる。 UMLから派生したSysMLだと、図の種類も少ないし、オブジェクト指向風味も薄まっているようです。それでも僕には面倒な感じです。「フローチャートをめぐる迷信と妄言と愚昧」にも書きましたが、箱と矢印だけくらいの、少数の要素からなる絵がいいのです。 内容： ロバストネス図 手書きにサイコー バウンダリーとインターフェイス まとめ ロバストネス図 絵にするのは好きだがモノグサである僕にピッタリだと思えるのがロバストネス図です。ロバストネス図の要素は3つしかありません。ユースケース図の要素を入れても5つです。「ロバストネス図の概要」（http://ww
フローチャートを復権させよう -- 2020年代のプログラミングへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「悟りやヒラメキがほんとに大キライだ 」という記事を書いた背景には、ユースケースの「主／副シナリオ」、「<<extend>>, <<include>>」とかの概念にウンザリしたことがあります。あれから後も、この件がどうも気にかかっていて、『ユースケースの適用：実践ガイド』（asin:4894711869）という本を恵比寿の有隣堂で見つけてすぐ購入しました。 この本には、僕が疑問に思っていた点が説明してあって、理解に役立ちました。ある程度は理解できた事と、その内容に賛同するかどうかは別問題でして、（理解してもなお）納得のいかない点は多々あります。その話は、まーいずれするかも。 ところで、この『ユースケースの適用：実践ガイド』の第5章「ユースケースを図で表現する」の冒頭に次のような文があります。 これまで、長い時間をかけてユースケースのテキストを書いてきました。しかし、ことわざにもあるとおり、
Wiki処理系を作る前に知るべきこと／考えるべきこと - 檜山正幸のキマイラ飼育記 (はてなBlog)
Wiki構文（Wiki記法のルール）は山にようにイッパイあります。 「新たにもう1つ構文を付け加えても別にいいだろう」と考えるか、「これ以上新しい構文を増やしてはいけない」と考えるかは人によるでしょう。僕は、「集約・統合してWiki構文を減らすべきだ」と考えています。それで、標準的なWiki構文としてWikiCreole 1.0を採用し、KuwataさんがCreoleパーザーを実装しています。 ところが、WikiCreoleの構文記述が曖昧過ぎてサッパリわからんのです。Kuwataさんもイライラしている様子。このような状況はWikiCreoleに限りません。たいていのWiki構文の記述はイイカゲンです -- いやっ、仕様書があるだけでマシなのです。イイカゲンな仕様に適合した（conformantな）処理系を作れと言われてもそりゃ困りますわな。 WikiCreole仕様の曖昧さは以前にも話題
この機会にマスターしようぜ、正規表現、構文図、オートマトン - 檜山正幸のキマイラ飼育記 (はてなBlog)
正規表現と構文図について解説します。オートマトンについても詳しく述べます。オートマトン・スゴロクで遊びましょう！ 世間でよく知られている／使われている概念・方法にはこだわらず、僕（檜山）の感覚で一番わかりやすいと思われる筋書きと用語法／図式法を使って説明します。この記事に目を通して“感じ”が掴めたら、形式言語理論の教科書を読み始めることが出来るでしょう。 [追記]この記事の内容に対する具体例は、「正規表現とオートマトン：なんだ簡単じゃん、JavaScriptによる実装」にあります。[/追記] 内容： 正規表現 正規表現の例 構文図 基本記号 連接 選択 省略可能 繰り返し ストレートワイヤーによるレイアウト調整 有限状態オートマトン 有限状態オートマトンの実行 バックトラックと先読み スゴロクとオートマトン コマをたくさん使うスゴロクと並列処理 非決定性オートマトンと決定性オートマトン 正
お絵描きで学ぶ・無限正規ツリーとBNF(バッカス／ナウア形式) - 檜山正幸のキマイラ飼育記 (はてなBlog)
久々のお絵描き講座です。10枚の絵を描いたぞ（って、落描きみたいなモンですけど）。 有向グラフは計算科学（コンピューティング・サイエンス）で頻出する大事なデータ構造です。コンピュータで扱えるのは有限グラフですが、無限グラフが登場しないのかというと、そうではありません。コンピュータでも、可能性として無限となりうるデータ構造を扱います。とはいえ、何の秩序もない無限データはさすがに扱いにくいので、有限的に定義できる無限構造が興味の対象となります。 ここでは、無限な有向グラフのなかで最もよく使う無限ツリーを考えます。さらに、次の条件を満たすものを例題に使います。 末端のノード（リーフノード）には整数の値が付着している。 中間の分岐ノードは特に値を持たない。 絵を描くときは、末端ノードには単に整数だけを書き、中間ノードは黒丸にします。ルートノードを識別するためには、「ルート」とラベルを書いた矢印を使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
この広告怖いよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
