  |
はてなキーワード: カウントアップとは
12とか60とかでひとまとまりとする単位が使われるのは、約数が多いからというのが理由。1、2、3…とカウントアップする使い方だけでなく、1/2、1/3、1/4…みたいに大きなものを分割する使い方が多いときに便利。10進だと2分割か5分割以外は整数にならないが、12進だと2、3、4、6分割が整数。60進だとさらに5分割も整数。角度なんてその最たるもので、1周を半分にしたり6等分したりする使いかたが便利だから約数が多くなるように1周=360度とする。1箱10個入りの商品は、箱に1x10か2x5のどちらかで箱詰めすることになる。1個の形がどんなものかによるけど、2x5でもだいぶ細長い形になることが多くなって扱いづらい。12個入りなら、1x12、2x6、3x4に加えて、さらに2x2x3という3次元的な詰め方もできる。だから1ダース=12個。
僕は29歳、年収約450万円、地方県立大卒で都内在住の放射線技師。身長164センチのガリガリでこれまで彼女もいない非モテだったことから恋愛や結婚にはおよび腰だったし、プライベートでも職場でも恋愛方面の会話になると逃げていた。当然素人童貞。
しかし、本当は恋愛もしたいし結婚もしたい。その欲求から逃げ続けて後で後悔するのも嫌だなと思った。技師や薬剤師、看護師や理学療法士などの同僚の中ではすっかり「恋愛にも結婚にも興味がない男」と認知されゲイ疑惑まで出ているので今更職場での出会いはない。社会人サークルなどに入ることを考えたが女性目当てでサークルに入るのはどうかと思うため断念。マッチングアプリはマッチ率が低く、マッチしても会えずに断念。よく考えれば、この歳で自分を棚上げして恋愛だなんだと言うのもおかしいと気がついて結婚相談所に行くことにした。
調べた結果、様々な媒体での口コミが評判良く、職員さんのTwitterでの印象が丁寧そうでよかった所に決め、先週の休日に向かった。結果を先取りすると相談所に入ることなく撤退した。
相談所のあるビルに入ろうとしたら自分の前にも女性がいて、同じエレベーターに入った。同じ年くらいの綺麗な女性で僕よりもかなり身長が高かった。その女性は相談所の階を押すと、ゴミを見るような目で僕を見て冷たい声で「どこですか？」と聞いてきた。僕の精神はそこで限界になった。このビルでこの時間に空いているのは相談所含め３つほど。１つはダーツバー、もう１つは男性が入ることはない類の店。この女性はこれまで良い縁に恵まれず、藁にも縋る思いで結婚相談所に来たのではないか、それにも関わらず相談所の入り口で見るからに相談所に来たと思われる非モテのチビを見て嫌悪感を催しているのではないか、と思ってしまった。
僕は咄嗟にダーツバーの入っている階をお願いした。これは完全に僕の思い込みだろうが、心なしか女性が安心したような気がした。ダーツバーに入るとオレンジレンジのYamatoに似た店員からダルそうに迎えられ、会員登録してから一人でダーツを始めた。昼間で他に客もおらず店員も暇だったのか対戦しようと言われ、カウントアップ、01、クリケットをそれぞれ数回ずつプレイ。当然負けて店員にビールをご馳走した。店員と車や服、学生時代の話をし、それからもう一度対戦し、二杯目のビールをご馳走。自分も一杯注文し、飲みながら店員、後から来た麻原彰晃似の店長、常連のサラリーマンらと話して帰宅した。
女性のゴミを見るような目で自尊心を砕かれたという悲しかったことと、通えそうな良いダーツバーを開拓したという嬉しいことが同時に起こった休日だった。
最近は自分の技術力じゃ太刀打ちできないアプリゲーばかりで離れていたんだけどシャニマスで復活した。
やっぱりゲームの自動化のプログラミングって純粋に楽しいんだよね
工夫と努力で手間が大幅に削減できる
楽しみながら作れるからプログラミング超初心者はやってみたほうがいいと思う。
楽しみながら基礎を学べるんじゃないかな。
まあ規約違反だけど。
そんなに悪質じゃないんじゃないんですかね。
ちなみに自分は昔ながらのUWSCを使うタイプで、VMwareの中で動かしてます。
（Virtual PCを使った時もあったんだけど、タイミングが安定しなかった）
フェスは若干めんどくさくて、メンタルの残量によってゲージが変わるからそれに応じてタイミングよく叩く必要がある。
調整しまくってかなり白が細くても大体パーフェクトとれるんだけど
PCの調子によってずれるんだよね。CPUの利用率というわけでもない感じで割と謎
自動でずれを把握して調整するまで作り込めればいいんだけどそこまではできてない。
ライブスキルも適当に選んで叩いてるだけなので、大して強くはない
思い出はキラキラしてるから判定し難いんだよね。色で判断してるからああゆうのは苦手。
あと体力減ってチカチカするのも勘弁してほしい。
帰宅して止まってたら、手動で伝説の一瞬を狙うけどフェスマスまで取れるのは極稀
フェスの自動化はだいぶ昔に書いたからもっと改善できそうだけど
プロデュースのほうは、最初は休みを連発してＦアイドルを量産するしかできなかったんだけど
WINGはオデマス編成で最弱オデを連発して決勝までいけるようにした。
TRUE取りたい時はシーズン３で止めるようにして、そっからは手動でファン稼ぎ
ただ時間はすごい掛かる。
Ｐカップ勢を真似てアピール直後にリロードするようにしたけど、あんま効果ないみたい。
最新作は感謝祭。これはついこの間できたばかり。
やり方としては、5色揃えた編成で開始するのが前提で
・お手伝いはVoのみ
・すべてのレッスンとお仕事を巡回してアイデアの埋まり具合をチェック
体力見て適宜お休みを入れつつその繰り返しという感じ。
やっぱり面倒くさかったのは後半で
まず現在を位置を判断して、目的地に最短で移動するための関数を作った
それを使ってレッスンとお仕事６箇所を順番で巡って、アイデアの埋まり具合をチェック
アイデアの埋まり具合は、地道に埋まったときの色を調べてVoのノートならはづき含めてほぼほぼ判断できるようにした
アイデアは点滅しやがるので、３回チェックするようにした
（たまに漏らすが許容範囲）
チェックしたアイデア数は逐次配列に入れて、最後に一番埋まり数が高い場所を判断して
そこでレッスン/お仕事実行
これでサクサク星１を３冊、星２を２冊埋めてくれるので今後はミッションがだいぶ楽になりそう
ついでに振返りまでやってくれると便利なんだけど
編成によって変わる部分が多すぎてちょっと手は出せてない。
たまに気づいたときに手動でやる程度
②画面の特定の位置の色を調べて想定通りならTRUE返す関数を作る
③上の関数の結果に応じて、マウスクリックなどのアクションを行う
これが基本
②と③をいっぱい並べて思い通りの動きを実現する
コツとしてはどこで中断しても再開できるように作る
（状態をフラグを管理するのはできるだけ避け、その画面の状況から判断する）
画面の色の判断は完全マッチではなく、色の範囲でマッチングさせる
（シャニマスは定期的に画像を生成しなおしているらしく、ドットレベルだと色変わりが激しい）
これは、気づいている人も多いけど、検査の不足が一部にある一方で、過剰に検査を要求している人も多数いて、両方を分けて議論をして、両方とも改善しなければいけないという話。
検査不足については、高山義浩先生（岩田健太郎教授のプロレス？相手）も「これまでの積極的疫学調査（感染者の接触者を追跡する調査）の結果をみると、このウイルスの感染力は必ずしも強くはありません。少なくとも、インフルエンザほどは強くない。」「私たちは封じ込められる可能性を捨てるべきではありません。」と語っている（https://www.facebook.com/100001305489071/posts/2716494688404021/）。封じ込めるためには、感染者を確定診断し、その濃厚接触者を追跡・隔離することが何より重要であるにも関わらず、死亡後に感染確認という例があったり、検査忌避に関する報道が多数あり、後述する検査キャパ改善が遅々としている点は問題であり、何としても改善すべき話である。
現状において、風邪症状のみで濃厚接触者でもない人が検査を求めるのが害悪でしかないという言説は、確かにその通りであり、啓蒙が必要であると考えるが、良い記事があるのでリンクを紹介して省略する。（新型コロナ、なぜ希望者全員に検査をしないの？ 感染管理の専門家に聞きました/https://www.buzzfeed.com/jp/naokoiwanaga/covid-19-sakamoto)
検査キャパについては、これが不足しているがゆえに検査不足があり、改善すべきと考える。積極的な検査数抑制は不正告発が容易な日本社会においては、ほぼないと考えるが、検査キャパ不足が改善がなされないのは行政の不作為であり、追及すべき段階と考える。（当初は、「武漢市への渡航歴」とか「武漢市への渡航歴があり、発熱かつ呼吸器症状を有する人との接触」など検査対象に制約があって、それも問題であり別増田で指摘したりもしたけど、そこは改善した https://anond.hatelabo.jp/20200210110528）
では、なぜ検査キャパが後述の大臣発言もあるのに増えないのか。この件は、１）受け手側の機器・検査要員の限界、２）輸送手段の限界 ３）院側での梱包発送 という問題があり、全てクリアにならないと検査が実施できないという３点があり、さらにはその限界を超えないように見通して、優先順位をつけ、検体受入れ可否も含めた調整も必要であること。
また、大きな要因として検体を量産していたダイヤモンドプリンセス号も含めて、検査需要があるエリアが偏っていて、稼働率が極端に低い都道府県と、極端に高い都道府県があることは容易に想像でき、日本全国での検査機器のキャパを母数として稼働率を見ても、そうそう上がらない状況にあった可能性は高い。
特定病原体を含むかもしれない検体の輸送は、梱包受け渡しにせよ、輸送業者の体制にしても厳格な決まりがあり、末尾にリンクを貼るが、そう簡単に民間委託キャパを増やせず、結果として保健所職員などの自治体職員の人的リソースの枯渇もあると考えられるし、長距離輸送も困難を伴うことになる。この点は特例的な臨時許可業者を検討したり、自衛隊の災害出動をかけるべきと考える。
また、東京都や愛知県内などの一部の保健所・衛生環境研究所では、人的リソース不足があるのは明白で、DMATでも自衛隊でも県庁職員でもいいし、その他大学の教育者・研究者・技官でも良いので、応援人員の動員を検討すべきである。
加藤厚労大臣は、国会答弁で18～23日の検査件数の内訳を明かし、その内容は18日996件 19日672件 20日656件 21日1594件 22日1166件 23日675件とのことである。この検査数はダイヤモンドプリンセス号、武漢帰国者チャーター便の搭乗者を含む可能性は高いが、両者ともにピークは超えている日程と考えられる。
一方で、「新型コロナウイルス感染症の現在の状況と厚生労働省の対応について」と題して、ほぼ日次で厚労省がWeb上で報告している文書によると、「２月25日18時時点までに疑似症サーベイランスおよび積極的疫学調査に基づき、計1,061件の検査を実施。そのうち147例が陽性。」とある。同文書時点の国内感染者数は160名（含む無症状者・除くDP号とチャーター便帰国者）であり、陽性者数と国内感染者数に大きな乖離はないので、市中の検査においては、1,061件がほぼ国内検査全数であるように読める。
一番さかのぼれる「１月27日12時現在 計14件」から約1カ月を経過して、1,061件しか検査してないという説明は、加藤大臣の答弁とも大きく乖離してており、どちらの数字が正しいかにより、検査不足の度合は大きく異なる。マスコミならびに野党各位は、「1日約3800件の検査が可能と説明していた」のになぜ「1日平均約900件」というピンボケな指摘をやめて、厚労省Webと大臣答弁の数字の差異こそ追及して欲しい。
なお、厚労省Webの数字は一部韓国紙にも参照されていて、間違いがあるのならば国際的な誤解を解くためにも訂正が必要であり、一方で大臣答弁に虚偽や欺瞞があったとすると、実態として1カ月でわずか1000人ちょっとしか検査していないということであり、国家総力をあげて改善すべきであると考える。
加藤大臣答弁の数字について、１つ仮説を述べておく。厚労省が出している検体採取に関するガイドライン（リンク末尾記載）によると、1人の患者から2検体「下気道由来検体（喀痰もしく䛿気管吸引液）」「鼻咽頭ぬぐい液」を検査することになっているが、それを２件とカウントし、同一患者からの経時的な検体も個別にカウントアップして検査数としている可能性を指摘しておきたい。
他に検査数・陽性者数の差異として、DP号下船厚労省職員や検疫官を中心に、一部「疑似症サーベイランスおよび積極的疫学調査」のいずれにも該当しないものの、検査を実施し、一部陽性となっているものがあることは予想される。
「自宅待機しろって言うけど、家族への感染は許容しろってことか？」という発言も多い。これは一理ある。この観点からは課題は２つあり、隔離場所の確保と、隔離に際して誰をどこへ隔離するかの優先順位付けの問題とに分かれる。この隔離優先順位付けのために、PCR検査をもっとすべきという意見は一面では正しいが、以下の観点から現状では軽症者は避けるべきという話になる。
・日本国内の流行がそこまでではなく感染確率そのものが低いこと
・PCR検査をするために病院へ出かけることが感染リスクを高めること
家族への感染リスクは、現状ではそもそもの感染確率が低いところから許容すべきではあるが、より流行が拡大した場合などは、もう一方の課題、「軽症の疑い者」の隔離場所の確保という観点も含めて対応すべきであろう。その場合はインバウンド激減となっているホテルの一棟借り上げとかも想定されるが、その施設のスタッフの防疫も考えると、むしろ「軽症の疑い者」の家族を、普通に宿泊客としてホテル等へ避難させ、当人を自宅隔離する方が簡便だと考えられる。
地場の観光産業を救う意味にもなるし、補助金を積んで「軽症の疑い者」の同居者に感染リスクを回避したい高齢者、基礎疾患がある高リスク者、もしくは受験生などがいる場合、リスク回避する家族が、ホテル・公立宿泊施設・公営住宅の空き部屋などを比較的安価に利用できるようにすれば良いと思う。自宅に要介護者がいるケースなどは、例外対応的な、病院未満の隔離先もあればなお良い。
そこまでの事態にならないといいんだけどね。以上。
最近大騒ぎになっているIntelなどのCPUレベルの脆弱性、MeltdownとSpectreについてメモ。最初はキャッシュ内のデータを読み取るのかと勘違いしていたのでその点を中心に。
・CPUによってアクセスが制限されているはずのカーネル領域データへのアクセスがアウト・オブ・オーダー実行(OoO)で動作してしまうことがある(Meltdown)
・OSによってアクセスが制限されているはずの別プロセスのユーザー領域データへのアクセスが投機的実行で動作してしまうことがある(Spectre)
ただし
・OoOや投機的実行でアクセスが制限されている領域へのアクセスが行われても、ソフトウェアがアクセス可能なレジスタやメインメモリ上の値は、OoOも投機的実行もないCPUと変わらない。MeltdownとSpectreでこの原理が破れたわけではない。
・キャッシュにはアクセスできない領域のデータが入っているかもしれないが、ソフトウェアから「L1キャッシュのn番目のデータを読む」といった操作はできないし、実のところMeltdownとSpectreではキャッシュにどんな値が入っているかは関係ない。
そこで、OoOや投機的実行でアクセスが制限されている領域へのアクセスが行われている間に、次のような処理が走るようにする。
a = *kptr; /* kptrはアクセスが制限されている領域へのポインタ */
b = array[a<<12]; /* 配列arrayは自プロセスの領域。12ビット左シフトはハードウェアプリフェッチャによる先読みの影響を防ぐため。 */
参考:
hiuchidaさん 「MeltdownとSpectreの違いについて分かったこと」
https://qiita.com/hiuchida/items/2248b379197a5052029e
品川高廣さんのツイート
https://twitter.com/utshina2/status/948809945327157253
配列arrayは自プロセスの領域内なので後から問題なくアクセス可能。変数nをカウントアップしながらarray[n<<12]のアクセス時間を順次計測すると、array[(*kptr)<<12]はキャッシュに残っているのでアクセス時間が早い。これによって*kptrの値が推定できる。
つまり、キャッシュに入っている値そのものではなく、あるアドレスがキャッシュされているか否かという形でOoOや投機的実行中の一時的な値を記憶させてしまう。
最近の回転寿司はどこもタブレットで注文して専用レーンで運ばれてくる
この前行った寿司屋も同じだったんだが，注文してから１０分とか２０分経っても全然来ない
一応，嫁が食べるあら汁と息子が食べるうどんは来たんだけど，俺が頼んだあおさ汁と１０皿ほど頼んだ寿司が全く来ない
「どの注文が来てませんか？」
と逆に聞かれてビックリした
そんなもん，テーブルの番号があるんだからそっちで把握できるんじゃないの？と思ったが
しばらくしたら帰って来て
「すぐにお持ちします」
とのことだったのでしばらく待ったら寿司が続々とやってきた
ただ，あおさ汁は来ないで代わりにあら汁とうどんを持ってきたので
「あら汁とうどんは来ていて，あおさ汁が来ていない」
っていうのを伝えた
このときはまだ「ああ，否定表現で伝えたのが良くなかったかな」とか思ったけど
次にしじみ汁とあおさ汁持ってきて流石にちょっとあきれてしまった
（ついでに言うと寿司も2種類ほど来なかったので再度店員に伝えたりした）
ここで，普通にiPadを導入しているような店舗のシステムを想像すると
ところがそこの店はそういうシステムではなさそうだ
そういうシステムならテーブル番号を伝えれば握っていないタスクをこなせばいいだけだからだ
そしてiPad上に「タスク完了」を示す何らかのフィードバックがあっても良い
しかしiPadの注文履歴を確認したがそういったステータスの確認はできなかった
2. タスクとしては管理されておらずただ画面にテーブルと注文が表示され
3. 他の注文が入ってくると表示している画面からは追い出されてしまう
つまりタスクがどこまで完了したかどうかは握る寿司職人の頭の中だけで管理されている
だから「注文が来ていない」というクレームに対してはiPadを持って行って「これとこれが来ていない」と伝えないといけないし
あおさ汁が来ていないのに平気であら汁とうどんを持ってくる
昔のように回転寿司の中にいる職人さんに口頭で注文を伝えていた方式を
ただiPadを使ってバックヤードに伝えているだけに過ぎないわけだ
この手の中途半端なシステム化がこの国には本当に多いと実感する
皿を回収口に投入するとカウントアップされ
現状の「仕事のやり方」をできるだけ変えずに
ほんの少しだけ便利に（ときには不便になるが）するためにIT化が行われる
この理由は明白で論理的な思考や状態遷移・管理に関する考え方に乏しいからだ
一番苦労したのは「タスク」という考え方の浸透だった
そういった考え方がそもそも無いからタスク管理ツールの導入にはえらく手間取った
こうした教育コストを払わずにIT化を行うからこの手の中途半端なシステムが導入されるんだと痛感している
小学生の子供にタブレット用アプリを自作した。別に大したものではない。
ボタンをタップすると二桁の整数の四則演算式がランダムで表示され、電卓を模した入力フォームに正解を打ち込むと、画面端の正解累計数がカウントアップされるだけのアプリだ。
そしてこれは子供には秘密だが、回答を打ち込んで送信ボタンを押した際、問題内容、子供の回答、正解したかどうか、回答にかかった時間(秒単位)といった情報がNASにログとして保存されるようになっている。
「お父さんかお母さんが見ていてあげるから、これを1,000回正解しなさい。それが出来たら、欲しがっていたゲームソフトを買いに行くよ」
「ズル」が出来ないよう色々と工夫をした。
簡単な問題が出るまでボタンを連打されないよう、強制的に一定秒数のインターバルを設け、さらに一定回数連続で間違えたら強制的に終了し、俺や嫁が復旧手順をとる(回答欄に解除コードを入力)か、日付が変わるまで再開出来ないようにした。
タブレット自体も厳重に保管し、俺か嫁の監督下でしか触らせない運用にした。当然、このアプリ以外の用途には一切使用禁止。
一日三十問として一ヶ月以内に達成出来れば上出来かと思っていたら、なんと一週間で達成してきた。子供の集中力ナメてた。
しかも、「今度欲しい物が出来た時のために今のうちに練習する」と、ノルマも何もないのにあのアプリを使わせろと言い出してきた。
