“Platform Engineering”という私的よく見かけるが意味を調べたことのない用語No.1のトピックについて書かれた本がO'Reillyからearly releaseされているので読んでる。まだ第一部しか公開されてない。 learning.oreilly.com その中に出てくるアプリケーションチームがTerraformコードを管理することで起きがちな問題について共感したので紹介する アプリケーションエンジニアリングチームがIaaSクラウドのあらゆるものを求めるようになったとき、多くの企業は、各チームに独自のクラウドインフラストラクチャを独自の構成でプロビジョニングする権限と責任を与えることが、摩擦の少ない方法だと判断しました。 実際には、これは、構成管理とインフラストラクチャプロビジョニングに精通した、兼業のクラウドエンジニアリングチームになることを意味していました。 繰り返

言いたいこと最近はCAT6Aでフラットケーブルが登場してるが、あれ全部ゴミだ 30mぐらいまであるけどマジゴミ。 買う価値なし。 ゴミは置いといても、LANケーブルには「準拠」と「対応」があるらしい。区別して使うべし 長い文章（読み飛ばしてよい）CAT6Aで施工指示したのに5Eになってたと言う記事を読んで思い出したので吐き出しておく。 大手OAサプライヤで売っている完成品LANケーブル。これもCAT6Aが標準になってきて久しい。5Eのものはほぼ見られなくなった。 その中でフラットケーブルと言われるものが売られている。 通常LANケーブルというのは、細い線が何本か寄り合わされて、さらに保護用のチューブに入れられた構造だ。なので断面が丸いケーブルが普通である。 それを、丸くまとめるのではなく一直線に横に並べ固めたものがある。これをフラットケーブルという。また見かけから「きしめんケーブル」などと

2024年1月末まで在籍していますが昨年12月に業務は終えていて、いまは有休消化期間中です。2010年から約14年間勤めてきた、自分の生き様そのものとも言えるクックパッドを離れるのには、表現しきれないほど大きく、複雑な思いがあります。 僕がこの14年間でやってきたことを振り返ってみます。 入社 クックパッドに入社した時は新卒3年目相当で、26歳でした。もともと料理と Ruby が好きで、当時まだ珍しかった Ruby on Rails でサービス開発をしているらしいという点や、当時からネットウォッチしていた @ryo_katsuma さんが所属していること、直属の上司の井原さんが転職したことが決め手になり、体当たりで飛び込みました。当時の僕はほとんど実績もなく、入れてもらえるかギリギリのところだったと思いますが、おそらく井原さんが頑張って交渉してくれたのだと思います。本当に感謝しています。こ

https://togetter.com/li/2231505 https://b.hatena.ne.jp/entry/s/togetter.com/li/2231505 こんな記事がありました。 道の駅が一般向けのゴミ箱を設置せず（注1) そうしたら勝手にゴミを捨てられて激おこと言う話ですね。 それの是非はともかくとして、そこに「有料でもいいからゴミを捨てさせてほしい」という声が結構あるが、社会制度的に想定してないので、結構面倒くさいんだよ、と言う話をします。 有料ゴミステーション設置は、産業廃棄物・一般廃棄物処分の許認可が必要で面倒そもそもこれが一番面倒くさいんですが、有料で他人のゴミを引き受ける行為は、ゴミの処分に当たるので、それなりの免許が必要になります。 裏技としては、地元の産廃業に依頼して、場所を貸していると言う体にするという方法も考えたのだが、これも他に面倒くさいことが頻発

これは マンション光配線の方式別になぜ速度が出ないのか？を解説する資料 配線方式によって天地の差が出るマンションタイプの回線を、できる限り快適に利用したい人向けの情報 付随情報として、J:COMとかのCATVの話や、UCOM光とかBB4Uとかのマンション共有インターネットの話も載せておく (注意) 一部例外はあります。例外につきましては、「そういうこともある」だと思って下さい。 想定すべき前提知識 フレッツ光やauひかりの分岐数は方式に関わらず 1収容 あたり 最大で 32 回線 となる 光配線方式はGE-PONの仕様上、どの事業者でも最大分岐数は32分岐となる NUROの採用するG-PONは規格上の最大分岐数は64~254となっているが、実際の運用は資料がないのでわかりません NTT の シェアドアクセスを利用している以上、8以上、8の倍数(8, 16, 24, 32, .... )分岐

昨日、岸田首相が原発を再稼働すると力強く宣言したが、中身が実質現状維持で失望が広がっている。 正直今の岸田内閣のエネルギー政策は大局観が無く、場当たり的すぎる。 個人的には、過去の政策を再評価して、今の政府の対応の問題点が正しく世の中に伝わってほしいと思っている。 という訳で今日は、大局観のあった元総理の功績について語っていきたい。 勿論原発の話である。原発が生理的に嫌いな人は回れ右していただくことをおすすめする。 元総理は、対抗する勢力にこれでもかと叩かれていたが、原子力政策については、しっかりした知見を持っていた。 元総理は、国のエネルギー基本計画に、CO2削減手段として「原発の新増設」を明記した。 また2030年に原子力による発電比率を5割まで高めることを掲げた。 更に原子力をインフラとして機能させるために、原子力人材の育成も計画に明記した。 国のインフラを考える時には、元総理のよう

留学、出張、旅行（含バックパッカー）などで20カ国以上自分の目で見てきた。 大学や職場でも欧米インドアフリカなどだいぶ多様な人たちを接してきた。 国際政治経済歴史をずっと勉強してきてる。 そんな俺が決める国ガチャランキング。 この国ガチャランキング、上位0.1%の富裕層に生まれるか一代で0.1%に食い込めるすごい才能を持ってるかで大きく変わるので0.1%になれる場合とそうじゃない場合で分けた。 国のチョイスは俺の主観だから入れるべき国があればコメで教えてくれ 上位0.1%の富裕層の場合S: アメリカ・中国・アラビア半島（サウジ・UAE・カタール・バーレーン） ※金があればとにかくやりたい放題。上流階級と一般市民は完全に別世界、楽園暮らしができる A: 日本・イギリス・フランス・オーストラリア・韓国・香港 ※比較的しっかりした国だし、金があれば上流階級ならではのさらに良い暮らしが待ってる B

つい先日レバノンという国に行ってきた。日本人からしたらカルロスゴーンが逃亡した先としてお馴染みのあの国である。この国は中東のパリと呼ばれるベイルートを始めとして欧米人観光客が多く訪れる綺麗な国であった。昔は。 しかし近年は宗派間の対立、格差社会の進行、政府の腐敗が重なり経済や国民生活は落ちぶれていった。ただでさえ弱っていた所をコロナとベイルート港爆発事故が襲い完全に失敗国家と成り果てた。カルロスゴーンどんまい。 と言うわけで今回は経済崩壊した国家で過ごしてみるとどんな状況なのかを書き連ねていきたいと思う。 街中にいるヒズボラ民兵まず最初に首都ベイルートでは1日の約半分しか電気が使えない。夜間と昼数時間程度電気が流れるだけである。外貨準備高がほぼ底をつき発電用の燃料が買えないからだ。僕らの行った時はまだ半日使えた。酷い時は3日間完全に電気止まってたらしい。クソ ここ最近ロシアによるウクライナ

八ッ場ダムは、試験湛水中（未完成）で、台風前からわざわざ水を貯めている状況なので、今回の利根川の状況と無関係。あっても、治水機能が極めて小さいことは、国土交通省のデータから明らか。なのに、熱狂する人たちがいることに驚く。客観的な事実とデータを直視しましょう。

blog.tinect.jp 人間の意志というものは基本脆弱なものと思っておいた方が間違いなく、「〇〇しようと決意する」というのは基本無意味です。 （中略） 決意しただけで習慣を根付かせられる人というのは、存在しないとまでは言いませんが、まあ稀有でしょう。 恐らく「習慣を根付かせる方法」として最強なのは、「自然に動くと、勝手にそれをやっていることになる」という導線とインフラの整備なのではないかなあ、と。 リンク先の話に限らず、「自然に動くと、勝手にそれをやっていることになる」ような導線やインフラは、習慣や規律を身に付けていくにあたって重要だと思う。 たとえば精神科病院などもそうで、病室、ホールの間取り、テレビやテーブルの位置関係次第で患者さんはかなり変わる。 ホールでコミュニケーションをおのずと取りたくなるような病院もあれば、病室に閉じこもっていたくなる病院もある。患者さんが1人でいたい時

この記事は一休.com アドベントカレンダーの24日目の記事です。 qiita.com 社内情報システム部の大多和（id:rotom）です。 一休には2018年8月に入社し、情報システムエンジニアとして、IT を活用した業務改善、オフィス環境の構築を中心とした社内の「情シス」業務全般を担当しています。 本エントリでは、表立って登場することの少ない「情シス」が普段何をしているか、ご紹介していきます。 情シスのお仕事 社内情報システム部は「システム本部」に所属しており、現在 6人 のメンバで業務を行っています。 一休における情シスは以下の2つの側面を持っています。 コーポレートエンジニアリング：社内ツールやシステムの導入及び管理運用、bot やスクリプト開発による業務の効率化などの業務改善の他、オフィスの IT インフラ環境の構築、改善など、IT を活用し、より社員がよりパフォーマンスを発揮で

どうもこんにちは。いつでもどこでも五里霧中。自分はどこへ案内すれば良いのか。 freee では蕎麦打ちの空き時間でエンジニアをやっている仙波です。 本記事は freee Developers Advent Calendar 2017の 14日目です。 今年のアドベントカレンダーも折り返し地点を過ぎました。 この時期は新そばも出回っている関係で本業が忙しく、今年のアドベントカレンダーをまだ追えていません。 おすすめの記事があったら教えてください。 昨日の社内蕎麦打ちワークショップ さて、そろそろプリンタが動かないって実家から電話がかかってくる季節ですよね。インクの発注は済ませましたか？ 今年はみんなスマートスピーカーや IoT 、ブロックチェーンやら機械学習やらについて書いていると思うので、自分はその前段階について書きたいと思います。 テーマは「よくわからないけど難しそう（だからイヤ）」を超

このページについて この記事は、以前書いた「社内Wikiに情報を書くときに守ってほしい、たったひとつのルール」の続編です。前回は、個々のページをどう書くべきかという話をしましたが、今回は社内 Wiki 全体を信用できるものにする方法について考えます。 muziyoshiz.hatenablog.com 想定する環境 この記事は、ソフトウェア開発プロジェクトに関する Wiki が社内にあって、そこに各人がドキュメント（仕様書や手順書など）を書けるようになっている環境を想定しています。 私自身、ソフトウェア開発のときしか Wiki を使わないので、具体例もそのような環境に寄っています。ただ、ある程度は社内 Wiki 全般に通じる話かと思います。 ルール：「更新され続ける」ページと「更新されない」ページをはっきり分ける ここ1年ほど社内プロジェクトをいくつか渡り歩いていたのですが、個人的には、こ

Advent Calendar の時期になりました。今年はイベントがあるので、今月だけ原稿をスキップしてもらいましたので、今月は執筆に関してはちょっと余裕があります。そこで、調子にのって多くのネタに参加してしまい、自分の首を絞めていることにさっき気がつきました。長くなりすぎて読み返していないので、誤字脱字やばいかもしれません。何か見つけたら、こそっと教えてください。 本日は、過去を思い出しながらのシステムエンジニア Advent Calendar 2016です。要求されているネタは次のとおりです。 SIerのSIerによるSIerのためのアドベントカレンダーです。 SIの現場でよくある課題・デザインパターンについて書きましょう。 SIerのためには書きますが、デザインパターンについては書きません。おそらくは老害が過去をふりかえる内容がほとんどです。実際、ちょっと SIってなんじゃらほいと振

DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。

こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、

Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S