GitHub - amoffat/supertag: A tag-based filesystemYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Oh Shit, Git!?!
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
海外製ルータの脆弱性検証 - ラック・セキュリティごった煮ブログ
※こちらの記事は2020年10月5日公開note版「ラック・セキュリティごった煮ブログ」と同じ内容です デジタルペンテストサービス部の魚脳、3dbd、カペルです。 コロナの影響で出社の機会が減った昨今、皆様いかがお過ごしでしょうか。リモートワークが広まってからというもの、ルータをはじめとするネットワーク機器の売り上げが好調らしいですね。いまやAmaz〇nで探せば5000円以下で買える海外製ルータがゴロゴロ見つかります。ポチれば数日後には手元に届く。本当に便利な時代になったものです。 でもそのルータって本当に安全なのでしょうか？ あまりにも安すぎる、何かあるのでは？そもそも海外製のルータってセキュリティ面はどうなの？といった疑問に答えるべく、今回は安価で手に入れた海外製ルータの脆弱性検証を行ってみました。 ルータの役割 そもそもルータって何のための機器か良く分からない、という方のために説明し
int32 のサロゲートキーが数年でオーバーフローしそうになった件 | フューチャー技術ブログ
はじめにはじめまして、2021/11 にキャリア入社したTIGの穴井です。失敗談をテーマにした連載の2本目です。 Go の ORM（Object-relational mapping）である gorm 利用時の構造体にて、サロゲートキーの型が int32であることに起因して、当該フィールドが数年でオーバーフローしそうだった件について、なぜ実装時に気づけなかったのか、記載いたします。 背景既存システムに機能追加することで、これまでとは比べ物にならないデータ量を扱うシステムとなることがあると思います。私が参画しているプロジェクトでも扱うデータ量が大幅に急増し、結果として Go の構造体の int32 のサロゲートキーが数年でオーバーフローすることが見込まれる状況となりました。 なぜ実装時に気づけなかったのかシステム開発を行う際に、開発者が共通で利用する部品を作り込むと思いますが、 その部品の利
Dig through SERVFAILs with EDE
It can be frustrating to get errors (SERVFAIL response codes) returned from your DNS queries. It can be even more frustrating if you don’t get enough information to understand why the error is occurring or what to do next. That’s why back in 2020, we launched support for Extended DNS Error (EDE) Codes to 1.1.1.1. As a quick refresher, EDE codes are a proposed IETF standard enabled by the Extension
ジッターを伴うタイムアウト、再試行、およびバックオフ
あるサービスまたはシステムが別のサービスまたはシステムを呼び出すたびに、障害が発生する可能性があります。これらの失敗は、さまざまな要因から発生することがあります。サーバー、ネットワーク、ロードバランサー、ソフトウェア、オペレーティングシステム、またはシステムオペレーターからのミスが含まれます。故障の可能性を減らすようにシステムを設計していますが、故障しないシステムを構築することは不可能です。そのため、Amazon では、障害の可能性を許容して削減するようにシステムを設計し、わずかな割合の障害を完全に停止するまで拡大することを防いでいます。回復力のあるシステムを構築するために、タイムアウト、再試行、およびバックオフの 3 つの重要なツールを採用しています。 リクエストが通常より長くかかり、完了しない可能性があるため、障害の種類の多くが明らかになります。クライアントがリクエストの完了を通常より
法政大学島野教授が投稿した「Twitterによって発見された新種ダニ」を見た一般の大学院生の投稿から、再び別の新種ダニを発見。 :: 法政大学
お知らせ 法政大学島野教授が投稿した「Twitterによって発見された新種ダニ」を見た一般の大学院生の投稿から、再び別の新種ダニを発見。 2022年06月02日 お知らせ ～SNSを通じて新種として記載されたAmeronothrus twitterに関するTwitterへの投稿を見た一般の大学院生の投稿から、再び別の新種を発見。Ameronothrus retweetと命名された～ 【発表のポイント】 （1）Twitterで偶然見つかり、『2021年の注目すべき海洋生物の新種トップ10』のひとつにも選ばれた、千葉県銚子市の「日本のツイッターダニ」Ameronothrus twitterについてSNSに投稿したところ、「今話題のハマベダニってこれのことだろうか？鳥取県で撮影。」という投稿があり、すぐにこのダニの研究を開始したところ新種であることが判明。 （2）学名をリツイートとしてAmero
僕らは何故Kubernetesを使うのか
最初に お仕事で「Kubernetesはいいので、次のプロジェクトで使いたい」と言うと 「何がいいんですか？」とか「何ができるの？」とか聞かれてうまく答えれない事がまぁまぁあったので自分なりにKubernetesがなぜ生まれたのか、なんで使いたいのかと何ができるかをまとめてみた リソース調達の歴史から見るKubernetesが現在の地位につくまで リソース(アプリケーションを動かすためのサーバなど)調達の視点から、Kuberenetes誕生までを見ていきます。 物理サーバを調達する時代 原初のアプリケーション開発では、アプリケーションを開発してキャパシティを予測して、リソース見積もりを行い、サーバ購入を行っていました。 この方法では以下のような課題がありました。 リソースを用意するのに、数週間から数ヶ月かかる サーバを注文してから、到着するまでの時間もかかりました。 またその前のリソース見
MySQL で複合インデックスを作成する際には必ず Explain の key_len を確認すべきという話
「Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました」でちゃんと触れられてないので今更ながら key_len について補足します。発表で触れた内容については言及しないので、storage engine や B+ tree といった用語がよくわからない方は発表内容を参照してください。 なお、MySQL のバージョンは 5.7.38 です。 mysql> SELECT @@version; +-----------+ | @@version | +-----------+ | 5.7.38 | +-----------+ 1 row in set (0.00 sec) 事前準備 sample-data-railsdm-2018 の orders テーブルを少しいじって、キャンセル時刻（canceled_at）、配送予定時刻（deliv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
golangci-lintを理解する
Firezone: Zero trust access that scales
自宅フロー解析
