ベリー！べリー！ベりー！
こんにちは。またしても食いしん坊いとうです。
写真下手なので前回の投稿のご飯はあんまりおいしくなさそうだなぁ。
と思っていたら飯テロと言われたので、うれしいです。
今回は、つい昨日ドはまりしたプログラムについて、愚痴ります。
簡単に作りたいものの説明をします。
①DBから文言を取得。
②↑の文言から文字列を抜き出す。
③↑の文字列と設定ファイルにあらかじめ列挙した文字列を比較。
っていうこれだけをしたかったんですけど。。。
まぁ、比較結果おかしいのなんの。
漢字と漢字の突き合わせは出来るのに、”べリー”と”ベリー”だけ合致させられない。
W ｈ ｙ ？
わいも昔はプログラマー。
「はは～ん、文字コードでは？」
と高をくくって文字コード設定をググりつつ、文字コードを”UTF-8”に統一しようと試行錯誤。
しかし、”べリー”は”ベリー”と合致しない。
気づいたら深夜。
翌日弊社の頼れる先輩たちにアドバイスをもらおう、とあきらめて帰宅。。。
翌日、先輩に相談したところ。。。
「原因は伸ばし棒では？」とアドバイスをもらって伸ばし棒を調査。
一緒だよ～～！！伸ばし棒は容疑者から外れる。。。ということは濁点ですか？？？
なんて頭を抱えていたら、先輩が16進数ダンプをとってくれ、原因が判明しました。
ひ ら が な と カ タ カ ナ ！
ああああああああああああああああ（怒
べ（ひらがな）
ベ（カタカナ）
わからんわーーーい！！！！
結末としましては、設定ファイルに記述する時に変換ミスをやらかしていたようです。
はぁ、、、なんでもかんでも文字コード疑っちゃだめだ。
みなさんはこんなドジしないとは思いますが、お気を付けください。。。
飯 A/W
こんにちは。iPX川口です。
この前まで暑かったのに肌寒くなってきて年末が近づいているんだなと、一年は早いなと思う今日この頃です。
関係ありませんが、
「え？君、そば派？うどん派じゃないんだ？」という会話にいやどっちでもでしょと心の中でつっこんだ経験、ありますよね。
ちなみに私は温はうどんで、冷はそばです。どっちでもいいですね。
さて、私は趣味で料理をするのですが寒くなってきたこの季節に丁度よいものがあるのでそれをご紹介します。
寒い時に食べたい、そう鍋です。
鍋＝美味い
鍋＝簡単
美味い＋簡単＝正義！！！
写真は鴨鍋です。
盛り付けと撮影はセンス無し。けど美味いです。
鴨鍋のレシピ
------------------------------------------------------------
鍋汁
めんつゆ(カツオ) 適当
塩 適当
酒 適当
水 適当
もしくは寄せ鍋の素
具材
鴨
つみれ(お好み)
ごぼう
えのき(他きのこ類でも代用可)
糸こんにゃく(お好み)
長ネギ
豆腐
白菜
春菊(お好み)
下ごしらえ
鴨 肉のにおい消しのために酒に浸しておく
ごぼう 土っぽいにおい消しのために水に浸しておく
調理
いい感じの鍋汁ができたら、火の通り辛そうな具材から投入。
(鴨はごぼうの近くに配置するとお互いでにおいを消し合ってくれます。)
春菊は他の食材に十分に火が通った後に投入し、5分ほど煮込む
完成！
------------------------------------------------------------
うん簡単！
鴨って売ってる？という質問を知り合いにされたことがありますが、スーパーに行くと意外とあります。
以上です。ありがとうございました。
品質管理のお話
こんにちわ、プログ3回目の投稿になります古谷です。
そろそろ技術系のブログを・・・と思いつつもなかなか書くのは難しいと思う日々。
というわけで今回は、業務に直接的には関係ありませんがちょこちょこ耳にするQC（品質管理）について書いていきます。
自分自身もなんだろう？と興味があったので調べてみることにしました。
１．QC（品質管理）とは
品質管理と聞くと、品質管理課の人が商品を検査し改善するもの。と思われる方が多いと思います。私も当初そうだと思っていましたが、これは正しくもあり、広義的にみると違った解釈をすることもできます。
◆広義の品質管理：
顧客や社会の要求する品質を満たし、ニーズに合った製品やサービスを作って提供するための品質管理
どう違うかというと、完成した商品から原因を探っていくより、開発全体を通して品質管理を行う方が有効的ではないかという考え方です。
最近ではこの「広義の品質管理」が一般的になってきているようです。
一例としてTQC（全社的品質管理）があります。
設計の段階から販売、アフターサービスといった全プロセスを総合的に品質管理する手法です。
これにより品質管理は「1部門だけが行うもの」ではなく「企業に属する全員で行うもの」となります。
２．品質管理の考え方
・品質第一：顧客は品質が高くないと購入しない。顧客が求めるものを品質が高い状態で提供する
・後工程もお客様：自分が行う業務だけではなく、その次の工程のことも考えた仕事をすれば全体の品質向上につながる。自分の仕事さえ完了すればいいという考え方は周りに負荷をかけ品質低下を招く。
・プロセスを管理する：良い結果、悪い結果を決めるのは結果までに至るプロセスによるもの。何か問題が起こった時、問題をおこしたプロセス（仕事のやり方）に原因がある。
品質管理の考え方をここでは3つ挙げてみました。他にもありますがどれも重要なことばかりです。文章で書かれると「己はしっかりできているのか」と心に響くものがありますね。
３．分析手法
今まで考え方を書いてきましたが、次は分析手法（問題解決手法）についてです。
分析する方法は有名なものとしてQC7つ道具、新QC7つ道具と呼ばれるものがあります。
中身については割愛しますが、2つの使いわけについて説明していきます。
QC7つ道具：数値データ特化の分析手法です。
例）商品の重量のばらつきをグラフ化して分析
新QC7つ道具：数値化できない言語データ特化の分析手法です。（一部数値データを扱います）
例）作業手順をチャート化し、見える化を図る
まとめ
最初は単なる興味から調べてみた品質管理ですが、自分を見つめなおすいい機会となりました。
特に品質管理の考え方は社会人になる前から知りたかった内容でした。
意識するしないで大きな差となってくることでしょう。
というわけで、品質管理のお話でした。ではでは。
視覚のオハナシ ”皆さん脳に騙されてますよ！”
iPX mazdaです。（３回目の登場です）
本日の前置き。
最近、運転する機会が増えましてウキウキしております。
山奥や海辺や雪山へ。
アウトドア＆ドライブが好きな私ですが、アルコールもとても好きなのです。
アルコールを嗜みたい時、自動で運転してくれたらな…と思い始めた今日この頃。
さて本日の本題に。
“視覚”について書き綴ります
導入バナシ
大学で少々視覚をテーマに研究しておりました。
運転には限りなく視覚が重要なファクターとなります。
「あ、あそこに好みの女の子がっ！」と言ってよそ見をしてはいけません。
とてつもなく良い視野角・反応速度は持っていても注視する所が偏ってしまうと危険です。
視覚は人間工学や動態学、人類生物学と言った領域の知識が必要な領域となりますが、そんな専門的な領域を学んだ人は少ないでしょう。
何か少ない知識でも賄えたりしないであろうか…。
実は、サリエンシー・マップ、ベイジアン・サプライズマップと言う計算理論的にコンピューター上で人間が注視している部分を再現出来る手法があります。
（南カリフォルニア大学のItti氏が実際に開発されたプログラム）
コンピューター上でも再現できれば色々と応用が利きそうですね～。
個人的には自動車業界もそうですが、サインデザイン・UI／UXに従事している業界の人達にも有効なのではと。
とは言うのも、
転業界して「デザイナーってあんまり検証してないやん。何を根拠にしてるんだ？」と多々思う事がありまして。
しっかりと検証・シミュレーションを行い根拠あるモノを作っていく必要が何に従事していたとしても必要なのではないかなと。
そろそろ、文章だけではつまらないので画を入れていきます。
視覚は脳を騙してます
入って来る光が錐体細胞を刺激して色の判別をし、視神経を通して電気信号を脳に届けています。
脳内で三次元情報へと変換され、視覚世界が構築されています。
つまりは、脳の独断と偏見で視覚世界が構成されているのですよ！
その根拠として、こちらをご覧ください。
チョコ好きの皆さん、どちらのチョコを手に取りますか？
無論、私は上の方を選びます。
しかしながら残念なお知らせをしますと、上下とも同サイズなのです…。
※※※Photoshopで編集なんてしてませんよ、現実です※※※
今回の例はポンゾ錯視です。
何で騙されるんだ？
それはですね、食いしん坊だからです（嘘）。
少しでも大きい方が嬉しいのは間違いないのですが、何故大きく見えてしまうのかと言いますと、脳は奥行を感じてしまっているからです。
脳の偏見
「な、なんでなんだ私の脳みそ！これは二次元の画じゃないか！」
二次元と分かっていながら、手前と奥を認識して勝手に脳が三次元変換しているのです。
実際、人間自体は三次元ですし住んでいる世界も三次元なので脳も自動的に三次元変換を加えているのでしょう。
手前と奥を感じたからと言って何故大きく見えるかはまだ疑問としてあるでしょう。
少々解説しますと黒い線がカギとなっています。
奥（尖がっている方）は狭い・小さいと感じている為、比較対象となるチョコレートが大きく認識してしまいます。
一方、手前のチョコは比較対象が大きな空白（空間）として捉える為、小さいと認識します。
互いに誇張されている感じですね。
まだまだ他にも錯視の法則がありますので調べてみて下さい。
世間ではトリックアートなんて流行っていますが、錯視の法則を利用していますよ！
今回の視覚について第１弾は閉幕とさせて頂きます。
次回、乞うご期待。
YammerでHubotを利用する（Hubotプログラミング入門編）
前書き
2本目の投稿です。iPXのabikoです。
前回から引き続きHubot〆の記事としてお送りします。
下準備
EC2とローカルでファイルのやり取りをする場合は、WinSCPなどのツールがあると便利です。
（viなどで直接編集する方は不要です。）
WinSCPでEC2に接続するには、Putty同様ホスト名・ユーザ名・秘密鍵の設定をする必要があります。
秘密鍵の設定箇所は「設定」から「SSH」＞「認証」の「秘密鍵」の項目です。
ここにEC2にアクセスするために使用している.ppkファイルのパスを指定すれば完了です。
スクリプトの配置場所とサンプルの利用
作成したスクリプトは Hubotのルートディレクトリ/scripts に置いていきましょう。
（これまでの私の記事ですと ~/YAMMERBOT/script）
ここにはサンプルとして example.coffee が入っております。
このファイルのコメントアウトを外しながら少しずつ改変していくと手っ取り早く理解が進むのではないでしょうか。
（私はCoffeeScriptはおろかJavaScriptの経験も乏しく、どうしてもサンプル頼りです）
また、以降の私のスクリプトを試したい場合には、 example.coffeeに下記「ここに追加」箇所に追加することで試せます。
※CoffeeScriptはインデントの階層でブロック（C言語で言う 中括弧{}）を表現します。追加の際はお気をつけください。
module.exports = (robot) -> （ここに追加） # robot.hear /badger/i, (res) -> # res.send "Badgers? BADGERS? WE DON'T NEED NO STINKIN BADGERS" ・・・（略）
CoffeeScriptは最終的にJavaScriptに変換されて実行される、JavaScriptを簡潔に記述できるようにした言語です。
なんとJavaScriptと比べ1/2～1/3の記述量で済むとか何とか。（利点は他にも色々あるようですが、ざっくり）
下記のページの上部メニュー「TryCoffeeScript」に移動すると、右側に書いたCoffeeScriptがリアルタイムでJavaScriptに変換され左側に出力されます。
CoffeeScriptになじみの無い方は使用してみるとイメージがつかめるかもしれません。
いざ、Hello World!
これは基本のping→pongの発言内容が変わったバージョンですね。
robot.respond /Hello/i, (res) -> res.send "World!"
サーバに編集したファイルを配置したらHubotを起動します。
スクリプトの読み込みはHubotの起動時に行われ、コードに記述ミスなどの不備があると起動できずにエラーになります。
つまり、コードを書き直すたびにHubotの再起動が必要です。
また、コードを試すだけであればYammerで発言しなくともコンソール上で確認可能です。
$ ./bin/hubot ・・・（略） YAMMERBOT> YAMMERBOT Hello YAMMERBOT> World!
動作の確認が取れたので、YammerでもHelloしてみます。
無事動きました!
かならずYAMMERBOTってつけないとダメなの？
YAMMERBOT ～ って書くのが煩わしいぞ！会話を自然にしたい！
と思ったそこのあなた、
robot.respond を robot.hear に変えて試してみましょう
robot.hear /Hello/i, (res) -> res.send "World!"
実行してみます。
$ ./bin/hubot ・・・（略） YAMMERBOT> Hello YAMMERBOT> World!
要望はかないましたが、デメリットもあります。
文中にHelloが含まれていても反応するのです。
YAMMERBOT> HogeHogeHelloFugaFuga YAMMERBOT> World!
よく使われるワードを使用すると、意図しない発言に反応してしまう可能性があるので注意が必要です。
また、respondとhearで受け取った発言内容を返したい場合、若干実装が異なってきます。
#hearの場合のコード robot.hear/Hello/i, (res) -> res.send res.match[0] #実行結果 YAMMERBOT> Hello YAMMERBOT> Hello #respond の場合のコード robot.respond /Hello/i, (res) -> res.send res.match[0] #実行結果 YAMMERBOT> YAMMERBOT Hello YAMMERBOT> YAMMERBOT Hello
msg.match[0] と書くと、発言内容の「全文」を取得できます。
そのため、respondで使用すると、呼び出しの文句（YAMMERBOT）まで取れてしまいました。
なんといいますか、このままでは使い勝手が悪そうです。
この問題については、括弧でくくる、と解決します。
respondやhearの引数になっている /～/ は正規表現で解釈されるため、(Hello) とくくることによって、Hello が正規表現の1つめの要素になるんですね。
あとはmsg.match[1]として1つめを取得すると、hearと同じ様な結果が得られるようになる、というわけです。
#respond で呼び出し文を除いて発言内容を返答 robot.respond /(Hello)/i, (res) -> res.send res.match[1] #実行結果 YAMMERBOT> YAMMERBOT Hello YAMMERBOT> Hello
では相手の発言の一部を返答に組み込む例をひとつ
#{}でくくると変数の中身を展開できることも利用します。
#相手の発言内容の一部を返答に組み込む robot.respond /Hello, I am ([a-z]+)/i, (res) -> res.send "Hi, #{res.match[1]}! I am YAMMERBOT!" #実行結果 YAMMERBOT> YAMMERBOT Hello, I am abiko. YAMMERBOT> Hi, abiko! I am YAMMERBOT! YAMMERBOT> YAMMERBOT Hello, I am HogeHoge. YAMMERBOT> Hi, HogeHoge! I am YAMMERBOT!
中学校の教科書の最初に出てきそうな受け答えができました！
ちなみに /～/i の i は大文字小文字を無視する(ignore)意味があります。
これまでの紹介してきたコードの場合、呼び出しの文句を含め大文字にする必要は無いのです。
[a-z]としていても、大文字小文字によらず英字を判定してくれます。
おみくじ
続いておみくじの実装に入ります。
実はこの課題、とてもコード上は簡単なんです。
robot.hear /おみくじ/i, (res) -> res.send res.random ["大吉", "吉", "凶", "大凶"]
random の引数にランダムにしたい配列の内容を渡すだけなんですね。
拍子抜け、と言うほどあっという間におみくじができてしまいました。
では、早速確認してみます。
$ ./bin/hubot ・・・（略） YAMMERBOT> おみくじ YAMMERBOT> 大吉
大吉でした！（ﾔｯﾀﾈ!）
scriptに日本語を書く場合は、ファイルの文字コードをUTF-8にする必要があるようです。
（SJISだと反応が返ってきませんでした。）
終わりに
ここまででHello Worldを含め、Hubotを一通り動作させることができました。
スクリプトについては超入門レベルでしたが、目標は達せられたかなと思います。
様々苦戦しましたが、その甲斐もあり？いい勉強になりました。
今のままだと常時稼動できないようなのでデーモン化するなど課題もでてきますが、次回取り上げるかは未定です。
ここまでお付き合い頂きありがとうございました。
それではまた、次の記事でお会いしましょう。
今回主立って参考にさせて頂いたサイト様
CoffeeScriptとはなんぞや？
CoffeeScript入門メモ
robot.respondでmsg.matchを使う場合は単一でもキーワードを()で囲まなければならない
Hubot + CoffeeScript ではじめるやわらかプログラミング入門 · GitHub
ありがとうございました！
