零細経営者からみた OSS スポンサーの金額や特典設定
こうしてくれ、じゃなくて、こうなってるとスポンサーしやすいというだけの話。 安くしてくれとかではなく、これくらいの金額だと検討しやすいと思ってもらえれば。 自社では OpenSSL $ 20,000/年 や Let's Encrypt $12,500/年、Biome $ 1,000/月のスポンサーにもなってるので、あくまで参考程度でどうぞ。 スタンス 企業としては、宣伝を目的としてスポンサーになるので、企業の宣伝になるような取り組みをしてくれるととてもスポンサーになりやすい。完全に広告宣伝費です。 ロゴと企業名を一番わかりやすいところに載せてくれる イベントやリリース時にスポンサーを紹介する この 2 点をやってくれると本当に嬉しい。 もちろん利用させて貰ってるから応援という意味でのスポンサーもあるが、宣伝できた方が嬉しいし、継続もしやすい。 金額 月額と年額で結構、感覚が違う。実は月額が
はてなブックマークのステージング環境を支える技術 - Hatena Developer Blog
id:cohalzです。この記事ははてなエンジニア Advent Calendar 2023 の29日目の記事です。 28日目の記事は id:SlashNephy さんの おうち Kubernetes クラスタ運用記 ~2023~ でした。 はてなブックマークにおけるステージング環境について紹介します。 はてなブックマークでは現在インフラをAWS上に構築しており、ECSやAurora MySQLのサービスを利用しています。 本番環境と同様にステージング環境も用意していますが、より良いステージング環境(例えば本番環境に近く、変更がすぐ試せて、費用が安い構成)にすることを目指し、いくつか工夫した点があるのでそれらを紹介します。 AWSアカウントの分離 はてなでは複数のサービスを運用していますが、はてなブックマーク単体でAWSアカウントを分けて他のサービスとリソースが同居しないようにしています。
株式会社はてな 京都本社が引っ越したらしいので行ってきた！ - 941::blog
まいどおおきに！くしいです！ ブログを引っ越したことだし、東京のIT系を中心に色々なオフィスを紹介しまくっている「行ってきたシリーズ」を再開していこうかなと思いましてね！いやはや、シリーズとしては173記事目らしいです、ンマー！すごい。心機一転がんばっていきたいお気持ちです。 というわけでお邪魔したのは、このブログを書くために利用させてもらっているはてなブログを提供している株式会社はてなさんです。過去に何度かお邪魔しており、今回で5回目のようです。さてさて、2022年の3月にお引越しされたというおニューな京都本社はどんな仕上がりでしょうか？ドキワクが止まりません。 2009年5月26日 はてな東京本店に行ってきた！ 2012年10月31日 はてな東京本店が引っ越したらしいので行ってきた！ 2015年6月26日 はてな東京本店が増床して広くなったらしいので行ってきた！ 2017年12月15日
クリアした美少女ゲーム2023 - Re:cohalz
去年に続いて調子よく美少女ゲームをプレイしていったので感想を書いていく。 去年の記事はこちら。 cohalz.co 景の海のアペイリア バトルシーンはどこもアツかったけど、特にダウトで知恵比べをする部分が一番のお気に入り。 かなり癖がある作品ではあるけど体験版の範囲がおそらく長いので、そこまでやって続きをやるか判断するといいかも。 個人的にはよくこんなストーリー作れたなと脱帽する。 攻略順は何も考えず上から三羽->ましろ->久遠とやっていけば良い。 これの元ネタこの作品だったの！ pic.twitter.com/MWBMONXQSa— こはる (@cohalz) 2022年12月28日 景の海のアペイリアからまだ6年も経ってないけど今やどんどんみんながAIを身近なものに利用していて作品にだいぶ近づいてきて作品の表現の受け取り方がまた変わってきそうな予感— こはる (@cohalz) 202
GraphQL Development Workflow
I think 2023 was the first year where I got my thoughts straight on how my ideal GraphQL development workflow looks like. To no surprise the folks working on and with Relay had already long figured this out. A common issue that showed up for me when going the non-relay path was that a lot of the tools for the aforementioned workflow weren't obvious or were hard to combine. This has been improving
OIDCを利用した個人的なWEBシステムで認証情報を何をもって維持するのか考えてみた
個人開発を何度もしてきて、何一つとしてリリースしてない私が考えてみました。 リリースしないというセキュリティ担保では、やはり駄目だろう、と。 駄目なんだろうな、と思い、自分なりに整理してみました。 個人的な結論 結論から話せ、と世の中がいうので結論から言います。 OIDCの処理はバックエンドで行えるならバックエンドで行う ブラウザから利用するWebシステムならCookieを使えば良い せっかくだしcookieにはJWTを入れておけばいい 個人的にはこんな感じでいいんじゃないかと思いました。 理由はここから先に記載します。興味があったら見てください。 セキュリティは難しいし、得意じゃないのでご指導ご鞭撻は優しくしてください。(祈り) OIDCの処理はどこに置くのがいいのか OIDC自体はブラウザで結果を受け取ることも、サーバで受け取ることも可能です。 ということは、まずそもそもどこで完結させ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
