Amazon Web Services ブログ AWS App Runner プライベートサービスの発表 この記事は Announcing AWS App Runner Private Services (記事公開日 : 2022 年 11 月 1 日) の翻訳です。 今年の 2 月、私たちは App Runner の VPC サポートの一般提供を発表しました。この機能により、お客様の App Runner サービスは Amazon Virtual Private Cloud (Amazon VPC) でホストされているデータベースや他のアプリケーションと通信できるようになりました。そして、本日 App Runner プライベートサービスのリリースを発表します。これにより、お客様は Amazon VPC 内で App Runner サービスにプライベートアクセス可能となり、アプリケーション

説明のために手順を確認したので、その覚書。 作業環境にリポジトリを用意する github.com $ git clone git@github.com:isucon/isucon12-qualify.git Dockerをインストールする www.docker.com 値上げが最近話題になりましたが、個人利用は無料です。 www.docker.com 次回はRancher Desktopを試してみます。 rancherdesktop.io docker-compose.ymlを書き換える 一箇所だけ書き換えないと、起動しません。 Docker Hubから「mysql/mysql-server:8.0.29」のイメージが無くなっていて、MySQLが起動できません。8.0.30以降のバージョンを指定しましょう(無くなった理由は探せませんでした...)。 2022/11/06追記 mysql-s

本稿は、Webアプリのプロトタイプを作るための道具として RedwoodJS を紹介する記事です。 前説：プロトタイピングにおける技術選定 シンプルなWebアプリのプロトタイプを作るとき、みなさんはどのような技術選定を行うでしょうか。 プロトタイプと言えど UI の検証もある程度は含んでいる場合がほとんどなので、筆者としては UI の構築には React を利用したい[1]ところです。テンプレートエンジンでは著しく開発効率が落ちるので、フルスタックフレームワークとしての Rails や Django はこの時点で選べないことになります。 しかし、React を選んだとしても大半のアプリケーションでは永続層が必要ですし、フロントエンドで計算させたくないロジックも多々あります。バックエンドを別で作る場合に直面するのは、クライアント側とのAPIスキーマの整合性をどう取るかという問題です。できれば

soudai.hatenablog.com この記事を読んで、新卒のころに同僚から掲題のようなことを言われたのを思い出した*1。そーだいさんの記事を読んだ自分の理解をおおまかにまとめると「自己の能力に自覚的になった上で、卑下するのはやめよう」という被評価者としてのスタンスの話だと思う。 同僚から言われた話も似ているけど、どう自己の能力に自覚的になるかという意味でやや違う。具体的には以下のような内容だった。 masawadaは相対感の勘が弱いので圧倒的に自己評価が低い もっと周り(同期、同じグレード*2のエンジニア、チームのエンジニア)を見て自分がどういう位置にいるのか知るべき 自己評価が不当に低かったり不当に高いということは自分の立ち位置が見えていないので不健全 元の記事では自己の能力に自覚的になれている前提があるように感じる。でも、当然みんながそうではないとも思う。自分に自信がなかったり

クライアント先の社内ポエムだけど必要になることがあったので転記した。 @nekoya さんにお願いしたらそちらも公開してくれた。:圧倒的感謝: @nekoya さんの話がとても良かったので僕もポエムを書いてみる。 zenn.dev 僕もその昔はもちろん駆け出しのエンジニアで自信が無くて自分を低く見積もったり、ある程度自信があっても 謙虚であることが美徳 と思って自分を敢えて卑下するなんてことをよくやっていた。 脳ある鷹は爪を隠す、なんていうけど確かに周囲に低能力だと思われていたほうが便利なシーンもあるにはある。 しかし少なくとも社会で働く上で 自分の能力を適切に評価する ことは自分にとっても会社にとっても重要なことだ。 その前提の上で、自分を過小に評価することは、あなたの仕事の成果に対して高評価し、認めてくれている人たちにとっては裏切り行為と言える。 例えばとても良い仕事をしたのにも関わら

github.blog という記事を今日みて、 echo "::set-output name=hoge::fuga" みたいなことをやってたのがdeprecatedになると知った。以下のドキュメントを参考に置換すればOKとのことだったので、せっかくなのでsedでやってみた。 https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter find .github/workflows -type f | xargs sed -i '' -e 's/echo "::set-output name=\(.*\)::\(.*\)"/echo "\1=\2" >> $GITHUB_OUTPUT/g' ちなみにはじめは sed -i

October 13, 2022 - The PostgreSQL Global Development Group today announced the release of PostgreSQL 15, the latest version of the world’s most advanced open source database. PostgreSQL 15 builds on the performance improvements of recent releases with noticeable gains for managing workloads in both local and distributed deployments, including improved sorting. This release improves the developer e

GitHub Actions: Deprecating save-state and set-output commands actions October 11, 2022 24-July-2023 Update: Our telemetry shows significant usage of these commands so we have decided to postpone the removal. To learn more, visit the latest changelog post. To avoid untrusted logged data to use save-stateand set-output workflow commands without the intention of the workflow author we have introduce

エンジニアとして一定以上大きい仕事をする際には、他人を巻き込んで仕事をする力が必要になってきます。 新しいフレームワークや言語の採用、自動テストの導入、インフラ基盤の刷新、スクラムの導入など、一定以上の大きさの取り組みでは折に触れて他人の巻き込みが必要になってきます。 そんな巻き込み力で苦労されている方も多いのではないでしょうか。かくいう私自身も現在進行形で苦労しています。 この記事ではそんな悩みを少しでも解決できればと思い、個人的に巻き込み力の決定版教科書だと思っている「Fearless Change」という書籍を紹介します。 TL;DR 「巻き込み」の課題感 巻き込み力の決定版教科書「Fearless Change」 どんな本？ どんな人におすすめ？ この本のどこが優れているの？ 本の内容をどうやって活かすか 組織の文化に合わせてローカライズする 多くのことを同時にやろうとしない まと

と言えば、zennで一番人気のあるの記事です。 Reactの堅牢な開発基盤を築きたいときに非常に参考になります。 @Meijin_gardenさんのこの記事が出たのは、ほぼ一年前。 今日までの間に、React v18.0のリリースというビッグなニュースもありました。 なので、2022年秋となると、一年前とは少し様子も変わってくるかもしれません。 「概ね賛成だけど、ここはこうしてみたい気もする」という部分もあります。 そんなわけで今回は、2022年秋バージョンのbulletproof-reactを一緒に考えていきたいです。 Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件の内容を前提に書いていきますので、まだ読まれていない方は、先に本家の記事を読まれると良さそうです。 改めて考えるbulletproof-reactの良さ ディレクトリ構成 Rou

あーはいはい、React Hook Formね、知ってる知ってる（知らない） そんな状態なので素振りしておく。 React Hook Form https://react-hook-form.com/get-started React Hook Form の重要なコンセプトの一つは、非制御コンポーネント (Uncontrolled Components) をフックに登録（register) し、フォームフィールドの値を検証と収集できるようにすることです。 DOMベースに値を持つコンポーネントを主体に、いい感じにフォーム管理ができるものという理解をした。 自分がReactを書くときは今のところ制御コンポーネントを使うケースが多いので、React Hook Form 向けに脳をスイッチしないといけなさそう。 useForm と register 特に重要なのは useForm と regist

スターフェスティバル株式会社 の バックエンドエンジニアの @ikkitang です。 上記の自己紹介にもありますが、私はプライベートで日本PostgreSQLユーザー会の理事をやっていて、その活動の一貫として先日の 2022-10-01（土)に行われたOpen Source Conference 2022 Online/Hiroshimaで最新バージョンのPostgreSQL15の最新機能について発表してきました。 スライドは公開しておりますので、以下を見て頂く事で全てを完全に理解していただけるかもしれませんが、解説しながらまとめたいと思います。 PostgreSQLのリリースサイクル PostgreSQLはPostgreSQL開発コミュニティというユーザーグループ主導で開発されています。 毎年9~10月にメジャーバージョンをリリースしておりまして、今年はPostgreSQL15のリリー

1年 CircleCI に入って来月で1年になる。あっというまだなぁ。 色々と面白いことが転がってるので全然飽きないし、スキルが高ければ高いほどその面白いものをもっと拾えるので、どんどんスキルアップしていきたい気持ち。 仕事のやり方を忘れようとしてる その一方で、いま僕は仕事のやり方を忘れようとしてる。これまでずっとやってきた自分の仕事のやり方をいちど忘れてみようと思っているのだ。もっと肩の力を抜いて、リラックスした気持ちで仕事をしてみたい。がんばらないように。 のだけど、これが思ってたより難しい。 つい、がんばってしまう。がんばる方がラクだと思ってしまう。そっちの方がラクならがんばったらいいやん。って思うかもしれないけど。せっかくなので違う働き方に挑戦してみたい。どんな景色が見えるんだろう？ということに興味がある。 過程より結果 今のチームでは、いちばん大切なこととして「プライベートを第

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。 LINEヤフー株式会社のコーポレートサイトはこちらです。 当ページに記載されている情報は、2023年9月30日時点の情報です。 このたび、LINEアプリのトークなどにおいて、ユーザーやLINE公式アカウントがURLを送信・投稿した際に、異なるページのプレビュー情報を誤表示してしまう不具合（以下、本事象）が判明いたしました。 本事象の概要について、以下のとおりご報告いたしますとともに、ユーザーおよび関係者の皆さまには多大なるご迷惑とご心配をおかけしますことを、深くお詫び申し上げます。なお、本事象に対しては、すでに暫定的な対応を実施しており、誤表示が新規に発生することはありません。 1. 発生した事象 当社が提供するLINEアプリのトークなどにおいて、ユーザーやLINE公式アカウントがURLを送信・投稿するとプレビ

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 作者:James StanierオライリージャパンAmazon 普通に良い本だなー。あんまり『エンジニアリング』というタイトルにこだわる必要も無くて（シチュエーションを説明する用語が、エンジニアリング・マネージャーに合わせてある、というだけなので）、専任のマネージャー職に初めて挑戦する時にざっと読んでおくと、心構えができる1冊ですね。 すべてを完璧にこなしている人はきっといないと思うけど、上手く立ち回っているマネージャーを観察していると、「あー確かにやっているー」という要素がたくさん有って、拾い読みしておいて何か一つだけでも「これだけ気をつけてみるか」と思えれば買った価値も十分に有ると言えるでしょう。 特に2章「まず自分を管理しよう」の章に紹介されている「カレンダー」「ToDoリスト」「メール」のあたりは、自

うちの会社は期首が9月で、今期で昇進した。世間では退職エントリーとか入社エントリーが多いから、自分は昇進エントリーを書く。（2回目） なお、1回目はこちら。3年前ですね。 patorash.hatenablog.com 課長に昇進した うちの会社ではキャリアとしてマネジメント職と専門職がある。前期までは専門職だったが、今期からはマネジメント職になる。マネジメント職になった経緯は、まぁ正直なところ横滑り的な感じではある。昨年、このポジションにいたカズさんこと id:tech-kazuhisa が退職したことで、傍から見ていた感じではあるが、チームが一気に硬直化してしまったように思えた。カズさんの存在の大きさがよくわかった1年だと感じた。 まぁそんなこんなで日々の雑談タイムや読書会などで彼らの話を聞いていると、色んな不安や不満の話が出てきたりするのだけれど、当時の自分は、違うチームのリーダーだ

プロダクトの非機能的な改善をビジネスの中でどのように進めるかは、多くのチームが頭を悩ませる課題であると思います。本記事では私が最近考えていることをまとめてみようと思います。主に自社プロダクトの継続開発を想定した議論をします。 前提 まず非機能改善について議論する上で、重要な前提がふたつあると思っています。 ひとつは、我々は常に共通の目標を持っているということです。プロダクトのミッションや期の目標のことです。ビジネスサイドの人もエンジニアも、そうした目標を達成するためにそこにいることに違いはありません。機能開発も非機能的な改善も、見ている時間軸が多少違うことはあれど、この目標を達成するための手段です。それらが一見対立するように見えるのは影響を与える指標が違うからです。 もうひとつは、非機能改善に「やらない」という選択肢はないということです。システムにはデフォルトで滅びる方向に力が加わっていま

７月にスタフェスに入社したインフラエンジニアの山﨑(koonagi)です。 中途入社して一ヶ月が経ったので志望動機や入社前後のギャップについてお伝えできればと思います。 スタフェスを選んだ理由 大きく分けて以下の2点に魅力的感じて、スタフェスを選びました。 ① 挑戦できる環境であること ② リモートでもコミュニケーションが円滑であること ① 挑戦できる環境であること スカウトメールを頂いて初めてスタフェスを知ったのですが、書いてある内容からワクワクが止まりませんでした。 インフラだけでなく、データ基盤側についてもやれることが沢山あり、ここなら挑戦できると感じました。 スカウト送って頂いたインフラ、データ基盤チームのリードのytakeさんとカジュアル面談をした際に、スキル、仕事への熱量の高さだけでなく、人柄も良く一緒に仕事をしたいと思いました。 一緒に仕事をしてみたい強いエンジニアがいて、更

開封 スッキリした色合いのボックスが届きました。 中に入っていたものです。取説もありました。 マイク本体は縦約8cm、直径約2cmととてもコンパクト。 マイク集音部。 集音部の反対側にオーディオケーブルジャックがあります。 オーディオケーブルは2種類。蛇腹のない方の長さは約40cmでスマホ用です。 スマホ用ケーブルの片方の端子は、黒い線が3本ある4極プラグです。 本体に挿すとこんな感じ。 ショックマウントは2つ付属していました。 マイクの装着方法は本体をはめ込むだけ。 ネジ穴の口径は1/4。 ウインドマフも付属しています。 本体に付けたところ。当たり前ですがピッタリです。 スペック