なんだか助かる便利なおっちゃんになりたい - Qiita
これまでの生存戦略 それほど尖った能力や知識がない中で、私のこれまでの生存戦略としては求められればなんでもやる、少しくらい泥水でも飲むというものでした。 フロントエンドからバックエンド、データベース設計、API設計、実装、インフラ側の設定、提案書作成、プレゼンテーション、プロジェクト進行、どれも“専門家として誇れるか”というと疑問がありますが、求められればなんでもやるスタンスでそれが自分の価値提供の形と考えていました。 また、以前までは「若い」というのも、強みでした。 一回りほど上の年齢に見られることも珍しくなく、「そんな若かったのか」と驚かれるなかで、「若いのに頑張ってるね」と年齢のフィルターで大目にみてもらえました。 しかし、そんな私も気が付けば40歳、もう若さという武器はありません。 （つい先日まで20代だったはずなのに..何かおかしい..） 体力的にも無理が効かず、新しいことを学ぶ
Apple Watch で取得したデータを Google Cloud に自動連携して BigQuery + Dataform + Looker Studio でダッシュボードを作った - Qiita
Apple Watch で取得したデータを Google Cloud に自動連携して BigQuery + Dataform + Looker Studio でダッシュボードを作ったBigQueryAppleWatchGoogleCloudDataformLookerStudio プロジェクトの区切りに初めて長期休暇を取得することにしました。 プロジェクト終盤の忙しさで疲れが溜まっていたので、休暇中に健康的な生活を送るために apple watch から取得したデータを可視化することにしました。 この記事では apple watch で計測したデータを毎日自動的に可視化する方法を書いています。 やったこと こんな感じのアーキテクチャで睡眠の可視化を作りました。 現時点で作成したのは次のような図です。 さすがにもう少し睡眠を取っている自覚はありますが、睡眠が浅いときに apple watch
SQS → Lambdaのリトライ処理について整理してみた - Qiita
AWSコンソールの画面でAWS Lambdaの画面に遷移して[関数] → [関数を作成]で "dog"という名前のLambda関数を作成します。 今回はロールは[基本的な Lambda アクセス権限で新しいロールを作成] で作成しインラインポリシーで以下の権限を追加しました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:[region]:[accountID]:inu-queue" } ] } そして[トリガーの追加]から先ほど作成したSQSのキュー"inu-queue"を選択しトリガーを有効にし
Branded Type について理解する - Qiita
目次 背景 既存の問題 Branded Type とは ユースケース 実践 最後に 1. 背景 先日あったSansan様のセミナーでBrandedTypeについて初めて知った為です。 こちらがプレゼンに使われていた資料です。 元ネタはこちらです。 次節から元ネタの方を和訳して説明します。 2. 既存の問題 以下をご覧ください。 function print(age:number,height:number) { console.log('ageを表示:',age); console.log('heightを表示:',height); } const age = 25; const height = 175; print(height,age); 引数の順番を間違えてしまいましたが、どちらも同じstring型を受けっているのでTypescriptではエラーにはなりません。 しかし、意図した処
Go言語の埋め込みについて4つのポイントでまとめました - Qiita
インターフェースに構造体は埋め込めません。インターフェースにはシグネチャを与えるものなので具象な構造体を埋め込むのはNGですね。 逆に他3つは可能です。それぞれの使い方を下記のサンプルコードで確認しました。 package main import ( "fmt" ) type Flyer interface { Fly() string } type Runner interface { Run() string } // ① インターフェースにインターフェースを埋め込む type FlyingRunner interface { Flyer Runner } // ② 構造体にインターフェースを埋め込む type ToriJin struct { // 鳥人 FlyingRunner } // ③ 構造体に構造体を埋め込む type ShinJinrui struct { // 新人類
【Go】型が特定のinterfaceを満たしているかをコンパイル時に確認させる方法 - Qiita
はじめに こんにちは、kenです。お仕事ではGoを使っています。 先日、Effective Go（Goの公式が出している慣用的なコーディングスタイルと実践を記したドキュメント）を読んでいたら興味深いことが書かれていたので今日はそれについて書こうと思います。 内容は「型が特定のinterfaceを満たしているかをコンパイル時に確認させる方法について」です。 Goのinterfaceについておさらい 本題に入る前にGoのinterfaceについてざっくり説明しておきます。interfaceについてもう知っているよという方はスキップしてください。 Go言語ではinterfaceをメソッドシグネチャの集合として定義します。 そして型がinterfaceを実装する際には、interfaceの定義に使ったメソッドを型に実装するだけでよく、「その型がどのinterfaceを実装しているか」については明示
bulkのinsert on duplicate key updateでデッドロックした話 - Qiita
VISITS Advent Calendar 22日目の記事です。 いま自分のチームではRailsのアプリケーションを運用しているのですが、MySQLのデータベースでごくまれにbulkのinsertでデッドロックが発生して原因究明に時間がかかったので、その内容を共有したいと思います。 状況 今回自分が遭遇したデッドロックは、RailsのコードからMySQLのDBに対して複数件のデータを一括挿入するタイミングで発生しました。 Rails6.0からbulk insertの機能が標準サポートされたんですが、Rails6.0以前ではactiverecord-importというgemで対応するケースが多いかと思います。 運用中のアプリケーションもRails6.0以前から運用していたこともあって切り替えられていないところも多く、今回のデッドロックもactiverecord-importの箇所で発生しま
[AWS CDK] Construct IDはパスカルケースで命名するのが良い - Qiita
new Table(this, 'ItemTable', { partitionKey: { name: 'id', type: AttributeType.STRING }, }); Logical IDは、CloudFormationテンプレート内でリソースを判別するためのIDです。 例えば以下のテンプレートでは、 ItemTable8236C20F がLogical IDです。 "Resources": { "ItemTable8236C20F": { "Type": "AWS::DynamoDB::Table", "Properties": { "KeySchema": [ { "AttributeName": "id", "KeyType": "HASH" } ], "AttributeDefinitions": [ { "AttributeName": "id", "Attri
![[AWS CDK] Construct IDはパスカルケースで命名するのが良い - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/17a5b6a3a7547586591a84135af2e3b3f81e60b0/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCQVdTJTIwQ0RLJTVEJTIwQ29uc3RydWN0JTIwSUQlRTMlODElQUYlRTMlODMlOTElRTMlODIlQjklRTMlODIlQUIlRTMlODMlQUIlRTMlODIlQjElRTMlODMlQkMlRTMlODIlQjklRTMlODElQTclRTUlOTElQkQlRTUlOTAlOEQlRTMlODElOTklRTMlODIlOEIlRTMlODElQUUlRTMlODElOEMlRTglODklQUYlRTMlODElODQmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWIyMGJkNzFmMDk5ZDE5Njc2YzlkZDhhOGZmOWM3MzVj%26mark-x%3D142%26mark-y%3D100%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDB0bW9rbXNzJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0wZGFlM2ViOGI2NGU4ZGI3MGY0ZDhkOTBiZTZlMGNmOQ%26blend-x%3D142%26blend-y%3D504%26blend-mode%3Dnormal%26s%3D7dcb6330dc61bad12d1595b930f3718f)
Raspberry Pi 4 でおうちKubernetesを作ろう（Raspbian Buster Lite対応版） - Qiita
Raspberry Pi 4 の考慮点 Raspberry Pi3 と比べた場合のRaspberry Pi4 の考慮点は以下の通りです。 発熱が大きいので、大型ヒートシンクか冷却ファンが必要 電源端子が、micro USB Type-B から USB Type-C に変更 必要な電源が5V/2.5A から 5V/3A に変更 他のおうちKubernetesな記事で使っているような ファンレス＆小型ヒートシンクな積層型ケース は使えないことに注意が必要です。 また、Raspberry Pi 4 は 5V/3A を電源として要求します。 一方、本環境では、電源としてAnker PowerPort+ 5 60W 5ポートを使っています。こちら 5V/2.4Aです。 今のところ、電源不足のログが出力されることもなく、動いているようなので、ひとまずこちらを使うことにしています。今後問題が出てくるよう
Amazon ECS の Blue/Green デプロイメントの動作は何が起こっているか解説したい - Qiita
はじめに Amazon ECS は、コンテナを動かしうまく管理するためのコンテナオーケストレーションサービスです。新たなバージョンのコンテナをデプロイするときに、いろいろなデプロイの方法が取れますが、ECS 側で用意されているデプロイ戦略が3種類あります Rolling Update : Service の中で稼働しているタスクを少しずつ順繰りアップデートする方式 Blue/Green Deployment : 新たな環境である Green 環境を用意して、LB レイヤーで切り替える方式 External Deployment : 外部のサードパーティの何かでデプロイをコントロールする方式 こちらの Document に記載があります。 : https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-types.htm
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
Amazon DynamoDB の論文を読んでいく - Qiita
概要 AWS で人気のサービス DynamoDB についての論文が公表され巷で噂になっていたと思う。 今回は、その論文を読み込んでいき、ざっくりまとめていくという記事になります。 完全趣味な記事なので、興味ある人がいれば幸いです笑 Abstract まず論文のタイトルですが、「Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service」と題したものとなっています。 Amazon DynamoDB は、NoSQL とよばれる部類のデータベースサービスです。 一貫した耐久性、可用性、パフォーマンスを提供してくれるマネージドなサービスなのが特徴ですね。 冒頭、2021年に66時間にわたる「Amazon Prime Day」中にピーク時8920万リクエスト/秒をさばいてい
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
Cognitoで学ぶ認証・認可 in AWS - Qiita
この記事について Webアプリのアクセス制御を行いたい！となったときに学ぶべきなのは認証・認可の仕組みです。 AWSにはAmazon Cognitoというユーザー管理を行うための仕組みが存在し、これを利用すれば「実装するだけなら」簡単にアプリのアクセス制御を行うことができます。 この記事では「Cognitoが実際に何をやってくれているのか？」というところまで掘り下げながら、簡単なReactアプリを作っていきます。 アジェンダ Cognitoのユーザープールを作って触ってみる Reactアプリに認証の仕組みを入れてみる Cognitoで認証済みの人だけが叩けるAPIをLambda + API Gatewayで作る CognitoのIDプールを作り、AWSでの認可の仕組みを学ぶ Cognito IDプールで認可された人だけが叩けるAPIをLambda + API Gatewayで作る 使用する
WebSocketについて調べてみた。 - Qiita
実はけっこう前からWebSocketの詳しい仕組みについて気になってて、遂に一念発起して調べてみた。何かとても良さげっぽい。 そもそもWebSocketとは Webにおいて双方向通信を低コストで行う為の仕組み。インタラクティブなWebアプリケーションではサーバから任意のタイミングでクライアントに情報の送信とかしたい事があって、例えばFacebookのチャットアプリみたいに多数のクライアントが一つのページにアクセスしてて誰かがメッセージを投稿するとそれをその他のユーザーに通知したい場合があって、そういった時に双方向通信の必要性が出てくる。 元々はWebにおいてはHTTPしか通信の選択肢が無くてHTTPのロングポーリング使って無理矢理双方向通信実現したりしてたんだけど、流石に無駄が多すぎるし辛いよねって事でWebSocketというプロトコルが作られた。 WebSocketにおいては、TCP上で
大規模データ移行の失敗を防ぎたい。計画やプログラム、インフラの注意点と、ありがちなこと - Qiita
仕事柄、大規模なデータ移行を何度か経験してきました。 データ移行、特にDBのマイグレーションでもなく、 システム移行のときのようなデータ構造の変更を伴う際には気をつけることがたくさんあります。 クラウドではだいぶ楽になりますが、 特にオンプレミスで検討せざるを得ない皆さんに気をつけないといけない点を共有します。 スケジューリング編 最初から検討し始めよう 開発プロジェクトにおいてシステム移行だけで4割の工数がかかると言われています。 しかし、新規システム部分の開発で頭が一杯になっていると、重要度の割に移行部分が後回しにされがちです。 移行用プログラム、移行用サーバ手配はもちろん、新規、既存システムへの影響も検討しないといけません。 できればプロジェクト開始時から人をアサインして計画を立てていきましょう。 移行自体が一つの開発プロジェクト相当です。頑張りましょう。 後半になって移行計画を立て
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
DynamoDB の設計について考えてみる。 - Qiita
Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R
TypeScriptのmoduleSuffixesについて考えて納得した - Qiita
みなさんこんにちは。今日は、TypeScriptの新しいコンパイラオプション（おそらく4.7で導入）であるmoduleSuffixesについての話題がTwitterで見られました。 moduleSuffixesについて詳しくはこちらをご参照ください。 これについては、「モジュール解決がさらに複雑化する」などいくつかの方向性から否定的な意見が見られました。しかし、筆者が考えてみたところ、正当性のある機能追加だと納得できたので考えをご紹介します。 3行でまとめると これまで通りランタイムの挙動に影響しないから大丈夫だよ pathsが怖くないならmoduleSuffixesも怖くないよ TypeScriptはJavaScript環境に追随するよ moduleSuffixesとは では、moduleSuffixesはどんなコンパイラオプションなのかという解説をまず少しします。これはTypeScri
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Go 言語】interface のポインタからメソッドコールできないのはなぜ？ - Qiita
