「アーキテクチャ」を含む日記 RSS

はてなキーワード: アーキテクチャとは

2022-05-21

零細Saasベンチャーから競合のSaasメガベンチャー転職した

表題の通り。当方エンジニア

前職と比較すると平均技術レベルマジで変わったように感じる。

前職だとクリーンアーキテクチャやらCI/CDやらは言葉意味すら知らない人も多かったけど、

今の職場だとイケてるエンジニアは当然知ってるよねみたいな概念は最若手含めてほぼ全員理解してる感じ。

FargateやらKubernetesやらGraphQLやらAWSやらGCPの聞いたことないサービスやら新しい技術は常に吸収して実戦投入してて、

凡人エンジニアである俺にはついていくだけでも結構きつい、でも乗り切ったら市場価値めっちゃ上がるんだろうなって感じもある

コード品質についても常に議論を交わしてて、コードレビューの厳しさとか今までやってきた会社とは比にならないレベル

命名として若干ニュアンス違和感があるとかUT項目の境界値が1ずれてるとかでもどんどん突っ込まれるし、「よくわかんないけど動いてるから良し!」みたいなのは容赦なく潰される。

ペアプロモブプロしょっちゅうみんなやってる。クラス設計に関する議題だけの会議とかも開かれたりする。

会社の規模も超大手ってわけじゃないけど俺が関わってるサービスの部分だけでも前職比較だとサポートとかデザイナーとか含めると10倍とは言わないけど近いくらはいる。

開発手法アジャイルの規模大きい版が実施されてて、それもなんちゃってじゃなくてちゃんセオリーに則ってる形で管理されている。



ただ「これだけの人数いて、これだけ高い技術力があるのに作ってるサービス自体は俺が極少人数で枯れきった技術スタック使って作ってた前職のサービスと大して変わんなくね?」っていうのもまた感じた。

そら管理コストがかかる分10倍の人数がいたって開発速度が単純計算10倍になるとは思ってないけど、前職で作ってたサービスの2倍分も価値提供できてんのかなこのサービス?っていう感じというか……

前職は優秀な人を放任してタイムアタック的にひたすら高速リリース繰り返すみたいな感じで、(一応セキュリティ周りとか品質とか最低限はちゃんとしてたよ)管理コストが少ない分一人あたりの生産性は高かったと思う、属人化ってことだからそれが良いとは思わんけど。

動いてるものが同じなら採用技術オンプレだろうとFargateだろうとGraphQLだろうとRubyだろうとウォーターフォールだろうとアジャイルだろうとユーザーにとっては関係ないし、

NetflixとかGoogleみたいな世界ならともかくとして、世の中の大半のシステムってそういうことじゃないじゃん?

難易度の高いイケてる技術スタックを使う=必然的エンジニアのお賃金が高くなるってことだから経営者視点から見てもこういう選択って果たして正しいのかなぁって。

なんならエンジニア賃金上げるための利権的な使われ方なんじゃっていう気もしてきた。

どう思うよ。

2022-05-16

anond:20060923210701

はてな匿名ダイアリー」は2006年9月サービス開始だそうで、ウェブログサービスとしては最古参になってますね。

匿名ブログを書けるというのは結構すごいんではと思ったり。「2ちゃんねる」化してわけでもない(と思うのは)アーキテクチャの為せる技ゆえかな。

このサービスはずっと続いて欲しい。

2022-05-09

はてブが今のような感じになったのはアーキテクチャが悪かったのか?

比較高学歴だったり、理系が多いとか、ソフトエンジニアが多いからかチームの雰囲気を良くするためにとか、

こうすれば良くなるってのを比較的見ている層だろう。

5ch、ヤフコメとは違うクラスターだが、自浄作用もなく手に負えない集団になった。


何が悪かったのか?


目利きに頼る設計だったからか?

はてブ価値の1つは「どこからそんな優良記事を見つけてきたのか」ってことだと思うが、

誰も大量のゴミから見つけてくる目利きをしなくなったからか、

どこでも盛り上がっている記事について斧を投げる。

スルーすれば良いはずが、わざわざコメントを書いて上位になる手助けをしている

(記事を書いている人をタイトルにつけてくれってコメント付くようなものは、スルーでいいはずだが目立つような行動をしてしまっている)


利用者は、それなりに年を取ったはずだが、どうだろうか。

2022-05-08

ギークためのChromebook入門

エントリ目的

ライトコンピュータユーザ一切合切無視してギークギークのため情報共有するためのエントリ
感想はてブへ、質問トラバに投げれば誰かが答えるんじゃないか?(他力本願)

開発者は初手でデベロッパーモードにするべし

セキュリティ懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
用途中でデベロッパーモードにするとストレージファクトリリセットされるので注意。

ハードウェア選択

Webで完結するのであれば低性能機で問題ない

Webエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的タブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ

ただし、Webベースゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。

ChromeOSハードウェアスペックで殴ると快適なのは変わらない

Core i7クラスCPUや16GB以上のワーキングメモリSSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラス3DCGAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。

Android Appレイヤーを中心に運用したいと考えてるならばx86_64機は非効率

Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。

1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者マジで底辺しか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。

しっかりリソース管理できているChromebook向けビルドアーキテクチャによらずサクサクなのでクロスプラットフォームビルドマジで開発チームの腕が如実に反映される。

ちなみにSnapdragon 8 Gen1なChromebook公式発表は今のとこ無いのでAndroid Appレイヤーブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。

Android Appレイヤー

macOSiOSレイヤーよりAndroid App数は多いし操作性は良い

Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。

Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。

GPS事実上ほぼ機能しない

ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバ接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。

USB over MIDIが使える

Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能ものの、iOS比較してレイテンシがそこそこ大きくDTM活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。

そもそも既存Android AppなDAWVSTやLV2などの外部プラグイン対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか?
ただし、DAW単体でDTMを完結するとレイテンシほとんど気にならなくなるので絶対Android AppでDTM不可能というわけでもない。

Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。

ChromeOS向けマルチタスク対応していないとAndroid Appはスリープする

ChromeOS向けマルチタスク対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。

まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの?とは思う。

ICT教育日本中学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスク考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか

Linuxレイヤー

実体LXC/LXD

LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも?

デフォルトイメージはChromeOS向けにカスタムされたDebian
別のLinuxディストリビューションへ置き換えることも出来るが一部機能制限される可能性がある。

IMLinuxレイヤー側で用意する必要がある

ChromeOS動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊ものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難

USB Pass Throughが使えない

ChromeOSマウントされたUSB機器、というかシリアル接続された機器Linuxレイヤーから認識しない。
見掛け上で接続されているハードのすべてはソフト仮想接続されているだけなので、一部経路から上手く認識しなかったりする。

まりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーゲームやろうと思ってもUSBゲームパッド動かないのでマウスキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。

それぞれが独立しているLinuxレイヤーAndroid Appレイヤー相互認識しない

言うなればAndroid Appレイヤースクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリキャプチャしようと思ってもキャプチャできず撮像は暗転している。

ChromeOSホストLinuxレイヤーAndroid Appレイヤーゲストなのでそりゃそうなんだけど気付かないとハマる。

LinuxレイヤーDockerを構築するのはやめておけ

LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境Chromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
まりゲストOS制限KVMも引き継ぐ。

ただしこれはDockerが導入できないという意味ではない。
自分解決する気概があるのならばDockerは便利に使える。

Web開発であれば必要十分

CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。

GIMPInkscapeなども動くけれどデザイナーAdobe使いたいんじゃなかろうか?

Chrome OS向けAndroid Studioが存在する

Android App向けIDEAndroid StudioはChromeOSけが存在するのでAndorid App開発が可能
しかデベロッパーモードでなければエミュレータや実機デバック制限が発生するので注意。

3DCGゲームを作りたいのであればGodot

UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスMITなので商用利用だってイケる。

3Dのほか2Dゲームもいける上に、最近IDEよろしくマウスポチポチUIを作れるし、軽量動作物理演算日本語ドキュメントまで揃っているので中高生ガンガン使える素晴らしいIDEだ。

総評

浅い部分は気軽だが深い部分は非常に難解、それがChromebook

浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザ視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。

しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇Linuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。

そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。

ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ

追記

少なくともGoogleエコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースアップデート無償で得られ、Gentoo LinuxベースなChromeOS潜在的マルウェア絶対数がそもそもWindowsMacよりも少ないという利点がある。
Bluetoothイヤホンヘッドフォンヘッドセットも使えるし、NestスピーカーNest HubNest Camを持っているのであればGoogleアシスタントからコントロールが容易なのは想像が付くだろう。Android AppレイヤーGoogleホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い
もちろんこれは選択するハードによるもの指紋認証ロックを解除することまでできる。

Googleエコシステムへ浸かっていてGoogle個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言欠点表現することが可能だ。


Chromebookじゃなくても別に良くね?」


そう、ギークLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギーク別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OS別になんだって良い。
このエントリは単にChromebookという新しい沼ギークの皆さんをご案内しているに過ぎないのだ。

2022-05-06

anond:20220505201518

言うても、メインフレームトランザクション作ってたようなレベル技術者は扱う技術がかなり変わってるけど、

アーキテクチャOSミドルウェア作る層の扱う技術としては、そもそもレイヤーで変わってないじゃん。

2022-05-05

anond:20220505202147

トレンド追うのは大事だぞ。10選択肢があって、技術選定するのと、2しか知らないで選択するのでは訳が違う。ただトレンドから使うっていうのはエンジニア失格。

スタートアップマイクロサービスアーキテクチャーやってますっていうのは最悪の悪手例。ビジネスチームとかすげーかわいそうだと思う。

2022-05-03

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

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

590あとで/4204users 【詳しすぎる2週間】親の死亡後にまずやること(行動チェックリスト付) | まごころ相続コンシェルジュ

291あとで/1560users Google製のJavaScript教育ツール「Grasshopper」は基礎から学べて初心者に優しい!【どれ使う?プログラミング教育ツール】 | 窓の杜

272あとで/1859users 無料コーディング練習所 | 未経験からWebデザイナーへ!

220あとで/1327users 【翻訳Googleエンジニアソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG

201あとで/1017users 30 分でわかる!アルゴリズムの基本 | E869120 | SpeakerDeck

191あとで/1365users Wi-Fiトラブル解決に便利! Windowsの隠れ便利機能Wlan Report」を活用しよう【イニシャルB】 | INTERNET Watch

175あとで/888users Web開発者もっと安全ウェブサイトの作り方」を読むべき - Flatt Security Blog

171あとで/2593users (追記あり) 10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp

164あとで/849users AWS初心者向けの教材まとめ、AWS日本法人が公開 | ITMedia

162あとで/1231users 【試し読み】書店員さんから反響! 精神疾患を抱えた妻の介護仕事…約20年にわたる苦悩の日々を綴った傑作ルポ『妻はサバイバー』|朝日新聞出版さんぽ|note

159あとで/935users 機械学習が独学できる日本語Youtube難易度別まとめ - Qiita

152あとで/961users 8時間を0.01秒に短縮 「アルゴリズムの素晴らしさが2分で分かる動画」が今すぐ勉強したくなる分かりやすさ | ねとらぼ

142あとで/889users 文春オンライン記事分析を支える爆速ダッシュボードを作るまで|Shota Tajima|note

141あとで/2006users さよなら絵梨 - 藤本タツキ | 少年ジャンプ+

140あとで/1138users 新電力中の人です。すべてをお話します | anond.hatelabo.jp

136あとで/1094users 『ゴールデンカムイ』全話無料! | ヤンジャン!

135あとで/780users Docker創始者らが開発、ビルドテストデプロイ自動化ポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に | Publickey

132あとで/575users フロントエンドエンジニアが知るべきキャッシュ理解する | カーーズ | Zenn

132あとで/1232users みんなが知ってる『ちょっとのコツでめっちゃ美味しくなる、楽になる』みたいなの教えて→全然知らなかった有益情報が集まる | Togetter

131あとで/679users 【個人開発】正規表現を学ぶ狩りに出ませんか?モンスターを倒しながら正規表現が学べるゲームRegex Hunting」を作りました - Qiita

124あとで/1217users 先輩に「何かタメになる話してくださいよ〜」と無茶振りしたら『Language Reactor』という2言語字幕を同時表示できるChrome拡張機能を教えてもらった | Togetter

124あとで/1254users 育休中に相方がめちゃくちゃ売れた|酒寄さん|note

120あとで/1114users Google Analytics(UA)が使えなくなるのはどのくらいヤバくて、いつまでに何をしたら良いのかの話。 - フジイユウジ::ドットネット

120あとで/598users 電子情報学特論:Chromiumアーキテクチャを解き明かす | Kentaro Hara | Google Slides

119あとで/1242users 僕がたどり着いた最強パリパリチキンの焼き方→上手に焼くポイントも「鶏肉好きとしては是非とも取り入れたい」「最高のライフハック」 | Togetter

118あとで/866users 「全クリエイターに広まってほしい」文化庁質問に答えるだけで『著作権契約書』が作れる超便利なツールを作っている | Togetter

116あとで/897users ちょっと触ったら休日が丸2日消失した 個人2022年ベストゲーム「TUNIC」を全力で推したい | ねとらぼ

115あとで/798users 結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ?と思ったとき選択肢 - Qiita

112あとで/494users 『良いコード/悪いコードで学ぶ設計入門 』を出版します|ミノ駆動note

109あとで/522users 予防に勝る防御なし - 堅牢コードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022

109あとで/1047users (続き)10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp

はてブではあまり見かけなかったタイプの商用っぽいけど大手メディアじゃなさそうなサイトが上位に入った

2022-05-01

ラジオ聴きながらプログラミングって難しくない?

ラジオを聴きながら、というか例えば芸人エピソードトークとかの内容をある程度理解しながらプログラミングってできるもんかな?

例えばテトリスしながらラジオの内容理解するのは多分余裕だし、筋トレしながら、運動しながらもまあ大丈夫

掃除しながらとか料理しながらも自分はよく聴く

でも例えば目で小説を読みながら別軸で別の小説を音声で聞く、は多分大多数の人間には無理な気がする。

文章書きながら~もちょっと自分には難しい、複雑な構成を書いていて頭のリソースが書く方に使われている場合は音声で言っている内容の理解度はめちゃくちゃ下がると思う。

プログラミングしながらの場合はどうなんだろう。

例えばプログラミングと言っても「リファクタリングとして○○クラスメソッドをXXクラスに移して決まった法則に従ってメソッド名を変更する作業を100回繰り返す」というようなあんまり知的労働を伴わないような単純作業ならまあ多分できる。

100回くらい同じ仕組みを作ったことあるシステムの構築、とかでもできなくはない気がする。

ただゼロイチでアーキテクチャを構築するとか、調査を含めた不具合解消とか、英語ドキュメント読みながらの検証作業とか、これはもう小説読みながら別の小説聴く、に近いものを求められる気がする。

ただ俺の脳のスペックだと難しい気がする、ってだけで他の人はどうなのかなってのもよくわからん

在宅ワークが増えて「音声で何かを聞きながら仕事をする」ことって昔に比べると増えたと思うんだけど、「プログラマーラジオを聞きながら仕事をする」ってできるものかね?

2022-04-29

anond:20220429190856

そりゃ当然で、今で言うアーキテクチャ設計とかの考え方で何処からハード制御でどこからソフト制御か変わってくるので実体としては境目はグラデーションなんだよ

計算機が突然まるっとソフト制御できていたわけでなくハード制御からソフト制御へ移行していった関係でそんなようなことになってる

2022-04-25

anond:20220425171449

偉い人の思う技術力がコーディングのものじゃなくてアーキテクチャ設計とか、それを仕様書に落とすことなんじゃね

コーディング技術じゃなくてバイトかに頼む作業ってイメージなのでは

そのバイトを動かす能力技術力ってことなんだと思う

2022-04-19

anond:20220419200107

参考ページ(続き)

タイトル
URL
eid
*21マザーボードフェーズの話 - PC Watchhttps://pc.watch.impress.co.jp/docs/news/1152140.html373849521
*22PCエンサイクロペディア:第8回 PCエンジンプロセッサ」の歴史(2)~性能向上に勤しんだ486/Pentium世代 2. RISCアーキテクチャに近づくPentium - @IThttps://atmarkit.itmedia.co.jp/fsys/pcencyclopedia/008procs_hist02/procs_hist04.html4701261286880018114
*23トレンドの光るPCはハデなだけではつまらない ~【DIY PC 08】マザー&ケースの機能活用して作るイルミネーションPC - PC Watchhttps://pc.watch.impress.co.jp/docs/news/1148442.html372842665
*24【笠原一輝ユビキタス情報局AMDRyzen ThreadripperがIntel危機感に火をつけた ~Intelの18コアのSkylake-X急遽投入の背景にあること - PC Watchhttps://pc.watch.impress.co.jp/docs/column/ubiq/1062361.html347169693
*25【Hothotレビュー】待望の第12世代Coreついに発売! ベンチマークで見るその実力 - PC Watchhttps://pc.watch.impress.co.jp/docs/column/hothot/1363614.html4710698281882741314
*26見れば全部わかるDDR4メモリ完全ガイド、規格からレイテンシ、本当の速さまで再確認 - AKIBA PC Hotline!https://akiba-pc.watch.impress.co.jp/docs/sp/1231939.html4680749088087636034
*27新登場の32GBメモリモジュール、使えるチップセットは? : AKIBAオーバークロックCafehttp://blog.livedoor.jp/ocworks/archives/52098537.html-
*28シングルチャネルおよびマルチチャネルメモリー・モードhttps://www.intel.co.jp/content/www/jp/ja/support/articles/000005657/boards-and-kits.html374335238
*29特集】同じSSDでもこれだけ違う。SATAから第4世代PCIeまで速度差を検証 - PC Watchhttps://pc.watch.impress.co.jp/docs/topic/feature/1386511.html4715121623230645378
*30SSDの選び方:SLCMLCTLC、QLC、PLCの違いを解説 | ちもろぐhttps://chimolog.co/bto-ssd-slc-mlc-tlc/369046698
*31消耗品と有寿命部品について : NEWS: ビジネスPC | NEChttps://jpn.nec.com/products/bizpc/info/pc/cosmable.html4668458216799596930
*32M-DISC - Wikipediahttps://ja.wikipedia.org/wiki/M-DISC260312391
*33PS5にみる物理メディア終焉 - ITmedia NEWShttps://www.itmedia.co.jp/news/articles/2006/17/news056.html4687255935115670114
*34特集】チャタってしまった10年物マウスが3,000円で完全復活! ~ドスパラマウスボタン故障修理サービス」に依頼してみた - PC Watchhttps://pc.watch.impress.co.jp/docs/topic/feature/1160250.html4662344022334670305
*35ロジクールトラックボールマウスM570を自分スイッチ交換修理した方法 - ネットの海の渚にてhttps://dobonkai.hatenablog.com/entry/Logicool-m570-repair4680507411203374530
*36マウスの左クリックおかしくなったので分解修理した : トイレのうず/ブログhttps://1010uzu.com/blog/overhaul-mouse-failing-in-left-click304301040
*37Logicool MX300 Optical Mouse M-BP82のメンテナンスhttps://orz7.web.fc2.com/rat/log/mx300-optical-mouse-m-bp82.htm-
*38加水分解の止め方、ベタベタの除去 - 黒色中国BLOGhttps://bci.hatenablog.com/entry/kasuibunkai4697762672020785762
*39Mouse Roller Wheel Durable Optical Pulley Repair Parts for Logitech MX510 518 G400|Replacement Parts & Accessories| - AliExpresshttps://www.aliexpress.com/item/1005003407488009.html-
*40ASCII.jpWindows 11アップグレード可能CPUは基本はやっぱり第8世代Zen+以降になりそう? (1/2)https://ascii.jp/elem/000/004/061/4061479/4704977165657723746
*41Microsoft2022年Windows 11高速化に注力すると宣言 - iPhone Maniahttps://iphone-mania.jp/news-420988/4711489752449241922
*42BIOSからUEFIへ BIOSはなぜ終わらなければならなかったのか:“PC”あるいは“Personal Computer”と呼ばれるもの、その変遷を辿る(1/4 ページ) - ITmedia NEWShttps://www.itmedia.co.jp/news/articles/2202/24/news067.html4715865033555686850
*43マザーボードのCSM(Compatibility Supported Module)を有効にする方法ASRockマザーボード) | TSUKUMO サポートFAQhttps://faq.tsukumo.co.jp/index.php?solution_id=13164709334416996014018
*44そうだ、グラフィックボード増設しよう! でも、その前に... - ツクモ福岡店 最新情報https://blog.tsukumo.co.jp/fukuoka/2015/08/post_116.html298062585
*45備忘録】mbr2gptコマンド実行後の回復環境消失対応方法: YOSIの小さな旅の記しhttp://kykyblog.air-nifty.com/blog/2021/09/post-802f79.html-
*46Windows1011でDiskPartコマンド使用する方法https://www.diskpart.com/jp/windows-10/diskpart-windows-10.html4705642648092693218
*47アライメントhttps://www.pc-master.jp/mainte/aft-hdd.html4699883528408540354
*48Windows 10Administrator ユーザー有効にする方法ラボラジアンhttps://laboradian.com/enable-administrator-on-windows10/-
*49Windows 10 は既定で OneDrive にファイルを保存するhttps://support.microsoft.com/ja-jp/office/windows-10-%E3%81%AF%E6%97%A2%E5%AE%9A%E3%81%A7-onedrive-%E3%81%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E4%BF%9D%E5%AD%98%E3%81%99%E3%82%8B-33da0077-770c-4bda-b61e-8c8e8ca70ac74687214936939669538
*50OneDriveのドキュメント・ピクチャデスクトップバックアップ同期をやめる手順 | パソコンかば堂本https://ikt-s.com/onedrive-backup-skip/-
*51Windows8をインストールしたSSD寿命を延ばす対策 | ZAKKINKShttps://zakkinks.com/windows8_ssd_hack/168055874
*52Windows10SSD寿命を延ばす対策第一回】 | ZAKKINKShttps://zakkinks.com/windows10_ssd_optimization/268597709
*53Windows10SSD寿命を延ばす対策【第二回】 | ZAKKINKShttps://zakkinks.com/windows10_ssd_optimization2/276446264
*54新しいコンテンツの保存先を変更する ( アプリインストール先変更方法を例に ) | ドスパラ サポートFAQ よくあるご質問お客様の「困った」や「知りたい」にお応えします。http://faq3.dospara.co.jp/faq/show/4557?site_domain=default369837603
*55一方、ふうえんさんちでは… SuperfetchとPrefetchについて~(1)http://blog.phooen.com/blog-entry-39.html217075081
*56windows10でAppData/Localを別ドライブへ移動する | ピースペースhttps://nasu38yen.wordpress.com/2015/11/19/windows10%E3%81%A7appdatalocal%E3%82%92%E5%88%A5%E3%83%89%E3%83%A9%E3%82%A4%E3%83%96%E3%81%B8%E7%A7%BB%E5%8B%95%E3%81%99%E3%82%8B/274477044
*57mutaguchi on Twitter: "Win10スタートメニューショートカットファイルとの関係性が未だにいまいちわからんショートカットファイル編集すると、スタートメニューから消滅したりするんだよなぁ。挙動が分からなくて困る。" / Twitterhttps://twitter.com/mutaguchi/status/1298882977863270406-


追記

トラバコメブクマしてくれた方々に感謝。人の興味を惹く内容を投稿できて良かった。

以下、説明しようと思ったトラバブコメに返信。

hoimin-densetsuさんのセルクマ

ブクマエントリのdata-entry-createdと件のブクマの日時分が一致してるが、濡れ衣だ。

初代Core…Allendale(65nm、Meromアーキテクチャ)か

Core第1世代Nehalem)のつもりで書いたが、Core Duoとかもっと古いのを失念してたので本文修正

こんだけ知識あるおじさんがお金無いはずがない

技能金銭にできない人々を我々は見てきたはず。

電源は新品がいい

古い電源でもイケるのではと憶測してそれを実証してみたいと思わなければ、自分もきっとそうした。

10年前にHDD 3TBってめちゃくちゃ高級品だと思う

PCのだいぶ後で、TV録画のために買った外付HDDが元。ケースが死んだので、中身をデータドライブとして使っていた。

一体何にパソコンを使っていたのか

はてブと5chとTwitterとそれらの引用元を隅々まで読む作業動画漫画鑑賞、Paradoxゲーム相場観察。

メインPC別にあるんじゃないの

上記用途しか使ってないので、他に良いPCを買うのは勿体なくてできなかった。

この増田んちのジャンク置き場ヤバそう

Socket7M/Bとかその頃のPC雑誌とか、必要な人がいたら譲るんだが。

参考文献57まであって草

玉石混ぜて文章量を稼ぐムーブ

学生さん可能性も

老眼の始まったアラフォーで、日本人学生で、増田ユーザで、最近10年ぶりに自作PCをしたという積集合が空でない可能性とは。

無欲ではなく最高の贅沢なんだろね

過ぎた吝嗇は強欲と執着の発露だとは思う。

ヒキニート疑惑も抱いている

他の人は言うのを遠慮してたのに。

その間も知識アップデートはあったはず

生憎、数年前のRyzenショックを見逃す程度には、自作PC事情への関与が薄かった。

なんでブログで書かなかったの

完璧主義自意識過剰怠惰のせいでブコメすら継続的にできない性質なので。今回は衝動的に長文を書きたくなって投稿した。

多分友達になれる

追記を見たら、その気が薄れるのではないかな。

ケチオブドケチ

支出抑制しようとする情熱収入を増大させる方に向かって欲しい人生だった。

古老の趣味やな

初老のおじさんに何てことを。

机の周りもめちゃくちゃ綺麗にしてそう

偏執狂は恐ろしく整備された部屋か恐ろしく汚い部屋かどちらかに住んでいるものだと思う。

「これ、安かったんよ」と自慢している大阪オカン共通する

そういう行為から抜け出せないならそうすることが許容される愛嬌は持ち合わせたいものだねと。

貧乏人はなぜ労力や時間という「コスト」を無視するんだ

考慮した上で優先事項から排除する性分なんだ。

2022-04-07

ゴマ化すは英語でsesamizeというネタを思いついた

そこで、sesamizeという単語について調べたところ、以下の用法が見つかった。


誤魔化す

そんなものは、どうにでもsesamize

https://society4.5ch.net/test/read.cgi/agri/1060453713/594

大抵のおやじギャグは、検索すれば先例が見つかるものだ。sesamizeも例に漏れず、2006年2ch書き込みに先例が見つかった。


胡麻胡麻油)をかける

https://twitter.com/i/status/453161537243332609

https://twitter.com/i/status/1319257152012206080

料理の味を胡麻で誤魔化すというギャグとも絡めた高度なネタ


セサミストリート化する

Sesamize Your Banana (or a compatible cell phone)

ttp://mobilestore.sesameworkshop.org/SesameStreet/ (アーカイブ

遅くとも2005年には、セサミストリート制作しているSesame Workshopがsesamizeという単語使用している。


Sesame化する

https://github.com/joshsh/sesametools

RDFデータベースJavaフレームワークであるSesameコマンドラインツール

SesameRDF4Jに統合されたらしい。


SeSAMe化する

https://github.com/zwdzwd/sesamize

DNAメチル化の解析を行うSeSAMeというR言語パッケージのために、データファイルを変換するツール


SESAME化する

SESAMEというセキュリティアーキテクチャを用いてアプリケーション保護することをsesamizeと表現することがあるようだ?




軽く検索しただけなので、把握しきれていない用法があるかもしれない。

ともあれ、sesamizeという単語には多様な意味がある、というわけだ。

2022-03-06

anond:20220306143946

サーバーレスビジネスロジックが分離されててスケーラブルだし

場所によらずデプロイできるからグローバルなサービスにあってるよね

リソースリッチ現代ステートレスアーキテクチャ

メンテナンス性に諸々優れてるというのは関数型プログラミングパラダイム(またはUnix哲学)で

我々エンジニア学習したことだしね。伸びると思うよサーバーレス

ただエコシステムや周辺の状況が発展途上だしサービスロジックによってはモノリシックな方が

あってるものもあるからケースバイケースでしょ

2022-03-04

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

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

361あとで/3270users 逮捕にそなえる人生継続計画 - やしお

257あとで/1505users 筑波教授が著した無料初心者向けPython教材「とてもわかりやすい」「素晴らしすぎる」 | Ledge.ai

246あとで/1545users 【独学可能英語を話す方法 第二言語習得研究行動科学に基づく英語学習ロードマップ - ポリグロトライフ | 言語まなび∞ラボ

228あとで/1502users 「1Byteが8bitに決まったワケ」についての長い話 まずは「バベッジの階差機関から | ITMedia

228あとで/1340users 1on1 ノウハウの共有 | DevelopersIO

218あとで/2069users 音声合成業界に激震! もはや人間の喋り声、入力文字読み上げソフトVOICEPEAKはビジネス用途でも自由に利用可能藤本健の “DTMステーション

172あとで/1057users 2022年ウクライナ情勢をより深く理解するための歴史文化背景雑学|tadhara|note

170あとで/912users BIOSからUEFIへ BIOSはなぜ終わらなければならなかったのか | ITMedia

168あとで/1175users 早く寝るために自分自身をハックする - 本しゃぶり

160あとで/1187users 富士通撤退する「メインフレーム」ってそもそも何? | koduki | Zenn

152あとで/854users 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか | 櫛田 瑞穂 | SpeakerDeck

148あとで/1128users 【登大遊天才エンジニアの安寧を求めない生き方日本で“大義”を持って働く選択は有利」 - エンジニアtype | 転職type

146あとで/1624users 元葬儀屋のワイが神奈川県警悪事淡々と話すスレ : うしみつ-5chまとめ- #神奈川

143あとで/756users 事業開発者プロダクトマネージャーが知っておくべきフレームワーク7選|Shinnote

142あとで/1250users 「Google検索は死んでいる」がバズったので「まとも検索」を作った。:村上福之の「ネットケータイ俺様」:オルタナティブブログ

138あとで/728users OSS経験「なにから始めたらいいかからない…」←これを一気に解決する神リポジトリ - Qiita

137あとで/1202users 中小企業Apple製品を利用する前にやっておくこと | Hiroshiman | Zenn

128あとで/1357users 1分でわかるウクライナ歴史 | anond.hatelabo.jp

124あとで/1265users 【MacKindle本も永久保存自動スクショPDF化する方法|脱凡リーマンブログ

124あとで/1192users これだけは押さえよう!住所フォームの作り方 - ケンオールブログ

119あとで/928users 今のウクライナ情勢が分かりやすくなる…地政学漫画紛争でしたら八田まで』が凄いと話題 | Togetter

118あとで/875users 「詩」というもの谷川俊太郎|「新潮編集部note

118あとで/955users 子ども自己肯定感を下げるNG言動 5000人を育成してわかった低い子の特徴(みらのび) - Yahoo!ニュース

115あとで/1012users 人は「楽と感じる方法しか選ばないことを前提に、仕組みを作らなければならない。 | 桃野泰徳 | Books & Apps

112あとで/1044users 定年退職後に料理をはじめた父の「大葉漬け」がヤミツキ必至の美味しさでご飯がとまらない/ 大葉の大量消費にもオススメ! | 砂子間正貫 | RocketNews24

112あとで/760users 東京都デジタル人材確保・育成基本方針 ver.1.0 | 東京都 | SpeakerDeck

111あとで/631users ソフトウェアアーキテクチャの基礎 | O'Reilly Japan

108あとで/652users ブラウザで動くサービスを作るとき技術選定 | moga | Zenn

105あとで/755users 2024年制度変更「つみたてNISA」 始めるなら2022年が有利な理由 | マネーポストWEB

104あとで/557users Webフロントエンドパフォーマンスチューニング55選 - Qiita

ウクライナを手軽に理解しようというエントリ多め

2022-02-24

anond:20220224195309

https://anond.hatelabo.jp/20220120221328

お前これか

28歳男プログラマー地方零細IT企業に勤めてるけどコロナきっかけに求人選択肢が増えたのと年齢的に焦りが出てきたので転職(+婚活)活動中。

Webプログラマー+自社サービス+フルリモートで初年度年収600万目指してるけどうまく行かない、今のところ3社落ちた。

1社目は面談時に噛み合わない感じがあったのでまあしゃーなしかなって思った。1次面接落ち。

2社目はその会社が出してるサービスとほぼ似たようなサービスを開発主導したことあったので「御社の○○で使われているXX機能(プレスリリース打つレベル機能)とほぼ同じものRTA感覚実装して2日でリリースしました」とかアピールしまくったのに余裕の1次面接落ち。倍率高そうだしこんなもんかーって思った。

3社目は「あなたテックリード経験などは経歴的に弊社の求める人材マッチしていてポートフォリオに載せてる個人開発アプリの○○なども魅力的で是非一緒に働きたいと~」っていう600万のスカウトが来たのに書類選考で落とされた。んな馬鹿なと思った

正直学歴とかは偏差値概念すらないようなものだけどテックリード経験ありでDDDやらクリーンアーキテクチャやらCIやら主導して導入経験もある俺は余裕で無双できるもんかと思ってた。

でもそれだけじゃ600万は流石に難しいのかなあ。単価高いフルリモート求人じゃ多分全国の数十人の中の1番に選ばれんといけん感じだもんなぁ。東大卒ガチガチ勢に叩きのめされてたらどうしようもないもんな。

2022-02-15

anond:20220214201323

マイクロサービスはそれなりに昔からアーキテクチャ自体存在しているが、多くの会社実践されはじめたのがこの5年くらいだろう。日本は常に3年以上遅れるけど。

人的リソースが潤沢で、サービスユーザー数も多く、長期展望が望めるようなサービスを開発している企業以外でやるのは、超アンチパターンからな。

日本スタートアップマイクロサービスやってますとか、学生の集まり企業しか見えない。

2022-02-01

そのシステムは死んでいる

プログラマーをやっていると、何やっても火を噴くようになったソースコードというのを目にすることがある。

だが火を噴きつつもなんとなくタスク完了できるし、いきなりそうなったわけでもないのでゆでガエルの様に経営陣はこんなもんだろうと深刻に見ようとしない。

だが、ちょっとした機能変更ですら1人月かかるなどという状況は異常だ。

これはそのソフトウェア採用したアーキテクチャが死んだ、ということでもある。

アーキテクチャは当初はとてもいいものだろうとみんなが考えて採用するが、時と共に基盤技術陳腐化する、新しい技術が台頭するということによって陳腐化したり使い物にならなくなったりする。

また、経済の発展と共にそのアーキテクチャではもたないようになることもある。

50cmくらいの溝にかける橋なら適当な板でも構わないが、その端の両端に気をつなぎ合わせて利根川を渡す橋を架けるとか、利根川をまたげるくらいの板を利根川に渡してみてもそれは端にはならない。自重で瞬く間に崩壊するだろう。

だが、ソフトウェア世界では、じゃぁ、更迭の橋げたを下に並べようとかそういう事をする。

上を車が通っていたが割れるなら、上にも鉄板を敷き詰めよう

元の板なんかなくてもいいんじゃないですか?

いやもう橋の中に埋め込まれてとることはできない。

でもその板が腐食してきてますよ、橋落ちますよ。

じゃぁ、もっと鉄板を分厚くしよう!

いや、だったら横にもう一つ橋を架けたら・・・

そんな金のかかることできるか!

みたいな変な議論をする羽目になる。

橋につぎはぎするのに毎年10億円を50年払い続けるのはいいが、新しい橋を20億円かけて架けてその後毎年2億円位のメンテナンスコストで済むほうは選ばない。

これはビジネスにおける会計年度のせいかもしれない。

まり新しい橋を架けた年は赤字になるので株価も下がるとか投資家還元できないとかそっちを考えるのだろうか。

そして会社は死んだシステム心中することになる。

2022-01-29

会津大学大学院 入学試験メモ

会津大学院入試について情報ほとんどなかったので、第2回試験を受けたメモをいくつか残しておく

大学院進学フェアでも話題には上がるので、記事に残しても問題はない認識

合格

具体的な数字は分からないけど、毎年1,2人は落ちているっぽいので、98% ぐらい?

今年は受験者数が急増したけど、募集人数も増えていた

寝坊や辞退などでそもそも受験しなかった人が落ちている気がする、しらんけど

推薦書

1ヶ月以上はゆとりを持って依頼をする

具体的に何を書いたのか聞いたほうが良い

研究計画書面接試験で話に辻褄が合わないと気持ち悪いので)

研究計画書

まず「大学院で何をするのか(したいのか/させてくれるのか)」を指導教員議論したほうがいい

研究計画書に書いた内容について、割とガッツリ面接試験で聞かれる(後述)

指定されたフォーマットであれば1ページに収める必要はないらしいので、私は2枚書いた

TOEIC スコア

どれくらい重視されるのかまったく分からん

とりあえず進級できるスコア持っていれば大丈夫なんじゃないかと思ってる

受験票の写真

ヨークベニマル証明写真機で私服で撮った

スーツじゃなくてもいいらしい、しらんけど

入学検定料

振り込み金額指定すると、それに手数料が上乗せされたので、特に気にせず金額指定する

口座残高が併記されている取引レシートをそのまま貼り付けた

出願

募集要項に書いてあるのでよく読む よ~く読む

朱書を忘れない 念のために宛名も書いた

学生募集係の方が書類の不備をチェックしてくれる 感謝を忘れない

服装

大学院入試スーツ私服か」は毎年各所で話題になる

他大は スーツ:私服=9:1 のこともあるらしいけど、会津大は スーツ:私服=6:4 ぐらいだった

革靴で雪道は死ぬので、スーツ場合には靴に気をつける

スーツの人はスニーカーが多かった気がするけど

持ってきて研究室や待合室で履き替えるのも良いと思う

(待合室とは言っても研究棟の北/南ラウンジ

私は私服で行ったけど、何も言われなかった

集合時間試験

試験日の1週間ほど前に学生から連絡がくるので、受験票をもらう

だいたい、集合時間の15分後に試験開始らしい

時間差で集合させられているので、特に待たされることはない

プレゼン資料

「専攻する分野と研究計画に関連する専門知識について英語による5分程度の発表」と指定されてる

具体的にどんな発表をするのが正しいか全然からなかったけど、研究計画書に書いた内容を噛み砕いて説明した

普通プレゼン5分+質疑応答10分の計15分

オナーズプログラムプレゼン5分+質疑応答25分の計30分

プレゼン方法

印刷した資料を配ることもできるし、PCプロジェクタにつなげることもできる

機材トラブルで泣きたくなかったので、私はプレゼン資料印刷して配布した

面接官は2人なので、自分の分も含めて3部以上は持っていくとよい

私は保険のために10部も印刷した 相手のことを考えてカラーコピーのほうがいい

面接

いきなりプレゼンするのかなと思ったら、まず簡単自己紹介要求された

briefly のレベルが分からなかったので、名前所属と興味分野の話を30秒ぐらいで話した

もっと話しても良かった可能性ある

プレゼンしてください、と言われるのでプレゼンする

自分が用意した資料自分でもチラチラ読みながらしゃべった

プレゼン中は何もつっこまれなかった

プレゼンした内容についてガンガン質問される マジでガンガン質問される

「(資料に挿入した画像)についてもっと詳しく説明できるか?」

「なぜこれをやりたいのか?なぜやる必要があるのか?」

他の方法でもよくないか?」

「この研究が達成されるとどんな良いことがあるのか?」

いわゆる research purpose、research questions、gaps、contributions あたりの質問ほとんど

卒論をやっていない退学進学組は、ここを突かれるとヤバそうなので気をつける

研究の話が一段落して時間があまると、

「なぜ就職ではなく進学を選んだのか」

大学院卒業後は進学するか就職するか」

あたりの一般的質問をされた

私は早期卒業タイプB2)で受験したので

大学を1年間短縮するとデメリットもあるが、なぜ短縮するのか」

についても聞かれたけど、これが一番むずかしかった

本来大学には長く在学していたほうが勉強研究ができて良いので ...

コンピュータ理工学の基礎知識」はあまり質問されないと思う

数学物理コンピュータアーキテクチャあたりの話は一切しなかった

でもこれは専攻する分野によるのと、研究計画書に書いた内容が影響すると思う

終わり

面接が終わって部屋から出たら、そのまま帰宅してOK

合格発表まで首を洗って待つ

入試で気になることがあったら、学生募集係に質問するといいらしい。事務的な話以外でも答えてくれることがある。

大学院進学フェアには行ったほうがいい。いろいろ聞ける。躊躇せずにガンガン質問していい。(1年生でも4年生でもOK

できれば研究室の先輩からいろいろ聞いておいたほうがいい。私の情報含め、1人の先輩の情報を過信しないでほしい。

(有能な人は「雑談レベル」と言うし、無能な人は「マジで死ぬ」と言うので)

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

アメリカガチシステム開発現場を行動観察

アメリカガチシステム開発現場を行動観察

ここから今日の本題です。

アジャイルコーチとして、アメリカガチの、ガチシステム開発現場に、言うたらエスノグラフィ(行動観察調査)をしてるようなもんです。三流プログラマながら。

そういうリファレンスみたいなことをお伝えしたら、皆さん(Regional Scrum Gathering Tokyo 2022の参加者)が喜んでくれるかなとか思って、内容を構成しています

ただ、僕が知っているのはマイクロソフトだけですし、自分職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから(笑)

そういうのを踏まえて聞いてください(笑)。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分経験したことのみで構成します。

ウォーターフォールは使われていない

まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。

fig

からといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア成熟)かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン(開発前の仕様策定)を大量に時間をかけてやってるというのもない。

デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。

何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たとき日本のお客さんに「ウォーターフォールアジャイルメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。

僕が当時そのことをブログに書いたらすごい炎上しましたけど。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります

開発者それぞれが責任を持って設計実装する

次は、僕のチームがどんな感じで運用されてるかっていうお話します。

マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います

基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。

自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者

fig

マネージャからアサインされるバックログ基本的にはふわっとしているので、ICがそれを明確にします。

IC仕様自分明確化して、自分デザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。

ただ、同じマイクロサービスメンテする役割の人みたいなのがいて、それは「Buddy」(バディ)みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。

他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。

多分このチームの単位マネージャ管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分レスポンシビリティを持って自分でやる。それは新人であっても一緒です。

司会)ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。

(右下の点線で囲われたところ)このチームはスケールコントローラをやっていて、(右上の3つのICを指して)このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。

でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。

司会)隣のチームと、このチームを分けているのは、マネージャが違うだけ?

ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイム担当してるんですよ。

給料を上げるのは他人との競争ではなく自分との戦い

さて、エンジニア評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログGAFA給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。

参考:GAFA米国本社エンジニア年収ジョブレベル別に比較してみた【GoogleAmazonFacebookApple

この図がまさに僕が言いたいことなので、この図を使います

fig

こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフト給料の額とかも調べられるんですよ。

どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフト場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。

このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。

から自分給料を上げたかったらどうするかっていうと、プロモート(ランク上げ)してもらえるように頑張るって感じです。他の人との戦いじゃないんです。

いまより一つ上のランク仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパル仕事してるからプロモートしよう」とノミネートしてくれる。

そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。

ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。

給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくま自分との戦いって感じになります

マネージャ自分仕事キャリアを助けてくれる

マネージャ存在っていうのは僕的にはすごい(日本と)違ってるように感じています

日本にいるときマネージャって進捗管理課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。

アメリカ場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリア成功するかっていうのをすごい重視してくれるんです。

fig

これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます

マネージャ大事仕事アンブロック」

マネージャのすごく大事仕事に「アンブロック」というのがありますIC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものアンブロックしてくれるんです。

fig

例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。

そういうブロックをされる状況が一番生産性を阻害すると思うんですね。

そういうときマネージャアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。

マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。

基本的納期の設定はない。マネージャも急かさな

あと結構面白いのは、少なくとも今の僕の職場では、納期基本的にない感じです。

fig

あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。

基本的納期的なものはなくて、できたときが終了なんです。

マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。

これは多分いろんな意味合いがあるんですよね。多分クラウドプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。

例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。

僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。

やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃん理解して、より良いアーキテクチャを作らないとひどい目にあう。

から多分マネージャ絶対に急かさないんだと思いますちゃん理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます

バックログはあり予定もあるが、達成されないこともしょっちゅう

司会)すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね(笑)納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。

バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。

だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICアサインするんです。

でも、それが今期に達成されないということはしょっちゅう起こります

思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。

変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。

司会)お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか?

僕らの場合プロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略(ストラテジ-)とカスタマフィードバックですね。

あとはハッカソンエンジニアがなにかプロポーズするときもあります

そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものピックアップされます

で、それが達成されてリリースされるまでの期間は本当にピンキリです。

僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります

僕の上司で僕よりもプログラミングができない人はいない

ではマネージャ技術力の話に進みたいと思います

僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。

彼らの技術力はどんな感じか。

僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。

その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります

何でかと言うと、どんなテッキー話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧理解してアーキテクチャの深い話をするんです。

給料が高くて当然だと思いますね。

fig

で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。

まり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。

そしてこういう人が僕の仕事サポートをしてくれる、応援をしてくれるわけです。

からこんな上司に何かを説得する必要なんてないんです。彼らがテッキーミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。

皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。

へーOutlookぽちぽちけがスキルのクソ雑魚ポンコツ年功序列PMになってるようなケースがないのねアメリカ

anond:20220125133452

要件定義工程アーキテクチャ設計工程実装工程…といろんな工程があって、

プログラマなんて簡単」と言われているのは実装工程のことだと思う

何をコーディングすべきか、どの言語フレームワークを使うべきか、全部決まった上であとは手を動かすだけ、の「手を動かすだけ」を簡単と言っているのかと

増田は上流から全部やったから難しかったのだろうし、実際上流で決めていく作業知識もいるし分析もしないといけないか簡単じゃないと思う、知らんけど

2022-01-20

弱者男性だけど弱者男性を抜け出すための転職活動が辛い

28歳男プログラマー地方零細IT企業に勤めてるけどコロナきっかけに求人選択肢が増えたのと年齢的に焦りが出てきたので転職(+婚活)活動中。

Webプログラマー+自社サービス+フルリモートで初年度年収600万目指してるけどうまく行かない、今のところ3社落ちた。

1社目は面談時に噛み合わない感じがあったのでまあしゃーなしかなって思った。1次面接落ち。

2社目はその会社が出してるサービスとほぼ似たようなサービスを開発主導したことあったので「御社の○○で使われているXX機能(プレスリリース打つレベル機能)とほぼ同じものRTA感覚実装して2日でリリースしました」とかアピールしまくったのに余裕の1次面接落ち。倍率高そうだしこんなもんかーって思った。

3社目は「あなたテックリード経験などは経歴的に弊社の求める人材マッチしていてポートフォリオに載せてる個人開発アプリの○○なども魅力的で是非一緒に働きたいと~」っていう600万のスカウトが来たのに書類選考で落とされた。んな馬鹿なと思った


正直学歴とかは偏差値概念すらないようなものだけどテックリード経験ありでDDDやらクリーンアーキテクチャやらCIやら主導して導入経験もある俺は余裕で無双できるもんかと思ってた。

でもそれだけじゃ600万は流石に難しいのかなあ。単価高いフルリモート求人じゃ多分全国の数十人の中の1番に選ばれんといけん感じだもんなぁ。東大卒ガチガチ勢に叩きのめされてたらどうしようもないもんな。

冴えない男に生まれた以上はスキルを上げて経験積んで資本主義社会で殴り合って金なり地位なり手に入れなきゃ俺なんて誰一人にも見向きもしてくれない。

食うにゃ困らんが、食うのに困らんだけの男など誰の視界にも入らない。負けたら死ぬまで孤独が続くだけ。

今を抜け出したかったら、弱者男性には戦う以外の選択肢はないんだ。

こんな焦燥感とは無縁で戦わないで済む人達が俺には心底羨ましいよ。。。。

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