Re：YammerでHubotを利用する（環境構築編１）
前書き
ご無沙汰しております。iPXのabikoです。
まだまだ残暑が続く中、皆さまいかがお過ごしでしょうか。
私はお盆半ばにして体調をくずし、風邪にしては長めに体調不良を引きずったのですが、ようやく回復してまいりました。
夏風邪のやっかいさを思い知っております。皆さまもお気をつけください。
大分間が空いてしましましたが、今回はHubotの実装について記事を書いていこうと思います。
再び環境構築をば
前回はローカルPC（Windows）にHubotをインストールしましたが、Botなのでサーバ上で動かし続けていたい、という思いから今回はサーバにインストールし直します。
使用するサービスは、Amazon EC2 (クラウド仮想サーバー)です。
※ローカルPCはWindows7 64bit
今回はひとまず Amazon EC2 に Amazon Linux のインスタンスを作成してSSHで接続するところまでです。
参考サイト
私がHubotの記事をお休みしている間に、webでは大変有益な情報が上がっていましたので紹介します。
Hubot を Amazon EC2 にセットアップして Yammer に投稿する - Qiita
では環境構築
上記のサイトの通りに進めれば環境構築はおろか、発言への反応までも完了するはずです。
ただ、私が進めていて躓いたところもありますので、接続が完了するところまでを順を追ってみていきます。
FizzとBuzzと色々な「知識」
私よりずっと成績のいい学生がたくさんいましたのに何で私が選ばれましたか。
と僕が委託されている会社の新入りインターンが不安たっぷりの声で歓迎会の参加している方皆に聞いた。
僕の立場では答える権利はなかったけど答えがわかった。所員さんのマネージャが口を開けた瞬間に何を言うか想像ができた。
「選ぶときに成績より大事なポイントがいっぱいあるから。」
というより、学生時代が終わったら僕は成績のことほとんど気にしなかった、自分のも、他人のも。学歴全体見ても、それだけで相手は「できる」か「できない」か判断するのは無理ほど難しい。
それだったら、どうやってどうやって人の知識や才能を測れるのか。僕は今回のブログ担当のベーカーで今回の記事にこの問題と最近はやっている解決について書かせていただきたいと思う。
続きを読むCANの基礎の基礎
お疲れ様です、今回の記事を担当する鈴木です。
お客様先で自動車に搭載されるECU（電子制御ユニット）やECUに実装される制御のテストの業務に携わっております。そこでは制御系の車載ネットワークの標準的なプロトコルであるCAN(controller area network)に触れることも多いです。そこでCANの概念についてほんの触りですが学習したことをお話させていただきます。
車載ネットワークの始まり
自動車のECUの始まりは1970年台にエンジン制御で使用されるようになったことだと言われております。その当時は1つのECUにワイヤ・ハーネスによってセンサやアクチュエータと結線され制御されていたため、ネットワークという概念を意識する必要は乏しかった。
その後、制御の品質・精密さ上げるために、センサの個数や制御箇所が増え、ECUも一つでは対応できなくなり、複数のECUを自動車に搭載するようになっていきました。しかし、ECUが増加するにつれて、ワイヤ・ハーネスが増加するなどの問題が発生していきました。こうした背景を解決するためにCANなどの車載ネットワークのプロトコルが開発されるようになりました。
CANの特徴
今回はCANの中でも、ネットワークトポロジ、通信方式、ネットワークの管理方式の概念について記載します。
①. バス型トポロジ
下記の図のようにバスに各ノード（自動車ならばECU）が接続しています。
ノードの追加削除が行いやすく、ネットワークの設計が行いやすい構造となっています。
②. ブロードキャスト
ネットワークにおいて、全てのノードに対して、同時にデータ（CANでいうならばフレーム）を送信すること。
下記の図のようにECU1が送信したデータは、CANバスに接続されている。ECU2、ECU3、ECU4、ECU5が同じメッセージを受信します。
③. マルチ・マスタ方式
基本的にバスが空いているときに最初に送信を開始したノードが送信を行いますが、送信したいノードが複数ある場合はデータの衝突などが考えられるため、衝突回避策が必要となります。CANではデータフレームに含まれるID（識別子）によって、送信の優先度が決まります。IDの値が小さいデータが優先され、そのデータの送信終了後、直ちに調停で後回しにされたデータが送信されます。下記の図の場合、ECU1とECU3がそれぞれデータを送信しようとしていますが、IDの値が最も小さいECU1から送信されます。
最後に
今回、挙げたものはCAN全体の仕様としても極々一部です。
特に本日記載したこと以外では、フレームのフォーマット、エラー検出処理、ツイストペアによるノイズに対するタフネス、同期処理などについても、機会がありましたら記載したいと思います。最後までご覧いただきありがとうございました。
参考文献
書籍
佐藤道夫（2016）『車載ネットワーク・システム徹底解説』CQ出版.
webページ
増田浩史（2008）
「CANプロトコルを理解するための基礎知識」, < http://monoist.atmarkit.co.jp/mn/articles/0806/16/news124.html>
2017年8月31日アクセス.
ベクター・ジャパン株式会社
「はじめてのCAN/CANFD」,
https://jp.vector.com/vj_beginners-can_jp.html
2017年8月31日アクセス.
CUDA Parallel Reduction
初めに
ご無沙汰しております。iPXの小川です。
弊社では定期的に社内でのCUDA勉強会を実施しております。
新入社員も増え、CUDA教育を行う機会も増えましたが、CUDAアーキテクチャの説明が文や図解だけだと難しく感じている今日このごろです。
そこで本日は私が理解を果たした過程で、一番寄与した Parallel Reduction を題材にサンプルコードを載せつつ寄り道をしながら解説してきたいと思います。
問題点の考察
CUDAの説明はNVIDIA様のオープンな資料・サンプルが充実し、「CUDA C プロフェッショナル プログラミング」などの良書も存在します。
ではなにゆえ壁に直面するのか、その問題点を実体験を元に考察してみます。
CUDA学習の中でよく直面したケースは、下記の黄金パターンでした。
- 概論の習得（理解したつもり）
- サンプルコードの読み解き
- ！理解不能！
何故なのか。
一つの原因は、資料中の説明がある側面から見てなされているからだ、と考えます。
CUDAは一言では並列コンピューティングプラットフォームですが、汎用的なプログラミングの為、デバイスの抽象化やメモリ管理の抽象化などあらゆる抽象化がなされています。
その全てをいきなり説明することも理解することも難しいので、段階によって側面に分解され説明がなされるのは順当な理由です。
よって自分が今学んでいる箇所はデバイスから見た側面なのか、プログラミングモデルから見た側面なのか、メモリモデルから見た側面なのか、説明の視点を理解することが迷子にならない最良の方法です。
CUDAの全てではありませんが、よく使う部分を抜粋して図解しようと思います。
記事で何をやっているかわからなくなった場合は図解を眺め直すことをおすすめします。
※実際にはデバイスによってSMの数などは異なります。
それでは次項よりサンプルコードを載せて解説していきます。
533333ﾞ4444422
前回のブログを見返してみたら某まつりの後に書いていたらしく、放牧前が懐かしくなったタキヤマです。
もう最後の単独ライブから一年ですかー
前回の最後にこんなことを書いていましたが…
> 次回順番が回ってきた時は、実際のDBを使用したチューニングでもやってみようかと思います（たぶん）
今回はまだやってみません。
次はやろうとは思いますが、準備時間がなさそうなので次々回かもしれません。
ということで今回はこちら
続きを読む