kube-schedulerのソースコードを読みながらPodがNodeにBindされるまでを理解する - Qiita
kube-scheduler は Kubernetesにおけるデフォルトスケジューラで、 Pod を Node に Bind する責務(+α)を担っています。 この文章は、(kube-scheduler)のソースコード(v1.13.3)を読み進めながら、「Podがどのような処理を経てNodeにBindされるか」を理解する手助けすることを目的として書かれました。 また、2019-02-05 Kubernetes 読書会 #4の資料としても用られました。 kube-schedulerのエントリーポイント(cmd/kube-scheduler/scheduler.go)から順に読んでいくスタイルで解説しています。 ソースコードをいきなり読む前に この文章では図をつかったわかりやすい解説ができていません。これまでに、自分でソースコードを読み解いて、解説スライド・記事を作ってくださっている方がいます
コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう｜ハイクラス転職・求人情報サイト AMBI（アンビ）
コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう コンテナ技術を適切に活用するには、コンテナが「どうやって」動いているかを学びたいところ。はてなのエンジニアhayajo_77さんがコンテナの要素技術の勘所を解説します。 こんにちは。株式会社はてなでサーバー監視サービス「Mackerel」のSREを務めるhayajo_77（ @hayajo ）です。 さて、コンテナ技術はDockerの登場がきっかけとなり、本格的に活用が始まりました。現在はKubernetesを始めとするコンテナオーケストレーションツールや AWS, GCP, Azure などのクラウドサービスで提供されるコンテナマネジメントサービスを採用したサービス運用事例が数多く紹介されており、コンテナ技術は「理解する」フェイズから「利用する」フェイズに移ってきています。 コンテナそのものは上記のツールやサービスにより
ゲリラでない採用面接ガイド(自分用) - 勘と経験と読経
ほぼ自分用メモ。人材の採用面接はいつも悩ましくて、いろいろ調べたり考えたりしている。いっぽうですぐに調べたことを忘れてしまう（だって人間だもの）のでストアしておく記事。定期的に更新していきたい。 現時点の採用面接の基本方針 所属組織のガイドラインはあるのだけれども、個人的にはいろいろと改善していきたいと思っている。というわけで現時点の方針は次のような感じ。 イントロダクションで面接の流れを説明する 面接官(自分)の自己紹介をしっかりする その後の質疑応答をスムーズに進めるために、面接官のレベルを(出来れば)把握してもらう 予め決めた評価軸に沿って評価する(思いつきで質問しない) アドリブを否定するものではないが、あくまで点数をつけるために必要な質問をする このあたりの詳細はGoogleのワーク・ルールズ本が詳しい 評価軸は秘密 妥協しない 短期的な視点(例えば今すぐ、どうしても人が欲しいと
ポッドキャストの録音のコツとオススメ機材 (2018年12月版) - 音味
ポッドキャストを良い音で録音して聞きやすくするためにajitofm でやっている工夫やマイクのセッティング、レコーダーなど機材について2018年12月時点でまとめてみます。 3行でまとめると マイキング(マイクの設置場所や調整)が一番大事 聞きやすい綺麗な音はできるだけ部屋の反響音を入れないこと 長くポッドキャストを続けるためには頑張りすぎないこと 目次 3行でまとめると 目次 ポッドキャストは良い音で録音しリスナーの疲労軽減 マイクの設置場所や調整 (マイキング )を一番意識 反響、空調音の少ない環境で収録 マイクと口元の距離はできるだけ近く一定に保つ 失敗をへらすコツは本番録音の前に試し録音をして確認すること マイクの吹かれ対策 ポッドキャストの録音に最適なマイクは？ 1人ポッドキャストはUSBマイクが最適 多人数での録音にはZOOM H6などのレコーダー ダイナミックマイクのSM58
Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
「エース人材さえいれば」という病｜篠田真貴子｜ エール ｜『LISTEN』監訳
以前、ある大手グローバル製造業の若手とお話しをした。職場をもっと活性化したいという課題だったと思う。 話をするうち、ある仮説が思い浮かんだ。 40年前、今の経営陣が若手だった頃、その会社はグローバル企業ではなかった。事業も今ほど多岐に渡っていなかった。ゼロからの海外市場開拓、新技術開発、事業の立ち上げ、初めて海外に製造拠点を作るなど、フロンティアがたくさんあった。 そうしたフロンティア開拓が実を結び、安定的に事業を運営できるようになった。もう少し具体的にいうと、フロンティアを開拓した先輩たちだけではなく、収益モデルとオペレーションを作った先輩たちがいたわけだ。ベンチャーでいうところの「スケールする」ってやつでしょうか。 ここまで完成すれば、「普通の人が普通に努力すれば、利益や成長という成果が出る」ようになる。先輩たちはそうなることを目指して、ゼロから事業を作り技術や市場を開拓してきた。それ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
