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内にアクセスできなか
部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
Next.jsのドキュメントを全部読んでみた - $shibayu36->blog;
最近Next.jsのドキュメントが更新されて、APIリファレンスが付くなど読みやすくなったので、この機会に全部読んでみた。メモを置いておく。 https://nextjs.org/docs/routing/introduction#dynamic-route-segments pages/post/[…all] → /post/* (/post/2020/id/title) こんなことできるのか！ただ全部吸い込まれるのは使いづらそう https://nextjs.org/docs/routing/shallow-routing router.pushにshallowオプションを加えると、getInitialPropsを実行しないレンダリングができる。ページ内でクエリやハッシュフラグメントを変えるなどで便利に使えそう import { useEffect } from 'react' imp
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
人事の仕事の全容を知る - 「人事管理入門」読んだ - $shibayu36->blog;
評価制度などの仕組みを考えるにあたり、一度人事関連の教科書を読んで全容を知らないといけないなと思ったので、おすすめされていた「人事管理入門」を読んだ。 マネジメント・テキスト 人事管理入門<第2版> 作者:今野 浩一郎,佐藤 博樹日本経済新聞出版Amazon とにかく面白く、教科書的に体系的にまとめられているのに関わらず分かりやすく、読んで非常に参考になった。この本を読むと、人事とはどういう役割なのか、グレード制度とは何か、人事評価とはどういう目的で行われるのかなど、人事にまつわる知識が体系的に身につけられる。そのため、人事部に所属している人にはとにかくおすすめだし、人事に関わってなくとも組織に興味があるならおすすめ。人事に関わる制度を考えるときには何度も読み返したい本だなと思った。 今の自分だと、「第1章 人事管理のとらえ方」「第2章 戦略・組織と人事管理」「第3章 社員区分制度と社員格
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
Karma, Mocha, Chaiを使ってTypeScriptでのテスト環境を構築する - $shibayu36->blog;
最近はTypeScriptを使ってフロントエンドの開発をしている。 JSをbrowserifyでビルドし、ライセンスコメントを適切に残す - $shibayu36->blog; gulp + browserify + tsifyを利用してTypeScriptコンパイル環境を作る - $shibayu36->blog; typingsを使ってnpmモジュールをTypeScriptで利用する - $shibayu36->blog; 以上の記事に引き続き、次はTypeScriptでユニットテストをするためのシンプルな環境を構築してみた。 今回のサンプルコードは https://github.com/shibayu36/typescript-project-sample/tree/967c9d74fd3d844127a4352f19a0cc31b7a0690d においてあるので、見ながら確認しても
Scala入門記 - $shibayu36->blog;
僕はこれまでまともに学習したプログラミング言語がPerlとJavaScriptしかなくて、静的言語的パラダイムや関数型パラダイムは概念は知っているものの、それがどう役に立つのか、逆にどういう面で課題がありどのように対処されているのか、などといったことを知らなかった。知らなくてもまあ仕事はPerlとJSでやっているので問題ない。しかしすでにこれらの言語から得られる概念的な知識の吸収の速度が鈍化してきていて、このままではエンジニアとしてまずいのではないかという危惧感があった。 そこで静的言語であり、関数型言語であり、また社内でも使われ始めているためサンプルコードがあるScalaの学習をすることにした。 学習するにあたって困ったことは、どういうドキュメントを読み、どのように実践するとScalaの概観をつかめるか分からないということだった。そこで今回は自分の経験を踏まえて、このように入門していくと
見学のときに不動産屋に質問して得た有益情報 - $shibayu36->blog;
良い物件ではなく良い不動産屋を探した - $shibayu36->blog; 先日の物件探しの見学のときに、不動産屋のこと全く知らないし質問チャンスと思っていろいろ聞いたのだけれど、いろいろと内容が面白かったので公開します。ちなみに京都で、かつその不動産屋で、ということなので、一般的ではないかもしれません。 その部屋が隣の音漏れがあるかとか運ですよね 雑談してて、部屋の間取りとか条件とかは情報で得られるけど、壁の音漏れとか、条件に入ってこないところとかもあったりして、そういう部分を含めると引っ越しは運ですよねーって話をしてたら、有益情報を得られた。 正確さは保証できないが、実は壁の音漏れなどの情報を得ることも出来る そういう条件に入ってこない悪い部分があると、住人が管理会社に何度もクレームを送って、対応されないから退去ということが起こる可能性がある なので、退去理由やクレームの量・内容を、
良い物件ではなく良い不動産屋を探した - $shibayu36->blog;
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
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のプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
Dockerが利用しているAUFSとLXC - $shibayu36->blog;
最近Dockerをいろいろ触ってみていて以下の様な記事を書いたりしました。 Dockerで立てたコンテナにsshで接続する - $shibayu36->blog; serfとDockerでクラスタを組んでみる - $shibayu36->blog; 本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; 社内用Docker Registryを立てる - $shibayu36->blog; docker commitでCMDやENVなどを指定する - $shibayu36->blog; docker inspectでDockerコンテナの情報を取得する - $shibayu36-
Immutable Infrastructureに対する自分なりの考えメモ - $shibayu36->blog;
インフラ系技術の流れ - Gosuke Miyashita 今さら聞けない Immutable Infrastructure - 昼メシ物語 2014年のウェブシステムアーキテクチャ - stanaka's blog http://rebuild.fm/25/ この辺りを読んだ。自分の中ではImmutable Infrastructureについてはここ一週間で調べただけであり、解説などは出来ないが、とりあえず自分用のメモとして自分の思ったことなどを書いていく。 コンテナベースのデプロイ Dockerなどが出てきたことにより、Dockerのイメージをそのままアップロードし、それを本番でも動かすということが出来そうというのが面白かった*1。こういう風なフローになるとすると、これまでのデプロイ手順とは全く違うようになりそう。 これまでのデプロイと、コンテナベースのデプロイ これまでのデプロイは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
