zshのcompinitに指定してるautoloadのオプション -Uz について
zshを使い始めて半年程たったので、設定を見直していたら補完機能を有効にする箇所が人によって違うことに気づきました。 普段からシェル使ってる人からしたら当たり前の知識なんだろうけど… Aさんautoload -U compinit # 保管機能を有効にする compinit # 実行するautoloadに -Uオプションがついてますね。 これはビルトイン関数を読み込む時に、ユーザ側で定義した aliasに上書きされるのを防いでくれる。 aliasは結構使うので、気付かぬうちに同名で定義することがあるかもしれないですね。 Bさんautoload -Uz compinit # 保管機能を有効にする compinit # 実行するautoloadのオプションに-zが追加されてますね。 この -zオプションはzsh形式での読込を指定します。 なぜこの -zオプションが必要になるか。それは、環境によ
PdM/EMが気づくべき「技術負債」の異変〜予測精度の幅で捉える〜
技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 技術負債とは、現場のエンジニアが感じる理想と現実との乖離のことでリファクタリングやリプレイスはそれを少しでも差分を埋めることである。（その差分を本当に埋めることができるかはエンジニアのスキルとシステムの複雑性による） そうなったときに、どこに一番その予兆ができるかというと一番わかり易いのは工数の予測精度の幅があると仮定する。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていること
Redis Cluster の運用とモニタリング/監視のコツ
この記事は、はてなエンジニア Advent Calendar 2017の 20 日目の記事です。19 日目の記事は yasuhiro_onishi さんのScratchを使った子どもへのプログラミング教育 — 大西ブログでした。 今年の 2 月にはてなに入社して、あと 1 ヶ月と少しで 1 年を迎えようとしています。はてなに入社してから Mackerel のインフラと時系列データベースの AWS 移行プロジェクトを任されたり、移行を終えた後も後片付けや移行後の運用を担当したりと、主に Mackerel にコミットしていた 1 年でした。自分が Mackerel にコミットしたところは Mackerel のイベントで登壇したいくつかの登壇資料にもあるとおり数多いのですが、この記事では、運用する中で試行錯誤を重ねて苦労した Mackerel を支える時系列データベースのコンポーネントとして利用
これからはじめる 実践SRE / SLO の監視をやってみよう
SRE がアツいですね。 昨年は以前に増して SRE 関連のイベントも増え、SRE 人材への注目も更に高まっていると感じた 1 年でした。私も Google Cloud の Customer Engineer として、お客様へ SRE のお話をする機会が増えてきています。 ご存知の通り、SRE は Google から生まれた運用プラクティス、またはそのロール自体を指す言葉です。 詳細は無料で読むことができる書籍を御覧ください。 “Site Reliability Engineering” 及び “The Site Reliability Workbook” （右上の右2つ）は HTML 形式 なので、Google Chrome で右クリックして 翻訳を選択するという簡単な手順で日本語でも読むことができます。（書籍がよい方は日本語版も購入できます。） 今回のテーマは SLO (Service
テープが擦り切れるまで聞いた Rebuild.fm 厳選オススメ回 4選
私はソフトウェアエンジニア、宮川達彦さんが運営するポッドキャスト Rebuild.fmの大ファンです。当時の同僚に勧められて初めて聞いた2014年から今まで聞いていない回はおそらくなく、何度も繰り返し聞いた回がいくつもあります。 自身で書いたブログなどでもRebuild.fmを参照させてもらったことも多く、2021年に翔泳社さん運営のWebメディア BizZineにプロダクトマネジメントに関する記事を投稿した際にも、記事内でRebuild.fmの回に触れ、放送回のタイトルを記事タイトルに引用させていただきました。 ビジネス寄りの媒体であるBizZineにRebuild.fmへのリンクが貼られているのは私の記事だけではないかと自負しています。
Kubernetes — Open Standards (OCI, CRI, CNI, CSI, SMI, CPI) Overview
What are Kubernetes Open Standards? — Introduction to K8s Open Standards. DevOps Mojo — Kubernetes — Open StandardsTL;DR:Open standards help and complement systems like Kubernetes, which is the de facto standard platform for orchestrating containers. Open Standards defines the best practices for implementing Kubernetes and play a vital role in supporting this implementation. Open standards are set
Generating UUIDs at scale on the Web
TL;DR can you trust every browser to generate globally unique identifiers at scale? At Teads, we have tried, and the answer is yes, with a few caveats. This article describes the experiments we’ve run and the discoveries we made along the way. Why we need client-side unique identifiersGenerating unique identifiers is a common need that third-party scripts integrated on Web pages and e-commerce sit
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
Cloud Spannerの主キーの設計
Cloud Spanner は完全に管理されたミッションクリティカルなリレーショナル データベース サービスであり、グローバルなスケールでのトランザクション整合性、スキーマ、SQL（拡張機能を含む ANSI… ただドキュメントを見てもID生成器のことなどを理解していないと、いざ設計するとき苦労するかと思い記載しました。ドキュメントの補足資料として読んでいただけたら幸いです。 Cloud Spannerの特徴特徴を簡単に記載しますと ノード、スプリットで構成されている。レコードデータはスプリットに配置される。どこに配置するかはレコードの主キーに依存する。レコードの増減に応じてCloud Spanner側で自動で(1)どのレコードをどのスプリットに配置するか。(2)スプリットの数 をコントロールするレコードをどのスプリットの配置するかはレコードの主キーの値に依存する分散されたスプリットにアクセ
データ指向アプリケーションデザイン
AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、
Google Apps Script は何が強くてどんなときに使うべきかプラクティスをまとめてみた
はじめにGoogle Apps Script は無料で色んなことが実現できるため、ついつい「全て GAS でやっちゃおう」みたいな話になりがちです。Google Apps Script も万能ではないので、強み・弱みを理解した上で他の選択肢と比較して使うのをお勧めします。 Google Apps Script のプロジェクトを 2–30 個作ってきた中で、自分なりのプラクティスをまとめてみます。 この内容は Cloud Next ’18 in Tokyo で登壇したときの内容を含んでいます。この登壇から半年以上経ったのでアップデート部分も以下にまとめています。 Google Apps Script の強み・弱みまず、強みと弱みについてまとめてみます。 強み 1. Google Apps の API を簡単に呼び出すことができる一番の強みはこれだと思います。Google Apps Scrip
「良いエンジニア」を言語化してみました
「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。 「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪ 妥協ない挑戦元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか？」というのをキーワードにやってました。 解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。 そんなこと言っても普段は妥協ばっかりですって？いえいえ、相反する選択肢の中で、何を
Apache Kafkaを使ったアプリ設計で反省している件を正直ベースで話す
Apache Kafka: Producer, Broker and Consumer2017年は生まれて始めてApache Kafkaを本格的に業務利用（PoCではなく本番運用）した年でした。Apache Kafka的なメッセージングミドルウェアそのもののは、社内的な事情でよく使っていたのでその使い勝手に対して困惑はほとんど無かったですし、ミドルウェアとして非常に安定しているため、Kafkaクラスタそのものでの不具合らしい不具合が発生したことは一度もありませんでした。 しかし、Kafkaのトピック設計などに関してのベストプラクティスは事例ベースでもあまり見かけたことがなく、チームメンバーと悩むことも多かったです。このストーリーでは、主にKafkaを利用したアプリ設計で考えたことや失敗したことを振り返りつつ共有します。なお、パーティション数や各種バッファサイズなどのチューニング要素は今回取
19: 読んでよかった技術書
この記事は「再起する青年 Advent Calendar 2017」19日目の記事です。 お題箱から「おすすめの技術書を教えてください」と来たので。 これまで読んで「実用できた」ものに絞ります。入門から応用まで。 システムプログラミングGNU 開発ツールhttp://www.oversea-pub.com/store/gnu_development_tools println(“hello world”); がなぜ動くのかわかる。 2. Linuxシステムプログラミング https://www.oreilly.co.jp/books/9784873113623/ カーネルや system call などの仕組みが網羅的にわかる。でも、今から始めるなら 「Goならわかるシステムプログラミング」がいいかもしれない。 言語学習プログラミングの基礎(OCaml)http://amzn.asia/e
うわっ、私のサイトBootstrapくさすぎ!? たった数文字変えるだけでBootstrapのくさみが抜ける7つのCSSテクニック。
なんか、このサイトBootstrapくさい。そう感じることはありませんか? その理由はズバリ、欧文ベースでつくられたフレームワークを文字構造の違う日本語で適用した際に不都合が出てしまっているからです。 それらが醸し出す違和感を放っておくと、Bootstrapくささを生み出す大きな原因になってしまいます。 そもそもの問題として、欧文と比較して和文は文字の要素が多く、文字自体のリズムも少ないため、どうしても複雑で単調に見えてしまいます。 しかし、和文だからといってあきらめることはありません。BootstrapのCSSを少しだけ変えるだけでグッと見た目がよくなる隠し味をご紹介します。 1. line-heightで行間にゆとりを。明朝やゴシックなど、フォントの種類が言葉の印象を表すように、文字の行間は読みやすさ、文章全体の雰囲気を左右します。 欧文をベースに設計されたBootstrapをそのまま
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Listen to Yourself: A Design Pattern for Event-Driven Microservices