「シェル」を含む日記 RSS

はてなキーワード: シェルとは

2022-05-14

自転車制動機構未来

リムタイプは将来絶滅するかな?ディスクブレーキ化されていくのかな?サイクルショップにしてみると、リムブレーキノウハウなんてさっさと忘れさり、ディスクブレーキノウハウだけ磨いていきたいって思うだろうからリム絶滅だろな。クロスバイクとかコミューターバイクとかそういう中途半端ものってなぜ存在するのだろうか?ママチャリシティサイクル)およびロードバイクでいいのに・・あとは山道で遊びたいMTBとかBTX

LLBEANはまずフロントシングル化+ホローテック

フロントギアマルチ (3s) なのが気に入らない。2か所もレバー操作必要だし、勾配のきつい坂道を延々のぼるわけでもないのに・・

LLBEANホローテック

使えずにおいてあるクランクアームがあるので、これに適合するBB (ホローテック、PW-BB73+)およびチェーンホイール新規に購入 (アリエク!!発注済)。

よく考えずにMTBクランクアーム買ってしまったもんだ。しか大丈夫クランクアームはBBに対しては圧入だな。BB側にスペーサーが付属してるんで68→73化して対応するんだね。

BBの仕組みの変化ってのも自転車パーツの進化の一つなのだろうか?メンテやりやすくなるよね

この前クランクアームを買い間違えてしまった。

BBなど追加購入して、このクロスバイクに取り付けたらいいのでは?」と思いつた。

クランクMTB用らしくてBBにいっぱいスペーサーがついてくるよう。

フロントシングル化したい

STIなどのシフター付ブレーキはめちゃくちゃ高いので、ブレーキだけの奴 (アリエクで)。AcadiaはブレーキがVじゃなくてキャリパーなのがGOOD. リアギア (7s) は サムシフターSL-TZ500でcontrol (アマで)。ペダルは流用。

ロハン化は

延期。

ステムはキル (quill) ステム

現状のハンドルバーの寸法 (25.4/22mm)。ドロハン (Upanbikeがアマで紹介されている)購入? いずれにせよドロハンをねじ込むのが大変だと思う。当て板とか首下の長いネジとかでこじ開けるんだよな。

https://youtu.be/WyLUh2eaXEw

Louis Garneau

さびバッシュガードが悲しい

クランクアームだけスクエアテーパーBB用の奴(アリエク) 買いなおす?コッタレスクランク抜き (B000RW71AS) も千五百円ほどで購入し自分でつけかえたら?ついでにペダルも折りたたみタイプのに?

今後の運用方針

出先では溝付きの駐輪場使うもしくは前輪外して駐輪場バーに引っ掛けて、駐輪。

自宅では自転車の前輪を外して玄関収容メンテスタンド購入済

旅行時は??

前輪外し+フォールディングペダル化+フォールディングハンドル化で車のトランクかもしくは後部座席の床部に

格納できないか

ラスペネは強力

ハンドルステムの件は無理せずプロ用の浸透潤滑剤が納品されてからにしやう!そういうことで納品を待ち、実際に使ってみたところ見事に緩めることできた。さすが浸透潤滑剤!威力あるわぁ。

アサヒサイクルがお安い完組の車輪を売らなくなったら

世の中で入手できる完組ホイール特にリア)がディスクブレーキタイプとなったら、いよいよフレーム(+フォーク、約一万五千円)買い替えか?そうするとリアが700で

フロントが26という異径組み合わせになるね?その時はハンドル回りも買い替えだよ。

電動アシスト自転車

電アシママチャリホイールMTB風)における変速は、内装変速機(3速)なのです。これって 5速 に変更できるものなのですか?

シフターはこれに伴って変更ですよね。おそらく3→5速にするとハブ径変わってくるので、スポークも総取り換えですかね?

アシストドライブ的には問題ないんでしょうか?

ギアは3速のままスプロケット部分(歯)だけ交換か?

サステナビリティだけを追求する自転車 (忘れよう)

子どもが乗っていた子供自転車(フレームサイズが350くらいしかない)が成育しすぎてダメになりそうだから・・

(ちな低身長者用のママチャリFSは420)流用可能な部分はそこから部品とり。

から後ろへ手順書を
番外編

後輪あとはRD(ディレーラー)。ワイヤー類を内装させる必要あり。根性的に大変?中華電動シフター(中華Di)って販売してないのか?

Louis Garneaux (26inchx1.5 HE) 投資分 (for restoration)

海外通販在庫一掃品のMTBフレーム(V台座付、でもフォー付属せず)に心惹かれる私

工賃

もしくは折り畳み式のフレーム

本当にあれ畳むのか?っていうフレーム (P/N = 1005003617006752)。あいつ→26用だった気がする。それで組むか?

それならポータビリティ高まる乗用車電車に積載可能)ってことで、訴求力ありまくりフロントホイールQRだし...。

DBマウントだったと思うので、フロントもリアもキャリパー一択

こいつもオリベロ化できると我が家で二つになる。二人で輪行母子輪行とか夫婦水入らずで輪行とか。父子で輪行・・はナイか?

26インチならスピードが出ない問題もある程度緩和されるし・・

折り畳み式における折り畳み式ハンドルというかフォークというかについて

折り畳み式フロントフォークみたいなのがあるのか?自宅にあるアジサシ見てるとフレームヘッドに刺さってるフォーク折れ曲ってコンパクト

化してるようだ

BBシェルは68とあるので、標準規格でしょ!?ママチャリのキャリパー化って検索すると死ぬほどたくさん出てくるのはなぜ?世の中には

ママチャリフレームがそんなに好きなのか?なにがそんなにいいのだろ?

その手のサイトお気に入りは これ→ st162c.blog.jp/

XShifter

電動(しか無線で)ギアチェンジさせるガジェット。これでハンドルからディレイラーまでの頑丈な金属線を張り巡らす必要がなくなるらしい。

NSXだかNXSだかという外国メーカージェネリック出すらしい。いまなら半額セール中らしい。

2022-05-13

タワマンのコンシェルジェに「床がきしんでるんで、キミに見に来て欲しいんだ」ってOK?

パンツスーツだし、

カギがない時に部屋まで来て明けてもらってお茶をふるまったり

「ベッドの下の床がきしんで音がする」って部屋内まで

見に来てもらってOK?


もちろん暇な時で結構ですけど。

2022-05-06

anond:20220506134340

個人的には前任者が3年使い古したノートPCのテカテカキーボードがゆるせんw

ラムシェルで使う。

2022-05-04

ノートPC中古は買うべきではない

キーボードが反応が悪かったり、タッチパッドがテカテカで反応悪かったりする。

ラムシェル型で閉じて使うならアリ。

喫茶店とかで使うのは恥ずかしいかもしれない。

2022-04-22

HHKBのよくある勘違い

PFUの高級キーボードHappy Hacking KeyboardHHKB)だが使い方を間違えている人が多い

矢印キーは使わない

HHKBの特徴は矢印キーが無いことだ

一応、Fnキーを押しながら使うことはできるが非常に使いにくい

なぜこんなことになっているか、というと、そもそもプログラマーハッカー)は基本的に矢印キーを使わないからだ

Vimの人はhjklでのキー移動、EmacsはC-BPNFでのキー移動

シェルを使う場合Emacs風にキー移動できるしショートカットを使うので基本的には使わない

ちなみに知らない人も多いがTwitterVim風のキーバインドで移動可能

Macの人は例えばメモアプリなんかがEmacs風のキーバインドで移動可能

ブラウザテキスト編集部分なんかでもEmacs風で移動可能

Windowsを使う場合アプリなんかでキーバインドを入れ替えて矢印キーを使わないようにする

こんな感じで矢印キーを使わない人が多いから、矢印キーが無くても問題ないのだ

何故矢印キーを使わないのか

勘違いしてはいけないのは、ハッカー

HHKBを使うために矢印キーを使わない」

のではなく

ハッカーが矢印キーを使わないかHHKBには矢印キーが無い」

ということだ

何故使わないかというと単純に「遅い」から

矢印キーホームポジションから離れた場所にあるため、使うためには一旦ホームポジションから指を離さなければならない

一度話してまた元に戻るという、このコンマ数秒レベルの遅延が鬱陶しくて仕方が無い

なのでホームポジションに指を置いたままキー移動したい、という考えに至っている

同様の理由でBack SapceやDeleteも使わない

Emacs風だとCtrl-HやCtrl-Dで代用する

持ち運び前提

とはいえ、全く矢印キーを使わないかというとそういうわけではなく、そりゃたまには使わざるを得ないし使った方が早い場面もある

なので矢印キーを右下の空いてるスペース(通称、猿が辻)に置いておけばいいし、HHKB Liteだとそこに矢印キーがある

なぜそれでも置かないかというと、そもそもが持ち運び前提のキーボードであって、少しでもキーを減らしたい、という哲学があるから

はっきり言ってしまって持ち運ばないならRealforceを使えば良く、HHKBを利用する利点は持ち運び前提であるという一点だけと言っても過言では無い

これの大きな理由は、昔はサーバルームでの作業のようにキーボードを繋いで利用するような使い方が前提であった、というのもあるがそもそも哲学によるところが大きい

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースからだ。

いまやパソコン消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。

和田先生のこの談話代表されるように、キーボード人間コンピュータと関わるうえで重要インタフェースであるという設計哲学がある

なのでキーボードコンピュータに備え付けられているものではなく、持ち運んで自分の好みのものを使う、ということを推奨している

そのためにもキーボードは使いやすさや打鍵感だけでなく持ち運びやすさを重要視してバランスの取れた設計を目指している

その結果、矢印キー排除するデメリットよりも、排除することで得られる持ち運びやすさのメリットの方が大きいと判断したのだ

左右の猿が辻があるお陰で持ち運びしやすいというのも使ったことがある人なら分かるポイントだと思う

複数持たない

この辺りは賛否あると思うが、馬の鞍であるという哲学に基づけば、PC毎にHHKBを用意したり、自宅と会社で2つ置いている、などは使い方として間違えている

全く同じキーボードであっても、物理的なモノが違えば慣れ親しんだものではなくなってしまうだろう

キーボードを生涯のインタフェースとするなら1つのHHKBを持ち運び使うということを体現して欲しい

ただ最近Bluetooth接続が増えたことや、HHKB BTの出来が良くないことなどもあるため、複数持っている人も多いとは思う

ちなみに、BTモデルには充電池が内蔵されておらず電池駆動なのも生涯使うことを考えているのだろうと思う

足は出さな

これはHHKBに限らない余談になるが、キーボードの裏面にある足は基本的に出さな

首に角度を付けるよりも水平の方が使いやすいのは人体の自然原理

なぜあの足が付いているか、というと実は「キートップを見やすくするため」だ

なのでHHKBの無刻印モデルに足が付いている理由は全く理解できないし、HHKBを使うような人がキートップを確認するとは思えないのでそもそもいらない

とはいえ、昔から足を出して手首に角度を付けてタイピングすることに慣れてしまっている人もそれなりにいるだろうから

自分の好みで出したり引っ込めたりすればいいとは思う

2022-03-29

anond:20220329151445

カジュアルファッションについての文脈でしょ。

登山スキーウェアの話じゃなくて。

それに厳冬期に役に立つのハードシェルとか防水性の高いアウターだと思う。綿製のミドラーのフードは防寒の意味では、ないよりマシ程度だと思う。

到底理解できないでしょうけど、

こういう偏見の決めつけも不要

2022-03-17

anond:20220317024135

モノのオタクになろうぜ! ガジェオタだ! モノは物言わぬから良いぞ!

輸入スマートフォンでも、輸入家電でも、イヤホンアンプの類でも、自作PCでも、自作キーボードでも、調べて凝ると沼が深いぜ!

女性でも好きそうなのはレジン充填シェル系のイヤホンとかかな! こういう見た目全振りのメーカーとかもある!

https://www.kineraaudio.com/ja/

2022-03-16

Macbook Proをクラムシェル で使ってると排熱で筐体が曲がって口がぱっかーん空いてバカみたい

死んだ貝かよwww

2022-03-11

古塔つみがうらやましい

花屋なんでしょ?

俺なんて人生詰んで何も残ってないよ?

インサイドキック堀川だって屋台でも生きていけるでしょ?

俺なんて外食起業なんてリターン少なすぎてバカバカしくてやりたくないよ?

電車内で高校生頭蓋骨砕いた元ホストシェルブリットカズだってなんだかんだヒモで生きていけるでしょ?

みんな俺より恵まれてるよ

まれすぎてる

2022-03-08

anond:20220308174836

ノーダメージとはいかないだろうけど、資源を握ってるからなぁ

実際シェルロシアから格安で」化石燃料調達したっていうし

なんかしらウクライナから妥協」を引き出せればそれを大きく宣伝して勝利宣言

適当なところで見切りをつけられればドイツがうやむやにしてくれんでしょ

まぁウクライナが「妥協」を飲むかは知らんが

2022-03-01

社用のiPhoneの遺失届が来て3時間

担当者がいまだにコンシェルサービス場所特定とか

電話かけてみたりと自力解決しようとしてキャリアに何の連絡もしてない。

当然、その間に来る他の仕事そいつ以外のメンバー負担

こいつアホなんかな。

2022-02-22

anond:20220222084920

「安寧を求める性向」は、エンジニアに不調をもたらす?

——登さんくらい常に気持ちフラットにできればいいのですが、仕事ストレスで参ってしまエンジニアも多くいます

そうですね。ストレスを感じる理由はさまざまあると思いますが、一つ例をあげるなら、仕事目的が「お金を稼ぐこと」それ自体になっている人は疲弊やすいかもしれませんね。

稼ぐことを目的としている人のゴールは、おそらくご自身の「安寧な暮らしの実現」にあるのだと思います。それがとても大事ことなのは言うまでもありませんし、否定するつもりも毛頭ありません。

一方で、私や私の周りにいる人たちは、現状の成果に満足せずに得たお金を次の進化のために再投資しようと試みる人ばかり。どちらが良いとか悪いとかではなく、価値観が違うだけのことです。

ただ、前者の「お金を儲けて安寧な暮らしがしたい」という人にとって、仕事から受ける疲労や気分の落ち込みというのは、ある種当たり前のことだとも思うんですよね。

——というと?

どこかで成長を諦め、安寧な生活を望むような性向が、かえって心身の不調やフラストレーションを生み、パフォーマンスを落とす一因になっているのではないかと思っているんです。

お金を稼ぐためだから、しょうがいか」と思ってやっていること自体が、ストレスになるのではないかと。

登 大遊さん

でも、こればっかりは人の価値観ですからね。変えようと思っても、すぐに変えられるものでもない。

どんな価値観で生きるのかを選ぶのはその人ですし、どんな人生を選んでもリスクはついて回ります

安寧な生活や休息を優先する生き方には、仕事に対するストレスやそれに付随する心身の不調などの副作用があるということに過ぎません。

ただ、一つ言えることがあります日本において、「大義を持って働く」生き方選択をした人は、これから大変有利だということです。

——どういう意味でしょう?

自分の手で未来を変えようと野心に燃える人が世界中から集まるシリコンバレーなどでは、埋もれてしまうかもしれない人であっても、日本旧態依然とした組織の中では、同じことをするだけで、比較相対的価値が高くなりますから

技術者がわざわざベンチャーを立ち上げ、投資からお金を引き出すために詭弁を弄したり、ニーズでっち上げたりしなくても、日本大企業にはストレート解決すべき課題いくらでもあります。そしてそれらの問題を、自分自身頭脳を用いて解決しようとする時は、必ず、従来とは異なる方法解決する必要があるのです。

なぜなら、まさに従来手法では解決できなかったこからその問題放置または堆積されているためです。

——その場合は、どうすればいいのでしょうか。

その問題を一旦一般化・抽象化した上で、これを解決することができるより低レイヤーフレームワークのようなものを作ってしまうことが重要です。一定の労力はかかりますが、それによって生じた汎用的成果物は、他の業務や他の組織においても普遍的価値を持つようになります

ここで重要なのは目的を「業務上の特定問題解決から昇格させ、「その特定問題本質的類似しており、かつ既存の最適な解決方法存在しない、新たな汎用的解決方法の実現」という、より価値の高い目標に設定する必要があるということです。

登 大遊さん

——目先の特定問題をその場しのぎで解決するのではなくて、普遍的価値を目指すと。

その結果、問題がうまく解決され、成果物が出たならば、サラリーマン的な自分自身個人)と自組織にとっての短期的な狭い利益だけでなく、同時に「世界における技術進歩」という長期的で大きな価値が生じます

具体例を挙げると、たとえば「UNIX」を構成する重要機能、たとえばシェルプロセス通信パイプgrepといった機能。これは電話会社であるAT&T社の特許部門における、膨大なテキストファイル全文検索するという特定業務解決しようとした同社の社員たちが、単にその社内問題解決にとどまらず、さまざまな組織目的で汎用的に利用できる仕組みを考案し、プログラミングして実装したものです。

結果として、「UNIX」は汎用的に利用される価値を有し、単に一企業業務に留まらず、全世界的に普及し現在サイバー世界の基礎となっています

このように考えれば、ICT技術者は、これまで組織内で放置または堆積されてきた多種多様課題について、目先の解決ではなく、「正しい普遍的方法解決する仕組みを作る」という気概で、真摯に向き合えば、自然に世の中に貢献できる成果ができるわけです。

2022-02-17

anond:20220217113442

でしょ

マックイーンで初めてを済ませたらもうライアンに乗り換えてて、メジロ家の姫みたいなことしてメジロ家に内紛をもたらしてそう

と思ったらしっかり会長ともできてんのがなんかよくないわ

マックイーンが一番抜けてる感あるから寝取られしまった可哀そうなマックイーンはなんかいいね

マベサンいくのもようわからん

それに比べてニシノフラワーは、同じ馬主セイウンスカイの子供産んでて尊いんだよな、と思って改めて繁殖実績見たらそうでもなかった

年度馬名性別父名
2007ニシノオフェンスアグネスタキオン
2004ニシノマナムスメアグネスタキオン
2003ニシノミライセイウンスカイ
2002ニシノカエデマルパントレセレブル
2001ニシノデューブライアンズタイム
2000ニシノハーロックタイキシャトル
1999ニシノライメイダンシングブレーヴ
1998ニシノシシオウラムタラ
1996ニシノセイリュウブライアンズタイム


あと、男の子がこわいメジロドーベルちゃんも、覚えてしまったらしっかりやれる子

初めてはエル

ドーベルってゼンノロブロイの子産んでたんか

なんかウマ娘的には相性よさそうだな

絡み合ったっけ?

年度馬名性別父名
2016ピンシェルルーラーシップ
2015メジロドーベルの2015キングカメハメハ
2014ホウオウドリームルーラーシップ
2012レーヌドブリゼンノロブロイ
2008メジロダイボサツディープインパクト
2007メジロオードリースペシャルウィーク
2006メジロシャレードマンハッタンカフェ
2003メジロアレグレットアグネスタキオン
2002メジロルルドサンデーサイレンス
2001メジロヒラリーエルコンドルパサー

2022-02-15

macOSBSDではない話

少し前にmacOSLinuxではないとTwitter話題になりました。その際に

macOSBSD

といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな~。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。

Unix
ベル研究所で開発されたOS
BSD
カリフォルニア大学バークレー校Unixを改良したOS
Mach
カーネギーメロン大学で開発されたOSで、BSD互換機能の開発のためBSDソースコードを流用しています
NeXTSTEP
NeXT社によりMach独自UI実装して開発されました
macOS
NeXTSTEPをもとにUI一新しました
FreeBSD
カリフォルニア大学でのBSDの開発が終了した後、それを引き継いで開発しているOS
MachBSD

Machは当時一世を風靡していたマイクロカーネル設計採用したOSで、BSDとは全く違うOSです。

ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ

といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。

macOSMachなのか

Mach1990年代研究プロジェクトが終了しています

macOSのもとになったNeXTSTEPMachを改造して始まりましたが、現在では別物であると考えるべきです。

macOSBSD

macOSは直接にはMachから派生したもので、BSDではありません。ただし

など、BSDと誤解させる点があるのは確かです。

Linux

Linus氏が実装したOSです。

上記UnixBSDMachNeXTSTEPmacOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。

しかし現状ではNode.jsPythonなどでプログラムを作ろうとした場合シェルで使うコマンドmacOSLinuxでは共通するものも多く

macOSUnixシェルの使い方を覚えた後にAWSVMログインするようになった

というユーザーmacOSLinuxが似ていると認識してしまうのは仕方がないところではあります

2022-02-03

[]2022年1月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

278あとで/1848users セガjavascriptぷよぷよを作るプログラミング講座を出しているが、とても良いプログラミングの教材になっている「写経はとても大事」 | Togetter

238あとで/1666users ジャズコード進行原理 - アラクー Arakur

228あとで/1260users ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive

220あとで/1885users Adobe製品と同じような事をフリーソフトでやりたい場合対応表がすごく使える→他にも高機能フリーソフトが集まる | Togetter

211あとで/1407users 「Visual Studio」の中の人が作ったプログラマー向け十徳ナイフ「DevToys」/今までググって探していたツールがひとまとめに | 窓の杜

210あとで/3113users ゲーム勝敗かんしゃくを起こす子どもにできることは大人げない大人になること|フィンランドワークショップomena|note

201あとで/1188users 総務省「誰でも使える統計オープンデータ無料オンライン講座スタート | ITMedia

198あとで/960users プログラムメモリをどう使うかを理解する(1) | rita | Zenn

196あとで/1262users 仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話田辺めぐみnote

189あとで/973users フロントエンドデザインパターン | Shinya Fujino | Zenn

187あとで/1551users 英語面接で5歳児みたいなことしか言えないからカッとなってWebサービス作った【個人開発】 - Qiita

187あとで/1563users TOEIC満点ホルダーがやっているおすすめ英語学習法(2022年版)|Shinnote

177あとで/1554users 207で1年間磨き続けた1on1フォーマットを公開します|207株式会社note

171あとで/1530users エンジニアの"有害な振る舞い"への対処法 - Qiita

170あとで/1316users 顧客との打ち合わせが上手い人がやっていること|いまにし|note

165あとで/1551users 「この会社は詰んでます。潰れました」で気づいた“恥ずかしさ” DeNA南場智子氏がエンジニアから学んだこと | logmi Tech

158あとで/1342users 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎|note

153あとで/1343users 強いエンジニアになるために英語必要と聞いたので4ヶ月でTOEICスコア400→900まで上げた話 - Qiita

148あとで/1190users なぜ40歳を越えると「やる気」が出ないのか? 「中年危機」を乗り越えるためのエンジンの回し方 | 野水克也, 萩原雅裕 | logmi Biz

148あとで/955users ITエンジニア投票した「ITエンジニア本大賞2022」ベスト10発表。「シェルワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など | Publickey

142あとで/690users JavaScriptを遊び尽くす究極のWebサービスツールを厳選して大公開! - paiza開発日誌

138あとで/891users そこまで努力しないで生活ちょっと改善する100の方法 | 英紙元旦に紹介 | COURRIER

137あとで/1237users 問題職員の正しい辞めさせ方 1/10 | anond.hatelabo.jp

136あとで/635users フロントエンドを集中的に学習できる究極の無料リソースを厳選してみた! - paiza開発日誌

133あとで/768users ミーティングファシリテーション入門 / Introduction To Meeting And Facilitation | ストックマーク株式会社 iwashi | SpeakerDeck

126あとで/1056users Future社員が使っているWindows便利ツール新人さん向け) | フューチャー技術ブログ

126あとで/802users 『データ分析のためのSQL勉強会資料公開|高橋 光|note

126あとで/859users エンジニアを始めてから便利だったツールまとめ | nakaatsu | Zenn

125あとで/757users 2022年におけるフロントエンド開発のベースライン - LINE ENGINEERING

123あとで/1202users 50歳になってようやく気付いた、人生重要なことと、後悔したこと。 | fujipon | Books & Apps

123あとで/1055users 【必読】総務省直伝のExcelマニュアル目から鱗が落ちるものだった | Togetter

ジャズコード進行解説したブログが2位になった。はてブでこんなページを目にできようとはとブクマカ驚愕

COURRIERの「そこまで努力しないで生活ちょっと改善する100の方法」はペイウォールの向こうに行ったが原文は読める。 https://www.theguardian.com/lifeandstyle/2022/jan/01/marginal-gains-100-ways-to-improve-your-life-without-really-trying

2022-01-25

本のまとめ

--

この本は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

2022-01-22

anond:20220122200813

国語増田にやっつけられたせいで誰も彼もが国語増田に見えるシェルショック兵士かよ

2022-01-02

ヴィーガンチラ裏

・めだま焼きと唐揚げ

親子丼

チーズハンバーグ牛肉

ラードで揚げたとんかつ

あたりは、ユダヤ教の「親と子を一緒に食べてはいけない」という教えに反するらしい。

最後のはちょっと違うかもだが。

ハラルとか仏教とかそれぞれ違ってめんどくさいから全部食わないのがいちばんだよ。

ID非公開さん

2016/9/1 15:50

6回答

ユダヤ教において「子ヤギの肉を、その母の乳で煮てはならない」という戒律がありますが、“親子”の組み合わせ料理は、ユダヤ教徒は厳禁で 同じ親子の組み合わせ、親子丼チーズバーガーすら厳

禁らしいです。

でも戒律は「子ヤギの肉を、その母の乳で煮てはならない」であって、あくまでも「子ヤギの肉」を「ヤギ乳で煮てはならない」であるから親子丼チーズバーガーなら問題ないんじゃないでしょうかねぇ?どうも悪い方へ解釈してしまってるのですね。

宗教・1,114閲覧

1人が共感しています

ベストアンサー

cav********さん

2016/9/1 19:05

良い悪いはともかく、拡大解釈であることは確かです。

ユダヤ教では「肉と乳製品をいっしょにとること」を禁じていますチーズバーガーやクリームシチューに肉を入れることはもちろん、一回の食事で肉と乳製品をとることはできません。肉料理の食後のコーヒーミルクを入れるなどもだめです。私がイスラエル旅行した時、肉料理の後にデザートとしてアイスクリームが出ましたが、牛乳ではなく豆乳を使っているとのことでした。肉と乳製品を食べる間に、6時間だか8時間だか置かないとだめなのです。(胃の中で双方がいっしょにならないように。)もちろん、どこまで厳格に守るかは個人差があるようです。

親子丼は、卵であって乳製品ではないので大丈夫なのではないでしょうか。

質問者からのお礼コメント

まったくだな、鶏・卵白親子丼、ヤギでないのに食いたくないのは とんでもない解釈

お礼日時:2016/9/7 14:18

Yahoo!検索で調べてみよう

クリームシチューチーズバーガー親子丼クリームシチュー肉料理

その他の回答(5件)

dol********さん

2016/9/2 8:10

違うよ。カシュルート(食物規定)では「肉」と「乳製品」を混ぜることが禁じられているんだよ。

で、卵も乳と同じように親鶏から出てきて、子を育てる成分を含むものだ。だから中世ユダヤ人は卵の性質上、乳と同じだと考えた。ただし、まだ殻を形成していない段階ならば乳とは見なされない。ここは議論があって、絶対そうだというわけでもないよ。

いずれにせよ、卵の殻座の部分には血が混じっているので、その部分を取り除かねばコシェル(適正)にならない。

また、厳格な人は食後にコーヒーを飲むこともしない。うっかりコーヒーミルクを入れて、胃の中で肉と乳が混ざることを防ぐためだ。

さらに、イスラエルマクドナルドなんかは、ハンバーガーを売るカウンターと、アイスクリームを売るカウンターとが別々になっている。

あなたは「悪い方へ解釈」と言ってるが、それは「食物規定は悪いもの!」というキリスト教価値観押し付けにすぎない。

こうした食文化全体として見れば、あなたが挙げた問題なんて取るに足りないことというか、むしろ「より安全な方へ」という解釈になっているんだよ。

なぜなら、神が与えた食物規定真意は、人には分からない。だから、人がうっかり規定違反することがあるかもしれない。それゆえ、神が具体的に命じたことを範例として、食生活の一つ一つについて詳細に検討した結果なんだ。人の謙遜さの現れなんだよ。

2021-12-31

anond:20211231112736

VDI 導入、コロナ禍におけるビデオ会議課題改善

そして中長期の PC 環境の構想へ

リクルートにおける VDI の導入、運用コロナ対応、そして今後の ICT 環境を紹介する連載。

今回は、VDI 導入を振り返り、中長期の PC 環境の構想をお伝えする。

石光直樹,リクルート(2021 年 05 月 24 日)

23 →目次に戻る

 “ ネットワーク状況によっては使えないシーンがある点 ” は、VDI なら避けられない問題です。特に外出中は、ス

マートフォンによるテザリングで VDI に接続する際に、エリアや移動状況によっては通信環境が安定せず、通信

切断されたり、通信速度が遅くなったりするなど、VDI がスムーズ動作しないシーンがありました。この課題

対しては、スマートフォンテザリング容量の観点なども含めて検討し、対処してきましたが、完全には解決でき

ませんでした。そこで、VDI では業務遂行がどうしても困難なユーザー限定し、さらに高セキュリティ業務以外

での利用において通常の PCFAT PC)を配布するようにしました。

もう一つの課題ビデオ会議実施時の不具合 ” については、もともと VDI とビデオ会議親和性は良くない点

が前提にありますビデオ会議場合クラウドサービスを使うことが多いと思いますが、通常の PC なら、クラ

ウドサービスPC 上のビデオ会議ソフトウェアが直接つながり、ユーザーは快適にビデオ会議ができます。一方、

VDI の場合クラウドサービスと VDI 上のビデオ会議ソフトウェアがまず接続され、その後 VDI から VDI 専用端

末(シンクライアント端末)に音声と動画転送される形になります。音声も動画もいわば二重でデータ転送

れる仕組みなので、劣化してしまうのは避けられません。具体的には、音声が途切れ途切れになったり、動画

カクカクしてスムーズ動作しなかったりすることになります

また、システム管理観点でもデメリットがあります。通常の PC では、ビデオ会議ソフトウェア機能クラウ

サービスとのネットワーク接続状況をチェックしてくれて、最適に通信する仕組みなのに対し、VDI ではそのよう

機能は使えません。ビデオ会議ソフトウェアにその機能が搭載されていても、VDI から VDI 専用端末に通信

る段階でそれらの機能無効化されてしまうのです。その結果、VDI 上でのビデオ会議は通常よりも多くの通信

量が発生してしまい、外出時などテザリングの容量を圧迫することになっていました。

しかし、最近ではビデオ会議のこうした課題回避策として、クラウドサービス各社が VDI 用のソフトウェア

リリースしてくれるようになってきました。VDI 用のビデオ会議ソフトウェアを VDI にインストールして、一部のソ

フトウェアコンポーネントを VDI 専用端末にもインストールします。そうすることで、VDI と VDI 専用端末が協調

してビデオ会議端末として動作し、クラウドサービスと VDI 専用端末とが直接つながる構成になり、従来に比べる

と音声や動画劣化が大幅に避けられるようになってきています

24 →目次に戻る

中長期の PC 環境を構想する――“ 中長期 ” という新たな観点の導入

 以上をまとめると、いまの VDI 環境では当初想定したメリットは得られたものの、ネットワークビデオ会議

おいてそれぞれの課題がありますネットワーク課題は、一部ユーザーFAT PC を配布することで、ビデオ

議の課題については VDI 用のビデオ会議ソフトウェアインストールすることで解決できます。いまの VDI 環境

評価するマトリクスを作って検討してみると、VDI 用のビデオ会議ソフトウェアがうまく動作すれば、VDI 環境

をそのまま継続するのが妥当なように見えました。とはいえ、そのような “ カイゼン策 ” を施しながら、VDI をい

まの形のまま続けるべきなのでしょうか。そして、そのような思考プロセスに本当に問題はないのでしょうか――。

われわれは検討時に、新たな視点を導入することにしました。それは “ 中長期 ” 視点です。2015 年においては、

3 つの課題という、“ いま、ここ ” における課題に対する解決策として VDI を採用したものの、今後長きにわたっ

会社を支えていくPC 環境を構想するに当たり、それだけでは不十分ではないかと考えました。リクルートは創

から 60 年以上がたちました。今後も長きにわたりカスタマークライアントの皆さんのためにより良いサービ

スを提供し続けることになるでしょう。それには短期的な視点だけではなく、中長期でのあるべき PC 環境を描い

て、それに向かっていまどうすべきかを考えなければならないと思ったのです。

そのためには、まず働き方が将来的にどうなるかを想定しなければなりません。次期 PC 環境検討していたの

コロナ禍前でしたが、ゆくゆくは「完全に場所を選ばない働き方」になるだろうと予想していました。キーワード

で示すならば、「Anytime/Anywhere/Securely/Work Digitally」という表現になるでしょうか。そのような働き方

を実現する PC 環境については、既にいわれて久しいですが、クラウド中心の方向性は変わらないでしょう。加えて、

今後は多種多様デバイスが出現すると想定しました。いまは PC や VDI が中心であり、補助的にスマートフォン

使われているというのがビジネスにおける PC 環境の実情だと考えます。では、今後はどうなるのか――。

スマートフォン中心になるという見方もありますが、学校では情報教育が進みノート型の端末が支給されており、

家庭においてはスマートスピーカーが広まりAR/VR拡張現実仮想現実)もゲームなどを中心に広がってき

ています。また、企業では製造業などで AR/VR が使われる事例も出てきており、IoT デバイスもいろいろなユー

スケースが生まれてきました。

そう考えると、ユーザーが使う端末は、どれかの端末に収束していくのではなく、2in1 あるいはクラムシェル

などの PCスマートフォンタブレットAR/VR デバイススマートスピーカーIoT などいろいろなデバイス

使いこなしていく世界になるのではないかと考えます業務のさまざまな場面で、いろいろなデバイスの中から

適なものを選び、さまざまなクラウドサービスを使いこなし業務をしているイメージです。それらを使うことで、場

所を選ばず、どこにいても対面同様のコラボレーションができるでしょう。さらには、AI人工知能技術などを

活用しながらユーザー業務支援するなどして、高い生産性を生み出すことができる環境になっていくのではな

いか、と予測します。

25 →目次に戻る

中長期視点で考え、いま行動する――「クラウドマルチデバイス環境」へ

われわれは、このような環境を「クラウドマルチデバイス環境」と呼ぶことにしました。中長期的には「クラ

ウドマルチデバイス環境」になるとして、VDI の EOSL 契機に対応しなければならないわれわれの次の PC

境はどのように整えたらいいのでしょうか。

 大事なのは、「中長期視点で考え、いま行動する」ことです。中長期視点だけを考えれば、一気に「クラウド

マルチデバイス環境」にすべきでしょう。ところが、われわれの環境内にはまだレガシーシステムが残っており、一

気にクラウドだけを利用する業務形態に変えるのは困難でした。また、検討した結果、現時点では VDI に勝るよ

うなセキュリティ確保の仕組みは見当たりませんでした。そのため、情報資産の囲い込みができるという点で、高

セキュリティ環境に対しては継続して VDI を活用することにしました。

セキュアな環境以外の用途においては、“ いま ” のことだけを考えれば、ビデオ会議の部分のみを改善して VDI

環境のまま、次期 PC 環境を作る方向もあり得ました。しかし、それでは今後の PC 環境が VDI に固定化されて

しまうことになります。VDI 環境をいままでと同様にオンプレミスで作るには、初期に大きな設備投資必要とな

り、また一度構築してしまうと使い捨てるわけにもいかず、それをしばらく運用し続ける必要があります。今後い

ろいろなクラウドサービスデバイスが出現すると、活用したいと思う方も多いでしょうが、既に VDI を使ってい

場合、VDI の代わりに別のものをすぐに使うということはなかなかできません。そういう意味で、PC 環境が固

定化されてしまうことになるのです。

 中長期の環境に一気に切り替える方針でもなければ、現在のことだけ考える方針でもなく、「中長期視点で考え、

いま行動する」方針検討した結果、次期 PC 環境は「クラウドマルチデバイス環境」を目指すための第一

位置付け、「VDI と FAT PCマルチ環境」を構築することに決定しました。先述した通り、レガシーシステム

存在し VDI 以上に情報の囲い込みができるソリューションがない中で、VDI から離れ、一気に中長期的な将来

像を目指すのは困難です。とはいえ「将来像に向けた環境をいま作るべき」と考え、VDI と FAT業務特性に応

じてユーザーに配布するマルチ環境刷新することにしました。つまり、高セキュリティ業務ユーザー向けにはセ

キュリティを確保した「セキュア VDI」、それ以外の一般ユーザー向けには FAT PC を配布することにしたのです。

将来的にはマルチデバイスといっても、いまだ PC がメインなので、まずは PC を配布し、その上で今後 AR/VR

デバイスといった他のデバイス検討していきたいと考えています

なお、VDI 環境としてはもう一つ、機能更新がない固定的な OS必要とするレガシーアプリ向けの環境も VDI

で用意することにしました。用途限定されていることから、社内では「特定用途 VDI」と呼んでいます

26 →目次に戻る

VDI 用のビデオ会議ソフトウェア導入による 2 つの課題

 以上をまとめますと、働き方は中長期的に「完全に場所を選ばない働き方」へと変わり、それに応じて PC

境は「クラウドマルチデバイス環境」になっていくでしょう。われわれも VDI の EOSL のタイミングで変わって

いかなければならず、将来に向けた第一歩として、次期 PC 環境は「VDI と FAT PCマルチ環境」を実現する

ことにした、ということになります

なお、コロナ禍において、われわれは現在の VDI 環境下でビデオ会議改善を試みました。先述した VDI 用

ビデオ会議ソフトウェアの導入を検討し、一部導入したのです。その結果、ビデオ会議の音声と動画品質

極めて改善されることになったものの、2 つの課題が新たに見つかったのです。

1 つ目は、普通ビデオ会議ソフトウェアと VDI 用のソフトウェアとの間に機能差があった点です。この課題

今後解消されるかもしれませんが、われわれが導入した段階では VDI 用のソフトウェア機能面で劣っていました。

2 つ目は、導入/管理コストです。1 つのビデオ会議システムしか使っていない場合問題いかもしれません

が、複数使っていたり、今後新しいシステムの導入を考えようとしたりすると、ソフトウェアの導入、管理に都度

工数がかかってしまうという難点が明らかになりました。

 以上 2 点については、いま検討されている方のご参考になれば幸いです。次回は、リクルートがいままさに取り

組んでいる「VDI と FAT PCマルチ環境」についてお話します。

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