エラーの伝え方を調べてて今さらNotifcation Patternを知る

    安易に例外を使ったり安易に例外をつぶしたりするコードになんか違和感があって調べてたんだけど、我らが Martin Fowler 先生の記事にたどりついた。で、

    Replacing Throwing Exceptions with Notification in Validations

    からの

    Notification

    からの

    Separated Presentation

    ですよ。

    API クライアントが UI を持つ場合、何らかのアクションに応じてサーバでエラーが起きたらそれをフィードバックする必要があって、そのためには

    • サーバ側の Error を詰め込んだオブジェクトをバケツリレー(?)1して
      • これは Model から独立しててよい
    • API（presentation）まで運んで
    • クライアントに返して
    • クライアントは Model で受け取って
    • いい具合に Error を表示するだけに集中する人に渡すといい

    って考えてたんだけど、ほぼまんま書いてあったわ…。15年前にガイシュツやったわ…。

    ※ Data Transfer Object も出てくるね

    Notification て名前は今だと UI の Pattern のようにも見えるけど、ここでは observeに対する notify くらいの意味かな。

    にしても JS ヘビーにはしない方がよいとずっと思ってたけど、間違ってなかったな。そっちに舵を切るにはフレームワークのケアしない領域の羅針盤が必要だけど Web 側の知見は不十分で、いわゆるクライアント-サーバモデルの GUI アプリケーションの知見がまさにハマってきそう。

    フロントエンドの世界では .NET のノウハウが Angular 1 辺りから入ってきてたけど、最近 Scala で DDD って話も結局 JavaEE 的な世界の話なのかなーくらいに思えてきた。あとはどんだけ言葉をそぎ落とすか、かなぁ。言葉が多いと言葉が目的化しちゃうのはフレームワークでもデザインパターンでもなんでも一緒な気がする。入り口に言葉を並べすぎるのはよくない。奥が深い程度の状態に留めておくのがよい。

    1. 別ルート作ってもよいかもしれない ↩

    guiflowとuiflowでUiFlows試してみた

      あるいは Kanazawa.rb meetup #66 に参加してきました。

      UiFlowsとは

      自分が知ったきっかけは誰かのツイート経由で

      画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール | UXデザイン会社Standardのブログ

      だったのですが、37 Signals ( Basecamp ) で

      A shorthand for designing UI flows – Signal v. Noise

      採用されている（今もなのかな？）シンプルに

      • 表示内容
      • 操作内容
      • リンク先

      を記述する言語です。

      「ツール」と紹介されることが多いみたいだけど、具体的なツールというよりは「記法」と表現した方がまだ近いかも。元のブログでは普通に手描きのものが紹介されています。（ただ、そもそも UI Flows って「名前」は存在しないような気がしませんか？）

      元のブログは英語ですが、画像だけ拾ってみても十分に雰囲気は分かります。だいたい以下のような感じになります。

      ユーザーの目にするもの
----------------------
ユーザーの操作するもの  --->  ユーザーの目にするもの
                              -----------------------
                              ユーザーの操作するもの

      guiflowとuiflow

      自分がこの言語に興味を持ったのは、グラフィックツールがなくても GitHub でメンテしやすい遷移図を描けないか？だったので欲しいのは言語そのものだけではなく、それを実際に遷移図に起こしてくれるツールだった。そこで出てきたのがこの二つ。

      この二つは同じ作者の手によるもので、 UI Flows 言語（仮にこう呼ぶ）を解釈し、ビジュアライズする実装。guiflow は Electron 製、uiflow は Node.js 製。

      guiflowよさげなんだけど…

      すぐに始められてグラフが見れるというのはすごくいいんだけど、ちょっと以下が気になった。

      試したのは v 0.1.1

      1. 日本語が Unicode Escapesequence になってしまう
      2. DnD でファイルを開いてくれない

      特に 1 が致命的で、一度このツールで保存しちゃうと、もうこのツールを使って読むか、変換済みの画像でなければ人間が共有するのは難しくなってしまう。（Unicode Escapesequence をそのまま読み下せる人は身近にはいませんので）

      うーーーーん。これはちょっと期待していたものと違うなぁ。

      uiflowは大丈夫なんだけど

      同じ作者の uiflow では、普通にエディタで作成した UTF-8 のデータを変換することができた。

      中を軽く読んでみたんだけど、どうも変換の処理ではなく、ACE というエディタでテキストデータを扱うと Unicode Escapesequnce になっちゃうのかな？

      Ace - The High Performance Code Editor for the Web

      uiflow を叩くのは我々コマンドラインに慣れている人間にはよいけど、遷移を考える人はそういう人ばかりではないので、これを普段使いにするかというと、ちょっと微妙な気がします。自動化の際には活躍すると思いますが。

      さーてこれはどうしよう、というところまでたどり着いて今回は力つきてしまいましたとさ。

      まとめ

      • UIの流れを記述するシンプルな言語がある
      • 2016年くらいから実装が増えてて試しやすくなってる
      • ただし元ネタは2009年のブログであり、今も使っているのかはよく分からなかった
      • guiflow は手軽に始められるけどテキストデータとしてはちょっと管理しにくいので課題はある

      久しぶりにSinatra AssetPackを触ったらbundle updateしないと動かなかった

      ※ というか Sinatra AssetPack はメンテナいなくなるよーって話だった。

      https://github.com/rstacruz/sinatra-assetpack/issues/197

      そうか。考えないとな。

      sinatra-assetpack

      1. sinatra入れる
      2. 次にsinatra-assetpack入れる

      ってする時に 2 で bundle だけ叩くとダメ。Sinatra AssetPack の方が Sinatra についていけてなくて Tilt が古いものでないと動かないから、みたい。正解はちゃんと

      bundle update

      すること。

      以前試した時には AssetPack がいちばん苦労なく動いたんだけど、他の asset なんとか sprockets なんとかの方がいいのかな。まぁ別に Coffee がどうとかには何もこだわってなくて、単に digest による cache buster が確実に動けばなんでもいいんだけど。

      まぁその辺の調査はやるとしてもまた今度。

      Emacs で設定ファイルとかをなんとなく見やすくする

      Twtterより。

      rubikitch 11/02/18 9:37 とりあえず (require 'generic-x) という行
                        を.emacsに加えとけ。/etc/hostsやらhttpd.confな
                        んかに色がつくようになるからさっ！せっかく機能
                        があるのになんで標準で有効になってないの？もっ
                        たいない。
wtnabe 11/02/18 15:56   (require 'generic-x) 21 でも動いた

      確かに便利。

      普段はそんなに必要ないけど *.conf なんかをいじるときに地味に便利。Emacs 21 on CentOS でも動いた。結構昔からあるのかも。

      [2011-03-09 追記]

      もっと詳しく書いてくれた人がいた。

      clmemo@aka: Emacs で設定ファイル (/etc/hosts, /etc/apache2.conf) の色付けをする

      .gitignore は .cvsignore と違ってホームディレクトリのものはデフォルトでは解釈されない

      info cvs より

      C.5 Ignoring files via cvsignore
================================
(snip
   * The per-user list in `.cvsignore' in your home directory is
     appended to the list, if it exists.

      man gitignore より

      NAME
      gitignore - Specifies intentionally untracked files to ignore
(snip
       o   Patterns read from the file specified by the configuration variable
          core.excludesfile.

      git の場合、~/.gitconfig は解釈されるが、この中で

      [core]
   excludesfile = /path/to/.gitignore

      の形で ~/.gitignore を指定してあげてないとその中身を ignore 対象にはしてくれない。おまけにちゃんとフルパスで書いてあげないといけない。

      ということで自前のツールで

      gitconfig.erb

      [core]
    excludesfile = <%= ENV['HOME'] %>/.gitignore

      てな形で用意しておくことにした。これで Linux でも OSX でもユーザー名が変わっても大丈夫。

      Wiki の横断検索と Namazu

      ※ 以後、Namazu, Namazu って書いているけど、同じ方法が使えれば estraier でもなんでもいいです。

      Wiki は普通 grep 検索できるので Namazu は必要ない。よほどページ数が増えればスピードの問題が出てくるが、普通はインデックスを起こすタイプの検索エンジンは Wiki にはそんなに必要ない。1

      ただし Wiki が増えた場合はそうはいかない。自分は PukiWiki をローカルで使っているが、WikiFarm というか、複数の Wiki に分けて使っている。PukiWiki は 1.4.4 になって複数の Wiki で同じ lib/ を共有しやすくなったり、以前より複数の Wiki を動かすのは簡単になっている2ので、興味がある人には是非オススメしたい。明らかに目的の違うもの、個人用のスペース（ここに日誌を書いたりする）、期間限定のプロジェクトなどを別々の Wiki に分けておくと何かと扱いやすいのだ。3（先に分けても後から分けてもいい。）ところが PukiWiki には複数の Wiki に対して検索する機能がないのでそこが不便。

      というかそもそも PukiWiki には WikiFarm の機能がない。複数の Wiki を PukiWiki 自身が管理しているわけじゃないんだから、そら横断検索ってのも無茶な話。そこで Namazu を使う。Namazu では 1Wiki対1インデックスのオーソドックスなインデックスを起こす。で、template で checkbox を用意して、複数のインデックスに対して一気に検索を掛けられるようにする。

      おしまい。

      いやいや。

      この方法にはまだまだ工夫の余地がある。

      • Wiki のパーサを外部（Web ベースでなくコマンドラインが嬉しい）から利用できる API があると、Namazu の filter を書きやすくなって検索精度を上げやすくなる。
        • サイドバーやナビゲーション要素を除いた HTML が取得できるといちばん嬉しい。
        • 今回の PukiWiki 用フィルタは超簡単なパーサもどきを Perl で別途用意したのだが、本当は PukiWiki のエンジンを利用して HTML を生成できればいちばんよかった。
      • DBMS 前提の Wiki だと Namazu と相性が悪いので、Namazu 用に（ってだけでもないけど）ナビゲーション要素などを除いた HTML を取得できる方法があるといいな。

      これが実現できるとどんな Wiki を使っていても Wiki の分割と精度の高い横断検索を実現できる。んだけど、Wiki エンジンの開発者やコミュニティでこういうことに意義を感じている人ってあんまり見ないのはなぜだろう。すげー便利なのに。ひょっとして自分の知らないもっといい方法が密かに定着しているのだろうか。

      1. もちろんページの書き方にもよるかもしれない。 ↩

      2. 本当は skin の共有や Wiki 間の移動をどうナビゲートするかまで考えるとまだ手間が掛かるんだけど。 ↩

      3. たださんもそんなことを以前日記に書いていたと思う。 ↩

      burn out blogging

      Blogを書くことの心理的負担とそれを上回る魅力 @CNET 梅田blog

      自分は Wiki や blog を始め Web 上のコミュニケーション技術の発達をとても面白いと感じているし、誰かのサイトに対してコメントを書いたりはする。でも自分が blog を立ち上げて積極的にさぁコメントいらっしゃい、trackback いらっしゃい、なんて気にはとうていなれない。なんていうか、自分に選択権のない偶発的なコミュニケーションが始まるということに興味が沸かないのだ。

      なんかあったらメールを送ってくれ、で立ち止まってしまっている自分がいる。blog は始めてもいないわけだけど、なんとなく burn out って分かる気もする。今の自分にとって、技術的な意味以上の魅力ってないんだなぁ。

      目が乾く

      部屋が変わって以来、ものすごく乾燥している感じがする。目がやたらと疲れるし、顔もつっぱっている。妙齢の男性の割にはお肌がきれいというのが自分のウリの一つなのに、最近はかなりお肌の調子が悪い。なんでこんなに違うのかなぁと思うのだが、この辺が高気密・高断熱な安普請ゆえなのだろうか。安普請なのはものすごい壁の薄さから考えて間違いないと思うんだけど。

      安いかどうかはともかく、現在の建物には乾燥に耐え兼ねて通気を確保しようにも窓が開けにくいという問題がある。窓がスライド式じゃなくてスウィング式なのだ。おかげで、ちょっとだけ窓を開けて室温を大幅に変えずに通気性だけ確保したい、という要求には全然応えられない。設計が間違ってると思うんだよなぁ、こういうの。

      窓って、何かスライド式よりスウィング式の方が明らかにいいっていうメリットがあるんですか？

      http://www.alianet.org/homedock/dannetu/3-1.html

      これによると職場の窓は引き窓と立てすべり出し窓と開き窓があるようだ。もっと引き窓の比率を上げてくれ、ってことだな。

      About

      例によって個人のなんちゃらです