インフラ担当がいない、地方で根深い「バックエンド軽視」の闇
経営者：「インフラも見ることができる、良いITエンジニアがなかなかいないんですよ」 ITエンジニア：「インフラ？ 勘弁してください。二度とやりたくありません……」 これは、経営者とITエンジニアの間に見られる乖離（かいり）である。筆者の経験では、特に「地方都市」でこの傾向が強い（具体的な都市名を挙げると無用な波紋を生み前向きな議論が進まないため、あえてぼかすことをご理解いただきたい）。 両者の溝はどのようにして生まれるのか、どう向き合うべきか。今回はこのテーマについて考えてみたい。 「開発ありき」「作ってなんぼ」、そもそもインフラ業務が認知されない Webサイトやアプリケーションを作っておしまい。サーバーやデータベース、ネットワークなどバックエンドのことは気にしない。あるいは意識から漏れる。いわば、「フロント重視」「バックエンド軽視」の状況を悪気なく作り出す。 その背景には「見えないものを
ずっと夜で - megamouthの葬列
入った会社はWebサービスをやっていた。アクセスカウンターとかレンタル掲示板みたいな、そういうプリミティブな感じのウェッブ。今でも化石みたいに残っているとこがあるよね。teacupとか。もうないか。 当時はそういうことをしている会社をASP（Application Service Provider)と呼んでいて、「うちはASP事業やってるんです」と言うと通りが良かった。 名刺代わりっていうのかな、何が出来るのか、うちはこんなに技術力あります、ってのをさ、運営しているWebサービスで表現するわけ。同業者が集まったらさ、世間話している風で、自分とこのサービス自慢しまくるんだよね。なんかこう、いやあ負荷高くて、この前もサーバー落ちてぇとか、うちのユーザーは中学生が多いんでぇとか、今で言うマウントの取り合いだよね。どこも流行ってないからさ、意味のわからないとこで競ってるんだよ。 プログラマ的にはA
ひとりインフラサバイバルガイド
まえがき 人生は色々あるので365日24時間会社のサービスのオンコールを受け続けないといけない事も時にはあります。 そうした状況で色々と安心してひとりインフラをやっていく為のノウハウが自分の中に溜まってきたので、ここにガイドとしてワーッと書いちゃおうと思います。 もちろんサービス構成によってはそうはいかない面も多々あるとは思いますが、あくまで一例として参考にしてもらえればと思います。 前提条件 インフラ AWS 通知系 Sentry Datadog PagerDuty という環境ではありますが、PagerDuty を利用されている方々であればおおよそ誰でも該当するような内容かなと思います。 装備品 必須アイテム スマートフォン📱 PagerDuty からの障害通知を受け取ったり、障害アナウンスや対応依頼等の連絡に用いる必須アイテムです 必ず常に持ち歩きましょう 振動に気付けるような場所に
開発マシンの人権スペックについては俺にも語らせろ | anopara
Twitterで開発マシンの「最低限の人権」とされるスペックについての話題が広がっています。 発端はこれです。 対GAFAで研究者の処遇改善 NTT、流出に危機感 NTTでは優秀な人材はGAFA（Google, Apple, Facebook, Amazon）に引き抜かれるので処遇を改善しよう（具体的には給料をあげよう）という話です。 そこで、「いや、給料だけの問題じゃない。意思決定が遅い組織的な問題やITエンジニアの仕事そのものへの無理解に起因する開発環境のチープさに嫌気が差して止めていくエンジニアは多い」という話がぶり返されます。この問題はITエンジニア業を営む人にとっては本当によく見る問題であります。 そんな中、ネットで有名なエンジニアの一人がタイムリーにNTT（研究所）を退社しGoogleに入るというエントリを書きました。 6年勤めたNTTを退職しました これでこの開発環境周りの論
先進的プログラマが微妙技術を勧めるという吐き気を催す邪悪 - フロイドの狂気日記
はてブで時折ホッテントリする技術系スライドなりトピックがある。 僕はいつも職業柄それを見るが「何だこの技術」というのも少なくない。 ディファクトスタンダードになっている技術の紹介なら参考になる。だがほんとに聞いたこともない技術でアプリを作りましたみたいなことが度々散見される。 2-3年前からAngular 2.X以降を勉強している人は今でも幸いであるが、もしBackborn.jsをpushする記事に目を止めて、一生懸命勉強していたとしたら今は別のスキルを勉強していることだろう。 2-3年前は勢力を2分する勢いだったgulpやgrantも今や先端技術とは言えない。今はwebpackがそれらに取って代わったらしい。 このようにたった2年で使っている技術が微妙になることはよくある やはり4-5年前はLaravelとPhalconというPHPフレームワークが話題になったが、Phalconの方はもは
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
間違いを正す「過程」も含めてコンテンツになる。但しアフターフォローは手厚く。 : 画面は開発中のものです
y_kobayashi@KOBA5884投稿通知： DNS設定に(浸透|伝播|伝搬|浸潤|反映)という現象は存在しない https://t.co/tCZi8Piib5 2017/02/20 00:04:53 y_kobayashi@KOBA5884投稿通知： なぜ「DNSの浸透」という誤った表現を使ったか。または、知識がブラックボックス化する過程の記録。 https://t.co/HZtXuQQCki 2017/02/20 20:43:40 上記2件の更新を通して思ったことを、少し肩の力を抜いて書いていこうと思います。 要は雑記です。とりとめのない文章です。 ・間違った情報を発信したことにより、「それが間違いである」と知っている人が教えてくれた 今回は、たまたまその分野に詳しい方の目に留まったため、間違いを正すきっかけとなりました。 何の気なしに呟いた内容でしたが、得たものは大きかったと思
Dockerでホストを乗っ取られた - Qiita
注意 本件記事ですが、私の不適切な行動（拾ったスクリプトを検証なく走らせる）が原因です。「dockerは（特に何もしなくとも）危険」との誤解を皆様に与えた点、ご迷惑をおかけいたしました。申し訳ございません。 拡散されている記事を削除するのはさらなる誤解を招きかねないと思いましたので、冒頭に注意を付記しております。以下の記事は、「自分が何してるかをきちんと検証できないとセキュリティホールを生み出す」という意味で参考にして頂ければ幸いです。 追記 Twitterやはてブで言及いただきました皆様、ありがとうございます。 本件はpullしてきたイメージが悪意ある開発者によるものかどうかにかぎらず、不適切な設定をしていると起こり得ます。 ※コメント欄に質問への回答という形で、私がそのときに走らせていたイメージの一覧を挙げておりますが、どのイメージも評判あるものだと思います。 皆様におかれましては「あ
次世代監視の大本命！ Prometheus を実運用してみた - Qiita
こんにちは！freeeでインフラゾンビをやっている @sugitak です。ゲームではレベルを上げて物理で殴る派です。 freee ではたまにインフラエンジニアの数が減るのですが、その減ったインフラエンジニアはインフラゾンビへと進化し、社内を闊歩します。インフラゾンビは主に開発チームに所属して、アプリっぽいインフラの仕事をインフラからアプリ側へと持っていきます。デプロイとか、Dockerとか、Jenkinsとかの、いわゆる DevOps 系のところですね。こうすることで開発者は手を出せるものの自由度が増えるし、インフラはより本来のインフラとして純度を上げていける、 so, win-win ってわけです。 さて、そんなわけで監視です。freee Engineers Advent Calendar 2016の9日目の記事として、 Prometheus による監視が最高なのでみんなもっと使おうと
二足の草鞋で生きていける人は少ない
世の中「不確実な時代だ」とか煽って、これからはこういう生き方をしないと生き残れないというジャーナリストたちがいる。曰く大企業が倒産する時代、1つの職だけでは駄目だ、複数の職を持ち多角化すべき、と。一見もっともらしいように聞こえるけれど、これは大半の人には自殺行為。それについて述べてみる。 たとえば新入社員、別に新入社員に限らないけどね、最初は同じスタートラインに立っている。しかし徐々に差がつきはじめ、早ければ半年、遅くとも2年目ぐらいに、だいたい社内での自分の立ち位置が見えてくる。トップクラスの同僚と自分を比べて、ちょっとやそっとでは覆せない差を感じるようになる。 そこでよくあるのが、1つのジャンルではかなわないから、2つのジャンルにまたがったスキルを身に着けて、自分の強みにしようという発想。 まあ気持ちは分からないではないのだが、これは典型的な自滅パターン。無論複数のスキルを身に着けてい
Webフロントエンドの人達(?)が次々と微妙なツールを導入して「流れが早過ぎる」とつぶやいているのを横目で見て感じている事 - latest log
自分の会社に「新ツール導入の際はCTOの許可が必要」というルールを生やして居心地を悪化させたり、後輩のやる気を削りたくなかったら、ツールの将来性を考えて行動したほうが… SI等のアレな現場にその手のルールが存在するのは何故なのか?という事と、自分達もその歴史の一節にならないように— コラーゲンたっぷりさん (@uupaa) November 20, 2015 必要な物は生まれる(創れば良い)ので、どんな問題がありどのような解決方法があり、状況の変化にどう対応するかなど、大人はツール導入前に織り込んでおくし、”勉強会の人が流行ってるって言ってたし”ですぐ廃れるツールを導入するなんて事を繰り返してると、あっという間にデストピアな職場に。な— コラーゲンたっぷりさん (@uupaa) November 20, 2015 “ツール導入で劇的に効率や抱えている問題が改善される”なら導入すればいいし、
Kaname Hayashi 『「いい人がいない」のメカニズム』 - SlideShare
「いい人がいない」の法則、中の下の法則 パートナーを探しても「いい人がいない」女性に�、その理由を図解し対策を提案します。 ＜リビジョン＞ 追記：「面積が一定」についての補足 (2015/10/18) 追記２：面積が小さい人っているよね？(2015/10/18) https://www.facebook.com/kaname.hayashiRead less
【前編】CTO不在で、開発組織改善に着手！ 一休のエンジニアが語る苦悩の1年
Twitterでハッシュタグ「#naoya_sushi」が生まれてしまうほど、無類の寿司好きとして知られる伊藤直也氏（@naoya_ito）。そんな伊藤氏をホスト役とし、トップエンジニアをゲストに招いて、寿司をつまみつつホンネで語ってもらおうという、この企画。 第四回のゲストは、伊藤氏が現在、技術顧問として就任し、開発部門の組織改善を行っている『株式会社一休』のエンジニア、宿泊事業本部のシステム開発部の部長である笹島祐介氏（写真中央）と開発組織改善の発起人である田中健介氏（写真右）の2名が登場！CTOが不在の開発現場で10年以上前からサービス提供している、そんなよくある状況の中、どのように現状の改革に挑んでいるのか――苦労話も炸裂し、現役エンジニアには興味深い話が展開されることに！お楽しみに！ — 伊藤直也（以下「naoya」）：とりあえず乾杯しましょうか。 — 笹島祐介（以下「笹島」）＆
コミュニティに参加してつまづき最小限、学び最大限に - Webアプリエンジニア養成読本 AdventCalendar2014 14日目 - uzullaがブログ
昨日オールナイトの忘年会で完全に眠いuzullaです。 本エントリはWebアプリエンジニア養成読本アドベントカレンダーですが、 Webアプリエンジニア養成読本 Advent Calendar 2014 - Qiita その書籍の作者４人が仲良くなったのも、この忘年会でした。 https://atnd.org/events/58716 https://atnd.org/events/58716 これもコミュニティの一つであり、人と人とのつながりというものは楽しく、有意義ですね。 もう8年目なのですが、これがおわると年末だ！という気分になります。 来年も是非参加したいですね。 まずはDISCLAIMER あくまで、これは個人的な視点で、個人的な趣向です。これが性に合わない人も絶対にたくさんいるでしょう。 「これにならって、よくわからん奴がふえるのは迷惑だ」と感じる人もいるでしょう。 先に言って
シニアエンジニアによるガラケー大戦回顧録に参加した
シニアエンジニアによるガラケー大戦回顧録 : ATNDに参加した。 この会合の主旨としては、当時の邪悪で不自由極まりないガラケーの開発姿勢が、如何に悲惨で惨めで肥溜めの中の蛭のようなものだったかを、非公開の会合で語ろうというものだ ガラケーの開発では、技術的に誤っている手法が実に多く使われていた。なるほど、不自由で貧弱なガラケーの実装が規格準拠しておらずバグだらけだったこともあろう。それにしても、ガラケーとは関係がないサーバーの中だけで完結する場所におけるクソもあった。何故そんなことになってしまったのか。 理由は、情報が公に出せず、したがって共有されなかったことだ。情報が共有されないため、表立って議論や相談が出来ない。その状態でかろうじて見つけたちっぽけな情報を元に、技術的に極めて劣っていながらも、何とか動くものを作り出していた。そして、その動くものを、正しいやり方だと勘違いしていたのだ。
Data::Dumper に代わる Data::Printer - 理系学生日記
LL でデバッグと言えばデバッガではなく print デバッグ、という人は多いと思います。ぼくはもっぱら print デバッグです。 いまこのタイミングでこのオブジェクトはどんな値を持っているんだろう、というときは、Perl だったらもっぱら Data::Dumper を使って、 sub p { print Dumper @_ } p $object; なんてのを良く書いてたんですけど、$object がクソみたいにデカいモジュールのオブジェクトだったりすると、ターミナルが溢れて(ぼくが)死んだりしてました。DateTime とか HTTP::Request あたりとか大変ですね。 で、ちょっと Data::Printer 良いよって声を聞いたので試してみたのでした。Class::MOP 依存だがな!!! 基本的な使い方 Data::Printer を use すると、p っていう関数がデ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js Is Dead - なぜ私がNode.jsを捨ててElixirに切り替えたのか-
自動テストを書く習慣がないチーム
「スキルなし・実績なし」 32歳窓際エンジニアがシリコンバレーで働くようになるまで
