Fastly のログイン画面をどうにかしてほしいという話 複数の Fastly アカウントにまたがって構築されいるシステムのメンテナンスという作業をしていて、気付いたらかなり体調が悪化してて、激しい頭痛と吐き気の襲われた。というのも、ログアウト => ログインを何度も何度も繰り返すことになるから↑の画面を何度も何度も何度も何度もみていたわけだ。 これを 30 インチのディスプレイに全画面でドカーンと出していたので、これはつまりポケモンショック同様の症状ということだと思う。 自分がそういう状態になっていると気付いてからは、以下の user.css を書いて回避した(user.css の適用にはこの拡張を使っている)。しかしまあ一度崩れた体調は今に至るまで回復していない。 section.authentication{ background-color:darkred; } Fastly は実

ママチャリ問題 ママチャリで画像検索するとこう ママチャリ 電動 だとこう ここで問題となるのが、電動のほうででてくるこれが「ママチャリ」という共通認識を得られているのか？ということです。このタイプの小径、低重心、長ホイールベースの自転車、今東京の子育て世代の多くの人が乗っていて、東京では本当にこれを頻繁に見ます。しかし東京以外の都市でこれが氾濫している印象はありません。 ではメーカーがこれを何と呼んでいるかについてですが、 パナソニックは「子乗せ」です。 ママチャリという用語は性やその役割についての現代の認識からするとアナクロであるので使っていないのかなとも思いますが「ママ」ともありまあママが使うこと前提でいろいろ謎です。単に「これはママチャリではないよな」と思っただけかもしれない。 ブリジストンは「子ども乗せ 電動アシスト自転車」です。 ブリジストンはあきらかに男女平等に配慮しています

Firebase でバックエンドエンジニアがいらなくなるは正しくない と思っている。 用語定義が曖昧だが、「バックエンドエンジニア」という言葉でなんとなく想像されるものとしては、 Rails とか Laravel とかでデータベースに CRUD する Web アプリケーションを書ける人を指すと思う。違いますかね。そんなに違ってないと思うが。 Firebase でこれらの知識をもつ人が不要か?というとある程度の規模、機能を持つアプリを作ろうと思うとこれは必須になる。 Firebase のデータベースは機能が少なく(とはいえ Firestore はわりと「これで十分じゃん」ではあるが)、なにか複雑なことをしようとすると、すぐに Cloud Functions という機能に頼ることになる。 Cloud Functions はようするに Firebase の Lambda + API Gatewa

日報 2005 年分はとりあえず全部読んだ その結果の感想としては、やはり https://diary.app.ssig33.com/349 で書いたような事態である可能性は高いと思う。 不審なバナナ売り pic.twitter.com/iI0UZ8aGE2 — 小池 陸 "病気のエビ" (@ssig33) April 16, 2018 やっぱこれ公式に残してたものじゃないんだろうなあ、、、こういう書き込みからするに pic.twitter.com/A4BD1aHtUU — 小池 陸 "病気のエビ" (@ssig33) April 16, 2018 のように受け取った人がメモを書き込んだ形跡が多々あるので。 あと思うのが、この日報はいったいどのように活用することを前提に作っていたのか？これを毎日読んだところでイラクの政治情勢にかんする現地の軍人のいまいち信用できない情勢判断ぐらいしか結局頭

見てるページを全部保存するという行ない をもうずっとしていて、以下のような user.js でページを全部保存してます。 // ==UserScript== // @name 見たサイト全部保存 // @namespace http://tampermonkey.net/ // @version 0.1 // @author You // @match http://*/* // @match https://*/* // @grant GM_xmlhttpRequest // @noframes // ==/UserScript== if(!!document.querySelector('title')){ const title = document.querySelector("title").textContent; const url = location.href; GM_x

全部クライアントサイド JavaScript で実装されててメモは Google Drive に保存される Markdown メモツール作った。 https://memopad.ssig33.com/ 以前から自分専用に使ってたメモツールがあったのだが、これにつかってた MySQL が落ちて、その MySQL の復帰のしかたはメモツールにしか書いてなかったみたいな頓知みたいな事態が起きてキレて作った。 バックエンドを自前のサーバーからクライアントサイド向けの Google の API Library に置き換えるだけなのでわりとシュッと出来てよかった。 React のおかげで本当にこういうのはめちゃくちゃ簡単になった。 HTML と JS は S3+Cloudfront でデプロイしている。これでやってる。 サイトの説明にも書いてるけど、あらゆる機能がクライアントで動くように実装されている

クレジットカード決済の実装 、一番いいのは Amazon Payment Paypal みたいに完全に外部のサービスとして構築されていてそこにリダイレクトして処理が行われるものを使うことだろう。 ただ Amazon アカウントもってないだとか Paypal アカウント持ってないだとかいう人は結構多いし、 B2B 系だとさらにいろいろ面倒は増すと思う。国内だと GMO ペイメントがアカウントなしで GMO 側のドメインで決済できるものを提供していたと思うが使ったことないのでよく知らない。こういうタイプは最も望ましい、と思う。 まあ他にもそういうリンク型みたいのいろいろあるだろ。専門じゃないからよく知らん。 非通過型決済とでもいうのか、クライアントサイドで決済を行なって決済事業者としかクレカ情報をやり取りしないタイプの決済サービスが最近は出てきている。 Stripe がそういうのだと代表的なの

おもしろい話をしようと思ったのですが、 15 分しかないので素早くやっていきます 結論 今すぐ Docker ベースで HA 環境を作らないといけない use Kubernetes ベンチャー企業でインフラのコストを低減させたい AWS や GCP が配ってるクーポンは無視して Heroku 使うべき デプロイが趣味の人 この場で Docker Swarm Mode を使いはじめるべき それ以外の人 Docker Swarm Mode にのんびり注目してみるといいです、全てが変わる可能性を持っている Kubernetes と比較した時に Docker Swarm mode が優れている点 Kubernetes の基本的な構成 引用元: kubernetesによるDockerコンテナ管理入門 - さくらのナレッジ Docker Swarm Mode の基本的な構成 図作成: ssig33 優