  |
はてなキーワード: ダッシュボードとは
なぜ神奈川かと言えば、自分と関連することもそうだが、この時点でビリだから。
https://cio.go.jp/c19vaccine_dashboard
2021/06/05時点
1回目が終わらないと絶対に接種が終わらないので、まずは1回目だけで計算する。
単純に Y(days) = a(傾き) x X(接種率)で計算する。
が、現状の傾きを示しているようなので、上記データから計算する。
なので
a = 0.739
で、Xが100%になる日は、
Y = 0.739 x X = 0.739 x 100 = 約74日
5/21から74日は、2021/8/2日。
1回目の接種日が全部終わるのが8/2。
Xを80%とすると、 Y = 0.739 x 80 = 約60日
5/21から60日は、2021/7/19日。
1回目の接種日が全部終わるのが7/19。
次に、2回目の接種が終わる日を計算してみる。
現状だと計算が難しいが、現時点(6/4)で2回目が0.59%であり、1回目の0.59%になったのは、5/11なので、ラグがそのぐらいあると仮定する。そうすると、25日後に2回目が追いつくと思われる。
ということで、2回目が終了するのは、
まず大前提だが、カーシェアは『その場所に置いてある車をみんなで使うサービス』だ。タイヤやブレーキオイル、ガソリン残量の管理をユーザーに回しているからの価格であって、レンタカーと比較するのはお門違い。
3日間も誰も借りない場所なのに、まんさんが利用する時は大好評で近隣含めて貸出中だったとのこと。火曜日に借りてまんさんが土曜に利用なら分からなくもない。
GPSで見つけられるが全台モニタリングしている訳じゃないので3日間誰も予約して無ければ気付かないこともある。
1ヶ月前から予約できるステーションは多くが乗り捨てサービス実施ステーションだ。これは『そこから空港近くの駐車場まで行って、そこに停めて飛行機に乗れる』サービスだ。レンタカーでよく聞くサービスだが、もしかすると利用者はどこでも置いといてOKとでも勘違いしたのかも。
ダッシュボード下のキーボックスに鍵挿して、外出てカードリーダーに会員カード当てたら返却完了になる。恐らくだがGPSでチェックはしていない。（ズレて返却不可にならないように）
チェックインサービス（指定された場所に一定時間停めると無料券もらえるサービス）とかで利用しているし、そもそも全台カーナビ付いているので当然ある。
まず利用中扱いで金はずっと継続。更にNOCで数万円かかる。会員は剥奪。二度と使わないにしても金は請求される。
免許証登録してます。もし登録会員以外に運転させてたのなら罰則追加。
空きがあれば他のを貸してくれます。でも近所に空きがなければゴメンナサイです。でも金は取られません。タイムズレンタカーが縮小傾向なのでこのへんは厳しくなっています。
まんさんが使う4日以上前に返却場所以外に乗り捨てられ、少なくとも3日間他の誰にも予約入らず、不幸にも当日近隣全てが貸出中だった。
凄く珍しい事です。まんさんが嘆くのは分かるが、タイムズカーシェアの日常では無い。
定期的にタイムズ自身が回って対応しています。ユーザー義務のチェックで気付けば優先で対応してくれます。（もちろん代車紹介してくれるが近隣に空きなければゴメンナサイ）
見たこと無い。
次のユーザーが報告して判明するシステムなので、次のユーザーが報告しなければ例えドアこすってもバレません。報告のメリット（会員ポイントが1ポイントのみ）がショボいので正直仕方ない。
一つは利用料を上げてタイムズの管理を増やす。ただ15分250円が限度だと思うし消費増税時に長時間プランの削除と値上げを実施しているので恐らく無いだろう。
もう一つはユーザーがより報告しやすくする方法だ。無料とは言え報告は電話ベース、利用中だと電話している最中にもカーシェアの料金はかかる。オマケに電話が苦手な人も年々増えている。とは言え報告に報酬を付けるとブレーキオイルをわざと抜いて故障連絡したり、自作自演のゴミ放置等が出てくるだろう。こっちも望み薄。せいぜいアプリから簡単に報告出来るようになるくらいか。
増田はレンタカーの営業時間、満タン返し、最初の傷チェック、返却時の確認のドキドキが全部無いカーシェアはとても楽だし、正直酷いユーザーにあったこと無い。汚れも匂いの被害もない。長時間利用の価格面と車を確実に利用できる面ではレンタカーに軍配が上がるが、増田的にはそれ以上に手に入る気軽さでカーシェアも充分オススメできると思う。
とりあえずタイムズ24はまんさんの件については何かコメント出すべきだと思う。別に疑っているわけじゃないが、流石に一方的な悪評が出まくってて不憫に思う。
内で実践した経験やノウハウを広く公開していきたい 従業員の働き方や意識についてはどうでしょうか。
ミレニアル世代以降を「目覚めた世代（Woke Generations）」と呼ぶことがあります。彼らは自分の価値観や会社が提供する価値を考え、社会的に間違っていることがあれば明確にメッセージとして主張します。従業員はただ雇われるのではなく、例えばDEI（ダイバーシティ、エクイティ、インクルージョン）を重視し、おかしいところがあれば臆することなく指摘するのが世界的な潮流です。企業はこうした従業員とよいコミュニケーションを取るために、ビジョンや具体的な回答を明確に示す必要がでてきます。
ですから今後は、ジョブディスクリプションに基づいた合意の下で働く「ジョブ型雇用」のように、企業と従業員が対等な関係性の中で役割や目的を明確化するローコンテクストな働き方が増えていきます。こうなると「オフィスに行く」という行動は、カルチャーの共有やテキストだけでは理解できない経験を伝えるなど、極めてハイコンテクストなコミュニケーションの場所になっていくと考えられます。
社内では部下の成長支援を目的として1on1ミーティングを定期的に実施しています。一人一人の従業員の未来を含めて、上司や管理職、経営層がどうサポートしていくかがこれまでより重要になってきたと感じます。従業員に真剣に向き合わないといけませんし、自分自身がジョブ型の人事制度にシフトする中で、部下の一人一人に対して何をどんな役割で任せるかを明確にコミットしないと、働く姿が見えなくなる可能性があります。そこも含めて難しい環境になってきたなと感じています。
その意味では、データを活用して一人一人の特性を把握したり、AIを使ってそれまで目に見えなかったスキルを見つけたりといった取り組みも進んでいるので、期待はしています。
前述したWork Life Shiftには3つの実践が含まれます。固定的なオフィスに全員出勤することを前提とした勤務制度や手当、福利厚生、IT環境などを全面的に見直し、時間や働く場所にとらわれない働き方の実践がSmart Workingです。
Borderless Officeは、オフィスの在り方を3つに分けて再設計する取り組みです。オフィスを性質別に「ハブオフィス」「サテライトオフィス」「ホーム＆シェアードオフィス」に分け、仕事の仕方を分類したのです。出社しなければできない仕事は会社でやり、家でできることは家でやります。実は、オフィスにはコクヨ製のファシリティも導入し、従業員が使うことを誇らしく思えるように作っています。これらと併せて、Culture Changeとしてジョブ型人事制度の導入など文化を変えていく取り組みも進めています。
――新しい働き方では「PCを設置したデスクに出向いて仕事をする」といった、従来の場所とデバイスの関係も変わり
ジョブ型、分散型の働き方が広がると未来学者フィリップ・ロスが言う「アプリ中心主義」の働き方（App Centric Work）になると言われています。仕事場所や同僚を探す、休憩のためにコーヒーを予約注文するなど、仕事をするためにまずアプリを立ち上げ、アプリを中心に仕事をまわすようになると、端末の重要性も高まっていきます。常に手の届くところに置き、全ての起点になるデバイスへのニーズは大きくなってくるでしょう。
「アプリ中心主義」の働き方は非常に良く理解できます。感覚的には「モバイルPC≒オフィス」が近いのではないでしょうか。「PCを開いた場所が仕事場である」という体験はテレワークを通じて多くの方が理解したのではないかと思います。仕事をこなす場所としてのオフィスはモバイルPCが代替するようになるかもしれません。
私たち富士通はモバイルPCがテレワークのキーになると考えています。テレワークの普及をきっかけにモバイルPCのニーズが高まったことを受け、現在もテレワーク向けの機能強化を進めています。弊社モバイルPC「LIFEBOOK U9シリーズ」は、コクヨさまにもご導入いただき、貴社従業員の皆さまにご好評いただいておりますが、このU9シリーズの最新機種では、エンドポイントセキュリティ対策の機能を強化し、より安全に快適にテレワークを実践できます。
今後は物理的なオフィスの役割は見直されるでしょう。今までと同じノートPCで仕事をするのであれば、わざわざオフィスに来る必要がなくなります。オフィスはオフィスでなければできない仕事のためにチューニングされていくでしょう。例えば、複数のディスプレイや議論のためのダッシュボード、遠隔のメンバーを交えて議論ができるワークスペースなどが整備されていくのではないでしょうか。
山下さんがおっしゃるようなハイコンテクストな議論を求めてオフィスを使うとき、従業員がいちいちモニターケーブルなどの周辺機器を各自で持ち込むのは合理的ではありませんし、フットワーク軽く議論に出かける状況を作りにくくなります。
富士通の場合、オフィス据え置きで大画面の液晶ディスプレイやポートリプリケータといった新たな設備を設置することでこうした問題に対処しています。小さな改善のように見えますが、ちょっとした気配りが組織の行動や発想を左右することがあります。私たち富士通は、大規模なテレワークを通じた経験から、そうしたノウハウも含めて時代に合った提案をしていきたいと考えて
URL に `locale=ja` が含まれていると発生するようです。ブラウザの「言語設定」から日本語を削除するか、https://creators.brave.com/ からログインページにアクセスしましょう。
URL に `locale=ja` が含まれていると発生するようです。ブラウザの「言語設定」から日本語を削除してください。
クレジットカードかデビットカードを PayPal で登録・認証しましょう。
なお、現在は BAT への移行期間らしいので手続きはお早めに。
https://brave.com/ja/bap-to-bat/
https://community.brave.com/ で質問しましょう（英語）。
上記のログインエラーに該当するスレッドは https://community.brave.com/t/cant-login-first/216606 です。
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ファンと変わりない。
