PMFを狙うスタートアップの開発戦略 – SOELU Developers – Medium
最短でサービスをローンチするサービスが世に出ない限り、検証は何も始まりません。最短でサービスをローンチするための技術選定を行う必要があります。 技術的な冒険はしない重要なのは『チームをリードできる技術を使うこと』であると考えています。最も自分が精通している技術で、メンバーが躓くことなく一直線に開発できるようサポートする必要があります。私の場合、最も手に馴染んだ言語がRubyであったため、Rubyを選択しました。 コードを書かないことに勝る手段はないまた、『いかにしてコードを書かずに済ますか』という観点も重要です。成熟したフルスタックフレームワークを使用することで、自分たちで書くコード量は圧倒的に短縮できます。私たちの場合、Ruby on Railsを使うことで多くの処理をGemに丸投げし、管理画面はRailsAdminを使用することで開発時間を圧縮しました。Railsはもちろん銀の弾丸では
最近のアプリ界隈での「設計」の違和感 - なるようになるかも
アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か？ MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
iOS/Androidアプリへドメイン駆動設計（DDD）を導入してCleanArchitectureを目指す [導入編] - Qiita
今回業務で初めてドメイン駆動設計（以後DDD）をiOSアプリへ導入してCleanArchitectureを目指してみたのでまとめとその所感をつらつらと書いてみます。 今回はたまたまiOSで導入したのでiOS前提で話を進めますがAndroidにも適用できる汎用的な概念です。 上辺だけの知識+オレオレルールで導入を始めたので間違っていたらご指摘お願いしますm(_ _)m そもそもドメイン駆動設計って？ MVCなどの概念と同じ（ちょっと違うけど）設計アーキテクチャの一つで、iOSやAndroidアプリ開発でおこりがちな、ファットコントローラーを解決することができるかもしれない設計手法の一つです。 MVCじゃだめなん？ MVCを採用するiOSやAndroidアプリでは、コントローラクラス（UIViewControllerやActivity）の責務が非常に広く、クラスが肥大化しやすいという問題点があ
![iOS/Androidアプリへドメイン駆動設計（DDD）を導入してCleanArchitectureを目指す [導入編] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/15c6d1499489a374a15e9fb0b368542aee9243ef/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9aU9TJTJGQW5kcm9pZCVFMyU4MiVBMiVFMyU4MyU5NyVFMyU4MyVBQSVFMyU4MSVCOCVFMyU4MyU4OSVFMyU4MyVBMSVFMyU4MiVBNCVFMyU4MyVCMyVFOSVBNyU4NiVFNSU4QiU5NSVFOCVBOCVBRCVFOCVBOCU4OCVFRiVCQyU4OERERCVFRiVCQyU4OSVFMyU4MiU5MiVFNSVCMCU4RSVFNSU4NSVBNSVFMyU4MSU5NyVFMyU4MSVBNkNsZWFuQXJjaGl0ZWN0dXJlJUUzJTgyJTkyJUU3JTlCJUFFJUU2JThDJTg3JUUzJTgxJTk5JTIwJTVCJUU1JUIwJThFJUU1JTg1JUE1JUU3JUI3JUE4JTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1hZDY3YjYxYjI5NWU0MjE0NTM5Yzg5MzdhNDE5NWIxYQ%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBrYXpha2FnbyZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDdjMzBmYzdmNTg3OWY3MzQzMzZiODYyMjllYzZmMWM%26blend-x%3D120%26blend-y%3D445%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44Kk44Kw44OL44K5%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D134%26txt-y%3D546%26s%3D35da62a5356cdeadbdcd94bcc732dc79)
まだiOSアプリのArchitecture選定で消耗してるの？ - Qiita
去年はiOS Clean ArchitectureについてまだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて色々書いてみたのですが、MobileアプリのArchitectureは色々あって何を採択するか結構悩んでいるんじゃないかなと思います。 Clean Architecture自体も学習コストが高くて理解するまで時間がかかるので、色々あるArchitectureの中からどうゆう基準で採択するのが良いかまとめてみることにしました。 書こうと思ったきっかけは、以下に影響されていたりします。 今から新規でAndroidアプリを書き始めるなら。 今から新規でiOSアプリを書き始めるなら。2016年冬 iOSのArchitectureについてはiOSアプリ設計大全集 2016にまとまっているので、それ以外のことについて書きたいと思います。 Clean
iOSアプリ設計大全集 2016 - Qiita
iOS関係の勉強会に参加するとほぼ間違いなく、設計に関する発表があるように思います。 「RxSwiftを使ってMVVM...」「Clean Architectureを導入...」, etc... 色々話を聞く中で、自分は以下のような課題があるなぁと感じています。 いろいろな設計方法があるけれど、結局何を使うべきなのかわからない 名前は聞いたことがあるけれど、それぞれがどのような設計で、何がメリットなのかわからない 勉強した時は分かったような気がしたけれど、もう忘れた この記事はこれらの解決の一助になればと思って書いたものになります。（設計へのモチベーションを上げたい） サンプルコードを交えながら、5つの設計について考察してみます。 ※ RxSwiftの名前を出しましたが、ライブラリに関してはこの記事では言及しません。 そもそも、なぜ設計に拘る必要があるのか iOSアプリ開発において、このよ
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
さらに上を目指すための iOS アプリ設計
2015/05/13 ヤフー社内「中級 iOS アプリ開発者」向けに行った講義の資料。Read less
iOSアプリの設計でBaseViewControllerのようなのは作りたくない - Qiita
結論 小手先で楽をするためのボトムアップな設計は後々苦労する 継承を使った差分プログラミングは長年運用していくと大変だ 人は楽な方に流れるので、Baseクラスで解決すべきでない問題をBaseクラスで解決して後で困る はじめに この文章は2015年1月のpotatotips13で発表するネタ用のメモに書いてました。 実際に発表した内容を含む様子は下記のページにまとめています。 http://curiosity.co.jp/potatotips13/ 会場で質問されたりツイートの様子を見てて気づいたのですが、BaseViewControllerを使いたくないという"この文章"と同意の意見は、比較的経験のあるおじさんたちの意見であって、若い人からするとなぜBaseViewControllerを使ってはいけないように言われるのかについて具体例を聞きたがる傾向が強いです。 また、不必要に自分が気に入
APIのエラーハンドリングを見直そう - WebPay Engineering Blog
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
イミュータブルデータモデル(入門編)
6. Step1 エンティティの抽出 発送担当者が受注リストをもとに、商品の在庫を確認し、在庫が あれば商品を発送する。 ① 要求仕様の「動詞」を抜き出しエンティティとする。 ② ①に関わる「名詞」を抜き出しエンティティとする。 ③ エンティティ間の関連に線を引く ④ 属性や候補キーも分かる範囲で書いておきます。 間違い！ この段階で実装をプロパティファイルにするとか、Enum にするとか決め打ちでエンティティとして表さないのはや めましょう。 まず、はじめにエンティティを抽出します。
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
iPhone「アプリの設計パターン」についてまとめてみる - ゆーすけべー日記
iPhoneアプリの良いアイデアが出たので、これから作り始めようというところである。 さて、iPhoneアプリ開発童貞ってわけではないが、今までただ闇雲に作っていた感があるので、 実際にXcodeを起動してコードを書き始める前の設計をどうしていこうかと考えている。 ソフトウェアの作成はじめてではもちろん無いのでだいたい勝手は分かるものの、 iPhone特有の設計思考が必要な気がして、文献を漁っている。 ところが、世に出回っているiPhoneアプリ本にはUIKitをいじくるだけの解説ばかりではないか！ で、つまるところ設計について有益だと思えたのは以下3つの文献だった。 「iOSアプリケーションプログラミングガイド」Appleのサイトからダウンロードできる 「iPhoneアプリ設計の極意 - 思わずタップしたくなるアプリのデザイン」のfladdictさんの章 「iOS開発におけるパターンによ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース設計徹底指南