Blufflog

This blog is bluff

Bluffbox

Bluffbox というマジックのレパートリーなどを管理できる Web サイトを作ったので公開します。

https://bluffbox.herokuapp.com

マジックのレパートリーを管理していないと、自分がどんなマジックができるのかが分からなくなりがちです(少なくとも自分は)。また、演技時間やテーブルの有無などの状況に応じたルーティンを組むのも面倒です。
紙の手帳・EvernoteExcel などでレパートリー管理をしている場合も、これらはレパートリー管理に最適化されたツールではないため何かと不便です。

そこで、マジックのレパートリー管理に最適化したサイト Bluffbox を作りました。Bluffbox ではトリック・ルーティン単位でレパートリーを柔軟に管理できます。もちろん、スマホでも PC でも利用可能です。
Bluffbox ではトリック・ルーティンに加え、以下の情報を管理できます。

  • 製品(e.g., 書籍、レクチャービデオ、マジックグッズ)
  • YouTube 動画
  • マジシャン

また、これらの情報を相互に関連付けることもできます。
さらに、記事の投稿・コメント、ユーザのフォローといった SNS 機能もあります。

全機能を無料でお使いいただけるので是非お試しください!
(情報を見るだけなら会員登録は不要ですが、情報の登録・編集には会員登録が必要です)

なお、サイトの不具合や脆弱性を見付けられた方はこちらからご連絡いただけると助かります。ご意見・ご質問もどうぞ。

パイプ枕の魅力

意外と見過ごされがち(?)なパイプ枕の魅力を簡潔にお伝えします。

  • 安い
  • 高さの無段階調節が可能
  • 通気性が良く、蒸れにくい
  • 虫が湧きにくい
  • 洗濯機で丸洗いできるなどメンテナンスしやすい

具体的にはこんな商品を買えばいいんじゃないでしょうか。ちなみにアフィリエイトではありませんし、アイリスオーヤマの回し者でもありません。

『初めてのGraphQL』を読みました

GraphQL 完全に理解した。

  • GraphQLREST API のような(主に Web の)API を定義する技術(言語、仕様)
  • REST はリソース(データ)毎にエンドポイントを持つため、複数のエンドポイントが必要になる
  • GraphQL は API で管理するリソースをグラフで表現。これが単一のエンドポイントになる。具体的には型定義を伴うスキーマを定義
  • GraphQL のオペレーションは Query、Mutation、Subscripiton の 3 つ
  • Query:データの取得
  • Mutation:データの作成、更新、削除など
  • Subscription:データの変更を監視。具体的には WebSocket などで実現
  • クエリはグラフで表現されたデータについて、その部分グラフを取得するようなイメージ(データのグラフを木(tree)で考えると、その部分木を指定して取り出すイメージ)
  • 各オペレーションもスキーマ定義する
  • GraphQL の主なメリット
    • 必要なデータ(フィールド、カラム)のみを取得できる
    • あるリソースに関連する他の複数のリソースをまとめて一度に取得できる
    • エンドポイントが単一なので管理、保守しやすい
  • GraphQL の主なデメリット(適当に書いてるので怪しい)
    • エンドポイントが単一なので、対策しないと大量のデータを要求するクエリを誰でも簡単に送れてしまう
    • まだ普及度が低く、新規導入には学習コストなどが必要(?)
    • コミュニティ、エコシステムが発展途上(?)
  • GraphQL スキーマJSON 風で、その型定義は TypeScript 風
  • GraphQL クエリは SQL 風。ただし、RDB における SQL の対象データ表現形式が表(テーブル)なのに対し、GraphQL クエリの対象データ表現形式はグラフという点は異なる
  • 昨今は React などの影響によりとかくフロントエンドが厚くなりがち。そこで API 利用のロジックを GraphQL オペレーションのスキーマ定義側に寄せることにより、フロントエンド側で API を叩く箇所をスリム化できるということはありそう(?)
  • 本書では、GraphQL を扱うための代表的なライブラリである Apollo を用いて、GraphQL API サーバーとそのクライアント Web アプリ(React)の実装を学べる。これによって実際の開発イメージが湧いたので良かった
  • GraphQL API に対して巨大なデータを要求することへの対策も軽く学べる。ここはもしかすると REST より複雑かも知れない
  • 日本語版の付録として「Relay 各仕様解説」があり、GraphQL APIスキーマ設計の参考になる。データに一意の ID を付与する手法や Cursor Connections というページネーション機能を API 設計に組み込む手法など。ページネーション機能を組み込んでおけばリクエスト制限もしやすくなりそう
  • 本書を読むのに特別な前提知識は不要だと思うが、REST APIJavaScript、React あたりはある程度分かっているとスムーズに読める
  • 本書内にはコード含め誤植が散見される気がするので、少なくともコードについては GitHub リポジトリも参照するのが良さそう

参考

In the Bluff (Ramón Riobóo)

詰まるところ、一般的な人にとってカードを当てるというのは非常に難しい事なのだ。それ以外の全ては枝葉である。

今回は Ramón Riobóo の『Thinking the Impossible』に収録されている「In the Bluff」というカードマジックについて。本書の一番最初に収録されている手順ですが、結局これが一番良かったかも知れません。ただこの本、今は入手しづらいかも知れませんが…。

本手順の現象を簡単に説明します。まず観客が 1 枚のカードを見て覚えます。別の観客がそのカードを少しずつ当てていき、最終的には完全に当ててしまいます。

本手順はレギュラーデック 1 組かつ準備なしで演じられ、カードの選ばせ方と当て方の 2 要素で構成されています。そしてそれぞれがこの手順以外にも応用可能です。

特にカードの選ばせ方については心理的策略が満載で非常に勉強になります。何を主たる動作にするか、観客のディレクションをどこにどのように向けるか、などについてのお手本のような手順になっています。具体的には、どのタイミングで何を話すか?どのタイミングで手を動かすか?どのタイミングでそれらを終えるか?また、その際の演者の態度はどうあるべきか?といった話です。

さらに、観客によるタネの推測を誤った方向にミスリードするレッドヘリングが巧妙で楽しいです。これはタマリッツの Neither Blind Nor Stupid やピット・ハートリングの Chaos にも似た感じがあります。ただし、ここでの選ばせ方は巧妙ですがやや込み入っており、マジシャン向けという感も多少あります。なので、ノンマジシャン相手に演じる際は別の選ばせ方を採用するのも良いかも知れません。1

当て方も観客に当てさせるという点が独特で面白い上に、説明できないトリック的な柔軟性と楽しさも兼ね備えています。さらに、個人的に大好きな某技法を使ったはったり感も大変好みです。

ということで、この手順を読むためだけでも本書を手に入れる価値はあると思います。おすすめです!


  1. マジックをノンマジシャン相手に演じる場合とマジシャン相手に演じる場合について、演目や演じ方をどのように変えるべきか、あるいは変える必要はないのか、などについては別の機会に論じてみたいと思います。

選択肢を選択する選択肢について

○か□かという 2 つの選択肢があるとき、1 つの選択肢を選択する方法としてはどのような選択肢があるでしょうか?

  • A: ○と□のどちらか 1 つを選択する
  • B: ○と□の間に存在する△などの中間値を選択する
    • 中間値の数はケースバイケースで、△以外の位置に存在する▽という中間値などもあるかも知れない
    • このような中間値が存在せず、○と□の 2 値しか存在しないケースもあり得る
    • また、これは平均値や中央値的な選択肢が正しいことは全く意味せず、○や□など極端な選択肢が誤っていることも全く意味しない
  • C: 弁証法的に○と□の両方を満足する円柱のような選択肢を選択する
    • もちろんそのような選択肢が無い、あるいは見付けるのが非常に困難なケースもあり得る
    • もしこのような選択肢が見付かるなら、多くの場合でその選択肢を選択することが望ましいと思われる
  • D: ○と□の外側(?)にある☆などを選択する
  • E: 何も選択しない(適切な解なし。何も選択しない方が良いというケースもあり得る)

タナトフォビアまとめ

当記事は学術的、科学的、医学的に正しい情報を提供するものではありません。Web 上の情報のスクラップブック的な位置づけの記事だとご理解いただくのが良いと思います。強いて言えば、文化、芸術、あるいは哲学寄りの話だと思います。一応、随時更新予定です。

タナトフォビアとは?

死恐怖症(しきょうふしょう、英語: death anxiety)は、死の観念によって引き起こされる不安の症状。「ひとが死に至る過程や、存在することが止まることについて考えるときに認識され、心配になるという死の感覚 (feeling of dread, apprehension or solicitude (anxiety) when one thinks of the process of dying, or ceasing to 'be')。

引用元:死恐怖症 - Wikipedia

表記揺れ

Web 上の日本語テキストでは「タナトフォビア」表記をよく目にする印象がありますが、以下のような表記もあるようです。

  • 死恐怖症
  • death anxiety

Wikipedia

上記の他、計 20 言語で死恐怖症(タナトフォビア)の記事が存在するようです。平均値は分かりませんが、先端恐怖症Wikipedia ページは 17 言語存在するのでそれよりは多いです。よって雑に言うと、タナトフォビアは先端恐怖症と同等かそれ以上にグローバル規模でメジャーな概念と言えるかも知れません。

5 ちゃんねる(2ch

5ch のメンタルヘルス板(メンヘラ板)に「■■■死恐怖症(タナトフォビア)<スレ数>棺目■■■」というスレタイのスレッドがあり、最新は 40 スレ目の ■■■死恐怖症(タナトフォビア)40棺目■■■ です。

スレッドテンプレ

タナトフォビアとは死そのものや死に関連するものに対する恐怖症のことです。
このスレにはこんな人たちがいます。

  1. 意識の喪失による無が怖い人
  2. 死に伴う孤独や痛みが怖い人
  3. 悲惨な目や災害にあって死ぬのが怖い人
  4. 生や死そのものの不可解さが怖い人
  5. 死んで人から忘れられるのが怖い人
  6. 永遠が怖い人
  7. 身近な人の死が怖い人
  8. 生きる事やこの世の全てが無意味に感じるのが怖い人
    これらのことを考え出すと思考が止まらなくなり、恐怖・発狂恐怖に陥る人。

タナトフォビアの類義語としてネクロフォビアがあります。
しかしタナトスはもともと死を擬人化した神の名を、ネクロは死体を指すので、
ネクロフォビアというと死体、つまり他者の死を意味するときに使う習慣もあるようです。
(ただし海外では同義語として扱われています。)

引用元:■■■死恐怖症(タナトフォビア)40棺目■■■

スレッド非公式(?)テンプレ

軽く確認したところ、35 スレ目まではテンプレ的に書き込まれていましたが、36 スレ目以降のスレでは書き込まれていないようです。よって仮に非公式テンプレとして扱いますが、これら一連のスレッドの思想などを象徴する文章だと思うので掲載しておきます。

■解決方法

どれも完全な解決方法ではありません。
前スレまでに書かれていたことなど。

(1)精神疾患の一種(強迫性障害・不安神経症の延長?)だと思われるので、精神科を受診し、処方された薬を飲む
(2)時間的余裕をなくす(時間があると余計なことを考えてしまうため)
(3)子供を作る(理由的には同上)
(4)気休めになる言葉や本を探す


解決方法の
(3)子供を作る、ですが、
子供もタナトになる恐れがあるのでオススメできないと思います。
実際に、子供作ったけど子供もタナトになってしまったと
言っていた方が過去スレにおられました。


611 名前:優しい名無しさん[sage] 投稿日:2010/10/14(木) 10:59:48 id:wwYsQ6Ob
このスレを見てるとタナトフォビアには2種類あるな

一つは慢性的タナトフォビア
死に対する恐怖が常に付きまとい、倦怠感や疲労感、 無気力状態になるか
あるいは暗鬱で絶望的な気分になったり、悲哀や悲壮感に包まれる。
酷い場合は毎日死について考え、常に精神的苦痛を感じている場合もある。
夜や寝る前は特に症状が酷くなるため、寝たらそのまま目覚めないのではないか、などの不安が頭をもたげたり
恐怖感や不安によって心が休まらず眠れなくなるなどして睡眠障害不眠症を引き起こす場合もある。
よって症状が重ければ重いほど必然的に日常生活に支障をきたし、死が頭から離れなくなり
常に憂鬱でやる気が出なかったり不安に悩まされることから、鬱病に近い

もう一つは発作性タナトフォビア
死に対する恐怖やイメージが瞬間的に増長してあるレベルに達したとき一種のパニック発作状態に陥る。
やはり起こる頻度に伴わずタイミングは夜や寝る前であることが多い。
症状としては発作が起きると同時に精神的苦痛と恐怖を伴いながら動悸が激しくなり
じっとしていられなくなってベッドから飛び起きたり椅子から立ち上がったり、酷い場合は叫ぶこともある。
それらの症状は大抵長くても1分程度で収まり、一度発作が起きれば次の発作がくるまでは安静である。
発作の来るタイミングは個人差があり不定期で、年に数回の人も居ればほぼ毎日発作が起きている人も居る。
日常生活については、症状が軽い場合や寝る前のみの場合は基本的に問題ないが
重い場合は公共の場や会社・学校で発作が来ないかという不安が付きまとうことから、パニック障害に近い。

もちろん、この二つを併発している場合もある


315 : 優しい名無しさん 2016/07/24(日) 17:08:59.45 id:vM8Zi/eo
普通の一般人が、末期ガンでベッドの上で死を待つ状態になったり
ISISに拉致られて数分後に首を切り落とされる状態の時に感じている死の恐怖を、
四六時中感じているのがタナトフォビアという病
死の直前になって初めて意識するような恐怖を常に意識しながら生きている
それは宛ら、何も罪を犯していなければ牢にも入っていない死刑囚の如し
娑婆にいても死への恐怖心は何時執行されるとも知れない処刑を待つ身と変わらない

タナトじゃない一般人は大袈裟にも程があると笑い飛ばすが、
こればかりはタナトを発症した人じゃないと絶対に理解して貰えないと思う

319 : 優しい名無しさん 2016/07/24(日) 22:51:36.71 id:dJu5pmqg
>>315
これテンプレにしていいくらい完璧な代弁

私達の脳はどうしちゃったんだろうね
何でこんなに死に取りつかれているんだろう…
さっき真田丸豊臣秀吉が「死にたくない」って喚いているのを見て自分と重なったわ

引用元:■■■死恐怖症(タナトフォビア)35棺目■■■

関連書籍

「死」とは何か イェール大学で23年連続の人気講義 完全翻訳版(シェリー・ケーガン):既読

うろ覚えなので間違ってるかも知れません。

  • 少なくとも無宗教無神論的には、死の定義からして死後に「私」が死を意識することはできないので、死という状況そのものを当事者的に怖がることはできない。いま生きている「私」がいずれ死ぬということを思うことが怖い(これは別の本で読んだ話だったかも…)
  • 今後拷問を受け続けることが確定している場合など、生きているよりも死んだ方が利得が高い(マシな)場合もあり得るので、必ずしも死は悪いものとは言えない
  • また、永遠に生きなければならない(死ねない)とすると、それはそれでやりたいことが完全になくなって、文字通り生き地獄的な苦痛になり得る。この場合は死が救いになるので、やはり必ずしも死は悪いものとは言えない
  • しかし、「私」がやりたいことの量に対して人間の寿命(長くても 100 年ちょっと)が短かすぎ、死ななければ本来できたかも知れないことをできずに寿命を迎えるということは大いにある。つまり、死までの猶予が短かすぎるという点において死が悪いということはあり得る。そしてこれが死の恐怖に繋がり得る

存在消滅 -死の恐怖をめぐる哲学エッセイ-(高村友也):未読

「いつか死んでしまう」という事実を前に、どのように生きていけばいいのだろうか——。

生まれてこない方が良かった―存在してしまうことの害悪(デイヴィッド・ベネター):未読

  • 反出生主義の有名な本
  • タナトフォビアそのものを扱っているわけではなさそうだが、そもそも生まれてこなければ死の恐怖を感じることもなかったので関連は深そう

不老不死クエスト タナトフォビアの処方箋(タナトフォビア&不老不死 研究会):未読

  • 同人誌っぽいが、タイトルがそのものズバリなので一応リストアップしておく

Next.js の公式チュートリアルを全部終えました

React 同様にこちらも今更ながら、Next.js の公式チュートリアルを全部終えました。やったことの概要は次の通りです。

感想

ざっと Next.js を学んだ感想です。

  • Next.js は React ベースの Web アプリを作るフレームワーク(React にもフレームワークっぽさはある気がしますが、基本的にはライブラリ扱いが一般的だと思います)
  • リソースのロード、レンダリング、コンピュテーション、キャッシングなどそれぞれについて、いつ、どこで、どの粒度で実行するかを制御可能
  • ファイル(ディレクトリ)構成と Link component によりマルチページアプリ化可能
  • SSR してクライアントに返した HTML は JS(React 周りのコード)のロードが完了するまでインタラクティブではない。この状態のページに JS をロードしてインタラクティブにすることを「ハイドレーション」と呼ぶ
  • 基本はページ単位でレンダリング方法(例:SSR、SSG、ISR)を制御
  • dynamic() 関数(API)などを用いることでコンポーネント単位でのロードタイミング、レンダリング方法(SSR するかどうか)の制御も可能
  • React Server Components も活用するとより細かな制御ができそう(?)
  • キャッシング、CDN、エッジコンピューティング、サーバーレス FaaS (Lambda) など、Next.js は多機能でそれらをカバーしてくれる Vercel というデプロイ先は便利(GitHub 連携なども楽)
  • しかし、Next.js は OSS とは言えそのメインの開発元は Vercel であり、ベンダーロックイン的なリスクは気になる

React 公式ドキュメントをだいたい全部読みました

今更ながら React 公式ドキュメントをだいたい読みました。「だいたい」というのは、API リファレンスコントリビューティングガイドラインは読んでいないからです。前者は必要に応じて(まさにリファレンスとして)参照すれば良いかなと思い、後者はコントリビュートしたいことがあればそのタイミングで読めば十分と考えたためです。

まずはチュートリアルを実施し、その三目並べ(Tic-tac-toe)アプリのソースコードGitHub リポジトリに上げました。

応用課題的なものがいくつかあったので、このリポジトリではそれらも実装してあります。このチュートリアルはクラスコンポーネントベースなので、このリポジトリのコードを関数コンポーネントに置き換えるなどリファクタリングすると練習になりそうですが、面倒なのでやっていません。

チュートリアル完了後に読んだドキュメントは次の通りです。

  1. Installation
  2. Main Concepts
  3. Advanced Guides
  4. Hooks
  5. Testing
  6. FAQ

これから学び始める方に向けて特に重要なリソースを抜粋すると次のような感じかと思います。

最低限

A, B のいずれか。

A. 手を動かして学ぶ

  1. チュートリアル
  2. Installation

B. 読んで学ぶ

  1. Installation
  2. Main Concepts

基礎を一通り

  1. チュートリアル
  2. Installation
  3. Main Concepts
  4. Hooks

感想

一通りざっと学んだ感想としては、以下がポイントだと思いました。

  • 原則は、宣言的 UI を可能にするシンプルな JS ライブラリ(DOM 操作などは React に丸投げ)
  • ただし、レンダリングや state 更新タイミングなど、パフォーマンス上の各種最適化などのブラックボックスもある
  • JSX は React API を呼び出す JS コードのシンタックスシュガー
  • コンポーネントの状態は state で管理し、props 経由でコンポーネントにデータを渡す
  • データの流れはコンポーネントツリーの上(ルート側)から下への一方向
  • コンテクストはグローバル変数的(?)
  • ClassComponent.render() (or FunctionComponent()) → reconciliation(差分検出処理)→ commit の流れ
  • フックを使うとオブジェクト指向的なクラスインスタンスに依存せず、基本は全て JS の関数で動く世界になる
  • API を叩いて非同期にデータを取得して state を更新するなどの処理は、副作用(effect)として useEffect() 内で実行するのが一般的

P.S.

まだ日本語に翻訳されていないと思いますがベータ版の React 公式ドキュメントもあり、レンダーとコミットの説明などをざっと見る限りこちらも読むと理解が深まりそうです。

なお、今は Next.js のチュートリアル(?)を読んでいます。