タグ

2019年12月17日のブックマーク (11件)

  • (ほぼ)無からのトラブルシューティング技法 - Qiita

    闇の魔術に対する防衛術 Advent Calendar 2019 16日目の記事です。 イントロダクション デプロイ自動化、コンテナ型仮想化、マイクロサービス化などが進み、トラブルシューティングの難易度が意図せず上がっているケースがあります。 日常の開発作業でアプリケーションの設定やアクセス経路をほとんど意識しない コンテナが軽量すぎて ps や netstat すら入っていない Infrastructure as Code (なおドキュメントは存在しない) ログ管理の基盤はあるが、欲しいログが収集されていないか、ログ以外を調べたいので役に立たない 今回は、こうしたケースで 対象システムに熟知していなくても トラブルシューティングを進めていく方法について取り上げます。 スタート あなたは Linux サーバへの SSH ログインに必要な情報を入手し、ログインに成功しました。なんと root

    (ほぼ)無からのトラブルシューティング技法 - Qiita
  • TechCrunch | Startup and Technology News

    Ahead of the AI safety summit kicking off in Seoul, South Korea later this week, its co-host the United Kingdom is expanding its own efforts in the field. The AI

    TechCrunch | Startup and Technology News
  • サイトを高速化したらロード時間は1.6秒に、Lighthouseは100を獲得、その際に実施した手順を解説

    サイトのロード時間とパフォーマンスを改善するために再構築した結果、ロード時間が1.6秒に短縮され、Lighthouseのスコアで100を獲得した際に、実施した手順を紹介します。 HTMLCSSベースの改善が主で、ロード時の数ミリ秒間の表示、スマホ用CSSファイルの分割など、いろいろなサイトやブログの改善にも役立つと思います。 当ブログにも改善すべき点があるのが分かったので、対応したいですね。 I rebuilt my portfolio🌻 Now it loads in 1.6s 🎉 Here's how I did by Saurabh Daware 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 要約 改善方法 1: リソースのプリロード 改善方法 2: CSSファイルの分割 改善方法 3: 画像の最適化 ボ

    サイトを高速化したらロード時間は1.6秒に、Lighthouseは100を獲得、その際に実施した手順を解説
  • rsyncの悲劇 〜本番環境を消し飛ばす前に覚えておきたいこと〜

    この記事は番環境でやらかしちゃった人 Advent Calendar 2019 17日目の記事です。 はじめまして、ダーシノ(@bc_rikko)です。 突然ですが、懺悔します。 私は転職して10ヶ月で2回も番環境をぶっ飛ばしました。お客様をはじめ、関係各位には多大なるご迷惑をおかけしたことを、ここでお詫び申し上げます。 1回目は2015年11月27日、入社27日目のこと。 gitの設定ミスにより壊れたブランチをmasterにforce pushしてしまい、CIが流れて番環境が壊れた。原因はpush.defaultなのだが、詳しくはすでに記事を書いているのでそちらを読んでほしい。 2回目は翌年9月1日、入社してちょうど10ヶ月たった日のことだ。 またしても番環境をぶっ飛ばした。しかも、前回より盛大に……。 タイトルにもあるようにrsyncコマンドが原因だ。 当記事では、この「rsy

    rsyncの悲劇 〜本番環境を消し飛ばす前に覚えておきたいこと〜
  • PlantUML で始めるリレーションシップ駆動要件分析 (RDRA) - Qiita

    はじめに ソフトウェア開発において、エンジニアが開発対象のドメインの業務に精通していない場合、書く内容やかける時間に程度はあれど 業務分析 や 要件定義 が必要になります。しかし、要件定義の方法論についての話題がネット上に上がることも少なく、書籍などもあまり話題になっていない印象があります (私の観測範囲では)。なので、私の場合、要件定義の実務では公の方法論を体系的に学ばずに、実務で見てきたものを自分なりにアレンジして対応してきました。 そんなとき、モデルベースの要件定義の方法論として リレーションシップ駆動分析 (RDRA) というものがあることを知りました。モデリングはずっと取り組んできていることなので、興味が湧いて少し調べてみると PlantUML でも表現できるというではありませんか! PlantUML Example for RDRA 2.0 ハンドブック そこで、RDRA2.0

    PlantUML で始めるリレーションシップ駆動要件分析 (RDRA) - Qiita
  • 普通ここまでやるか?納税者を平気でダマす税務署の卑劣な手口 - まぐまぐニュース!

    先日掲載の「恐ろしい自爆営業。元国税が明かす、かんぽより酷い税務署の実態」では、税務署員に課せられている「信じ難いノルマ」の実態を暴露した、元国税調査官で作家の大村大次郎さん。今回大村さんはメルマガ『大村大次郎の音で役に立つ税金情報』で、何も知らない納税者を平気で騙す税務署の「卑劣」な手口を白日の下に晒しています。 ※記事は有料メルマガ『大村大次郎の音で役に立つ税金情報』2019年12月16日号の一部抜粋です。ご興味をお持ちの方はぜひこの機会にバックナンバー含め初月無料のお試し購読をどうぞ。 プロフィール:大村大次郎(おおむら・おおじろう) 大阪府出身。10年間の国税局勤務の後、経理事務所などを経て経営コンサルタント、フリーライターに。主な著書に「あらゆる領収書は経費で落とせる」(中央公論新社)「悪の会計学」(双葉社)がある。 税務署は平気で納税者を騙す 前回の「恐ろしい自爆営業。元

    普通ここまでやるか?納税者を平気でダマす税務署の卑劣な手口 - まぐまぐニュース!
  • 大規模オンプレミスなヤフーのサーバーインフラの裏側 〜 サーバー調達や運用の流れを紹介します

    OEM系→ODM系にシフトした背景ですが、1つは 価格競争力 です。 インフラにおいてプライスは重要な指標です。 また昔と今でヤフーのサーバーの買い方に違いがある事もポイントになっています。 昔のヤフーは、いろいろな部門が、いろいろな構成のサーバーを、いろいろなタイミングで購入していました。 この結果、納期面で有利なOEMを第一選択肢としていました。 またいろいろな構成のサーバーが入る事を考慮した結果、自営保守ではカバーしきれない範囲も多く、ベンダーが提供するサポートに依存している部分もありました。 しかし最近では 自社クラウド環境の普及により、決まった部門決まった構成決まったタイミングで購入するように になってきたため、 納期に関して余裕を持ったスケジューリングができるようになりました。 またクラウド環境で利用できるサーバーはかなりハイスペックなため、価格の数%の違いも大きなビジネスイン

    大規模オンプレミスなヤフーのサーバーインフラの裏側 〜 サーバー調達や運用の流れを紹介します
  • エンジニアだけが優遇されるのではない組織をつくりたい - Unknown Error

    ※ 2つの意味で解釈できるようなタイトルだった*1ため、より伝えたいことが明確になるタイトルに訂正しました。ご指摘いただいた皆様ありがとうございました。お詫び申し上げます この記事はEngineering Manager Advent Calendar 2019の17日目の記事です。 手前味噌だが、所属している会社のエンジニア組織はだいぶ良い感じになってきているという自負がある。最近書いた自社のブログのエントリも多くの方に共感いただいた。 hackerslab.aktsk.jp 一つ一つの組織活動に対してこれって当にあるべき姿なんだっけというのを問い続けながら地道な改善を続け、組織としての練度が大分高まってきた。 結果として、自社のあらゆる組織の中で、エンジニア組織は一番改善が進んでいる。*2 一方で、そこはかとなく、「このままで良いんだろうか」というモヤモヤがある。 会社はエンジニア

    エンジニアだけが優遇されるのではない組織をつくりたい - Unknown Error
  • SREってなんだ?哲学と習慣、そしてツール。

    1.SREの哲学と原則 SREは”DevOpsを純粋な形にしたもの”なのか SRE担当VPとして、Matthew FlamingはNew RelicのSREプラクティスを監督しています。SREはおそらく”DevOpsの原則を単一の役割に最も純粋に蒸留したものだ”と彼は考えています。 昨年の FutureStack New YorkでGoogleのSREであるLiz Fong-Jones氏はこの考えを広げました。Googleのソフトウェアエンジニアは、運用システムのコードと信頼性に常に責任を負っていますが”SREはさまざまなシステムがどのように連携するか、どのように機能するか、そしてどのように改善されるべきかについて、専門的な理解を深めることに責任がある”と彼女は言いました。SREはソフトウェアエンジニアリングのタスクを引き受ける可能性がありますが、エンジニアリングチームが提供するサービスの

    SREってなんだ?哲学と習慣、そしてツール。
    Akineko
    Akineko 2019/12/17
  • Cloud FunctionsをGoで書く。またはFirebaseのためのマイクロサービスアーキテクチャ - laiso

    Firebase Advent Calendar 2019 の17日目です。16日目はKesin11さんの「Firebase Emulator Suiteをフル活用してTDDで開発しよう」でした。 はじめに FirebaseプロジェクトでCloud Firestoreを利用する時は通常Node.jsによるCloud Functionsでトリガーとなる処理を記述します。その他には関連するAPIサーバー、WebアプリのフロントエンドのSSR、バックエンドの非同期処理など、多くの場面でCloud Functionsが活用されています。 この開発→デプロイサイクルをお手軽に行ってくれるのがfirebase-toolsというnpmモジュールです。JavaScriptでFunctionを実装し、firebase deployコマンドを実行するだけでFirebaseプロジェクト用のCloud Funct

    Cloud FunctionsをGoで書く。またはFirebaseのためのマイクロサービスアーキテクチャ - laiso
  • rufo - Ruby Formatter - ongaeshi

    Ruby用の高速フォーマッタ。純粋にフォーマッタだけなのがよい。 1. gem install rufo code:shell $ gem install rufo 2. jnbt.vscode-rufo のインストール VSCodeで"rufo"で検索してインストール。 3. VSCodeの設定 Windowsの場合、rufo.batにする必要があるので注意。rufoだとnot foundする。 code:setting.json "rufo.exe": "rufo.bat" 4. Ctrl+Shift+F でフォーマット #ruby

    rufo - Ruby Formatter - ongaeshi