この記事は C# Advent Calendar 2020 22日目の記事です。 ここで紹介したサンプルプロジェクトは、GitHubで公開しています。 Sumples/TypeScriptTest at master · Atria64/Samples はじめに 今回はC#でのSPA開発が可能となる画期的なフレームワーク「Blazor」を話題に記事を投稿しようと思います。 Blazorが何かよくわからない方は、以下の記事を参照すると良いかもしれません。 いいからBlazorをさわるんだ - Qiita Blazor をお勧めできる人は誰か? - Qiita また、Blazorを利用すると以下のようなものが作れます。 Atria64/CUIPortfolio: CUI風Portfolio Blazorで作成したCUI風のサイトです Atria64/RandomSushi 某スシローのメニュー

もう理解できた方は多いと思われますが・・・ この変更を行うと郵便番号や、電話番号の数値の先頭0が飛ばされてしまうのです！ 携帯番号は090,080とはじまるので、これが 90, 80になってしまいます。 このことに気がつかず、当時数値データのみのカラムなんだから、数値型にするべきだろうと 本番にマイグレーションしてしまいました。 そして、翌日に会員データがおかしいと連絡を受けて発覚しました。 幸いなことに、DBのバックアップがあったのと、 電話番号と郵便番号はある程度パターンが決まっているので、桁数などでチェックを行い、0が取り除かれたであろうデータは０を追加してデータの修正を行いました。結果会員データの復旧をすることができました。 最終的に内部スキーマはVarCharで適切なlengthを指定するように変更しました。 惨劇はなぜおこってしまったのか 自分が無知であった。また調査・確認が足

EC と CRM を支援する API プラットフォーム「prismatix」を構成するマイクロサービスの設計・開発を担当していただきます。 prismatixは複数の小規模なサービスが協調してサービスを構成する「マイクロサービスアーキテクチャ」を採用しています。それぞれのサービスは認証・認可、商品管理、決済などEC領域で重要な機能を分担しており、顧客の要件に応じて選択的に機能を提供することが可能です。各サービスはJavaとSpring Bootで構成されたDockerコンテナをECS上でホストし、データストアにはRDSやDynamoDBなどマネージドサービスを採用しています。 いわゆるECサイトのようなフロントエンドアプリケーションはサービスとしては提供せず、データストア / ビジネスロジックのみを提供するシステムの形態は、昨今「ヘッドレスコマース」という言葉で知られるようになってきました

このやらかしは、私の人生観を変えるきっかけとなった出来事でもあります。最後までお読みいただけたら幸いです。 環境 CentOS やらかしたこと root ユーザの Crontab を他の一般ユーザのもので上書きしました。 背景 某平日の夜 9 時半ごろ、（当時）新卒 2 年目で開発チームの私と新卒 4 年目でインフラチームの先輩は障害対応にあたっており、 Crontab の一部をコメントアウトする操作 を行おうとしていました。 私「もう眠いですよ～先輩、早くクーロン見ましょ 」 先輩「うん、見よ見よ これをこうして... 」 私「Crontab の確認って、 Crontab を確認したいユーザにログインして crontab -l じゃないんですか？ 」 先輩「ああ、それもあるけどわたしはいつも root で /var/spool/cron/${ユーザ名} 見てる よー 」 私「へぇ～、初め

この記事は C# Advent Calendar 2020 17日目の記事です。 はじめに C#を書いている人なら一度はインターフェースという機能を見たことがあるだろう。 メソッド、プロパティなどの定義だけを記述しておき、実装を強制できるあれのことだ。 一体あんなものが何の役に立つんだろうか。 私は最初そんなことを思っていた。 しかし、テストコードを書きたいと思ったときインターフェースはとても役に立つことに気づいたんだ。 この記事ではテストが難しいコードに対し、インターフェースを使用し、テスタブルなコードに変更していくことで、インターフェースについて理解を深められたらと思う。 対象者 この記事は以下のような人を対象とする。 インターフェースの使い所やメリットがいまいち良くわからないという人 テスタブルなコードを書きたいと思っている人 それでは始めよう。 例題 入力した文字列をラベルプリンタ

何事もなく進む作業。 今回は一部機器繋ぎこみだけなので、そろそろ作業の終わりも見えてきたとき、一本の電話がかかってきた。 一本の電話 電話の表示を見ると、その時の案件リーダの方の名前が表示されている。 このタイミングでかかってくる電話に良いことがあったためしがない。 でたくない、、、でたくないが、意を決して出る。 私：「どうしましたか？」 リ：「お客様から電話があって監視からエラーが出ていると連絡があったけど何かやった？」 私：「今、L3スイッチを繋いだところなのでリンクアップのメッセージとかじゃないですか？」 リ：「うちのシステムではなく、別のシステムの監視からエラーが出続けているそうなんだけど。」 私：「（別のシステム！？）」 自分のシステムならともかく、別のシステム！！！ しびれとも寒気ともいえぬ、血の気が引く感覚が全身を駆け巡りました。 惨劇はなぜおこってしまったのか すぐに原因の

SREチーム 鈴木心之介 です。 職歴の空白 を経て参画しました。 社名変更して co.jp ドメインを複数保有する技術 の節は皆様ありがとうございました。 たぶんそのうち書かれるだろう「Dockerコンテナ移行しました」記事の先史時代の記録として、また、事業の成長に併走してきたEC2でのアーキテクチャの御焚上として奏上するものです。 問題意識 アプリケーションはRuby on Railsで実装し、インフラはAWSにEC2, RDS, S3を中核に構成してます。運用状況はEC2に限らず大変きびしく、早くどうにかしないと事業の成長の足枷になりそうでした。入社前のカジュアル面談で伺っていた情報と、入社後の情報収集から、大枠の問題意識を以下4つに絞りました。 デプロイメント セキュリティ スケーラビリティ ディザスタリカバリ どれも解決すべきで、優先順位にみなさま一家言あるかと思います。ただセキ

本番環境でやらかしちゃった人 Advent Calendar 2020 14日目 の記事です。 稀によくあるアラートで始まる朝 ある日の朝、いくつかあるマイクロサービスの内の一つが稀によくある一部のメトリクスが取れてない趣旨のアラートが大量に飛んでいた形跡を発見した。 この稀によくあるアラートの原因として考えられるのは、一部のサーバーの調子悪いか、監視サービスが不調のどちらかだった。 ここで簡単にサービスの構成を説明しよう。 よくあるロードバランサーにいくつかのインスタンスがぶら下がってる系のもので、負荷が高まったらスケールアウトして、負荷が低くなればスケールインするいい感じのやつ。某AWSではオートスケーリンググループと呼ばれるもの。 インスタンスは使い捨て可能で、サーバーが不調になれば、自動でいい感じに殺すため、大体アラートが出ていても、朝起きた時には直ってることが多い。 加えて早朝に

この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」の12日目です。参加できて嬉しいです。 https://qiita.com/advent-calendar/2020/yarakashi-production ※この話はフィクションです。また、派手な内容ではありません。 AM8:35 私は某ソフトウェア開発会社でシステムのヘルプデスクを担当している。いつも通りに出勤し、パソコンを立ち上げ、問い合わせメールがないかチェックする。 正確には「開発以外担当」である。体制図にも文字通りそう書いてある。開発担当が「開発の要件が決まってから商用リリースまで」を、開発以外担当が「それ以外」をやる。ユーザニーズをまとめて開発内容を整理するのも「以外担当」であるし、開発担当が作ったバグも、リリース後ならお客様対応含め「以外担当」がやる。あなた方に瑕疵担保責任という概念はない

はじめに どうも、情シスの徳道＠上越オフィスです。今回はネットワークネタです。 唐突ですが、会社を代表するグローバルIPアドレスって多くの場合は本社の固定グローバルIPアドレス（プロバイダに依存）ではないでしょうか。 ゼロトラストが叫ばれて久しいですが、弊社のようにお客さまの環境を保守するサービスを行っている場合、やはり境界防御として接続元のグローバルIPアドレスを指定して許可されることが多いです。 地方オフィスが増えてくると特定の環境への接続許可をしてもらうIPアドレスの登録も増えてきます。VPN接続で本社など特定拠点経由での接続を行っていたとしても、プロバイダに依存することになったり冗長化が大変だったりしますね。 弊社では数年前からAWSのElastic IP経由で変化しない&冗長化されたグローバルIPアドレスからAWSに接続する社内ネットワークを構築してきました。 今回はクラスメソッ

Amazon Linux 2 上に .NET 5 と MagicOnion を使ったゲームサーバー開発環境作ってみた #csharp 先日リリースされた .NET 5 SDKを使い、Amazon Linux 2上にMagicOnionを使ったゲームサーバー開発環境を作ってみました。 こんにちは、事業開発部の高野です。このエントリは下記のAdvent Calendar 2020への、8日目の参加エントリです。 AWS & Game Advent Calendar 2020 - Qiita C# その2 Advent Calendar 2020 - Qiita 前日はそれぞれ AWS & Game AWS SDKをUnity(2018.1以降)で使う - Qiita C# その2 【WPF】XAMLビューアーにRegionの内容を表示させたい【Prism】 - Qiita でした。 はじめに

自己紹介 本職のエンジニアではありませんが、ちょっとICT系に詳しそうなやつって感じで、部署のサーバ管理を任されたりもしています。 背景 私の（当時所属していた）部署では、毎年、数週間かけて前年の各人の業務実績をとりまとめて一つの冊子（PDF）にするという仕事があり、この作業を少しでも自動化するため、Webサービスが内製されました。当初は単純に各ユーザが自分の業務実績一覧をテキストで用意してアップロードするというものでしたが、秘伝のタレのように毎年少しずつ改良されたり、大幅に作り直されて別システムから業務データを取り込んでからブラウザ上で編集できるようになったりしつつ、なんやかんやあって私が引き継ぎます。他にやりたい人もなく、ひとり鯖管です。OSはCentOS6でした。 このシステムでは、毎年新しいデータを編集するため、その作業開始時にデータを初期化する必要があります。この作業も自動化し、

とある休日 ワイ「あ〜、今日は暇やな〜」 娘（5歳）「ねえパパ、相談したいことがあるんだけど」 ワイ「おお、娘ちゃん」 ワイ「ええで、何でも相談してや」 娘「実はね、幼稚園である遊びが流行ってるの」 ワイ「ほうほう、どんな遊びかな？」 娘「ええとね」 娘「サイコロを2回ふって、2回とも同じ目が出たら勝ちっていう遊びなの」 ワイ「おお、楽しそうやないかい」 娘「それでね、勝った人にはすご〜くいいことがあるの」 ワイ「ええ？すご〜くいいこと？」 ワイ「なんや気になるわ、教えてぇや」 娘「100万円もらえるの」 ワイ「ととと賭博やないかい！！！」 娘「しかも、そのあとね」 娘「なんやかんやで三食付きの施設にずっと無料で泊まれるの」 ワイ「いや、それブタ箱入っとるやないかい！！！」 娘「でもこの間、その遊びが幼稚園の規則で禁止されちゃったの・・・」 ワイ「いや法律で禁止されてんねん」 娘「それでね

先週の金曜日で1ヶ月のCX事業本部での研修が終わりました、新卒エンジニアのたいがーです? 現在クラスメソッドの新卒一期生として入社した私たちは、風神、雷神という2チームに分かれ、各部署で研修をさせていただいています。それぞれの部署で出される課題に取り組み、年明けには正規配属される予定です。 4月からの研修はこのような形で進みました。 ES(エンプロイーサクセス)部: 1ヶ月 AWS事業本部 コンサル部: 3ヶ月 オペレーション部: 2ヶ月 IT推進室: 1ヶ月 CX事業本部: 1ヶ月 そして、私の所属している雷神チームは本日からDA事業本部で研修させていただく予定となっています。\よろしくお願いいたします!/ 気がつけば社会人になり研修が始まり、約7ヶ月。そろそろどこに希望を出すのか考えなければならない時期がやってきます。その際、どんなことをしたのか思い起こせるようにブログを書いておこうと

課題 突然キャンペーンとかの高トラフィックが来る！とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない！！とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 とりあえず何とかしたい TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.39

ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

はじめに 皆さんこんにちは！営業推進室の大森です。 クラスメソッド にJoinしてからそろそろ半年になります。弊社の理念は「オープンな発想と高い技術力によって全ての人々の創造活動に貢献する」と言うことですので多くのスペシャリストが在籍しております。そんな中私も最先端の技術を体感していないといけないと感じていました。 また弊社にはCLP（Classmethod Leadership Principle）と言う行動指針や価値観があります。リーダーシップ、パートナーシップ、ダイバーシティ、プロフェッショナル、感謝、顧客視点、フィードバック、情報発信、やってみる、楽しむの10項目です。 まずはやってみる 入社少し前から車の買い替えを検討していたのですが、そこで私は最先端のテクノロジーを体感すべく、またCLPの中の「やってみる」と言うことを忠実に実行するために行動に移しました。 やはり車業界の最新の