5月に沖縄県の南大東島と北大東島に行ってきた。沖縄本島の遥か東に浮かぶ絶海の孤島で、周囲を険しい断崖に囲まれていることから波風の影響を受けやすく、フェリーを港に接岸することができない。 なので荷物も人もクレーンに吊るされて乗り降りする――という話を前回の記事「大東島では荷物も人もクレーンに吊るされ上陸する」に書かせて頂いた。 実はその記事ではあえて言及しなかった港が南大東島に存在する。島の北西部に位置する「漁港」である。これが、とにもかくにも凄いのだ。 1981年神奈川生まれ。テケテケな文化財ライター。古いモノを漁るべく、各地を奔走中。常になんとかなるさと思いながら生きてるが、実際なんとかなってしまっているのがタチ悪い。2011年には30歳の節目として歩き遍路をやりました。2012年には31歳の節目としてサンティアゴ巡礼をやりました。（動画インタビュー） 前の記事：大東島では荷物も人もクレ

TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

常時接続型 API を構築するとき、 Go + gRPC Streaming はパフォーマンスに優れる有力な選択肢となります。しかしながら常時接続ゆえ、通常通信時間が短時間で終了する Web API とは異なる注意点があります。そこで本セッションでは、gRPC Streaming の紹介にはじまり、注意点やハマりポイントをご紹介します。また、GKE 上でオートスケールするオートモーティブ移動体情報配信システムを構築した事例をご紹介します。

本番環境の監視をZABBIXからPrometheusに切り替えてから3か月程度経過しました。 今回は Prometheus 導入に関してハマったところ 現在のPrometheus活用状況 といった所を紹介したいと思います。 「Prometheusって何？」という方はこちらをご覧ください。 tech.willgate.co.jp Prometheus導入でハマったところ メール送信設定 Rプロキシ経由にする 現在のPrometheus活用状況 現在の構成 ECインスタンスの監視 設定のバージョン管理 種類豊富なexporter 柔軟なPromQL Grafanaとの組み合わせ まとめ その後の取り組み（2019/11/12 追記） Prometheus導入でハマったところ 紹介するところ以外でも色んなところでハマったのですが、代表的なところを紹介します。 メール送信設定 Alertmanag

JVM (Java 仮想マシン) には DNS の名前解決の結果をキャッシュする挙動が備わっている。キャッシュするだけならいいのだけれど、このキャッシュでは DNS の TTL を無視してキャッシュするため、名前解決の結果が変わっても JVM からの接続先が切り替わるまでに（TTL から想定される時間以上に）時間がかかる、あるいは全く切り替わらないということがある。この挙動やその制御について調べたので、その話をする。 （以下の話題では Oracle JDK および OpenJDK を対象にして論じるので、それ以外の JVM 実装でどうなってるかは調べていない。適用できる箇所もあればそうでない箇所もありそう） 背景・解説 これらのデフォルト値は名前解決成功時は セキュリティーマネージャーがインストールされている場合のデフォルト値は -1 (ずっと) で、セキュリティーマネージャーがインストー

このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし

async/awaitの最小限の機能が、 Rust 1.38.0 リリースを目標に準備されています。Rust1.36.0のリリースが2019-07-04で、Rustは6週間ごとにリリースされるので、順調にいけば 2019-09-26 頃にリリースされると思われます。もちろんnightlyではすでに試せます。 さてこのasync/awaitですが、他の言語のasync/awaitと基本コンセプトは近いものの、いくつか異なる点があります。個人的には以下のことを把握しておくとよいと思いました。 後置await構文 戻り値型 (内部戻り値型・実装ごとに異なる型) 駆動 (awaitまたはspawnしないと進まない) キャンセル (awaitポイントは中止ポイント) 本稿は現象の説明にとどめ、そうなっている理由には基本的に言及しませんが、どれもきちんと理由があってそうなっています。その点はご承知おき

ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか？」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって（若干訂正してますが）ここに残して

readable-code-chap5-6.md 5章 コメントすべきことを知る コメントの目的は書き手の意図を読み手に知らせることである コメントすべきでないことを知る コードを書いているときの自分の考えを記録する 読み手の立場になって何が必要かを考える コメントすべきではないこと パっとみて当たり前にわかることをコメントに書かない // 休日を計算する function caliculateHoliday() { ... } // 関数実行時の年の1/1から12/31まで、祝日を除く休日を計算する function caliculateHoliday() {....} コメントにパッと見でわからないことを書くようにしよう 関数名がひどい場合はコメントではなく関数名を書く // Kintoneのカスタマイズでコメントを128kbに制限する // コメントにはコメント内容、コメント時刻、コ

ScalaMatsuri 2019 http://2019.scalamatsuri.org/index_en.html

「15年」 あなたは15年と聞いて何を思い浮かべるだろうか。 例えば人が生まれて15年。 その人は今頃中学校を卒業し高校生になる頃だろう。 例えば15年戦争。 1931年の満州事変から始まった一連の戦争が1945年に終結するまでにかかった年月。 例えば私が2chのソフトドリンク板に「とあるスレッド」を立てそのスレッドが1000レスに達するまでの年月。 と言うわけではじめまして。 2ch（現在は5chですが、この記事では2chと記載します）ではいつも所謂「名無しさん」ではありますが、ここではamino774mlと名乗らせて頂きます。 よろしくお願いします。 さてこの度何故このようなブログを開設したのか。 それを語るにはまずはこの2chのスレッドを見ていただく必要があると思います。 アミノバリューってどうよ？ これは2003年9月19日にソフトドリンク板に立てられたスレッドの一つです。 何を隠

人生の選択肢に不正解はない。「仕事と子育ての両立」で悩んでいた私にそう教えてくれたのは、ある男子大学生だった。 記者として働きながら2人の子どもを育てている筆者。夫の仕事も忙しく、仕事も子育ても中途半端な自分に罪悪感を抱えることも少なくない。 だが、男子大学生にシッターとして週に1日子育てと家事を頼むようになり、考え方が変わった。男子大学生と私たち家族の交流を紹介する。（中村かさね／ハフポスト日本版） 「両立」って、誰のものだろう。 「仕事と子育ての両立」は、数年前までの私にとって、最大のテーマだった。 仕事を終えて保育園に直行しても午後7時過ぎ。必死で走って迎えに行ったのに、保育園から「帰りたくない」と泣きわめく息子。 後から“お迎え”のお友だちにも次々と抜かれていく。保育園の入り口にしゃがみ込んで意地を張る息子を無理に自転車に乗せることもできず（暴れて危ないので…）、途方に暮れた。 「

ツイートしてて自己完結してしまったので記録のために。 あーそういや今更だけど、stdoutとstderrはまとめてlogging driverに渡されちゃうのか。どちらなのかはdriverには渡っているのでfluentdに出せばラベル付いてるので、ログのことだけ考えれば仕組み的にはどちらに出しても扱うこと自体には問題が無さそう。 — Aki (@nekoruri) June 22, 2019 デーモンアプリケーションで想定外のエラーが出うるのであれば、構造化ログをstdoutという分離は全然ありうると思う。 — Aki (@nekoruri) June 22, 2019 でもそうしちゃうとエコシステムから外れちゃうので、やっぱり最大公約数としてはparseableなテキストでstdout/stderrかなあという気がしてきた。やはりDockerにfile descripterの概念が欲しい

モンスト事業本部SREグループの伊藤です。 普段はモンストに関するシステムの改善・運用を様々な面から行っています。 今回もサービスの直接的な改善ではないですが、ツール等のIP制限を減らす取り組みについてご紹介します。 サービスの直接的な改善もいつか書ければなと思っております。 皆さんはIP制限をしているツール等はいくつくらいありますでしょうか？ モンストにも歴史的経緯でIP制限されたツールや、特に制限されていないツール（！）までいくつもありました。 自作のツール以外にも開発や運用で使っているツールのフロントエンドなども合わせると30以上のツールがあります。 運用で使うツールはアラート対応などでオフィスにいない時でもどこからでもスマートに見れると嬉しいです。 特にサーバーのメトリクスは移動中に見れると対応しているメンバーにアドバイスができたり非常に助かります。 これまではオフィスのIPからの

この度、自身が立ち上げて主宰していた、Scala関西の運営から抜けました。 つい先日も勉強会でScalaの話をしたり、Scala関西Summit 2019も開催すると決めて、例年通り主宰として準備を進めていたので、この急な話はいろんな人を戸惑わせることは承知しています。 ですので、理由を公開しなければと思い、ブログを書いています。 最初に前置きしておくと、抜けると決めたのは本当に急な話です。 あと、病気だとか実はスタッフと仲が悪かったとか、ネガティブな理由ではないです。 先日までScala関西やる気満々だったのも嘘ではないです。 抜けようと決断した前後にはいろいろな葛藤もありましたが、前向きな理由によるものです。その辺りはご安心(?)ください。 抜けようと決断した理由 運営から抜けようと考えることになったきっかけは、下記資料です 2019/05 Scala導入を検討したい人に向けた情報をま

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

0.　はじめに 18年10月にKotlinのコルーチンがexperimentalからstableになりました。 遅ればせながら、コルーチンを触ってみました。 この記事は、これからコルーチンを学習する人向けの記事です。 ＊Kotlin1.3、 kotlinx-coroutines1.0.1の環境です。 ＊Kotlinが初めての方は、こちらで気軽に試せるので触ってみてください。先頭にimport kotlinx.coroutines.*を忘れずに。 1.　コルーチンとは Wikipediaから引用します。 コルーチン（英: co-routine）とはプログラミングの構造の一種。サブルーチンがエントリーからリターンまでを一つの処理単位とするのに対し、コルーチンはいったん処理を中断した後、続きから処理を再開できる。 どういうことなのか。簡単なプログラムを例にして説明をします。 fun main()

kotlin.connpass.comでコルーチンに関する話をしてきました。 Kotlin コルーチンを理解しよう スライドはコチラ。音声や動画が無くても大体読めばわかる内容になっていると思います。 流れ 6月末にひつじさんからお手紙がとどく 直前の技術書典4でKotlinのコルーチンを使う前に自前で実装してみるという話を書いていたこともあり、 その辺をベースにした話の組み立てでできそうな気がするということでシュッと受けた。 結果的にめちゃくちゃ大変でしたが最終形はなんとかまとまったので良かったです。 調べたことや登壇時は触れられなかったことなど 話のベースは頭の中にあったものの、コルーチンの概念そのものが一体どういうものなのかあまり深く理解していなかったこともあり、その辺の調査もしなきゃな〜と手を動かし始めるとそのままどツボへ真っ逆さま。今回話の流れや時間的に触れられなかったことなんかを