イベントメモ に関する投稿を表示しています

せっかくだから STARMARIE の情報をまとめて紹介するよ

知人と共に STARMARIE のワンマンライブに参加してきた。

STARMARIE OFFICIAL WEB -2018年2月4日 中野サンプラザ単独公演-

知人に提供する目的で信頼できるソース(主に公式系)の URL を色々まとめてたんだけど、せっかくだからココにも書いておく。

特に代表のブログとか探そうとしないと見つからないのにいい話の塊みたいなものなのでぜひチェックしてほしい。むしろ代表推したい…


  • 今のところはメンバーカラーが特にない

  • 各メンバーの愛称、呼び名も上記の通り。
    • のんちゃん : 木下 望
    • しのはむ : 高森 紫乃
    • ひぃちゃん : 松崎 博香
    • もにゃ : 中根 もにゃ
    • かえちゃん : 渡辺 楓
  • mix、コール、掛け声、ライブの雰囲気など
    • 今は特にまとまったものはないっぽい(?)
      • ライブの様子を見る限りは、何曲か自発的にまとまったような掛け声があるっぽい
        • 実際何か言ってる
    • ライブでは振りコピするが多い
      • オタ芸している人もちらほら居たりはする
      • 人気曲なんかでサイリウム持ってると振りコピが整って見えてとても良さがある
      • もちろん振りコピをしないでサイリウム振っている人もいる
      • 各自の高まりたいように、応援したいようにやったらいいと思う!!!
        • ただし本人達はもちろん、周りの人にも厄介行為することだけはNG

THE AI 2018 というイベントに参加したメモ

先日、株式会社レッジが主催する THE AI 2018 というイベントに、色々が色々あって参加させてもらった。色々が色々でちゃんと見てなかったのだけどチケット 4 万円なのか…

THE AI 2018 | Ledge.ai

Ledge.ai たまにディープラーニング系のこと調べて辿りついたりするのだけど、元々が BITA デジマラボ、ビットエーだったとのこと、それはしらんかった。

Ledge.ai(レッジ) | AI:人工知能特化型メディア

ビットエー、AI特化型メディア「BITAデジマラボ」を「Ledge.ai(レッジエーアイ)」として全面刷新し、AI関連事業を「株式会社レッジ」として子会社化|株式会社ビットエーのプレスリリース

 

会場の雰囲気はこんな感じだった。オープニングがブチアゲ EDM で非常によかった(そこじゃない)

 

要するにイベントレポって話なわけで、気になったところだけメモしてたので、それを~~~。

  • 「未来ではなく、今のAIの話」「ビジネスに使えるAIの話」をするような場所。
  • 人間のスゴイところは変化はいろいろあるが、当たり前が変化することに適応していくところ
  • アスリートの学習の話
    • 自動化
      • 物事を反復するのは考えなくても出来るようにするため
      • 細部への意識ではなく全体の意識に変わる = チャンク化
      • 一度自動化したものを忘れることは難しい(英単語を日本語で考えるとか)
      • 上手くなることはその環境下で最適化すること
      • とはいえ完璧に最適化すると変化に対応できない
    • 集中
      • 集中は発想の連鎖を止めて没頭している状態
      • 上位でざっくり考えて全体が動いている(歩く時混乱しないよね)
      • 逆に下まで考えていることが降りてくると混乱する
      • 発想の連鎖を止めるために外部のモノ、テクノロジーも使う
      • 体験すると再現性が生まれる、フェアでなくなってしまうので、ドーピングはチートアイテム
    • イメージ
      • VRはある意味それ
      • トップアスリートにはデータや傾向がないのでイメージが大事
      • 他人の動きを見て推測、抽象化することが上手い人が多い
      • ただし推測は実態と違う、腕を動かそうと思っても肩を動かさないといけなかったり
      • 予測ができる範囲のことでは学習はできない
      • 計画できないものを計画できるような設計が学習には大事
    • 内製
      • アスリートは記憶を都合よく変える人が多い印象、自分を信じてやっていく
      • ビジョンを作る、10秒切るぞ!とか。それがないと10秒は何の意味もない
      • ビジョンとのギャップを考えて改善していく
      • 考えると頭のなかで失敗もできる
      • 頭のなかでシミュレーション、経験を積んで、深く考えていく
    • 欲求
      • 短期と長期の欲求をコントロールする
      • 今日は遊びたい、来年オリンピック出たい。練習したら遊ぼう!など
    • 長くスポーツを見ていて、勉強して100年前と同じという印象
      • 強い者でもなく、賢い者でもなく、適応した者が生き残っていく
      • 人の能力は必要で、AIが出来てもそれに合わせて適応し動いていく
  • MSさんの話
    • Azure、Trusted Cloudを意識している
      • セキュリティ、個人情報、コンプライアンス
      • そして透明性。公的機関から要請されたらすぐ情報を出せる
      • データセンターの紹介動画
    • AzureのCognitiveService
      • Vision, Language, Speech, Search, Knowledge
      • 中でもSearchは画像検索もできたりして面白い
      • Bingのデータを使ったりもしている
      • ビジネスで使えるよう、カスタムできるものも提供している
      • 活用例
        • レタス農家、コンバインとAIで雑草の仕分け
        • 北大eラーニング、字幕と翻訳の自動化
        • JFKの文章公開、OCRやテキスト起こし、検索で文章検索
        • 鳥の計測
        • 他にもいろいろあるよ
    • AzureのDataLake
      • SQLライクに書けるものを使ったBigData処理
      • そこにCognitiveServiceの一部の機能を組み合わせられうr
    • これまでデータは手入力していた
      • いかにしてデータの価値を上げていくか、自動化するか
      • 文字よりも写真のほうが情報量が多い、AIでそれもわかるようにんっってきた
      • IoTもデータ集めの自動化
    • AIはソフトウェアのエンジン
      • 正しく使わないと、正しく成果が出ない
      • Azureはドメインに限らず使えるように工夫している
      • なのでそのまま特化したドメインに適用しようとするとうまくいかない
      • ビジネスに使えない可能性も高いので、カスタムできるようにしている
        • データ収集~モデル構築~学習~運用
      • ルールベースの世界にちょっとのAIを足すことで今までより便利な世界になる
    • AIスクールも無料で見れるので活用してほしい
  • リクルートさんの話
    • テクノロジーズ、R&Dでビジネスへの活用をする
    • リクルート内では人のパターンを模倣するものとしてAIを定義
      • データとアルゴリズムで人のパターンを再現する
    • 社内でデータは多数いろいろあって何か使えないかなあというところでA3RTが誕生
      • A3RTでAIの構築が簡単になるので、ビジネス検討や要件、に注力できる
    • 事例
      • カーセンサーでCNN、写真から車名を当てられる。SNSでバズる
      • ゼクシィ、やりたい式の写真からキーワードを上げてくれる
      • ArGon、社内全体的に利用している校閲サービス。ルールベースと機械学習
        • Word2Vecやレーベンシュタイン距離、Bidictional LSTMを活用して誤字脱字、表記ゆれ、矛盾の解決
        • ルールはWeb上のUIを使って簡単に設定できるようになっている
      • 口コミ、CNN、AttensionNetで審査の自動化
    • AIは完璧でないので育てていく。学習しよう
      • AIは補助的なものである
      • AIを使って何をしたいか明確化する
      • 精度100%は無理、人がデータ入れたりロジック考えるんで
      • やりっぱなしじゃなくて、AIでどうなった、進化させていこう
    • AIの難しいところはAIだけ考えればいいわけでないところ
      • 運用するならアーキテクチャやインタフェースも考える必要がある
      • 新しいロジックや仕組みを使えば出来るわけでもない
      • チームで戦う。Pythonできますでは戦えない
    • 施策を継続していくために、問題を解決したり実際に使っていく
      • KPI、精度の目標は事前にすりあわせておく。見切り発車はあぶない
    • 逆にR&Dとして、テクノロジーを元にチャレンジする場も作っている
      • DQNを何かに使えないか?→UXやサイト改善?
      • 資料を作るのも時間が掛かるので、適切に判断するためにも上司は内容を理解するよう追いつけるよう務める
  • CAさんの話
    • AI Lab、産学連携なども駆使して、AI技術自体を良くしていこうとしている
    • たとえば阪大の石黒先生と一緒に社会実験をしている
      • 接客コミュニケーション
        • 音声、処理に時間が掛かる
        • テキスト、一問一答の精度は良いがやりとりが難しい
        • 選択式、現段階では最適か?ストーリーの折込もできる
    • アドテクでもAIを活用する
      • ブランド既存の回避、CV率上昇。テロや悲惨なニュースを避けたり
      • 文書の意味をアノテーションして推定、適切なマッチングへ
    • ロボットインタラクション、人とロボットのつながりを研究している
      • 近距離でのコミュニケーションは昔から変わっていない、これをテクノロジーしていきたい
  • ドコモさんの話
    • イノベーションを起こしていく、新規事業を作っていく部署がある
    • ecコンシェル。AIをビジネス、デジタルマーケティングに使った
      • ドコモはコミュニケーションの会社、webのコミュニケーションを良くしたい
      • 個人に特化したものを一部AIを入れてやっていく
    • Produt, Market Fit
      • ものと市場の合わせていく、マーケットにウケるものじゃないとどんなにいい出来でも売れない、難しい
    • バナーや施策は何があたるかわからない
      • 多腕バンディットアルゴリズムで色々出して解決するようなものやっている
      • 実際にはPKSHAと一緒に。
      • webの改善に強化学習を取り入れたりしている
    • AIDMA、それぞれのフェーズでコミュニケーションのやり方が違う
      • 行動心理学などの考え方もAIに取り入れつつ、適切なアクションを導き出す
      • ダッシュボードを用意して可視化
      • そもそもAIDMAのフェーズもAIで判定できるのでは?
  • ソニーさんの話
    • ディープラーニングは破壊的テクノロジー
      • 機械学習でできなかった可能性を実現できる
      • 色々な作業が自動化されていく、応用範囲、普及が広がっていく
    • ソニーでは機械学習は昔から。2010年くらいからディープラーニングもやっている
      • 事業がたくさんあるので、横断的にできるよう適切に開発できるようなツールを内製している、今回で三世代目
      • 社内で1000人以上使っている
      • コアとなるライブラリとGUIでネットワーク構築できるツール
    • 社内の事例
      • 不動産の予測、間取りや駅徒歩などの情報から金額を予測
      • Experia Ear、頭の動きセンサ、動きの判定
      • aibo、画像認識、各種センサで行動を分岐
    • 認識の基本は入力と出力のペア
      • 意識して業務を見つめると、きっと自動化できるものがある
      • その上でNNの設計が必要で、最後は回して学習していく
      • ディープラーニングのポテンシャルがあるので、発想と取り組み次第で利益へ
      • 一方で利用する人自身の認識が不足、応用できる技術者が少ない
      • そこで内製ツールを公開して盛り上げていきたい
    • ニューラルネットワークライブラリ
      • Tensorflowやchainerのように使える。LeNetも6行で書ける、GPU利用も1行で設定完了
      • C++で書いているのでエッジデバイスでも使える
      • インタフェースとしてはC++とPythonものを提供している
      • コア部分はプラグイン方式を取っているので自社デバイス、特殊な環境も使える
    • ニューラルネットワーククライアント
      • GUIでネットワーク構築が出来る
      • Windows向けアプリケーション、クラウド版もCPU版は公開、GPUはもうちょっと
      • AutoEncoderやRNN、GAN、半教師なども組める
      • テンプレ機能で難しいネットワークも1ボタンで組める
      • 最後の仕上げにネットワークの構成やパラメータを変えて最適化していく機能がある
      • 出来上がったネットワークはライブラリで利用できる形式で出力できる
    • みんな使ってね

 

ソニーさんのやつは見ていて面白そうだった。ディープラーニング出来る人が組んで試すという時代は通り過ぎ、知見がない人(プログラミングも)もとりあえず使うことが出来る時代になったのかもしれない。
「GANで画像が作れるんでしょ、でもなあ…」→ニューラルネットワークコンソールを使ったら簡単にできるよ!!

Neural Network Console

 

リクルートさんの A3RT も一部公開されている。無料で出来上がったモデルが使えるので、ディープラーニングのパワーを感じるのにはいいかもしれない。校正 API とかめっちゃ良さそうじゃないっすか。

A3RT

 

プレス席があったので、そのうちメディア系のところからちゃんとした(?)イベントレポがでると思うので、他のセッションどうなんよとかはそういうのを見るとよさそう。

 

参加していた人は役職も企業も様々で、だれもが AI に関心な感じだった。役職の部分だとエンジニアやデータサイエンティストな人もいれば、セールスな人、マネージャーな人、などなど。企業側は大手や小さい会社、web、リアル、などなど。
この一日、チケット代も含め、企業間の取引の話も進んでいるだろうし、数千万円とかもっと大きなお金がゴゴゴってなってるんだろうなあ。なるほど~

とやかくとかではまったく無いんだけど、この手のちゃんとしすぎているイベントは俺が作るんだ!な人は、得られる情報があまりない可能性もあるので、参加しないほうが良さそう。少なくともぼくの感覚としては、テックテック!な人じゃなくて、単純に懇親会ネットワーキングマンでビジネスするぞ!な人が一番価値ありそうだなあっておもいました!

 

逆に作る人は仕事で使えるようにこのインタビューに出てる本を読むと幸せ度があがるとおもいます。ぼくはちょっとだけしか読めてないんですが、サービスへの機械学習システムをどういう形で組み込むか、とか、機械学習を使わずに分析していく、とかって話はめっちゃ良いです。

【AI people:vol.7】『仕事ではじめる機械学習』著者座談会:前編 きっかけは「没原稿の供養プロジェクト」だった | blog - 人工知能(AI)/機械学習に特化した勉強会コミュニティ【Team AI】

Progressive Web Apps Roadshow Tokyo 2017 に参加した

PWA Roadshow Tokyo 2017 という PWA についていろいろ説明したり、コードを弄ったり、未来を感じたりするイベントに参加してきたログ的なもの。

イベント応募

Google Developers Japan のブログを見ていたら、たまたまイベントやるよ!を見かける。

Google Developers Japan: Progressive Web Apps Roadshow Tokyo 2017 を開催します

PWA という単語をぼちぼち聞いてはいて、てっきり Web サイトがアプリ化できる!というものだと思っていたものの、それ以上はまったくしらなかったので、せっかくだから勉強してみよう!と Google 主催のイベントに応募したのがきっかけ。

イベントページはここ。
Progressive Web Apps Roadshow Tokyo 2017 | ホーム

イベントページ自体は日本語なものの、セッションが英語だったりちょこちょこと文言が英語で若干不安になるが、それはまあそれとして、英語の勉強にもいいでしょう、と気合を入れて応募した。定員200名に入るのかどうかわからなかったが、後日参加できるよ!のメールが来てホッとしたことを覚えている。

受付~会場入り

平日だったので、ギョムをおやすみさせてもらっていった。 Google 東京オフィスはたぶん初めて…、前に何かのイベントでいったことあるかも?六本木ヒルズ、森タワーにそのオフィスを構える。

Google のオフィス | Google

東京
〒106-6126
東京都港区
六本木 6-10-1
六本木ヒルズ森タワー
電話: +81-3-6384-9000

日比谷線六本木駅からもそう遠くない。 1 番の出口を目指すと到着する。

通常、森タワーに部外者が入るには、対応する LL または UL にある受付の人に名刺を見せたりが必要だが、今回は多くの人が訪れることもあってか LL にイベント用の受付が設置されていた。受付の方にメールで来ていた参加証を見せる。参加者の名前をリストにしているようで、来た人欄に丸がつけられた。

会場は 27 階…(だったと思う)で C ホールからエレベーターで行く。

会場はプレゼンホールのようになっていて、足元に電源あり、 27? くらいのモニター 9 枚による巨大なスクリーン、後方席には上にもディスプレイ、そしてゆったりとした座席、さらには後ろに通訳ブース、とすごく整っていた会場だった。
窓、明かりは壁際のスイッチでオンオフできるよう。壁一面が真っ白でスクリーン周辺は黒なっていて、見やすかった。

話し声が聞こえたところによると、このスペースはわりかしできたばかりで、このイベントが初めての通訳ありだったり大規模にやったり、人柱てきなものになっていたそう。

ちなみに Google のゲスト用の無線 LAN アクセスポイントの SSID は GoogleGuest でパスワード無しだった。よく見ると GoogleGuestLegacy みたいなものもあって、無線 LAN ルータを刷新でもしたのかな?なんて思ってた。

いろいろセッションメモ

ずらーーーーっとして、見にくい点は申し訳ない。整えるとちょっとつらみが。。

キーノート: Progressive Web Apps: What, Why and How

  • Ajax で Web は変わった
    • Google Maps で革命が、ズーム、スクロール、自動読み込み
  • 2014年にモバイルとデスクトップの利用率が入れ替わる
    • モバイルでは 87% のユーザがアプリ体験を重視している、通知やホームスクリーン
    • ユーザの時間はよく使うアプリ 3 つにおおよそ集約する
      • 新規インストールもなかなか起こらない
    • モバイルにおいて)アプリは体験、可能性、将来性が高い一方で多くにリーチすることは難しい
    • モバイルにおいて)Web は逆にリーチできるが体験がアプリほど高くない
      • PWA でそれを解決していきたい
  • PWA はユーザエクスペリエンス向上のため、エンドユーザのための仕事をすること
  • PWA で新しいことを多数学ぶ必要はない
    • いままでのことを応用、よりよくするだけ
    • FIRE = Fast Integrated Reliable Engaging の観点で価値を生み出していく
      • Fast: 動作を軽快に、パフォーマンスを良く
      • Integrated: ネイティブアプリと同じような OS と融合したユーザ体験を
      • Reliable: 通信が途切れてもよいような Web 、信頼性を高く
      • Engaging: ユーザ体験、Web サイトの価値向上
    • こういったものに Service Worker が必要不可欠
      • ブラウザとサーバ、ネットワーク通信との間にはまり、オフライン機能の提供をすることもできる
  • PWA は Progressive(段階的) である
    • Web で作ったアプリケーションをデスクトップでもモバイルでも
    • モバイルは端末、環境がさまざまなので、フィーチャーディテクションを使い、段階的に機能・体験を提供しよう
  • PWA はどんどん広まっている
    • Twitter, LANCOME, Lyfy, Nikkei, Rakuten, suumo, travago, CNET, CNN, forbes, …

セッション1: Integrated Experiences

  • FIRE の 2つめ
    • web と OS がより連携し、よりよい体験を
  • 80% のユーザがモバイルのホーム画面上でアプリを移動している
    • 利便性や見た目を重視する
    • web ページのショートカットをホーム画面に置くことはいままでもできていた
      • 設置するにあたってメニュー操作が必要、ブラウザが立ち上がる、オフラインで見れないといったエクスペリエンスの問題があった
    • WebApp Manifest で解決する
      • ウェブアプリ マニフェスト  |  Web  |  Google Developers
      • 見た目上はほぼアプリになり、どんなアイコンか、起動画面をどうするかを設定できる
      • ブラウザによって実装がことなるが、自動でサジェストしてくれる
        • Chrome の場合は次の通り
          • WebApp Manifest が正しく書かれている
            • アプリ名、144px のアイコン、 URL
            • 要するにアプリっぽく見えるためのプロパティが必須
          • Offline Support with Service Worker
            • ネットワークがなくても動作する、という信頼がないとだめ
          • Engaged User
            • スパムアプリでないことを Chrome がチェックしている
            • 基準は明確に決まっておらず、様子を見ながらころころ変わっている
              • 「たまたまアクセスがあったときにサジェストを出す」ではない
          • こうしたややこしいことがあるのは FIRE を約束するため
  • Web Payments
    • モバイルの CVR は デスクトップ比で 66% 低い
      • 購買には支払情報、届け先などをフォーム上で入力が必要
      • モバイルで入力するのは面倒なので、離脱率が高いように見える
    • そのフォームが面倒なことに対して Autofill がすでにある
      • 最適なフォームの作成  |  Web  |  Google Developers
      • ブラウザはフィールドの属性値と並びで判断している
        • zipcode は国際的なのでわかるが yubin は判断できない
      • うまく動かないケース多いハズなので、正しく autocomplete 属性を設定すること
        • 新しい属性を入れるので元々のコードを汚すことがない
    • すべての Web サイトに対して、お金を払うことについて一貫したユーザ体験を提供することが Web Payments の目的
      • 支払い方法、配送先を決められる
        • Android Pay など支払い専用アプリケーションを利用することもできる
          • 複数指定して、対応している支払いするものだけ表示される
        • 指定された生情報が JS に渡される
      • お金を支払う処理まで行うものではなく、決済と配送先の入力を簡易的にするためのもの
      • クロスブラウザ、クロスプラットフォーム、オープンなエコシステム
    • Autofill は古いブラウザでも問題がないので積極的に利用していくとよい
      • フィーチャーディテクションを行い Web Payments も利用していくとユーザ体験が向上する
    • Web Payments はまだまだ発展する余地があるので、デベロッパーからの意見を取り入れていきたい
  • 他にも OS と融合していく機能・体験はある
    • Media Session, Media Capture, Casting Support, …
    • PWA として他のアプリと同じように振る舞うための API

セッション 2: Reliable Experiences

  • Web だから、ネットワークがどうであれ、アプリのように振る舞うことでユーザビリティを上げる
    • アプリはオフラインでも動く
    • 地下鉄では移動して接続が切れたりする、勝手が悪い
    • 新高校では電波が立っているが通信がうまくできなかったりする
    • 世界では 60% のユーザが 2G 回線を利用して、 3 秒待つと 53% が離脱している
  • Service Worker で解決していく
    • ローカルプロキシとして動作する、データのキャッシュを行える
    • 常に動いているわけではなく、必要なときに動作する
      • ブラウザが閉じていても通知を受信したらワーカーが起動する、など
      • App like lifecycle
        • 登録、インストールが必要
        • ユーザは何が起こっているのか知る必要は無く、裏で静かに動く
    • ローカルプロキシとしては 2 回目の読み込みから動くようになる
      • 初回の読み込みは登録とインストールだけ
      • 2 回目以降でワーカ0のアップデートを確認し、動いていく
    • キャッシュやリクエスト、ネットワーク状況をコントロールできる
      • キャッシュ戦略をいくつか紹介
        • キャッシュを見て、なければネットワークへレスポンス
          • 更新ができないので、あまり変わらないようなものにオススメ
        • ネットワークを見て、なければキャッシュを見る
          • ネットワークが繋がりにくいと待たされるが、キャッシュ更新は可能
        • キャッシュとネットワークの同時リクエスト
          • キャッシュがあれば利用
          • ネットワークが来たらキャッシュ更新し、データ反映
        • キャッシュ→ネットワーク→キャッシュ
          • ネットワークが繋がらないので何かコンテンツを提供することができる
          • ユーザの離脱を回避する可能性がある
      • キャッシュはアプリケーションの性質によってベストな方法が変わる
  • Service Worker のためのツールセット
    • DevTools は有効に使える
      • 困ったときは Clear Storage を実行するとおおよそ解決する
    • workbox
      • Welcome to Workbox
      • キャッシュ戦略のコードを簡単に記述することができる

セッション 3: Engaging Experiences

  • Material Design が PWA でも活用できる
  • プッシュ通知
    • タイムリーに正確で意味のある必要な情報を通知することがよい通知
      • x) 飛行機の離陸時間が変わりました!
      • o) 登場予定の xx 便の離陸時間が 13:00 から 14:00 に変更になりました
    • PWA におけるプッシュ通知では Web Push プロトコルを利用する
      • まずクライアントサイドで、ユーザの許可、サブスクライブ、サーバ送信
      • サーバサイドで Web Push プロトコルを利用してメッセージ送信
        • プッシュサービスがメッセージ配信を行い、中身を見ることはできない
      • クライアントの Service Worker によってイベントが発行され、メッセージ処理を行うことができる
      • メッセージはパブリックキーとプライベートキーを使って暗号化される
    • ユーザ許可を得る際に、二重の仕組みにすると許可されやすい
      • 設定画面やアプリケーションのダイアログとして “許可する” を表示
        • その後にブラウザ側の許可を出す
      • さらに通知される情報を設定できるとよい
    • Service Worker のイベントが発行した時、適切なアイコンやボタン、画像などを設置するとよい
      • アクションへの設定もできるので、ユーザ体験を考えて実施していく

セッション 4: Secure Experiences

  • HTTPS は Identity, Confidentiality, Integrity のため
    • サイトは誰なのか保証する
    • クライアント / サーバ の機密性
    • 改ざん防止
  • しかし導入にあたって Unimportant, Perf, Cost, Maintenance の問題がある

セッション 5: Tooling - Lighthouse and Beyond

  • Chrome DevTools を開いたときの Audit というタブが Lighthouse と呼ばれている
  • 例として React を使った SPA を PWA 対応をしていってみる
    • Lighthouse を実行した結果をベースラインとして、施策をしていき点数の上下を見ていく
    • 実行した際にチェックリストがでるので、これにしがたって順番に対応をしていくとよい
    • iOS や Safari の対応のために、サーバサイドレンダリングを行う
      • Lighthouse でもそれによってパフォーマンス、モバイル対応の評価が向上する
    • PWA に向けてキャッシュをする際、App Shell + Dynamic Content という考え方を組むとよい
      • App Shell モデル  |  Web  |  Google Developers
      • アプリケーションのガワ、全体感を作る部分が App Shell で、これをキャッシュする
      • ネットワークが有効なら、コンテンツを更新していく
        • 更新したコンテンツをキャッシュするとファーストビューが素早く見れる
    • WebApp Manifest を入れることで “ホーム画面に追加” ができるようになるが、これは DevTools で確認できる
      • DevTools 内にリンクがあり、これを推すと “ホームに追加” サジェストを出すことができる
  • このようにして PWA 対応を進めていくとよい

コードラボ

  • コードラボに必要なソース、説明などはここからいける
  • この時間は、ここまで話を見て、聞いて、学んできたことを各自で自由にお試しください、という時間
    • せっかく作っている人たちがいるので、相談・議論したりするのが推奨されている
      • 通訳さんもいるのでドシドシ聞いていこう!
    • とにかく自由な時間
  • 聞こえた話
    • PWA に SPA は仕様としても個人的には必須ではない
      • SPA は敷居が高い
      • SPA にせずともリソースをキャッシュすればスピードアップすることは十分に可能
    • Cache Storage が更新されないバグがある
      • 6-12 週間くらいで FIX されていく動きあり
    • 1 サイトに複数の Service Worker がいることも可能
      • ただし管理上の危険が伴う、ワーカーを分ける必要はないのでは?
  • 作業メモ
    • まずは “はじめてのプログレッシブウェブアプリ” をやってみる
    • 時間があれば、ごみばこいんのトップページを PWA 対応してみたい
      • gomiba.co.in ではなく、ローカル環境で、ちょっとやってみる程度
    • importScripts という関数はワーカー内で利用できるグローバルなもの
    • そもそも Service Worker は Web Worker のうちの 1 つ
    • リセットするときは Clear Storage + タブを閉じる + タブを再度開く ことが大事そう
      • Service Worker のコードがいつアップグレードされるのかわかっていない感
    • コードラボの資料の手順が丁寧なのでそれを見るとよい
      • とりあえずやってみたい!というひとはググって “やってみたったwwww” みたいな記事は見なくていい
      • ただしいきなり色々な単語がでてきて、そこへの説明はあまりないので、辞書を 1 つずつ倒していく
    • ごみばこいんの PWA 対応に取り掛かる
      • workbox をオススメしていたので、これを使ってみる
        • とりあえずビルドなしでも利用はできるが CLI ツールとしての利用になるので Node.js は必要
        • workbox.prod.js が読み込めれば利用できるので、そのソースだけ持ってくればよい
          • CDN は無さそう? → Q&A
        • 外部リソース、CDN のキャッシュはできない?
          • workbox に生成してもらったコードは静的ファイルのみのキャッシュ
          • そのコードをそのまま使う分には CDN のキャッシュはできない
      • PWA 対応がちゃんと動くか確認するのに実機を使うようにするとちょっと面倒
        • USB つないで実機の Service Worker をリセットしたりする必要がある
        • デスクトップでも “ホームに追加” 的な動きはあるので、これを試して良ければ実機確認が良さそう
          • デスクトップにショートカットが置かれる
      • アプリっぽい見た目になるまではサクっとできる
        • Webview を埋め込む、いわゆるガワネイティブみたいなものは PWA 対応をすることで不要になりそう
        • ただし未経験がゆえにぼちぼちとハマるところはあるので、コレで実際に動かしているプロダクトに入れるのは慎重にやりたい

実際にできたものがこれ。

WebApp Manifest を入れ、 Service Worker によるオフラインサポートをしたら、ホームに追加が出来るようになり、ごみばこいんのトップページをアプリのように表示することができた。アイコンを適当に引き伸ばしたら白い余白が出来てしまったが…。

セッション 6: AMP

  • PWA における早くしよう!はキャッシュをして 2 回目から早くしよう!
    • AMP はそもそも最初から早くしよう!
  • モバイルの平均読み込み時間は 19 秒。 77% が 10 秒以上かかっている
    • 初回読み込みリクエストが 214 もある
    • 半分は広告
    • 早くしようとすると UX がよいが マネタイズが難しい
  • AMP のモチベーション
    • 遅い読み込み、スクロールできない、読み込みにおけるレイアウト崩れを解消する
  • AMP HTML + AMP JS + AMP Cache
    • AMP HTML
      • 広告はサポートしているアドネットのみ、認められないものは設置できない
      • 画像などのリソースなども指定された方法のみ有効
    • AMP JS
      • 遅延読み込みやサイズ指定を自動、または制約によって行う
    • AMP Cache
      • 正しく AMP 対応されていればクローラがやってきてキャッシュする
      • CDN 的なもので、各地にエッジサーバがあり、通信路も最適化される
        • エッジサーバはクローズではあるが、 Web の世界中で最適な対応になるまで時間かかるので、先に作った
        • 元ページはどうであれエッジサーバは HTTP/2 で通信できる
  • AMP + PWA
    • amp-install-serviceworker を利用すると Service Worker の登録ができる
    • AMP から遷移先のページをキャッシュすることができるので、常に早い Web 体験をすることができる
    • 大きく 3 つの方法が取れる
      • AMP as PWA
        • AMP そのものを PWA で扱う
        • AMP ページで Service Worker を登録し、遷移先に必要な AppShell をキャッシュする
        • 例) Learn AMP by Example
      • AMP to PWA
        • AMP から PWA にうまく遷移する
        • 動的なサイトなら有効、ただし手間がかかる
      • AMP in PWA
        • PWA に AMP を埋め込む
          • AMP HTML を持っておく
          • AMP ページにはそれをそのまま出す
          • PWA ページにはコンテンツとして埋め込む
        • iframe では遅いので Shadow DOM で解決する必要がある

クロージング

  • PWA が伝わったと思う
    • プログレッシブエンハンスメントなので、段階的に、できるところから、ユーザエクスペリエンスのために対応していこう
  • 紹介できなかったところで、面白いものがまだまだある
    • Credential Management API
    • Web VR
    • Web Assembly
    • Silent Push

Q&A

  • Q) 新フローに対して慣れが必要だけどチェックアウトのフロー簡略化も対象か
    • Payment Request API の中で住所や支払い情報を入れる
      • 今まで複数のページに渡ってやっていたのがまとまる
    • サイトによって色々なパターンがあるので、一概にどうこうする、とはいえない
      • 個別に相談・提案します
  • Q) “ホーム画面に追加” を追加モジュールでできるか
    • 今後でやっていきたい
    • 議論としては右往左往しているような状況
  • Q) PWA は何を指しているのか
    • 答えはマーケティング用語であり、バズワード
    • 優れたユーザ体験を高速でエンゲージメントがあって…。これがPWAだ!というものはない
      • Lighthouse がチェックする指標が一番近い
  • Q) 通知の登録、削除、登録のフローは可能か
    • パーミッションを外した場合、ask、になっているなら許可を求める。
      • ブロックなら終了。何もできない
    • PWA.locks にはよいリスティングはある、誰でも登録できるが微妙なものもある
  • Q) モバイルのペイメント CVR の数字はどこのもの?
    • 社内の調査 PDF
    • ドイツ銀行の有料のもの
  • Q) CVR はフォームが悪いか、Web 体験が悪いか
    • フォームの途中でドロップすることが多いようにミメル
  • Q) Server Push はキャッシュ関係なく送るか?
    • その通り
    • Service Worker からはどうするか知ることはない
      • クッキーを使ってどういうキャッシュを持っているか確認する、という対策はできる
    • いい案があればコミュニティに挙げてみて
  • Q) Push 通知の許可に 2 度目のチャンスはない。ホームに追加も同じ?
    • 14 日後まででない。無視ではなくしない、にした場合 3 ヶ月後まででない
    • PWA コア機能を作ってるチームが UX やユーザリサーチをしているので変わる可能性はある
  • Q) PWA はアンインストールがあるか、キャッシュは誰が度のタイミングで責任を持つか
    • Android 、他のアプリと同じようにアンインストールすればクリアする、ストレージのクリアも同じ
    • ユーザとしてはサービスワーカーを処理するのはむずかしい
    • clear-site-data というヘッダーがあって、シグナルも増えている
    • quota を使って容量制限を設ける、ということも可能
  • Q) Service Woker スクリプトを CDN に置けるか?
    • できるが、やらないほうがいい
    • 重要なコンポーネントになるので、常に最新のバージョンを見れるようにしたほうがいい
      • ServiceWorker自体がキャッシュされるとこまっちゃう
    • CDN の必要性が薄まる
      • 必要なときにサーバにアクセスする。クライアントにキャッシュできる
  • Q) CDN のキャッシュはできるか?
    • クロスオリジンはキャッシュできる、がうまくいかないかも
    • Service Worker から fetch してキャッシュすることはできるが inspect できない
  • Q) Payment Request API でポイントから一部支払うことはできるか
    • マイナスを入れることでできる
    • UI の調整は今後も考えてない、声が多ければ仕様に増える可能性がある
  • Q) Service Worker がキャッシュするとリクエストは出るか?
    • リクエストが出る
    • AMP by Example を見てみるとよい
  • Q) 広告に対して行っているサポート
    • 遅延ロードがあるくらいで特にない
    • AMP フォーマットで広告を書くと、広告が AMP になるので CVR 問題は少ないはず
    • PWA については普通のページになるので特にない
    • Web だからユーザがオンラインで振る舞うので問題ない
      • オフラインならネイティブアプリの真似をすればいい
  • Q) しばらく Web to App の流れだったが App to Webが来るか?
    • Web とネイティブが近づいている。相互に機能が出入りして融合しつつある
    • ニュース、プッシュ通知が有効なので新規なら PWA でいいのでは?いまのアプリが順調ならアプリでもいい
      • PWA だからうまくいく!というわけではない、ユーザリサーチしていこう
  • Q) PWA に向いているライブラリ
    • 普通の Web なので、自由に、使いやすいものを選ぶとおい
  • Q) mBasS などあるが Push 通知をどうするか
    • 何かを推奨するわけでなく、標準のプロトコルを使うとよい
  • Q) ブラウザキャッシュと Service Worker キャッシュの違い
    • Service Worker キャッシュは明示的に今ここに欲しい、ができる
    • ブラウザキャッシュは来たらキャッシュするよ、という程度
  • Q) push 通知許可ダイアログ表示について、intervention でブロックするなどは検討してる?
    • (話を聞いてなくてメモできなかった。。。)
  • Q) クライアントに PWA を提案する一言キーワード
    • ベストなエクスペリエンスを提供します
    • ユーザを考えるべき
    • ネイティブアプリみたいな Web
    • それがベストなマーケティング
  • Q) PWA の分析は GA で可能か
    • はい、ガイドもあるので参考にしてね
    • workbox の中に analytics もあるので、オフライン中の動作をトラックして次にオンラインのときに送れる
  • Q) PWA のネイティブの今後。ネイティブ不要?
    • 常両方必要、どちらがいてよい、ということはない
    • Google でも仲良くやっている
    • よい体験のためにどちらの利点も考えていくべき
  • Q) ネイティブアプリと比べたバッテリー消費
    • とくにない
    • ネットワークアクティビティをあまり行わないようにしたほうがバッテリーが落ち着く
      • Service Worker でキャッシュするとリクエストがへってよい
    • 動画など GPU アクセラレーションをするなどなるとネイティブがつよい
  • Q) Service Worker v2 の中で面白いものは?
    • バックグラウンドシンク
      • オフライン中に起こったアクションをオンラインになったら送出できる
    • サイレントプッシュ
    • ストリーム
  • Q) Service Worker はアプリ開発者向け?ライブラリにオフライン機能を追加するようなユースケースは考えられているか?
    • ライブラリが持っているサービスワーカーのコードとマージする必要がある
    • 基本的には 1 つのサイトに 1 つのサービスワーカー
      • インポートや複数走らせるが議論されている
      • そのあたりのベストプラクティスが特にない、よいエコシステム成熟してない
  • Q) iOS は使えない機能があると思うが PWA でどうしたらよいか
    • まずよいエクスペリエンスをデスクトップ・モバイルで作って、よりよくしていくだけ
      • iOS だからやらない、とかっていう話ではない
    • フィーチャーがサポートされたときに有効になっていく
      • プログレッシブエンハンスメントしていく
  • Q) 他のベンダーとの連携アイオニックとか
    • Polymer でも一緒にやっていてので一緒に進めている
    • ブラウザベンダとも Chrome サミットでパネルディスカッションやセッションを進めている
      • Google だけでなく全体で進めている

そのほかの情報とか

参加者に関しては、ゲーム系会社の方がいたり、 SEO や広告を取り扱うメディア系の方がいたり、エンジニアだったり Web 担当者だったり、いやもう PWA やってて~な人もいたようだった。何ができてどう活かしていけるのか、 アプリと PWA 、 AMP と PWA 、これからの Web 、興味関心が高いように思えた。

今回のイベントのスライドはここにある。(ルートが Google Developer Groups になっているので公開してよいものだろう)

Twitter のまとめはここ

ほかの参加したよ!ブログはここ(リストの更新予定はない)

おわりに

今回のイベントを通して PWA について深まったが、 Google の人たちは終始、 Progressive Enhancement だ、と言っていたのが印象的だった。 PWA それ自体は別に Web をアプリ化するような技術そのものもでもなく、プッシュ通知を送れるような技術でもない。複数の Web Standard な API を組み合わせ、モバイルにおけるユーザ体験をより良くしていこう、というものだと認識した。

コードラボの時間で Push 通知や Payment Request API も試してみたかったが、時間が足りなかったのでそのうちやってみたい。デファクトスタンダードみたいなものがない、 W3C で通った API をやることになるだろうので、実プロダクトに入れづらいところだが、そこはプログレッシブにやれたらいいな。

無料で、ランチもついて、きれいな会場で、丸一日めっちゃ楽しかった。 Google さんありがとうございました!

今度はチームでISUCONに参戦したものの予選敗退でした

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

詳しくはこちら > ISUCON6 開催&日程決定! #isucon : ISUCON公式Blog

今回はぼっちーむを回避して、会社の人と合わせて3人(+おまけ)でやっていました。
5、6人いれば2チームで競う感じの参戦方法もありだったのですが、ちょっと都合が合わず。。なので1チームでした。

今回は初のチーム参戦ということもあって、意外と勝手がわからないことが多く、苦戦しました。

結果としては予選敗退でした・・・次はもうちょっと上位へ・・・!

ちなみに前回の参加レポはこちら > ISUCON5 オンライン予選に参加していました

やったことをまとめていきますねー

==============================

■初Azure!!

初というとちょっと語弊がありますが、触ったことがあるのはかなり昔のAzureなので初Azureでもいいでしょう。
当時と比べてかなり進化したUIになっていて、とても使いやすかったです。
ガッツリインフラマンじゃないのでなんとも言えないところもありますが、まあまあいい感じなのではないでしょうか。

ちょっぴり残念ポイントとしては、無料枠をなぜか使いきっており(もしかして:MSのAPI的なやつで登録した?)、
仕方なく従量課金になったところでしょうか。数百円くらいの請求が来ると思います。まあまあ。

■とりあえずシステムをPHPに切り替えた

まっさきにPHPへ切り替えました。
切り替えたとき、nginxのMIME読み込みがなかったためか、Chromeで正しく画面が表示されておらず、この解決にも時間がかかってしまいました。
ただまあ、静的ファイルはちゃんと出ていたのでベンチは通っていましたw

3000点くらいですかね。

ちなみにPHP7が入っていました。
5.6.xxxだったら7入れてようと思っていたのですが、さすがにそこでの利点はないようです;;

■とりあえずgit pullで更新できるようにした

とりあえず社内のリポジトリにぶっこんで、git pullしてコードを更新できるようにしました。
capistranoなど仕込んでもよかったのですが、おてがるに、最速に、安定に。

■isudaの文字列長を別カラムに保存してインデックスを張った

チームメイトがなんだこれはーーーって言いながら直していました。
これでスコアが6000点くらいでしたかね。

他にもインデックスがなさそうなところにもりもり張ってこのくらいだったかと。

■isutar→isudaにHTTP通信するのをやめた

ぼくがなんだこれはーーーーって言いながら書き直していました。
具体的にはDBも同居しているんだからそのまま直にSELECT掛けにいけばいいんじゃないかなあ、という実装に変更しました。
同居ではなく、サーバ台数が多いなら分けたほうが縦横に広げやすいと思うので、そっちのほうがいいですよねきっと。

この同タイミングで、nginxも1サーバだけにするように変更しました。

ちょこちょこバグが発生して時間がとられていくものの、無事完了してスコアが15000点くらいです。

■isuda→isutarにHTTP通信するのをやめた

逆も同じつくりになっていたので、こちらも同様にしてやめました。
また同タイミングで、nginxのfastcgicacheを入れました。

スコアが23000点ほど。

ただfastcgicacheはうまく設定できていなかったようで、スコアへの要因はあまりなかったようです。

■Redisキャッシュへ

ここまでですでにhtmlifyメソッドがヤバソウ、スターをキャッシュとかできないかなあ、といった話題が出ていました。
こつこつ裏で実装を進めており、夕方ころに完成、マージしていきます。

ここでスコアが25000点ほど。
うーん、キャッシュの作り方が悪かったのか、ちょっと微妙な結果でした。

■時間切れ。
といったあたりで終了の時間になりました。

2万点台に乗ったとき、ベンチのランキング上位に入ったので、このまま順調に対応していければ本選出場も行けそうな予感がチーム内にあったのですが、、
バグが出まくったりコンフリクトしたりと、課題が残る結果に終わってしまいました。

==============================

時系列的にはこんなところです。

やり残した部分や気になる部分を挙げると…

・htmlifyをちゃんと見れていなかった
 ここ改善する余地めっちゃありそう。

・スパムチェックも何かできそう
 バイナリがWebサーバになっていて、そこそこパフォーマンス高そうでしたが、HTTP通信はやっぱりコストが高いと思います。キャッシュできるといいなあ、とか。
 バイナリになっていて隠されていましたが、例えばベンチをガンガン回してチェックした内容をRedisとかnginxのリバースプロキシなどにとりあえず入れておくとか…。
 気合い入れてリバースエンジニアリング的なこととか…;;
 最初からちょっと様子をみていたのですが、パフォーマンス高そう、がわかったときに一気に後回しにしていました(この判断はただしい気がする)

・キャッシュをちゃんと作る
 もうちょっと気合い入れて作ったらもうちょっとスコア伸びてくれそう
 というか作ったキャッシュが当たっているか見てないのも問題→当たってないならそのキャッシュは作ってもダメなのではーーー

・最初にスコア計算の方法をちゃんと見ておくべき
 POST遅延がかなり減点されるので、そこで一部足を引っ張られていた可能性が高そう

・初期化処理生かせてない
 前回参加したISUCONでは初期化処理もそこそこコードを書いていたのですが、今回はまったく書いていませんでした。
 キャッシュを作ったり、下準備をしたりなどいろいろできるはず。。。

・個々人で開発できる環境整備してあげよう
 ケチって1サーバで動作確認しまくっていたのですが効率が悪すぎて。。。
 ローカルでも動くようにDBコピーするとかいろいろ手は打てたはず

・リブート検証してないよ
 結果としてはしなくてもよかった点数になりましたが、ここもちゃんと見てあげないと、でした。
 ルールにも再起動して大丈夫なこと、とかって書いてありましたね。

・git pullしてたけどコンフリクトしてやばい感じになってた
 雑にフリースタイルにコミット!プッシュ!マージ!していましたが、ぶつかって直すと壊れて、が後半に頻発してヤバイ感じになっていました。
 ある程度のルールを事前に決めるなりすり合わせするべきですねー

・個々人の役割があまり明確でなかった
 ある人はこれをやり、ある人も同じものをやり、が多くは無いですが少し発生していました。
 それぞれ得意スキルが異なっているはず(あまり詳しい得意スキルを把握していなかった)なので、最高のパフォーマンスを出せる場所へ誘導してもりもりやってもらう感じに~~~
 うぐぐぐ。。

ぐぬぬ・・・・課題が山盛りじゃ・・・

【U-NEXT ☓ Oisix 】データ分析と機械学習 事例発表」に参加してきた

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

「【U-NEXT ☓ Oisix 】データ分析と機械学習 事例発表」に参加してきたので、そのレポートです。

会場

五反田にあるOisixのオフィスで行われました。ここは駅に近く、アクセス良好でした。
オフィス内は綺麗で、ところどころにOisixらしさ、農産物のイラストがありました。

懇親会で出していただいた、トマトとブドウはとてもおいしかったです。これはOisixで買えるやつなのだろうか…!

Oisix事例:顧客属性推定とレコメンド

自己紹介

喋っていた方は、がっつりエンジニアだったというわけではなく、個人的にシステムトレードに興味があり、そこからOisixへ入社してデータ分析を始めたそうです。
現在は、パーソナライズやレコメンドを進めているそうです。

パーソナライズプロジェクト

Oisixとしては、お客様1人1人によりそったサービスや商品を提供したいので、様々な状況を理解して提案していくようなシステムにしたいと話していました。

Oisixでは定期ボックスという週に1度の頻度で定期的に購入できるものがあり、この中にデフォルトで商品が入っている状態になっています。定められた期日までは商品が変更でき、欲しいもの不要なものを入れ替えられます。

この定期ボックスにデフォルトでいれる商品が、ほとんどの人が同じモノになっていたので、パーソナライズして1人1人違うものを提案していく、というのが具体的なもののようです。

レコメンドのやり方

レコメンドは「顧客のクラスタ分析」と「商品のバスケット分析」の二段階で行っているそうです。単にバスケット分析をしただけでは、似たような商品を提示するに止まってしまいます。顧客のクラスタ分析をしてからバスケット分析をすることで、より精度を上げるようにしていました。

クラスタ分析としてクラスタリングとクラス分類があります。クラスタリングは教師なし学習で、全体をなんとなく眺めてざっくり囲むようなアルゴリズムが主なものです。クラス分類は教師あり学習で、例えば子供がいるかいないかを予測するものになります。

今回はクラス分類を利用して、子供のありなし、料理のするしないを分類し、2x2の4パターンに分けたそうです。
社内にもともとある知見や仮説が、この特徴だったので選択したそうです。

バスケット分析は「リフト値」と呼ばれるものを計算して高い順に出すものです。リフト値は信頼度と呼ばれる値と、支持度と呼ばれる値から算出されます。具体的には「ポテトフライを買った人はクラッカーを買っている傾向がある」といったものになります。

レコメンドのための基盤

OisixではメインDBとしてオラクルが使われているそうです。ここには顧客や商品のデータ、受注に関するデータが入っています。また、MySQLも合わせて利用されており、こちらには購買履歴や売り場に反映するための商品データが入っています。

データ分析用としては、トレジャーデータを利用しており、データの集約や加工をこちらで行っているようでした。

具体的なレコメンドへの流れ

データ整備

何をするにもまずはデータを整備する必要があります。

Oisixではトレジャーデータに集めて、そのデータを基に分析をしていました。
ここでの失敗談として、DBデータが更新されていなかったり、意味のないものが登録されていたりなどしたこともあり、手戻りが発生したそうです。

きちんと分析できるための準備も大事ですね。

アンケートの収集

ユーザのクラスタ分析に向けて、ユーザーアンケートによって教師データを集めたそうです。例えば「食の好みは」「料理をしますか」などを聞くことで、

ただ、アンケートの内容を詰め切れていなかった部分もあり解答と実態に差が出てしまうこともあったようです。自社サービスの特徴も考えてアンケートを作ろう、ということを言っていました。

外れ値データの除外

分類することが難しいので、「ほぼ買われている」「まったく買われていない」というものを除外したそうです。
具体的には購買数量をk-meansにかけて分けていったと話していました。

分類モデル

Y=セグメントに属するか、X=過去6ヵ月の商品ごとの購買数、1200人のデータセットとして、ロジスティック回帰によって、モデルを作ったそうです。
しかし、学習するたびに異なる結果になってしまったそうです。原因としては、説明変数が多すぎたと話しています。一般的には説明変数の5倍にあたる
データセットを準備すると良いです。

今回はデータセットの準備も出来ないため、似たような商品をまとめたり、削ったりなどすることで、説明変数の数を減らしていき、モデルが動くようにしていました。

分類モデルの適応

出来たモデルを顧客全体にあてて前述の4種類に分類したそうです。具体的には二回に分けて実施して、子供のありなし→料理のするしない といったようです。
テクニカルな話ですが、標準化の手法がやや間違っており、平均→標準偏差の重み設定を再適用してしまった、と話していました。

バスケット分析

顧客の分類が出来たので、それぞれに対してバスケット分析をしていきます。
実例の紹介もあり、例えば「シャルドネ→ソービニョンブラン」といった具合に見せていただきました。

やはり問題もあり、似たようなカテゴリが出てしまったり、毎週1人1人に様々な商品を提案することが困難だということがわかったそうです。
機械学習が万能ではない、ということを認識する機会になったと話していました。

商品の提示

実験的にできた結果ですが、実際にそのレコメンド効果を試すために、サイトの様々なところに出してABテストをしていったそうです。
同じロジックで出しても売り上げが変わり、売り場ごとに特徴の違いというのがあったようです。

今後について

顧客属性と商品属性をかけ合わせたり、地域や季節といった要因を組み合わせたり、もっともっと試したいことや、応用した別機能を考えていきたいと話していました。

U-NEXT事例:レコメンドシステムのこれまでとこれから

自己紹介

研究開発として、二人で進めており、どちらもエンジニアではないが理系出身ということでやっていたそうです。

U-NEXTのレコメンドシステム

U-NEXTは動画、電子書籍の配信サービスです。
12万本の映像、20万冊の電子書籍と多くのものがあり、とても端から端までは見切れません。
そこで、キュレーションをする仕組みを作りましたが、それも多くなってきてしまったので、リニューアルに合わせてレコメンドシステムを乗せて、より満足度を上げようという試みのようです。

レコメンドの要件としては、1人1人に違うものを、一日一回の更新で、でもパフォーマンスは損なわず、そして準備期間も短く…、となかなか険しいものだったそうです。

レコメンドシステムとしてやったこと

まずはデータを放り込む場所、ロジックを用意し、Oisixと同じくトレジャーデータに入れていったそうです。
そして分析やシステム構築というフェーズに入るのですが、社外と提携して進めるという話もありつつも、社内で小さく初めてトライアンドエラーでぐるぐる回していこうとしていました。
その裏ではレコメンドの評価を正しくできるように、目標が達成しているか見えるように判断できる仕組み作りも行ったそうです。

結果としては、視聴時間が27.5%アップし、「気持ちの良いレコメンドをしてくれる」といった評価も得られているそうです。

レコメンドの実践における課題

作ったことのある人がいない、作り方がわからない

「推薦システムのアルゴリズム」を読み、社内で勉強して、試行錯誤していった。トレジャーデータを利用することで、小さく始めるということも叶ったと話しています。

レコメンドの方法

レコメンドの方法としては大きく、協調フィルタリングか内容ベースの分析があります。
U-NEXTではよりよいレコメンドを求めてどちらも試していったそうです。

協調フィルタリングとしては、
評点の予測がよくありますが、U-NEXTには評点データがあまりなく、主に暗黙的データと呼ばれるログ、
つまり「動画再生ログ」「購入ログ」「クリック・遷移ログ」といったものをうまく利用することで、協調フィルタリングを実現していました。

協調フィルタリングにはユーザベースとアイテムべースがありますが、
ユーザベースは登録時の属性を利用するなどしたものの、新規ユーザーや視聴数の少ないユーザにはうまく働かず、難しいとの見方でした。
一方アイテムベースでは、再生ログを基に分析をし、結果として視聴時間がアップして成功と話していました。

内容ベースは、内部的に持っているタグカテゴリの分類や、そのベクトル化、そしてクラスタリングといったものを組み合わせて進めたようです。
具体的には、ApacheSparkとkuromoji.js、t-SNE、Scala、自作の可視化ツールを利用して、実施→正しさの人力検証をしていたとのことです。
しかし、協調フィルタリングに比べると、あまり良い結果にはならなかったそうです。
ただコールドスタート問題の解決(分析をするまで時間がかかる)や、セレンディビティの演出(出くわした!というもの)といった部分に一定の効果が見られるとのことで、
今後も進めていきたいと話しています。

また、レコメンドはエンジニアだけのものではなく、マーケティングやプロモーション担当の人もいじりたいとのことで、
GUIアプリケーションを提供して、設定変更やレコメンド適用についてをやりやすくしているとのことです。

他社との連携

atilikaという会社と協力して進めており、機械学習に関する流れの加速や、atilikaの持っている知見や発想、技術を利用していくという話です。
最先端のアルゴリズムや技術の適用など、自社だけで追いつけない部分をお願いしたり、データ分析という部分についてコンサルティングしてもらっているそうです。

まとめ

参加表明が100人を超えていたり、質疑応答やその後の懇親会も活発な発言があったり、様々な業界の様々な人がこの分野に関心があるということを実感しました。

個人的にも、機械学習を少しやってみている段階で、これでいいのかどうか、どうやって進めていこうか、といった部分を悩んでいるところだったので、
こういった事例を聞けることで不安解消につながって、非常に良い会だったと思います。

すごいシステム、完璧そうなシステムといったもの用意しないと、運用できないのではと思っていた節もあったのですが、
実際に事例を聞いてみると、ぼくの学習している範囲でも実現できそうなことばかりで、このくらいでもいいのねーと思いました。

すごいシステムを目指すというのも大事だと思いますが、ひとまずは今の自分のレベルくらいで、いろいろと活用していきたいと思います。

Electronで社内ツールを作った話をしました / #JSオジサン #6 2日目

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

JSオジサン#6 2日目 で喋っていました。


こんにちは。ごみばこです。

最近はLaravelオジサン…ですかね。たーまーにJSオジサンしてます。
…いやいや、年齢的にはまだまだオジサンじゃなくて、お兄さんですよ。

JSオジサン#6 2日目

満員御礼!! JSオジサン #6 「まさかの3日間連続開催だよ!」2日目
https://atnd.org/events/71990

今回のJSオジサンも21cafeさんでの開催です。
いつもありがとうございます!そこそこキャパが広くて、スライドも見やすくて、立地もよし。快適環境です!

さて、今回のJSオジサンでは、言ってしまえば勉強会駆動開発のような「せっかくだから」精神で登壇者側に参戦しました。

せっかくチャンスがあるから。
せっかくElectronやってみたかったから。

せっかくだから作ってみた系の話をしました。

Electronで社内ツールを作ったお話 from sters9

すこし解説をいれます。

ハイテンションキャラ

LT5分だし、Electron超感動したし、実際ほんとすごいから、
ハイテンションキャラで「サイコー感」を出していこう。

という思いのもとで、こういうスライドに仕上げました。
普段からこんなじゃないですよ!!!!!

偶然にも、ハイテンションノリが他の人と被っておらず、「Electron」という流行ネタも被らず、
いい感じに印象づけはできたのかなと思っていたりします。

社内ツール1

「なんとかかんとかーベイ」ってサービスの管理画面が、Flash製でもっさりでつらい。
というところから来ています。

当初はブックマークレット超がんばっていたのですが、人によっては動く動かないとかで、
こまめな対応や更新が面倒になってしまったので、いっそElectronでつくったろか、と。

いうのは実は後付けで、作ったのは一年前?とか、かなり前になります。
当時はnode-webkitを使って作ったのですが、「まあ、だいたいイメージ一緒だし…」というノリで入れました。

このときnode-webkitを触って、なんだかいい感じ!なんだけどなんだかなあ…
という気持ちがあったので、ここにきてElectronいい感じ!!という話を聞いてずっとやりたいと思っていたのでベストタイミングですね。

社内ツール2

Confuluenceのクライアントアプリです。

Qiitaで見かける、チャットワーククライアントアプリと同じように、
「webviewタグ」を使って、いわゆるガワネイティブと呼ばれる仕上がりにしています。

APIなんかも提供されているので、Confuluence内の色んなデータをばっさばっさ取れて、フルに画面を構築することも可能でしょう。ただGET系のリクエストは、JIRAやBitbucketなど、別のAtlassian製品を使ってると、そっちの情報が降ってきたり、 混在していたりすることもある(主にActivityStream)ので、扱いには気を付けないといけないこともあるかと思います。
オンプレの場合はちょっとわからないです…。ヘーシャはクラウドの方を利用しているので…。

そして、もしかしたら「最強のConfuluenceクライアント戦争」の到来…!?
参考:最強のTwitterクライアント戦争情報( http://r7kamura.hatenablog.com/entry/2015/08/25/154846


さてさてガワネイティブをしたとき、イケてない中身とかほしい機能を付けるためにもあれこれいじくりたくなりますよね?

ただ、Electronでは、Electronアプリを動かすプロセス、ウィンドウのプロセス、webviewのプロセス、といった具合に、それぞれの画面(?)は簡単にはつながっていないのです。
そんなとき、IPCと呼ばれるプロセス間通信の機能を使うことで…

うーん、長くなりそう…。このあとはまたどこかで書きます。


ツール2のConfuluenceクライアントアプリについては、、いかんせん急ごしらえな部分がおおく、正直見せられるようなものではない残念施構成なのでうーん。

そのうち、またElectronの話を書きます。
感動したので熱はしばらく冷めないことでしょう。

それではまたー(*'ω'*)


ア!1日目も参加者だったので、また参加レポあげます!!!

PHPカンファレンス2015へ参加していました

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

こんにちは。ごみばこです。

先日行われていた、PHPカンファレンス2015へ当日スタッフとして参加していました。

http://phpcon.php.gr.jp/2015/

参加した背景

これでも私はぺちぱーなのです。
もとい、最近はnodejsもrubyもunity3dもさっぱりで、ずっとPHPおじさん…。

ということで、PHP7とかHHVMとか色々おもしろそうですよ!とキャッチしており、
いま行くしかねえ!

と思ったときに、ちょうど当日スタッフの募集が行われていたので、PHPお世話になってるし面白そうだしやってみよう!と思いたち、当日スタッフに名乗りあげました。

「当日スタッフ」

当日スタッフの応募とかしてるけど実際なにしとんねんとやる前は思っていたので、きっと他の誰かも同じだと思い、やったことでも書いておきましょう。

  • スタッフTシャツを着る
  • 配布物のまとめ
  • 会場設営(机を出したり椅子を出したり)
  • 受付(配布物の手渡し)
  • セッションの案内、ルームの様子見
  • 片づけ(机しまって椅子しまって、ゴミ捨てして、)

基調講演も含めて、全部ではないですが、多くのセッションを見れたのは非常にうれしいです。スタッフとしては、セッションに集中しすぎるのはNGだと思うのですが…、、そこはちょっと反省点、、

悪かったポイントもいくつか挙げておくと、人が多いからいっか、となってしまったり。受付はもうちょっとなんとかできたなーと思います。スポンサーこっち、スピーカーこっち、とA4に書くだけでもだいぶ変わったでしょう。
あ!受付については、アクセス過多になっていたので、横にインスタンス立ち上げたらいい感じに捌けていったので、そこは自分でもよくやったと思います!

また、今までがわからないのですが、当日スタッフ向けの話が本当に当日しかなく、どこまでが当日スタッフの範疇なのか、誰に回せばいいのか、等々、多くはないものの、ちょこちょこどうしようかなポイントがあったのも事実です。みなさん日々のお仕事にプラスなので、そりゃ忙しく。前日までバタバタしていたようですし仕方ないですね。。

あとはちょっとどうなのかわからないのですが、内輪盛り上がりみたいなやつはやっぱりどこでも。僕自身はまあいいんじゃないっスか、というくらいですが、知り合いだけでウェーイしてるのは、新規参入が難しそうだなあ、とよく思います。

セッションへの感想とか

PHP7期待しかねえ…!おしまい。

・・・ちょっと嘘が入ってますね。
完全に個人的な話ですが、PHP7については期待しかないものの、お仕事ですぐにつかえなさそうな気がしていてちょっと残念です…。
めっちゃパフォーマンス上がっているようですし新機能もあるし、使いたいよなあ。
色々ちょうどいいタイミングだと思うんですけどねえ…(意味深)

他は、徳丸先生のインジェクション事例と、Drupal8とSkyWayの裏側を見ていました。

インジェクション事例は怖いっすねー。デモされるとよくわからんけどID/PW抜かれてるやべー!みたいな気持ちが湧いてきて、ヤバさ実感という感じです。
や、よくわからないわけじゃないですよ、これでも一応セキュリティを勉強していた身ですし、Web世界に身を置いているので…。今後はマイナンバー云々などもありますし、スマホ盛り上がってますし、がんばりましょう、というところで。

Drupal8は…。うん、どうだろう。よさそうだけど使うタイミングないかなあ…という感じです。。
CTFとかで出てくるとちょっとだけ面白いかもしれない(適当)

SkyWayの件は、SkyWayの話なのですが、どのような開発の歴史を歩んできたかという話でした。
WebRTCが云々SkyWayが云々ではなく、普通に普通にアプリケーションで利用しているミドルウェア的なものやデプロイ回り、それらツール構成の話、人員の話で、かなり興味深かったです。
APIが用意されていたり、安いとか色々いい感じで、Cloudn結構よさそうだなあという気持ちも出てきました。どこか時間とお金の余裕があるときにでもお試しでアプリ乗っけてみたいですね。

「PHPカンファレンス」

昨年は参加していなかった(はず)のでどんな雰囲気かわからなかったのですが、予想以上にたっぷりPHPだったと思います。近年のWeb界隈のいろんな話が飛び交うと思っていたのですが、見たセッションのせいか、そんなに多くはなかったと感じます。
それでいて、PHPの幅広い話題が出てきたり、LTや懇親会での深い話や、はたまた別方面に飛んでいくような話もおおく、非常に満足しています。

そんなセッションだけでなく、スタッフの皆さんだったり参加者だったりのさまざまな方と、PHPだけじゃなくて運用回りとか他の技術とかとか、なお話しをできたこともとてもよかったです。

素晴らしい出会いを用意してくれたカンファレンスに、PHPユーザ会に、スポンサーみなさまに、
圧倒的「感謝」!👏👏

ISUCON5 オンライン予選に参加していました

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

こんにちは。ごみばこです。

以前より気になっていたISUCON、ついに初参加しました。

同じ会社の人もでたいー!と言っていたので、これはいいチャンスだと思っていたのですが、
結果的にみんな予定が…とかでボッチ参戦でした。オコです。とてもかなしい。


ISUCONとは?

「Iikanjini Speed Up Contest」の略で、Webアプリケーションのパフォーマンスをあげようぜ!というものです。
http://isucon.net/


やったこと。

  • 用事のため、12時半ごろからの参加。ぐぬぬ。
  • PHPの実装があやしいということで、再実装する勇気は出ず、Rubyに逃げる
  • 静的ファイルをnginxで返すようにした
      ちょっとだけ上がった。
  • worker_processをあげてみた
      1kくらい上がった
  • relationsをRedisにキャッシュしてみるもうまくできない…
      /initializeで持ってきて、全部そこを使えばいいんじゃね!?!?と思ったけどうまく行かず。
  • footprintのDATE(created_at)をやめる
      ちょっと上がった。
  • / と /login を見直した
      8kくらいまで上がった
  • entriesがアレすぎるのでキャッシュしてみる。
      参照したentriesを全部redisに突っ込む仕様にした。が、スコアが5kまで落ちる。
  • Redisが詰まった…?(????)か、ベンチボタンダブルクリックして2回走ってた…?
      結果よくわからないので戻す。
  • 最後いろいろいじくったら9700くらいになって時間切れ
      インデックス張ったり、ビューの処理をなるたけやめたり。
  • ペプシのストロングゼロめっちゃのんでた。おすすめ
      500mlペットが75円なのめっちゃつよい。

やらなかった、やれなかったこと

  • 過去問で練習
      やろう!やろう!言っててなにもしてない!ひどい!
  • PHPでがんばる
      妥協。PHP7とかHHVMとか試したかったでござる
  • デプロイの仕組みを作る
      1人だし妥協。git pullすらしてない。
  • entriesのカラム調整
      ALTER TABLEに時間がかかりすぎ…。
  • erbをやめる
      erbめっちゃ遅いで。と噂を聞いた程度、実際にloginページはやめた。nginxのプロキシキャッシュも試してみたかった
  • SQLクエリの様子を見る
      スローログの設定がうまくできなかった。アプリ側でログだせばよかったなあ
  • Redisキャッシュ
      やり方がだいぶおかしかったかもしれない。
  • アクセスログの詳細度をあげる
      レスポンスタイムとか見れたはず
  • チームで戦う
      次こそ!
  • erb中のロジック見直し
      終了後によく見たら、もうちょっとだけなんとかできそうな部分あるじゃん…
  • 再起動しての動作確認
      完全に忘れてた。

「1日目、2日目、それぞれで3000点に最も早く到達したチーム (ただし予選終了後の追試の対象には含まれます)」とあったので、ひとまずの目標を3000点にしていました。最終的に1万にとどかないくらいというところで、まあまあ満足する結果になりました。

そんな感じで、1人でも意外といけそうということはわかったのですが、見たいところやいじりたいところが多すぎて、うまく整理できてなかったようです。
もうちょっと、ここがこうでーとか色々メモして、見ていく順番をつけてあげると、自分の動き方がよくなってスコアも伸ばせたかなあ、という印象です

あとは、圧倒的な知識不足を感じました。
以前やっていたとはいえ、Rubyもなんだっけなーくらいだったり、どんなライブラリ使うといいかとかわからないし。
nginxよくわからないし、ミドルウェアもうーん、うーん…、うーーーーーん。

直前で猛練習したり、日頃から触っているような生活じゃないと、いきなりコンテスト!は厳しい感じでした。

あとは1人なのもあって、時間とスコアだけしか見てない動き方だった部分も反省点かなと。

git?いやいや、面倒だから本番いじっちゃおー。_bkとかしときゃいいでしょ。とか。
特定のページだけ静的化とか普通しないけど、スコア伸びたしいいやこれ。とか。
なんでそうなるのかわからないけどこういう設定すりゃいいんでしょwとか。

ということで、次回(もしあれば)は、3人で出る!を目標にがんばります。
本選もいけるなら行きたいけど、楽しいのがいちばんだよね!

最後に、運営のみなさま、楽しいイベントをありがとうございました!

私立プログラミングキャンプ2015 Tokyoに参加してました。

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

ピクシブさんにて、土日通しの泊まり込みハッカソンでした。

途中でちょこっと寝てしまったようですが、ほぼほぼ完走しました。

(ただし成果がついてきているとは言っていない)

ありがとうピクシブさん。
ありがとうゲヒルンさん。
ありがとうオプティムさん。

やったこと

・ごみばこいんのマルチプレイ対応(仮)
・誤字脱字検出っぽいなにか
・ごはんをたべる
・ツイッターを見る
・アニメを見る

ごみばこいんのマルチプレイ対応(仮)

作業時間の7割くらいをここに費やしました。

過去に一度やっていたのですが、ソースコードが消えてしまい…。

ということで、改めて作っていました。

サーバサイドでそれっぽい動きをするものを作り、ある程度の頻度で同期するようにしたら、
クライアント側の動きとサーバ側の動きが異なりすぎて、ひどいラグが起きているかのような同期性能になりました。

memo

ひどい…。

以前おこなっていた方が、WebSocketで高頻度で同期していたので、安定してくっついていましたが、
ちょっとこれではだめですね。

また出直してきます。

誤字脱字検出っぽいなにか

ちょっとした都合で、誤字脱字を判定したいなーという都合があり、
それっぽい実装でできるのでは?と思って試していました。

実装としては、機械学習のようななにかになっています。

よしなにわかち書きのようなことをしてからの、
前後の出てくる文字列を数えて、データとして持っています。

入力値に対しても同じように処理し、
もっているデータと付け合わせてレーベンシュタイン距離的なものを出し、
一番近いものを出す、だけです。

超簡単!!

が、たとえば、漢字が変換されてないとか誤変換とか、
「よしなにわかち書き」が雑すぎて、実用にはちょっと無理すぎるレベルでした。

その問題あたりをちゃんとしたら戦えそうな気がするので、
また試してみます。


tmp

ごはんをたべる

パンがメインでした!!!

あとエナドリ!!!

ビタミン不足しそうだったので、ウイダーインゼリー的なのも食べてました!!!

ツイッターを見る

ひと段落つくたびにツイッターみてました。

久々にまじまじ見てましたけど、結構おもしろいですよね。ツイッター。

アニメを見る

アニメを見ながらコード書いてました。

最近はやりの、友利奈緒さんを見ました。
非常に残念なことに、私には友利奈緒さんの良さがさっぱりわかりませんでした。
もうちょっと見るといいんですかね~。

あ、伊波まひるさんはかわいかったです。
良さがありました。

おわりに

ハックしてる感の高いハッカソンめっちゃ面白いのでまたやりたいです!!!!!!!

次はISUCONか~~!?!?!??

#upcamp 2014 Tokyo に参加してましたよ

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

ドーモ、ごみばこです。

私立・プログラミングキャンプ 2014 東京大会
https://atnd.org/events/52713

こんなものに参加していました。
スタッフ側だったようです。

  が!9時集合なのに9時に起きて10時着という大失態。。
  ごめんなさいごめんなさい。。。

参加者みなさま、スタッフかたがた、お疲れ様でした!

会場提供してくださった オプティム さん。
ピザ提供してくださった ゲヒルン さん。
ありがとうございます!最高!!

 

1. やったこと

・水運びました
・ジュース類運びました
・ピザ運びました
  サイコー。

・RFC2616をちょこっと眺めました
  >> http://lab.moyo.biz/translations/rfc/rfc2616-ja.txt
  ざっくりまとめると、HTTP/1.1 の仕様書です。

・ソケットよくわからんつらいってずっと言っていました
  >> http://e-words.jp/w/E382BDE382B1E38383E38388.html
  ラップされてるのはちらほらとやる機会があったものの、
  acceptとかrecvとかそのくらいのものはなかった。

・winsockのサンプルコードを眺めました
  >> http://e-words.jp/w/Winsock.html
  WSAなんたらかんたらとか。
  ウィンドウハンドルがどうこうとか。使ってないですけど。

・OfficeTanakaのサイトをあちこち眺めていました
  >> http://officetanaka.net/excel/
  VBAにこまると大体でてくるので強い

・「さっきまで動いてたけど動かなくなった」と言っていました
  よくあるはなし。

 

2. 成果

まずはこちらをご覧ください。

 

3. 技術的なサムシング

・全体像はこんなかんじ。
  ・ひとまず自分だけ見れればいいやのレベルで
  ・ExcelVBAでHTTPサーバを建てる
  ・ワークシート名でルーティング
  ・ワークシート内のコンテンツがレスポンス
  ・(想定)DB.tableなシートを作ってデータを保持する
  ・(想定)POSTデータを読み込んでデータを保存する
  ・(想定)データを読み込んで動的に埋め込む
  ・シンプルに掲示板を作りたかった(白目)

  思いのほか、ソケット周りで詰まってしまってレスポンスを返すのがやっと。
  『さっきまで動いてたけど(変数化|リファクタ|再起動)したら動かなくなった!』

・ワークシート内のテキストを返す
  シート内を全文テキストとして取得するのどうするんだろう
  → 全セルみたら死ぬしなあ
   → いったんtsvに落としこんでから読みこめばいいんだ
    → なんかダブルクオートで囲まれたりなんかつらすぎる…
     → なんかもう、一旦正規表現でよしなに消しとこう…
    → たぶんここでキャッシュしたら早くなるんだろうなー
     → ひとまずいいや

・Declareステートメント
  >> http://msdn.microsoft.com/ja-jp/library/cc376178.aspx
  コピペしないで書いたのは多分初めて。
  必要な関数をMSDNで調べて、引数とか戻り値を合わせて。

・クラスモジュール
  >> http://www.excellenceweb.net/vba/class/what_vba_class.html
  >> http://codezine.jp/article/detail/499

  全部やるとあれな予感がしたので、一旦リクエストとレスポンスだけクラス化した。
  クラス化した直後は最高に穏やかな気分だった。

  Before:
  『あ゛あ゛あ゛あ゛あ゛変数スコープう゛う゛う゛う゛う゛』
  『いや、あの、えっと、その、つらいです、はい、まじで』

  After:
  『こころのやすらぎ』

・振り返るとそんなに書くこと無かった(重要)

 

4. これやることにした経緯

このあたりをご参照ください。

ちがう。
ぼくはcanvasとかsvgとか、オンラインで動くやつを求めていたんですよ。

ですがここで、気付いてしまったわけです。
「Excelってグラフ作れるよなあ、VBAでプログラム書けるよなあ。あっ(察し)」

 

5. 作ってみて思ったこと

もしかして『始めたいです!』な人向けとして意外に需要があるのでは?

ほら、セルのおかげでしっかり構造化できるし。

インデントもちゃんとできるし。

ハイライトも実装すればできるし。

おや?????

 
あ、この流れしってる。
言い出しっぺの法則ってやつだ。

……そういえば、プログラムエディタをExcelにしよう!って話もありましたね。
  >> http://d.hatena.ne.jp/miya2000/20111221/p0

  あ、ここにシートのテキスト化があった…

 

6. おまけ

名前を書いてあった紙があるじゃろ?

2014-08-17 23.35.50

 

これを、

 

こう、

 

ごみばこの出来上がりじゃ!w

2014-08-17 23.35.30

1 2 3