サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが
ここのところ雑にWebサービスをリリースする機会が減って最近はFlutterでネイティブアプリばかり書いてるのでWebの最新に追いつけてない。 最近の流行りのWebサービス開発について自分の必要そうな範囲でちょっと調べてみる。 自分の場合、フロントエンドはTypeScript+(Vue or Nuxt)でやって、サーバーサイドはRailsで書いちゃうことがまだ多い。 これでもなんとかなるけど、もうどうせならJSで一気通貫でフロントエンドとサーバーサイドを書ければ楽なのにと思いつつある。 パッと思いつくのはTypeScriptでフロントエンドをNext,Nuxtあたりでやって、バックエンドAPIをexpressとかサーバーレスAPIを適当に書くとかだけど、今だともっと良い方法ありそう。 本当はDartでサーバーサイド、FlutterでwebまでいければDart統一時代になって願ったり叶ったり
この記事はSmartHR Advent Calendar 2020 11日目の記事です。 僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。 このエントリでは、そのコーナーで共有した内容をひとつ紹介します。 APIに制限をかける方法について APIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。 じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に
この記事は一休.com Advent Calendar 2023 8日目の記事です。 2023-09-25に入社して2か月半が経ったので、既存のWebサービスの開発にソフトウェアエンジニアとして参加するにあたって役立ったことを書いておく。 『Webサービスのソフトウェアエンジニアとしての転職活動で役立ったこと』の続編といえるかもしれない。 前提 観点 どのようなサービスかを調べる どのようにデータを保持するかを調べる どのようなコードかを調べる 「未知の未知」をできるだけ早く減らす チームの開発体制に興味を持つ 所感 前提 レストラン予約のサービスの開発に参加した 歴史が長い（2006〜） Webアプリケーションを開発する 技術スタックは転職前後で完全に変わった 前: Rails, PHP, Nuxt, MySQLなど7年 後: Rust, Next.js, Python, Microso
TypeScriptでWebサービス開発（Apollo Server/Prisma/Next.js etc...)
最近開発しているBtoB SaaSサービスの技術スタックを、RailsからNode.jsに移行した。 これにより、フロントエンドもバックエンドも全てをTypeScriptで統一することができた。 特にNode.jsのWebバックエンドの構成について、まだまだ世の中に知見が少ない気がしているので記事にしておく。 Webバックエンド - Node.js(TypeScript) Nexus/Apollo Server (Webサーバー) GraphQLサーバーとして、Apollo ServerのコードファーストなアプローチでのラッパーであるNexusを使っている。 Railsからの移行を決断できたのも、Apollo ServerとPrismaにより、外部との通信が型付きで、かつ開発体験よく書けるようになたから、というのが大きくある。 数年前の段階だと、素のexpressを使ってWebサーバーを立
【感想】『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』：Lambdaで本格サービス開発まで - Rのつく財団入り口
サーバーレスアプリケーション開発ガイド Lambda関数を用いたサーバーレス開発をもっと知っておこうと思って読んだ本の感想です。2018年4月刊行、サーバーレスの主要サービス解説にコードはPython、のみならずフロントはVue.jsを使った本格開発まで、実践的な内容が詰まった本です。 作者は現Amazon Web Services Japan所属のKeisuke69こと西谷圭介さん。Twitterでもよくお見掛けします。(@Keisuke69) サーバーレスアプリケーション開発ガイド Chapter1 サーバーレスアプリケーションの概要 1-1 サーバーレスアプリケーションとは 1-2 ユースケースとアーキテクチャパターン 1-3 サーバーレスアプリケーションのライフサイクル管理 Chapter2 Amazon Web Services（AWS）利用の準備 Chapter3 インフラを自
ドワンゴ教育事業Webフロントエンドチームの berlysia です*1。 はじめに この記事では、日本語の縦書きHTMLにおいて、「ある1文字が縦組みのなかで違和感なく縦書きとして表示される」とはどのように成り立っているのか、意図しない表記になりやすい文字とその理由について紹介します。 最後まで読むと、縦書き時の文字の縦横に関する問題をたちどころに分解できるようになるはずです。とりあえずフォントのせいだろうかと疑う日々には、これでおさらばしましょう*2。 はじめに N予備校における日本語縦書きHTML CSS の関連仕様 日本語の一般的な縦書きに設定する うまくいかないことが起こりやすい文字たち うまくいかない文字がうまくいかない理由を理解する 縦書きを考慮した文字の周りの方向の定義 CSS における縦書きでの文字の縦横 upright typesetting sideways type
はじめに ドワンゴ教育事業 Web フロントエンドチームの berlysia です。 ドワンゴ教育事業が提供するオンライン学習サービス『N予備校』は、この 4 月でリリース 6 周年を迎えました。N 予備校の Web フロントエンドはリリース以来、全面的な書き換えを行い、今も続けています。 この記事では書き換えに伴う N 予備校の Web フロントエンド実装の変遷を説明し、これら書き換えの経験やWebフロントエンドという領域の性質を踏まえて、すべてを書き換え続ける選択をしていることを述べます。 この記事は berlysia が他社様イベント*1にて発表させていただいた話題を元に再構成しています。 speakerdeck.com ※JSConf JP 2021 で発表させていただいた事例とは異なるコードを対象にしています。 はじめに 実装の 5 つの世代 v1 v2 v3 v3(TypeSc
サービス開発における暗黙知を無くす「完全に理解した会」｜cluster - メタバースプラットフォーム
Cluster Tech Blogははてなブログへお引越ししました 引き続きそちらで記事を発信していきますので、ぜひご覧ください！
【ツイッターで毎週トレンド入りするサービス開発者が教える】再現性を持って「バズ」るサービスを作る方法 - AppBrew Tech Blog
こんにちは。れとるときゃりー(@retoruto_carry)と申します。 AppbrewではPdM・デザイナー・フロントエンドエンジニアをやっています。 プライベートでは、個人開発でみんなのボタンメーカーというサービスを運営したりしています。 ほぼ毎週ツイッターのトレンドに乗るような、所謂「バズ系」のWebサービスで、月に50万人くらいに利用してもらっています。 ツイッターをやっている方は、なんとなく見たことある気がする人も多いのではないでしょうか？ みんなのボタンメーカー 今回は、その知見を活用し、お仕事で「LIPSショッピング」というコスメの買い物ができるサービスのバズキャンペーンの企画・デザイン・実装を行いました。 コスメクーポンガチャ ちょうどいいので、それを題材にして、再現性をもって「バズ」るサービスを作る方法について話していこうと思います。 キャンペーンはかなり好評で、ツイッ
このドワンゴ教育サービス開発者ブログを開設してから2年が経ちました。 特に2021年3月からおよそ1年の間、技術ブログの運用体制を整え、定期的に記事を投稿してきました。 この記事では、技術ブログ運用の背景と現在の運用体制、成果と課題についてまとめます。 背景：教育事業の成長のために 運用：編集部体制の構築 執筆フロー 執筆者のアサインとテーマの決定 記事構成・目次の作成 初稿の作成 完成稿の作成 社内公開と公開日の調整 公開 成果 採用での成果 副次的な効果 課題と今後の展望 We are hiring! 背景：教育事業の成長のために 私達は教育を生業とすることもあり、学習や知見の共有は大事な業務のひとつです。 そのような活動の場のひとつとして技術ブログを開設していましたが、有志の手によって不定期に更新される程度で、効果的に活用できていませんでした。 そのような中で、さらなる事業成長のため
となっています。 構成図 クラスタを構成するものを図にすると以下のようになります。 この中の一部コンポーネントは次節以降で登場します。 Kubernetes基盤 クラスタの基盤部分についてどのような構成になっているのか説明します。 kubeadm クラスタの構築自体については kubeadm を利用しています。 kubeadm を利用したクラスタの構築方法については公式のドキュメントが参考になります。 Static Pod と systemd kubeadm でデプロイすると kube-apiserver 等は Static Pod で、kubelet は systemd 以下で動作するようになります。 kube-apiserver は意外にメモリを食ってしまうのでそのまま動作させているとメモリ不足になることがあります。（ありました） なので kube-apiserver と etcd の
2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo
【Team & Project】LINEの機械学習を活用したサービス開発を担当しているチームを紹介します
LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズ。今回は、LINEの機械学習を活用したサービス開発を担うMachine Learningチームを紹介します。Machine Learningチームのそれぞれのポジションで開発を進めている4名（菊地悠、齋藤祐樹、櫻打彬夫、境美樹）に話を聞きました。 ―― まず、自己紹介をお願いします。 菊地：2017年10月にプロジェクトマネージャーとして入社しました。前職は携帯電話キャリアでソフトウェア畑の研究系業務からスタートし、転職直前は位置情報系サービスの分析・開発に携わっていました。現在はチームのマネージャーとして、プロジェクトや業務の管理を行なっています。 齋藤：前の会社では広告のCTR予測やショッピングサイトのランキン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス開発の施策に納得できない時にエンジニアができるアクション - $shibayu36->blog;
最近のモダンなWebサービス開発の構成について調べるメモ
APIに利用制限をかけるとしたらどういうやりかたがあるのか - おもしろwebサービス開発日記
中途入社のソフトウェアエンジニアがWebサービス開発に参加するとき役立ったこと - kymmt
縦書きHTMLにおける文字の向きはどのように定まるか - ドワンゴ教育サービス開発者ブログ
全てを書き換え続ける。N予備校Webフロントエンド実装6年のあゆみ - ドワンゴ教育サービス開発者ブログ
技術ブログを（だいたい）1年続けた背景と成果 - ドワンゴ教育サービス開発者ブログ
Managed Kubernetesサービス開発者の自宅k8sクラスタ全容
サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発