どんなアイテム？ 「フィギュア9」はたった13gの手のひらに収まるカラビナ。 特徴的なのは、本体下部のギザギザした部分。このパーツが、ロープワークの手助けになるアイディア商品なのです。 数秒で面倒なロープワークが解決 船のイカリのような形をしたこの箇所に、番号と矢印が記されています。 その指示の通りにロープをひっかけるとご覧の通り。面倒なロープワークを省くことができるのです。慣れると素秒でロープワーク完結します。 ちなみにロープの長さはどれだけ長くてもOK！　私は色んなシーンで使うことを想定して10m用意しました。 ロープの経に関しても2mm〜5mmと一般的に使用されるロープの経ならどれでも対応できるような構造になっています。 使用パターンは2つ使い方その1 まずはスタンダードな使い方として、カラビナにロープを固定する方法です。 カラビナのフック部の番号がふられている通りに、ロープを通しま

ヨッピー @yoppymodel ライター／オールドルーキーサウナ渋谷店GM／お仕事や相談はyoppymodel@gmail.com もしくはDMでどうぞ！ ヨッピーとは？ yoppymodel.hatenablog.com/entry/2018/11/… yoppymodel.hatenablog.com ヨッピー @yoppymodel この地図見ると「そのエリアで車が必須かどうか」が一撃でわかるな！ 青→車無し生活余裕 緑→車無いと不便だけど無くてもなんとか オレンジ以上→車必須 って感じではなかろうか。 ただ、北海道が真っ赤っかかと思いきや緑のエリアもそこそこあるのが意外！ pic.twitter.com/6d2eQkoe6r 2023-09-27 16:15:46

こんにちは、Platform Team というチームでマネージャーをしている荒引 (@a_bicky) です。 Platform Team は、データエンジニア・アーキテクト的な役割を担う Repro Core Unit と、インフラエンジニア・SRE 的な役割を担う Sys-Infra Unit から成るチームです。 先月 SRE Lounge #15 で「何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜」と題して次の発表をしたんですが、時間の都合上話せなかった内容があるので、それらについて触れたいと思います。 なお、当日の発表内容は動画でも視聴可能です。 アジェンダ 本エントリーのアジェンダは次のとおりです。 SRE Lounge #15 での発表内容の要約 Repro Core と Sys-Infra の棲み分け R

こんにちは、ソーシャル経済メディア「NewsPicks」でSREをしている飯野です。 今回はSREで行ったNew RelicをCDK for TerraformでIaC管理する話を紹介したいと思います。 SLOモニタリングをSREチームだけで行うのは難しい CDK for Terraformとcdktf-newrelic-provider 追記 IaCで作成する内容 CDK for Terraformで実装していく -1. cdktf init 0. @cdktf/newrelic-provicerの初期化 1.DataNewrelicEntityの作成 2.ServiceLevelの作成 3.AlertPolicyの作成 4.AlertCondition（バーンレートアラート）の作成 5. NotificationDestinationの作成 6. NotificationChannel

この記事について JavaScriptではthrow文という文を使うことで例外を投げることができます。 このthrow文ですが、私はレビューなどで例外を投げないでくださいというコメントをするのですがその理由とどのようにコードを変更すればよいのか、ということを書いておこうと思いました。 前提条件 この記事の内容は下記の条件を前提として書き進めていきます。 TypeScriptを採用していること フロントエンド開発の場合 Node.jsを利用したサーバーサイドのコードやCLIツールの開発、各種ライブラリの開発については本記事の対象に含まれないことをご了承下さい。 結論 先に結論から書いておくとTypeScriptを利用している場合例外はカスタムエラーを返却するか、Result型を利用するのがよいと思っています。 次の章からサンプルコードを用いながらthrow文を使った実例と、代替え案について記

Agile Journeyをご覧のみなさん、はじめまして。株式会社リンクアンドモチベーションの川津（@KawatsuYusuke）です。こちらの記事では主に私たちがFour Keys メトリクスを元に、開発生産性向上を目指した活動に関する話題についてお伝えします。 と言っても、『LeanとDevOpsの科学』をはじめ、Four Keysの運用に関するトピックはすでに多く語られています。また、Four Keysは便利なメトリクスであるがゆえに、ときに「Four Keysを改善する」という手段が目的化してしまうことがあります。本稿では主にこれから開発生産性向上に取り組もうとしている方に向けて、私たちの取り組みと、体験したアンチパターンをもとに、「Four Keys改善の取り組みには "なぜ？" が大事」についてお伝えします。 私たちの開発生産性向上のはじまりと、目指すべき状態の設定 Four

2023年12月4日追記。 この記事は2023年の9月下旬に書かれた記事です。 わりと反射的に書いてしまった内容も含んでるので(CNCFのリリースにもコメントを寄越していたGruntworkの関わりを見逃してたのは痛恨のミス。色んな思いがあるのはそれはそう)、本件について語るにもっと最適な方の説明を読んでいただければ幸いです。 先月行われたHashiCorp社によるソフトウェアライセンスの変更はTerraformコミュニティに衝撃を与えたことは記憶に新しい。具体的には、Terraformのライセンスが、オープンソース/フリーソフトウェアを前提としたMPL2.0から、商用利用に制限をかけられたBSLv1.1に変更された。これにより、Terraformは伝統的な意味でのオープンソースソフトウェアではなくなってしまい、ソースコードが単に利用できるソフトウェアに変わってしまったと評する人もいる。[

Twitterの内部構造を読解してみる 前口上 Twitterのようなマイクロブログサービスでは短時間で書き込みも多く、特にタイムライン周りは単にRDBのデータを出し入れるするだけではスケールしなくなります。 インターネット上に断片ながらTwitterの中の人がアーキテクチャについて解説した記事や動画がいくつか落ちていたので、Twitterがタイムラインをどうやってキャッシュしているかについてまとめてみたいと思います(推測を含みます)。 Twitterのテーブル構造 単純なTwitterのテーブル定義をRDBで定義すると以下のようになると思います。 tweets ツイート id user_id contents tweet_at followers フォロワー source_user_id destination_user_id users ユーザー id user_name timeli

Extraの詳細についてはMySQL『8.8.2 EXPLAIN 出力フォーマット#EXPLAIN の追加情報』をご覧になってください。 EXPLAINでチェックすべきポイント EXPLAINの結果を利用してクエリチューニングする際のチェックポイントについて紹介します。 typeに『ALL』『index』が表示されていないか ALLはインデックスを利用せず、テーブルのフルスキャン（全表走査）が実行されていることを意味します。テーブルのフルスキャンはとても遅い処理です。 indexはALLと違いインデックスこそ使われていますが、当該インデックスをフルスキャンする必要のある遅い処理です。 ExtraのUsing indexはインデックスだけでクエリが解決できることを示すポジティブな指標ですが、typeのindexはネガティブな指標なので注意しましょう。 ただしORDER BYとLIMITを組み

mysql> select * from test_table; +----+--------+--------+--------+ | id | teamid | status | a | +----+--------+--------+--------+ | 1 | 1 | no | 200 | | 2 | 1 | ok | 250 | +----+--------+--------+--------+ 2 rows in set (0.00 sec) mysql> mysql> select * from test_table \G ************ 1. row ************ id: 1 teamid: 1 status: no a: 200 ************　2. row ************ id: 2 teamid: 1 status: ok

Indexを作成すべき列の特長 1. テーブル内のデータ量が多く、少量のレコードを検索する場合 2. WHERE句の条件、結合の条件、ORDER BY句の条件として頻繁に利用する ただし全表走査が目的のテーブルであれば索引は不要 3. NULL値が多いデータから、NULL値以外の検索をする IndexはNULLを含まないのでNULL値以外の検索には効果がある 逆に、Indexを作成すべきでない列の特徴 表の規模が小さいか、表から大部分のレコードを検索する場合 WHERE句等の条件としてあまり仕様されないもの 列の値が頻繁に挿入、更新、削除される Indexは表に新規行が挿入されればIndexにも自動的に値が格納される。そのためデータの検索速度は向上するが挿入、更新、削除の処理では索引のメンテナンス作業が発生し、速度低下につながる WHERE句の条件として使用されるが、列が式の一部として参照

こんにちは、つくぼし(tsukuboshi0755)です！ RDSの機能の一つとして、パフォーマンスインサイト(Performance Insights)というものが存在します。 今回はRDSパフォーマンスインサイトについて、頭の整理を兼ねて深掘りしてみたいと思います。 パフォーマンスインサイトとは？ パフォーマンスインサイトを有効化する事で、RDSのパフォーマンスに関するデータが集計され、AWSコンソール上に可視化されます。 コンソール上で可視化されたグラフから、DBの負荷の原因となっている項目を見つけ、DBの性能改善に役立てる事が可能です。 AWSの公式ドキュメントでは、以下のように記載されております。 平均アクティブセッション(AAS)とは？ パフォーマンスインサイトでは、平均アクティブセッション(AAS)という単位で、DBへの負荷状況を測定します。 AASは、以下のように計算されま

Amazon Web Services ブログ Performance Insights を使用して Amazon Aurora の MySQL のワークロードを分析する Amazon Relational Database Service (Amazon RDS) Performance Insights を使用すれば、パフォーマンスの問題の原因だけでなく、Amazon RDS データベース上のワークロードの性質を即座に把握できます。このブログ記事では、Amazon Aurora MySQL-Compatible Edition の Performance Insights ダッシュボードを手短に見て、パフォーマンスの問題を分析する方法を学びます。前回のブログ記事「Performance Insights で Amazon RDS データベースのワークロードを分析する」では、Perfor

HTTPステータスコードの422エラーは、404や500などのコードほど一般的にはみられません。422エラーは、リクエストのどの部分が問題を引き起こしているかが明確にわからないため、判断が難しいことがあります。 概して、422はサーバーがリクエストを理解しているのに、ユーザー側の問題で処理されないことを意味するコード。何かしらの問題を修正し、ページを再読み込みすれば、エラーは解決できます。 この記事では、WordPressユーザー向けに、422エラーの原因と解決方法をご説明します。早速みていきましょう！ 422エラーについて動画での解説もご用意しています。 HTTPステータスコードの422エラーとは 422エラーは、サーバー側がリクエストを理解しているにもかかわらず、処理ができないというHTTPステータスコードで、正式名称は「422 Unprocessable Entity（処理できないエ

【Laravel】Mysql とのコネクションをプーリングさせる方法Laravel で Mysql とのコネクションプーリングを行う方法メモ。 プーリングさせる意味PHPではデフォルトでDBへの接続をプーリングさせません。 ですが、DBへのコネクション数を減らして負荷を下げる意味では行う方がベターです。 また多数のSQLを発行する場面で一々コネクションの発生が抑えられるなどの効果があります。 修正PDO::ATTR_PERSISTENT の設定を追加。 PDO::ATTR_PERSISTENT はコネクションプーリングの設定です。 PHP: 接続、および接続の管理 - Manual #例4 持続的な接続 <?php // ～省略～～～～～～～～～ 'mysql' => [ 'driver' => 'mysql', 'url' => env('DATABASE_URL'), 'host' =

最近めっちゃLaravel使ってます。 で、Laravelのコネクションプーリングの話です。 コネクションプーリングとは、DBとの接続を永続化させること。 フレームワークによっては、これがデフォルトで永続化されているものもあるようですが、Laravelの場合はデフォルトで永続化がオフになっています。 DBとの接続の永続化、というと語弊があるかもしれないので補足しておくとPDOオブジェクトのインスタンス化時の接続をキャッシュしておく、といったほうが良いでしょうか。 これによって、毎回クエリ実行時に接続をする必要がなくなるのでオーバーヘッドが短縮され、高速化される、というわけですね。 あまり必要に感じる場面には出くわさないかもしれませんが...笑 で、Laravelでコネクションプーリングを有効にする設定が下記です。 'pgsql' => [ 'driver' => 'pgsql', 'url

トランザクションがコネクション切断時とかに、どういう挙動を示すか？調べてみました。 PHP＆MySQLのトランザクション関連の仕様ざっくりと デフォルトでは、すべてのSQLがトランザクションを使用し、オートコミットする。（updateしたら即反映） 明示的に、beginTransactionした場合、そのコネクション上で行われた更新は、commit or rollbackメソッド実行時に一括で反映される。 また、beginTransaction中に接続が切断された場合、rollbackする。 http://dev.mysql.com/doc/refman/5.6/ja/innodb-implicit-commit.html 他のRDBMSだと、コネクション切断時はデフォルトcommitだったりするときもあるので、挙動は確認したほうが良いと思います。 暗黙的コミットにも気をつける 13.3.

https://yojo.connpass.com/event/294169/ のイベントの登壇資料です。 React のコンポーネント指向開発について、いくつかの誤解があります。（またはかつてありました。）これらの誤解を解きながら、「一つのコンポーネントが複雑で長大になる」「多くのコードジャンプを要して、全体像をつかみにくい」状況に陥らないためのコツを「Container コンポーネント」に着目して解説します。