〜Twilog・Togetter統合の舞台裏〜 by 吉田俊明、青山民人|トゥギャッター株式会社 Twilog https://twilog.togetter.com/ Togetter https://togetter.com/
[Linux] GitLabオンプレミス構築 (Docker) この記事のGitLab構築はDockerを用いて行うこととする.Dockerを用いることのメリットは,1. 簡単に設定できる.2. イメージごとバックアップすることで,他のマシンに… ラベルとは Redmine, GitHub, GitLabなどのチケットやIssue管理において,Issueを分類わけするためのものである. ラベルを付けておくと,そのIssueに取り掛かる人はどのような内容なのか把握できる.また,後々見直すときも探しやすい. ラベルの重要性に関しては,ある程度共通認識があると思うが,実際のところどのようなラベルを使えば良いかというのは,案外難しい. Issueラベル 優先度系 Priority: Critical 緊急のもの,直ちに対応すべきPriority: High 優先度:高Priority: Mediu
この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな! ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください! 【追記】 上記に対して「有料記事がダメって事?」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います!そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ
ソフトウェアエンジニアの後藤です。 今回は私が所属するプロジェクトで行った、ゲームロジックのクラスライブラリ化について紹介します。 経緯 開発初期にゲームの戦闘パートなどの、所謂「メインゲーム」を Unity のプロジェクト内に実装していました。 しかし開発が進むにつれて、 Unity を使わずにメインゲームを動かしたい場面が出てきました。その例を以下に挙げます。 AI に1000回バトルさせて勝率を記録する サーバに送られたログから戦闘を再現できるか検証し、ユーザーがチートしているか調べる これを実現するため、メインゲームの機能を Unity から分離して他のアプリケーションでも利用できるようにしました。 目的・問題設定 サンプルとして簡素なRPGの戦闘パートを作成しました。 [ゲームルール] ■キャラクターは「味方」と「敵」のチームに分かれる ■素早さが高い順に1人ずつ、誰かに攻撃する
【この記事の対象者】 仕様書の書き方が分からなくて、困っているゲームプランナー ゲームプランナーの素養を身に付けたい人 ゲーム開発に興味がある人 【この記事で学べること】 仕様の考え方 仕様書の作成方法 ゲームデザインに関する基礎知識 前回の記事 前回の記事では、なぜ人によって仕様書作成の能力に差が出るのかを解説しました。今回は仕様書作成の能力を身に付けるための方法を紹介します。 はじめに仕様書が書けない人は、次のどちらかに当てはまると思います。 やりたいことがはっきりしていない やりたいことがはっきりしているが、何を書けばいいのか分からない 『2』に関しては「仕様書の書き方」を調べていけば、答えにたどり着く可能性があります。 しかし、『1』の場合は「仕様書の書き方」を調べても、答えにたどり着けません。なぜなら、「仕様書の書き方」でつまづいているのではなく、「仕様の考え方」の部分でつまづい
TOPコラムテック最前線レポート【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 2024年8月8日 プログラマ、テスト駆動開発者 和田 卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』(オライリージャパン、2010)監修。『SQLアンチパターン』(オライリージャパン、2013)監訳。『テスト駆動開発』(オーム社、2017)翻訳。『事業をエンジニアリングする技術者たち』(ラムダノート、2022)編者。テストライブ
ここ数年Unityを使ったUI開発に携わることが多くその知見は過去に何度か発信してきました。 今回は新規ゲーム開発で、 UIの設計をやったことのない初心者エンジニア 向けに役立つ9つのTipsを紹介します。 【本記事で得られる内容】 UI開発歴15年の確かなUI開発ノウハウいざUI開発を任された時のための初心者エンジニア向けの知見失敗しないUI開発には「開発思想」は必須失敗しないUI開発に必要なのは「開発思想」です。思想なき開発に成功なし。 まず、このノウハウがどういう思想をもとにしたものかを簡単に説明します。 オオバがUI開発で大事にしている思想は2つ。 思想① 開発期間を短く抑えたい当たり前ですが開発にはお金(コスト)がかかります。そして予算の関係上、コストとは 有限 です。開発コストの大半は 人件費(人件費 × 開発期間) 。 つまり、 開発メンバーは少ないほどよい のです。 「開発
こちらのイベントの登壇発表資料です。 アーキテクチャを突き詰める Online Conference https://findy.connpass.com/event/314782/
技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな
PHPerKaigi 2024の登壇資料のほうが図面がわかりやすいので記載する。 ※2024/06/25 追記 speakerdeck.com どうもキャッシュバスターズ、 id:Soudai です。 Cache(以下、キャッシュ)は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒め
事前知識編 システム開発するプログラマも読んでおいたほうがいい資料とか。 今時のシステムならまず仕様や運用に反映される。されてなかったらむしろこっちから確認取りに行った方がいい。 JOGAガイドライン 昔ガチャとかが問題になったときに出てきた協会のガイドライン。 オンラインゲーム安心安全宣言 オンラインゲームにおけるビジネスモデルの企画設計および運用ガイドライン ランダム型アイテム提供方式を利用したアイテム販売における表示および運営ガイドライン オンラインゲームガイドライン 開発環境編 GitHubみたいなPullRequestを出せる環境 GitだけじゃなくてGitHub。必然的に規模が大きくなるのでプルリク出して進めることになります。 CIまで設定をする 最初のうちにCircleCIのようなテストの自動実行する仕組みまで揃えてしまっておいたほうが良いです。後からだとそもそも対応できなく
株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。1回目は、開発の生産性に大きく影響する、「チームの認知負荷(Team Cognitive Load)」について。 名村卓氏のキャリア変遷大谷旅人氏(以下、大谷):それでは本日のメインの名村さんのお話に入りたいと思います。LayerX 名村さん、ご登壇よろしくお願いします。 名村卓氏(以下、名村):はい、よろしくお願いします。LayerXの名村と申します。今、LayerXでEnabling Teamという、Enablementをやっている組織にいるのですが、今日はそこでの経験と諸々含めてお話できればと思っています
こんにちは。 個人開発で食べている、あたかです。 この記事は、 「ユーザーが定着するカスタマーサポート術」 前編の続きなので、前編がまだの方はコチラどうぞ という訳で、つべこべ言わず後編行ってみましょう🚀 共感するものがあったら、是非サービスの改善に活用してみてください。 11. まずはありがとう、から お問い合わせへの返信は 「お問い合わせ、ありがとうございます。」 という感謝の言葉から始める。 ありがとうって、みんなを幸せにする魔法のコトバですね。 12. さらにお礼を 前にもお問合せをして来た人だとわかった場合は、前にもお問い合わせをしてくれた事のお礼を伝える。 覚えてくれていると嬉しいものですよね。 13. 必要な情報は自動添付 OSバージョン、端末種類、アプリバージョン、その他、原因特定に必要なパラメータが、お問合せ内容に自動で添付されるように仕込んで、余計なやり取りを極力減ら
こんにちは。 個人開発で食べている、あたかです。 企業よりマンパワーが圧倒的に弱い個人開発だと、色々とミニマルに進めざるを得ないかもしれませんが、特に手を抜きがちなのが、CS(カスタマーサポート)じゃないでしょうか? DL数や、ストアランキング、SNSでのバズり具合が注目されがちですが、個人開発で食べていくには、そんなことより、 「どれだけユーザーが残ってくれるか」 の方がずっと重要です。 そんな重要な要素を支える大きな力がCS! こんなレビューも有るように、デキルCSは収益にも繋がっていきます。 という訳で、僕が実践している、企業を超えるカスタマーサポート術 を共有します。 長くなりそうなので、前編、後編に分けてお送りします。 共感する所がありましたら、是非、今日から実践してみてください。 後編はコチラ 1. お問い合わせ機能を入れる まず入れないとね。 あと、手を抜いて、バグ報告という
semantic-commit-messages.md Semantic Commit Messages See how a minor change to your commit message style can make you a better programmer. Format: <type>(<scope>): <subject> <scope> is optional Example feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in present tense. | +-------> Type: chore, docs, feat, fix, refactor, style, or test. More Examples: feat: (new feature for the user, not a
こんにちは。 家で毎日エルデンリングをしながら、個人開発アプリだけで生活している、あたかです。 コロナとロシア問題で、ガクンと下がった広告収益に比べて、 圧倒的安定感 を見せていたサブスクさん。 最近はサブスクのサービスが増えて、月額を払い続ける抵抗感が下がって来ていることもあり、ますますサブスク重要だなぁ〜と実感しています。 🍄 サブスク機能、どうやって決めていますか? そんな大事なサブスク機能、お金を払ってもらうには 有料級の凄く良いものを! と考えますよね。 似たようなコンセプトの競合アプリのサブスク機能を見て、同じ、もしくはそれを超える機能を入れるのが、簡単で一般的ですかね? 「それ、間違っています」 なんて大それたことは(タイトルに入ってるけど)言えませんが、とてもモッタイナイです。 何でかといいますと...。 過去にこういった記事で、沢山の方に読んで頂いた僕のアプリ 「しつこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く