とある課題について

とある塾の課題です。急遽参加できなくなってしまったため、課題をWebに上げたものです。

ふと生活していて気になったこと〜からの〜こういうことだったのか!という気づきについて纏めるものです。

メルカリの出品画面

最近ではありませんが、フリーマーケットアプリのメルカリの出品画面の入力項目の並びで「商品画像」が一番最初にあったことが気になりました。

f:id:rocky_manobi:20171115165642p:plain

昔のヤフオク等、PCベースのサービスの出品画面では、商品画像の登録は最後の方に求められました。 最も手間がかかるので、最初に求めてしまうとそもそも離脱してしまう人が多いからだと考えていました。

そんな項目をどうしてトップに持ってくるのかなと思って使ってみたところ、画像を登録した段階で商品のその他の情報が入力されました。 テクノロジーを上手く使って「出品」のハードルを下げられていると思いました。

また、よく考えてみると、スマホインターフェイスでは商品画像の登録、この場合では手持ちの商品の写真を撮る、という行為こそがむしろ他の情報の入力よりも考えずに行える行為であり、一番最初にやってもらう行動としては適切なものなのかも、とも考えました。

f:id:rocky_manobi:20171115164500p:plain

Macの充電器

恥ずかしながら、この羽をこう使えるとは、他の人が使っているのを見るまで気づきませんでした。

f:id:rocky_manobi:20171115170455p:plain

f:id:rocky_manobi:20171115170407p:plain

余ったコードを巻き付ける(今更??って言われそうですが)

f:id:rocky_manobi:20171115170422p:plain

100均のフック(?)

知人の自宅の壁に100均で買えそうなフックが貼り付けてありました。 3つのうち1つが90度傾けて張ってあったのでなんだろうと効いてみたところ、、、

f:id:rocky_manobi:20171115170931p:plain

こんなふうにタブレットを設置して、ベビーモニタを表示しているとのこと。 (実は写真は撮り忘れていたためウチのものです。早速導入しました。タブレットの画面...90度傾いてますね)

f:id:rocky_manobi:20171115170912p:plain

イオンスタイル豊田

母校に講演に行った際に立ち寄った愛知県のイオン豊田で子供のオムツ替えをしていたところ、普段は大暴れするのにおとなしく上を向いて止まっていてくれました。 渡したおもちゃに集中しているわけでもなく、おかしいなと思って上をみたら、天井にアニメが投影されていました。

f:id:rocky_manobi:20171115094513p:plain

洗濯バサミ

この手の一般的な製品は、洗濯ばさみの中心の金属部分に紐(といっていいのか)がついていることが多い気がしますが、わざわざ接合部を2箇所にしてあります。 下方向の力が加わると洗濯ばさみが開く方向にも力が加わるようになっていて「片手で引っ張って取る」というのがやりやすいようになっているのでは、と考えました。

f:id:rocky_manobi:20171115134621p:plain

以上となります m( _ _ )m

Herokuで複数Dynoにするとsocket.ioが繋がらなくなる問題への対処

最近HerokuでSocket.io依存のサービスを運用する機会があったので手順だけメモ。 (日本語記事あまり見つからないので、もしかしたら socket.io-redisがこの問題をも解決してくれているのかな…)

症状

Heroku上でクラスタリングしたsocket.io(node.js)との接続が確立できない。 エラーメッセージは下記2種類。ポーリングで接続成功した後に、websocketにupgradeしようとして失敗しているような感じ。最初に接続確立したときと違うサーバにつなぎに行こうとして怒られてしまっているみたい。

Failed to load resource: the server responded with a status of 400 (Bad Request)
WebSocket connection to ......... failed: WebSocket is closed before the connection is established.

手順

  1. heroku側でhttp-session-affinity をONにする
  2. socket.ioのfallback optionをwebsocket優先にする

現時点ではChromeFirefoxであれば1の対処だけでOK。 Mac/iOS Safariやnode.jsのsocket.io-clientなどの場合は2の対処までしてやる必要があります。

HerokuのHttp Session AffinityをONにする

詳しくは コチラ

heroku features:enable http-session-affinity

client側のsocket.ioのfallback optionをwebsocket優先にする

デフォルトではpolllingwebsocket の順番で接続をしていくsocket.ioですが、クラスタリングされたサーバに接続する場合は順番を指定して、websocketから繋ぐようにする。

const options = { 
  transports: ['websocket', 'polling' ]
};

const socket = io.connect( "URL" ,options);

付録

socket系 x クラスタリングで発生する問題としては、セッションが各nodeで共有されないことくらいで、broadcastのときに困るくらいだろうとタカをくくっていました。Broadcastの問題に関しては別のソリューションで解決していたので、今回はたまたまsocket.io-redisを使っていませんでした。もしかしたらこの問題自体、socket.io-redisが一緒に解決しちゃってくれる可能性もあります。

ちなみにsocket.io、以前はwebsocketから順番にfallbackしていっていたのを、どこかのバージョンで逆にするようにしています。そのほうがwebsocket非対応のオールドブラウザでの接続確立までの時間が短くなるという理由らしいです。

SI(お堅い/石器時代のシステム開発)業界から抜け出してイケてる開発がしたいと思ってやったこと

友人から相談を受けたのでせっかくなので公開する。

SIというか、「受託で硬いシステムを作っている会社に属していて、あまり1からのシステム構築とかやったことがない」という状態から、イケてる(と思われる)会社や開発現場に移るためにどんな準備をしたか、ということを書いていく。ちなみに現在はNextremerにてエンジニアをしつつ、高知AIラボのリーダーとして、イケてるエンジニアリング環境を作るため、色々と試行錯誤をしている。スーパーエンジニアではないけど、今は満足したエンジニアリング生活をしているので、誰かの参考になると良いな。

注意

  • 2012年付近での経験をもとに書いています。時代の違いによる周辺環境の変化についてフォローできているかどうかは保証しかねます。
  • SIがイケていないと言っているのではありません。僕のいた現場がイケていないだけです。
  • 何をもってイケているのか。よりお金が動いているのは当然SIじゃないか!という議論をここでするつもりはありません。割と僕、その考え方に共感しますが、相談内容にそって、エンジニア的視点から書きました。

はじめに

まずは前提条件から。抜け出さねば!!と思ったきっかけは以下のとおり。

  • 豊田高専情報工学卒 + 1年間米国留学 ののち、2009年にシステム開発会社(前々職)に入社(21歳)
  • 1年目,2年目と金融関連のプロジェクトに多数参画し、それなりにできるSE(自称)として勤務
  • 2011年暮れ、会社をやめてWeb系ベンチャーに行った同期組と1年ぶりに再開し、自分の技術力の無さ、及び周辺環境のヤバさに気づく
  • 2012年1月、レベルアップして環境を変えるための活動を開始

最初はなんとなく「バリバリのプログラマ」を目指してスタートしたのだけど、途中からは「ビジネスレイヤと技術レイヤの中間でいい顔をできるポジショニング」に方向転換している。当時考えていたことと、今思えばということとが錯綜しているので、読みづらくなること必至。

主にやったことは以下の3つ

  • アンテナとポートフォリオの整備
  • 技術力の向上(開発/設計/チームビルディング/スタートアップ)
  • プレゼンスとコネクションの整備

上の二つは2012年(当時24歳)に自分でやばいと思ってやったこと。エンジニア/ITビジネス屋としての基礎力をつけるためにやった。三つめは、2013年に出会った師匠的な人と一緒に仕事して感じてやった。最終的には「ビジネスと技術のハイブリッド」という方向性を目指すことにはなったけど、二つ目の技術力向上でやったことの蓄積がなければ、薄っぺらい奴になっていたと思うので今の所全部大事だと思っている。

アンテナとポートフォリオの整備

アンテナ : 情報収集能力

とりあえず、業界でイケてそうな奴らは何を見ていて、何を考えているのかを知りたかったので、著名なエンジニア(のちにビジネス屋)をTwitterでフォローした。「XX使って見た」とか「このイベント面白そう」とか「良記事!!」の情報を垂れ流してくれるので、とりあえず情報INPUTはこれだけでもいいくらい。最初は100人くらい。ココみたいなページが割とたくさんあるので参考にした。 特定のメディアとかをフォローする手ももちろんあるのだけど、自分で選ぶよりも、できる人たちがシェアしてるやつを掠め取った方が最初は効率が良い。その中でよく目にするようなメディアをピックアップしてフォローするのがオススメ。

ポートフォリオ : アウトプットする場所

即転職を意識、というよりも、必要あらばいつでも転職できるようにしておくため、自分が何者かを見てもらえる場所が必要だと考えた。内容はともかく、自ら情報発信をしているというマインドセットは加点になるはずだと考え、下記を始めた。

  • ブログ運用をはじめた
  • Github上での活動を開始した

ブログ運用

当時、自分はサーバ運用を全くしたこともなかったので、さくらVPSを契約してワードプレスを入れて、ついでに自分のプロジェクト管理用にRedmineを入れて運用してみた。今では不要だけど、コードも管理したかったのでSVNとGitの環境整備もしてみた。これらの作業を通じて、ポートやらサービスやらパッケージやらビルドやらSSHやらその辺りをなんとなく理解した。のちの技術書行脚に向けてはかなり役にたったと思っている。とはいえ、その辺りの技術習得の目的がなければ、はてなとかQiita等々、既にあるものに乗れば良いと。

ブログの内容は、勉強のときにハマったことだったり、業務で「ORA-XXXXX」的なエラーにぶち当たってトラブルシュートしたり、「xxxxxの調べ方調べて見て」というオーダーに対して調べたことなどのまとめが中心。それなりにアクセスがつくとやる気が出る。(残念ながらさくらVPSのお金払い忘れて解約してしまい、もうブログは残っていない)。

ただし、技術ブログは自分の底を晒すことにもなるので、ある程度のレベルに達するまでは見習い感が結構でる。その時はわからないのだけど、結構出る。事実、半年前に当時のエントリを読んだ時には悶絶というか、単純に消したくなった(全部消えたのはワザとではない)。書くことを繰り返すという訓練はとても良いことなのだけど、転職においては短期的な成果は得にくい。短期での転職を考えている場合は、とりあえず書き始めて、今回はそれをアピールせずにゆっくり準備をするなどしても良いと思う(転職先で転職したいと思うことだってあるでしょう?)。

ちなみに こんなバカなこと もしてみたことがある。

Github上での活動

優先度と書く順番が逆になってしまうけど、Github上での活動の方が今は大事かも。

まずは勉強の過程で作ったものなどはじゃんじゃんリポジトリにあげて公開してしまうのが良い。PCのdotfiles(設定ファイル)のgit管理とかをやってみるのも良い。また、採用する側の立場から付け加えると、なるべく早くアカウントを作って、ちゃんとプロフィール写真も設定して、転職のために急いで作りました感をなくして置くのも大切。

また、現場では何らかの形でほぼ100%使うことになるので、使い方、UIなどに慣れておくのも大事。

技術力向上(開発/設計/チームビルディング/スタートアップ)

書籍を読んだ

今はdot install、スクーなどのサービスも盛り上がっているので前ほどの重要性はないとの見方が強いけども、なんだかんだで基礎力と語れる厚みを身につけるために本は読んでおいた方が良いと思っている。本当は読んだ書籍を列挙していきたいのだけれど、今出先なので方向性だけ列挙する。

注意 : 本当に時代の影響を強く受けるので注意。それから、相談してくれた人のことを考えながら書いているのでその辺りのバイアスはあるかな。デベロッパーでもSE的な感じでも、この辺りを知識として知っておいた方が良さそうだな〜と思うものをピックアップしたつもり

  • 言語/設計/開発
    • マーティン先生のリファクタリングに始まり、名著と呼ばれるものを中心に読み進める
    • 言語としては当時の唯一の使用言語Javaと、個人的に暑いと思っていたRubyを中心に勉強
    • 今だとSI以外に行くとすれば言語はPython,Ruby,node.js,php,JVM系となる気がする。
    • 関数型に手を出しても良いけどまずは必須ではないと思う。
    • 結城先生のJavaデザインパターン本を写経したのは記憶にある懐かしい(一応知識としては必要だと思っている)
  • ビジネス / マネジメント

それから、SIからの転職という意味では「チーム開発実践入門」は読んでみると良いかも。少し古いけど、このレベルでちゃんとやれてる開発現場はまだまだないし、SI現場だとなかなか想像つかないと思うので理想イメージ掴むためにも読んで見た方が良いかと。

一次情報へアクセスする癖をつけた

何か新しいツールや言語を試そうとする時、最初の方は日本語ドキュメントに頼ることになると思うけど、慣れてきたらインストールや環境構築は公式サイトに行って Get Started の項を参考に行うことをオススメする。一次情報にアクセスできるということは圧倒的なアドバンテージ、というか一次情報にアクセスできないのは圧倒的なディスアドバンテージになるので、英語文書へのアレルギーをなくしておくのはビジネス屋としての生存戦略上必須だと思っている。

プレゼンスとコネクションの整備

かっこよいサブタイトルだけど、要するにIT勉強会にでました、という話。目的は社外にエンジニアの仲間を作りたかったから。深い情報はやっぱりF2Fでの雑談に限るので。(だから運営を手伝ったりとかも積極的にやった) ジャンルは特定の技術だったり、アジャイルなんかの開発プロセスだったり、転職系、ワークスタイル系だったり、とにかく結構参加した。

おすすめとしては、無理目でもなるべく頑張って発表者になること。自分が発表しない勉強会の後の懇親会は辛い。自分から話しかけないといけないので緊張する。一方で発表者であると自分が何者かを全員にあらかじめ効かせた後なので割と色々な人が話しかけてくれる。

というわけで、こんな感じです。

  • コミュ力に自信がある人 : IT勉強会に行く
  • コミュ力に自信がない人 : IT勉強会で発表する

(コミュ力だけではなく、勉強会に参加する人間で一番学びを得ているのは発表者でもあるのでここはおすすめ)

付録 : 移ってから思ったこと

準備としてやったことはとりあえず生きているとおもう。実際に移ってみて大事だと思ったのは「カルチャーギャップを埋める」ということ。 仕事が降ってくる、というよりも社内で仕事をとりにいく、という考え方でないと振り回されることが多くて苦しいと思う。その代わり、割と自分で正しいと思うことができるし、何より周辺環境の変化に対応する力がついた。自分としては移ってよかったと思っている。(業態の違いと会社の規模が一緒に語られている感はあるけど、likely的な感じであっていると思う )

いま書きながら思ったことだけど、上記の3つの準備は「能動的に動く」という習慣をつけるのにも役に立ったのかなと思った。「自分のポートフォリオを作りたい」という意識でいろんなことを調べて色々なものを作って色々な人と話して色々な人と色々なものを作って、、大変だったけど「自分で何をするか決める」「自分でどうするか決める」という経験を積み重ねるのはすごく大事だと思う。周りを見て見ても、そういう活動をしている人の方が、環境変化にうまく適応できている気がする。

それから、 SIer時代の経験は決して無駄ではない ということ。成果物や仕事のやりかたは大きく違うけど、知識として知っておいた方が良いことは本当に沢山ある。「堅くやるならこうだけど、この案件の場合はこの方がいいな」的な判断は、そもそも「堅いやり方」を知らないとできない。なんだかんだでどんな開発現場にも社内外にお客さんがいる。一般的なやり方を知らないことと、知っていて違う選択をすることは大きく違う。SIer時代の経験は確実に生きていると今でも思う(というか最近"特に"そう思う)。

エンジニアとビジネス、Web系とSI系、時と場合によっていろんな帽子を組み合わせて戦える人材は、活躍の範囲がとても広くて重宝される。

とはいえ反対に、過去やってきたやり方に執着しすぎると、ギャップに対応できずに辛い。大事なのは、今いる場所と過去に居た場所と自分の居たい場所の、環境の違いをしっかりと認識して、アクションを選ぶことなのではないかと書きながら思った。このあたりは改めてちゃんと整理してエントリにした方が良いな。

おわりに

上記のとおり準備をしつつ、働きつつとやっていたら、機会に恵まれてフラフラここまで、という感じ。道中で大きな借りを作ってしまった方々も居て、現状その借りを返すために今いるところでまずはビッグになろうと言うのが現在のステータス。これから転職を考えている方に少しでも参考になればと思いますです。

とりあえず、早足だけどこんな感じ。Done is better than perfect なのでここで終わりにしよう。 ちゃんと推敲した記事はまたリライトします。

宣伝

Nextremerではエンジニアを募集しています。 スタートアップのカオス感はありますが、その中でちょっとでもイケてる開発現場になるよう、色々考えてやっています。

www.wantedly.com

Puck.js で遊ぶ - Web Bluetoothを使って、ボタンでブラウザを操作する

株式会社Nextremerアドベントカレンダーの22日目の記事です

長年さくらのVPS上で運用してきたブログが、クレジットカード紛失による停止処理、からの支払い情報再設定の忘却により跡形もなくなくなってしまった関係で、またはてなに戻ってきました。 というわけで一から再出発です。

性懲りもなくJavaScript Board

Nextremer高知AIラボ で働いているのでAIネタを書きたいなと思っていましたが、お世話になっている村岡氏とお寿司を食べていたらPuck.jsを託されてしまったので、2年前のコレのノリよろしくGordon Williams氏並びにEspruinoプロジェクトの援護射撃をしてみたいと思います。

やること

Puck.jsのボタンを押したらブラウザでAlertが出る!それだけだ。 f:id:rocky_manobi:20161223211724g:plain

Puck.js とは

Puck.js - the JavaScript Bluetooth Beacon

https://ksr-ugc.imgix.net/assets/012/951/602/6ea47be2bcca0c693df65467f3a276d0_original.png?w=1536&h=864&fit=fill&bg=000000&v=1468142794&auto=format&q=92&s=61331722490cf5091eb7309e6c90a5b6

さらっと紹介します。

JavaScrpitで制御できる、いや、JavaScriptでしか制御できないIoT向けマイコンEspruinoシリーズの最新作(2016.12.22時点)。 ボード本体だけでなく、BLE(Bluetooth 5.0)、NFCの通信機構や、光、温度、磁気などを測定するセンサー、そしてなんと耐水の筐体までが標準で装備された、脱DIYモデル(なのか?)。ボードの大きさは直径35mmでコイン電池(CR2032)で動作するというのもすぐに何かに使えそう感を醸し出している。

開発もワイヤレスで行うことが前提で作られていて、初期から使っている身としては驚くばかり。もちろんGPIOも6個あるので、これまでのような開発も可能。 Kickstarter価格は1個28ポンド(3000円くらい?)。ちなみに今は日本でも購入できますが、、、高い

Web BluetoothのためのMacChromeの準備

いつもながら丁寧な公式チュートリアルを参考にすれば迷うことなくセットアップができると思いますが、以下の二つだけは押さえておきましょう。

  • MacでBLEが有効かどうかを確認する
    • このMacについて > システムレポート > ハードウェア > Bluetooth とたどって、BlueTooth Low Energyが有効になっていればOK
    • 2,3年以内に買ったMacならほぼ大丈夫でしょう。
  • ChromeでWeb Bluetoothを有効にする
    • アドレスバーにchrome://flags/#enable-web-bluetoothと打ち込めば、あとはお分かりいただけると思います。

上記手順後、Chromeを再起動したのちに、Espruino Web IDEを起動します。最近ではchrome extension版ではなく、オンラインのやつもあるそうです。 デバイス接続ボタンを押して、選択肢にWeb Bluetoothが表示されればPC側の設定はOKです。Espruino Web IDE がわからない方はこちら をどうぞ。

接続ができたら、コンソールにLED1.write(true)とでも打ち込んでみましょう。赤色LEDが光ってくれるはずです。

Puck.jsのボタンでブラウザを操作

それではいよいよボタンでブラウザを操作してみます。実際に動くDEMOはgithubページ に置いてあるので、Puck.jsをお持ちの方は使ってみましょう。

ソースコードはこちらです。

github.com

ポイント

Web Bluetoothを用いて、といっても実際に直でAPIを叩くことはありません。デバイスとの通信の細かいところをWrapしてくれているpuck.jsを使います。ものすごくシンプルです。

puck.jsを読み込む

  <script src="https://www.puck-js.com/puck.js"></script>

ボタンの状態をリスニングする処理**

Listener的なやり方があればと思ったのですが、見つけられなかったので定期的にボタンの状態を読み込む処理を実行することで実現しています。UARTを直接触って、puck.js側もちゃんとプログラミングしてやればもちろん可能ですが、今回は手軽さ重視で。

// 0.5 sec 毎にボタンの状態をチェックする
function startListening(){
    setInterval( function(){
      Puck.eval("BTN.read()",function(x) {
        console.log(x);
        if( x ) {
          // ボタンを押したらやってほしいことを書く
          alert("ボタンを押したな!!!?")
        }
      }); 
    },500);
}

ボタン情報取得を開始するボタン

このWeb BluetoothChromeの実装ではセキュリティの関係で、ユーザ操作なしにBLE通信を開始することはできません。よって、制御開始ボタンを配置して、クリック時に制御処理が走るようにします。ボタンだらけですね。

<button onclick="startListening()">ボタン制御を開始</button>

おわりに

日本で決してスケールすることなく、初期からのコアなファンだけが使い続けているEspruinoシリーズ。 いよいよエンジニア向けDIYきっととしてではなく、何かの製品に紛れ込んできても良いのでは?という期待をせざるをえませんね!

おまけ:せっかくなので音声認識STARTボタンとして

何かのプロダクトに使われるかもしれない、と言いましたがその最初の一つは弊社の対話プロダクト、MINARAIかもしれません。試しにCEATEC JAPAN2016でも展示した、高知県の観光案内を音声対話でやってくれる「ザキオとぶらり」に組み込んでみました。

ボタンを押したら音声認識をスタートさせる、の図

www.youtube.com

騒音ガヤガヤの中でも僕の質問を聞き取ってくれていますね。

騒音のある環境下における音声認識の大きな課題は、実はノイズよりも「どこからどこまでが答えるべきユーザ発話なのか」をハンドリングするところにあります。例えば近くで人が雑談していたり、館内放送が流れていたりすると、その声を認識してしゃべり始めてしまうわけです。 現状弊社は、タッチパネルでボタンを押してから音声認識を開始したり、音声認識は動きっぱなしにしておいて、ボタン付きマイクのボタンを押している間以外は音量が0になるように制御したりして、この問題を避けています(もちろん研究レベルでは正面から戦っていますが...)。

ただ、タッチパネルは通常のディスプレイに比べて、現場に設置した場合の耐久性に難があることが、ボタン付きマイクは設置場所やマイクの形状などに制限が出てしまうことがデメリットになっています。と、いうわけで、こういった手軽に使えるIoTデバイスを用いたボタン&ソフト的アプローチは良い解決策になるかもしれません。

もしかしたら今後の弊社の展示物にこんなボタンがついたものが出てくるかも。。。。