タグ

ブックマーク / blog.shibayu36.org (10)

  • 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したけどpsqldocker内にアクセスできなか

    Next.js + Prisma + NextAuth.js + React Queryを試した - $shibayu36->blog;
    laiso
    laiso 2021/05/09
  • 締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;

    これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクト

    締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
    laiso
    laiso 2020/07/28
  • Next.jsアプリケーションを動かす環境をaws-cdkを使って構築する(with CloudFront/S3/Fargate) - $shibayu36->blog;

    Next.jsをproduction環境で使うために外観を掴んでおきたいと思い、Next.jsアプリケーションを動かすAWS環境をaws-cdkを使って構築するサンプルを作ってみた。だいぶ荒削りだけど、参考になる例にはなったと思う。 https://github.com/shibayu36/nextjs-on-ecs 利用した技術 AWS CloudFront S3 ECR ECS aws-cdk Docker Next.js + TypeScript 今回作ったアーキテクチャ 全てのリクエストをCloudFrontに通すフルCDNアーキテクチャ フルCDNアーキテクチャ実験 / Minami Aoyama Night #1 - Speaker Deck フルCDNアーキテクチャでサービス設計した話 - Speaker Deck next buildで生成した静的ファイルはS3から配信

    Next.jsアプリケーションを動かす環境をaws-cdkを使って構築する(with CloudFront/S3/Fargate) - $shibayu36->blog;
    laiso
    laiso 2020/02/26
    CDK良さそう
  • ディレクターを経験して良かった - $shibayu36->blog;

    この記事は、はてなディレクターアドベントカレンダー2016の19日目です。昨日は id:shimobayashi の「効率的で課題解決的な態度にひそむ罠について」でした。 こんにちは、はてなでアプリケーションエンジニアをやっているid:shiba_yu36です。僕は現在はエンジニアをやっていますが、一度はてなでディレクター(いわゆるプロダクトマネージャー職)を経験しています。ディレクターに挑戦した理由は、マネジメントという分野にも少し興味があったためです。しかし、当時なかなかディレクターという職種を楽しむことが出来ず、結局1年足らずで挫折してエンジニアに戻ったという過去があります。 このような経験でしたが、僕はとにかく一度ディレクターを経験して良かったと思っています。なぜならディレクター経験がエンジニアとしての今の自分に非常に活かされているからです。そこで、今回は自分がディレクターを経験し

    ディレクターを経験して良かった - $shibayu36->blog;
    laiso
    laiso 2016/12/19
  • 見学のときに不動産屋に質問して得た有益情報 - $shibayu36->blog;

    良い物件ではなく良い不動産屋を探した - $shibayu36->blog; 先日の物件探しの見学のときに、不動産屋のこと全く知らないし質問チャンスと思っていろいろ聞いたのだけれど、いろいろと内容が面白かったので公開します。ちなみに京都で、かつその不動産屋で、ということなので、一般的ではないかもしれません。 その部屋が隣の音漏れがあるかとか運ですよね 雑談してて、部屋の間取りとか条件とかは情報で得られるけど、壁の音漏れとか、条件に入ってこないところとかもあったりして、そういう部分を含めると引っ越しは運ですよねーって話をしてたら、有益情報を得られた。 正確さは保証できないが、実は壁の音漏れなどの情報を得ることも出来る そういう条件に入ってこない悪い部分があると、住人が管理会社に何度もクレームを送って、対応されないから退去ということが起こる可能性がある なので、退去理由やクレームの量・内容を、

    見学のときに不動産屋に質問して得た有益情報 - $shibayu36->blog;
    laiso
    laiso 2014/07/23
  • レビュータイムの導入・消滅・再導入 - $shibayu36->blog;

    今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi

    レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
    laiso
    laiso 2014/03/13
  • コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;

    id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性

    コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
    laiso
    laiso 2014/01/20
    “スマフォ技術に詳しいエンジニアはチームに一人しかいないけど、誰がレビューするの?” 重大だ
  • 仕事の仕方が悪かった - $shibayu36->blog;

    ここ最近全く仕事に対してモチベーションが湧かなくて困ったと思っていたけど、仕事のやり方が悪かったせいと気づいた。IRCを見すぎていた。 仕事するときに基的に集中力を落とすようなものは出来るだけ見ないようにしていた。例えばtwitterを見ないようにクライアントは立ちあげないとか、あえてクライアントを立ち上げるショートカットキーを設定しないとか。 とは言えIRCとかは仕事でコミュニケーションするときに使っていて、それを落としてしまうとコミュニケーションが困難になる。なのでIRCは立ちあげないことはせず、気にならないようにTotalSpacesみたいなものを使って別windowに押し込めるとかしていた。 IRCを別windowにしたといっても、実際にはショートカットとかで簡単に見れてしまっていて、慣れてしまうと結局IRCを見てしまっていた。結果として、集中力を欠き、仕事の進み方が遅くなり、い

    仕事の仕方が悪かった - $shibayu36->blog;
    laiso
    laiso 2013/09/25
  • Test::Perl::Criticでコーディング規約をテストする - $shibayu36->blog;

    コーディング規約はあるけれど、レビューの時にチェックするのは大変ということで、とりあえずTest::Perl::Criticを使って軽くテストを書いてみました。 僕はある程度のコーディングのブレは許容して、チーム全員で合意がとれるものだけを自動でチェックするようにしたほうが良いと思っているので、rcファイルを使って、必要な物だけ追加していく形式を試してみました。 テストの追加 まずテストは以下のようにt/perlcriticrcを読み込むという設定をしてあげた上で、libとt全部をテストするように書きます。 require Test::Perl::Critic; my $rcfile = File::Spec->catfile( 't', 'perlcriticrc' ); Test::Perl::Critic->import( -profile => $rcfile ); all_cri

    Test::Perl::Criticでコーディング規約をテストする - $shibayu36->blog;
    laiso
    laiso 2013/09/05
  • 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;

    Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべきだなと感じた。 このではソフトウェアコンストラクションに関する話題を扱っている。このの中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による

    職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
    laiso
    laiso 2013/03/09
  • 1