書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想とその検討停止について - Qiita
この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 23日目の記事です。 昨日の記事は弊チームの inductor による「GKEの内部負荷分散機能を使ってInternal Load Balancerを構築する」でした。面倒で困っているのでGCP様にはなんとかして欲しいものです さて本記事では、残念ながら本番運用には至らなかったのですが、私がここ暫くMLOps業の裏でやっていた「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想」の検討結果について供養のつもりで記そうと思います。 なお、今年は弊社では全部で5つのAdvent Calendarが公開されています。 ZOZOテクノロジーズ #1 Advent Calendar 2019 ZOZOテクノロジーズ #2 Advent Calendar 2019 ZOZOテクノロジーズ #3 Ad
クライアントとサーバーどちらに実装するかの設計指針をチームで持つこと - tomoima525's blog
モバイルアプリケーションを開発していると、この要件や仕様はクライアントとサーバーどちらに置くべきか、という議論がチームでなされることがしばしばあります。例えば、 あるレスポンスAを受けて処理Bを行い、その結果をユーザーに提示する 登録処理などで、処理C,処理Dという異なる処理を並列して行い、それらが完了したらユーザー側に通知する やろうと思えばクライアント側で処理を全て持つこともできますし、サーバー側で実装もできますね。 このような仕様のディスカッションが起きたとき、チームで統一した判断基準を持っていますか? 自分の場合、クライアントアプリはロジックをなるべくサーバーに移譲すべき という設計指針をチームに提案します。 上の例で言うならば、 サーバーから処理Bも踏まえたレスポンスA'を返してもらい、ユーザーに提示する クライアントは1リクエストをサーバーに投げる。サーバー側で処理C,Dを投げ
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
技術選択とアーキテクトの役割
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。
ITにおける発明的問題解決の理論 - 西尾泰和のはてなダイアリー
「発明的問題解決の理論」(TRIZ)という、発明を「ひらめき」に頼るのではなく「既存の発明を集めたデータベースから類似の問題とその解決方法を探すこと」で効率化しようという方法論がある。 簡単に説明すると、解決したい問題を「強度は増やしたいが重さは増やしたくない」などの「特性の矛盾」として表現する。そして既存の特許情報から同じ問題を解決しているものを探し、参考にするという仕組み。特性を39個に分類し、39x39のマトリクスから解決の典型的なパターン40個を調べる「矛盾マトリクス」などの補助システムがある。 しかし作られた時代が古いため(1946〜1969)、その後発展した情報技術に関する特性が不足している。ディスク容量や回線速度なんかが属性のリストにない。ディスク容量を「体積」に相当するとみなしていいのか？回線速度は何に相当するのか？？ そういうわけで既存の「解決手法」を「何と何の矛盾を解決
レイヤー越えが出来ない人たち - Nothing ventured, nothing gained.
物にはそれぞれの役割というものがある。 もちろん、本来の役割を超えて利用されることもある。可能性は無限大だ。 だが、ある物に固執し、本来ならば他の物で対応されるべきものまでをも無理に対応しようとすることは褒められたものではない。コンピューターシステムでは、そのような行為はコストを増大させることになったり、設計に無理を生じさせる。 spモードはなぜIPアドレスに頼らざるを得なかったか : 高木浩光＠自宅の日記 NTT DoCoMoのspモードでの障害は当初の予想よりも深刻な根本設計レベルの問題が原因であることが指摘されている。Web技術者にとって、IPアドレスとユーザーを結びつけるなどということはあり得ない。だが、NTT DoCoMoにとってはそうでもなかったらしい。 高木さんのブログでその背景などが推測されているが、今回の件だけではなく、NTT DoCoMoなどのキャリア系の人たちに共通す
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Azureテクノロジ入門 2016 目次 - 日経BP書店