「ライフサイクル」を含む日記 RSS

はてなキーワード: ライフサイクルとは

2022-06-13

ベンチャーの良さは仲の良さだけ

著名な投資家達はみんな口を揃えて言うけど

ベンチャーのやってる業務内容が当たるかどうかなんかどうでも良くて

CxOの仲の良さしか見てないし実際にそれが一番成功要因になる

何が売れて何が儲かるかが分かったら苦労しないってのは投資家も一緒

ベンチャーが少し大きくなって人を採りだしたとき

から入ってきた人達とも仲が良いかどうかも成功要因

さらに大きくなってメガベンチャーレベルに人が増えてきたら、さすがに仲の良さは維持できなくなる

そしてその辺で加速度的成長って奴は無くなる

こうなると成長はするけど楽しくなくなるのでCxO達は徐々に離脱して別の新しい業態活躍する

ここまでが一般的ベンチャーライフサイクル

なのでまずCxOの仲が悪い・ニュートラル関係とかだとまず成功しない

から入ってきた人達との仲が悪い・ニュートラル関係だとこれも成功しない

から入ってきた人なんてクビにすればいいっていう考え方もあるけど

そういう考え方してるチームは大体仲が悪くなるってのは歴史証明してる

ベンチャーで働きたいならインターンなりお試しなりで2週間ぐらい働いてみるのと、プライベートでも付き合ってみる

そんで仕事以外の部分でも仲良くなれそうって思うなら入ればいい

プライベートでは人付き合いしたくない、っていう人はそもそもベンチャーに向かない

ベンチャーってルームシェアみたいなもんだから裸の付き合い出来ない人は無理だと思うな

2022-04-23

ヤマダHD、社内資格SDGsマイスター制度」を新設 省エネ知識は当たり前に

 ヤマダホールディングスは、サステナブル経営の一環として「SDGsマイスター制度」を新設する。同社が掲げるSDGs目標達成への重要課題に向き合うための新教育制度として、SDGsにかかる基本的知識習得と、社会課題を「自分ごと」と捉えて自身行動様式を変化させることのできる人材の育成を目的として、全従業員対象資格取得を推奨する。



 ヤマダホールディングスでは、独自SDGs目標達成に向けた重要課題を掲げ、これまでも循環型社会の構築など、持続可能社会の実現に向けた取り組みを推進してきた。今回の「SDGsマイスター制度」は、これまでの環境保全に関わる社会の動きと同社の取り組みへの理解に加え、SDGs全般への理解・浸透とダイバーシティ推進のための知見を高め、従業員知識向上を通じて企業としての持続的成長を促すものとして新設することとなった。

 SDGsマイスター認定者には、ヤマダホールディングス独自環境マーク「YAMADA GREEN」をモチーフにした認定バッジを贈呈する。今年末までに導入予定であるバッジは、ヤマダホールディングスグループで構築された製品ライフサイクル完結の仕組みを活用した再生マテリアルで作製、グループ内での資源循環とSDGsの知見の証として制服に着用する。

 SDGsマイスター認定試験を受けるためには、まず、SDGsに関わる基本的知識習得目的とした3つの試験SDGs概念SDGs達成への当社の重要課題、DE&Iへの理解)に合格し、「SDGsマスター」に認定されていることが必須条件となる。

 SDGsマスター認定された後、経済経営知識社会現象などに関する試験突破すると「SDGsマイスター」として認定バッジ付与される。今年から試験実施し、早ければ来春にはSDGsマイスター認定者が誕生することとなる。また、SDGsマスターSDGsマイスターともに、来春以降は社内の人事評価制度への組み入れを予定している。

 ヤマダホールディングスでは、SDGsへの理解・浸透を目的として、昨年7月に有志の従業員による「SDGsひろめ隊」を発足、チャットルーム活用して情報共有や意見交換をしている。全国の店舗本社従業員からなるメンバーで、SDGs目標達成に向けた課題解決という視点での業務フロー改善案日常生活での取り組みなどを共有し、会社として、個人としてできることについて情報共有がなされるなど、活発に活動している。

 今回は、環境配慮した商品サービスをヤマダホールディングス独自認定した環境マーク「YAMADA GREEN」の認知拡大について考えた際、「まずは社員環境に関する取り組みへの理解を深めるために資格にしてはどうか」という声がひろめ隊の社員からあがったことがきっかけで、資格制度の新設に向けたプロジェクトが発足した。

 この新資格制度は、ヤマダホールディングスグループ企業で開始した、エシカル素材“バナナペーパー”の名刺印刷業務に次いで、「SDGsひろめ隊」の活動会社連携した事例となる。

 ヤマダホールディングスグループは、今後も、SDGs目標達成に向けた社会課題を「自分ごと」と捉え、会社として、個人として、できること、やるべきことに真摯に向き合い、持続可能社会の実現に向けた取り組みを推進していく方針

取り組みは素晴らしいと思うけど、IT資格に比べてなんか陳腐というか、お勉強会お遊戯会感が否めない

あくま物流業であり、IT製造業とは違うということが分かる

2022-02-28

anond:20220228170443

貯めこまないでライフサイクルで一つずつタスクを潰せば楽。


溜め込むからしんどくなる

2022-02-11

anond:20220211101653

なるほど!立って半畳寝て1畳といっても米だけでもライフサイクルで考えたら120㎡余分にいるんだね。野菜も考えたらもっといるね。肉も考えたらもっともっといるね。

2022-02-05

マツダ技報2021年度版が発表されたので適当感想とか

2021年度のマツダ技報が発表されましたね。

https://www.mazda.com/ja/innovation/technology/gihou/2021/

これについてちょっと色んな感情を抱いたわけで感想というか考察というかなんかそういうのを書きます

電池制御屋さん(?)なのでメインはEV関連のところだけピックアップしてみます。本当は全部やろうと思ったけどエンジンとか分からなくて書くことなかったです。

普段こういうことやらないので読みにくかったら見なかったことにしておいてください。

あと、そもそも私は社員でもE&Tさん販売店さんでもないですので間違ってたりしたらごめんなさい。

去年に比べてボリュームも多く、メインのトピックとしてMX-30のEVが挙げられていますね。マツダ初のEVですからそりゃあ力を入れますよね。(デミオEV?あれは量産されてないかノーカンで)

では順に見ていきます

巻頭言

こういった経営戦略は専門外ですし特にないです。頑張って下さい、という感じです。でも、スモールプレイヤーであることを自覚しているならなぜスバルさんのようにEV開発にトヨタの力を借りなかったのかが不思議ですが極めて高度な経営戦略判断なのでしょう。

私はEV反対でもEV賛成でもなく、ユーザが好きなものを買えばいいと思いますが以下の件、エンジニアとしてずっと疑問に思ってますよ。

https://www.mazda.com/ja/csr/environment/lca/

ところで、技報は直近だと技企が担当ぽいんですがどういう基準で毎年内容とか選んでるんですかね。分かりません。

MX-30のデザイン

デザイン要件絶対いいね?

両開きドア、必要だったんでしょうか。使いにくいと思うんですが…

車格的にこれ以上大きくできないけど四人乗りだし特徴出さないといけないという苦肉の策でしょうか。

私は美術の成績が2くらいしかないのでデザインはよくわかりません。

あ、でも、インテリアコルクの件は誰が思いついたんでしょうか?どういうコルクでどういう工夫がされているかわかりませんが、熱衝撃でボロボロにならないんですかね。ぜひそういうのを技報で取り上げて欲しかったなぁ。

MX-30の紹介

書かれていることは難しくて分かりません。商品企画って大変だと思います

みなさん、一回乗ってみるといいと思います。思いの外普通の車です。

エレクトリック G-ベクタリング コントロール プラス(e-GVC Plus)の開発

制御って難しいですよね。まず式が多くて難しい。

この手の制御実車でのフィーリング評価が多いでしょうからそれだけ走らないといけないだろうし大変だと思います

Fig.4ってどう見ればいいんですかね。そりゃ制御切ってる赤線が0なのは当然だと思うんですが。GVCのリクエストに対してモータリクエストトルクが遅れているのはなにか意図があるんでしょうか。私には分かりません。てかこれ実トルクじゃないのね。

Fig.6ではGVCの有無による加減速が記載されてますね。GVCの有無で横Gは変わらないけど前後方向は、「ターンイン時に減速」「ターンアウト時に加速」と。いやこれ、運転してる人には誤差みたいなレベルのGだけど(たぶん、普通運転してたら0.1~0.4Gくらいでこのデータだと最大0.4m/s^2≒0.04G)いるのこの制御?

この辺で読むのやめたけど、Fig.20はどうかと思う。基準おかしいでしょそのグラフ

MX-30 EV MODELモータペダル開発

この辺も専門外だから流し読み。ペダルの味付けの話かな(適当)

Leafとかi3とか回生がキツくて慣れるまでなんか気持ち悪かったけど、MX-30はその辺まだ運転やすかった気がする。

MX-30 エレキシフトシステムの開発

これもよく分からない。感想としては、エレキシフトである必要ないよねって思う。

電子制御にすれば車側からの介入がかけられるってこと書いてあるけど、ソフトウェアバグリスクを抱えることになりそうだし、そもそもどういうヒューマンエラーを想定してんの?って素人的には思うんですよねぇ。

でもそれよりもあの変なシフトの形状の方が気になる。

BEVバッテリーを使い切る技術

よっしゃ来た。一応電池屋さんだからね、私。

LCA(ライフサイクルアセスメント)の件はいったん不問にするわ。

ふむふむ、LiB温度管理をしっかりして容量と入出力を使い切ると。むしろそれ以外にはないわな。

モータの話はパス、よくわからん

クーリング・ヒータシステム」うん、こういうのでいいんだよ、こういうので。

なるほど、冷媒冷却なのね。Fig.8を見ると温めるのにはヒートポンプ使わないのか。もっぱら冷却専門って感じね。そりゃあ電池が動かないくら寒いときに温めるんだから効率の悪いヒートポンプ使わないのは当然か。Hondaさんはモータ系の冷却水を電池に回して加温にも使ってた気がするけど冷媒だと難しいんでしょう。

ところで、車室内が暖房電池が冷却を求めている場合(真冬の高速連続走行)とかの時はどうなるんでしょうね。ヒートポンプ一個しかないけど。

冬場はヒータを使って電池を温めて充電時間短縮に貢献しているんですね。

あ、そういえば低温の充電についてはこんな記事ありましたよ。

https://insideevs.com/news/486109/mazda-mx-30-battery-pack-heating-issue/

MX-30 EV MODEL への MBD の適用

マツダさん、色んなところでMBDのお話してるのでやっぱりありました。

元々シミュレーション研究やってたんで、モデルベースとかシミュレーションとか僕は好きですよ。

これを見るとHILSがメインなんですかね。HILSって物できてから色々するものだと思ってるんですがこれはMBDなんでしょうか。まぁHILSにはモータとか電池とかのモデルが入っているのでその意味ではMBDか…

ゴリゴリ計算化学なのはないんでしょうか。EVから電池系でその辺もあるかと思ってたんですが。

MX-30 高電圧システム制御の紹介

EVにするにあたって新設した機能説明的な感じですね。

気になるのは4.1の説明で「ユニット通信PCMとの Peer to Peer通信を基本とした」と書いてますね。だいたい今の車載系のネットワークはCAN通信なのでP2PっちゃP2Pなんですが、わざわざ書いてるということは何か特別なことがあるんですかね。

Fig.5らへんでは「充電みたいに特定機能しか使わないときは他の機能を切って余計な電源使わないようにしたよー」って書いてますが、充電してるなら誤差みたいな電流では…?てかまぁ、関係ないユニットそもそも動かさないのは当然だと思うんですが。

4.3はよくソフト系の品質検証である直交表ですかね。私も何度か作成したことあります。MBDでやるにしてもテスト数絞らないといけないからこういう感じで管理してるんですね。でも、機能毎の組み合わせをみるだけでも効果あるんでしょうか?不具合が見つかったとしても書けないでしょうから記載なくても仕方ないか

MX-30 EV MODEL の外部充電システム開発

市場での適合性とか考えると特に大変そう。でも気になるのは「1.はじめに」に書かれている「MX-30は約40分でSOC 80%まで充電できる」の文言

え?40分?いつの車?35.5kWhしかないのに?もしかして急速充電器の出力30kWとかで想定してる?市場の急速充電器は大部分が(少なくとも日本は)50kWだと思うんですが。

外部充電関連やってる人はホント尊敬してますだって仕様書難しいし仕様書曖昧ときあるし。COMBOとか仕様書自体なんか怪しいし。

本文中でも「HILSだけでは発見できない」って書いてあるけど本当にそうだと思います

電圧電池パックの耐振動性開発

またしてもキタコレ案件機構評価はよくやってたからね。

2.1見ると電池電子部品扱いなの…?なんか共振点が被らないように工夫しました的なこと書いてある。

でも電池って重量あるし、特に考慮かいらなそうなんだけど、マツダさんでは電池も細かくモデリングしてるのかしら。あとこれ疑問なんだけど、EVで使われるモータとかってエンジンよりも高周波成分持ってそうなんだけど言うほどないのかね、知らんけど。

2.2には不思議な式が載っている。ダメージ量というのはマツダさん独自概念だと思う。少なくとも俺はいままで振動とか疲労とかの勉強していてであったことはない。疑問なのはFig.4の加速度に通常ひずみに対して使われるレインフロー法を適用していることになってるんだけどあってるこれ??加速度応力は比例関係にあるけど周波数成分考慮しないと意味なくない??まぁ、そこはマツダさん独自手法が隠れてるってことなんだろうか。

そして3.1には気になることが書いてある。

市場の耐振動保証目標の4倍相当を保証している」

いや、とんでもない超過剰品質じゃん。強度半分でいいか車両価格下げてくれ。

3.2はモデルの話。しかし、写真を見るとマツダさんのアッパーケースは樹脂。これどうしているんだろうか。樹脂のシミュレーションなんてあまり精度よくできるとは聞かないし熱とか湿度とかの影響をもろに受けるはず。この辺もシミュレーション出来ているならすごいと思うんだけど特に書かれてない。一番壊れたらやばそうなのに。

MX-30 BEV&Bピラーレスボディー開発

ボデー屋さんじゃないからよくわかんない。でも、MX-30って両開きだから剛性保つの大変そう。

MX-30 の衝突安全性

これも私詳しくないからよく分からない。

2.1には前突時の話が載ってて、電池を守らなきゃいけないから大変だとか。電池ってR100メカニカルショックの試験あるからそれなりに大丈夫だと思うんだけどそうでもないのかな。あるいはR93/94で代替してるのか。ところで、実車たことある人は分かると思うんだけど、MX-30ってモータルームスカスカバカかい支柱みたいなのがあるんだけどあれどうにかならなかったのか。てかバランス悪すぎるだろあの構造。内燃仕様も作る都合で仕方なかったのかもしれないけど他の車みたいに充電器入れとかにすればよかったのに。てか充電口とかフロントに持ってくればハーネスとか安くなりそう(モータ/インバータ系と同じところからバッテリパックに入れればいい)のになんであん構造なんだろう。

3.1は側突の話。MX-30は両開きだから大変そう。ところで、これ全部解析の画像しかないけど、実車のやつはやっぱり画像写せないんだろうか。シミュレーション研究やっていた身としてはシミュレーション完璧でないことは分かっているので逆に不安なんだけど、こういうでか物はシミュレーションで十分ということなのかな。(認証試験実車だろうけど)

マルチパワーソース車における外観品質の造り込み

よくわかんない。たぶん難しい。

Self-empowerment Driving Vehicle の開発

日本語でおk。なんだそれは。とりあえず読んでない。

車両機能材料特性をつなぐマルチスケール解析技術研究

電池EV関係ないけど私が元々分子動力シミュレーションやってたから。

でも、ほとんどMDの話が書いてない。シミュレーション条件も特に書いてないけど、写真を見る限り大した分子数で計算してなさそう。

これで精度が出るんだろうか。その辺を詳しく書いて欲しかった。

この手の計算は結果自体は出る。シミュレーションしてるんだから計算自体はできるものから。ただ、現実実験結果定量的に合わせるのは非常に難しい。定性的傾向は出ても、定量的比較MDでは非常に難しい。

これは経験的なもので私が研究していたのは何年も前だけど傾向は変わっていないと思う。4.1でいちおう妥当検証が書かれているけど、MDの結果については定量的比較されているわけではない。紙面の都合もあるから仕方ないか

おわり

ということでマツダ技報2021年度版の感想勝手考察でした。適当に読んだから読み間違えてたりしたら申し訳ないです。私はマツダ車乗ってるしこれからも頑張ってください。

あと、まだまだ勉強中の身なので技術的な部分でなんか間違ってたりしたら教えてください。

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

2021-11-28

anond:20211128104421

需要が消えるわけじゃないので、コンテンツライフサイクルが縮むだけで、むしろ喜ぶのかもな。

2021-10-17

anond:20211017112040

ごめん5年サポートになったみたい 知らんかったわ

https://asohiroblog.net/windows-10-ltsc-2022-when-coming/

なぜ10年のサポートから5年に変わったのか

Windows 10 Enterprise LTSCは、大体の環境クラウド接続できないような環境運用されており、一般的企業の利用とはかけ離れた特殊シナリオに利用されます

たとえば、何年も機能アップデート適用できないようなデバイスや、インターネット接続しない製造現場プロセス制御デバイスなど、長期的なサポート必要とする特殊システムなどです。

Microsoft社は、LTSC を利用している企業に対して調査したところ、LTSC版導入企業の多くが、10年間のライフサイクル必要としていないことが判明したとのことです。

理由としては、IT技術の変化スピードが速くなっている中、10年前の製品使用する企業が新たな試みや事業開拓することはできないという意見があるとのことです。

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、REST API のような単一の振る舞い(エンドポイント)とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション通信の潮流と、計算資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。

まり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。

なので、以下のコメントちょっと論点がずれてると思いました。

はあ?「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わりますオブジェクト指向とはほぼ無関係です。

https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin

なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない

https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang

しかに、アプリケーション単位アプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います

ソフトウェア記述をまとめるという視点では主にステートレス関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理やすくするという視点ではオブジェクトというのはライフサイクルリソース管理視点が足りず小さすぎる、ということで、オブジェクト指向粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います

個人的にわからなかったのは以下の部分です。

オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない?」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。

当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの?」って思ってしまますオブジェクト指向定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェア組織化すること」なのであれば)。

おわりに

Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

2021-08-27

政府統一Webサイト、暫定版を12月までに公開 製作事業者決定

これは控えめに言って最高

あとは地方自治体統一CMSフォーマットにしてほしいね

DrupalWPより自由度が高いから、高い技術力のあるベンダーだと運用やすいと思う

内閣官房IT総合戦略室(IT室)は8月26日中央省庁情報を集約した「政府統一Webサイト」の構築に向けた実証事業受託事業者が決定したと発表した。落札したのは、官公庁を中心にWebシステム開発を手掛けるANNAI(東京都千代田区)で、落札額は7000万円。実証事業では、サイトデザインルールや基盤作りといった方針を固め、暫定版サイト12月末までに公開する予定。

photo

競争入札落札したANNAI

 落札したANNAIはCMSコンテンツ管理システム)「Drupal」(ドルーパル)を使ったWebシステム開発を手掛ける。内閣府東京大学京都市などのWeb開発に携わった実績を持つという。

photo

ANNAIの受注実績

 これまでは各省庁が個別Webサイトを整備したり、運用したりしていたため、各サイトUIUX一貫性がない上、類似する内容が複数サイトに散在しているなどの課題があった。このため、政府統一Webサイトフォーマットを決め、UIUX標準化統一化を図る。実証間中デザイン統一ルールを整備し、9月に発足するデジタル庁の公式Webサイトを使って検証する。統一サイトへの移行時期についてIT室は「各省庁が契約するシステムライフサイクルなども見ながら、段階的に検討する」としている。

photo

サイトデザイン統一されていない各省庁のWebサイト

 UIUX統一化に加え、英国政府統一サイト「GOV.UK」を参考に、日本政府全体のトップページのようなサイトも構築し、各省庁のサイトリンク付けすることで、少ない手順で国民必要情報を得られる環境も整備する。これまでは一つの情報を得るために、複数の省庁のWebサイトを横断して閲覧しなければならないケースもあったという。数年かけて統一サイトに集約する方針

photo

photo

英国政府の「GOV.UK

 総務省運営し、行政機関へのオンライン申請法令検索機能などを提供するポータルサイトe-GOV」とも機能が重複する可能性があることから政府統一Webサイトとの役割分担などについても今後検討するという。https://www.itmedia.co.jp/news/articles/2108/27/news108.html

2021-07-24

毎年のことだけどオタク臭いのは服のせい、洗濯のせい、みたいな話題が上がる。

そして毎年のことだけど洗濯くらいしてるみたいな反発がある。

毎年のことだけど理解が浅い気がするので(理解が浅いというよりも洗濯エアプっぽいので)少し書きたい。

そもそも洗濯すれば綺麗になるという考えが間違っている。

例えば、一度つかった雑巾はどんな洗濯をしてもまっさら状態には戻らない。

汚れは必ず残る。

服も同じで一度着てしまえば、どんなこだわりの洗濯をしても汚れの全てが落ちるわけではない。

汚れの99.99%が落ちたとしても0.01%は残る(数字適当)。

まり知られていないけれど、汚れは汚れがあると残りやすい。

イメージするなら汚れは汚れの足場となる。

ツルツルな状態では汚れも落ちやすいのだけど、ちょっとした汚れがあるとツルツルじゃなくなり汚れの上に汚れが溜まっていく。

一度目の洗濯で汚れが99.99%落ちたとしても、二度目の洗濯では0.01%残った汚れを足がかりにして汚れの勢力は拡大し、99.95%程度しか落ちくなる。

5回、10回と着て洗濯しても汚れは倍々ゲームで残っていく。そしてこの汚れが匂いの原因となる。

汚れは雑菌が繁殖させるからだ。


勘違いの一つとして生乾き臭がある。確かに生乾きは臭うのだけど乾燥機を使おうが汚れの残った服は着ればすぐに雑菌が繁殖するから臭う。

こうなった服を腐っていると表現する人もいるくらいで、基本的に捨てるしかない。


冒頭に戻るとオタクが臭う原因は、服のライフサイクルが長いからだ。

残念ながら長い時間着た服は落ちにくい汚れが溜まっていて、当然オタクじゃなくても臭うようになる。


どうしても服のライフサイクルを伸ばしたいなら洗剤を変えるか、浸け置きするか、お湯で洗うくらいしかない。

洗剤を変えるなら一度石鹸を試して欲しい。

石鹸アルカリ性タンパク質を犯すので中性洗剤で落としにくい汚れを落とすことが出来る。

ただ、汚れを完全に落とし切ることは不可能であり、こだわりの洗濯をしたところで最終的にはどうあがいても臭うにようになることは知っておいてほしい。


あと、中空繊維など機能性繊維と呼ばれるものは汚れが残りやすく、臭くなりやすいから服を買い換えないオタクは避けた方がいい。

エアリズムが臭くなるってのは汚れが落ちにくいから。

中途半端意識が高いオタクはなぜかアンダーアーマーとかスポーツウエアーを普段着にするけど、夏物のスポーツウエアーは毎年買い替えないと臭くなる。


とにかく服、特に夏物はこまめに買い換えろってこと。

2021-07-18

せっかく英語のつづりに意味があるのにカタカナにするな

からある言葉しょうがないけど、現代海外から入ってくる言葉を無理にカタカナ表記にして、一見日本語っぽくするのをやめろ。

今、リコンファーム(reconfirm: [予約など]を再確認する)が話題になってて、そもそもカタカナとか英語とかじゃなくて「再確認」でええやろと思うけど、どうしても英語で言いたいならreとcon-firmに意味があるわけだからreconfirmって書けやって思う。

まあ発音日本式でもいいけどさ、たとえば「ハロー効果」ってあるけど、日本人ってまずこれ見たたときhelloか波浪と連想するよね?でも実際にはhaloで「後光」って意味。後光って意味を知らずに「はろー効果」っていう言葉だけ覚えるのむずかしいと思うわけよ。「ハロー注意報」と同じぐらい難しいんじゃない?

ホールケーキもさ、hole cakeだと思ってるんだろうな。a whole cakeで「ケーキまるごと1つ」って意味からカタカナにするともう1回英語に戻さないとわけわからなくなる。これは昔からある言葉からしょうがないんだろうけど……そうだからサイクリング(Cycling)、ライフサイクル(Life Cycle)、シリンダー(Cylinder)、サイクロン(Cyclone)、シクロアルカン(Cycloalkane)とかの共通点を見いだせず、1つ1つバラバラに覚えるハメになる。

パルスオキシメーター」とかさ、pulse oximeter[パルスオキシメーター]って併記したりルビふって書けばいいじゃん。pulseが波/振動、oxiが酸素、meterが計測器なんだから、「パルスオキシメーター」ってカタカナにして暗号化する必要ないじゃん。クリアホルダーとかな、clear folderで、clear(透明な)、fold(折りたたんで収納する)、er(やつ)なのに「ホルダー」とか書いてあるから「hold」と勘違いして、PCの「フォルダー」とは全然無関係ものだと感じてる人が多いんじゃないか

こういうのって、せっかく漢字で書けるのにわざわざカタカナにしてるのと同じなんだよな。外国人向けにわかやすくなると思って「誤解を招く発言をしてしまい失礼しました」を「ゴカイをマネハツゲンをシテシマイシツレイシマシタ」みたいに変えたり、「巨漢の男性玄関の扉をぶち破った」を「キョカンダンセイがゲンカンのトビラをブチヤブッタ」って変えるぐらい迷惑。ヨミニクイイガイはモンダイナイノデコウシタヒウキでもドッカイジタイはカノウダトオモウケド。

中国出身の人が、習近平を「シーチンピンってカタカナっぽく言わないで、わからない」っていうふうに言ってたけど、本当に外来語特に英語を誰のためにカタカナにしてるのか理解できない。英語がわかってる人もカタカナにされるとわからなくなる。発音が違うから認識できないし、普段カタカナで話さな英語カタカナにされると迷惑potatoはポディトゥって聞こえるからポテトって言われてもポディトゥのことだと認識できないって感覚。誰にとっても迷惑情報にたどり着きにくくなるだけではっきり言ってうざい。「この記事ポテトだ」って言っても「何が芋なんだ?」ってわけわかんないけど、「この記事potatoだ」なら、なんか日本語じゃない意味があるんだろうなって推測できるじゃん?

「ゴ・ジューのトオ」って書かれて何かすぐわかる?「ケンドウ・モツカナェイ」って書かれて何かすぐわかるか?

もとが外国語カタカナ意味がある。マーチャンダイザーっていうのは「merchandiser商品[merchandise]計画をする人)/ merchant: 商人」だし、インテークマホールド(エンジン空気を取り込む複数の弁[Intake: 吸入、manifold: 多様体])とか、インフォームド・コンセント(Informed[知らされた]、Consent[同意])とかさ。コロナ(Corona: かんむり)でいうとバリアント(Variant: 変異体、vary: に変える/を多様にする)もそう。ジングルベルも「Jingle: チリンチリン」で、チリンチリンって鳴るベルだし、全部意味があるのにカタカナ台無しスペルの1つ1つに歴史意味があるのに消してるんだよなあ。

マジみんな、なんのために今まで日本語存在してなかった外来語カタカナにしてんの。インディビジュアルなオピニオンのタームスでは、エジュケーションにアットオールコントビュートしないかナンセンスだとコンシダレイトなんだが?イディオットマストゲットリドオブでは?ファック。

2021-07-12

ムクドリがいっぱい!

 最近農道のど真ん中のトンビポイント(なぜかよくトンビがトコトコ歩いているポイント)にトンビがいない。最近田んぼ周り、なんならスズメもいない。

 私の車が通ると、慌てて飛び立つのムクドリばかり。ムクドリがいっぱい。あっちもこっちもムクドリ。そして、最近めっきり見ないスズメシジュウカラ

 先日、ちょう久しぶりにオナガを見た。なぜか知らんけど、今、全国的オナガの生息域が山の方へ撤退していて、市街地にはオナガってあまりいないんだって。そう言われてみれば、私の子時代オナガ電線に停まってる姿は、日常風景だったなあ。ここいらでオナガを見ないのは、私の出身地とは違う県だからかなと思っていたけど違うみたいだ。

 6月末に麦刈りが終わってすぐ、田植えが行われた。この地方二毛作普通ないか、春の田んぼの空き日数がものっすごく短い。

 どちらかといえば河川の上流に近い地域(私の故郷に比べれば)なせいか、ここら辺は田植えの時期が遅い。元から遅いんだけど、温暖化や毎年9月頃の台風や水害対策もあるようで、田植え時期が年々遅くなってとうとう6月末にまで先延ばされるようになった。20年くらい前はGW前後だったと思ったけれども。

 そんな訳で、田植えの時期がズレたせいで、田んぼ周りの生き物のライフサイクルもだいぶ変わったんじゃないかなと思う。ヒバリ麦畑に巣を作るので、田植え時期のズレと共に麦刈り時期も遅れたことにより、昔よりもゆっくり繁殖できるのかなあ? 今年は五月半ばくらいまで、ヒバリがピヨピヨしていたはず。

 一方、田んぼに中々水が入らないせいで残念なことになっていそうなのはカエルツバメだ。タガメみたいな水生昆虫もかな。

 春、カエル冬眠から目覚める頃、田んぼにはまだ水がない。五月にカエルタマゴやお玉じゃくしは見られなくなった。

 GW前頃にツバメが渡ってくるが、田んぼに水がないと虫があまり捕れない。そのせいかツバメが多く飛来する時期も昔よりも遅くなってる感じがする。

 最近、すっかり梅雨なので、カエルツバメはめちゃめちゃ元気だ。しかし、ツバメが元の住み処に戻るまであと一ヶ月くらいしかない。ツバメライフサイクルを調べたことがないからわからないけど、確かオオヨシキリは春の繁殖期(3月7月くらい?)に時間の許す限り産卵と育児を繰り返す。ツバメもそうだとしたら、もしかすると1サイクルぶんくらい、繁殖回数が減っているかもしれない。もし巣が敵に襲われたりなどして雛が全滅した場合、巣を作り直しタマゴを産み直す暇がないのでは? 知らんけど。

 我が家にはツバメが巣を作ってくれないので残念。最近ツバメ、民家に巣を作っても壊されるだけだって学習していないか? それか、昼間の住宅街人間の気配がしないので、ここに巣を作っても天敵から守られることはないと思っていそう。うちだけじゃなく、軒下にツバメの巣があるお家が、近所には全然ない。

 そのかわり、幼稚園病院老人ホーム小学校の高い所の軒下にツバメが営巣しているのは見た。近所のスーパーには十年前はよくツバメが巣を作っていたけれど、店の人によって徹底的に壊されてしまうせいか、今ではすっかりツバメが寄り付かない。

 ゴーストタウンには住まない鳥といえば、スズメもそうなのだ人口スズメの数は比例する。私の住んでる地区空き家も多いし昼間誰もいない家が多い。見かけるスズメの数も年々減っている。人間の気配が少ないうえ、カラスハクビシンとヘビが多く住み着いているので、スズメが住むには向いていなさそう。

 数年前、大雨でうちの屋根にあったスズメの巣がベランダに落ちてきたことがあった。当時は私だけでなく、小さかった子供たちも家にいてにぎやかだったから、スズメ的にはうちの屋根の上は安らげる場所だったかもしれない。

 ところが、ハクビシンが近所に住み着いた。うちの屋根の上もハクビシン通り道になっていて、西の雨樋と東の雨樋の両方にハクビシン足跡がついてる。時々、ベランダハクビシンウンコが落ちている。

 ハクビシン通路に営巣は無理なのだろう。去年も今年も雨が降ってもスズメの巣は落ちて来ないし、あっちこっちムクドリだらけになった最近は、スズメの姿をあまり見かけなくなったし、ベランダの物干し竿にスズメウンコがついていることもなくなった。

 田植えが終わって数日しか経たないうちに、田んぼの水面がぶわーっと水草の芽みたいなものに覆われた。そしたら、沢山カモがきた。水深が浅いせいで、せっせとばた足に励んでいるお尻がよく見えて可愛い。けれども、親ガモが仔ガモの行列を連れているのは、いまだ見たことがない。

 毎年、田んぼに水が入るとアオサギが沢山飛来してくる。この地方あんまりシラサギは見かけないんだよなと思っていたが、この二、三年ばかりはけっこうシラサギも見かける。面白いもんで、アオサギシラサギって田んぼの同じ区画に一緒に居ることはあまり多くないようだ。農道を挟んであっちの田んぼにはアオサギ軍団、こっちの田んぼにはシラサギ軍団、と別れて固まりがち。

 今年はアオサギシラサギも飛来が遅いな、と思っていた先日、変わった鳥を見た。すごく脚が長くて、翼の前半分が白く後ろ半分が黒と、色がパッキリ別れているので、アオサギでもシラサギでもないと思う。ツル的な何か? でも、ここいら辺でそんなツルっぽいものを見るのは、初めてだと思う。

 ところで、今年は1羽もキジを見ていない。キジ! 居るんですよ。田舎とはいえそんなに大自然豊富な所じゃないのに。だけど、今年はまだ見ていない。

 以前、この町の中だけどもっと南の方に住んでいたとき、庭によくキジがくるお宅が当時の私の住み処のすぐそばにあった。そこんちの庭が私の家の窓からよく見えたので、キジがくると飛んでくまで眺めていたなあ。

 うちからキロ先に、かなりでかい河があり河原人間用にカスタマイズされていない部分にはかなりのワイルドネイチャーが広がっている。どのくらいワイルドかというと、数年前まではよく鹿や猪が出た。ここ数年はめっきり猪注意報が発令されないけど、たぶん朝っぱらから堤防付近人間がやたら走ったり自転車こいでたり犬の散歩しまくってるからじゃないかなあ?

 河原に行ったらハイタカが見れるかなあ。ハイタカ一度も見たことないから見てみたいよなぁ、と思うんだけど、河原に降りる階段の手前に大きな住宅街があって、そんな所を歩いていると知り合いに「あんた何してんのこんな所で!?」と言われまくりそうなので、近づけないでいる。

 河と鳥で思い出したけど、この町に移り住んでから一度もカワセミを見ていない。故郷にはカワセミがいて、大してきれいでもないむしろ汚いドブ川にかかる橋の欄干によく停まっていて、魚獲ってた。

2021-07-11

anond:20210711103618

そのライフサイクル知ってる。

大きな声は自信のあらわれ。とても頼りになる。

2021-07-10

anond:20210709233114

待遇が良い会社の探し方 / Engineeringと組み合わせると儲かるスキル

色々あるけどいくつか紹介したい。

待遇が良い会社の探し方

サービスクオリティが上がると無茶苦茶儲かるビジネスモデル

そうすると、Amazon全体の売上が+0.1%上がる。実際にはEC以外の事業もあるし.com以外もあるからそこまで単純じゃないけど、まあ+0.0何%単位で上がる。

Amazon2020年の年間売上が3860億ドル(≒41兆円)だそうなので、これは物凄い収益性改善になる。+0.01%改善で410億円の売上げアップである

こういう会社は、高待遇を出す事ができる。だって儲かるので。

GoogleとかAppleとかFacebookも同じ様な構造を持ってる。金融業とかもそういう構造を持ってるときがある。

一方で、儲かってはいるけど別にサービスクオリティが上がっても売上が大して増えない会社というのもある。

例えば、特定業界利権を独占してるような会社は、別にクオリティが高くても低くてもあんまり売上に影響はない。こういう会社社員に高い給料を支払うインセンティブが乏しい。それよりもロビー活動お金を使った方が儲かる。

とにかく市場が伸びてて人がたくさん必要会社

新しい市場が立ち上がった直後は物凄く儲かる事がある。(マーケットライフサイクルとかで検索してほしい)

例えば、最近日本だと2010年代ソーシャルゲーム市場の立ち上がり期とか凄かった。

昔のソシャゲ技術的にもクリエイティブ的にも簡素だったから1本2000万円とかで開発できた。

それでヒットすると平気で月商1億円とか超える。

儲かるのでどんどん新しい会社が参入して人を雇いまくった。

人をどんどん雇っても儲かるので、高待遇でも採用する。いわば人材の競り合いで値がつり上がっていく状態

こういう市場でも高待遇が得られる。

ちなみに、こういう市場はすぐ飽和する。

今ではソシャゲ1本の開発費は軽く10億円以上の掛かると聞いた。

から、こういう市場で高待遇が得られる期間は短い。タイミング重要

最近だとAI / Big Dataブームとかがそれかな。

自分場合は、そんな感じで「成長期の市場」で待遇を上げた後、その市場がしぼむより先に「サービスクオリティが上がると無茶苦茶儲かる会社」に転職したって感じのキャリアです。

エンタープライズ

あと、自分は良く知らないけどエンタープライズ系のIT企業待遇良いっぽい。

MicrosoftとかSalesforceとかね。なんでこういう会社って高待遇だしてるんだろう。知ってる人いたら教えてプリーズ

Engineeringと組み合わせると良いスキル

端的に言えば、Managementか営業と組み合わせると良いと思う。

Engineeringが分からないEngineering Managerとか機能しないので需要がある。

そして、Engineerの中でManagementを好んでいてしかも適正がある人が少ないので供給が足りてない。

需要供給を上回ってるので価格が上がってる。

営業についても同じで、技術が分かってないと出来ないタイプ営業必要会社を探すと良い。

ぶっちゃけた話しをすると「Engineerがバカにしがちだけど、実はビジネス重要仕事」っていうのが色々あるのでそういうのを探すと良い。

2021-06-06

anond:20210606135419

どうだろう。貯蓄が直線的に増え続けるとは限らないし、ライフサイクルによる急な出費なんかもあり得る。意外と、何歳の時にどれくらい収入・出費があるかぱっとイメージできないでしょ?

あとはこのご時世、資産を貯蓄だけで持っているのはもったいないなんてことも考えられる。節税しつつ金融資産分散して、少しでも増やせれば老後への進捗率も高まるというもの

そこで我々、ファイナンシャルプランナー金融営業の出番ってわけですよ、ぐへへ。

2021-05-13

anond:20210513112747

ビットコインが下がる時にアルトコインが上がる場合もあるので一概に言えない。

しかし、いくつか言えることもある。

まず、

基本的にどの市場でも、先導している銘柄上下すると釣られて他の銘柄上下しがちだ。これは「釣られている」としか言いようがない。

・どの銘柄にも影響する事態が起きれば全ての銘柄が同時に上下する。コロナなどはまさにそれ。

市場ライフサイクルという観点もある。

市場全体が上昇に向かう時、初めに投資されるのは一番人気の銘柄だ(同語反復気味だが)。大量の資金と大量の注目を集めて市場全体の上昇を先導していく。一番人気の銘柄資金が過剰供給されているとなると、徐々に人気下位の銘柄市場参加者の目が向いて、「まだあまり投資されていないからチャンスだ」と、投資先が変わっていく。そうして市場の各銘柄資金が順に巡っていく。

市場全体の銘柄がまんべんなく投資過剰気味になる頃には、投資過剰と判断されたそこここの銘柄でプチバブルがはじけ始める。

・最終的に市場全体が下落を始める時も、最初に落ち始めるのは先導銘柄のことが多い。先導銘柄が落ち始めれば釣られてその他の銘柄も落ち始める。売りが売りを呼ぶ展開になって市場全体が急落する。

2021-05-06

今時の若い者は青春を残しなさい

デジタルデータ簡単に消える

新しいものをどんどん乗り換え乗り換えで商品ライフサイクルは短い

タピオカも鬼滅も過去のものになりつつある

長く続くサービスは変わり映えせず青春感は無くなる

2021-01-08

製品開発の仕事してるんだけど

コロナで人を呼べなくなったのでプロトタイプ検証ができない

前世代の製品ライフサイクルもあるので納期を変えるのは難しい

このままだと検証されていない製品を作る羽目になる

絶対同じ悩みを抱えている開発者って多いと思うんだけどみんなどうしてるの

2020-12-18

炭素EVっていうけど。

電池作ったり使い終わった電池処分したりするときCO2を大量消費するようじゃ本末転倒だよね。

ましてや充電するための電気の発電に大量のCO2使っていたりとか。

製造から廃却までのライフサイクルで考えないと、今の日本原発事情みたいになると思うよ。

ポピュリズムだけで戦略を決めるべきではないと思うんだ。

2020-12-15

忠臣蔵オワコン談義

なんか一周回って「会社に忠誠を誓って滅私奉公しても報われない社会になったから」

もしくは「もう滅私奉公時代じゃないんだよと忠臣蔵オワコンにしたい派遣会社陰謀

あたりが正解でいいんじゃないのって気がしてきた

 

さておき12月前半~中旬一般社会人がクソ忙しい時期にガッツリ参加必須イベントぶちこんでくるソシャゲ業界の慣習

そろそろ空気読んで1月後半~2月とか時間を作りやすい時期を選んでくれませんかね

残業して土日も仕事して家の中の買い物や掃除も詰まってる中で毎日ログイン毎日大型イベント巡回攻略情報漁って挙句オンラインイベント参加煽り

そろそろ死ぬよ? 課金社会人死んじゃうよ?

賞与狙いの課金アイテム販売は今まで通りのスケジュール我慢してやるから

せめてお前らのメイン顧客ライフサイクルぐらい把握してくれっつーの

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