Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 - Diary
Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 Heroku を使うときに問題になるのは、データベースに何を使うかということです。 Heroku 標準の PostgreSQL Amazon RDS ClearDB (Heroku で MySQL を使えるアドオン) などが代表的な選択肢としてあります。ここで Heroku 公式が公開している RDS を使う方法についてのドキュメントを見ると、 RDS のインスタンスをインターネットに全公開して Heroku から接続せよと書かれています。 ネットワーク的な防壁がそろった環境が当然の現代においてこの方針はいかにも許容できないもののように思えます。しかし、ここで ClearDB と Heroku 標準の PostgreSQL について考えてみましょう。 まず ClearD
PDF を Gyazo に展開して Scrapbox の記事にして全文検索する - Diary
PDF を Gyazo に展開して Scrapbox の記事にして全文検索する という試みについてです。 まず PDF を Gyazo に展開して Scrapbox の記事にするということですが、これについてブラウザ上で簡単に動くツールを実装しました。 https://ssig33.github.io/pdftoscrapbox/ おそろしく素朴な見た目ですがとりあえず動きます。Chrome や Edge に Tamper Monkey (試してないけど Firefox と Greasemonkey でも動くんじゃないかな)を入れて、 input に Scrapbox のプロジェクト名を入れて user.js をインストールした上で赤いところに PDFをドラッグ&ドロップすると、 PDF.js で PDF でレンダリングした上で全てのページを Gyazo にアップロードして Scrapbo
cookpad TechConf 2019 にいってきた - Diary
cookpad TechConf 2019 にいってきた 面白かった、参考になったトーク スライドとかは Qiita に cookpad がまとめを作っています。 藤井 謙士朗 - 新規サービス開発を加速させる技術とデザイン このサービスについて、エンジニア視点で書かれた紹介記事はあって Firebaseでバックエンドエンジニア不在のアプリ開発 クックパッドが体感した、メリットと課題 これは結構面白い記事で、レスとしてこんなものを書いたりした。 KomercoではReactでWebの管理画面やティザー画面を作っていて、デザイナーがコードを書いているので、フロントエンジニアもいないんです と何事もないかのように書かれているところに実際何があるかをデザイナーが何をしているかというのをデザイナー視点で話していた。紹介されているツールや技法は非常に興味深い一方で、 これ簡単にまとめると、プログラミ
アル中は死ぬ病気です - Diary
治療受けて 1 年で 3 割ぐらい死にます。 5 年だと半分近く死にます。糖尿病、肝臓病、精神状態の悪化による自殺、酔いによる事故死などさまざまな死因があります。 アル中は否認する病気です 「自分が決してアル中であることを認めない」というのもアル中の症状です。「山口容疑者は自分がアル中であることを認めろ」などと責めてもなににもなりません。 アル中の治療とは断酒です アル中による急性の諸症状が落ち着かせたらあとはひたすら酒を飲まないように指導するのが治療です。一度アル中になった人が治療の結果酒との適切な付き合い方を回復できるということはありません。 むしろ一度断酒した人が再度飲酒を開始した場合治療開始以前よりも激しい依存症になりそのまま死亡することが多いです。 たとえばほんのちょっと、一滴飲まされた というのから 3 ヶ月で車に飛び込んだだかぼーっとしてて轢かれただかで死んだ人を見たことがあ
見てるページを全部保存するという行ない - Diary
見てるページを全部保存するという行ない をもうずっとしていて、以下のような 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 メモツール作った。 - Diary
全部クライアントサイド JavaScript で実装されててメモは Google Drive に保存される Markdown メモツール作った。 https://memopad.ssig33.com/ 以前から自分専用に使ってたメモツールがあったのだが、これにつかってた MySQL が落ちて、その MySQL の復帰のしかたはメモツールにしか書いてなかったみたいな頓知みたいな事態が起きてキレて作った。 バックエンドを自前のサーバーからクライアントサイド向けの Google の API Library に置き換えるだけなのでわりとシュッと出来てよかった。 React のおかげで本当にこういうのはめちゃくちゃ簡単になった。 HTML と JS は S3+Cloudfront でデプロイしている。これでやってる。 サイトの説明にも書いてるけど、あらゆる機能がクライアントで動くように実装されている
OSS 版 Fastladder で LDR と全く同じインターフェイスでフィード読む - Diary
OSS 版 Fastladder で LDR と全く同じインターフェイスでフィード読む というようなことをやっていきたい人がいると思います。 1. さくら VPS 契約する 1,706円/月 のメモリ 2GB プランがいいと思います。ストレージは SSD じゃなくて HDD にしときましょう。 2. 環境のセットアップ 面倒がすくないと思うので、標準 OS の CentOS 7 でサーバーを起動してください。このへんよくわからん人はさくらのマニュアルみて。 3. Docker のインストール root ユーザーか sudo 実行できるユーザーで以下を実行してください。 SSH とか分かんない人はあきらめるか調べろ！！！ # curl -fsSL get.docker.com -o get-docker.sh # sh get-docker.sh # service docker start
Github の Project 機能いつのまにかにかなり便利になっていて - Diary
Github の Project 機能いつのまにかにかなり便利になっていて 、まずリポジトリごとだけではなくて、オーガナイゼーションに Project を作れるようになっている。あれを最初みた人はだれでも複数リポジトリを跨げるようにしないと問題にならない、と思ったはずだがそれは実現した。 また Project 上で作成したふせんを issue に変換できるようになっている。また変化する際にどのリポジトリの issue にするかを選択できる。 結果として、 Project の画面上であーでもないこーでもないみたいな感じでタスクを洗い出し計画をたてる それを各リポジトリの issue にしてそこに詳細を書いてしかるべき人物にアサインする 以後は Project の画面上で複数のリポジトリにまたがったプロジェクトの状況を一覧、管理する ということができるようになった。多くの組織でこれは実用品にな
Web 系プログラマーの教育の問題だけど 基礎的な HTML/CSS の部分を覚えるのはプログラミングの学習「以前」にやっといてもらわないとどうにもならん。それも出来てない「初学者」を相手にしても多分どうにもならないです。何故なら目的に応じた HTML/CSS をなんとか書けるようになるかというところである程度スクリーニングされるから。 - Diary
Web 系プログラマーの教育の問題だけど 基礎的な HTML/CSS の部分を覚えるのはプログラミングの学習「以前」にやっといてもらわないとどうにもならん。それも出来てない「初学者」を相手にしても多分どうにもならないです。何故なら目的に応じた HTML/CSS をなんとか書けるようになるかというところである程度スクリーニングされるから。 ですが現実問題としていちいち自分で Web サイトを作ったりブログのテーマを自作したりする若者は着実に減っています。よって HTML/CSS の基礎がない人間を相手にしなければならないと言える。大企業であればこうした問題に対処ができる。教育工程を充実させられるというのもあるが、やってみて駄目だった人を別の部署にまわす余裕があるという話でもある。 ではどうすればいいかというと、諦めて Web は全然金と手間かけない方針でやるとか、出来る人を高い金でもってくる
UPQ 問題に関連して思い出したこと - Diary
UPQ 問題に関連して思い出したこと なんだけど、 ODM/OEM の多用による日本企業の空洞化が進んでいる分野というのは何も IT 業界や家電業界に限らなくて、ファッション業界もこれがすごい。というかこっちのほうが中国における産業の立ち上がりが早かったりもともと調達前提のビジネスモデルが発達していた分エレクトロニクス関連よりも状況が酷いかもしれん。 なんでもいいから適当な郊外型ショッピングモール 2,3 個を回ってみればいいのだが、特に区別もつけられないようなどうでもいい店が沢山あって、しかもどのショッピングモールに行ってもかならずほとんど同じような店が同じように入居している。 ではそういう店はいわゆるセレクトショップなのか?というと自前のブランドの商品を売っている。あれはなんなのかという、中国のファッション企業に「ブランドを一個お願いします」という形で発注するとブランドイメージを中国の
インフラエンジニアのいない会社で働いて 1 年半 - Diary
インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。 本当に自分達でなにもサーバーを管理してい
Docker イメージの最適化問題 - Diary
Docker イメージの最適化問題 前提 1. 実行環境は頻繁に捨てられる オートスケールでの増減 CodeBuild 使う場合とか サーバーの故障、不具合 ぼくが使ってるゴミクラウドみたいなやつではすっげー頻繁におきてる 前提 2. 面倒なことはしたくない そりゃまあね。 すると？ 綺麗に作られた Docker イメージはベースとアプリケーション固有部分が分離していて転送が最適化されるみたいな話はあるんですが、それはそうとして頻繁にベースごと吹き飛ばされるという環境で生活している人は多いのではないかと思う。 このような情勢のもとではいろいろ頑張って最適化したところでダメなときはダメだしみたいな話になってくる。 というわけでなのでこのへんあんまり神経質にやる必要はないと思う。普通に書けばまあ普通にある程度キャッシュされますよ以上のことを考えなくていいんじゃないかな。そういうところ神経質に気
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
タイでは服喪のためにウェブサイトが白黒になっている - Diary