  |
はてなキーワード: ダッシュボードとは
18から日常的に自動車(AT車)を運転してる30代で、ずっとゴールド免許だが、実は過去に駐車場で何度か踏み間違えてヒヤッとしたことがある（少し離れた駐車スペース間の移動[前進]、駐車時[後退]）。いずれもクリープだけでは足りないような場所で、アクセルで車速を加減していたときだった。幸い事故には至らなかったが、報道のせいか最近怖くて仕方ない。
そんなやつは運転するなという厳しい声もあるだろうが、現実的にはなかなかそうもいかない。各種センサーやワンペダルといったハード的な工夫は報道で見かけるが、そのほかに、何かしら有効に機能すると思われるユーザーレベルの知恵や心がけがあったら教えてくれないだろうか。
以下、現状自分で試していること。
書いていてふと思ったのだが、「いまどちらのペダルに足が乗っているか」をHUDなどに表示させるようなセンサー技術はないのだろうか。
いや、いざ間違える時はそんな表示を見ている余裕はないのかもしれない。
[追記]ブレーキを踏むとリアのブレーキランプと連動して赤く光る視覚フィードバック装置を、前を見ていても視界に入り、かつ邪魔にならない感じでダッシュボード辺りにつけられないだろうか。
「ブレーキを踏むと赤く光る」と認識する習慣がつけば、エラー時にも気づきやすくなると思う。
みなさんどうもありがとうございます。
一気に踏まず、少し踏んで、車体の挙動を身体で確認してから踏む
踏み込む前にトンットンッって足でペダルを軽く叩いて、動きを確認してから踏む
形状の違いを足裏で確認
これは良さそうだと思いました。同じようなことを昔から私も心がけていますので、そのおかげで踏み間違えてもぶつかる前に修正できたのかもしれません。
そもそもうまくいきそうなことをやっている場合はWebフロントエンドに時間をかけてられないという話。
まともなエンジニアなら枯れてない技術を使った時に生じるコストを理解している。それはたくさん残ってるバグとか、バージョンアップによるAPI変更への対応するコストだ。そういう対応コストはユーザがうれしいものではない。「あの話題のモジュールに投げたバグ修正がマージされました！」とか言っても、ねぇ？
あとWebフロントエンドって、最新の技術を使ってもレガシーな技術を使っても結局html/js/cssが成果物なので、出来上がったモノはユーザから見ると大差ない。つまりWebフロントエンドに限って言えば最新の技術を採用していても競争優位にはなりにくいのだ。
ユーザに需要があるものを作ってる時って、枯れてない技術に挑戦したりしてる暇はなくて、小慣れた道具でつくらなくちゃいけないことが多い。毎週のように新機能が待ち望まれている状態ではゆったりと開発してるわけにもいかない。
ちょっと逆説的だが、ゆったりと開発できているということは、作っているものに需要があるか怪しいということだ。
新規プロジェクトが立ち上がったものの、方向性がぼやけていて、プロダクトマネージャが決めなくちゃいけないことがたくさん残っているような場合、エンジニアはもちろん暇になる。
コードベースはまだないのでリファクタリングもできず、データもまだないのでダッシュボードを作ったりもできないとなると、エンジニアは「じゃあUIは前から使ってみたかったアレで作ろう。時間はあるし」となる。
だいたいこういうプロジェクトが成功することはないし、こういうときしかWebフロントエンドに最新の技術スタックは採用できない。ちゃんとしたプロジェクトではそんなヒマはないからだ。
新規プロジェクトが立ち上がって、プロダクトの方向性が明確なときは、エンジニアはすぐに手を動かすことができる。ユーザが欲しかった機能が開発できていれば、すぐにユーザからフィードバックが返ってくる。そうすると次の機能開発にとりかかれる。
こういうプロジェクトではWebフロントエンドに枯れていない技術を採用するヒマはない。枯れてない技術を採用するにしても、サービスをスケールさせるためとか、ユーザに見える価値を提供するためのものだ。
Webフロントエンドにバリバリ新しいやつを投入するのはもちろん悪いことじゃないのだけれども、そんな余裕があるなんて、ひょっとして作っているサービスはイケてないんじゃないでしょうか? もしくはビジネス的な成功はまあ別にどうでもいいかな、というスタンスなんでしょうか?
一度手を動かし始める前に周囲を見渡してみるとよいのではないでしょうか。
テスラの車は、トヨタとメルセデスの古いプラットフォームから派生した純電気自動車だ。まあ、旧型カムリだ。各ECUとインパネ(IC)間がCANバスで結ばれ、ゲートウェイを通して車内インフォテインメント(カーナビ)が接続できる。そして、ゲートウェイにはセンターコンソール(MCU)、自動運転モジュール(APE)が接続されている。まあマツコネみたいなものだ。ただし、通常のカーナビと違い、このMCUはTegra 3(旧世代)または超高速なIntel Atomプロセッサ(現行)が採用されている(マジ)。そして、海賊版のUbuntu GNU/Linuxを実行している(マジ)。そしてLTE回線に直結し、テスラ本社のサーバ(mothership.tesla.com)にOpenVPN接続している。
古いモデルは3G、新しいモデルはLTEモジュールを標準搭載している。明示的に特別注文しない限り無効化や取り外しは行われない。本社Mothershipは各車の動作状況を監視・操作するほか、オートパイロット起動通知を受け取り、またssh接続のためのパスワードを保持する。これによりファームウェアのrootが取られた場合にオーナーを蹴り出したり、あるいは事故発生時に「オートパイロットは(直前でエラーを吐いて運転をぶん投げたため)使用されておりませんでした」と発表するなどいち早くメディア対策を行うことができる。
更新パッケージは前述のOpenVPN経由でダウンロードされ、その中にAPEファームウェアのほかにもドアハンドル、ブレーキ、インバータECUなどのファームウェアが含まれていれば、MCUが更新処理を行う。これまでに配信されたアップデートには、Linux Kernelを含むMCUのOS更新、インバータ出力アップ(設計の三倍程度)、緊急制動距離の延長と短縮、自動緊急ブレーキの追加、自動運転の警告間隔延長・短縮(事故報道の頻度に応じて調整)、自動運転機能そのものの搭載や根本的な入れ替えなどがある。現在の仕様ではファームウェアバージョン表記はYYYY.WW.x.y.zで、GitのコミットIDが末尾に付き、平均して月2回程度のローリングリリースが行われる。つまりリポジトリのheadがざっと社内検証を通るとLTEで降ってくる。非常にまれなケースでは社長(@elonmusk)の「やりましょう」ツイートから数時間でバージョンが上がる。
純電気自動車なので、エンジンは搭載しない。代わりに車体下面にリチウムイオン電池パック(ノミナル電圧480Vまたは400V)を搭載する。パックは火薬式ヒューズを含む高電圧コンタクタ(リレー)を介してモータおよびインバータと接続され、インバータはモータ進角を監視しながらスロットル指示に合わせて三相交流電源を供給する。この辺りはCPUファンと変わりない。
ガレージの中は身を切る寒さで、キーを持つ手が悴んだ。毎日こうも寒いと、地球温暖化はでっち上げだなんていう冗談の一つも言いたくなる。
知人の頼みで留学生を空港まで迎えに行くとメイリンに話したところ、自分も行くというものだから、僕は直接空港に行くという当初の予定を変更し、彼女の家に向かっていた。
ここ数日は晴れていて、雪は随分捌けてはいたが、路面の凍結があるかもしれず、神経質にならざるを得ない。バスを使っても良かったが、大きな荷物を抱えてやってくる右も左もわからない留学生には、足がないのは心許ない。
２ブロックほど走行しメイリンの家に到着すると、車を道路の脇に寄せ、彼女が現れるのを待った。
Me: I’m here （着いたよ)
Meiling: k （わかった）
Meiling is typing… （メイリンが入力中……）
Meiling: I’ll be there soon （もうすぐ行く）
あと４分。そう僕は打算した。彼女が「良い」と言ってから出発しているのに、どうして到着してからさらに待つことになるのか、時々不思議に思ったりもするが、これはいつものことだ。
＊＊
４年前、僕が初めてシアトル・タコマ国際空港に到着したとき、僕はBITの寮に向かうシャトルバスを探して、空港内を歩き回っていた。
海外に行くのはそれが初めてのことで、文字通り右も左もわからなかった。
やっと見つけたターミナルは、タクシーが行き交っていて、シャトルバスが停まるところではなかった。疲労で立ち尽くしていた僕に、タクシー運転手が声をかけた。
「タクシーを探してるのか」
「どこの大学」
彼は僕を空港内のインフォメーションセンターに連れて行った。そうして僕が探しているターミナルを案内員の女性に問い合わせてくれた。
その女性は、僕にターミナルへの経路を伝えるだけでなく、わざわざ近くまで付き添って歩いてくれた。
そうして僕は、やっとの事で正しいターミナルに辿り着いたのだった。親切に恵まれて。
ターミナルのベンチには先客がいた。きっとこれは幸運なのだと、僕はわけもなく直感した。
それは小柄なアジア人の女の子で、彼女は僕に親しげに話しかけた。
「BITに？」
「はい」
「良かった。私もです」
彼女が続けた。
「シャトルバス、もうずっと待ってるんです」
「どのくらいですか？」
「１時間くらいです。もしかして場所を間違えたんじゃないかって思ってたんです」
「やっぱりここですよね」
「もうすぐかも」
「そうだと良いんですけど」
「……」
僕は会話に言葉を継ぎ足すことができなかった。
彼女の座っているベンチはまだスペースに余裕があったけど、僕はなんとなく気が引けてそこに座ることができなかった。脚は棒のようになっていたのに。
手持ち無沙汰になって、僕はバックパックから、宮部みゆきの『火車』の文庫本を取り出した。
その時、
「来た」
彼女が叫んだ。
BITのマスコットである、ブルドッグの『ジュリアン君』のプリントが入った白いバンが、僕たちの目の前に止まった。
僕は慌てて文庫本をバックパックに戻して、車輪の滑りの悪くなったスーツケースを引きずり始めようとしていた。
「ところで、」
歩き始めた彼女が踵を返して言った。
「お名前聞いても良いですか？」
僕はサトシと答えた。彼女はメイリンと名乗り、ピカッと笑った。
＊＊
偶然、僕は親切と幸運に恵まれたが、宮本恵梨香が同じだとは限らない。彼女が迷わないように、僕は昨晩、手荷物レーンから僕が迎えに行くターミナルまでの経路をできるだけ詳細に説明して、空港のマップとともに彼女宛にメールした。僕の車の車種とナンバーも添えて。
窓をノックする音がした。
メイリンが手を振っていた。ピカッと笑いながら。
うちのじいちゃん若いころそういう体質だった。でもばあちゃんに詐欺といわれてる。
見た目はいまだに太らないんだけど羊羹一本食べができるくらいの甘党。
自動車のダッシュボードにかくしもってた鈴カステラを孫に「完全にカピカピじゃん」ってバカにされてた。
いまは別の薬の副作用もあって、油断すると糖尿フラグが立ちまくり。
背が高いから目立たないんだけどちょっと顔が丸くなったとおもったら脂肪肝もあったことがある（酒一滴ものめないのに）
若い人からするとすでに修行僧みたいなのに、野菜食べないからだって完全菜食みたいになってる。
でもまだ一回も梗塞系やってないし本当の糖尿にもなってない
（一度なると血管全体から目や足など末端からボロボロになっていく）
旦那であるじいちゃんの体にちょっと変調がある（その別の薬のほうで）と泣かれる。
めんどくさいなもう。年相応の変化なんだからこっちに泣きついてくるなよ・・。
若い女はダイエットの失敗を通して何を食べるか、運動とは何かを学べた子だけは夫ともども健康で長生きできるよ。
数ヶ月前のはてなブックマークの仕様変更で"はてなNG"などのChromeのエクステンションが使えなくなったとかなんとかいう話を見た覚えがある。その後の展開は知らないけれど、今見たところ最終更新日が2014年のままだからおそらくどうもなっていないのだろう。
WebExtensionsの知識もないので、出来合いの広告ブロックアドオンuBlock Originのコスメティックフィルターを使って仕様変更後のはてなブックマークのエントリーをブロックする方法をメモしておく。使ったブラウザはFirefox 60だけど、他のブラウザでも似たような感じでできるのではないだろうか。
uBlock Originのダッシュボードを開く。ツールバーのアイコンやアドオンメニューの設定ボタンから開くことができる。
My Filtersタブを開く。
例えば朝日新聞のasahi.comをブロックしたい場合、次の行を追加しApply Changesボタンを押して変更を確定する。
hatena.ne.jp##.js-keyboard-selectable-item:has(a[href*="asahi.com"])
ブロックしたいサイトが増田(anod.hatelabo.jp)だとしたら次のような行を足すことになる。
hatena.ne.jp##.js-keyboard-selectable-item:has(a[href*="anond.hatelabo.jp"])
例えば「アメフト」を含むエントリーをブロックしたい場合は、次の行を追加しApply Changesボタンを押して変更を確定する。
はてなブックマークのエントリーリストページにはタイル、リスト、ヘッドラインと3種類の表示方法があり、htmlの書かれ方もそれぞれ違うが、class="js-keyboard-selectable-item"のli要素がどの表示方法でも共通して存在する。2018年3月以降のはてブページでエントリーをブロックするためにはこの要素を指定して隠すのが手っ取り早い。広告ブロックソフトを使うにせよ、JavaScriptを自分で書くにせよそういう方針になると思う。
uBlock Originを使ったブロックの欠点は上記のように設定が若干難しいのと、はてなNGのようにIDを指定するだけでブコメもブログも両方ブロックという芸当はできないことだろうか。ブコメ、ブログをそれぞれブロックすることになる。利点は高速性を謳うuBlock Originなどの機能をそのまま使うので速度低下を最小限に抑えられることだろう。
コンサルにてアナリストをやった後、データサイエンティストを名乗りながら仕事をしています。そんな中で嫌だったなと思った人たちとプロジェクト
最近はアウトカムでの評価の流れにはなってきたが、まだまだモデルの評価をする事は少ない。
でも何故か相変わらずロジステックとCox回帰をやれればおっけーであり、モデルの精度が当たらなくてもオッズ比と説明変数の
有意差だけでていれば上手く行く分野。 本当に心が痛む上、まだまだ「医者でなければ人であらず」が通ってしまい、モデルの説明よりもお医者様のお言葉が1stにきてしまう。また分析プロジェクトの
設計らしい設計があまり出来ないのもつらいところ（モデルの精度が出ていないのにそのオッズ比・有意差に何の意味があるんだと思う）。後日本の製薬企業から「何とか工夫で有意差がでないのか！！」
という謎おしかりを受ける・・・いやそんなん無理ですやんと切実に思う。やる気でこの世界の数字は変わりません。
割と良いBIみたいなんが良くも悪くもあるためアナリストの人たちがやった気になっているやつ。Web関係のアナリストは、アナリストを名乗って欲しくない人の方が多いイメージ（勿論しっかりWebアナリストやっている方々は知っている）。広告内容を分類し、CVを予測、そしてマルチチャネルの予算からのCVを最適化案件をしていたらWebアナリスト様から「私の作るLPは最適です。なので予算４０００万です」という謎の最適の主張を受けたのはいい思い出（何故かデザイナー様がWebアナリストもやっていた）。広告内容のuser2vecでのレコメンド実装にチャレンジして評価して、協調フィルタリングよりも精度はよさげだな喜んでいたら、どっかのよくわからないレコメンドツールというのが汎用性もあるし、既存のツールに１万ぐらい払えば追加できるとそして何故か「最適化」されているという言葉に役員が騙されて決済がおりていたのを聞いたときは殺意が沸いた。どうせ既存のマーケティングオートメーションのレコメンドエンジンなんて協調フィルタリング・ロジぐらいだろうと思っている。本気で分析やっている人がそうそう最適化なんて言葉を使わないと思うんだ・・・。まぁここの反省はWeb業界といってもみんなコーディングがりがりではなくてGUIでいいならそれでが割と多いという事を学んだ （注意）。
３．データベース関連
どっかの人のにもあったが、「あっ、データ分析分かるんだよね？」という事でVB6とAccessの改修をやらされそうになったときは全力で拒否った。
４．やる気を説いて来る人達
やる気で数字が変わったら誰も苦労なんてしないんだよ・・・。半教師有り等で精度向上見込めるといってもいくらなんでもこのデータでは
５．ホワイトボックステストを要求されたとき
モデルのホワイトボックステストってどうやってやるんだ？精度を検証用データでやっていれば良いじゃないかと思っていた。ただそこの金融系でITプロジェクトは、基本的に「ホワイトボックステスト」やらが必須らしく・・・おいおい・・。とりあえずカテゴリーの目的変数がそれぞれの値を取ることを客先で見せてかつレポートで「こうこうこうゆうときにカテゴリー変数が変わりますよ」という彼らがいう境界線の確認を全てやることになった。カバレッジ１００％も言われたが、流石に無さ過ぎるので諦めてもらった。
６．KGIとKPIしっかり切り分けてBI作成していたら集計屋かといって来られる時
どこかの人にもあったが、私はビジネスが動けばよいと思っているので難しい分析をしなくても上手く行く時は、集計で上手く切り分けて、要因分析をやる（裏で決定木とかで境界値とかは見ていたりする）。ただ何故かそれで集計ばかりしかしていないと怒られる。別に研究者ではないし、難しい分析をしてクライアントへの説明に時間を取られたり、展開が難しくなるぐらいならば皆と合意した上で、KPIとKGIを切り分けてダッシュボード作成をしっかり出来る方が実はビジネス上上手く行くだ。むしろ自分への戒めでいつも難しい分析が本当に必要なのかと思ってるぐらいである。
注意 因みに私の別部署でインフラ基盤周りのWordpress関係が炎上していた。そこそこの大規模でWordpress使うって大変らしいのに・・・。
