社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
Prettierを使わない理由
この記事はPrettierを使用している人を非難したり、脱Prettierを推奨する事を目的としていません。 こういった考え方もあるということをひとつの意見としてご覧いただければ幸いです。 勘違いしている人が多そうなので追記します。 Prettierを使わないというのは私が独断で決めた事ではないです。 チームが発足する際の技術選定で合意は取れていますし、私が関与していない別のチームでも同様にPrettier無しで開発しています。 私達のチームはメンバー同士を互いに信頼していますし、細いスタイルで喧嘩を始めるようなメンバーは居ないので安心してください。 はじめに Prettierはコードフォーマッターとして広く使われているツールです。 コードスタイルに関する議論をなくすことを目的としており、ESLintとは異なりデフォルト設定のままですぐに使えるのが特徴です。 さらに、PrettierはJS
DDDにおける認証の実装場所
こんにちは。株式会社プラハCEOの松原です。 DDDに基づいて開発しているアプリケーションの「認証」ってどこで実装するのが良いのだろう？ 対象読者 何となくDDDに関する本を読んで理解した気がする 試しにDDDに基づいてアプリケーションを実装し始めた 認証の実装をどこに書くべきかわからず詰まった 結論（オニオンアーキテクチャの場合） 実装はUI層かInfrastructure層 自分ならInfrastructure層 認証後のインターフェースはアプリケーション層 コンテキストは1つにまとめている前提（認証コンテキストを作らない場合の置き場所） UI層って何やねん DDDとの相性の良さからよく併用されるオニオンアーキテクチャの図を見ると、以下3つの層が一番外側に位置しています： UI(User Interface) Infrastructure Tests (図はこちらから引用) UIと言え
WEBエンジニアだけど1mmも確定申告が分からないので調べたのだ～～！
2月になると「確定申告の季節ですね～」と言うエンジニアがいるのだ。 ぼくも「そうですねー」と話をあわせるのだが 「確定申告」ってなんなのだあああああああ～～～～？ 実はぜんぜん知らないのだああああああああああああああ ･･･って内心は思ってるのだ。 そんなことではいけないと思い、確定申告について調べてみたのだ！ 確定申告とは？ 一言でいうと「私は今年これだけ稼ぎました！」と税務署に報告することを指すらしいのだ。 うん、それは知ってるのだ。 中学生のときに「国民は納税する義務があるよ」と教えられたのだ。 でも、具体的に いつ？ どれくらい稼いだら？ どうやって申告する？ 税金の仕組みってどうなってるの？ など詳しいことは教えられていない気がするのだ。 そこらへんを掘り下げていくのだ。 その前に：会社員は？ 会社員の場合は、源泉徴収（げんせんちょうしゅう）というやつのおかげで、確定申告をしなく
VScodeだけでGit操作を完結させるのだ～～ッ!!
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
RustでAPIを開発してみたら結構辛かった話
はじめに 皆様こんにちは、株式会社プラハのAwataです。 今日は、以前書いたリーダーの振り返り記事で軽く触れていた、RustでのAPI開発についての記事を書いていこうと思います。 結論RustでWebは辛い！という話なんですが、約5か月くらいRustでWeb開発をしたので、今後の参考になるようなことを書いていこうと思います。 ぜひ最後までお付き合いください。 TL;DR RustでWeb開発はまだ早いかもしれない。 RustでDDDはやりやすい。ただしDIがやりにくい場合があるので、そこは要注意。 Rustはモジュールの仕組みが協力なので、モジュラモノリスはやりやすい。 サンプルリポジトリはこちら Rustはやっぱり難しいけど人気の理由も少し分かった気がする そもそもなぜRustでやってみようとなったのか 前例が少ない中、どうしてRustで開発しようと思ったのか気になる方も多いと思います
技術書の予習と復習
どうも、株式会社プラハCEO兼エンジニアの松原です 最近若手エンジニアから「技術書や記事からのインプットが遅い、あるいは浅いことに悩んでいる」と相談を受けました。 (自分のインプットの巧拙はひとまず棚に上げて)自分は技術書を読む際は予習と復習を結構するタイプなので、自分なりに工夫していることについて書き残してみようと考えました。超オレオレ理論ですが、悩んでいる方の参考になれば幸いです 本の予習と復習 自分は技術書を読む前後でこんなことをしています: (予習)その本にかける時間を決める (予習)本から学びたいことを書き出す (予習)胡散臭い人に書かれたと考える (復習)仮説を作り、検証する (復習)自分の行動の変化を書き出す (復習)記事を書くか、人に話す 結構面倒だと思いますが、自分にとっては効果的でした 0. その本にかける時間を決める 自分がこれから説明する予習と復習は、めちゃくちゃ時
tRPCを導入したら爆速でWebサービスをリリースできた話
この記事は 「個人開発Advent Calendar 2022」 8日目の記事です。 はじめに 先日リリースされた、SplarateというWebサービスの開発をお手伝いしています。そこで導入したtRPCが驚くほど便利だったので、実際の体験を交えてその使いやすさを紹介します。 tRPCとは？ tRPC allows you to easily build & consume fully typesafe APIs without schemas or code generation. https://trpc.io/docs/ tRPCは、スキーマやコード生成なしで型安全なAPIを簡単に構築し、呼び出すことのできるライブラリです。 tRPC is for full-stack TypeScript developers. と謳われているように、TypeScriptに特化して作られており、Ty
マイクロサービスの再考: タダ飯なんてものはない
どうも、株式会社プラハCEO兼エンジニアの松原です。 先日かとじゅんさんがツイートで紹介していたマイクロサービスに関する論文を読むついでに、適度に意訳した内容を音声入力してみました。ついでに意訳レベルなので翻訳の質は保証できないのですが、もし内容を読んでみて少しでも興味を持てた場合は実際の論文にも目を通してみると良いかもしれません。 論文のリンク: 「これ日本語でなんて言うの？」って分からなかった部分も多々あったのでより適切な単語があったら教えてほしい...! 導入 マイクロサービスには様々なプラクティスや技術を用いて以下のメリットを目指す 素早いデリバリー 高いスケーラビリティ 自律性 しかし実際にこの業界で実装されるマイクロサービスは採用するプラクティスや効果に大きな差があるため、オンラインサーベイ(51回答)と経験豊富なマイクロサービス実践者14名にインタビューを行った。 わかったこ
100名以上のメンターをやって見えた「めちゃくちゃ伸びる人」の共通点
どうも、株式会社プラハCEO兼エンジニアの松原です。 弊社では中級エンジニアを育成するプログラミングブートキャンプ「PrAha Challenge」を2年近く運営しています。累計100名近くの方々が参加して、日々実践的な技術課題に取り組みながら、メンターと技術的な質疑応答を繰り返しています。 実はプラハチャレンジの第1期から第5期までのメンターセッションは全て私が担当しているため、累計100名近くのエンジニアの成長を間近に見てきた経験から「めちゃくちゃ伸びるエンジニアの共通点」を見つけた気がしたので、何かの役に立てばと思い、Zennにも書き残そうと考えた次第です。 ちなみに弊社が運営しているpodcastでも同じテーマについて話しているので、耳で聞く方がお好みの方がいたらぜひ以下のpodcastへ！ TL;DR めっちゃ伸びる人は 分からないことを言葉にするのが上手 情報を鵜呑みにしない
次世代SQLクライアントArctypeを触ってみる
どうも、株式会社プラハCEOの松原です 先日社内のエンジニアに「このSQLクライアントがイケてそう！」と教わったので早速Arctypeを触ってみました TL;DR クエリの補完が最高 チャートやダッシュボードを通して簡単に可視化できる 操作性に優れていて、見た目が綺麗 クエリやダッシュボードごとに権限管理できる プレースホルダーを使えば非開発者ともクエリを共有しやすい 説明しよう、Arctypeとは なんかイケてるSQLクライアントです セットアップ それぐらいしか分からないので、ひとまずDBを立ち上げて実際に使ってみようと思います。こちらのmysql-employeesを使わせていただきましょう docker run -d \ --name mysql-employees \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=college \ -v $PWD/
idをautoincrementして何が悪いの？
idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
