Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
お知らせ: 2022/9/1 CS50 を活用した非営利/協賛企業による「コロナ学生支援」プロジェクトを実施中 ▼ 学生の方へ:CS50 の学習(履修証明書の取得)を一緒に取り組むプロジェクト CS50日本語版の翻訳コントリビューターである CODEGYM が主催する、非営利/無償のプロジェクト「CODEGYM Academy (外部リンク)」は、昨年に続き2022年度(春/秋)も、キャリア選択を控えた学生に対し、以下の企業の協賛により無償で17週間のプログラミング教育カリキュラムを提供します。 CODEGYM Academy 協賛企業(2022年) https://codegym.jp/academy/ 今年度のエントリーは締め切りました — ようこそ! このページは、ハーバード大学 CS50 の日本語版翻訳プロジェクトのページです。当サイトのドメインに掲載されているコンテンツは、Cre
こんにちは。クックパッド デザイン戦略本部長の宇野です。 いきなりですが「ユーザーファースト」って良い言葉ですよね。サービスのあり方の基本であり、モノづくりをしていてそれを無視したいという人はいないはず。 しかし僕はこのユーザーファーストという言葉をあまり使わず、使う際は慎重に取り扱うようにしています。この言葉の概念はとても難しいと考えているからです。 「ユーザー」って誰のこと?目の前にいるユーザーの話をそのまま取り入れれば必ず良いものが作れるの? 答えは明確にNoです。 当然ですが無視するべきという話ではありません。ただ、向き合ってるユーザーがどんな人なのか、その人が本当に欲しているものは何なのかを徹底的に考え抜く必要があります。 お問い合わせをしてきている人はだれ? ユーザーからのご意見やお問い合わせ、アプリストアのレビューはとてもありがたいですよね。そこから新たな改善案をもらったり、
誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。 自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。 相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。 「相談する必要がないと考えている」 この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションポーカーなどで権限委譲を見直したりしてもいいかもしれない。 目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するな
iCARE Dev Meetup 20 で発表した資料です #icare_meetup p.7,8,61 https://graphql.org/ p.18 https://twitter.com/a_suenami/status/1379270185207484417 p.33 [SQLQL - Qiita](https://qiita.com/yancya/items/4b7979d83cbf6af9b819) p.33 https://twitter.com/onk/status/912491093127598080 p.35 [【エンジニアブログ】ダイニーのエンジニアリング3カ条|dinii(ダイニー)公式|note](https://note.com/dinii/n/n9be778bd7da3) p.36 [Smart UI パターンが再評価される世界 - id:onk のはてな
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
はじめに CloudFrontへアクセスしてきた日次のリクエスト数やデータ転送量の合計値を求めることがあったため、 備忘録として残します。 必要な設定 AWS CLIの設定 CloudFrontがあるAWSアカウントでIAMユーザ + アクセスキーを取得しておく CloudFrontのUsageで使用量を確認できるが、、 CloudFrontのマネージメントコンソールのUsageで個別のDistribution毎に特定期間の使用量を指定すると確認できます。 が、細かく時間を絞っての確認は出来ない仕様になっています。 そういった場合は、CloudWatchのAWS CLIのget-metric-statisticsを使って集計することが可能です。 リクエスト数合計の取得 2020/8/17 15:00〜2020/8/18 15:00までのリクエスト数の合計を取得してみましょう。 dimens
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは? 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか? 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしま
視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ?」「どう見極めればええのん?」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
イントロダクション 開催に至る経緯 人材育成における「70:20:10の法則」 振り返りから学ぶとはどういうことか 敢えて敷居を高くした発表の場を提供 リモートワークでの情報共有やコミュニケーションに関する危機意識 準備段階で行なったこと 社内テックカンファレンス盛り上げるためにやった7つの工夫 1.原則全員参加で公式感の醸成 2.低ハードル、低負担 3.発表用フレームワークの提供 4.聴き手の本気度をあげる複数トラック制 5.👏 と顔出しによる虚無感の回避 6.副音声としてのSlack活用 7.全セッションに司会付き 当日の様子 各発表の雰囲気 当日の発表タイトル 結果と振り返り アンケート結果 自由回答の感想もいくつかご紹介します 実施してみてわかったこと 社内ならではの良さの発見 今後について、学びの仕組み化 イントロダクション こんにちはエンジニアリングマネージャーの普川泰如(@
macOSにインストールしたMySQLWorkbench 8.0.23が起動しない。 コマンドラインで実行すると以下のエラーメッセージが出力されていた。 ❯ /Applications/MySQLWorkbench.app/Contents/MacOS/MySQLWorkbench Fatal Python error: initfsencoding: unable to load the file system codec, sys.path = ['/Applications/MySQLWorkbench.app/Contents/Resources/libraries', '/Library/Frameworks/Python.framework/Versions/3.7/lib/python37.zip', '/Library/Frameworks/Python.framework
Amazon Web Services ブログ AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス この記事では、AWS Cloud Development Kit (AWS CDK) を中心とした、大規模なチームで複雑なクラウドアプリケーションの開発を組織化するための戦略について説明します。AWS CDK では、開発者や管理者は、TypeScript、Python、Java、C#などの使い慣れたプログラミング言語を使ってクラウドアプリケーションを定義することができます。アプリケーションは、Stage、Stack、Constructに整理されており、ランタイムロジック (AWS Lambda コードやコンテナ化されたサービスなど) と、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Relational D
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
電気通信事業法 第九条の規定に違反して電気通信事業を営んだ者は、三年以下の懲役若しくは二百万円以下の罰金に処し、又はこれを併科する。 実はこの法律のことは知っていたので、特定の人だけが見られるチャットを作るのを今まで避けてきました。届出は面倒そうだと思っていましたが、実行してみると簡単だったので記事にまとめました。 総務省による解説 電気通信事業参入マニュアル[追補版] を基準に解説します。 他人の通信を媒介する 電気通信設備を用いて「他人の通信を媒介する」とは、他人の依頼を受けて、情報をその内容を変更することなく、伝送・交換し、隔地者間の通信を取次、又は仲介してそれを完成させることをいう 『他人の通信を媒介する』場合、クローズド・チャットと見なされ、電気通信事業の届出が必要となることがあります。なお『オープン・チャットは電子掲示板と考えらえるため届出は不要』らしいです。そういうものとして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く