  |
はてなキーワード: UXとは
高齢者向けのワクチン予約サイトがなかなか混雑して苦労するらしい。高齢親に頼まれたので、予約開始前に操作手順を確認してみた。
接種券番号と氏名が印字された接種券が郵送で届くので、予約サイトにアクセスしてみる。URLはこんなかんじ。
ttps://vaccines.sciseed.jp/(自治体名)/
フローはだいたいこんなかんじ。UIはまあ普通の予約サイトなかんじ。
3.初期パスワードを変更
5.接種会場検索→希望日時を選択→予約完了(予約開始前なので未確認)
そしていくつかトラップがあるようだ。
1.初期パスワードは生年月日(西暦)の数字8文字。誕生日を和暦でしか覚えてないと詰む。
2.メールアドレスの認証処理がなく、どのメールアドレスでも登録可能な模様。ここだけガバガバな理由は不明。
3.パスワードリマインダーが実装されていないようなので、失念したら詰む。多分電話しないとダメ。
そしてどうやら1.から3.までは予約当日より前に設定可能で、当日はログインして4.マイページで待機していれば進めるようだ。そんなのどこにも書いてない。
推測だけど、各自治体のサイトが混雑でつながらないっての、1.2.3.を当日朝によーいドンでやってるからではないかと。そりゃ混雑するのでは。
選挙投票所方式で「mmddのHHmm-HHmmの間にXX会場に来てね、予定が合わない場合は連絡してね」で十分で、混雑したら空間をとって一人ずつ入場させればすむだろうに。
必要なところにリソースが投入されてなくて、コネとしがらみでどうでもいいところにカネが動いてるのだろうなと想像させる作りだった。
ドメイン駆動設計ってあくまで設計手法っていうかビジネスロジックのモデリングまでが本分だから
システムドメイン（領域）にビジネスドメインで履いていた土足のまま踏み入ってはいけない
※補足追記：基本設計したら詳細設計するけども、そこでビジネスロジックをシステムロジックに翻訳するからコードレベルでは一対一にはならないということ
概念の次元が違うのだから現実に漫画の理屈を持ち込むなっていうレベルの話（ビジネスが漫画レベルという意味ではない）
モデリングによって現行のビジネスの問題を洗い出し、それを課題として解決（仕事を楽に）するのがシステム
それも一回で終わりじゃなくてシステム化したビジネスを再びドメインモデル化して分析、課題をシステムで解決ってサイクルを回していかなくちゃいけない
システム側も細かいこと言えば領域が分かれてるからそれぞれの領域に合わせて駆動方法は変えなきゃうまく回らない。
データレイク周りならデータ駆動型の方が適しているし、逆にアプリケーション側でビジネスやUXを無視してデータ主体で走るのは阿呆の所業だし、
馬鹿の一つ覚えで〇〇駆動設計だの開発だの一本槍でパワープレイするやつが多すぎなんだよ！ 適材適所って理解しろよ！
ちゃんと各分野のスペシャリストを雇って意思決定層に組み込んだ方が結果的に時間や金なんかのコストが少なくなるよって話が通じないよね
なんせ全体像がわからない、検索ワードを知らないとたどり着けない。
UI/UXはずっと変わっているのだけど、デザイナーやアーキテクトの人は、その場その場で見て感じて判断しかしないのかと思ってしまう。
はてなスターは、ある程度気の利いたことが言えて、タイミングよくブックマークできれば、スターは簡単に集まる。
逆に言うと、時間を外しても、コメントがわかりにくい文体になっていると全然スターはつかない。
人気コメ常連であることが、更にスターが付きやすくなる条件にもなるが、それも最初の条件を守っていればクリアできる。
人気コメは人気コメになるだけの気づきを与えてくれることももちろん多いが、
それよりも、人気コメになりにくい時間にブックマークをしている冷静な意見を書いている人をお気に入りに入れた方が、何倍も気づきを与えてくれる。
はてな社は、人気コメのアルゴリズムをいじるより、もっとお気に入り機能を使おうと思えるUXにするなりなんなりした方がいいと思う。
はてブは頭のおかしな人も多いが、昔は無駄に相手の人格だけを攻撃して喜んでいるような、下種はそんなにいなかった。
サービスというものは、UI次第でどうしても居つくユーザが変わってしまう。
ここ数年の対立煽りの加速は、通報機能が面倒くさくなってから一気に加速したと思っている。
追記＞
RRD はてななんて、運転手が心肺停止して歩く程度の速さで中央線を越えるような車を見かけても平気でスルーするような、人でなしの集まりなんだから、そこでどう見られたからってなんの意味もない。
そんな話してない。
さすがに全然関係なさすぎる。人でなし以前に、人と会話する能力を得た方がいい。
追記２
「途中でブクマしてごぼう抜きするのが気持ちいいんじゃないか」（系の意見）
わかる。し、個人的にもそういうのは好きだ。
Slackのドヤ顔上から目線の広告もそうだけど、当時は全世界的にそういう空気だった。
モバイルOSやらarm向けOSやらで他社の模倣が大失敗していたこともあり、Teamsを有望視する声はあまり大きくなかったと記憶している。
結果論で言えば、TeamsがO365に含まれている時点で決まり切っていた未来だと言うことも出来るだろうが、同じ立場のYammerが今に至ってもうだつが上がらない以上Teamsの成功を説明するには不十分だ。
製品単独の機能比較で「Slackの方がUI/UXが優れている」というエンジニアから上がった声とは思えないようなふわっとした優位性が語られることは多い。
しかし、Teamsの優位性は「わざわざ別のサービスを買ってインテグレーションをしなくても様々なサービスがはじめから連携している」事にある。
コレの重要なポイントは「サービスを作った会社自身がインテグレーション部分も含めて正常動作を保証することが契約に含まれている」ということだ。
Slackと各種サービスを組み合わせて同等の価格で同等のサービスを提供するベンダーがいたとしてもその点だけはTeamsに太刀打ちできない。
企業の収益の観点からすればMicrosoftにとっては顧客がO365を買ってくれていればチャットツールにTeamsを使おうがSlackを使おうが収益の観点から損はない。
しかし、SlackにとってはSlackの代わりにTeamsを採用されたらその分の収益が見込めない。
そもそもが競合というにはあまりにも一方的な関係であるわけだ。
Microsoft社内のTeams開発チームにとってみれば確かに最有力の競合ではあるんだろうが。
ここ最近Slackは「TeamsがO365に無料でついてるなんて卑怯だ」と主張するようになった。
Teams発表当初のSlackユーザーにタイムトラベルしてこの状況を伝えても鼻で笑われること必至な状況だ。
しかし、TeamsはO365の各種サービスのパーツを寄せ集めて上っ面を整えただけのサービスなのでホントにO365のおまけ程度のサービスなのだ。
チャットメッセージはExchangeの各ユーザーのメールボックスの隠し領域に保存されてるし、チーム用のストレージはsharepointサイトだ。
クラウドPBXなどの有償オプションはあるが、Teams利用に必須ではないし、むしろ存在すら知らない組織の方が多いだろう。
専用のリソースがないわけではないが、それもAzure向けに大量確保しているリソースを流用するだけだ。
チャットツールに関するリソースをすべてそのためだけに調達しなければならないSlackが太刀打ちできるわけがない。
調達の共通化によるボリュームメリットを否定するならそれは資本主義の否定だ。
同一分野のツールである以上、完全に無視するのは愚策であるとはいえ、今のように必要以上にTeamsを意識した戦略はコストの浪費に他ならない。
Teamsの牙城は元々O365の牙城だっただけで、Slackから奪ったわけではない。
既に従業員一人あたりでSlackと同額かそれ以上のコストをかけてる企業に「優れたチャット専用ツールのためにもっと金出してください」と呼びかけたところで、それに応じる企業はそんなに多くない。
PV乞食がSlackとTeamsを並べて囃し立てるから「つかめたはずの客を奪われた」ように錯覚させられるかも知れないが、Teamsが囲った客にSlackがつかめたはずの客はホントにいたのか？
Slackは元々「チャット専用ツールのために金を出す」というブルジョワ企業のためのサービスとして成長してきた。
フリーミアムで客を囲ってはいても最終目的はチャット専用ツールで収益を上げることだった。
だったらTeamsに対しては競合の一つ以上に注意を払わず数少ないブルジョワ企業のために動くべきではなかったのか。
そう思っていたら、SlackはSalesforceに身売りしてTeams対抗路線により明確にフォーカスしていくようだ。
SalesforceがGithubに対するMSのように「太っ腹で放任主義なパトロン」のような立ち位置に納まってくれれば良いが、既にチャットツールとして組み込むとかそういう話も出てるのであまり楽観視は出来ない。
next.js が vercel を提供して CDN からサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。
それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。「とにかくフロントエンド領域しか絶対にやりたくない」という人が沢山いるが、しかし一方フロントエンドで無理しないでサーバーを書くだけで楽になるようなタスクはいくらでもある(典型的には API たくさんアクセスするとか)。
そうしたときに、フロントエンドメインだがバックエンドも書けるみたいな人がそういうサーバー忌避患者を介護する層として BFF の需要があり(無論それだけが BFF に求められるのではなく認証などの要素も大きいが)、サーバーサイドレンダリングというタスクもあるため node.js で何らかのサーバーが書かれていった。
アイソモーフィックな JS によりフロントエンドとサーバーサイドを統合する、という試みはこれまであまり成功しなかったので(結局どっちにも詳しくないといけないから正しく書ける人がすくない)、 next.js の getStaticProps や React Server Component は「サーバーサイドだけで動くコードを見た目上フロントエンドのコードの中に含める」という解決策を提示した。
ここまでしないとフロントの人がサーバー側を書いてくれないという現実は、あるわけですよ。「そんな奴言って聞かせりゃいいじゃねえか」とか思うかもしれないけど、これが現実。これが全てという話でもないけど、わりとこんな話が大きいように僕には見える。
起きていることはそういう話なのだけど、これはけして JSP 時代への先祖帰りではなく、この進歩の先にはサーバーとクライアントを跨いで快適な UX を誰でも簡単に実現するという未来が、もしかしたら今回こそ実現できるかもしれない、と僕は思ってます。
Apple M1の高性能の理由について、ネットはクソみたいな解説記事に溢れている。
技術に明るいはずのはてなーですら某AVライターの間違いだらけの記事に釣られて、300ブクマ超が集まっていて嘆かわしい。
それもこれも後藤センセーがいつまでたっても解説記事を書いてくれないせいではあるが、公開情報が少なすぎるせいでまともなライターほど記事を書けないのも理解できる。
違います。
そもそもM1はDRAMをSoC化／ワンチップ化していません。M1がやっているのはSiP(System in Package、複数チップをワンパッケージに組み込む）であって、eDRAMによるSoCとは全く異なるものです。
SiPとSoCはJavaとJavascriptくらいには違います。
違います。
HBM系のメモリを採用していたらメモリ帯域は大幅に向上しますが、M1は標準DDR系メモリをワンパッケージ化しているだけなので、帯域もレイテンシも変わりません。
帯域はM1 MBPとIntel MBP(Ice Lake)でチャネル数同じ、前者はLPDDR4X-4266、後者はLPDDR4X-3733なのでメモリ帯域は14%しか向上していません。また、x86／x64最新世代のTiger Lake／ReniorはLPDDR4X-4266に対応しています。レイテンシはM1が96.8ns、Tiger Lakeが98.4nsでほぼ同等です。
Apple M1の実力を最新世代のIntel/AMD CPUと比較。M1が両者を大きく上回る結果ににあるように、SiP化によって消費電力の削減は期待できます。
違います。
SoC-DRAM間がマザーボード上で30cmあったとしても、電気信号の伝送にかかる時間は片道1nsです。仮にSiP化で物理的距離が1/100になったとしてもレイテンシ100usが98.02usになるだけで、CPUにとってDRAMが絶望的に遠いことに変わりありません。
違います。
まず、同一チップ上のCPUとGPUが同一のメモリーコントローラ／DRAMを共有するという意味では、Intelは2011年のSandy Bridge、AMDも2011年のLlanoからUMAです。一歩進んだメモリ空間の共有、コヒーレンシの確保という意味でも、AMDは2014年のKaveriから対応していて、この点においてM1に革新性はありません。
違います。
上記のSandy Bridge、Llanoの世代からかつてのノースブリッジがCPUに取り込まれたため、2011年以降のモバイルPC向け”CPU”のほぼ全てにはGPU／メモリーコントローラが含まれています。
かつてのサウスブリッジはIntelは今でもワンチップ化こそしていませんが、2013年のHaswellからMCMでワンパッケージ内には収められています。AMDは2014年のCarrizoからサウスブリッジ機能もCPUに取り込まれています。
この意味で、x86／x64のモバイルPC向け”CPU”は、かなり以前からSoCです。
違います。
NPUを活かせるアプリケーションは2020年現在では未だ限定的です。もしNPUの有無によってUXが決定的に改善されるなら、NPUありのSnapdargon 8cxを積むSurface Pro Xは同世代のSurface Pro 7よりずっと快適でなければなりませんが、そのような事実はありません。
違います。
CISC／RISCの論争は20年以上前に終わった話です。その後CISCはRISCの美点、RISCはCISCの美点を取り入れたので、現代のCPUはISAがCISCか／RISCかだけで性能が決定されることはありません。
歴史的経緯からx86／x64のデコーダが複雑になりがちなのは事実ですが、5W以下のローパワープロセッサの開発へ向かうIntelにあるように、ISAの差による消費電力増は10～20%のレンジで、さらに性能増によって相殺される分、電力効率の差としてはわずかです。
頑張って最適化してIPC上げたのと、スマホ由来の積極的なDVFS・クロックゲーティング・パワーゲーティングで浮いた消費電力を回しているからです。
気が向いたら書きます。
12月3日に出たライザのアトリエ2 〜失われた伝承と秘密の妖精〜を遊んだ。
しょうがないとは思っている。
1年で納得するようなクオリティの続編を出せと言われたら無理だろうと思う。
その意味では時間が全くないのによくやったと褒めるべきだろう。
・また結局異界とフィルフィサのお話、ラスボスはまたちょっと違う大物個体のフィルフィサ
→新しく見つかった別の異界の門を封じてストーリーエンド（前作と一緒）
→ストーリー途中で魔獣に乗れるようになるのだが、魔獣に乗ってるとフィールドを掘れるようになりそこから重要な素材がランダムで出て来る（素材は各ダンジョンで変わる）、逆にフィールドに配置されている採集場所は序盤中盤とほぼ一緒で採集する価値がない飾りになる
・魔獣で素材を掘り起こすため、あの素材どこで取れるっけ？を忘れやすい
・仲間が人生の目的を見つけて将来の行動や夢を持って進んでいるのに、主人公であるライザが前作で錬金術師になったと変化があってから進めてない
→自分の将来の夢や目的を見つけてないので2の舞台でやることを達成したら故郷の島に帰る、周りの仲間と比べてこいつ何にも成長してないなという感じが強い、主人公のくせに停滞している
・ストーリークリア後の裏ダンジョンがない、クリア後のやりこみがしょぼい
→裏ボスは解禁される、またクリアデータで最初から周回できる（装備など引き継ぎ可能、高難易度が解禁される）
・ストーリーは謎の石（実は卵）から生まれた謎の生物フィー（正体は異界の精霊）の調査からはじまってフィーが異界の生き物であるためライザたちの世界では摂取できるモノが乏しく生きていけずどうにか元気にするためにフィーが食べられるものを頑張って探す話だ。結局フィーのために食べるものを探してたら誤って、古代人の工夫によって封鎖されていた異界の門を解放させてしまった。そこから出てきた大物個体フィルフィサをやっつける。フィーの食べ物の問題は解決できなかったので門から異界に行かせて、そこでならフィーの食べるものがあるので異界で生きていけとお別れして門を封鎖する。それで終わり。
→普通はストーリークリア後のやりこみとして異界に行ったフィーに会いに行けるように錬金術でチョメチョメするために頑張るとかそういう展開になるのだが、とにかくフィーがいなくなってそれで終わり。ライザもやることがなくなったので故郷に帰ると言って閉幕。
ガッカリポイントを言うだけだとフェアではないのでグッドポイントも言っておく。
・バトルがさらに派手になっている（数少ない改善改良ポイント）
・前作よりワンランク上の素材が出てる
→前作はゴルドテリオンが最上級の鉱物系素材だった。今作はさらにワンランク上のグランツオルゲンが出ている。
→細かい差異は変わってるが本質的には前作のやりこみと同じことをやってる
Switchのヒューマンリソースマシーンっていうゲーム知ってる？
https://note.com/keigox68000/n/nb3b536465f00
わたしはUI/UXデザイナーなんだけど、大学のとににプログラミングの授業があったりしたのでちょっとだけわかる(ほんとにほんとにほんとにちょっとだけ)
最近デートしてるエンジニアと家でゲームして遊んでたんだけど、ヒューマンリソースマシーンを買ったままやってないことに気づいて一緒にやった。
中盤まで自力で解いて、2.3個教えてもらいながら解いて(ここは、最高だったな。その人がいつもの何億倍も知的に見えた)、そのあとはその人が一人で問いてた。
わたしからしたら全てのエンジニアはわたしにできないことをよくわからない感じでやってるすごい人！みたいなイメージだったんだけど、中盤ちょっと行ったところで、その人がクリアできなくなったのを見て、全然できないじゃん！！！！ってなった。
クリアできてなかったのは、
二つの数字を比べて、どちらも正or負の数字の場合0を、異なる数字の場合1をアウトプットに出すっていう問題。
ソートのアルゴリズム思いつかないから解けないとかならわかるけどさぁ
あとは、普段は問題に出てくるようなアルゴリズムがあらかじめ言語ごとに用意されてるとかもあるだろうけどさ、
でもこの上に書いた問題解けないってエンジニアに重要な考える力弱くない？って思った
すなわち仕事の能力低い人なのかなって思って、めちゃくちゃ優しいけど、めちゃくちゃ萎えた🤷♀️
追加
