はらだ

アプリ/事業開発日記です。 開発、運営中のスポーツチーム用クローズドSNSについて書き…

はらだ

アプリ/事業開発日記です。 開発、運営中のスポーツチーム用クローズドSNSについて書きます。 UIUX、ユーザーの声、具体的なプログラミングの話。 Django, ReactNative, React, TypeScript, AWS 麻布 ⇒ 東大 ⇒ 今

最近の記事

50万円をクラウドファンディングで集めるために僕がした4つのコト

こんにちは、起業しつつエンジニアしてる原田です。 昨年の9月から10月にかけて、クラウドファンディングを行いました。内容は、僕の開発しているスポーツチーム用の動画サービスのスマホアプリ化プロジェクトです(https://camp-fire.jp/projects/view/152303)。 サービスを一言で言うと、もっとチーム内で簡単に動画を共有・蓄積して、知見を溜めて上手くなろうぜ!っていうものです。 結果として76名もの方からご支援いただき、50万円を超える支援額が集

    • CEOがCTOを兼ねてはいけない3つのワケ

      お久しぶりです、はらだです。 チームづくりを考えていくうちに、CEOとCTO兼任ってアンチパターンだなと思うようになりました。 まぁ僕は今ガッツリ兼任なんですが。 そう思った理由は3つあります。 1. CEOにコードを書く時間はない 2. プロダクトの限界が決まってしまう 3. ユーザーインタビューを躊躇しがち ちなみに以前はこんな記事も書いてました。 事業を一人でやることの「デ」メリット 1. CEOにコードを書く時間はないいやもうこれ。 作業のスイッチングコストも

      • その2 著作権 "良いウェブサービスを支える「利用規約」の作り方 " を読んだのでまとめました

        こんばんは! クリスマスも終わりましたので、"良いウェブサービスを支える「利用規約」の作り方 "から抜粋して、著作権についてまとめます。 ちなみに前回は3大ドキュメント(利用規約、プライバシーポリシー、特定商取引法に基づく表示)に関してでした。 ユーザー投稿型のサービスだと、著作権の扱いがめちゃ大事になります。 「ユーザーの投稿を広告に使いたい…」とか、ありますよね。 サービスの売却の際にも、ユーザーの著作権をどの程度おさえてるかが大事になります。 また、サービス事業者

        • その1 3大ドキュメント "良いウェブサービスを支える「利用規約」の作り方 " を読んだのでまとめました

          こんにちは、はらだです。 アプリリリース最後の難関、利用規約まで来ました。 ので、良本と噂の「良いウェブサービスを支える「利用規約」の作り方」を読んでみることに。 Twitterで紹介してくださった方、ありがとうございます! 結局は弁護士さんに相談しますが、少しは概観を理解していないとこの先もまずいと思うので。 また、弁護士さんとお話をする時に具体的に尋ねる項目を考えておくのは重要だと思います。 時間の節約的にも、スーパード素人だと舐められないためにも! ってことで記憶

        50万円をクラウドファンディングで集めるために僕がした4つのコト

        • CEOがCTOを兼ねてはいけない3つのワケ

        • その2 著作権 "良いウェブサービスを支える「利用規約」の作り方 " を読んだのでまとめました

        • その1 3大ドキュメント "良いウェブサービスを支える「利用規約」の作り方 " を読んだのでまとめました

          AWS EC2 スポットインスタンスの使い方と使いどこ

          EC2スポットインスタンスというのを初めて知りました。 スポットインスタンスと言っても、性能は普通のインスタンスと変わりません。 インスタンスタイプもt2.largeとか、普通のEC2と同じです。 ではどこが違うのか、 安く借りられる(メリット) 最大で90%オフらしいです。 僕がみた感じだと70%オフくらいが多かったです。 いつインスタンスが落とされるか分からない(デメリット) AWSの都合で勝手に落とされるらしいです。 一応落とされる2分前には連絡が来るそうです。 空

          AWS EC2 スポットインスタンスの使い方と使いどこ

          AWS LightsailからEC2への移行

          久しぶりのnoteです。 アプリ開発その他で忙殺されていました。 始めの2週間は毎日書いていたのに…これからまた再開します! まぁ今回はただの備忘録です。 Lightsailから移行する必要性LightsailからEC2に移行した訳は、EC2の方が自由度が高いからです。 以下によくまとまっています。 参考 : Amazon Lightsailとは?EC2との違いとメリット・デメリットを調べてみた Lightsailは、いろんなもの(RDB, DNSとか)が含まれた月額固定

          AWS LightsailからEC2への移行

          GatsbyJS始めました。

          GatsbyJS始めました。 静的サイトジェネレータです。 Gatsbyのメリット・爆速(SSR, SPA, PWA) ・既存のWordPressサイトから引っ越し可能(WordPressサイトからデータを引っこ抜いて移植) ・内部はReactなのでデザイン変更等が楽 ・プラグインが豊富 といったメリットがあります。 なかでも、WordPressからのお引越しは感動しました。 ブログを改めるとなると、今まで書いた記事が引き継げない(=>スイッチングコストが高い)ってのが真

          GatsbyJS始めました。

          gitignoreでディレクトリごと無視すると、「その中の特定のファイルだけはgitに反映」ができない

          タイトルが分かりづらいですが、例えば dir1というディレクトリは基本全部除外したい(gitignore)。 けど、dir1/file1だけはgitに含めたい…。 ありますよね。 そんなときは dir/* !dir/file1 と書きます。 ダメな例gitignoreに dir !dir/file1 と書いてもfile1はgitに反映されません。 dirとだけ書くのはdirディレクトリを全無視という意味で、dir/*は、dirディレクトリの配下全部除外の意

          gitignoreでディレクトリごと無視すると、「その中の特定のファイルだけはgitに反映」ができない

          FireBase+ReactNative(Expo)でチャットアプリ作りました。

          気になるなぁ。 一回触れたいなぁ。 と思いつつ、全く触っていなかったFirebase。 ついに触れ合いました。 Djangoはリアルタイム通信に向いていません。 今までDaphneというライブラリでWebsocketを使っていましたが、プロセスがゾンビ化したり色々面倒なので、リアルタイム性が求められる部分はFirebaseにしようかと思っていました。 最近、僕のサービスClubCloudをスマホアプリ化するということで、バックエンドをフロントエンドと切り離したり、Reac

          FireBase+ReactNative(Expo)でチャットアプリ作りました。

          Django+ReactNativeでCookieでセッション管理

          今のサービスClubCloudをネイティブアプリ化するため、認証をいじっています。 Djangoのデフォルトは、Cookieを使ったセッション管理と認証です。 これを、Tokenベースのステートレスな認証に変えようかと思いましたが、とりあえず現状のCookieベースでネイティブアプリと連携させることにしました。 Djangoは全然RESTじゃない?最近だとTokenを使ったRESTfulな実装が一般的かなと思います。 RESTとは以下のような設計原則です(これに従うのが、R

          Django+ReactNativeでCookieでセッション管理

          EC2 だけhttps化(not with ロードバランサー but Nginx)

          完全に備忘録です。 テスト環境を作るために、もう一つEC2を立てました。 本当に一部の機能のテストをするだけのものです。 例えば、ブラウザとLinux間でライブストリーミングを行ったり。 ロードバランサ―も特に必要ないと思うので、EC2を直接HTTPS化します。 おおまかな流れロードバランサ―を使った場合は Route53で名前解決 ⇒ ロードバランサ―のポート443に ⇒ EC2のポート80に というリクエストの流れでした。 今回は直接 Route53で名前解決

          EC2 だけhttps化(not with ロードバランサー but Nginx)

          Nginxで異なるページで別々にベーシック認証

          ベーシック認証なんだかんだ便利なので、仕事でも使ったりします。 ページごとにユーザー名とパスワードを変えることも簡単にできます。 使ったのはAmazonLinux、Nginxです。 ユーザー名とパスワードの入ったファイルを作るhtpasswdというコマンドを使うので、マシンにインストールします。 sudo yum install -y httpd-tools 次に sudo htpasswd -c /etc/nginx/ファイル名 ユーザ名 ファイル名は.htpas

          Nginxで異なるページで別々にベーシック認証

          技術書典7に行ってきました!(混み具合とか、買ったものとか書きます)

          9/22(日)、技術書典7に行ってきました。 初めての技術書典! 混み具合11時前に会場に着き、列に並び、入場しました。 列に並ぶのは30分ほどでしたが、人の数は凄まじかったです。 日に当たるのが辛かったな。 日傘を持参している方もいました。 入場後の印象としては、混んでたけど、そこまで混んでないって感じでしたね。 2時間で2階と3階全てのエリアを満足に回ることができました。 購入はもちろん、見本を見るのも十分にできました。 11:00-13:00の入場だと入場料が100

          技術書典7に行ってきました!(混み具合とか、買ったものとか書きます)

          Django、カスタムヘッダー + ミドルウェアでテンプレートとAPI用レスポンス(Json)を出し分け!

          こんにちは、PWAの勉強会で「PWAあるある」とか発表しておきながら、脱PWAからのネイティブアプリ開発資金クラウドファンディングの話(宣伝ではない)までしてしまった原田です。 コードは同じでAPIだけJSONで返したい ネイティブアプリにするということでレスポンスをJSONにしないといけません。 しかし今はDjangoのテンプレートエンジンを使っているので、レスポンスはHttpResponseです。 これはJSONシリアライズできません。 そこで、Web用のHttpRe

          Django、カスタムヘッダー + ミドルウェアでテンプレートとAPI用レスポンス(Json)を出し分け!

          他サーバーで取得したドメインをAWSでhttps化する その3(NSレコードの移し替え )

          前回までで、ロードバランサーへのSSL証明書のアタッチとポート443の開放は終わりました。 次に、というか最後に必要なのが、他サーバーからのネームサーバーの変更とNSレコードの移し替えです。 ネームサーバーは、どこのレコードでリクエストをルーティングするか、NSレコードはそのルーティングの内容を定めているものらしいです。 今ドメインのネームサーバーはスターサーバーのものになってるので、ドメインに関する情報はスターサーバーのレコードを参照しています。 これを、対象ドメインのネ

          他サーバーで取得したドメインをAWSでhttps化する その3(NSレコードの移し替え )

          他サーバーで取得したドメインをAWSでhttps化する その2(ロードバランサへのSSL証明書のアタッチ)

          前回、他サーバーで取得したSSL証明書をAWSのACMにインポートしました。 それを今回443ポートの解放に使います。 https://recipe.kc-cloud.jp/archives/11067 この記事にある中の一番最初の構成を目指します。 つまり、クライアントからのリクエストをRoute53でALB(ELB)の443ポートに送って、ALBがEC2の80番ポートに送る構成です。 443に必要なので、SSL証明書はALBにつけます。 さらにセキュリティを強固にした

          他サーバーで取得したドメインをAWSでhttps化する その2(ロードバランサへのSSL証明書のアタッチ)