hubot+slack で Attachments を使おうとしてハマった話
An introduction to messages | Slack
ここに書かれている通り、slackにメッセージを投稿する時、Attachmentsという機能を使うとメッセージを装飾することができる。
で、それをhubotから利用しようとしてハマったというお話。
調べる中で「msg.sendではなくhubot.emitを使う」という記事を見つけたのでその通りにしてみたところ動かず。
さらに色々調べたところ、なんと最近仕様が変わったとのこと。おかげでネット上にある記事のほとんどが役に立たなくなってしまっていた。
最新のQAを漁ったりドキュメントを読み直したりしながらなんとか問題を解決。
以下がそのサンプルコード。
module.exports = (robot) -> robot.respond /HELLO/, (msg) -> data = attachments: JSON.stringify([{ "fallback": "Required plain-text summary of the attachment.", "color": "#36a64f", "pretext": "Optional text that appears above the attachment block", "author_name": "Bobby Tables", "author_link": "http://flickr.com/bobby/", "author_icon": "http://flickr.com/icons/bobby.jpg", "title": "Slack API Documentation", "title_link": "https://api.slack.com/", "text": "Optional text that appears within the attachment", "image_url": "http://my-website.com/path/to/image.jpg", "thumb_url": "http://example.com/path/to/thumb.png", "footer": "Slack API", "footer_icon": "https://platform.slack-edge.com/img/default_application_icon.png", "ts": "123456789" }]) msg.send data
Markdownエディタを作る（その１）
自チームの生産性向上のためにMarkdownエディタを導入することに。
Markdownエディタと生産性向上の関係については別途書くとして、今回は最初にやったこと諸々について。
1.ベースとなるMarkdownエディタを導入する
スクラッチから作るのは手間なのでベースとなってくれるコードを検索。ちょうど良いものが以下の記事で公開されていたので、そのままいただくことに。
これが素晴らしくて、以下その理由。
1. とにかくシンプルに実装されている→カスタマイズしやすい
2. marked.jsが使われている→いくつかあるパーサーの中でおそらく一番良さそう
パーサーについては以下の比較記事が非常に参考になりました。
後は足りない機能を追加していくことになるが、まずはパーサーの設定と機能追加を。
2.パーサーの設定
marked.jsはsetOptions関数を使ってその動作を変更することができる。
今回「これまで使ってきたテキストエディタの代替ツール」としてメンバーに使ってもらうことを考えると、改行動作（半角スペース２つ＝改行）をなんとかしないといけない。実はその設定がここでできる。
editor.jsを以下のように修正することで、改行動作が通常のエディタと同じになってくれる。
marked.setOptions({ breaks: true, ←これを追記 langPrefix: '' });
3.パーサーに新たな処理を追加
次に、marked.jsにないパース処理を追加する。
追加したいのはチェックボックスへの整形処理。Atom等のMarkdownエディターでは普通に実装されているこの機能が、なぜかmarked.jsにはなかった。
ということでまたeditor.jsを修正。
var html = marked(src); // チェックボックスへの変換機能を追加 html = html.replace(/\[x\]/g, '<input type="checkbox" checked="checked">'); html = html.replace(/\[ \]/g, '<input type="checkbox">'); $('#result').html(html);
これで「[ ]」と記入すると空のチェックボックスに、「[x]」と記入するとチェックが入ったチェックボックスに変換されるようになりました。
今回はなんの考慮もしていないお手軽改造です。何か不都合が見つかったらそのとき直します。
今回はここまで。
次回はたぶんUI周りについて書きます。
bin/hubotで「iconv.nodeが見つからない」とErrorが出た時の対処法
忘れないようにメモ。
ターミナルで bin/hubot した時に以下のエラーが出た時の対処法。
Error: Cannot find module '../build/Debug/iconv.node'
hubotフォルダ配下の node_modules/iconv に移動し、以下のコマンドを実行。
node-gyp configure node-gyp build
もし node-gyp で command not found が出たら、以下のやり方で node-gyp をインストールする。
npm install -g node-gyp
ユニバーサルデザインとその界隈のキーワードをまとめてみた
始めはユニバーサルデザインについて書こうと思ったのですが、Googleで「ユニバーサルデザイン」を検索するといろいろな関連語が出てきまして。その中に幾つか混同しやすいものがあったので、まずは自分の頭の整理がてらそれらの言葉（「ユニバーサルデザイン」「ノーマライゼーション」「バリアフリー」「アクセシビリティ」「ユーザビリティ」）についてまとめてみようと思います。
ユニバーサルデザインとノーマライゼーション
この二つは「全ての人にとって等しく利用可能な状態を目指す」という考え方であり、意味としては似ています。が、言葉自体の生まれの違いからその対象が異なっています。
ユニバーサルデザインはデザイン用語であり、その対象は「施設・製品・情報等」です。対してノーマライゼーションは社会福祉用語であり、対象は人を囲む環境全てです。ノーマライゼーションは考え方というよりも思想や理念に近いです。
アプリケーションやWebサービスを開発する場合や製品開発を行う場合は、ノーマライゼーションという表現は意味が大きすぎるので、ユニバーサルデザインという表現のほうがよりマッチします。
ユニバーサルデザインとバリアフリー
ユニバーサルデザインが「すべての人にとって等しく利用可能な状態を目指す」という"考え方"であるのに対し、バリアフリーは「すべての人にとって等しく利用可能な状態にするために、その障害となる要素が取り除かれている」という"状態"を表します。
よって、バリアフリーはその対象となる既存の何かが存在します。0からなにかを作ろうとしたときにいきなりバリアフリーを目指すということはありません。
ノーマライゼーションとバリアフリー
この二つはその対象を「人を囲む環境全て」としている点で似ています。つまり、デザインに限らず、社会の仕組みや人々の意識まで含められています。
バリアフリーは、段差をなくすといった物理的な障害の解決を指すと思われがちですが、実際には社会的弱者に対する偏見といった精神的・社会的な障害も含めて取り除くことも目的としています。
アクセシビリティとユーザビリティ
この二つはこれまでの３つのワードとは異なり、考え方ではなく"度合い"を指しています。
アクセシビリティは「利用可能な状態へのなりやすさ」を表すので、その度合いは「確保されている・確保されていない」と表現され、対してユーザビリティは「使いやすさ」を表すので、その度合いは「高い・低い」と表現されます。
例えば「アクセシビリティが十分確保されていない」と言った場合、それは「人によっては利用可能な状態に到達できない可能性がある」ことを表しています。ここに使いやすいか否かという観点は入っていません。使う以前の話というわけです。
また「ユーザビリティが低い」と言った場合、それは「利用者にとって使い勝手が悪い」ことを表しています。この表現は利用可能な状態であることが前提となっているので、利用可能な状態になるまでの難度は観点に入っていません。
まとめ
以上ユニバーサルデザインを含む５つのワードについて書いてきました。こうして改めて書いてみると明確な違いがあることがわかりますね。最後に各ワードの簡単な例文を並べてみます。
・ノーマライゼーションを推進する
・ユニバーサルデザインを取り入れる
・バリアフリー化する
こんな感じでしょうか。
一通り言葉の整理ができたところで、次回はユニバーサルデザインについて書いてみようと思います。
スマホ時代のプロダクトデザインってなんだろう
Microcar Mondays Pt VIII - ClassicCarWeekly.netClassicCarWeekly.net
フィーチャーフォン全盛期のころの端末デザインってこんな感じだったなと思った。見た目も機能もそれぞれ個性があって。
スマホ時代になってプロダクトデザインからユーザインターフェースデザインに重要性がシフトして、それはそれですばらしい変化だったと思うのだけれど、やっぱりどこか寂しい感じもあるわけで。あのころのプロダクトデザインを担っていたデザイナーさんたちは今なにしてるんだろう。
スマホはボディに占める画面の割合がとんでもなく大きいので、どうしても画面内に力を入れざるを得ないのは仕方が無いことだとは思うんですけどね。そんな状況で、画面そのものを工夫することでプロダクトデザインとしての個性を出してきたのが「GALAXY Note Edge」と「AQUOS CRYSTAL」なんじゃないかと。
どちらもデザイン力というよりは技術力の高さによって生まれた端末という印象で、やっぱりプロダクトデザインって昔のそれとは違うんだなと。いや、フィーチャーフォンもとんでもない技術力があってこそのあのプロダクトデザインだったわけですけども。だってあれだけ高いスペックで、あれだけいくつもアンテナやセンサーを干渉しないように入れ込んで、それであのボディサイズですからね。
ディスプレイに関する技術の進化は液晶テレビの普及に伴って画質の進化という形でしばらく進んでいたけど、スマホが出てきてその進化の形に多様性が出てきたような気がします。例えば曲がるディスプレイとか、向こうが透けて見えるディスプレイとか。技術としては数年前からあったけど適用先がなかったこれらの技術がいよいよ日の目を見る可能性が出てきて一気に進んだ感じ。
このディスプレイのバリエーションがそのままスマホのプロダクトデザインのバリエーションになっていくというのがあと数年続くんじゃないですかね。となると次はなんだろう。やっぱり透けるスマホかな・・・。
Play Frameworkでいろいろはまったので備忘録的に書いてみる
もうなんでこんなしょうもないことで何時間もはまってるんだと自分が情けなくなるのですが、同じ目にあわないよう備忘録としてつらつらと書いておきます。
eclipse上でrender()がエラー扱いされる
これ、eclipse上では「引数なしのrender()なんてないよ。引数入れろよ。」と怒られるんですが、実行する分には問題ないんです。きっとプラグインなんだろうとscala IDEのプラグインをインストールしたら見事解決しました。（見事ってほどの話ではないか）
viewsに作成したhoge.scala.htmlをコードから参照できない
最初からあるindex.scala.htmlとmain.scala.html以外を追加しようとしてはまりました。結局「コンソールを開いてcompileコマンドを打つ」で解決。これをすることによってviews内の.scala.htmlをclass化してくれるらしく、class化しないといつまでたってもコードから参照できないからエラーが出ていたということのよう。
わかればなんてことない話しだけども、一度runコマンドで走らせて「コード修正→ブラウザリロード」で動作確認をしていたので改めてコンパイルするという考えになかなか気づけなかった。
playコマンドが使えない
これが今回一番しょうもないはまり。
いろんな記事で「playコマンドでコンソール開いて云々」って書かれていて、でもどうやってもplayコマンドが使えなくてなんだこれはと調べていたら、これPlay Frameworkの古いバージョンの話でした。最新バージョンではactivatorコマンドに変わっていて、だったらいつも使ってるじゃんと。素人か。
