結論 社内システム上の多数のアプリケーションがChatGPT APIを活用しているというシチュエーションを想定し、AI共通基盤が持つべき機能とアーキテクチャを検討しました。 ポイントは以下の３つです。 社内システム上のあらゆるアプリケーションにChatGPT APIが組み込まれる未来が想定される アプリケーションごとに必要な実装は重複するため共通化が可能 Proxyサーバを社内に配置しそこで共通的な処理を行い、各アプリケーションはAPI呼び出しのみを行う 背景 -ChatGPT APIの2024年を予想する- 2023年5月現在のChatGPT APIの活用状況 2023年3月1日にChatGPT APIであるGPT3.5-turboがリリースされ、あらゆるプレイヤーによってこぞって活用方法が模索されています。 現在の活用状況について知見を深めたかったため、TwitterにてChatGPT

集客としてのSEOの重要性 個人開発者の多くが悩む、集客。 せっかく作ったのに誰も使ってくれない、というやつです。 集客の手段は様々ありますが、よくあるのが主に以下の５つです。 広告 SNS運用 口コミ SNSにおけるバズ 検索流入(Google, AppStoreなど) この中でもお金がかからず、時間的コストもかけず、運に頼らないもので、 長期的に安定して集客ができるのは「検索流入」です。 SEOはその検索流入を最大化させようという取り組みになります。 対象読者 ツール系のWebアプリの検索流入を増やしたい個人開発者を対象としています。 SEOで検索をするとブログやメディアを対象とした解説記事が多く見つけることができますが、ツール系のWebアプリを対象としている記事は少ないという印象です。 また、内容としては「キーワード選定」と「タイトル、h1タグの設定」という超基本的(でも一番大事だと

要約 Qiita記事がトレンドインすると、瞬間的にWebサービスへのアクセス数が急増するが、数日でアクセス数は元に戻ってしまう。 そこで以下の施策を速攻で打ってバズっているうちに有益な学びを得るべきと考え、本記事はそれを実践した結果を実データと合わせて説明している。 事前登録フォームを作って興味を持ってくれた人と繋がる Twitterやはてぶのコメントからどうして興味を持ってくれたのか考察する 有料機能を作って単なるバズなのか、本当にニーズがあるのか判断できるようにする バズる１週間前にやっていたこと 3日でツールをサクッと作った 英語面接や仕事で海外の人とやりとりをするときに「ちょっと難しい質問」をされると、途端に5歳児になってしまう自分が恥ずかしくなり、DeepLで英語の勉強をするツールを作った。 自分が使うだけのつもりだったので、アカウント機能などはなく、コアな機能１つを実装しただけ

要約 「英語で意見を言おうとすると5歳児のようになってしまう」という課題を解決するEnglisterというサービスを開発した。 自分で使ってみたところ、10問程度の問題を解くだけでスラスラと英語で意見を言えるようになった。 実装はDeepL APIとNext.jsのAPI routeを使って爆速開発をした。 追加(2021/01/18) 記事を公開してから毎日機能追加をしています。２週間前からどれだけ変わったか是非見ていただきたいです。 背景にあった課題 「英語で意見を言おうとすると5歳児のようになってしまう」 英語にすごい苦手意識があるわけではない。TOEICは840点で、すごく簡単な日常会話なら問題なくできるので、海外旅行で困るということはなかった。しかし、仕事でたまに海外の人とやりとりをするときや外資系企業の英語面接で**「ちょっと難しい質問」**をされると、途端に5歳児になってしま

const [state, setState] = useState({count:0, boolean:true}) Reactで最もよく使う状態管理を行うhook、 useState。めちゃくちゃ使い心地いいですよね。 でもこのuseStateは、当たり前ですが、共有されません。 沖縄県在住のAさんがsetStateで状態を変更しても、東京都在住のBさんのstateには影響を与えません。 当たり前ですね。 でもそれができたら面白くない？ 誰かがsetStateを実行したら、それが同じページを見ているすべての人に反映されたら何か面白いことができそうじゃないですか？ 例えば、オンライン勉強会とかができる 上記のデモ画面を見てください。ブラウザを二つ立ち上げて、片方だけを操作しています。なのに、もう片方のスライドも同期してスライドが切り替わっているのが分かるでしょうか。 これはスライド番号を

今回伝えたいこと Hasuraの有効性を伝える 開発工数の削減効果 柔軟性の高さ セキュア 「開発工数の削減」という課題 昨今のエンジニアの不足や単価の上昇により、開発工数を十分に確保できない課題がある。どこの会社も開発工数を減らすために色々な策を講じているのではないか。 新技術の活用 慣れた技術の利用 プロセスの見直し 徹底した自動化 スコープの見直し 過剰品質をやめる などなど。今回は一番上の「新技術の活用」によって開発工数を削減できる可能性があるのではないかということを提案する。 こんなアプリを作ることになったとする 仮にあなたがこんなアプリを作ることになったとする。 シンプルなオンラインホワイトボードツールで以下のような機能があることが必要 付箋に文字を書ける 付箋を動かせる 付箋の色がユーザ固有の色になる 付箋を消せる(自分の作った付箋だけ) 付箋の位置、内容などをリアルタイムに

背景 AWS LambdaでAPI開発をする AWS LambdaとAPI Gatewayを組み合わせることでサーバレスのAPIを開発することが可能です。サーバレスで構築することで手間をかけずにスケーラビリティやコストの最適化を手に入れることができ、さらに死活監視等が不要のため運用のコストを大幅に下げることができます。 開発パターンがまとまっていない サーバレスによるAPI開発は非常にメリットが多いのですが、開発パターンが様々あり一貫した方法があるわけではありません。例えば、Lambdaのデプロイは手動でzipをアップロードする方法や、SAM/ServerlesssFrameworkなどのデプロイ支援ツールを利用する方法、さらにオンラインエディタのCloud9を利用することもあります。関数ごとにディレクトリを分離する場合もあるし、ソースコードを共有してエントリーポイントだけ切り替える場合も

結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。 このアーキテクチャでどんなものができるのよ、という視点で見ていただくと面白いかもしれません。 ↓ 背景 アーキテクチャに絶対の正解はない アーキテクチャには絶対の正解はありません。 なぜなら、プロダクトやフェーズによって求められる要件が異なり、それに適したア

失敗してしまう個人開発 趣味の個人開発で過去にいくつものプロダクトを作ってきました。 ユーザがたくさんついて、ゆくゆくは収益化したいななどと思いながら作っていましたが、残念ながらどれも一瞬だけ少人数の人に使われるだけで、そのさきを描けずにいました。 「いいアイディアが思いついたからいきなり作り始めた」とか「顧客が不在のままとにかく作ってしまった」とかは個人開発でやりがちです。最初にアイディアや顧客について詰めていなかったために誰にも使われないで終わってしまう、というのはよくある失敗なのではないかと思っています。 趣味の開発や、技術力向上という意味ではそれでもいいのですが、あわよくばビジネスにしていきたいという思いがある時は一旦考え直す必要があるかもしれません。 誰も課題だと感じていない領域を攻めていたり、自分の解決策がユーザにとってお金を払いたいほど魅力的でない場合はユーザを定着させること

概要 ウォータフォールでの開発経験が長いチームメンバにて、アジャイル開発推進プロジェクトとしていくつかのアジャイル開発のプラクティスをレクチャーし、その感想を伺いました。 メンバの現職ではどのようにプロジェクトを進めているか 機能単位のタスクを出して見積もりを行う 線表(スケジュール)を引く 基本的にスケジュール通りに進めていく 遅れが出たら別部署から助けを借りる、人を増やす、お客さんと調整を行う 「この人はこの機能を担当」という風に分担し、個人でコーディングを進めていく(他の人がどんなプログラムを書いているかは全く見えない) 基本的にその部署が今までやってきた案件をとってくるため「なにこれ」という仕事はこない メンバが感じているウォーターフォールの良いところ/悪いところ 良いところ 得意な案件を慣れた手順で開発していくため、不安なくプロジェクトを進めることができる 「こういうものを作りた

前書き プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか？」だ。厳しいところだと「何日に納品してくれるのか？」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。 見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。 なぜ見積もりをしないといけないのか？ 見

追記(2019/11/2) 今回の記事で深く扱えなかったリファクタリングに関する記事を書きました。 「汚いコード、綺麗なコードって何？」リファクタリングを考えてみる テスト駆動開発とは テスト駆動開発とは、「テスト => 実装 => リファクタリング」という流れを何回も何回も繰り返してプロダクトを成長させていく開発手法です。 もう少し詳しく説明します。次の３段階を繰り返します。 1. テストケースを考えるフェーズ これは設計を考えることに等しいフェーズです。このオブジェクトがどんな機能を持っていて欲しいか、どういう風に使われるか、そしてその時にどんな結果を返して欲しいか、という思いをテストケースに込めます。 重要なのはこの時に実装のことは一切考えず、どう使われるかを考えることです。 2. 実装するフェーズ テストをパスするためだけの最低限度の実装をします。この時も抽象化やキレイなコードなど

追記(2019/11/2) 今回の記事で深く扱えなかったリファクタリングに関する記事を書きました。 「汚いコード、綺麗なコードって何？」リファクタリングを考えてみる 追記(2019/08/16) 今回の記事では深く扱えなかったテスト駆動開発についての記事を書きました。参考にしてください。 僕たちがテスト駆動開発をする理由 リファクタリングに関する記事も書く予定です。 背景 フルリモートエンジニアはとてもいいものです。どこでも仕事ができるので旅行をしながら、海外にいながら、温泉に入りながら、どこででも好きなタイミングで仕事をすることができます。 この素晴らしい自由を支えるのは顧客との信頼です。 フルリモートの仕事は、仕事の過程を見ることができないため完全な成果物主義であり、この仕事をこの人に任せればこんな成果物が返ってくるだろうという期待と信頼関係によって成り立っています。 顧客に価値を届け

まえがき 以前に初心者3人でwebサービス(webアプリ)を作ったので、立ち上げからリリースまでを時系列に書いていくという記事を書かせていただきました。 今回は、前回の失敗を踏まえてサービス作りを考えて実装してみました。 それがTwitterでプレゼントキャンペーンを開ける「プレキャン」というサービスです！ 今回の記事は雑多な内容になりますので、目次から気になるものだけをつまみ食いしてお読みください。各項目の内容は独立していますので、どこから読んでいただいても大丈夫です。 目次 １、前回の反省点と、プレキャンを作ろうと思ったきっかけ ２、サービス内容 ３、試しにプレゼントキャンペーンに応募してみて ４、「RTしたらすぐくる」を実現する技術 ５、TwitterAPI制限への対応 ６、キャンペーン終了後に再抽選 ７、dynamoDB + lambda開発で採用したプラクティス ８、システムの応

8/19(開始から0日目) 議題 : 「何をやるか決める」 時間 : 3時間 初日の会議は何をやるか決めました。作ってみたいもの、やってみたいこと、アイディアをとにかく雑多に書き出していきました。 その時に出たアイディアがこんな感じです(原文ママ) リアルタイムに腹筋バトル ツイッターのその人のイラストだけを収集して表示 飲食店のメニューのweb化 スピード合コン jsのアニメーションをフル活用したブログ 目標達成を対戦化(対人) バーチャルユーチューバーの情報を集める 自分の宣伝してほしいものを提示して、ツイートをしてもらう 同じ料理をどれ程うまく撮れたか投稿し合って投票でランキングするアプリ。 youtubeライブ&チャット + twitter CMの間に溜まったツイートを見るサイト 飯を食べるとカーリングのストーンが投げられる 「自分たちでも作れる」「作ってて楽しいもの」「ユーザ投稿