Highlight and capture web pages in your favorite browser. Save anything and everything with just one click. Try it with your favorite browser Capture Easily capture pages and metadata to durable files you can read offline. Templates allow you to customize how web pages are saved to your vault.

メドピア社内で定期的に開催しているAWSに関する勉強会を開催しています。本資料はそのうちのECSに関する回のものです。

銀座Rails #35 (https://ginza-rails.connpass.com/event/216491/) AWS Lambdaのコンテナイメージサポートを利用してRailsのコードを動かす方法とそのユースケースについて。

はじめに エンジニアに関する情報量は日本よりも海外（特にアメリカ）の方が圧倒的です。 そのため、英語での情報収集を習慣付けておくとより早く必要な情報に辿り着くことができます。 英語がわからない場合は、ChatGPTに全てコピペして翻訳させましょう！日本語ネイティブの皆さんでも余裕で海外コンテンツを見ることができるでしょう！ 本記事では、濃い情報が集まる場所をまとめました。 日頃の情報収集やキャリアに関する情報まで幅広くまとめたので、エンジニア学生や初学者にとって役に立つ内容かと思います。 ChatGPTと紹介している情報源を連携すれば、英語が苦手だとしても必要な情報に素早く辿り着くことができるでしょう。 本記事の対象読者： 日頃の学習に役立つ情報源を知りたい方 年収やキャリアに関する情報を手に入れたい方 インターンや就活前に情報を仕入れておきたい方 本記事の構成 学習系 ニュース系 キャリ

何かの取り組みを始める時、たいていまずは"過去の経緯"をざっと調べると思う。そうしないと過去に起きた問題を踏んでしまったり再発明をしてしまったりするからである。 皆当たり前にやっているように見えて、この過去の経緯の調べ方には意外とスキルのバラつきがある。自分も常にうまくできているわけではないので、思考整理のために雑に書き出してみる。 たとえば一例として、「Androidの自動テストの方針」を決めようとしているとしよう。背景にある課題は適当に想定してほしい。次のようなステップで過去の経緯を調査していく。 1. 調査期間を決める 調査はダラダラとやってしまいがちなので自分で期限を決める 内容にもよるが、自分は半日~1日に設定することが多い。社外の方とのスケジュール調整が入る場合には1週間くらいかかることもある 例で言うと、自分ならいったん1日で設定してガッと集中して調べてキャッチアップすると思

目次 目次 はじめに 開発生産性の歴史 工業製品のコスト管理 (1950~1970年代) 工業製品とサービス業の収益増加 (1980~2000年代) ITサービスの開発生産性 (2010年代~) 2024年現在の開発生産性 開発生産性の経営視点での構造化 B-1 プロセス改善 B-2 ソフトウェア化 B-3 技術的負債 B-4 開発者体験 2024年時点での開発生産性の現在地 まとめ 【採用】開発生産性の歴史を一緒に作りませんか？ 参考文献 はじめに 食べログ開発本部、品質管理室で室長をしている荻野です。近年ITサービス業界では、ビジネスを取り巻く変化に迅速に対応するため、アジャイル開発やDevOpsなどの開発プラクティスが普及し、開発生産性に関する議論が活発化しています1。 このブログ記事では、開発生産性の歴史をアジャイル開発の源流である日本の製造業まで遡って振り返った上で、開発生産性C

マナリンクCTOの名人です。 2022年3月頃から社内で実施している「10分勉強会」という取り組みと、実際の内容についてざっくり紹介していきます。 10分勉強会の目的 10分勉強会の目的は以下のとおりです。 すぐに実務で使えるかは分からないけど、知っておいて損はないことを先に学ぶ機会を作る 実務にて学んだことで、他のメンバーにも知ってほしいと思ったことを共有する機会を作る 前者については、たとえば「新しいバージョンのPHPについて調べてみた」といった、すぐには役立たないがいずれ使うであろう知識が挙げられます。後者については、たとえば「ある施策の実装をきっかけにCSSの◯◯プロパティについて学びなおした」といった例が挙げられます。 （ちょっとあまり上手な図解ではない気がしますが）学習機会の必要性について図解してみました。 エンジニアがある施策Aを実装するには、最低限これさえ分かっていたら実装

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

「【SmartHR/カケハシ/リクルート】複雑化する開発体制におけるエンジニアの社内巻き込み術 ‐プロダクト成長をリードするエンジニアたちの試行錯誤‐」は、成長プロダクトの開発をリードするエンジニアたちの試行錯誤に触れ、社内巻き込み術や改善のステップなどのノウハウを紹介するイベントです。ここで株式会社SmartHRの大谷氏が登壇。チーム人数の増加によって生まれた課題と、その課題にどう対処したかを紹介します。 みなさんはこういった経験をしたことがありますか？ 大谷洋生氏：では僕の発表を始めようかなと思います。「エンジニア主導の仕様検討：はじめの一歩を踏み出す」というタイトルで、話をさせていただきたいと思います。よろしくお願いします。 まず自己紹介ですね。SmartHRから来ました。エンジニアをしています。大谷と言います。ふだんはRailsを書いたりReactを書いたり、あとはFlutterを

マネジメントの想定問題集があれば、疑似体験により引き出しが増えて成長が早まるのではないかと思ったことがあるので雑にかいておきたい。 マネジメントは昔からたくさんの関連書籍も出ていて、ある程度型をもって技術として磨いていけるものではある。 一方で、「やらないことを決める」「思い切って委譲する」といったいわゆる"セオリー"的なことは理解はしつつも、そういう小綺麗な話ばかりではないのはマネジメント経験者なら共感できるのではなかろうか。 社内での役割や経営・メンバーとの関係性にもよるけれども、たとえば次のような泥くさい想定問題があったらどう答えるか考えてみると面白いかもしれない。 1on1 でメンバーから「事業 / プロダクトの方針がわからない」と言われました このまま放置すると離職リスクになりうるかもしれません マネージャーとしてどう動きますか？ 事業計画上、4週間後にはリリースしたい機能があり

SREチームの長田です。 皆さんは操作するAWSアカウントを取り違えたことはありますか？ 私はあります。 カヤックのSREは複数のプロダクトを担当することも多く、 ひとつのプロダクトでも環境(本番、ステージング、開発、etc.)ごとにAWSアカウントを分ける場合があり、 扱わなければならないAWSアカウントが多くなる傾向にあります *1。 今回はうっかり別のアカウントのリソースを削除してしまったーといったオペレーションミスを減らすために個人的に行っている、 「気をつける」以外の対策を紹介します。 間違いに気づくための対策 対象のアカウントが操作の対象として正しいかどうかは、結局は操作している本人にしか分かりません *2。 そのため、「アカウント取り違え自体をなくす」のではなく、 「アカウントを取り違えていることに気づきやすくする」ための対策をしています。 AWSコンソール用の対策 AWSコ

週末にちょっとしたウェブサイトというかリンク集（？）を作った。 今回は生成AIツールをフル活用していつもより効率よく作業ができた。 生成AIツールについては日々、新しいものがヤバイすごいと宣伝されているけど、実際にどう使っているのかという情報が少ないと感じている。 なので具体的な使い方を書いてみることにした。 作ったもの 開発の概要 最終的なアーキテクチャ UI開発に生成AIツールを使う 初期デザインの参考元 デザインツールの選定と比較 Next.jsの利用 Cursorを活用した開発 データ整形にLLMを使う スクレイピング Amazonの商品データ取得 LLMの選定 動的なコードと静的なコードの使い分け TypeScriptを使わない範囲を定めた 静的サイト生成（SSG）の採用 柔軟なデータベース設計 まとめ 作ったもの 『最も重要な「最も重要なマンガ10選」10選』は「最も重要なマン

2024年10月31日に株式会社ビッグツリーテクノロジー＆コンサルティング様のイベントで登壇した際の資料です。 発売から3年たった、「AWSコンテナ[本格]入門ハンズオン」を今ならどう作り変えるだろう？という観点で話をしています。

IPoEの普及によって、日本の家庭のインターネット回線は 確実にIPv6化が進行している 家庭用のインターネット常時接続サービスでIPoE（IP over Ethernet）が簡単に利用できるようになった。IPoEでは、簡単に言えば、自宅が1つのサブネットワークになる。そもそもIP over Ethernetとはイーサネットを流れているIPと同じということである。 実際、ルーターにはIPv6グローバルネットワークアドレスが割り当てられ、そこから自動割り当てられたWindowsマシンのIPv6アドレスもインターネットでそのまま通用するグローバルアドレスである。 そういうわけで、あらためてIPv6とまともに付き合う必要が出てきた。今回は、IPv6の基本の「キ」としてざっくりとした解説をする。 まずは基本となるIPv6アドレスについて まずはIPv6アドレスについてだ。IPv6アドレスは128b

AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book

AWSのワークショップをあさってました。 実践力を鍛えるBootcamp - クラウドネイティブ編 - いいですね～　実践力、鍛えましょう！ で環境構築をするぞーと見ていると。。。 VS Code ServerをEC2で起動するCloudFormationテンプレートが用意されている！！！ さりげない優しさ すてきすぎ やってみました。 手順 上記ページの「Launch」リンクをクリックします マネジメントコンソールのログインが必要でしたら、ログインしてください スタックのクイック作成画面が表示されます。必要でしたらパラメータなどを修正してください デフォルト値は以下のとおりです スタックのデプロイが始まりますので完了するまで待ちます 出力タブに「PasswordURL」と「URL」が表示されますので、まずは「PasswordURL」のリンクをクリックします Secrets Manager

前編：近代ラーメン史上最も重要な店舗6選 ラーメン二郎（東京）1968年創業。豚骨や豚肉、背脂を煮込んだ脂肪分と旨味が溢れるジャンクなスープ、一般的なラーメン店よりも多い麺量に野菜が盛られたボリューミーなラーメンが特徴。学生街（慶應義塾大学三田キャンパス近く）という立地も相まって、一躍人気店に。1990年代になってからは「直系」と呼ばれる暖簾分け店が増え、2000年以降はラーメンの特徴や注文システム等を模倣した「インスパイア店」が急増。全国規模の知名度を得るに至る。 吉村家（神奈川）1974年創業。白濁した豚骨スープに東京の醤油を合わせたラーメンを考案し、人気店となる。弟子の独立店も1990年代から神奈川を中心に増加し、2000年以降は、模倣したラーメンをセントラルキッチンでチェーン展開する企業も参入。ラーメンの一大ジャンル「家系」として認知される。 ちなみに創業者の吉村実氏は、開業前、東

前職を辞めるタイミングで、それまで個人事業主として細々と引き受けていた仕事(技術広報のメンタリングや顧問業)をまとめて会社を作ろうとしたらタイトルの通りだったよという話をします。 freee会社設立はいいぞ 基本的にはこれに登録して、この通りにやっていくと会社ができる。 (厳密には登記後に登記簿と印鑑証明関連で所轄の税務署へ行く必要はある) このfreee会社設立は本当にすごくて、全て無料で使えてfreeeに詳しい税理士を紹介までしてくれる。 流れとしては、サービスに登録するとすぐに電話がかかってきて面談日の設定がされる。初回の面談では、会社を作る背景やなにをしたいかをユーザー(自分)から説明、freeeの方から今後の手順を説明され、不明点に答えてくれるという超手厚いもの。 基本的にはサイトにあるものの情報を集めたり決めたりして、手順どおりにポチポチ進めていくと会社が出来る。不思議だ。すご

チャットコミュニケーションむずかしい。全然そんなつもりで書いてないのに受け手の解釈が乗っかって伝わったりする。 たとえば純粋に質問しているだけなのに責められているように感じる人もいるし、感謝を伝えたつもりが煽りや嫌味と捉えられることもありうる。 そもそもチャット以前の関係性の問題として対処すべきこともあるし、受け手の人となりや状況を完全に理解することもできないのであまり気にしすぎても仕方ない。一方で、自分の経験上解釈ズレが起きやすい表現は明確にあって、自分はそれらを"禁止"するマイルールを作っている。誰でもできるチャットコミュニケーションの工夫の一つとして雑にまとめておく。 あー / えっと 「あー (そうじゃなくて)」とか「えっと (理解できないみたいだからどう言おうかな)」みたいな感じで相手に非があるという印象で伝わることもある じっくり考えられるチャットでこれらを書く必要もないので使

もし世界が消滅して Visual Studio Code の設定が失われてしまった時に、この記事を見ればまた VSCode のカスタマイズが復元できる。 ここでは Visual Studio Code の見た目に影響するものについてのみ 取り上げる。 スクリーンショット Editor Terminal Zen Mode 環境 Visual Studio Code バージョン: 1.94.2 (user setup) コミット: 384ff7382de624fb94dbaf6da11977bba1ecd427 日付: 2024-10-09T16:08:44.566Z Electron: 30.5.1 ElectronBuildId: 10262041 Chromium: 124.0.6367.243 Node.js: 20.16.0 V8: 12.4.254.20-electron.0 OS