「使用」を含む日記 RSS

はてなキーワード: 使用とは

2022-01-28

anond:20220128185914

北朝鮮弾道ミサイル核兵器能力を整備していますが、あなた北朝鮮はそれらを使用しないと思っているんですか?

逆に聞くけど、憲法9条を堅持すれば北朝鮮はそれらの使用やめるの?

そばドライブマイカースケール

anond:20220128081119

竜とそばかすの姫  越知町高知県高岡郡から 田園調布 夜行バス使用 夜行バス横浜YCAT バスタ新宿 東京鍛冶橋のいずれか着で 800キロメートル強 

渋滞なしで10-11時間Google調べ)



ドライブ・マイ・カー 上十二滝村は架空地名なので ①原作小説初出と同じ中頓別町とすると または ②北海道南端 とすると

仙台回ると2200キロメートル強、(日本海新潟秋田回ると2100キロメートル前後) 渋滞なしで29時間Google調べ)

函館駅裏として1500キロメートル前後渋滞なしで22時間Google調べ)

往復 3000-4500キロメートル不眠不休フェリー待ち時間ゼロで45時間かかる。距離だけならルート66全長(4000キロメートル弱)といい勝負だ。

とは言え、移動は往復でも、中頓別から電話広島国際演劇祭のプログラマー柚原(演:安部聡子)に電話すればいいと考えれば29時間以内でクリアできる。

アベノマスク配布

これ、「感染症対策のため不織布マスクをしてください」とお願いしても「あ?国が配布してるマスクだぞ!何か文句あるのか?」で性能の低いマスクを使う輩が出てくる悪手なんだよなぁ。

「当時は緊急性を鑑みて布マスクを配布しましたが、その後の研究の結果、不織布マスク効果が高いことがわかり、また供給も十分にされているため、今後は布マスク使用しないでください」とか言ったほうがまだマシだよ。

基本的に何が問題かと言うとウクライナがどうなろうと欧米の知ったことではない、ということなんだよな。

欧米各国は、あのへんの地域ロシア縄張りだと思ってるし、

クリミア半島ときロシアクリミアを手放すなんてことありえないと、

ある意味ロシア以上に理解しているから形ばかりの抗議で終わったわけだし。

 

ウクライナ民主的政権になるか、

ロシア傀儡政権になるか、なんてどうでもいいんだよ。

つーか、親ロシアデフォルトだと思ってるわけだし。

 

ただ歴史的視点でいうと

こういった黙認行為がやがては大きな大戦へと

繋がっていった、というのが第二次世界大戦だった。

果たして歴史は繰り返すのか、核の抑止力機能するのか。

 

と、考えると戦争になってもお互いに核兵器使用しない、

という条約を結んだりしたら、それはヤバい、ということでもある。

買える冷蔵庫が無かった

十数年使用した冷蔵庫が壊れそうなので、新しい冷蔵庫を買いに電気屋に行った。 

我が家は氷を使わないので、製氷機にスペースを割いてほしくない、これでまず買える冷蔵庫が大幅に減る。

チルド室狭くして水を入れたり、引き出し一つ丸々氷コーナーだったり。いらん。

今はチルド室が二段になっている形が多いようで、焼肉セットなど分厚い肉の容器を入れられそうにない薄っぺらいチルドルームが多い、これも不便そうで買いたくない。

背が低いので高さは175以下で容量は最低350リットルは欲しい、これがもう絶望的にない、どれもこれも180センチオーバー、前回は高くない冷蔵庫沢山あったのに、何でそこまで大型化したのか。

野菜室は白菜大好き人間なので白菜を丸ごと立てて入れられるスペースがほしいが、これも意外とない。

ペットボトル飲料なんて飲まないのに、野菜室にわざわざペットボトルを立てるコーナーを壁で区切ってる冷蔵庫である、いらん、自由野菜を入れさせろ。

前回買った時からAQUAかいメーカーが増えていたので店員さんに聞いたら、SANYO技術者中国メーカー事業譲渡されて作ってるメーカーらしい、なんか切ない。

結局何も買えずに帰ってきた。

何か買わないといけないのに本当に困る。

2022-01-27

20年以上前ウォシュレットが怖い

まあ子供だった俺が全て悪いんだけど。

我が家にはトイレが二つある、1階の皆が使うトイレと2階にある今は俺しか使わないトイレだ。

中学生の時はじめて我が家ウォシュレットが導入されたが、俺は尻に水を当てるとか怖くて一度も試さなかったし、使う気にもならなかった。我ながら中坊の癖に好奇心が足りない。

つのまにやら家族は基本1階のリビングで、俺が2階の自室に引き籠もるようになってトイレの専用化が発生した。この頃から俺の趣味トイレ掃除が加わったが今回の主題から逸れるので割愛する、一言だけ残せば手間を省けばトイレ掃除は楽しくて気持ちいい。

閑話休題それから数年後、電気節約のためにトイレ使用後に蓋を必ず下ろすようにしよう、と父親が言いだした。

当時の俺は普通に面倒だから嫌だと感じたし、手間を惜しむ為なら多少の不便はどうでもいいという思考を持っていた。

ので、便座のコンセントを引っこ抜いた。

どうせ俺しか使わないし、便座冷たくても耐えられるし、節約にもなるから文句あるまい、と思ったし、事実強くは言われなかった。

それから20年。

いや、ウォシュレット初体験のものは4、5年前だったかな? 理由はもう忘れたが、外出先、どこかの店舗にあった綺麗なトイレでさ、ふと思いつきでウォシュレットを使ったんだ。

いや最高だなウォシュレット

尻が楽に綺麗になるじゃん、これは文明の利器だよ、使わないのは損だ。

と思ったものの……さて今さら自宅のウォシュレットに電源入れるか? 入れたとして20年ほったらかしの管を通って飛び出す水を尻穴に当てたいか? と自問自答するとどうしても拒否反応が出る。

から言いたいのは無闇に手間を惜しむなということと、好奇心を持つことは大事、そして無駄な意地は張らないほうがいい、ということだ。

病床を0にすればいいんじゃない

ゼロ除算で病床使用率が計算できなくなるから緊急事態宣言できなくなるじゃん

増田陰毛の七番勝負

陰毛をなんとかしたくて仕方なかった。当増田は30代女性陰毛は非常に濃く、かつ広範囲に生えている。ある夏の生理不快感に業を煮やし、とりあえず剃ってやろうと思い立った。闘いの始まりであった。

第1戦:「カミソリ」

陰毛-増田×(決まり手:カミソリふ負け)

【評】お察しの通り。あちこち切るわ伸びるとチクチクするわで地獄生理直後で皮膚が荒れていたであろうことも拍車を掛けた。

第2戦:「ヒートカッター

陰毛-増田×(決まり手:毛量)

【評】熱線で焼き切ることで毛先が丸くなり、チクチクしないとか。「遊女は線香で処理してたってのはこれかァ…」と感慨。粗いクシに熱線が渡してあるような形状の製品だったが、毛量に負け2回で壊れる。使用感は良かった。

第3戦:「男性用すね毛カッター

陰毛-増田×(決まり手:毛量)

【評】第2戦でカサが減れば楽になることが分かったので、断面さえスパッとしていなければチクチクしないのでは?と対戦。あっという間に詰まった。

第4戦:「除毛クリーム

陰毛-増田×(決まり手:毛量と1本1本の太さ)

【評】このころ読んだ「パイパンにしたらマジ快適」みたいな増田で除毛クリームを使っていたのに感化され対戦。もちろん大敗。定刻置いても毛が溶けず、数分おきに様子を見ていたがヒリヒリしだしてギブアップ。二度としない。

第5戦:「ブラジリアンワックス

陰毛-増田×(決まり手:毛量と毛根の強さ)

【評】剃っても切っても溶かしてもダメなら抜くしかないのでは?と対戦。さすがに自分でビリっと剥がす度胸はなかったので、ホットペッパーで安いサロンを予約。いざ施術、痛い。クソ痛い。特にVとIの境目がヤバい。目から火花が出る。毛が多いせいかサロンのお姉さんも明らかにダルそう。フラッシュ脱毛お勧めされるが丁重に断る。施術後はさすがに快適だったが、埋没毛が生じたことや、何より痛すぎたので二度とやらない。

第6戦:「専用シェーバー+家庭用脱毛器」

陰毛-増田?(現在対戦中)

【評】サロン脱毛勧誘は断ったが、結局根本を死なすしか解決策はないんだな…と決意。脱毛器はワキに使っているレーザー式のトリアがあったので、それを転用することに(メーカー非推奨なので自己責任)。

問題は①脱毛前に一度毛を剃る必要があるが、過去にカミソリ負けの経験がある②ワキでもまあまあ痛かったレーザー果たして陰毛で耐えられるのか?の2点。まず①の解決策としてパナソニックVIOシェーバーを購入。これが予想外に良かった。むろん宣伝文句のようにツルスベにはならないが、刃が詰まったりパワーダウンすることなバリバリ剃れる。皮膚も荒れにくい。

そして②だが、メッッッッッッッッッ痛い。出力を最弱にしても痛い。ワキとは比較にならない。第5戦と同じく、VとIの境目は特にヤバヤバのヤバであるワックス脱毛とはまた違う痛み。インターネッツ対処法を調べ、事前に鎮痛剤服用+麻酔成分を含む一般薬(ラナケインボラギノールなど)+保冷剤でだいぶマシになった。インターネッツには感謝しかない。

初回はさほど効果を感じられない上にヤケドっぽくなり凹んだが、繰り返すうち「あれ…?気持ちカサが…減った…?」という状態に。心なしか生える・伸びるのも遅くなってきた。これはいよいよ増田側の勝利が見えてきたのでは…??

闘いはつづく

番勝負って語呂がいいかなと思ったがそこまで行ってなかった。

これまでの敗北を振り返ってみれば、世の陰毛処理の体験談いかに薄め〜普通陰毛を持つ人々の筆によるものであるか、そしてそれに早めに気付いてさえいればこれほどの試行錯誤はなかったのに、という思いでいっぱいである。

ただ、試行錯誤を経て勝利への道筋は見えてきた。別にツルツルは求めておらず、全体量が減ってくれれば、特にIOの密度が多少なりとも下がってくれれば言うことはない。しかしIとOというのはなかなか効果が出にくいエリアらしく、まだまだ長い闘いが続きそうである。今後の増田選手活躍にご期待ください。

anond:20220124014542

欠けた大地の異界3Fクリア

2つあるワープゾーンが面倒くさかった。一歩歩くたびにウィザードアイを使う必要があり、マップ手書きしないと無理。

魔術師ロード、侍、ビショップの3人がウィザードアイを使い切るたびに帰還するひつようがあった。

敵は凶悪で逃げそこなうと大抵誰か死ぬ(ファイアドレイクフェニックスはそうでもないけど)。

特に、タフ・全体攻撃持ち・首はね・集団で出現と3拍子そろったファイアマティスは3グループ以上出たら負けるから逃げるしかない。

中ボスは初戦で死人ゼロ攻略できた。正直、ファイアマティ軍団ほど怖くなかった。

最初のターンに敵の攻撃がエレメンタルに集中してくれたおかげで、マジックスクリーンを張れたのが大きい。

ロードビショップが毎ターンマジックスクリーンを重ねがけしたので、敵のティルトウェイトを含む魔法攻撃がほぼ無力化できたし、ブレイクスクリーンを撃った上でスティールライフトキシックウルフボスに刺さったおかげで危なげなく勝利

そのまま4F探索へ入れる程度の消耗で済んだ。

で、また4Fで敵の凶悪度が上昇。特に手ごわい編成のやつでなければ勝てると言えば勝てるが、毎回総力戦になるから魔法使用回数と気力がもりもり削られてつらい。

あと、強い武器が出ないせいで、2Fから装備がほぼ更新されていない。戦士二人はカシナートと切り裂きの短刀二刀流。侍は蜻蛉切り。ロードは後列からバルダッシュ盗賊女王の鞭。ビショップは聖なるフレイル

ロードと侍の火力が戦士の半分しか無い上にHPもしょぼいせいで、最終的に予備役入りするはずの戦士2人がバリバリタンクダメージディーラーとして活躍している。もうこのままの編成で行こうかな・・・

2022-01-26

Laravel一歩目を踏み出す前に盛大につまづくの巻

イケてるエンジニアもすなるLaravelといふFWを、底辺チンカスエンジニアの私もしてみむとてするなり。

https://readouble.com/laravel/4.2/ja/quick.html

最初にComposerを使用し、Laravelインストーラーをダウンロードします。

フレームワークとか逆に難解すぎてやってられねーよ!と今まで拒否し続けてみたものの、なんか人気らしいので気になったんですよ。

で、公式サイトクイックスタートを見たら、1行目からこれですよ。

Composer? アホかと。バカかと。お前らな、依存管理如きで余計な要素を増やしてんじゃねーよ、ボケが。

名前は知ってるが使ったことないし、ちょっとググってもよく分からない。分かろうとも思わない。思えない。もともと頭が悪い上に中年なので学習意欲もわかない。

終わりです。終わりました。ハードル高すぎるんですよ。

Composerで手軽にインストール

って、Composer自体が手軽じゃないんすよ。

ComposerだのAnsibleだのDockerだの超絶魅力的だけど全然意味わかんないっすよ。俺くらいのバカでも分かるように作って欲しいんすよ。

結局フレームワーク使って何かハマった時にブラックボックスすぎてかえって面倒なことになるので(≒言い訳)、俺はこれから自作FWでやっていきます

それでも個人でいろいろ開発して全然困らず食っていけてるので(≒言い訳)。

結論をまとめるとPHP最高!ってことです。

病床使用率 42.8%

2022/01/13 15.1%

2022/01/16 17.9%

2022/01/17 21.1%

2022/01/18 23.4%

2022/01/19 25.9%

2022/01/21 31.5%

2022/01/23 35.3%

2022/01/24 36.3%

2022/01/25 39.8%

2022/01/26 42.8%

 

50%予想

1/28〜1/30 金土日のどれか

 

anond:20220126165412

業務スーパー本質は「大量」である

食堂カレーを作るとき市販バーモントカレー12粒入りのをいちいち箱破いてルー取り出してなんてやってたら日が暮れる

からたとえ安くなくても大量に購入できて大量にストックできて大量に使用できるのなら、業務用途では業務用を買うし使う

で、大量大容量パックのついでとして、1食分あたりの単価が安いことが「多い」というだけである

なので、安いの比較対象としてたとえばスーパー利益マイナス大安売り目玉商品とか持ってこられると、業務スーパーでもぜんぜん安くならない

anond:20220123165427

多くの関西人が同様で、必死のパッチ死語となりそうではあった

が、関西大阪北部しか知らん)には会話に笑いを取り入れないといけないという残酷な闇ルール存在する

またスベってもある程度周りがフォローしてくれる優しい環境もまた存在する

年配だったり地位あったり皆に酒を振る舞ったりして常に周りからフォローを得やすおっさんは、特にその恩恵を受け、寒いギャグなりなんなりを吐き放題だ。それは周囲に苦痛を与えたり、運よくWIN-WINだったり(ギャグ打率が高めで金銭的に付き合ってると得)する

また、話に笑いを入れるとしても芸人の持ちギャグなどの使用頻度は低い傾向にあり(これはよくすべるしリカバリしにくい、テレビフジモンがよくやってる一周回って面白くなるタイミングとかであればそこそこ使用価値はあるが、あの辺の匙加減はおっさんにはわからず、おっさんがやるとちょうどよい時期でも寒い)、結局オリジナルだかパクリだかわからないダジャレ採用されやす

必死のパッチはそんな中でも今まで過去に一度もバズったことがなく、細々と使われ続けている(一時阪神タイガースでこじんまりとした流行を見せたが(あまりにもメジャーダジャレはそれもまた寒い

なので、周囲に自分に対する敬意と優しさを兼ね備えた人材が多く存在している状況で、必死になったエピソードトーク披露するさいに、「必死のパッチやったで」とかで使えばよいと思います

いいねボタンエコじゃない

いいねボタンの仕組み

 

いいねボタンを押すと

いいねしたユーザーいいねされた記事などのデータが1つのレコードとして登録される。

仮に2万人がいいねすれば2万レコードデータが増える。

2万いいねされたユーザー記事が100万件あれば、2万×100万件分のデータ領域使用される。

 

いいねエコじゃないので控えたまえ。限りある資源大事に。

病床使用率 39.8%

2022/01/13 15.1%

2022/01/16 17.9%

2022/01/17 21.1%

2022/01/18 23.4%

2022/01/19 25.9%

2022/01/21 31.5%

2022/01/23 35.3%

2022/01/24 36.3%

2022/01/25 39.8%

 

50%予測1/29

5ch「小さい子を持つ親のここが嫌い」スレテンプレがすごい

0002 おさかなくわえた名無しさん 2021/05/07 06:26:27

スレ用語解説

ヒリとは、文字通りガキをヒリだしただけで国や少子化対策に貢献していると思い込み、恥じらいを捨て、ガキをだしに傍若無人非常識な振る舞いをする頭の悪い自己中心的な子持ち女のこと。

ヘラヘラして聖母女神気取りのニヤニヤ系ヒリと、無愛想で棒読み注意の仏頂面ヒリの2パターンが多い。

 

汁とはヒリの男バージョン

計画性ガン無視避妊せず汁を出すので汁と呼ばれる。

 

ダニとはヒリ汁に躾をされていない+少子化理由に甘やかされ、国の宝としてかしずわれることが多い為に

傍若無人で我儘勝手な振る舞いをする何の理性のない畜生以下の糞ガキの事。

 

ダニとは自我が芽生えていないすぐ喚き散らす人間未満の赤ん坊のこと。上記ダニの前段階。

特にヒリ汁に盾や免罪符に使われる多くどこにでも連れまわされることが多い。ダニーカーで突撃無理難題要求する際の口実に利用される。

ヒリには周りに愛想よくすることを強いるための道具として利用されることが多い。

 

ダニーカーはベビーカー通称ダニを運ぶために使われるためそう呼ばれる。

ヒリ汁の最強兵器で、突撃場所占拠に使われることが多い。特にヒリが使用しており並列走行が多く人の歩行の阻害になっている。

他人に持ち運びさせるなど親切の強要に使うことが多く、手助けしても十中八九礼言わずである

 

ダニンプはパコってボテっただけなのに、国の宝を抱えていると思い込み傲岸不遜な振る舞いをする妊婦のこと。

ダニをダシに傍若無人な振る舞いをするヒリの前段階。 通称ニンプリンセス

 

道路族文字通り公共の場である車道占拠し通行の妨害や、騒音を撒き散らしたりするなど傍若無人な振る舞いをするダニヒリ汁の集団のこと

その傍若無人さは最早公害レベル社会問題にもなっている。

これらのポイント

 

「世の中の全ての子持ちに当てはまるわけではない」

 

と言うこと

ただ現在では、圧倒的多数がそれに当てはまると揶揄されるほど

『 酷 く 目 に 付 く 様 に な っ た 』

 

 

0003 おさかなくわえた名無しさん 2021/05/07 06:26:51

これだけは確実に言える

 

自由放任を履き違えている

権利だけを主張して責任義務遂行しない

・ガキを盾に全ての法律破壊しようと画策する

年金税金の仕組みを知らないでこなしは年金貰うなと喚き散らす

・躾と虐待の線引きが出来ないので手を挙げただけで虐待だと喚く、もしくは引っ込みがつかずに一線を超えてしま

・堪え性が無いので少しの我慢すらできない

・かつて日本国内を恐怖に陥れたテロリスト団体オウム真理教教祖(麻原彰晃死刑執行済み)は妻子持ちであることを知らない

・「母は偉大」と言いつつ、2006年に起きた秋田児童連続殺人犯畠山容疑者のような母親がいることは認めない

・人には徹底的に厳しく自分にはどこまでも甘い

・人からの親切を当たり前のものとしてとらえる

自己中心的なくせに他力本願

他人迷惑をかけることに対しては無頓着だが、自分にとって都合の悪いことや迷惑になることには過敏に反応する

社会ルールマナーに順応しようとせず自己中心的な主張をし反社会的な行動をとる

・人に迷惑をかけてもお互い様理論という屁理屈正当化

自分の非は絶対に認めない

子供は泣くのが仕事と都合のいいような弁解をし、親の仕事は果たさな

子供が親を選べないように、親だって子供を選べない!って意味不明理屈をこねる

・好きでパコってボテっただけなのに、少子化に貢献してると威張り散らす

屁理屈言い訳だけは一人前

 

 

0004 おさかなくわえた名無しさん 2021/05/07 06:27:14

出産アカダニをやたらと神格化する

・そのくせ躾けも碌にせず、ダニの世話は他人任せにする

他人任せなくせに要求が高い上に多く、気に入らないことがあれば文句を言う

・そのくせ自分は親として最低限の義務を果たさな

自分ダニのことを未来の宝!や未来納税者!と言って憚らない

・そのくせ今の納税者には感謝のかけらもなく迷惑をかけても平気

個性多様性理解を求めるくせに、「子供嫌い」という個性は認めない

ダニに対する愛情ママアピール母性本能ではなく、単なる自己満足自己陶酔であることに気づいていない

ダニの奇声は親でもきつい!とか言うくせに他人迷惑がると不寛容!と喚き散らす

24時間ダニに付き添うなんて無理!というくせに教員には365日24時間休むことを許さないと抜かす

他人の落ち度は過剰に責め立てるくせに、自分に落ち度がある場合言い訳にヒリ屈をこね自己擁護挙句の果てには責任転嫁する。

2022-01-25

慶応大「4月から対面授業9割に転換」

授業をどうするかについては、塾長になって以降、各学部代表者が頻繁に集まって、徹底的に議論しました。その結果、教員学生全員の顔を見ながら教え、場を共有することが大切だ、このままだと教育の質が落ちかねないという結論になりました。一方で、最先端ツールを使って新しい授業をすることも必要で、両方をミックスすることにしました。最終的に、この4月からの対面授業は9割とし、昨年12月24日大学ホームページ公表しました。

慶応大「4月から対面授業9割に転換」 その理由伊藤公平塾長に聞く(朝日新聞EduA) - Yahoo!ニュース

https://news.yahoo.co.jp/articles/3c21c256ab97b33e7e8d7b9a944532d868a92ffc

一方で、

2022年は、どのように授業を受けたいか」を550人に聞いたところ、「ハイブリッド授業希望」38%と「オンライン授業希望」36%が同程度で、「対面授業希望」26%が最も少ない結果となった。

ハイブリッドという特殊な授業形態が最も期待される背景には、友人と交流する、そして通学時間を短縮させることを共に叶えたいといった、大学生たちの願いが込められているのかもしれない。

また、複数人大学生に話を聞いた結果、同じ「ハイブリッド授業」という言葉使用していても、実際の実施形態は異なることも分かった。

オンラインと対面授業から柔軟に選べる形式、各科目でオンラインまたは対面のいずれかを実施方法とし、複数の科目を合わせて数えると体系上ハイブリッドとなる形式、そして1つの科目の中で、授業内容によってオンラインまたは対面授業を使い分ける授業形式もあるという。

大学生が受けたい授業、「ハイブリッド」38%、「オンライン」36%、「対面」26% =Dtto調べ= | ICT教育ニュース

https://ict-enews.net/2022/01/dtto/

企業の人事もそうなんだけど、バブル世代の対面幻想って何なんだろうね。大教室で何百人も集まってただ教員の話を聞くような必要はないじゃん。新人研修も、今年は「万全の対策をとって対面で」とかいうだいきぎょー、結構多いみたいよ。

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

バンドメンバー容姿について言及しないでほしい

先月、好きなバンドメジャーデビュー後初のワンマンやったんだがこれがすげえ良かったので、他人感想見たくてTwitterパブサした。

そしたらボーカルのAさんがイケメン!みたいな容姿に触れる感想公式タグ付けてツイートしてる人が多くて驚いた。

どちらかというと顔売りしてないバンドなんだが……メジャーデビューしてからしばらく顔出し控えてたし、何枚か出たアルバムはどのジャケにも写真使ってないし、PVにもメンバー出てないし……。

このままファンがAさんの容姿に触れるようなツイート連発したら、曲じゃなくてボーカルの顔で売れてんだろって言われそうで怖い。

女性ファンが多いのを理由に「アイドルバンド」って叩かれた某バンドが、それを否定するために男性ファンを過剰に優遇するようになって炎上したけど、好きなバンドにああはなってほしくない。

アイドルバンドという単語悪口として機能するのもどうかと思うが)

顔出し控えめなのが仮にバンド方針だとして、所属レーベルがそれを許したってことは顔売りしなくても売れるだけの力があると判断されてるってことだろうし、顔出し控えめなのは顔売りバンドって言われるのを避けたいからなんじゃないかと思う。

それなのにワンマン参戦するような熱量あるファンメンバー容姿言及するのは、それがポジティブ感想でも関係者意図努力無駄にしてないだろうか。

どうしてもメンバー容姿についてツイートしたいなら、せめて公式エゴサや他のファンパブサに引っかからないようにしてほしい……。

本当にライブパフォーマンスが最高だから、色んな人にこのバンドライブに参加してほしいと強く思ってる。

からバンドみたいに、ファンが、自分ではどうしようもできない属性のせいでエントリーする資格すら剥奪されるような事態になってほしくない。

これ読んで気分悪くした人がいたらごめん。(特にバンドファンの方々……)

色んな観点から反論はいっぱいあると思うけど、少しでも「これは自分の好きなバンドの話かもしれない」と感じたなら、心の片隅において、ライブ感想ツイートする前に思い出してもらえると嬉しい。

※ちょいちょいフェイク入れてるけど、デビュー時顔出しなし・ジャケに写真使用PVメンバー出ないのは本当

anond:20220125141249

そうだね、まずはホモセクシャルという言葉から排除しよう

そっちの方が同性愛者についての文脈でよく使用されるから

anond:20220125092447

R-指定「さっきから全部 言葉ブーメランになって服が真っ赤」

呂布カルマブーメランは確実にお前の首を切り裂いて俺の手元に戻ってくる」

 

ちなみにアボリジニブーメランは基本鈍器として使用されていた

投げることもあったが基本はノーリターン

カンガルーの首の骨くらいは叩き折れるくらい威力があったらしい

リターン型のブーメラン存在はしたがごく一部の地域しか使われていなかった

https://liberal-arts-guide.com/aborigine-boomerang/

“「気持ちわるい」と言うのはいじめではない”

気持ちわるい」と言うのはいじめではない、ってそれにしてもすごい主張だ…。

なんだろう、言葉の重みの感覚が違うのか?

対人で使うのは相当憚られる加害ワードだという認識なのだが…。

オレは少なくとも、リアルでは陰口でさえ使ったことはない。

匿名ネットでは、明らかなセクハラコメントを注意するときだけ使用した覚えがある。その場合だって、敵の行動のどこが加害的だったのかを指摘した上で「気持ちわるい」を言ったと思う。

オレは男性だが、ひょっとすると性別や年齢によっても価値観は違ってくるかもしれない。

anond:20220125061634

2022-01-24

病床使用率 36.3%

2022/01/13 15.1%

2022/01/16 17.9%

2022/01/17 21.1%

2022/01/18 23.4%

2022/01/19 25.9%

2022/01/21 31.5%

2022/01/23 35.3%

2022/01/24 36.3%

 

50%超え27日〜31日予想

ポケモンGoOSMに対する功罪

Show the Niantic flag!

OSM成功したボランタリー地理情報 VGI(Volunteered Geographic Information) の一例と説明されますが、あくまでそれは一つの要素であって、世の中に定着した「最大」の理由ボランティア運営によるクラウドソーシング手法採用したことではありません

Google Maps のように商用利用時に制限のかかったウェブ地図よりも、より自由で、ある意味何でもできる OSM採用する企業が増えたことで、OSM認知度が向上するとともに、企業OSM を用いたサービス収益を生むことによる「エコシステム」がまわった。商用利用を許容することで民間企業による OSMデータ更新と利用価値を更に高める正のフィードバックへとつながったのだと筆者は考えます

https://medium.com/furuhashilab/show-the-niantic-flag-4ab03ed1c3ea


OpenStreetMapとは、自由に改変ができその利用もGoogleMapより自由度が高いことで有名な地図ソフトです。登山マップゲームマップなど、様々な分野で活躍しています。これの特徴は、無償ボランティアや利用する企業によるメンテナンスにあります。その中にはAppleFacebookといったあまり地図関係しないような企業も参加しています

存在しない島を追加したり海岸をまっすぐにいじったりすることは可能ですが、当然そのようなこのはしてはいけません。地図としてきちんと整備することが第一で、OSMやその利用者利益に繋がります

ここで名指しで取り上げられているNianticは、ご存じのようにポケモンGoを開発運営する企業

ポケモンGO地図OSMを元に作られていますポケモンGO日本だけでなく世界中で広く利用されており、その人口も非常に多いことで有名です。当然Niantic世界でも指折りのOSMユーザーでありその恩恵を受けていますが、実はNianticはそのOSMに対する貢献が殆ど無いことでも有名です。

自身アプリ内で直に使用し多くのユーザーの目に触れているものを、自らメンテナンスして貢献していないという実態コミュニティの中に筒抜けです。

言ってみればNianticはみんなで作る地図ただ乗りしているわけです。

それだけなら大したことではないかもしれません。OSSを幅広く利用していても、その改善に努めないことが間違っては居ません。

ただ、Nianticの作っているポケモンGOOSM自体への改ざんに繋がっているのが厄介な点です。ポケモンGoOSM上の公園などの特定場所ポケモンが出没しやす仕様です。逆に言えばOSMをいじって自分の周囲に大量をポケモンを出してしまうことも原理的には可能です。そしてそのような改ざんOSMコミュニティの中で非常に問題視されました。現在過去ほど大規模な改ざんは行われていないようですが、小規模な改ざんは今も続いているでしょう。当然、OSMは全世界的にそれが反映されるので、OSMを利用する企業個人がその改ざん被害者となり得ます

それを知っているNiantic問題放置し、修復を他の企業ボランティアに任せっきりにしていますただ乗りを明らかに超えていることでしょう。

さらに、現在ではOSMを超えてGoogleStreetMapの改ざんも多く報告されています実在しないもの審査させるために、その根拠となりうるストビュー意図的改ざんをして審査を通すやり方です。

ここまでしてまでポケストが欲しい人が多いのが実情

また、ポケモンGoのポケストはそもそもIngressというゲームポータルに由来します。最初こそこのポータルを設置する機能ポケモンGoにはありませんでしたが、現在ポケモンGoユーザーでも申請審査可能となっていますしかし当然由来と使い方が違う物を別々のユーザー申請審査することは非常に軋轢を生むことになります

現実問題ポケモンGo申請審査ができるようになってから不正なWayspotの登録加速度的に広がりました。何も無いはず場所に大量のスポットが出現したり、本来はありえないもの登録されていたり。酷いときには地域毎で談合を行っていますさらにNiaticはあろうことかFourSquarer上から任意スポット抽出してスポットしました。ユーザーに何も伝えずです。

これがポケモンGoの為だけならまだギリギリわかりますが、他のIngress魔法同盟ピクミンなどにも影響が及ぶスポットをこのような乱雑なやり方で作成することは問題です。

将来のゲームユーザーも使う物をポケモンGo恣意的且つ数の暴力で歪めているのが現状です。

唯一のいいところですが、OSMマッパーが少しだけ増えたことでしょうか。

これについてNianticや多くのポケモンGoユーザー殆ど反応していません。彼らは何を思っているのでしょう。

ログイン ユーザー登録
ようこそ ゲスト さん