隊長、Androidアプリのソースがぐちゃぐちゃであります！！ - Qiita
複数の責務をFragmentやActivityに押し込めてるのが原因です。 公式サイトに書いてあるようなこともありますが、今一度まとめてみました。 -- Activityの長さが10000行を超えました！！とても保守できません！！隊長！！ 初期のAndroid開発は手探りでした。Activity、Intent等、大きな枠組みでは優れてましたが、その上の層に関してはノータッチでした。 皆Activityが単位として大きすぎるのは理解してましたが、多くの人はActivityにコードを詰め込む道を選びました。フレームワークを 使う ことに慣れすぎて、 作る ことには不慣れだったのです。 とはいえ、そんなコードはすぐ破綻します。それではまずいということで、GUIフレームワークの知見のある人達は、各々、オレオレフレームワークを内部で抱え込むことになりました。暗黒時代です。 しばらくして、開発が追いつ
DB 設計時のサイズ見積り[最新版] - Qiita
こんにちは、すっかり秋ですね！@yone098 です。 みなさんDBの設計してますか？ DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5
![DB 設計時のサイズ見積り[最新版] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f42e24e40ddeea81bc76c98ccc1f982252cd6b3c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9REIlMjAlRTglQTglQUQlRTglQTglODglRTYlOTklODIlRTMlODElQUUlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTglQTYlOEIlRTclQTklOEQlRTMlODIlOEElNUIlRTYlOUMlODAlRTYlOTYlQjAlRTclODklODglNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWM5ZmIwOTA1Y2UwNjU4NDA0MzRmOTZlMmI2NDFlMGU1%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b25lMDk4JTQwZ2l0aHViJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iZDkzOTdmMGQ3NWNhMGM4M2I3NmMxNjM4ODQ2OWQxMA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-QWJieQ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D6f836c4a275f61471b9e3f73ef123bda)
アプリのUI設計は「紙でやる」のが早い！ - Qiita
はじめに こんにちはー！！ UI設計やってますか？ 今回は「ペーパープロトタイピング」の話。 アプリでは主流になってる現場も少なくないですよね！ 今までのやり方とペーパープロトタイピングの違いや、 プロトタイピングツール「POP」と「Prott」の比較の話なんかをしようと思います！ 今までのアプリUI設計 Webデザインと同じ方法でアプリ設計を行っている場合、手順は ●ワイヤフレーム→モックアップ→実装 厳密に言うと ●①ヒアリング→②ワイヤフレーム→③レビュー→④モックアップ→⑤レビュー→⑥実装→⑦レビュー デザイナーがいないと ●①ヒアリング→②ExcelでUI設計→③レビュー→④実装→⑤レビュー って場合も結構多いと思います。 これ結構時間かかりますよね～。 しかも！ 大抵の場合、実装後のレビューの段階（つまり最終段階）で 「やっぱここ動きおかしいよね！直せる？」 「・・・。（えー！
設計書からソースコードを自動的に生成することの何がいけないのか
某SIerの「設計書からソースコードを自動的に生成するソリューション」について、エンジニアの間でブーイングの声が広まってる感があったので、ちょっと前に考えたことを書いてみる。 設計書からソースコードを自動生成することの何がイケてないのか。 それは、どんな設計書なら自動的にソースコードを生成出来るのか？ということに尽きる。 ソースコードを生成するということは、結局は変換をするということである。機械的に自動生成が出来るためには、ソースコードに変換するための情報が設計書と自動生成ツールの中に全て揃っていなくてはいけない。つまり、完全に動くソースコードに変換できるような情報をすべて設計書に書かなくてはいけないということを意味するのだ。実行可能な設計書と言ってもいいだろう。 かつての UMLモデリングツールなども MDD(Model Driven Development: モデル駆動設計)を称して、
ITの常識は世間の非常識：日経ビジネスオンライン
少し前、ある大手企業の情報システム責任者を長年務めてこられた方にお目にかかる機会があった。初めのうちは雑談していたのだが、最後は「経営トップのIT（情報技術）理解」という話題になってしまった。 「経営トップがITを分かっているかどうか、それが問題だとコラムや記事をお書きになっていますね。私も長年、分かってもらおうといろいろ取り組んできましたが正直、無理かなあというのが最近の実感ですね」 「御社のビジネスはコンピューターがないと成立しないでしょう」 「よくITは経営戦略そのもの、と言いますね。当社の場合、戦略と一体かどうかは分かりませんが、コンピューターが止まってしまったら、当社が潰れることだけは間違いありません。戦略というより、もはや生命線と言っていい。これほど重要なことなのに、経営トップの理解は残念ながらいま一つです」 100億円投じたのに期限までに完成しない 「コンピューターの機械は、
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
アジャイル手法が設計技法にも浸透しつつある - プログラマの思索
平鍋さんの記事「データモデリングなきアジャイル開発は危ういか？：An Agile Way：ITmedia オルタナティブ・ブログ」がとても分かりやすかったのでメモ。 【元ネタ】 データモデリングなきアジャイル開発は危ういか？：An Agile Way：ITmedia オルタナティブ・ブログ Twitter / akipii: とても良い記事。昔ながらの設計技法が古くなっている事実を認識すべき RT @hiranabe: 渡辺さん稲見さんへ返信ブログ書きました。「データモデリングなきアジャイル開発は危ういか？」 http://bit.ly/UsO1aA Twitter / yusuke_arclamp: アーキテクチャ設計の生成パターンは良いのがないんだよね。結局、プロトや繰り返し開発のようにプロジェクトマネジメントでリスク回避的に選択するのがベストプラクティスになってて。 Twitter
「データモデルなきアジャイル」の危うさ - 設計者の発言
例によってこれは「業務システム」に関する議論である。ゲームソフトでも組込み系でもＢ２Ｃサイトでもサービス系でもなく、販売管理システムや生産管理システムといった基幹系業務支援システム（ＤＢ構造が複雑なシステムといってもいい）に限った話だ。その種のシステムをアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 ＤＢ構造のそういった特性を公知させたのが、前回記事で説明した「ＤＯＡ（データ中心アプローチ）」だった。機能のあり方を確立したうえでデータのあ
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
クックパッド流UIの作り方 - takeshi nagayama's blog
なんか突然東京行きたくなったので、ひょひょいと行ってきた。 たまたま立ち寄ったクックパッドっていう会社でクックパッド流UIの作り方という勉強会してたので、偶然持ち合わせていたはてなステッカー渡したりおいしい料理いただいたりした。 UI/UXのためのSass 池田さん / サービスデザイン部 Sass / Haml (エンジニア・デザイナー問わずに) Github デザイナーもpull req 一つのサービスを複数チームで開発 各デバイスで速いサイクルでの開発 Sassとは → ぐぐれ 全体のデザインを束ねる → デザインガイドライン ガイドライン Sassで統一的なものを提供する 画像を使わずにCSSでデザインするメリット mixinをつかって統一できる 画像編集がいらない プロパティの変更によってデザインに幅をもたせる事ができる mixinの中身は応用がきくような仕組みにしておく 検証を
RESTful Web アプリの設計レビューの話
1. RESTful Web アプリの 設計レビューの話 和田 卓人 (a.k.a id:t-wada or @t_wada) July 23, 2012 @ sendagaya.rb 3. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社 取締役社長 4. 私と REST (input) • WEB+DB PRESS vol.32「REST アーキテクチャスタイル入門」 • はてぶ設計議論 • DHH の RubyKaigi 2006 Keynote • WEB+DB PRESS vol.38∼「REST レシピ」 • 『RESTful Web Service』
サロゲートキーは後付けでもできる。 - SQLer 生島勘富 のブログ
業務システムのほとんどはナチュラルキーで構築されていると思います。 しかし、シノニムやトリガーを利用すれば、既存システムを変更することなくサロゲートキーを追加して、それ以降、サロゲートキーによる運用も可能になります。手順は以下の通りです。 元のテーブル 以下の３つのテーブルをサロゲートキーによる運用に変更します。 ■ Foods 料理マスタ 物理名論理名備考 CD料理CD主キー Name名前 Price価格 …… ■ Ingredients 材料マスタ 物理名論理名備考 CD材料CD主キー Name名前 Cost_Price材料費 …… ■ Recipes レシピマスタ 物理名論理名備考 Food_CD料理CD主キー（複合） Ingredient_CD材料CD主キー（複合） Quantity使用量 …… IDカラムを付加する。 現在のテーブル名にIDを採番したシノニムを作成し、全部のテーブ
主キーのナチュラル⇔サロゲート問題 - b6note
についてひとこといっておくか、みたいな。 複合主キーを避けるべき理由 http://d.hatena.ne.jp/torazuka/20110713/pk 今回これを書きながら、色々考える機会になりました。 ありがとうございました＞id:torazuka さん 自分のぶこめ http://b.hatena.ne.jp/akitsukada/20110715#bookmark-50842882 複合主キー、ここでいう「ナチュラルキー」は論理設計とか分析モデルのときにデータの意味をはっきりさせるために抽出し、物理設計/実装段階で物理的制約や要件に応じてサロゲートキーをつければいいと思うと書いたんだけど、何しろ100文字ではちょっと足りないので もうちょっと自分の考えを補足 わたしの考え まず自分の立場は、上記のブコメを展開して データモデリング、分析、論理設計の段階ではID（サロゲートキー）を
アーキテクトの審美眼
MS萩原さんのセッション。同名の書籍（元ネタはDBマガジンの同名の連載）が元になっていて、そのダイジェスト版＋最新の動向の補足、という形。とても示唆に富んでいるんだけど、抽象的な上に、1つ1つのトピックがめちゃめちゃ重たいので、きちんと理解しようとすると調べる量がとても多くなってしまう上に、そもそも理解しきるのが難しすぎる。とりあえずは現段階の自分の稚拙な理解をもとに、こんなことじゃないかなーと補足しながら書いていく。 アーキテクチャの原則アーキテクトにとっては、アーキテクチャの原則を理解することが重要。アーキテクチャの原則は、インフラなどが変化しても変わらず、クラウドでも通用する。 アーキテクチャ先行定義の原則アーキテクチャは先行定義せねばならぬ、という原則。アーキテクチャ設計を含むソフトウェア開発は、こんな風な流れになるはず。 モデリングとアーキテクチャ設計の双方のインプットとして、シ
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
Mockingbird has Shut Down
Mockingbird is no longer in operation. We’re hoping to open-source the code sometime in the near future. In the meantime, some simple alternatives, in a similar spirit to Mockingbird, are: Excalidraw: https://excalidraw.com TLDraw: https://www.tldraw.com If you need a more comprehensive mockup solution, you might want to check out the following: FigJam: https://www.figma.com/figjam/ MockFlow: http
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
draw.io
オブジェクト指向の設計と実装の学び方のコツ
[REST] 認証が必要な API を REST っぽく作るときのメモ - それはBooks
iPlotz: wireframing, mockups and prototyping for websites and applications