はてなブックマーク

はじめに 身の回りでは新卒研修の準備などが進む中、もし自分が新卒に伝えたいことがあるとしたらなんだろう？と考えてみたところ、 これは健康の大切さだなと思い立ち、この記事を書いています。 （とはいえ、新卒以外の方々にも役に立つ内容になっているかとは思います。） 自分は新卒時（前職）に終電ギリギリまで働き、土日も出社して、それを数ヶ月続けて、体調を崩し、休職した経験があります。 ※この働き方は強制されたものではなく、自分で選択した働き方です。 当時思うと新卒なのだから早く戦力にならないといけない！、新卒研修早く終わらせて実務に入らないといけない！という気持ちが先行していました。 あとは激務が正解だと思っていました。 そして体調を崩してから1ヶ月後くらいに職場復帰をしました。 体調を崩した時の辛さなどは生々しく書けるのですが、それはこの記事で伝えたいことではないので省略します。 あとは現職中での

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 株式会社Hajimariが展開するプロパートナーズサービス（フリーランスと企業様のマッチング支援事業を展開しています）を利用していただいている、 稼働者・企業担当者の双方に提供している自社開発の稼働管理ツール【Haijmari Works】のプロダクトオーナーをやっています。 野澤です。 今回は実例マッピングをチームで何回かやってみて、さまざまなことを学びながら、やっと最近チーム内で標準化するところまでやったのでその過程や学んだこと、ステークホルダーの方々の声、実際にどういうルールで実例マッピングをやっていくことにしたのかの紹

はじめに 今携わっているプロジェクトの中で自分はテックリードとして動いていたのですが、9月からプロダクトオーナーが転職してしまうということで、自分がその役割を引き継ぐことになりました。 プロダクトオーナーは初めてやるので様々な本を読んでインプットをしていたのですが、 その中で『プロダクトマネージャーのしごと』を読んでいたときに第7章の『「ベストプラクティス」のワーストなところ』を読んでとても衝撃を受け、自分自身の経験と共に記事としてまとめたいと思い、この記事を書いています。 この記事でいうベストプラクティスについて 本や記事に書いてあるような、動画で取り上げられているような「こうしたらうまくいく」「こうしたら良い」「こうするべき」「こうやったらうまくいった」などのことを全般を指していると思ってください。 ベストプラクティスを信じすぎていた新卒1年目、2年目 新卒で入った会社はECサイトのパ

はじめに 6月に凄腕エンジニアさんから学んだ例外の話というQiita記事を書かせていただいたところ、かなり反響がありました。（2023年07月08日時点で570いいね、550ストック、はてなブックマークが560usersにブックマークされています） コメントなども目を通させていただいたところ、自分に基本的な例外の知識が足りないなと思ったので、いろいろな記事に目を通したり、本を読んだりして、インプットしました。 そのアウトプットとして今回記事を書きます。 エラーと例外 この記事ではエラーと例外という二つの概念は同じ概念で交換可能なものとして扱います。 （ソフトウェア設計のトレードオフと誤りより引用） Javaでは【プログラムではどうにもできない事態が起きた時に発生するものがエラー、そうではないものは例外】というような考え方があったり、他にも【想定内であれば例外、想定外であればエラー】という考

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 凄腕エンジニアさんから学んだ例外の話、たくさん読んでいただけているみたいでありがとうございます。 はてなブックマークのコメントなども読ませていただき、勉強させていただいています。 コメントを読んでみて、自分の記事がちょっと誤解を与えてしまっている部分もあるのかもしれない。。。と感じましたので、今回補足記事としてこの記事を書きます。 【例外が起こった時の挙動を決めるのはプレゼンテーション層】について この表現によって、例外は常にプレゼンテーション層でtry-catchをするものなんだと誤解を与えてしまったかもしれません。 この表

はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth

はじめに 最近コードを書いていてふと、今の自分は以前とは全く違う思考でコードを書くようになってるな。。。と気づいたので、少しまとめたいと思います。 以前 「本でこういうコードの書き方が良いって書いてあったな〜」 「本でこういうコードの書き方だめって書いてあったな〜」 「凝集度あげるためにデータとメソッドは一箇所にまとめた方がいいな〜」 「単一責務の原則に反しているからなおさないとな〜」 ↓ 実際に改善 ↓ 「よし綺麗になった」 最近 「使いやすい形のインタフェースになっているかな？」 「メンテのためにも共通化しておいたほうが良いな。。。」 「どういうデータ構造で持っておくのが嬉しいだろうか？」 「直感的に理解できるようになっているだろうか？意図などは伝わるかな？」 ↓ 実際に改善 ↓ 結果的に綺麗になっている 以前と最近との違いは？ 以前と最近の主な違いは、思考の過程で具体的に自分のコード

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 管理画面を開発しているときに、いくつかポイントがあるなと思ったのでアウトプットします。 現場で行われるやり取りやコミュニケーションを考慮する URLでの共有 現場では 「こういう検索結果のこういうユーザーに対してこういう操作をしてください！」 というふうに他の人にURLを共有して指示を出したり、 「今月の対象はこの人達だから、確認お願い！」 というふうにコミュニケーションを取りながら業務を進めます。 ある状態のページをURLを通して共有したいことは多々あります。 URLに状態をもたせることは重要ですし、URLで表現できたら便利

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 運が良いことに自分は今、今まで出会ってきたエンジニアの中で一番凄いと思う人と一緒に働けています。 今の会社で働けていてよかったな〜と日々感謝しつつ、一緒に働いている中でたくさんのことを勉強させていただいています。 そしてそろそろアウトプットせねば！（使命感）と思いこの記事を書いています。 今回は技術以外のことで学んだこと、大切だと思ったことを書いていきます。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） （どれくらい凄いのかも本当は書きたいですが、この記事の目的とは離れてしまうので省略します。。。）

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最初に 皆さんはドキュメントとどのように付き合っていますか？ 前職はベンチャー企業ではあったのですが、割とウォーターフォールに近く、決められた仕様を満たしていればOKというふうな感じだったので、 仕様書を書いて、エンジニア数人で仕様書レビューをして、OKが出たら実装して、テスト前にテスト仕様書書いてテスト仕様書のレビューして。。。というふうに開発を行っていました。 今はスクラムマスターがいる環境でアジャイルで開発を行っています。 ドキュメントに関しては特に決まりはなく、開発者が書いたほうがいいなと思ったタイミングで書かれています。 ドキ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回は外部キーを張るときに最低限意識したいことについて書きました。 何か間違えがあったり、もっとこういうところも意識してますという人がいたらコメントお願いします。 この記事で伝えたいこと ①リレーションシップ先のデータを消したときに同時にリレーションシップ元のデータが消えても自然な状態を作る ON DELETE CASCADEをうまく利用できる状態を作る つまり親子関係を正確に表現する。 リレーションシップ先は親テーブル、リレーションシップ元は子テーブルを意味しています。 ②データを作成するときのことを考えてデータの生成順序が