CtoCのニワトリとタマゴの問題を解決するためにやった5つのこと
初期のマーケットプレイスの立ち上げ方法シリーズの続編。 前回も話したようにフリマアプリのようなマーケットプレイスは出品者と購入者の両方が必要です。 ただし、最初のプラットフォームは、ほとんどのユーザーにとって、そこに参加するコストの方が、そこから得られる価値より高くなります。 つまり買い手がいないマーケットプレイスに登録して、商品を出品する手間(コスト)を払うユーザーなどいないという問題にぶち当たります。 なので、プラットフォームの最初の目標は、両方のユーザーを十分な数を集めて流動性を確保することです。 どちらが先か？ 冒頭の通り、マーケットプレイスは需要と供給においてどちらを先に獲得するのか？といったニワトリが先か、タマゴが先か問題に必ず直面します。 そしてほとんどの場合、初期の流動性の確保のために売り手(供給サイド)の構築から始めることになります。 これは初期の段階では、売り手側により
サマータイム実施は不可能である
3. 何故不可能なのか • 多くの情報システムが「時間」を基準に動作 • この情報システムがあまりにも多い • 政府・自治体の情報システムはもちろん 医療・交通運輸・金融・エネルギー・通信放送・防衛… の重要インフラシステムから 企業内の業務・財務・人事給与等のシステム、 家庭内のテレビ・エアコンなどの家電まで • これらの時間変更の工数が膨大 • 手動設定できるものは手間だがまだマシ • 自動設定するものこそ「正しく自動設定」されるか不明 • しかも特に24時間動作のシステムにおいて 夏時間実施前後で誤動作の可能性が高く要精査 理由が判明しても修正が不可能の場合多々あり 4. 大きな見積もり • 国・自治体や重要インフラ企業の 業務を支える情報システムの修正は 必要性の調査・予算見積と確保・ 設計・修正作業・テスト・実施まで 含めて4～5年は必要と思われる • 民間企業においても最低3年
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
保存しておくと便利！CSS Flexboxでよく使用するコードがまとめられたCSSのスニペット集 | コリス
ヘッダでロゴを左寄せにしたり、検索窓を右寄せにしたり、画像をページの中央に配置したり、ページ上のあらゆる要素を揃え整列させるFlexboxをベースにしたスタイルシートのスニペットを紹介します。 サイトやブログの全体で利用できるユーティリティのclassとして、保存しておくと便利なスニペット集です。 Speed up alignment in CSS with Flexbox utility classes by CodyHouse 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 CSSで面倒なのは要素を整列させること Flexbox以前 Flexboxで簡単に CSSで面倒なのは要素を整列させること CSSで面倒なのは、要素を整列させることでした。しかし、Flexboxが登場して、理にかなった方法で整列させることが可能になりまし
Web Workerによる並列処理をRxJSを用いて実装する - Qiita
import { Observable, from } from 'rxjs' import { bufferCount, mergeMap } from 'rxjs/operators' const enum InputType { InitialData, Direction, } interface InitialData { type: InputType.InitialData // 初期化のためのデータを追加 } interface Direction { type: InputData.Direction // 並列化する処理のためのデータを追加 } function start(initialData: InitialData, directions: Direction[], threads: number) { const chunkSize = Math.ceil(d
JPEG画像の最適化には85%の品質がいいらしいので画像の最適化プロセスを見直してみた
オリジナルはPhotoshopの「書き出し」で画質を100%にして書き出した画像です。画像によっては81%にしても目視では差がわからなかったので、それくらい下げちゃっても良さそうですけど、ざっくりとしたデフォルトとしては85%が良さそうです。91% → 85%の方が85% → 81%より圧縮率がいいんですね。 サンプル画像 上の表にある「sampleXX.jpg」の画像をまとめて圧縮したファイルを用意しました。ご参考までに以下からダウンロードどうぞ。 サンプル画像をまとめて圧縮したファイル（ZIP / 3.4MB） ちなみに、表で91%と81%になっているのはImageOptimで設定できるのが、なぜかその数値だったからです。90%、80%には設定できませんでした（v1.8.0）。 職場で作業するときのプロセスはだいたい以下のような感じです。 PhotoshopやAffinity Desi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
