Next.js って App Router が出てきて平和じゃなくなったよね
背景 Next.js に App Router が導入されてから1年近くが経ちました。しかし、未だに App Router を前提として設計のベストプラクティスが定まっておらず、身近なフロントエンドエンジニアはみな「まだプロダクトに取り入れるには考えることが多いよね」という共通認識のまま止まっているような気がしています。 また、App Router が導入されるまでは、技術選定の無難な選択肢として Next.js が最有力でした。しかし、現在は App Router の設計のプラクティスが未発達なことや、オーバースペックであるという見方が出てきており、検討しなければならないことが多くなったように感じます。 そうした中で、ではその懸念というのはどのようなものがあり、導入しずらい要因に何があるのか、というところが、今回執筆を行う上での背景になります。 App Router導入で考えないといけな
こんにちは！いつも有益な情報をご教授頂きありがとうございます。 プログラミング完全未経験からインターン獲得まで、熊崎さんだったらどのような学習をするか教えて頂けますでしょうか？具体的にはメルカリやサイバーエージェントなどでインターンすることが目標です。応募要件を見てみると経験者を求めている企業が多いと感じています(経験が必要項目になっていなくても、経験者と比較されると圧倒的に不利だと思います。) | mond
こんにちは！いつも有益な情報をご教授頂きありがとうございます。 プログラミング完全未経験からインターン獲得まで、熊崎さんだったらどのような学習をするか教えて頂けますでしょうか？具体的にはメルカリやサイバーエージェントなどでインターンすることが目標です。応募要件を見てみると経験者を求めている企業が多いと感じています(経験が必要項目になっていなくても、経験者と比較されると圧倒的に不利だと思います。) そもそもインターンが目標というのが少し立ち止まって考えて欲しい所です。ここで僕の好きな記事を一つ紹介します。Joel on Softwareという有名なブログの「Finding Great Developers」です。英文に抵抗があるならページごと機械翻訳に投げ込んでも構いませんが、僕の文脈でピックアップして伝えたい部分だけ掻い摘んで伝えます、僕によるバイアスを含むので興味を持ったら是非原文も読ん
開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ
2024/07/13 大吉祥寺.pm 20分レギュラートーク 登壇資料
【注意喚起】ReactのuseStateの値がすぐに更新されない理由を誤って理解しがちな件について - Qiita
「state 更新 反映されない」を検索するまで Reactにまだ慣れていない段階で開発をしているとuseStateの問題に詰まってこのような検索をする方は多いかなと思います。 私もその一人で、公式のチュートリアルを一通りやったにも関わらずこの問題に詰まってしまったのは忸怩たる思いでございます。 「useStateで定義した値はset関数で更新できて、useStateはフックなので実行すると画面が更新される」というのはまずReactを勉強する最初の段階で理解するでしょう。 そこで、言われた通りにuseStateで値を定義し、ユーザーの操作によって画面を更新させるコードを書きます。 import { useState } from 'react'; export default function Counter() { const [number, setNumber] = useState
「開発生産性の教科書」という本を執筆しました - Findy Tech Blog
こんにちは！ファインディ CTOの佐藤(@ma3tk)です。 表題の通り、約1年半ほどの期間をかけて「エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～」(以降、開発生産性の教科書)という本を執筆しました。 本日(2024年7月11日)発売となりましたので、改めて「開発生産性」に対する思いをお伝えしたり、本の内容の一部をご紹介したいと思います。 「開発生産性の教科書」のご紹介 エンジニア組織を強くする 開発生産性の教科書 本の概要は次のとおりです。 項目 詳細 タイトル エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ 著者 佐藤 将高、Findy Inc. 発行 技術評論社 定価 2,860円（税込） 発売日 2024年7月11日 ISBN 978-4297142490 購入 Amazon / 楽天ブックス 全
スタートアップなのにフロントエンドのテストカバレッジが90%を超えている話 | Resilire Tech Blog
はじめに サプライチェーンリスク管理クラウドサービスResilireでエンジニアをしている奥村@showkittie です。 Resilireでは、1歳の子の育児に悪戦苦闘しながら、フロントエンド、サーバサイドを問わずプロダクトエンジニアをやっています。 ResilireはシリーズAを迎えたばかりのアーリースタートアップでありながら、フロントエンドのテストカバレッジが90%を超えており、必要なケースについてはほぼテストが網羅されています。 私は今年の4月に入社したばかりですが、すでにテストカバレッジの高さに助けられ、不具合の混入をせずに済んだことが何度もあります。 今日は、Resilireのフロントエンドのテスト戦略とカバレッジの高さの理由についてお伝えしたいと思います。 スタートアップとテスト 冒頭にもお伝えした通りResilireはアーリースタートアップです。エンジニアリングに求められ
理解しやすいコードの書き方～理解容易性の7つの観点～ - Qiita
はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 （変数や関数の）名称は分かりやすくする （変数や関数の）役割は１つにする （変数や関数の）参照は狭くする （変数や関数の）状態は変えられなくする （関数やクラスの）面積は小さくする （関数や
スクラムが「上手くいってる」「上手くいってない」の頭の整理 - Mitsuyuki.Shiiba
この記事を見かけて、やっとむさんだなーやさしく伝えたんだろうなーって思いつつ。「上手くいく」「上手くいってない」って幅がありそうだよなと思ったので、頭の中の整理をしてみることにした。来週の発表の準備が煮詰まっているから気分転換しているだけともいう。 yattom.hatenablog.com やっとむさんの記事を読む 「スクラムで開発を進めている」という状況で 「問題が多い→ならば→スクラムは合わない」のか？という問いに対して やっとむさんの回答は「問題がある→ならば→スクラムは上手くいっている」 と書いてある。「合わない」は「うち（の会社）には合わない」の意味。 最初にことわっておく ふだんからいろいろとお話をされている関係性の中で伝えていて、その前後にいろんなお話をしているんだろうなと想像している。 だから、僕がここで書くようなことは、その関係性の中ですでに共有されていることだと思って
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
評価されやすいエンジニアとは、成果を効果的にアピール出来るエンジニアのこと。
こんにちは、しんざきです。週に一回ファミコン版のイーアルカンフーを遊ぶ習慣がもう15年くらい続いておりまして、そろそろ一度知見を集積しようかと思っているところです。面白いですよね、イーアルカンフー。 この記事で書きたいのは、大体以下のようなことです。 ・「評価されやすいエンジニア」とは、「ちゃんと自分の成果を言語化してアピール出来るエンジニア」です ・「アピール」というと苦手意識を持つ人が多いのですが、必要なのは自分を大きく見せることではなく、具体的な達成状況の可視化です ・「自分の成果を言語化出来るか」というのは、日々の仕事で能力を発揮する上でもとても大事です ・成果を言語化する上では、ちゃんと「ストーリー」を考えることも大事です ・ストーリーといっても、別にありもしない物語を作れという話ではなく、組織が持っているビジョンや方向性に合致する成果になっているか、という話です ・特に新人さん
その失敗から何を学ぶ？不確実性をマネジメントして目標達成するための心得 #webtan
Web担当者Forumミーティング2024春 B2-1オープニング基調講演
【プレビュー】１ヶ月1000万頂く頂き女子りりちゃんの【みんなを稼がせるマニュアル】｜ちいかわころす｜note
<a href="http://archive.today/Owyye"> <img style="width:300px;height:200px;background-color:white" src="https://archive.md/Owyye/d32517806df52b70c39151aa24937f31ec8b2131/scr.png"><br> 【プレビュー】１ヶ月1000万頂く頂き女子りりちゃんの【みんなを稼がせるマニュアル】｜ちいかわころす｜note<br> アーカイブされた 2024年5月9日 16:18:41 UTC </a> {{cite web | title = 【プレビュー】１ヶ月1000万頂く頂き女子りりちゃんの【みんなを稼がせるマニュアル】｜ちいかわころす｜note | url = https://note.com/preview/nba450e53
エラーや非同期処理をより安全に扱うための TypeScript ライブラリ Effect-TS
TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性（concurrency）：Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ（composability）：小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理（resource-safety）：処理が失敗したとしても、安全にリソースを開放する 型安全性（type-safety）：TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理（error handling）：構造化された信頼性の高い方法でエラーを処理する 非同期性（asynchronicity
先延ばし魔の頭の中はどうなっているか
Tim Urban / 青木靖 訳 2016年2月 (TED2016) 大学では政治専攻だったので、レポートを沢山書かなければなりませんでした。普通の学生がレポートを書く場合、作業量はこんな感じに分布していることでしょう。 これだと、はじめはゆっくりですが、最初の週、十分に進めておいて、後半多少負荷が高くはなっても、秩序ある状態が保たれています。私だってそんな風にやりたいと思います。予定としては、すぐ取りかかるつもりでいますが、実際にレポートをやる段になると、私の場合こんな風になってしまいます。 毎回こういうことになるんです。それから90ページの卒論を書くことになりました。１年かけて書くべきものです。いつものようなやり方が通用しないのは分かっていました。規模が大きすぎます。それで計画を立てて、こんな感じでやろうと決めました。 １年の計画です。はじめは軽く、中間で少し上がり、終盤でスパートを
仕事をがんばる“戦闘モード”が一定以上続くとどうなる？ 自分をケアするために知っておきたい「観察」の方法
本イベントは、『部下との対話が上手なマネジャーは観察から始める ポリヴェーガル理論で知る心の距離の縮め方』の出版を記念して開催されました。同書籍の著者で株式会社ロッカン代表の白井剛司氏が登壇。本記事では、観察に役立つポリヴェーガル理論と、自分の状態を自覚するための3色のモードについて解説しました。 前回の記事はこちら 観察には3つの段階がある 白井剛司氏：では、（職場に安心感やつながりを作るための）「観察」とは何だろうということですね。3つの段階があるんですけど、1番目は自分の言動パターンに気づくことです。「自分は、人から何か言われた時に『いや、そうじゃないのに』と思ったり、『こう返さなきゃいけない』と思ったりする」と気づく感じですね。 あと萎縮したり、腹が立って感情的になったり、それを我慢しようとしたりしていることに、自分なりに気づく。まずは自分に注意を向けます。2番目は、自分（の状態）
私が 1on1 でしていること - Mobile Factory Tech Blog
言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター
【スゴ本】ITエンジニアの「武器」を増やす5冊
Dain 古今東西のスゴ本（すごい本）を探しまくり、読みまくる書評ブログ「わたしが知らないスゴ本は、きっとあなたが読んでいる」の中の人。自分のアンテナだけを頼りにした閉鎖的な読書から、本を介して人とつながるスタイルへの変化と発見を、ブログに書き続けて10年以上。書評家の傍ら、エンジニア・PMとしても活動している。 わたしが知らないスゴ本は、きっとあなたが読んでいる keyboard_arrow_down はじめに keyboard_arrow_down 独学のキモは「いかに継続するか」 keyboard_arrow_down 「顧客が本当に必要だったもの」をいつ知るか？ keyboard_arrow_down チームに笑顔を keyboard_arrow_down 質の高い課題を見極める keyboard_arrow_down 技術を哲学する keyboard_arrow_down おわり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1on1ミーティングガイド (1on1ガイド)
仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた
Yahoo! 知恵袋フロントエンドをリアーキテクトしている話
