Streamlit設計方針: 効果的なアプリケーションの構築を考える
はじめに 初めまして。 都内IT企業で、データアルゴリズムチームのエンジニアをしております、Noraです。 機械学習やデータサイエンスプロジェクトに関わる際、デモプロダクトを作りたい状況は多いと思います。 その際、Streamlitという、PythonのみでWebアプリケーションを作成できるフレームワークが有用です。 今回の記事では、「運用保守が容易で開発コストを下げる」ディレクトリ設計方針を解説していきます。 「Streamlitプロジェクトの、最適なディレクトリ設計方針を考えたい」という、チームで開発しているエンジニアにおすすめの記事となっております！ こちらの記事内容は個人の経験がベースになっておりますので、未熟な点も多いかと思います。 ご意見あればコメントいただけますと幸いです🙆♀️ 🙆 では、ぜひご覧ください！ 設計の考え方 今回、ディレクトリ設計を考える上で、以下2つのポ
スキーマファースト開発のためのOpenAPI（Swagger）設計規約 | フューチャー技術ブログ
はじめまして。TIG DXユニット 1の亀井です。 はじめに みなさん、Swagger使ってますか？ Swaggerや周辺ツールについては 某先輩の記事 にて丁寧に解説されていますので、 本記事では実際にSwaggerのスキーマ定義を設計していく上で取り決めた規約について書いてみたいと思います。 前提私が在籍しているプロジェクトでは、REST APIは golang でフロントエンドを Vue.js + TypeScript で構築しています。 短期間・高品質での構築を実現するためにSwaggerを設計ドキュメントとしてだけではなく、コード自動生成やモックサーバーに活用させることで徹底したスキーマファーストな開発を行ってきました。 というわけで、今回は下記のツールを利用することを前提として規約を作成しています。 go-swagger: Goアプリケーションのハンドラ、リクエスト/レスポンス
【DB設計入門|ER図|MySQL】コンビニレシートから学ぶ！データモデリング手法 | Wedding Park CREATORS Blog
はじめに こんにちは、岩橋聡吾です。 今回は私が実務で行っているデータモデリング手法（実際手法とは名ばかりですが…）を紹介いたします。 データモデリングは、ご存知の通り、その後のシステム開発や拡張スピード、またシステム自身のパフォーマンスにも深く関わってきます。ここをどのように設計するかが開発プロジェクトを進める上で大きなカギになります。 なぜレシートなのか モデリングする上で、その対象となるサービス・システムのビジネスロジックや仕様を深く理解する必要があります。レシートの背景にある「物を買う」という行為は至極身近なものであり、誰しもがそのレシートが発行されるまでの流れを経験で知っています。またレシートは、その小さな紙の中に「店舗」や「商品」など、WEBサービスで馴染みがある概念も多く含まれており、訓練をする上で非常に手頃なものです（「コンビニ」なるフレーズは掴みに使わせていただきましたw
API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
【企業サイト構築用】WordPress設計ガイドライン - Qiita
備忘録を兼ねて、企業サイト構築時に決めている設計方針・インストールしているプラグイン・セキュリティ対策をそれぞれまとめました。セキュリティ対策の項目を除き、構築時の細かい設定やプログラム実装についての説明は省略しています。 （※）2018.01.13: セキュリティ対策について加筆・修正を行いました 概要 実装する際の方針として、WordPressと紐付ける必要のないファイルは、できるだけWordPressのファイル・フォルダと分けて構築する手法を採択しています。これはサイト全体をWordPress依存にさせたくない、ということが大きな理由です。 また、関係ないファイルをWordPress内で管理させることによって、お客様やHTMLに詳しくない編集者が不用意にファイルを更新してしまうことを防ぐ意味もあります。8年以上WordPressと付き合ってきましたが、以下の設計方針が最も最適だと考え
Androidのデザインパターンを考えてみた - もやもやエンジニア
一番最新のやつはこっち rei19.hatenablog.com 前提 新しいトライとしてAndroidを書き始めてだいたい半年くらいたったのですが、教科書通りにコードを書いていたもののAPIを呼ぶあたりの実装がどうにもしっくりこなくかったので、良い機会だと思い設計を見直す事にしました。 以下、めっちゃ参考にしたスライド。ありがたや。 iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い from Ken Morishita iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い ポイント 基本的にModelは死なない + 通知で変更を伝える役割を持つ ViewやVCでAPIを呼ぶのはユーザーの操作に影響されやすいからやめれ 作ってみた 以前、このポストでAtndのAPIを呼んで結果をListViewに表示してみるというのを勉強のア
Bootstrap と BEM を組み合わせた CSS 設計パターンについて考える | PSYENCE:MEDIA
前置き - CSS 設計が難しい件について 誤解を恐れずに言うならば、CSS は変数も関数も条件分岐もない、ある種ゆるふわな言語（仕様）といえます。そのためプログラミング言語のように記述ミス一つで全ての挙動が止まるなんてことはありませんし、いくら冗長に記述しようがブラウザ上での挙動に差異が生まれることも殆どありません。ちょっと嗜めばそれっぽいものが作れてしまうので、マークアップエンジニアのいない小規模体制の組織であれば、サーバーサイドエンジニアやデザイナーが片手間で習得して実装してしまうというのも珍しいことではないでしょう。それでも良かったのかもしれません。これまでは…。 片手間で学習した知識というのはなかなか体系化されないものです。CSS も御多分に漏れずプログラミングのテクノロジーは日進月歩なため、その時は最新だった技術が僅か一年も経たないうちに廃れてしまい、バッドノウハウ化してしまう
オブジェクト指向設計の４つの流派からドメイン駆動設計へ - プログラマの思索
先日の大阪DDD勉強会に刺激を受けて、「ユースケース駆動開発実践ガイド」と「オブジェクト開発の神髄」と「アジャイルソフトウェア開発の奥義」「実践UML」を読み直している。 ラフなメモ書き。 【元ネタ】 【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper vol2_20140309 · dddosaka/reading_ddd_report Wiki 【１】個人的には、オブジェクト指向設計という考え方は好き。 データモデリングはDB設計でも業務の設計でも必須だが、データだけではシステムは動かない。プログラムも作る必要があるけれど、DOAにこだわると、なぜかソースの自動生成に走ってしまうように思える。 オブジェクト指向設計は、アジャイル開発と相性がよい。 また、開発チームの構造解析にもオブジェクト指向設計
Java におけるコード進化パターン (Code Evolution Patterns in Java)
Java におけるコード進化パターン (Code Evolution Patterns in Java) asato shimotaki <asatohan at gmail.com> 最終更新日 : 2009/6/21 (2004/4/22 より) [...] For twenty years, I spent two or three hours a day looking at pairs of things -- buildings, tiles, stones, windows, carpets, figures, carvings of flowers, paths, seats, funiture, streets, paintings, fountains, doorways, arches, friezes -- comparing them, and asking my
インターフェイス指向設計
本書はインターフェイスを用いたソフトウェア設計の仕組みを解説する本です。ソリューションをインターフェイスのレベルにまで分解し、相互作用するインターフェイスを適切に実装して、しっかりとした構造を持つプログラムを作成する手法を学びます。インターフェイスの凝集度とは、継承の利点、リモートインターフェイスとの通信など、基礎となる知識から、開発プロセスについて、Web自動集約ツール、サービスレジストリなど、発展的な内容まで、「インターフェイスから考える設計」についてを包括的に学びます。 最初に完璧をめざすのではなく「まず動くものをつくる」というアジャイル開発手法でインターフェイス設計を学ぶ本書は、より信頼度の高いソフトウェアを開発したい技術者必携の一冊です。 監訳者まえがき はじめに I部 インターフェイスのすべて 1章 インターフェイスとは何か 1.1 ピザを注文するインターフェイス 1.1.1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースオブジェクトの命名規約 - Qiita
MySQLテーブル設計入門
IBM Developer