筑波大学で分散システムの話をしてきました - kuenishi's blog
また呼んでいただいたので、筑波大学の情報システム特別講義D（1/19, 20 - 20日4限）で話してきました。これは業界で川島さんに無茶振りをされた人が聴講に来た大学生を置き去りにして講師陣に実力を試されるという素敵なイベントです。発表に使ったスライドはこちらです。自分で論文読んで証明を考えながら作ったスライドなので曖昧なところや誤りがあれば指摘いただきたいです。 前回はデータベースの話をしました。 kuenishi.hatenadiary.jp 今回は、転職もしたし、NoSQLブーム的なのも一通り終わったのでもうデータベースの話でもねーだろってことで、分散システムの理論面に入門した内容になっています。分散システムの理論面は20世紀に一通り出揃ってしまって、21世紀の最初の15年は実装と運用の時代でした。具体的には、理論と実装のギャップをどう埋めるかという研究や試行錯誤が盛んで、理論それ
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
「もっと早く知っていれば...」とならないための、開発効率を最大化するライブラリとの向き合い方・探し方・使い方 - Qiita
「もっと早く知っていれば...」とならないための、開発効率を最大化するライブラリとの向き合い方・探し方・使い方AndroidiOS初心者ライブラリ新人プログラマ応援 株式会社LITALICO でエンジニアをやっています、@kentya6です。 『LITALICO Advent Calendar 2016』22日目の記事となります。 前回、スクリーンショット拡張Macアプリ「Fuwari」を作って公開しましたという記事を書きましたが、このアプリを開発するにあたって多くのライブラリを使用しました。これらのライブラリを利用しなければ、短期間でのアプリ開発は実現できなかったと思います。 今回は、こういったライブラリを利用してより短期間でアプリケーションを作るために抑えておきたい、ライブラリとの向き合い方や探し方、使い方の話をしたいと思います。 はじめに ライブラリとは、ある機能を様々なプログラムに
実録!!データ構造リファクタリング -- 僕とメッセージ機能の300日戦争 - Qiita
みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。 さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の
REST APIの設計で消耗している感じたときのgRPC入門 - Qiita
REST APIによる設計 最近のシステムは様々なデバイスやスケーラビリティを重視するため、各システムを分割し軽量なAPIで連携するマイクロサービス的なアーキテクチャスタイルが増えてきています。 そして、そのAPI連携で広く採用されているのが、REST APIです。 しかし、こうした設計を行っていくには、適切に考慮、選択しなければならないことも多くあります。 URL、パラメータ、エラーなどの設計 各言語ごとのライブラリや、サーバ、クライアントの選定、設計 認証、認可 ドキュメント管理 ユニットテスト、インテグレーションテスト、モック、Consumer-Driven Contracts 開発用ツール 絶対的スタンダードがない状況下で、こういった問題はシステムやメンバーが増えるにつれ複雑化していき、設計や管理、その仕組み作りに時間を取られ、本来の目的となるべき機能開発の時間を失っていくことにな
Clean ArchitectureでAPI Serverを構築してみる - Qiita
この記事では、アーキテクチャを採用する理由、次にClean Architectureの概要、最後にアプリケーションの構築をしていきます。 この後詳しく見ていきますが、Clean architectureの概念は比較的シンプルでわかりやすいものだと思います。しかし実際コードに落とし込んだ時、これってどう実装すればいいのかな？と迷うことがあったので、自分の理解も深めるために実際にAPI Serverを構築していきたいと思います。 また、サーバーサイドでの採用事例をあまりみないので誰かの参考になればいいかなと思います。 サンプルコードは、Go言語です。 アーキテクチャを採用する理由 アーキテクチャに期待することは、関心の分離です。 関心の分離を正しく行うことで、次のようなメリットがあると思います。 再利用性の高い設計になり生産性が向上する コードの可読性が上がり、メンテナンスが容易になる 変化に
ヤフーの社内システムを紹介します
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。情報システム本部の伊藤（@koh110）です。 社内システムの開発、運用を担当しています。 弊社は10月に本社を東京ミッドタウンからガーデンテラス紀尾井町へ移転しました。 情報システム本部では本社移転に合わせ4つの社内システムをリリースしました。 今日はこちらのシステムについて紹介をさせていただこうと思います。 社内位置情報システム（pozzy） このシステムは社内のWi-Fiにつながっている端末を検出し、人の位置情報を検索できるようにします。 ヤフーでは全社員にPCとiPhoneを貸与しています。これらの端末は各端末に発行された証明書によって社内のWi-Fiに自動で接続されるように設定されています。 この情報を利用し
業務系Webアプリケーションシステムの画面設計のしかた - Qiita
どのシステム開発でも画面設計は非常に大切です。 画面設計時に良し悪しが決まってしまうことが多々あります。何故かというと画面というのは視覚的に見ることが可能なため、目に見えないプログラム実装に比べて人は評価しやすいのです。 今回は私なりの画面設計のしかたをまとめたいと思います。タイトルには「業務系Webアプリケーションシステム」と記述しましたが、仕事上こちらの開発が多いためこのように記述しました。 また業務系システムの画面設計関連の記事をあまり見かけたことがないため、今後、業務系システムの画面設計を行う方にとっての参考になればと思います。 1. 様々な業務システムのレイアウトを知る まず、作り始める前に業務システムのデザインをストックします。業務システムを調べてみるとたくさんの画面デザインを見ることができるため、こんな画面にしたいというイメージを膨らませます。 また検索時にヒットする画面たち
新しめのCSS設計まとめ 〜2016年冬〜 - Qiita
最近新たに色々なCSSの設計が提唱されているので、学習を兼ねて簡単にまとめました。 どれも実際に実践してないものばかりなので、表面を舐めたいなくらいの気持ちで読んでください。 ググればもっと詳しく解説してくれている良記事があります。 以降のCSS設計へ影響を及ぼした３大アーキテクチャ 派生したCSSの設計たちは、ほぼこれらの考え方に影響を受けている。 はじめに簡単におさらい。 OOCSS 米Yahoo!のNicole Sulivan氏提唱。 構造と見た目を切り分けて考える。オブジェクト指向型CSS。 .box { width: 100px; height: 100px; } .box-red { background-color: red; } .box-blue { background-color: blue; }
APIファースト開発勉強会に参加してきた - Qiita
11/5に @kantomi さん主催の勉強会に参加してきたので, 得られた知見などをメモしておきます. 個人的にはたいへん有意義な勉強会でありがとうございました. 機会があればまた参加したいと思います. 概要 UI, APIから設計開発をスタートする"APIファースト開発"によってDB設計の確定を後回しにし, DB設計変更による手戻り(=炎上)を防ごう. ビジネスロジックはSQLで書こう. RDBMSはいろんなことを考慮して実行計画を考えてくれる. O/Rマッパー逝ってよし. SQLで書けるかどうかはまずExcelで書いてみて考えよう. ExcelでできればSQLでできる. APIファースト開発のメリット プロジェクトが炎上してデスマに陥るのは, ひとえに"DB設計"に手戻りが発生するからである. 逆にUIとかの変更であれば, デザイナは大変だが炎上・デスマにはならない. DB設計が変更
RestfulApiの設計書 - Qiita
{ "message" : "Validation failed", "errors" : { "identify" : [ "The identify is invalid format", "The identify is too long", ], "password" : [ "The password is required", ], } } 3.柔軟性 httpパラメータで取得するパラメーターの制限、絞り込み、並び順を指定可能にしよう。カンマ区切りで複数条件可能！ * fields : 取得したいパラメーター * getNumber : ページ数 * pageSize : 1ページの件数 * sort : 並び替え * q : 文字列の部分検索 例：/companies/:companyId?fields=data&q=サンプル&sort=id,name 注釈：頻繁に使用する条
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをまとめた章を用意したので、チェックポイントだけ知りたい方は最後だけ見ていただければと思います。 DB論理設計の流れ DB論理設計は以下のようなステップで進めていきます。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 以下では各ステップごとに章を
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動設計で、モデリングをどうやっているか、それをどう実装に結びつけているかの事例紹介。 RDRA+ICONXをベースに、より機敏なやり方への挑戦。実践的なオブジェクト指向設計。Read less
綺麗な設計を身に付けるためのSandi Metzルール
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。 Sandi Metz’ rules for developers このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。 そのルールは以下の通りです。 クラス内のコードが100行を超えてはならない メソッド内のコードが5行を超えてはならない 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす） コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる ビューは1つのイン
機械学習で泣かないためのコード設計
【第40回AIセミナー】 「説明できるAI 〜AIはブラックボックスなのか？〜」 https://www.airc.aist.go.jp/seminar_detail/seminar_040.html 【講演タイトル】 機械学習モデルの判断根拠の説明 【講演概要】 本講演では、機械学習モデルの判断根拠を提示するための説明法について紹介する。高精度な認識・識別が可能な機械学習モデルは一般に非常に複雑な構造をしており、どのような基準で判断が下されているかを人間が窺い知ることは困難である。このようなモデルのブラックボックス性を解消するために、近年様々なモデルの説明法が研究・提案されてきている。本講演ではこれら近年の代表的な説明法について紹介する。 本スライドは、弊社の梅本により弊社内の技術勉強会で使用されたものです。 近年注目を集めるアーキテクチャーである「Transformer」の解説スライド
マイクロにしすぎた結果がこれだよ！
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirect Notice
RDBアンチパターン // Speaker Deck
リアルタイム通信をささえるブラナイのサーバー開発と運用（前編）
