divではなく、spanを使ったほうが良いと思いました！ + <div>山田</div> - <span>山田</span> 文章だけで「ここはこうした方がいい」を説明するより、コードも一緒に提案してあげた方が分かりやすいです。 GitHub上だと、以下のように操作するとコードの提案ができます👇️ GitHubのリンクを貼る時はパーマリンクを使う
ブックマーク / zenn.dev/praha (12)
-
s_ryuuki 2024/10/13
-
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
-
VScodeだけでGit操作を完結させるのだ～～ッ!!
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
-
ブランチ名をもとにPRに自動でラベルを貼るGitHubActions
はじめに 弊社では、2023年11月よりOSSチームの活動がスタートしました。 このチームに参加しているメンバーは、1週間のうちの1日分の稼働をOSS活動に割り当てる事ができます。社員の技術力向上及び、日頃使わせていただいているOSSコミュニティに対する恩返しをチームのミッションとしています。 OSSチーム以前のOSS部では下記のような活動も行っていました。 今回は、OSSチームで新たに開発したGitHub Custom Actionsについて紹介させて頂きます。 GitHub Custom Actions GitHubActionsでusesの所に指定するアレです。 Docker Container ActionsやJavaScript Actions、Composite Actionsなど、さまざまな種類が存在しますが、今回はCustom Actionsの詳細な解説は省略させていただき
-
フロントエンドのテストコードを充実させるためにやったこと
まえがき （フロントエンドに限らずですが）フロントエンドの開発において、テストコードを充実させることはいいことづくめのように思えます。 機能が壊れていないことを確認しながらプロダクションコードを変更できる バグの発生に気づきやすくなる 動作確認を省ける場面が増え、開発速度が向上する テストを書きやすいように工夫してプロダクションコードを書くようになり、結果的にコンポーネントの設計やアクセシビリティを向上させることができる とはいえ、フロントエンドのテストコードを充実させるにはそれなりの工数が必要です。また、テストコードの書き方によってはメンテナンスコストもかかり、最悪の場合壊れっぱなしで放置されがちです。 プロダクトの新規開発にあたって0からフロントエンドの設計・開発環境構築をする機会があったので、フロントエンドのテストコードの書き方について調査して内容を整理しました。 前提 React/
-
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/
-
答えやすい質問、答えづらい質問
こんにちは。株式会社プラハCEOの松原です 先輩に質問したら「もうちょっと聞きたいことをまとめてくれない？」と怒られた StackOverflowに質問したけど誰も答えてくれずしばらくして通知が届いたらdownvoteだった 質問しても曖昧な回答しか返ってこなくて、お互い気まずい空気が流れる そもそも技術系の質問するのが苦手 どれか1つでも該当する方にはこの記事が役に立つかもしれません。ちなみに僕は新人時代にフルコンボだドン 最近ではプラハチャレンジのメンターとして質問を受ける側に立つことが多いのですが、「これは答えやすい」と思う質問もあれば「ちょっと答えづらい...」と思う質問もあります。かれこれメンターとして1000個近くの質問を受けて来たので、せっかくの経験を生かしてより良い質問に繋がるチェックシートを作ってみました。 相手に十分な情報を与えているか 「プログラマが知るべき97のこと
-
ドメイン知識が漏れるとは何なのか
こんにちは。株式会社プラハCEOの松原です 先日プラハチャレンジのメンターセッションで「ドメイン知識が漏れるってどういうことなの？」という話になったので、その際に話したことをまとめてみようと思いました。 こちら本日のメイン、ドメイン知識が漏れまくっているコードです： class Person { // (ドメイン) public age: number public constructor(age: number) { this.age = age } } class Usecase1 { // （アプリケーションサービス層に属するクラス。コントローラー層のメソッドの1つと捉えていただいてもOKです） do(p: Person) { if (p.age > 18) { // 18歳以上なら登録できる！ } } } class Usecase2 { // （アプリケーションサービス層に属する
-
盛大な手戻りを防ぐため、先にテストケースだけレビューしてもらう開発手法
こんにちは。株式会社プラハCEOの松原です TL;DR デキる人は完成形を見せてから詳細を進めていく 30%ぐらい完成したタイミングで完成イメージを一度見せて、齟齬がないことを確認すると良い コードも完成イメージを一度レビューしてもらってから細部を実装した方が良いのではないか テストケースだけ先に見てもらうと良いんじゃない？ 仕事がデキる人はなぜ〇〇なのか 「仕事がデキる人はなぜ〇〇なのか」みたいなビジネス書によく書いてあるテクニックがあります。それは 頼まれた仕事は30%ぐらい完成したタイミングで一度依頼主に見せて、認識齟齬がないことを確認すること よく出てくるのがプレゼンの例です： 仕事がデキないパターン 上司「今度の企画案を部長に説明するためのプレゼンを作っておいてくれ。プレゼンは1週間後ね」 部下「わかりました！」 〜1週間後〜 部下「できました！」 上司「なにこれ！全然思ってたの
-
そのテストは本当に保証したいことを保証しているのか？
こんにちは。株式会社プラハCEOの松原です。 昨今は自動テストを書かないとサバンナのライオンにまで怒られるほど自動テストの文化が浸透していますが、時々こんなテストを見かけます： フロントエンドのテスト it('allows us to set props', () => { const wrapper = mount(<Foo bar="baz" />); expect(wrapper.props().bar).to.equal('baz'); wrapper.setProps({ bar: 'foo' }); expect(wrapper.props().bar).to.equal('foo'); }); test('drinkEach drinks each drink', () => { const drink = jest.fn(); drinkEach(drink, ['lemo
-
DDDにおける認証の実装場所
こんにちは。株式会社プラハCEOの松原です。 DDDに基づいて開発しているアプリケーションの「認証」ってどこで実装するのが良いのだろう？ 対象読者 何となくDDDに関する本を読んで理解した気がする 試しにDDDに基づいてアプリケーションを実装し始めた 認証の実装をどこに書くべきかわからず詰まった 結論（オニオンアーキテクチャの場合） 実装はUI層かInfrastructure層 自分ならInfrastructure層 認証後のインターフェースはアプリケーション層 コンテキストは1つにまとめている前提（認証コンテキストを作らない場合の置き場所） UI層って何やねん DDDとの相性の良さからよく併用されるオニオンアーキテクチャの図を見ると、以下3つの層が一番外側に位置しています： UI(User Interface) Infrastructure Tests (図はこちらから引用) UIと言え
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました