在宅勤務のために買ったけどいらなかったものまとめ - Diary
在宅勤務のために買ったけどいらなかったものまとめ 「在宅勤務環境整備しました」とかいって金持ち自慢するのがこの 2 年間ずっと流行ってた感じしますよね、最悪です。 本日は在宅勤務環境整備のために買ってみていらなかったもの、ゴミだったものについて紹介していきます。 マルチディスプレイまわり全般 ぼくは家での作業は主に 24 インチ iMac を使っているんですが、ディスプレイ増やしてみるか〜みたいな感じで浪費をしはじめることがたまにあります。 それで買ったものは ディスプレイアーム https://www.amazon.co.jp/dp/B00MIBN16O/ LG の USB Type-C でつながる 4K ディスプレイ https://www.amazon.co.jp/dp/B09CYBJ31X/ iPad スタンド(こういうやつ https://www.amazon.co.jp/dp/
Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 - Diary
Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 Heroku を使うときに問題になるのは、データベースに何を使うかということです。 Heroku 標準の PostgreSQL Amazon RDS ClearDB (Heroku で MySQL を使えるアドオン) などが代表的な選択肢としてあります。ここで Heroku 公式が公開している RDS を使う方法についてのドキュメントを見ると、 RDS のインスタンスをインターネットに全公開して Heroku から接続せよと書かれています。 ネットワーク的な防壁がそろった環境が当然の現代においてこの方針はいかにも許容できないもののように思えます。しかし、ここで ClearDB と Heroku 標準の PostgreSQL について考えてみましょう。 まず ClearD
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる - Diary
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。 Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。 本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだい
見てるページを全部保存するという行ない - 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
Firebase 使ってみた 2018 - Diary
Firebase 使ってみた 2018 最近は技術についてはレイトマジョリティでいいなと思ってる。 Firebase はもう完全にやっていけるかんじっぽいのというのを各方面から聞いたので試してみた。 だいぶ前に Firebase を使ってみたとき、 Realtime Database のクセが強すぎてこれはあかんなという感じだった。今では Cloud Firestore があるので話が違うだろうと思いあらためて実用アプリを一個作ってみた。 前にクライアントサイドだけで実行して保存先は Google Drive という野蛮なメモツールを作ったことがあった。これのバックエンドを Google Drive から Firebase にしてみた。 元々のツールが Google Drive との接続部分を一つのファイルに切り出していたので、これをいじって Firebase に対応するだけでスッと作れた
Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる - Diary
Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる 個人的なアプリをつくるとき、だいたい以下のような環境で作業しています WAF は Echo go-bindata をつかって各種アセットを Go のソースにくみこみ webpack をつかって JavaScript をコンパイル にたような環境の人はおおいのでは。 Go のアプリのビルドと実行は fresh でやってます。みんなつかってるとおもいます。 webpack にかんしては --watch オプションをつかうことで、物事がおこなわれていきます。 ここで問題になるのが webpack がコンパイルしたものをいちいち go-bindata で処理しないといけないということです。これを手動でやるのはいかにもダサい。ということでいろいろかんがえたりしらべたりしたところ、 on
コマンドを Docker で配布するみたいな話あったけど俺は mutt を Docker で実行したかった - Diary
コマンドを Docker で配布するみたいな話あったけど俺は mutt を Docker で実行したかった のでやってみたのだがまあ大変にひどいかんじでとりあえずできた。 1. モチベーション いろんな設定ファイルをいれている dotfiles とかなんとかそんな名前のリポジトリがみなさんにもあるとおもうのですが、それを分割したいというのが当初のモチベーション。 2. 思いついた解決策 Dockerfile と muttrc を入れたプライベートリポジトリをつくって、それをビルドしたものを自分の private registry かなんかにぶっこんでおく シェルの設定ファイルで docker run hoge みたいなものを alias でサクっと実行できるようにしておく 3. 実際に行なわれたこと とりあえず mutt をいれたイメージをつくって実行してみたところ Docker の Ps
インフラエンジニアのいない会社で働いて 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 イメージはベースとアプリケーション固有部分が分離していて転送が最適化されるみたいな話はあるんですが、それはそうとして頻繁にベースごと吹き飛ばされるという環境で生活している人は多いのではないかと思う。 このような情勢のもとではいろいろ頑張って最適化したところでダメなときはダメだしみたいな話になってくる。 というわけでなのでこのへんあんまり神経質にやる必要はないと思う。普通に書けばまあ普通にある程度キャッシュされますよ以上のことを考えなくていいんじゃないかな。そういうところ神経質に気
AWS CodeBuild をちょっと触ってみた - Diary
AWS CodeBuild をちょっと触ってみた フルマネージドのビルドサービス という触れ込みで、実際まあその通りなんだけど、これはあくまでもビルドツールであって CI ツールではない。出来ることはビルドだけ。 なので Amazon Travis 的なサービスではない。 AWS CodePipeline や Lambda や API Gateway などと組合せることで一気通貫の CI 環境を構築することはもちろん可能だが、大抵の場合において Travis に金を払ったほうがいいと思う。 Jenkins おじさんならぬ AWS CodePipeline が発生してしまう。 ビルドタスクが大量にあり Travis なり Jenkins なりのレーンが頻繁に逼迫してる会社ならばこれらサービスを使ってやっていくコストをペイできることでしょう。 一方で個人が Github の Private リ
Docker Swarm Mode の話(タイトル変えた) - Diary
おもしろい話をしようと思ったのですが、 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 優
Docker swarm mode の構成をバックアップする - Diary
Docker swarm mode の構成をバックアップする スクリプトを書いた。 Ruby で書かれています。実行すると docker service create --name=lig -p 30007:26667 imagename docker service create --name=diary -p 30000:3000 --mount type=bind,source=/source/,target=/target diaryimage:v17 docker service create --name=mariadb -p 30023:3306 --mount type=bind,source=/mariadb,target=/var/lib/mysql --constraint=node.hostname==hostname mariadb:latest みたいな感じで出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker 1.13 はだめ - Diary