2020年のミーティングベストプラクティス - miso-engine
仕事でミーティングを主催するようになって、かつて自分が感じたミーティングに対する不満をすべて解決しようと試行錯誤してきた。昔作ったミーティングへの不満を箇条書きしたものが出てきたのでアップしておく。笑ってしまう勢いがある。 アジェンダがない 議事録がない 議論がループする 会議に関するファイルが見つからない 合意形成の経緯がわからない 発言の少ないメンバーの意見が反映されない 後からSlackで意見が投げられる メンバーによって使える時間がまちまち リモート参加も多く現地メンバーとすれ違いがち この件を友達と話したところ、みんなさも当たり前のようにミーティングをしているけど、誰にもミーティングの仕方を教わったことないし、勉強してないよねって話題になり、それもそうだなぁと思って改めて調べてみて色々試してきた。その結果たる現時点の川鍋流ベストプラクティスを共有する。リモートワークにももちろん対
天井への金具設置メモ - miso-engine
会社に屋内測位システムQuuppa*1を導入した。Quuppaは電波を発信するロケーターを天井に取り付ける必要があり、そのための工事をした。この記事は、天井への機械の吊り下げを行うための金具を設置するためのメモである。 設置後の様子 天井に設置した機械と金具 石膏ボードと思われる天井に、凸型の金具（凸部と両サイドに穴があるもの）をボードアンカーで留め、その金具と機械の金具をボルトで留めている。 天井の状況 www.diy-shop.jp 弊社の天井は、通常の石膏ボードと思われるものであった。構造的には上記記事の画像の通りになっていた。桟の部分には木ネジで行けるが、それ以外の中空部分ではボードアンカーを使う必要がある。今回、位置測位システムだったので、部屋の中央に置きたく、そこは中空だったのでボードアンカーを利用した。 ボードアンカー 記事にある通り、ボードアンカーは複数種類あるが、ネジを利
macOSでのopenFrameworksのIDEはQt Creatorが良かった - miso-engine
openFrameworksもv0.10.0がリリースされたことだしと思い、oFを書く時のmacOSのIDEを調査＆比較してみた。結果はQt Creatorがコード補完の精度と速度、アドオンの扱いやすさの点でベストだと思う。比較したIDEは以下の3つ。 Xcode 9.3.1 Visual Studio Code 1.23.1 Qt Creator 4.6.1 コンピューターの環境 macOS High Sierra 10.13.4 openFrameworks v0.10.0 Xcode macOSのデフォルト開発環境でありoF公式にサポートされているIDEでもあるが、oFの開発において以下のような欠点がある。 コード補完がダメダメ やたら重い 設定ファイルがいつの間にか書き換わりがち アドオンの追加がめんどくさい とにかく使っていてストレスが溜まりがちなIDEであるが、Swift開発だ
仕事場のコンテナ収納 - miso-engine
はじめに 収納についてずっと考えてきたけど、プラスチックのコンテナを使うのが正解だとようやく分かった。よく片付いてるなと思う研究室（橋本研や梶本研など）の様子を垣間見るたびにプラスチックのコンテナがちらちら見えてたからなんとなくそうなんだろうなと思っていた。 件の橋本研。デイリーポータルＺで垣間見える。写真は、”アイデアスケッチの描き方を習ってわかった10のポイント - デイリーポータルZ：@nifty” から引用している。 左後ろにコンテナ収納がびっしり詰まっている。コンテナが入っているところは、棚の高さを目一杯生かしていて、ほとんど隙間がなくスペース効率が極めて高い。 こちらの画像では、ラベルも見える。 ということで、思い切ってプラのコンテナをたくさん買ってみたらめっちゃ片付いた。 買ったコンテナ 思い切って買い過ぎて天井まで積み上げられてしまった。すべてのコンテナは透明であるとよい。
openFrameworksでやっておくとよいこと - miso-engine
仕事するたびに毎回忘れてしまった！って思ったりするのでまとめておく。 設計編 全体の設計を考える アプリを分けてOSCで連携する 規模が大きい & 期間が長い場合はAPIを先に定義し、各々がモックで開発するべき ofxStateMachineを使って各Stateごとの動作にする そもそもoFを使わない（UI系はネイティブなども検討する） クラスの設計 基本はシンプルにオブジェクトの保有とポリモーフィズムで コールバックはofEventを使う 設計と資料（全て手書きで良い） クラスが10を超えるならクラス図を作る 複雑な処理はシーケンス図を書いて把握する 他のアプリやデバイスと連携が必要なときもシーケンス図で処理を把握する 状態遷移が多いものは、画面遷移図か状態遷移図を用意する 設計のためのデザインパターンを知っておく 非直感的な設計のデザインパターンは大変便利なときがある デザインパターン
openFrameworksからのUnity入門 - miso-engine
僕は普段、なにか表示系のものを作るときはopenFrameworksを使っているのだけど、今回3Dでグリグリや！という案件があったのでUnityを利用した。ということでoF経験者がUnityに入門する時のノウハウをまとめておく。Unityのバージョンは5.6.1f1、oFはv0.9.8。 Unityの強みと弱み Unityはゲームエンジンで、ゲームエンジンなので状態や遷移の管理に優れており、3Dオブジェクトの扱いが簡単、強力なGUIによってパラメータの変更がラク、標準で物理演算エンジンが組み込まれているが、一方でテクスチャになにかを描いたりする機能はない。oFとの比較で強みと弱みをまとめると以下のような感じだ。 強み シーン、アニメーションなどの状態管理が優れている ゲームエンジンなのでそのへんのサポートが豊富 特にアニメーションはコード無しでかなり高度なことが出来て大変助かった 強力なエ
Mac対応コンピュータビジョン向けカメラ - miso-engine
先日の仕事で、Webカメラの性能だと微妙だなって感じがあったので、コンピュータビジョン向けカメラを検討し、導入してみたので共有。 使ってみた感想的にはWebカメラで足りるならWebカメラ使ったほうが気軽でいいね、といったところ。もちろんコンピュータビジョン向けのカメラにもメリットはあるのだが、気軽に、という感じではないのだ。 ロジクール c920r 前も紹介したがWebカメラ界最高峰。720Pで30fps出せる。こいつを使ってみてダメなときにコンピュータビジョン向けカメラを検討するべき。 Logicool ロジクール HD プロ ウェブカム c920r 出版社/メーカー: ロジクール発売日: 2015/09/17メディア: Personal Computersこの商品を含むブログを見る コンピュータビジョン向けカメラとは 720Pで60fpsはUSB2.0だと厳しく、USB3かEthern
openFrameworksのofxOSCでデカい（65KB以上くらい）データを送る - miso-engine
openFramworksのofxOSCでは画像を送ることが可能だが、サンプルにも書かれている通り、一定以上のサイズはサンプルのコードでは送る事ができない。具体的には大体65000Byte以上くらいなのだが、これはOSCが利用しているUDPのペイロードサイズの制限（より正確にはIPパケット）によるものだ。ちょうどよい解説が@ITにあったので引用しておく。 1つのUDPパケットで運ぶことのできるデータ(「ペイロード(荷物)」という)の長さは、下位層のIPパケットの長さの制約を受ける。(標準の)IPパケットでは、1回の送信で、最大では65515bytes(65535bytesから、IPヘッダの最低サイズ20bytesを引いたもの)までのデータを送信することができる(IPヘッダ・オプションが付くと、さらに小さくなる)。そのため、1つのUDPパケットで送信することのできる最大ペイロード・サイズは、
openFrameworksでofThreadを利用しマルチスレッドを実装する - miso-engine
先日openFrameworks（以下oF）を使った仕事でどうしてもシングルスレッドだと画像の処理速度が遅いのでマルチスレッドにしたことがあった。Macを使っていたので、最初はiOSアプリを作っていた時代に使い慣れていたGCDを利用していたのだけど、どうもGCDを利用すると落ちたりはしないのだが、肝心の処理する画像が極稀にグリッチし、頻繁にメモリの位置が間違っていた。そこで、最終的にはC++のスレッドを扱う機能を抽象化したofThreadを利用してマルチスレッドの処理を実現したので、ofThreadの使い方のメモを残しておく。 oFにおけるマルチスレッドプログラミングの注意点 最初に注意点を書くと、oFの元となるOpenGLの限界によりOpenGL的な機能はマルチスレッド出来ない。というのもOpenGLはメインスレッド（GLスレッドと呼ばれる）で動く必要があるからだ。そのため、画像の処理に
mbedのBLE_APIライブラリで128bitUUIDを利用する - miso-engine
表題の件をもう少し詳しく説明するとBLEにおいてGATTサービスのUUIDは128bitなのだが、mbedのBLEスタックであるBLE_APIライブラリのサンプルコードでは16bitのUUIDが使われたものばかりで、128bitで利用しようとすると少々ややこしかったのでここに書いておく。 なぜサンプルコードが16bitUUIDばかり使うかというと、Bluetooth規格で定められたサービスであれば16bitで定義されているからで、大体の利用がそれで足りるからだろう。しかし、独自のサービスをいれたい場合、16bitのUUIDは利用してはいけない*1ので、128bitのUUIDを利用しないといけないのだ。 前提 BLE_APIは2015年10月7日時点での最新版を利用した。また、mbedはBLE Nanoを利用している。 https://developer.mbed.org/teams/Blu
BLE NanoをmbedとしてMacから使うとき、Finderでプログラムを書き込まないほうがよい - miso-engine
BLE Nano — RedBearLab RedBearLabのBLE NanoはNordic nRF51822 SoCを簡単に使えるようにしたボード。話題のBLE（Bluetooth LE）が簡単かつちっちゃく使える。開発環境としては、Nordic nRF51822 BLE SDK、mbed、Arduinoが使える。今回mbedで使おうとしたのだが、肝心のプログラムの書き込み部分がうまくいかないことがあって、その解決方法を書いておく。 BLE Nanoキット 出版社/メーカー: スイッチサイエンスメディア: エレクトロニクスこの商品を含むブログを見る 問題 BLE Nanoでは、というかmbedでは、"MBED"としてマウントされたボリュームに、サーバー側でコンパイルしたバイナリ（hexファイル）をコピーするとプログラムが書き込まれる。Macだと当然Finderからやると思うのだが、そ
研究室・工房の工具収納術 - miso-engine
今年の4月から早稲田大学の橋田朋子研究室に修士1年として所属しています。この研究室は学生が入るのは今年からの新しい研究室で、ほぼなんにもない状態から研究をスタートしています。研究自体もイチから楽しんでやってるのですが、研究室の部屋自体もまっさらで、机、椅子、棚をなににするか、というところから始まっています。 橋田研究室は、 メディアテクノロジーの研究を通じて、ヒトが情報世界や実世界のモノ・コト・ヒトへアクセスするためのディスプレイ・インタフェース・空間の新たなキノウやカタチの在り方ついて多角的に探求したいと考えています。 http://tomokohashida.tumblr.com/about という研究室なので、ものづくりをしないと研究になりません。そんなわけで、工具の収納自体と収納方法について、ベストプラクティスを知りたいなと思っていたところ、友人の矢島さん@kasumi_yとしげお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
