エンジニアや研究者からマネージャーや経営者になる時の不安について - 人間とウェブの未来
自分は元々とにかく技術志向のエンジニアであり研究者であった。とにかくコードを書いたり論文を書いたりすることが生き甲斐であった。 そんな自分が数年前に色々考えた結果、マネージャーや経営者の道を志すようになったのだが、その際によく聞かれることがある。「技術を中心にやれなくなる不安や葛藤はなかったんですか？」と。 その答えとしては「その不安や葛藤はない」である。なぜかというと、マネージャーや経営者に強烈な専門性を感じているからだ。勉強すればするほど、あれ、これはエンジニアや研究者の時にやっていた学び方とほとんど変わらないのではないか、と思えているからである。 おそらく僕自身も、かつてはマネージャーや経営者に専門性を見出せておらず、エンジニアからそうなることは考えてもいなかった。むしろ、技術者としての諦めのような風に捉えていたかもしれない。しかし、自分がそこに身を置くにつれて、全くもって雰囲気で適
家族やプライベートを犠牲にして仕事や実績を得ていたことから目を背けられなくなった件
新型コロナウィルスの影響によって、急激に働き方が変わってきた。コロナ禍の初期、大体1年目においては、まだタイトルのような「家族やプライベートを犠牲にして仕事や実績を得ていた」ことから目をそむけることができていたし、なんとなくモヤモヤしていたけれど、そのような考えにある種至っていないような感覚であった。 コロナ禍の初期は、働き方が一気にオフラインからオンラインになって、出張や勤務など多くの時間的な制約から解き放たれ、随分と様々なオンラインの取り組みやコミュニケーションに参加しやすくなった。また、そのタイミングで僕はInfraStudyと呼んでいる大規模オンライン勉強会を企画し、運営してきた。 そういった様々なオンライン上の取り組みの中で「オフラインだったら夜の勉強会や懇親会に参加できるけれど、オンラインだったら家族もいるし難しい」といったような話を聞くことが増えてきた。その時僕は、正直、なぜ
viを:wqや:q!、あるいはZZで終了するのとではどちらが効率的か - 人間とウェブの未来
後ろの方に追記をいくつか書いているのでそちらも是非参照ください 今日さくらインターネット研究所の雑談タイムで、viの終了時には:wqや:q!とかで終了するよりもZZで終了すべき、という話題が出た。 ここで簡単に整理しておくと、 :wqはファイルを上書き保存して終了 :qは上書きせずに終了 ZZ はファイルに変更があれば保存して終了、なければ上書きせずに終了 というコマンドである。 最初はZZ便利だよなぁと思っていたけど、確か過去にZZだとやりにくいところがあって使うのをやめた記憶があった。それで色々話をしていると、やっぱりZZを使った方が良いケースが思いつかなかった。 そこで、ZZいらんでしょ、などと発言したりしていたのだった。 といのうも、僕のviの終了するパターンとしては、 まず:qを押す 変更がなければそのまま終了、変更があれば変更があるよとwarningが出て終了できない warn
分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから - 人間とウェブの未来
本エントリはさくらインターネットアドベントカレンダー2018の12月25日の記事です。メリークリスマス！！！！！ 12月24日は、echizenya yotaさんの「さくらインターネット株式会社の田中邦裕社長からクリスマスプレゼントをもらう方法」でした。 ということで、今日は @matsumotory が 「分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから」について書いてみようと思います。 現状のgVisorやFirecrackerをはじめとするコンテナ実行基盤技術の公開に伴って、個人としてはこれからますます分散型データセンターOSのような基盤と、その上で実行されるリアクティブ性を持つコンテナ実行環境が重要になってくる時代がはじまるように思っています。 今日は、そのあたりについての自分の考えと、その流れを見据えて現在開発しているミドルウェアを2つ紹介したいと思い
プログラミングにおける不安と学びのプロセス - 人間とウェブの未来
僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来
という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い
研究者と技術者の狭間で感じた事 - 情熱が自分を変える - 人間とウェブの未来
吉報は突然届くもので、本日、情報処理学会の山下記念研究賞の受賞が決定しました。 まず、情報処理学会の山下記念研究賞（旧研究賞）とは以下のような賞になります。3年前に会社を辞めてまで学術研究に飛び込んだ自分としては、非常に光栄ですし何よりうれしいです。 2014年度詳細-情報処理学会 山下記念研究賞の推薦理由は、 [推薦理由] Webサービスを安定して提供するために，Webサーバソフトウェアの内部機能の拡張が必要となる場合がある．この機能拡張を，生産性や保守性を考慮してスクリプト言語で行う手法の提案がいくつかなされているが，高速性・省メモリ・安全性の面でいくつかの課題があった．著者は，Apache HTTP Serverに組み込みスクリプ卜言語であるmrubyを組み込むことで，Rubyスクリプトにより容易に機能拡張でき，高速・省メモリで動作する機能拡張支援機構を提案している．また，本機構の有
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
