マイクロサービス化や大規模リファクタリングの手順を学ぶ - モノリスからマイクロサービスへを読んだ - $shibayu36->blog;
本当に最高の本でした。マイクロサービス化に取り組んでなかったとしても、規模が一定以上大きいプログラムのリファクタリング手法としても勉強になるので、みんな読みましょう！少なくともマイクロサービス化をしていきたいと思っていて、この本を読んでないならば、まずは一旦手を止めて関係する人全員でこの本を読んでから再度手を動かす、くらいでも良いレベルと感じました。 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド 作者:Sam NewmanオライリージャパンAmazon この本を読んでいると、マイクロサービス化をしたいときは、必ず以下の手順でやっていくべきと感じました。 目的を明確にする 達成したいことは何か？事業が達成しようとしていることにあった一連の成果が目的でなければならない。これは、システムのエンドユーザーへのメリットを説明する方法で明確にできる その目的を達成するために、な
Next.js + Prisma + NextAuth.js + React Queryを試した - $shibayu36->blog;
2分コーディングの一環でNext.js + Prisma + NextAuth.js + React Query で作るフルスタックアプリケーションの新時代をやった。とにかく簡単に認証 + DBアクセスがあるアプリケーションを作ってvercelにデプロイできるサンプルが出来て非常に良かった。趣味プロダクトをちょっと作ってみるのに良さそう。 shibayu36/next-prisma-auth-tutorialに試した例を置いているので参考にどうぞ。 やれたこと Googleのアカウントを使ってサインインし、TODOを追加できるアプリケーション herokuのPostgreSQL dbをデータソースとして動くアプリケーションをvercelにデプロイ 作業メモ prisma、migrationのツールも入ってるし便利すぎる。 migrationしたけどpsqlでdocker内にアクセスできなか
TypeScriptの型を手に馴染ませるためにやっていること - $shibayu36->blog;
最近TypeScriptが好きで勉強していっている。しかしなかなか型定義周りが手に馴染まず、少し複雑な型定義を読んだり、自分でユーティリティ型を定義したりすることが難しかった。 そこで型を手に馴染ませるために色々学習をしてみたので、やっていることをメモしておく。 まずざっとTypeScriptの型概要を学ぶ まずTypeScriptでの型を簡単に学ぶには以下の2つの資料がわかりやすかった。 TypeScriptの型入門 - Qiita TypeScriptの型初級 - Qiita ひたすら型演習をする 資料を読むだけでは全く手に馴染まないと思ったので、その後ひたすら型演習をしている。 まずは TypeScriptの型演習 - Qiita 。これは先程の型初級、型入門の記事を書いた人が演習問題を作っているため同じ流れで学習でき、さらに解説編も充実しているので、手を動かしながら学ぶのに最適であ
VSCodeのFindで今マッチしている場所にボーダーを引いて見やすくする - $shibayu36->blog;
VSCodeでFindしている時に、マッチしているwordは背景色が変わって分かるのだけど、今どこにフォーカスしているかが分かりづらかった。これが特に問題が起こるのがReplaceをしようとしている時で、Replaceするたびに今どこ？とマッチ箇所を探していた。これだと時間がかかって困る。 調べてみるとTheme Color | Visual Studio Code Extension APIに書かれているように、自分のsettings.json内で自分用に色を調整し、見やすくカスタマイズ出来ることが分かった。これでFindの現在のマッチ箇所を見やすくしてみる。 Findの色のカスタマイズは editor.findMatchBackground: Color of the current search match. editor.findMatchHighlightBackground:
アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;
最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon この本では、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根本対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない！」「障害対応をもっとうまくやる方法はないのだろうか？」と思う人には参考になる部分が多いと思う。 個人的にこの本の中で一番良いなと思ったのは、 SREだけでなくアプリケーションエ
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
「みんなのGo言語」を読んだ - $shibayu36->blog;
Go言語の学習のため、A Tour of Goに引き続き、「みんなのGo言語」を読んだ。 みんなのGo言語[現場で使える実践テクニック] 作者:松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太技術評論社Amazon 「みんなのGo言語」はGo言語を実践的に使うためのTipsがいろいろまとめられていて非常に良かった。Go言語のA Tour of Goをやったけど、次にどうすればよいかわからない、具体的にGoの良い書き方が分からないという人が読むと非常に勉強になりそう。 僕はまだGoをそこまで書いていないので、「第1章Goによるチーム開発のはじめ方とコードを書く上での心得」と「第4章コマンドラインツールを作る」が非常に参考になった。例えば以下のようなものが参考になった(数字はKindleのロケーション番号)。 Goプロジェクトのプロジェクト構成やディレクトリ構成 519, 2389
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
CSSのブラウザサポート状況を自動でチェックできるdoiuseが便利 - $shibayu36->blog;
最近書いているCSSがそもそも今サービスが推奨しているブラウザでサポートされているのかチェックするのだるいと思っていたら、doiuseという便利なツールを見つけた。 doiuseとは https://www.npmjs.com/package/doiuse CSSのブラウザサポートのチェックをしてくれるモジュール。caniuse のデータベースを利用して、ブラウザと自分が書いているCSSを指定して、サポートされていないCSSの書き方を見つけてくれる。 試す環境を用意する とりあえず試すための環境を用意する。適当なディレクトリを作って、必要なライブラリをインストールする。また、検証するためにbootstrapも入れておく。 $ mkdir try-doiuse $ cd try-doiuse $ npm install --save-dev doiuse $ npm install --sa
pecoを使い始めた - $shibayu36->blog;
なんかpercol最近いきなり流行ってるなーと思ってたら、percolのgo版pecoがいつの間にか出てて流行ってた。ターミナル版anything的なpercolをzawの代わりに試してみた - $shibayu36->blog;みたいな感じで、昔からpercol使っててまあいいかと思ってたけど 設定ファイルが分かりやすい brewで簡単に入れることが出来る そこそこ開発されてる というメリットもありそうなので乗り換えようとしてみている。 https://github.com/peco/peco pecoのファイル運用 前と大体同じ感じでやる。基本的にこういうツールは自分でいろいろ作りたくなってきて、設定が増えてきて破滅するので、ファイルを置くディレクトリを決めておいてそこに置いておくことにする。 .zshrc : 決めたディレクトリのファイルの全ロードと、キーバインドの設定 ~/.zsh
DevLove関西で「課題をテストで解決する」という発表をしました - $shibayu36->blog;
DevLove関西に行ったので、「課題をテストで解決する」という発表をしてきました。 内容はスライドに書いてあるとおりです。以下のことを特に話したくて、今回の発表をしました。 何度も起こる課題があったときに人が気をつけようとしない 最悪のケースでは根本原因を知ろうとせず、間違えた人を怒ることで解決しようとしてしまう 何度も起こる課題なら、機械に自動的にやらせる その例として今回はテストでやりましょうという話をした あとテストいろいろあって始め方がわからないという時は、こういう課題をテストにするというところから始めるとやりやすいかもしれない 参考 この資料作るにあたってひたすらブログ書いたので参考にどうぞ 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->b
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
cron周りのベストプラクティス読んだ - $shibayu36->blog;
WEB+DBのPerl Hackers Hubで書かれていた「cron周りのベストプラクティス」を読んだ。かなり参考になった。 経緯としては読みたいって呟いたら感想よろしくと言われたので慌てて読んだ。 @shiba_yu36 「読んだ」なら言ってもいい— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジに謝られても…— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジになって感想エントリを書いてください。— songmu (@songmu) 2014年2月24日 特に参考になったこと batch.pl batch.plは非常に良いと思った。というのもcronとかのスクリプトで非常に簡単な事をやっている場合は適当にplファイルを作っちゃって登録するんだけど、得てしてそういうのはテストが無くてバグってて、しかもcronのロ
Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog;
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ この辺に書いたとおり、id:wtatsuru, id:y_uuki, id:hagihala と一緒に、DockerやMesosなどを利用してBlue-Green Deploymentのプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
AWS, chef, Cinnamon等を使った無停止デプロイ(PrePAN carton 1.0化の裏側) - $shibayu36->blog;
最近PrePAN uses carton 1.0 now! - $shibayu36->blog;でも書いたとおり、PrePANのcarton 1.0化を進めていました。 通常であれば変更点をアプリケーションサーバにデプロイし、サーバを再起動すれば良いのですが、cartonを0.9から1.0に上げるというまあまあ大きな変更を加えるため、事前に動作確認を行い、無停止でデプロイしたいと考えました。そこでAWSを使って無停止デプロイを試してみたのでそれについて書こうと思います。 PrePANのサーバ構成やデプロイ手順の検討 無停止デプロイの説明の前にPrePANのサーバ構成を紹介しておきます。 現状はELB 1つに対し、EC2が2台ぶら下がっているという状態で運用しています。そしてEC2に対してはそれぞれapp-1, app-2という名前でタグがついています。 開発メモ#2 : AWS でのホス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
