iii threetreeslight

May 13, 2018

Generate SSL/TLS certificate with let's encrypt

gcpにはaws acmに該当するサービスがないので、証明書を作成しなければいけない。 そのため、Let’s encryptを利用した証明書発行を行う。 Let’s encryptとは https://letsencrypt.org/about/ Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG). 通信の安全を担保するためにも全ての通信がssl/tls ptorocolでの通信する必要がある。 そのためにも、free and automatedなCAっていうのが大事。それを提供しているのがlet’s encryptedという認識です。 let’s encryptによる証明書の発行にはshell accessとそうでない方法ががあり、shell accessを前提としたcertbot ACME clinetを使うと良いよということのようだ。 https://letsencrypt.org/getting-started/ We recommend that most people with shell access use the Certbot ACME client. It can automate certificate issuance and installation with no downtime. ... Read more

May 7, 2018

Publish blog on GCS

とりあえずある程度形ができたので、publishしていきたいと思う。 hosting static website on gcs とりあえずgcsでstatic site hosting出来るだろうと思ったら、あった。 https://cloud.google.com/storage/docs/hosting-static-website まずはdomainの所有権をgoogle search consoleから取得しなければいけないというところにgoogleっぽさを感じた。 AWS S3ではbucket作ってcnameで飛ばせば良いだけなのに対し、GCP上では結構違う domain nameを含むバケットの場合は、ドメインの所有権認証をする https://cloud.google.com/storage/docs/domain-name-verification#verification googleっぽい valueに c.storage.googleapis.com. を指定したCNAME DNS recordを作成する GCSはGCP内からのアクセスを前提としたストレージであり、public endpointが最初から提供されていないということかな? 公開endpointは c.storage.googleapis.com にアクセスするとproxyされるという妙 あとはgcs bucketを作って、コンテンツをuploadし、各ファイルにread権限を付与 静的サイトのエンドポイントにアクセスしたときに表示するページやエラーページを指定 一旦公開できた。

May 6, 2018

Make plugins available for mitame

dockerあるしもうlocalのnodeを切り替える必要ないよなーと思ったためにnvmをやめようと思う。 それにともない、mitame側でnpm pakcage のglobal installが出来るようにしてみた https://github.com/timakin/itamae-plugin-resource-npm/pull/1 初めてmitamaeのpluginを書いたのでdesiredとcurrentの作りはいいなぁと感じた次第でした

May 2, 2018

Refine intercom UI

Reproではテクニカルなサポートにintercomを利用している。 最近UIもrenewalされたが、まだ痒いところに手が届いていない状況であることは否めない。 そういうところを直すために、 refine-intercom というextentionを作った。 Automatically ellipsis email history チケット管理の観点からも、なるべく社内外からの問い合わせ回答する場所をintercomに一本化しており、その問い合わせ経路の一つにemailがある。 このとき、emailでやり取りしていたお客様から、テクニカルな質問があるときは途中からtechnical supportにバトンタッチされる。 これはとても良いことなのだが、大きな問題はemailの履歴である。 この履歴がintercomの会話パネルを全て埋め尽くす。いくらスクロールしても終わらない状態。とはいえ、読みたいときもゼロではない。 こういう状態が続いていたわけです。 このような問題を解決するために、emailの履歴とみられる情報をconversation上に見つけたらdetail tagで括って、必要となるまで非表示にしてしまうようにしました。 ここらへんはintercomさんでうまくやってくれるとユーザービリティ高いのになぁ Expand conversation window チャットツールをディスプレイ縦置きした状態で見る人は少なからずいるはずで、例に漏れず私もその一員である。 このとき問題なのが、full HDサイズのディスプレイを縦置きすると横幅が1080になる。 コードを書くときはこれで問題ないのだが、チャットする上では、こう会話ペインがぎゅっと小さくなるわけだ。 そうしたときに、常に見たいわけではない情報を隠したい。 このために右ペインのペルソナ情報を隠すボタンを作った。 今思うとキーボードショートカットを割り当てたほうが良かった気もしている。 Essential tag validator 単純に問い合わせを受けて処理するだけなら問題ないのだが、問い合わせの機能や種別、処理時間を分析したいニーズは往々にあると思う。 そういうニーズに対してintercomは正直まだまだ行けてなくて辛い。 なので、会話にタグ (e.g. feature-push など ) を付けてzendeskやgoogle spreadsheetに記録して分析している。 そういうときに問題と成るのが、分析軸となる担当者のtagのつけ忘れである。 この問題に対応するために、必要なtagのprefixをchromeのstorageに記録しておき、最初のconversationのタグ情報をチェックするようにした。 こうすることで、タグつけ忘れが見える化され、問題が解決されることを祈る。 あっタグ情報はstorageに記録以外にも、gistなりs3なりにおいたファイルをパースして取得するようにしておけば、各位の設定漏れもなくなるから良いのかなぁ

April 30, 2018

build hugo on ci

deployに備えてblogのci環境を構築する。 stackshare - ci を見る限りcircleciがshare的にも無難。 とはいえ、使い慣れたツールっていうのも味気ないが、将来的にはconcourse ci に載せ替えるとしてとりあえずはcircleciを利用する。 circleciで準備されたimageを利用するのだが、その中でやれ何かをinstallするとか辛いし時間がもったいない。 速さは正義なので、imageをpullしてcodeをmountし、buildするという流れが望ましい。 create docker image まずhugoが稼働するdocker imageをつくる。 世にあるやつがメンテナンスされていないのと、host側の設定をcopyするようなものだったので、動きやすさを含めて自分で作成。 https://hub.docker.com/r/threetreeslight/docker-hugo/ executer type どうするか? executerをdockerで動かしたときに、container内にcheck-outしたfileをどうやってmountするか。 circleciを見る限りvolumeを共有することは困難である。そりゃそうだよね。 https://circleci.com/docs/2.0/executor-types/#using-docker とはいえmachineを使うと Start time が 30-60 sec という。 このリードタイムは許せない。 Remote Docker そこで見つけたのがRemote Dockerという機能 https://circleci.com/docs/2.0/building-docker-images/ To build Docker images for deployment, you must use a special setup_remote_docker key which creates a separate environment for each build for security. This environment is remote, fully-isolated and has been configured to execute Docker commands. ... Read more

April 30, 2018

build hugo on ci

deployに備えてblogのci環境を構築する。 stackshare - ci を見る限りcircleciがshare的にも無難。 とはいえ、使い慣れたツールっていうのも味気ないが、将来的にはconcourse ci に載せ替えるとしてとりあえずはcircleciを利用する。 circleciで準備されたimageを利用するのだが、その中でやれ何かをinstallするとか辛いし時間がもったいない。 速さは正義なので、imageをpullしてcodeをmountし、buildするという流れが望ましい。 create docker image まずhugoが稼働するdocker imageをつくる。 世にあるやつがメンテナンスされていないのと、host側の設定をcopyするようなものだったので、動きやすさを含めて自分で作成。 https://hub.docker.com/r/threetreeslight/docker-hugo/ executer type どうするか? executerをdockerで動かしたときに、container内にcheck-outしたfileをどうやってmountするか。 circleciを見る限りvolumeを共有することは困難である。そりゃそうだよね。 https://circleci.com/docs/2.0/executor-types/#using-docker とはいえmachineを使うと Start time が 30-60 sec という。 このリードタイムは許せない。 Remote Docker そこで見つけたのがRemote Dockerという機能 https://circleci.com/docs/2.0/building-docker-images/ To build Docker images for deployment, you must use a special setup_remote_docker key which creates a separate environment for each build for security. This environment is remote, fully-isolated and has been configured to execute Docker commands. ... Read more

April 30, 2018

about

github twitter Qiita slideshare / speakerdeck LTs mastodonがどうやって分散SNSを実現しているのか on shinjukurb#49 at May 24, 2017 jsonapi-resourcesの良い面・悪い面 on shinjukurb #48 at 2016 Data qualityを意識したリファクタリングツール、sicenetist gemについて on shinjukurb #47 at Oct 27, 2016 Dockerizeして
大変だった話、幸せになった話 on TechBlog DeepDive meetup #1 at July 5, 2016 background jobで
気をつけないといかんところ on shinjukurb #37 at May 25, 2016 今だから言えるやらないほうが良かったこと on スタートアップ企業tips共有会 at Apr 27, 2016 AWS Auroraよもやま話 on shinjukurb #33 at Jan 27, 2016 1秒でも早くAutoScale on shinjukurb #32 at Dec 16, 2015 決済って悩むことが多い on shinjukurb #30 at Nov 25, 2015 rails + serverengineで
お手軽daemon on shinjukurb #29 at Sep 30, 2015 what is the best way of method swizzling? ... Read more

April 30, 2018

Don't work hugo autorebuild with dinghy

host側のvolumeをmountしているのだが、その変更をwatcherが補足しない = LiveReloadが動かないのはかなり辛い。 そのため、hugoとdinghyのコードを追う。 そもそもdinghyがmountしたhostのfseventを伝搬できているのか? dinghyは fsevent を vmに伝搬しているはず。 そのため、 inotify-tools を使ってどのようなeventとして伝搬されているのか確認する。 $ docker run -it --rm -v $PWD:/app debian:latest sh % apt-get update && apt-get install -y inotify-tools % cd /app % inotifywait -rme modify,attrib,move,close_write,create,delete,delete_self . Setting up watches. Beware: since -r was given, this may take a while! Watches established. # fileをcontainer内で作成するとcreateのeventを補足する $ docker exec 2a5e08389e9b touch /app/foo.md ./ CREATE foo.md ./ ATTRIB foo.md ./ CLOSE_WRITE,CLOSE foo.md . ... Read more

April 29, 2018

Dockerize hugo on local

blogをtumblerからhugo に移す。 それにともない、まずはlocal開発環境のdockerize。 ちょっとはまったところ そりゃそうだよねってところなのですが dinghy(docker-machine)経由でアクセスするので、assetsの表示を直す hugoの組み込みサーバーはlocalhostをdefaultでbindしている ここらへんはbaseURLとbindを指定することで解決。 # docker-compose.ymlversion:"3"services:blog:build:context:.volumes:-.:/appports:-"1313:1313"command:["hugo","server","--baseURL=http://${DOCKER_HOST_IP}:1313","--bind=0.0.0.0"] watcherが期待通り動いていないので、そこは後日

February 4, 2015

セールスにおけるベストシナリオはエンジニアにおけるワーストシナリオである

(ワーストシナリオっていうのは耐えれる負荷って意味です。) 事業計画を実現に向けてより具体的な計画を立てていくためには、お互いに上記を理解していることが大事だ。 もし、理解していないとビジネスサイドとエンジニアサイドの話し合いは、お互いに猜疑心に満ち溢れていく。実際そうだったし。 例えば ビ「この顧客この時期に取るる予定」 エ「そうすると負荷分散のためにこれとこれをそろそろやろうかな。でも、そうするとこの機能は遅れそう。ちょっと手も回らないから人も増やしてなんとかしたいところだけど」 ビ「うーん、そうしたらちょっとずらそっか?」 エ「えっ?ずらせちゃうもの?」 ビ「現実問題そう簡単には上手くいかないだろうし。掛かるっていうんなら。」 エ「そうしたら、機能開発を先に進めておいたほうがよさそうだね。」 で、あるあるなのは ビ「そういえばこれをここまで進めたいんだけど、いつ頃できるんだっけ?」 エ「ん?話違くない?それをやるんなら人増やしたいし、その動きできてないよ」 ビ「いやいや、遅れるっていうからそれに合わせたんじゃん」 エ「えっ?その必要性がでるまでそれはやらないよ。現実問題がわからないんじゃないの?」 ビジネスサイドはエンジニアに合わせる、エンジニアはビジネスサイドに合わせる。 するとお互いが何も決まらない。だってマイルストーンの決定権をお互いに持っていないのだから。 なぜこのような事態に陥るのか R&Dフェーズや基礎機能を構築していくフェーズは、そもそも物がないので売れないからマイルストーンの決定権は ビジネスサイド < エンジニアサイド でいい。そうでしか動けない。 ただし、売上が立つフェーズ、もしくは積極的に立てるフェーズから ビジネスサイド > エンジニアサイド というマイルストーン決定権の変化が発生する。 言葉にすると ビ「あれ、エンジニアが決めない???しかも毎回言うことが違うの?」 エ「毎回言うこと違うの???っていうかなんでマイルストーンが定まらないの?」 こんな感じ。 解決策としては 見える化して、それを毎週なり振り返ること。今はこれしか思いつかない。 ビジネスサイドは マイルストーンの決定権を持っていることを意識し、現実的な数字を引く。 そして安易にそのマイルストーンをずらす発言はしてはいけない。 エンジニアサイドは ビジネスマイルストーンをビジネスサイドから引き出す努力をする。 マイルストーン達成に向けて必要なことを見える化する。 ビジネスサイドがエンジニアリングが出来る必要が有ると言われる所以はここら辺じゃないだろうか。 ちゃんと見えるかできればそんな努力する必要ないと信じてる。 とはいえ、この解決策が有効か検証し続けるしかない。