タグ

ブックマーク / zenn.dev/praha (5)

  • RustでAPIを開発してみたら結構辛かった話

    はじめに 皆様こんにちは、株式会社プラハのAwataです。 今日は、以前書いたリーダーの振り返り記事で軽く触れていた、RustでのAPI開発についての記事を書いていこうと思います。 結論RustでWebは辛い!という話なんですが、約5か月くらいRustでWeb開発をしたので、今後の参考になるようなことを書いていこうと思います。 ぜひ最後までお付き合いください。 TL;DR RustでWeb開発はまだ早いかもしれない。 RustでDDDはやりやすい。ただしDIがやりにくい場合があるので、そこは要注意。 Rustはモジュールの仕組みが協力なので、モジュラモノリスはやりやすい。 サンプルリポジトリはこちら Rustはやっぱり難しいけど人気の理由も少し分かった気がする そもそもなぜRustでやってみようとなったのか 前例が少ない中、どうしてRustで開発しようと思ったのか気になる方も多いと思います

    RustでAPIを開発してみたら結構辛かった話
  • マイクロサービスの再考: タダ飯なんてものはない

    どうも、株式会社プラハCEOエンジニアの松原です。 先日かとじゅんさんがツイートで紹介していたマイクロサービスに関する論文を読むついでに、適度に意訳した内容を音声入力してみました。ついでに意訳レベルなので翻訳の質は保証できないのですが、もし内容を読んでみて少しでも興味を持てた場合は実際の論文にも目を通してみると良いかもしれません。 論文のリンク: 「これ日語でなんて言うの?」って分からなかった部分も多々あったのでより適切な単語があったら教えてほしい...! 導入 マイクロサービスには様々なプラクティスや技術を用いて以下のメリットを目指す 素早いデリバリー 高いスケーラビリティ 自律性 しかし実際にこの業界で実装されるマイクロサービスは採用するプラクティスや効果に大きな差があるため、オンラインサーベイ(51回答)と経験豊富なマイクロサービス実践者14名にインタビューを行った。 わかったこ

    マイクロサービスの再考: タダ飯なんてものはない
  • 100名以上のメンターをやって見えた「めちゃくちゃ伸びる人」の共通点

    どうも、株式会社プラハCEOエンジニアの松原です。 弊社では中級エンジニアを育成するプログラミングブートキャンプ「PrAha Challenge」を2年近く運営しています。累計100名近くの方々が参加して、日々実践的な技術課題に取り組みながら、メンターと技術的な質疑応答を繰り返しています。 実はプラハチャレンジの第1期から第5期までのメンターセッションは全て私が担当しているため、累計100名近くのエンジニアの成長を間近に見てきた経験から「めちゃくちゃ伸びるエンジニアの共通点」を見つけた気がしたので、何かの役に立てばと思い、Zennにも書き残そうと考えた次第です。 ちなみに弊社が運営しているpodcastでも同じテーマについて話しているので、耳で聞く方がお好みの方がいたらぜひ以下のpodcastへ! TL;DR めっちゃ伸びる人は 分からないことを言葉にするのが上手 情報を鵜呑みにしない

    100名以上のメンターをやって見えた「めちゃくちゃ伸びる人」の共通点
  • 消す前提で機能を作ろう

    どうも、株式会社プラハCEOの松原です 先日プラハチャレンジの参加者と雑談していた際に 消す前提で機能を作ると保守性が上がるかもしれない という内容に触れたので、思ったことを記事にまとめてみました。 企画には必ず切り戻し条件を明示する 少し話が脱線しますが、僕はエンジニアになる前はWEBサービスの新規事業企画を担当していて、当時所属していたチームではサービスに追加機能を立案するときは 何が起きたらこの機能を削除するのか という「切り戻し条件」がセットで求められていました。 例えば求人サイトの応募を増やしたいな〜と考えて新機能を立案するとしたら、こんな感じ: 機能概要:スマホ閲覧者にはフッターに応募ボタンを表示する 切り戻し条件:実験的に追加した画面の求人応募率が逆に5%低下したらフッターを削除する 機能を追加しているとき自分はサービスを改善しているように感じがちですが、正確には機能を追加す

    消す前提で機能を作ろう
  • 盛大な手戻りを防ぐため、先にテストケースだけレビューしてもらう開発手法

    こんにちは。株式会社プラハCEOの松原です TL;DR デキる人は完成形を見せてから詳細を進めていく 30%ぐらい完成したタイミングで完成イメージを一度見せて、齟齬がないことを確認すると良い コードも完成イメージを一度レビューしてもらってから細部を実装した方が良いのではないか テストケースだけ先に見てもらうと良いんじゃない? 仕事がデキる人はなぜ〇〇なのか 「仕事がデキる人はなぜ〇〇なのか」みたいなビジネス書によく書いてあるテクニックがあります。それは 頼まれた仕事は30%ぐらい完成したタイミングで一度依頼主に見せて、認識齟齬がないことを確認すること よく出てくるのがプレゼンの例です: 仕事がデキないパターン 上司「今度の企画案を部長に説明するためのプレゼンを作っておいてくれ。プレゼンは1週間後ね」 部下「わかりました!」 〜1週間後〜 部下「できました!」 上司「なにこれ!全然思ってたの

    盛大な手戻りを防ぐため、先にテストケースだけレビューしてもらう開発手法
  • 1