〜Twilog・Togetter統合の舞台裏〜 by 吉田俊明、青山民人｜トゥギャッター株式会社 Twilog https://twilog.togetter.com/ Togetter https://togetter.com/
独学で個人開発を始めて5年が経ちました。これまでには収益化に成功したサービスもあれば、鳴かず飛ばずでお蔵入りになったサービスも数多くあります。それらの経験から、成功したサービスはなぜ上手くいったのか、マーケティングや収益化において押さえておくべきことは何か、その要点が少しずつ見えるようになりました。 今回は私が開発〜集客〜収益化を行うプロセスと、各工程で気をつけているポイントを順を追って書き出してみます。上手く言語化できているか分かりませんが、暖かい目でお付き合いください。 収益化した3つのサービス 私はこれまでにWebサービスを20個以上開発しており、現在はポモドーロタイマー（月間100万ユーザー）やYouTubeのループ再生ツール（月間10万ユーザー）などを運営し、そこからの収入で生活しています。 基本は海外向けのBtoCで、以下のようなツール系が中心です： 収益化済みサービス： Po
この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ
はじめに はじめまして、Data Scientist の山内（@jof_5）です。 本記事では、先日、社内で開催した Dify ハッカソンの様子について紹介します。 はじめに Dify ハッカソン実施の背景 開発したLLMアプリケーションのご紹介 1. クラウドサービス見積もりくん 2. Sales Lead Generator 3. その他 Dify ハッカソンを通じて得た学び 最後に Dify ハッカソン実施の背景 先日、LLM アプリケーションをノーコードで開発できる Dify という新しいツールが登場し、LLM アプリケーション開発を大幅に簡素化できると話題になっていました。 dify.ai 社内でも話題に上がっており、Dify の実用性について興味深い議論が巻き起こりました。「本当に使いやすいのか？」「どこまでの機能が実装可能か？」「実際の開発現場でどの程度有用か？」といった疑問
こんにちは、AIShift バックエンドエンジニアの石井(@sugar235711)です。 AIShiftでは去年の11月からAI Worker[1]という新しいサービスの開発が始まりました。（以下AI Worker） 本格的に開発が始まり3ヶ月弱経ったので、その間に試してきた技術やチームの取り組みについてまとめてみたいと思います。 はじめに この記事では、AI Workerのおおまかな概要・設計を説明し、それらのバックエンドを実現する上でどのような技術を試してきたのか、技術以外でのチームの取り組みについてまとめます。 少し分量が多いので、ライブラリについての情報を求めている方は、目次から気になる部分を読んでいただければと思います。 何を作っているのか ざっくりまとめると、Microsoft Teams/Web上で動くAIを活用した業務改善プラットフォームを作成しています。 GPTとRAG
はじめに 個人でフロントエンド(react)、バックエンド(node.js)、データベース(postgreSQL)を利用したWebサービスを公開したいと考えていました。 まずはテスト的に無料で外部公開できるサービスがないか調査しましたが、2022年8月に有料化されたHerokuの記事ばかりヒットしてしました。 結果的には無料で使用できる構成があり、実際にテストプログラムを動作させることができましたので構成例として記載しておきます。 ※無料なので比較的厳しい条件も含まれていたりするのでそれぞれのサービスを確認お願いします。 例えばsupabaseは数日間利用がないとインスタンスが一時停止して手動で起動させないといけないなどがあります。 今回試したサービス できるだけ同じサービスに集約したいと考えていましたが、実際にはフロントエンド、バックエンド、データベースはそれぞれ異なるサービスになってし
本記事は 執筆デビューWeek 10日目の記事です。 ✨ 9日目 ▶▶ 本記事 ▶▶ 11日目 🔰 初めに MVCとREST APIの違い ビュー層の構成 認証・認可アーキテクチャ サービス構成 REST API+SPA構成のメリット/デメリット MVC構成のメリット/デメリット 総括 最後に 初めに 初めまして。9月にキャリア入社した芳賀と申します。前職ではオンプレミス環境+MVC構成のWebアプリのエンジニアをしておりました。現在はAmazon ECS+REST API（Spring Boot）+SPA構成のバックエンドエンジニアをしており、入社前後でアーキテクチャ構成がかなり変わって四苦八苦しております(笑) そこで、2か月間の経験をもとにMVC/REST APIの差で困ったポイントをまとめてみました。今後アーキテクチャ変更に取り組まれようとしている方の一助になればと思います。 M
マイクロサービスアーキテクチャにおいては、個々が独立に選定したデータベースを持つ複数のサービスにまたがって、データの整合性を維持する必要があります。 そのための方法として、Sagaパターンと呼ばれる設計方法がありますが、Sagaでは分離性が欠如しておりLost Update等の異常が発生しかねません。 そこで本記事では、Sagaの分離性を高めるための実装におけるTipsを解説します。 目次 目次 はじめに 複数サービス間での整合性維持における課題 Sagaパターン Sagaを構成するトランザクション Sagaによって実現される安全性 原子性（Atomicity） 整合性（Consistency） 分離性（Isolation） 永続性（Durability） 異常を防止/軽減する実装 分離性の欠如が引き起こす異常 分離性の欠如への対策 Semantic Lock Commutative Up
Instagramはどうやって3人のエンジニアで1400万人にサービスを提供できるシステムを組み上げたのか
Instagramは2010年10月にサービスを開始後、2011年12月までのわずか1年間で1400万人に利用されるほど巨大なサービスに成長しました。こうしたスケールに対応できるシステムを組み上げたのはたった3人のエンジニアだったとのことで、どのように少人数でスケールするシステムを組み上げたのかについて、エキスパートエンジニアのレオナルド・クリードさんが解説しています。 How Instagram scaled to 14 million users with only 3 engineers https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million レオナルド・クリードさんは、Instagramが3人のエンジニアで安定して巨大なサービスを提供できた理由として、下記の3つの原則を守ったからだと述べています
GraphQL実践ノウハウ https://speakerdeck.com/sonatard/graphql-knowhow GraphQL実践ノウハウv2 https://speakerdeck.com/sonatard/graphql-knowhow-v2 宣言的UIの状態管理とアー…
要約 「英語で意見を言おうとすると5歳児のようになってしまう」という課題を解決するEnglisterというサービスを開発した。 自分で使ってみたところ、10問程度の問題を解くだけでスラスラと英語で意見を言えるようになった。 実装はDeepL APIとNext.jsのAPI routeを使って爆速開発をした。 追加(2021/01/18) 記事を公開してから毎日機能追加をしています。２週間前からどれだけ変わったか是非見ていただきたいです。 背景にあった課題 「英語で意見を言おうとすると5歳児のようになってしまう」 英語にすごい苦手意識があるわけではない。TOEICは840点で、すごく簡単な日常会話なら問題なくできるので、海外旅行で困るということはなかった。しかし、仕事でたまに海外の人とやりとりをするときや外資系企業の英語面接で**「ちょっと難しい質問」**をされると、途端に5歳児になってしま
はじめにTIG真野です。 Google DriveにアップロードされたExcelファイルを利用したちょっとしたジョブを実装する機会があり、処理を動かしたいのがAWSなど別のプラットフォームであったため、サービスアカウントを用いてGoogle Drive APIにアクセスするGoプログラムを作りました。 いくつかの人が書いている通り、Google Drive APIもv2, v3で情報が入り乱れていて本家のドキュメントを探したて見ながら試行錯誤したりちょっと悩みました。また、サービスアカウント利用する実装例が少なかったので手順をまとめていきます。 認証方式Google Drive APIを用いたコード実装を始める前に、事前にアカウントなどの権限周りの準備を実施します。 Google Drive APIを使うための認証方式には大きく4つの方法があります。 APIキー: 一般公開データに匿名でア
2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo
2011 年の文章だけど、今でもかなり示唆深い。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（前編） Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（中編） Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（後編） 以下は気になったポイントを引用しつつ、行間を読みつつまとめたもの。個人的な解釈も入っているので注意してください。 プロダクトとプラットフォーム まずシステムを “プロダクト” と “プラットフォーム” に分け、それらが根本的に違うと言っている。 特定のセグメントに価値を届けるシステム (垂直統合的)特定のセグメントに機能を素早く提供できる完璧な要件定義をし、それをリリースするのが理想 プロダクト プラットフォーム プロダクトは特定のセグメントに対して価
はじめに こんにちは、メルカリJP の Search Backend チームの otter です。 今回は、BFF的役割を担っている Search API のインターフェースを version 2 として刷新したときの課題や改善した点について紹介したいと思います。 API が持っていた課題 ご存知の方も多いと思いますが、メルカリではサービス全体としてマイクロサービスアーキテクチャによる開発を採用しています。 Search API もモノリシックな API からマイクロサービスとして切り出されたもので、iOS やAndroid などのクライアントとの後方互換性を担保するため、API のインターフェースや仕様はそのまま移行されました。 そのため、サービス面では柔軟に新たな施策に対応するのが難しかったり、システム面では各マイクロサービスで共通化されるべき、エラーハンドリングやページネーションがメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
