社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
![フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ](https://cdn-ak-scissors.b.st-hatena.com/image/square/1bfb7c3a61f31b8513f12bd85fbabfd9de47dfb6/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--F_dG7ohH--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%2525E3%252583%252595%2525E3%252583%2525AB%2525E3%252583%2525AA%2525E3%252583%2525A2%2525E3%252583%2525BC%2525E3%252583%252588%2525E3%252581%2525A7%2525E7%25259B%2525B8%2525E6%252589%25258B%2525E3%252581%2525AB%2525E6%2525B0%252597%2525E6%25258C%252581%2525E3%252581%2525A1%2525E3%252582%252588%2525E3%252581%25258F%2525E4%2525BB%252595%2525E4%2525BA%25258B%2525E3%252582%252592%2525E3%252581%252597%2525E3%252581%2525A6%2525E3%252582%252582%2525E3%252582%252589%2525E3%252581%252586%2525E3%252581%25259F%2525E3%252582%252581%2525E3%252581%2525AE%2525E3%252582%2525B3%2525E3%252583%252584%2525E3%252581%252582%2525E3%252582%25258C%2525E3%252581%252593%2525E3%252582%25258C%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_34%3Apenpen%252Cx_220%252Cy_108%2Fbo_3px_solid_rgb%3Ad6e3ed%252Cg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2NiNzU1NDliMzkuanBlZw%3D%3D%252Cr_20%252Cw_90%252Cx_92%252Cy_102%2Fco_rgb%3A6e7b85%252Cg_south_west%252Cl_text%3Anotosansjp-medium.otf_30%3A%2525E3%252582%2525A2%2525E3%252582%2525AC%2525E3%252583%2525AB%2525E3%252583%2525BC%2525E3%252583%252588%2525E3%252583%252586%2525E3%252582%2525AF%2525E3%252583%25258E%2525E3%252583%2525AD%2525E3%252582%2525B8%2525E3%252583%2525BC%2525E3%252582%2525BA%25252FPrAha%252Cx_220%252Cy_160%2Fbo_4px_solid_white%252Cg_south_west%252Ch_50%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzY0YmViMTBjODcuanBlZw%3D%3D%252Cr_max%252Cw_50%252Cx_139%252Cy_84%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
株式会社プラハは2022年、株式会社アガルートによるM&Aで子会社となりました。 この変化の一環として、アガルート社長自らがプロダクトオーナーのひとりとして参加する新規プロダクト開発が始まりました。プロダクトの開発はプラハの私たちが担当し、私も「開発チームのリーダー」としてそのチームに加わることになりました。 私はこれまで開発メンバーとしての経験しかありませんでしたが、エクストリームプログラミングとかレガシーコードからの脱却とかめっちゃ好きで、本で学んだプラクティスをリーダーとして実践できる機会が与えられて最高にハッピーでした。しかも、プロダクトオーナーの一人として参加するアガルート社長はこれまで伝統的な開発手法しか経験したことがないとのことで、新たな開発の進め方を経験してもらう絶好の機会でもありました。 やったこと 「欲しい機能一覧」を受け取ったが、いったん白紙に戻した プロジェクトが始
この記事はPrettierを使用している人を非難したり、脱Prettierを推奨する事を目的としていません。 こういった考え方もあるということをひとつの意見としてご覧いただければ幸いです。 勘違いしている人が多そうなので追記します。 Prettierを使わないというのは私が独断で決めた事ではないです。 チームが発足する際の技術選定で合意は取れていますし、私が関与していない別のチームでも同様にPrettier無しで開発しています。 私達のチームはメンバー同士を互いに信頼していますし、細いスタイルで喧嘩を始めるようなメンバーは居ないので安心してください。 はじめに Prettierはコードフォーマッターとして広く使われているツールです。 コードスタイルに関する議論をなくすことを目的としており、ESLintとは異なりデフォルト設定のままですぐに使えるのが特徴です。 さらに、PrettierはJS
2月になると「確定申告の季節ですね~」と言うエンジニアがいるのだ。 ぼくも「そうですねー」と話をあわせるのだが 「確定申告」ってなんなのだあああああああ~~~~? 実はぜんぜん知らないのだああああああああああああああ ・・・って内心は思ってるのだ。 そんなことではいけないと思い、確定申告について調べてみたのだ! 確定申告とは? 一言でいうと「私は今年これだけ稼ぎました!」と税務署に報告することを指すらしいのだ。 うん、それは知ってるのだ。 中学生のときに「国民は納税する義務があるよ」と教えられたのだ。 でも、具体的に いつ? どれくらい稼いだら? どうやって申告する? 税金の仕組みってどうなってるの? など詳しいことは教えられていない気がするのだ。 そこらへんを掘り下げていくのだ。 その前に:会社員は? 会社員の場合は、源泉徴収(げんせんちょうしゅう)というやつのおかげで、確定申告をしなく
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に! この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯) 以下のようにするのだ。 +ボタンをクリック:ステージングする ーボタンをクリック:ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい? これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
はじめに 皆様こんにちは、株式会社プラハのAwataです。 今回は、直近の開発において、マイクロサービスを検討をしたがモジュラモノリスを採用した経緯を書いていこうと思います。 案件の詳細に興味がある方は、以前書いたリーダーの振り返り記事を読んで頂ければと思います。 ※マイクロサービスやモジュラモノリスが何なのか?というそれぞれの詳細にはこの記事では触れませんのでご注意ください。 TL;DR マイクロサービスは思ったよりも難しい 組織的な問題がないならマイクロサービスはきっとまだ早い 将来的にマイクロサービスにするかもしれないなら、モジュラモノリスがいいかもしれない なぜマイクロサービスを検討したか 今回の案件では、既存システムとの連携が必須でしたが、既存システムのコードがかなり汚く、手を入れることが難しい状態でした。 そのため、既存システムのコードは極力触らずに新規サービスを開発したいと考
はじめに 皆様こんにちは。 私事ですが、もうすぐチームリーダーになって1年が経ちます。 そこで、今回はチームリーダー1年目に読んでよかった書籍5選を紹介したいと思います。 記載している順番に特に意味はないので、気になった本があればぜひ読んでみてください。 また、初めてチームリーダーを務めた案件の振り返り記事もこちらに書いていますので、もし興味があればぜひ読んでみてください。 そもそもチームリーダーに求められる能力って? 書籍の紹介に入る前に、少しだけ雑談にお付き合いください。 皆さんは、チームリーダーに求められるのはどんな能力だと思いますか? 私は、「チームの成果を最大化できること」だと思います。 (この後紹介する書籍の受け売りです) おそらくこれまでメンバーとして働いてきた人にとって、自分だけでなくチームとして成果を最大化するためには、新しい考え方や働き方を取り入れる必要があります。 例
どうも、株式会社プラハCEO兼エンジニアの松原です 最近若手エンジニアから「技術書や記事からのインプットが遅い、あるいは浅いことに悩んでいる」と相談を受けました。 (自分のインプットの巧拙はひとまず棚に上げて)自分は技術書を読む際は予習と復習を結構するタイプなので、自分なりに工夫していることについて書き残してみようと考えました。超オレオレ理論ですが、悩んでいる方の参考になれば幸いです 本の予習と復習 自分は技術書を読む前後でこんなことをしています: (予習)その本にかける時間を決める (予習)本から学びたいことを書き出す (予習)胡散臭い人に書かれたと考える (復習)仮説を作り、検証する (復習)自分の行動の変化を書き出す (復習)記事を書くか、人に話す 結構面倒だと思いますが、自分にとっては効果的でした 0. その本にかける時間を決める 自分がこれから説明する予習と復習は、めちゃくちゃ時
どうも、株式会社プラハCEO兼エンジニアの松原です。 先日かとじゅんさんがツイートで紹介していたマイクロサービスに関する論文を読むついでに、適度に意訳した内容を音声入力してみました。ついでに意訳レベルなので翻訳の質は保証できないのですが、もし内容を読んでみて少しでも興味を持てた場合は実際の論文にも目を通してみると良いかもしれません。 論文のリンク: 「これ日本語でなんて言うの?」って分からなかった部分も多々あったのでより適切な単語があったら教えてほしい...! 導入 マイクロサービスには様々なプラクティスや技術を用いて以下のメリットを目指す 素早いデリバリー 高いスケーラビリティ 自律性 しかし実際にこの業界で実装されるマイクロサービスは採用するプラクティスや効果に大きな差があるため、オンラインサーベイ(51回答)と経験豊富なマイクロサービス実践者14名にインタビューを行った。 わかったこ
どうも、株式会社プラハCEO兼エンジニアの松原です。 弊社では中級エンジニアを育成するプログラミングブートキャンプ「PrAha Challenge」を2年近く運営しています。累計100名近くの方々が参加して、日々実践的な技術課題に取り組みながら、メンターと技術的な質疑応答を繰り返しています。 実はプラハチャレンジの第1期から第5期までのメンターセッションは全て私が担当しているため、累計100名近くのエンジニアの成長を間近に見てきた経験から「めちゃくちゃ伸びるエンジニアの共通点」を見つけた気がしたので、何かの役に立てばと思い、Zennにも書き残そうと考えた次第です。 ちなみに弊社が運営しているpodcastでも同じテーマについて話しているので、耳で聞く方がお好みの方がいたらぜひ以下のpodcastへ! TL;DR めっちゃ伸びる人は 分からないことを言葉にするのが上手 情報を鵜呑みにしない
どうも、株式会社プラハ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/
こんにちは。株式会社プラハCEOの松原です。 DDDに基づいて開発しているアプリケーションの「認証」ってどこで実装するのが良いのだろう? 対象読者 何となくDDDに関する本を読んで理解した気がする 試しにDDDに基づいてアプリケーションを実装し始めた 認証の実装をどこに書くべきかわからず詰まった 結論(オニオンアーキテクチャの場合) 実装はUI層かInfrastructure層 自分ならInfrastructure層 認証後のインターフェースはアプリケーション層 コンテキストは1つにまとめている前提(認証コンテキストを作らない場合の置き場所) UI層って何やねん DDDとの相性の良さからよく併用されるオニオンアーキテクチャの図を見ると、以下3つの層が一番外側に位置しています: UI(User Interface) Infrastructure Tests (図はこちらから引用) UIと言え
idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか?」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・! 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ?「人としてそれはやっちゃダメで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く