サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
今年の「#文学」
www.keisuke69.net
もう一週間ほど前になりますが「AWS Lambda 10周年記念生誕祭」というイベントを2024年11月13日に開催しました。知らない人のために一応お伝えするとAWS LambdaというAWSのサービスがありまして、このサービスがちょうど10年前の2014年11月13日に発表されたことからAWS Lambdaに縁のある人たちを集めてワイワイやるっていうイベントです。 serverless-newworld.connpass.com 会場はFindyさんの大崎オフィスでした。人数は約100人ほどでオンラインはなくオフラインのみです。半年くらい前に募集開始してあっという間に埋まり、当日を迎えました。久しぶりにお会いする懐かしい方、お世話になった方、一方で馴染みはなかったもののイベント趣旨に賛同して来てくれた方など多くの人に集まっていただけました。なお、残念ながらキャンセルされた方もいらっしゃっ
久しぶりのポエムです。先日Xで何気なくこんな投稿をした。今回のポエムはこの投稿がきっかけだ。 自分でプロダクト作るのもいいけど、すでに多くのユーザー抱えて世の中の役に立っててイケてるプロダクトを開発してるチームの困りごとの解決を支援した方が結果的に世の中により多く貢献できるのでは？と思って今はDELTAにいる 今思えばAWSに入った時も同じような考えだった— Keisuke Nishitani (@Keisuke69) 2024年11月2日 僕はこれまでずっとソフトウェアエンジニアとして20年くらい働いてきた。ソフトウェアエンジニアと言っているがインフラ領域をやっていた期間もキャリア初期に多少ある。クラウドではなくオンプレだ。2000年代後半はとあるクラウドサービスを作る側にいて、利用者としてクラウドを使うようになった2011年以降はサーバーサイドの開発でクラウドインフラの構築を包含するよ
Xなどではすでにお話ししていますが、2024年6月17日から株式会社DELTAという会社のCOO（最高執行責任者）を務めています。 今日から株式会社DELTAでCOOをやることになりました。 CTOじゃなくてCOOです。 なお、これまでの株式会社Singular Perturbations (犯罪予測のほう)のCTOも引き続きやります！ pic.twitter.com/BmuGwhC6Az— Keisuke Nishitani (@Keisuke69) 2024年6月17日 この投稿では会社のロゴ画像のみ投稿したのでティザー広告みたいで何をするのかさっぱりわからないってお声をたくさんいただいたので簡単に紹介しておきます。でも本題はそこじゃないです。 今回はなぜ僕がこういう選択をしたのかという話です。 DELTAって？ 何をやるのか なんでやるのか 経緯 不安はなかったのか 最後に DELT
はじめに まず、大事なこと イベント開催告知まで 開催告知初日 2日目 3日目以降 企画に関して 認知に関して 最後に 本記事の内容を以下のイベントで話します。YouTube Liveでオンラインです。 【天下一武道会裏話】3000人集客のためにやったことなど話します - connpass はじめに 去る2024年2月1日に『第1回 AWSコスト削減天下一武道会』という勉強会を開催しました。 このイベントはわたくし、西谷が個人で企画して運営したイベントですが最終的な申し込み数は3692人とかなりの規模になります。 これがどのくらいの数かと言うと昨年Connpassで募集されたイベントで1番のものが日本ディープラーニング協会主催のイベントでちょうどGPT4が発表されて大注目を浴びたタイミングで開催されたものであり、4900人以上とすごい数になっています。さすがにこれには及ばず、2番目に多かっ
昨日、2024年2月1日に自身が企画・運営をした『第一回AWSコスト削減天下一武道会』というイベントを終えました。申し込み人数としては最終的には3692人の人がConnpass上で申し込んでくれました。 この数は個人が企画して開催するIT関連の勉強会としては類を見ない規模だったのではないかと自負しております。 もちろんテーマとか色んな条件が重なってのこの数字ではありますが、集客のために意図的にやったことなどもありました。それらが予想以上の効果を出したわけですがその辺の話に興味のある方も多そうだったのでこちらについては別途イベントを開催して話すことにしました。 no1.connpass.com こちらは2月5日の12時からオンラインのみで開催します。 イベントの振り返りですがまずは素晴らしい発表をしていただいた登壇者の方々にお礼を言いたいです。ありがとうございます。 発表内容もさることながら
はじめに すでに2024年も10日目が過ぎて、もちろん仕事始めもしているのですが昨年中に間に合わなかった振り返りとかをしていこうかなと思います。 前提 自分は株式会社Singular Perturbations（以下SP）というスタートアップで取締役CTOをしている。この会社は『犯罪予測』というテクノロジーを研究開発し、それをもとにしたソリューションをプロダクトとして提供している。 また、これとは別に妻と一緒に会社をやっている。とはいえ自分はこの会社のオーナーではあるが代表取締役社長は妻となっている。自分は役員ですらない。 2023年を一言で言うと 『停滞』の一言につきる。といってもこれはあくまでもエンジニアとしての停滞という意味。 どういうことかというと2023年はプロダクトの開発ということ自体をあまりしなかったのもあるし、仕事としてソフトウェアエンジニアリングの観点で新しいこともあまり
昨年までは毎月買った本やマンガとそれらに対する一言コメントをブログで書いていたんだけど今年はそれをやらずに来てしまったので今年かった本で良かったものをいくつかピックアップして紹介する。 実際にはもっと数多く買ってるし、買っただけで読んでいないものも多い。2023年に買った本はマンガも合わせて合計で366冊、そのうちマンガ以外は151冊だった。 なお、対象は自分で買った書籍だけ。つまり献本とかでいただいたものはこの対象に加えていません。 ちなみにいずれの本もすべて電子書籍で購入している。全体ではAmazonのKindleを中心に一部オライリーのeBookなんだけど、選んだものはすべてKindleで買ったものだった。 というわけで紹介していく。 AWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか フロントエンド開発のためのセキュリティ入門 知
はじめに 6月21日（水）に『俺たちの本当にやりたかったDevDay（俺たちのDevDay）』を無事に開催できたので記録がてら簡単に振り返っていきます。読み物なので長いです。 このイベントが行われることになった経緯とかはこちら。 俺んとこ 来ないか？『俺たちの本当にやりたかったDevDay』を開催することにした - Sweet Escape 当日まで 当日までのあれこれを時系列で。 まず、このイベントをやるって決めて会場も決まってない状態でConnpassでイベント作って公開したのが4月24日。ちなみにこの会場決まってない状態でイベント作ったことが後々面倒なことになるのだけどそれは後ほど。ありがたいことに翌日にはクラスメソッド株式会社さんに会場提供いただけることが決まった。 その後、本家のCFP結果が決まるまで特に進展はなく5月1日に本家のCFPの結果が発表されたので早速俺たちのDevDa
というわけでやります。 connpass.com まだ詳細は決まってないけど良かったら来てね。 今回はこのイベントにまつわる話です。ダラダラと書いたので長いです。 はじめに 2023年の6月21日から22日にAWSの開発者向けイベントであるAWS DevDayが開催される。このAWS DevDayではCall for Proposal（CFP）という形でセッションが公募されている。 細かいルールとかはこちらを見ていただくとして、採択されるかどうかには一般の人からのリアクションの数も参考にするという。 さて、転職してからはめっぽう外部で登壇するってことは減っている。 これは今の僕は有限である時間の割り当て先としてそういった活動ではなくプロダクト開発に直接的に関係することにあてたいからだ。 とはいいつつもたまにはそういうこともして世の中にアピールしておかないとなってことで僕もCFPを出した。以
はじめに 先日、エンジニア界隈では有名なポッドキャストであるfukabori.fmに出させていただきまして、そのときのトピックがサーバーレスでした。 ポッドキャストはこちらで聞けますのでぜひどうぞ。 fukabori.fm そこでもいろいろお話ししたのですが改めて話せなかったことなども含めて書こうかなと。つまり、ポエムです。散らかった文章な上に少し長めなのでお時間のある方だけどうぞ。 なお、サーバーレスの黎明期の話とかそういう思い出話は以前に書いたこちらの投稿があります。 サーバーレスと僕のこれまでとこれから - Sweet Escape 今回は思い出話ではなく、サーバーレスに個人として魅力を感じ、仕事としてその良さを広めたり、実装のお手伝いをし続けてきた自分がそういった仕事から離れた2022年現在どういう風に向き合ってるかについてのポエムです。 前提 現在の自分は株式会社Singular
SQLに関するメモ。前提としてPostgreSQLを使っています。 以下のようなTimestamp型で日時の情報を持つテーブルがあるとする。 id: integer timestamp: timestamp with time zone 1 2022-01-01 00:00:00+00 2 2022-02-01 00:00:00+00 3 2022-10-01 00:00:00+00 4 2022-10-01 00:00:00+00 5 2022-12-01 00:00:00+00 で、月ごとの件数を集計をしたい場合、何も考えずにこんなSQLを書く。 SELECT to_char(timestamp, 'YYYYMM') AS MONTH, count(id) FROM table1 GROUP BY MONTH ORDER BY MONTH; そうすると得られるのはこんな結果。 mont
はじめに 近頃Zoomとかで話をするときに背景について聞かれることが増えてきたので過去に別ブログに書いた記事をアップデートしつつこちらのブログに持ってきました。背景と言ってもバーチャル背景ではなくリアル背景なのですが、その話です。 時期的には2020年くらいの話です。 我が家っていうか自室です。もともと７畳ほどの部屋を自室として使っていたのですが、まあなんの変哲もない部屋だったんですね。普通に白い壁紙が貼られてる感じのよくある普通の部屋です。 リビングは一部の壁面をエコカラットにしていてとてもいい感じなんですが。 なので以前から部屋の雰囲気を変えたいなーと思っていたわけです。そんな中で新型コロナウィルスが流行してリモート会議・ビデオ会議が多くなってきてました。Zoomのようにバーチャル背景がある場合はいいんですが、当時在籍していた会社ではその機能がないミーティングツールを使うことが多かった
このブログはクラメソの方がこういうの書いていたので試しに書いてみた感じです。 AWS DevDay Japan 2022 に「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 」というタイトルで登壇しました #AWSDevDay | DevelopersIO 資料 speakerdeck.com 発表理由とか AWSのDevDayはCFPを募集していることから応募した結果、無事に採択されて昨年に引き続きセッションをする機会をいただきました。実は2個出したんだけどもう一方はダメでした。 FirebaseのCloud FirestoreをやめてAWS上で構築したAPIへ移行するという話なんですが実は以前にも検討段階でこのブログで書いた内容です。今回はタイミング的に実際に移行した後ということで前回のブログの内容をアップデートするような内容となっています。 以前のブ
今作ってるAPIでは初めてNest.jsを使ってるんだけど、認可処理をどうしようかと考えたのでそのメモ。 ちなみにこの投稿では簡単な定義として認証(Authentication)とは利用者の本人確認、つまり通信の相手が誰であるかの確認とする。一方、認可（Authorization）とは利用者がシステム内、サービス内で実行できる操作の権限とする。 前提 TypeScript Nest.js Prisma Firebase Authentication 認証自体はFirebase Authenticationを使っているので、認可をどうするかが話の主眼。 なお、前提として認証はクライアントサイドでFirebase Authenticationが認証時に発行するJWTのトークンを取得してAuthorizationヘッダにBearerトークンとして渡すよくあるやつで対応しますが、ここに関しては本投
今回はバックエンドAPIでページネーションをどうやるかについての話なので、よくある無限スクロールUIのようなフロントエンド側の実装に関する話はしない。あくまでもAPI、もっと言えばRESTfulなAPIのリクエスト・レスポンスにおけるページネーションの話。 本気で深く考えるというよりざっくり検討したときの話です。 はじめに REST APIを実装するにあたってリスト系のAPIを提供する場合に必須といっても過言ではないのがページネーション。大量のリソースをレスポンスする場合にそれらを一気に返してしまうことは応答速度、転送量、クライアントサイドでの扱いづらさなどなどに繋がるので必須と言える。 最近、新たなAPIを開発するにあたってページネーションをする必要があったこともあり、今回はこのページネーションをどうやって提供するか整理して改めて検討してみた。 前提 TypeScript Nest.js
既存のデータベースをPrismaでマイグレーションできるようにしたくなった。理由はいろいろあるがやはりローカル環境 → 開発環境 → ステージング環境 → 本番環境へとDBの定義を反映していくのが手作業はさすがにないなと思えてきたからだ。もちろん実際には毎回SQLを直接手で入力なんてことはないだろうけど。 あとは他の人が開発するのにDBのセットアップをする際にも楽だ。 というわけで導入しようとしたのだがそれなりに悩んだりしたのでメモを残しておく。 前提 すでに存在しているDBをPrismaのmigrationツール管理下におく これまでは直接DBにDDL文を実行して定義などしていた DBの定義はprisma db pullを実行してsyncしていた やっていく まずは既存のDBの定義とPrismaのモデルを同期します。普段からやってるものの念の為。 prisma db pull 同期したら
FirebaseのFirestoreをやめることにしたので雑なメモを残しておく。なお、まだ走り始めたばかりなので、内容には間違いや考慮不足も多数含まれる可能性があるので読む人はその点注意を。あと、あくまでも雑なメモなので細かいところは書いていない。 なぜ脱Firestoreするのか？ なぜGraphQLではなくREST APIなのか？ 移行にあたって検討したこと、決め事 ドキュメントIDをどう扱うか サブコレクションをどう扱うか 配列やマップといったフィールドのタイプをどう扱うか 追記: Mapの配列をどうするか Firebase Authenticationとセキュリティルールで実現しているセキュリティ機能をどうするか では実際にどんなテーブル設計にするのか 次にやること なぜ脱Firestoreするのか？ まず、脱Firestoreする理由は ユースケースとしてFirestoreでは対
最近、一意な識別子について検討することがあったのでその検討メモ。 一意な識別子とは つまり、重複しない、ユニークな識別子（Identifier, 以下id）のこと。ここではRDBのテーブルにおける主キーとして使うことを想定かつ前提としている。したがって、主キーの要件であるユニーク性を持ったidをどうやって生成していくか。 そんなのDBの連番でいいじゃんて話もあるがここではその話はせず、あくまでも一意な識別子をどう生成するかの話に絞る。 選択肢 一番有名だと思われるUUIDを筆頭にいくつかの選択肢がある。 UUID ULID CUID Nano ID 他にもTwitter発のSnowflakeとか今はDeprecatedになってるshortidなどがあるが、キリがないのでここでは上記の4種類だけで簡単に比較した。また、実際にはUUIDはバージョンによってSpecが異なるがここではバージョン4
先月買ったDAHON K3ネタです。 DAHON ダホン K3 14インチ (KAA433) 折りたたみ自転車 3段変速 アルミフレーム ミニベロ 軽量 コンパクト 小径車 通勤 通学 サイクリング (ホワイト×ブラック) [並行輸入品] ノーブランド品 Amazon 今回はDAHON K3としてはド定番のカスタムです。標準タイヤからシュワルベのビッグアップル14インチに変更するというものですね。 シュワルベ BIG APPLE ビッグアップル 14×2.00 ワイヤービード ブラック リフレックス [並行輸入品] SCHWALBE Amazon やるかやらないか悩んでいたものの標準タイヤで1ヶ月ほど過ごしてみて10kmぐらい移動するとやっぱり辛いなってことで交換することにしました。 いわく、乗り心地は大幅に改善し、標準でも思ったより良く走るK3がさらによく走るようになるという噂。交換しな
AWSのAmpify ConsoleでCORSの設定が必要になったんだけど、やり方についてググっても意外とドンピシャな情報がなかったのでメモ。 結論から言うと特段それようの設定があるわけではなくベタにヘッダを指定するだけだった。これはAmplify ConsoleのカスタムヘッダでCORSで必要となる一連の設定をするだけでいい。 この設定はマネージメントコンソールからもできるし、プロジェクトのトップディレクトリ直下にcustomHeaders.ymlというファイルに記述しておくことも可能。 マネージメントコンソールからやる場合はアプリを選択してカスタムヘッダの設定画面を開けばエディタがあるのでそこに直接記述する。記述したものを後からダウンロードすることも可能。 こんな感じの内容をYAML形式で記述する。 customHeaders: - pattern: '*.json' headers:
はじめに コミット前にlint系のチェックをしたいケースってあると思います。特にチーム開発とかの場合、全員がlintをちゃんと実行してほしいとかあるかと。そういったときのためにコミットのタイミングでlint系のコマンドを実行するための仕組みとしてhuskyとlint-stagedを組み合わせたものが定番かと思います。 新しいプロジェクトのリポジトリを作るたびにこの組み合わせのセットアップを行うのですが、毎回ググりながらやるのでいい加減に面倒になって自分用のメモを残しておきます。 huskyとlint-stagedそのものについては大雑把に説明すると、huskyがコミット前に何らかの処理を実行するためのツール、lint-stagedがGitでステージにあるファイルに対してlintを実行するためのツールです。 インストール yarn add husky lint-staged -D lint-
はじめに AWSには認証・認可のサービスとしてAmazon Cognitoというものが存在します。ややこしいのですが、認証のためのコンポーネントがAmazon Cognito user pools(以下、user pool)で認可のためのコンポーネントがAmazon Cognito identity pools (以下、identity pool)です。ちなみにidentity poolのほうはfederated identityと表記されている場合もあります。 そのうち、今回はidentity poolの話です。 identity poolは認証機構は持たず、大雑把にいうと任意のログインプロバイダで認証されたユーザに対してIAMロールが設定されたidを紐付けた上でテンポラリのAWSクレデンシャルを提供するといったサービスです。 この任意のログインプロバイダとしてFacebook、Twit
久しぶりのポエムです。 最近こんなブログがバズっていてそれに関連して思うところもあったので書きます。 別にアンサーブログとかそういうのではなくて、前々からぼんやりと思ってるところがありそれがこのブログ記事によって刺激されたので吐き出すって感じ。 rabspice.hatenablog.com 自分自身も昔こういうことを書いたこともある www.keisuke69.net これを書いたときから2年も経っていて当時と今とでは置かれている環境も変わったので、まず最初に前提として自分の置かれている立場、状況について話をしておこう。 僕はいわゆるソフトウェアエンジニアに近い領域で仕事をしているエンジニアだ。と言ってもポジション的には取締役CTOだったりすることもあり、残念ながら毎日コードだけを書いて過ごせてるわけではない。 取締役とかCTOとか偉そうなポジション名であるものの、シードラウンドのスター
前提 はじめに virtiofsさっそく試す もうちょっとちゃんと計測してみる Named Volumeを試してみる まとめ 追記（超重要） 追記2 前提 特にVSCodeのRemote Containers使ってる人には耳寄りです。別に使ってなくてもMacでDocker Desktop使ってる人ならあてはまります。 あと、このポストはMacといってもM1 MaxなMacBook Proで確認したものです。なので同じMacでもIntel Macとかだと違う結果になるかもしれません。 また、ここで紹介しているものはまだExperimental（試験的）な機能なので不具合や問題を引き起こす可能性があります。なので試す方はその辺は承知の上で試してみてください。 はじめに さて、MacでDocker Desktopというと「遅い」というのがこれまでの常識。自分のように普段VSCodeのRemote
ちょっとそんな話をする機会があったのでついでにまとめておく。技術的な内容というよりはポエムに近いなぐり書きなので甘い部分は多々あると思う。 前提 大前提としてあくまでも僕個人の感覚だし、自分の置かれている状況を踏まえての話なのでフラットな比較評価ではない部分は多々あるし、異論は多いにあると思う。そしてバイアスがかなりかかった意見でもあるとは思っている。 まず、このまとめの前提となる環境は以下のような環境だ。 GraphQLを使ったプロダクトではない フロントエンドとバックエンドはそれぞれ別のエンジニアがいる フロントエンドはReact、TypeScript、Next.jsあたり、バックエンドはPythonでコンテナ。つまりLambdaとかのサーバーレスではない 一言でAWS Amplifyと言っているがこの記事で述べていることの多くはAmplify LibraryおよびAmplify CL
タイトル通りです。 事の経緯はですね、2019年の7月に購入したMacBook Proをずっと使ってたんですが、2021年にM1 MaxなMacBook Proに買い替えたんです。 僕は大体2年に1回くらいのペースでそのときの1番盛り盛りにしたスペックのMacBook Pro（MBP）を買い直すというサイクルで回してます。 当時買ったMBPは初めてのスペースグレイでした。ちなみに新しいMBPもスペースグレイです。 エンジニアと言えばラップトップに好きなステッカーを貼って飾りつけるという固定観念があるので僕もいくつかペタペタ貼ってました。 で、その古いMBPをようやく誰かに売ろうと思い表に貼ってあったステッカーを剥がしたんです。 ステッカーを剥がすにはステッカー剥がしでもいいですが中性洗剤なんかがいいです。よく紹介されてますね。 そして糊が残っても除光液なんかでさって拭いてあげれば綺麗さっぱ
※ 当初、成田空港での検査を「PCR検査」と書いていましたが正確にはPCRが検査ではなく「抗原検査」でした。該当箇所は単に「検査」と修正しました。 はじめに 実は2022年の1月22日から10日ほど仕事でブラジルに行ってました。2年ぶりの海外出張です。 今回は仕事は仕事なんですがJICAの調査ミッションでもあるため公用旅券での渡航です。 というか公用旅券なんていうものの存在を初めて知ったよ。 経路としてはJICAでブラジルに飛ぶ場合の規定ルートとされているカタールのドーハ経由です。これがかなり遠い。片道だいたい30時間くらい。 とはいえ行きは機上のの時間が長いくらいで、それはそれで疲れるもののブラジルはサンパウロに到着してしまえばサクッと入国して市街に行けるわけです。自分の場合、実際にはサンパウロからそのまま飛行機に乗ってベロオリゾンテというところまで行ったのですが。 問題は帰りです。 帰
（Update）このブログは最後の追記だけを見れば事足ります。 Amplify ConsoleでとあるReact、Next.jsベースのアプリケーションをホストしているんだけど、最新のプッシュで動いたデプロイがビルドのフェーズで落ちてしまった。 ログは以下。 2022-01-12T01:20:42.950Z [WARNING]: error @typescript-eslint/[email protected]: The engine "node" is incompatible with this module. Expected version "^12.22.0 || ^14.17.0 || >=16.0.0". Got "12.21.0" 2022-01-12T01:20:42.958Z [WARNING]: error Found incompatible mod
本記事はAWS Startup Community Advent Calendar 2021の20日目です。 ポエム、というかいろんなことを赤裸々に語ろうと思います。が、一回とめどなく書いたらとても文章が長くなったのでかいつまんで書き直しました。もし内容的に興味がある部分があったらTwitterのDMとかそういうので聞いていただければと思います。 はじめに なぜ入社したか 何をしてきたか バックエンドAPIの作り直し 脱EXPO Jestの導入 react-native-background-geolocationへの移行 デザインリニューアル Webアプリケーションの開発 国際化対応 ビルド自動化 モニタリング環境の導入 採用 Analyticsの導入 開発プロセス作り MapBoxの検証 最近着手したこと、やりたいこと、悩み UXとUIの見直し 月次データ更新処理の自動化 研究成果をど
次のページ
このページを最初にブックマークしてみませんか？
『Sweet Escape』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
