エンジニア3年目までに読んで良かった書籍 - Yuki Watanabe's Blog
未経験からエンジニアになり3年が経ちました。 この3年間はベテランエンジニアとの差を埋めるべく、プライベートの時間の大半を学習に充ててきました。幸い少しずつ成長を感じられ、業務では難易度の高い仕事を任せてもらえるようになったと感じます。このキャッチアップのために100冊以上の技術関連書籍を読んだことでしょう。 ここ最近、知人やTwitter経由で知り合った方から、私が学習に使った書籍について質問を頂くことが多いです。そこで、今後参照していただきやすいように、これまで私が読んで良かった書籍を1つの記事にまとめようと思います。 前提：エンジニアとして経験した技術 書籍について 全エンジニア向け Web / インターネット イラスト図解式 この一冊で全部わかるWeb技術の基本 (★) HTMLコーダー＆ウェブ担当者のための Webページ高速化超入門 (★) Webを支える技術 -HTTP、URI
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
[研究室向け]なぜ君はソースコードのエラーを自分で解決できないのか？ - Qiita
1. Intro 1.1 タイトルの答え それは，最初から"How"(どうやってこの問題を解決すべきか)だけを考えているからです． 最初に問うべきなのは"Why"(なぜこの問題が起きたか)です． このタイトルの問いも，なぜ？から始まっています．「どうやって自分でエラーを解決するか」だけを考えていると，問題の根本的な原因が分からないため，ずっと自分でエラーを解決することはできません． 1.2 Keyword 最初に自分に問いかけるべき言葉 〇 Why(なぜ？): なぜこの問題が起きたか ✕ How(どうやって？): どうやってこの問題を解決すべきか 1.3 背景 研究室では毎年，いつまでたっても自分でソースコードのエラーや出力の問題を解決できず，進捗が遅かったり開発をあきらめてしまったりする人が発生する．本記事では，なぜ自分でエラー・問題を解決できないのか？を明確にする． <注意書き> この
![[研究室向け]なぜ君はソースコードのエラーを自分で解決できないのか？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/dc9ae9dc576dac7161be1e28e1f8b0fb3d5bbc8b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU3JUEwJTk0JUU3JUE5JUI2JUU1JUFFJUE0JUU1JTkwJTkxJUUzJTgxJTkxJTVEJUUzJTgxJUFBJUUzJTgxJTlDJUU1JTkwJTlCJUUzJTgxJUFGJUUzJTgyJUJEJUUzJTgzJUJDJUUzJTgyJUI5JUUzJTgyJUIzJUUzJTgzJUJDJUUzJTgzJTg5JUUzJTgxJUFFJUUzJTgyJUE4JUUzJTgzJUE5JUUzJTgzJUJDJUUzJTgyJTkyJUU4JTg3JUFBJUU1JTg4JTg2JUUzJTgxJUE3JUU4JUE3JUEzJUU2JUIxJUJBJUUzJTgxJUE3JUUzJTgxJThEJUUzJTgxJUFBJUUzJTgxJTg0JUUzJTgxJUFFJUUzJTgxJThCJUVGJUJDJTlGJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05MjkxODQ4MWM1Y2M2ZWE1M2M3NTE4YTcwZTg2N2NmMA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwa29raTIwMjImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zMiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWFjMGY0Mjc5NDg4YTRjNjE3YmJkN2UwMDM1YmIzYWNl%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D449e447b533b76e2a2cfa6d32f1a6826)
デバッグが早い人と遅い人の違い
会社にデバッグの早い人と遅い人がいる。 二人を観察していると、色々な違いが見れて勉強になる。 いくつかまとめてみる。 ・デバッグが早い人はコードに着手する前に状況を整理する 期待動作はどのようなものか、現状の動作（バグ）はどんなものか、どんな条件でバグが生じるか、生じないかを整理する 他人からアサインされたタスクの場合、手早くこれらを質問して状況を確認する。 デバッグが遅い人は何も考えずにコードを触り始める。 「何をデバッグしているの？」と聞くと言語化出来ない。 場当たり的、五月雨式に質問する。 ・デバッグが早い人は仮説を持っている。 ざっくりと全体像を把握し、当たりをつけてから作業する。 全ての作業が仮説の検証作業。結果が出た時に次に何をすべきかも把握している。 デバッグが遅い人は自分でも何をやっているか分かっていない。 「よくわからないけど一応2回試してみた」とか言う。 「それは今何を
Semantic Commit Messages
semantic-commit-messages.md Semantic Commit Messages See how a minor change to your commit message style can make you a better programmer. Format: <type>(<scope>): <subject> <scope> is optional Example feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in present tense. | +-------> Type: chore, docs, feat, fix, refactor, style, or test. More Examples: feat: (new feature for the user, not a
「データ分析の民主化」の在り方を、「社員全員Excel経営」が「社員全員データサイエンス経営」へと進化していった事例に見る - 渋谷駅前で働くデータサイエンティストのブログ
以前こんな記事を書いたことがあります。 「社員全員Excel経営」で名高い、ワークマン社のサクセスストーリーを論評したものです。2012年にCIOに就任した土屋哲雄常務のリーダーシップのもと、取引データの完全電子化を皮切りに「全社員がExcelを使いこなして数字とデータで経営する」戦略へと移行し、社内のExcelデータ分析資格を一定以上取得しないと管理職に昇進できないとか、はたまた幹部クラスの企画・経営会議ではデータに基づかない議論や提案は相手にすらされないとか、「Excelを社員全員が使えるようになるだけでもここまで企業カルチャーは変わり得るのか」という事例のオンパレードで、関連記事や書籍を読んでいて舌を巻いたのを覚えています。まさしく「ワークマンのすごいデータ活用」だったのです。 一方、個人的に強く印象を受けたのが土屋常務が様々なところでコメントしていた「我が社には突出したデータサイエ
【あなたのことを】 GitHubの設定でmainブランチの誤更新を防止しよう 【守りたい】 | DevelopersIO
「よし、修正完了！」 「作業ブランチにpushしてプルリク作成するかー」 「git push っと」 「あ、やべ、今mainブランチだわ。。pushちゃった。。」 こんなことってありませんか？ 自分が進めているプロジェクトでは、基本的にプルリクエストが承認されなければmainブランチにマージできない運用となっています。 しかし、GitHubの設定によっては上記のようなミスが起こりうるので、あらためて設定を整理してみました。 プルリクエスト作成時に特定の人物をレビュアーに指定する GitHubのcode ownersという機能を使い、プルリクエスト時にチームメンバーなどをレビュアーに指定できます。 リポジトリに.github/CODEOWNERSというファイルを作成し、レビュアーに指定したいアカウント名を指定します。 .github/CODEOWNERS # @hoge, @fuga, @f
先輩エンジニアから「メモリを意識してプログラムを書かないやつは三流だ」と言われたのですが、今は令和ですよと言いたかったです。メモリを意識してプログラムを書く必要性を分かりやすく教えて頂けませんか？
回答 (25件中の1件目) 令和だろうがなんだろうが意識はしてないとダメだと思いますよ。 ハードウェア資源の限られた組み込み系やゲーム系は別として、業務系でもWeb 系でも 1バイトでも少なくなるように無駄を削るみたいなことはしなくてもいいでしょうし、たいていは解放漏れも意識しなくて良くなってます。 昭和〜平成初期のハードウェア/ ソフトウェア事情から考えれば、およそ足りなくなることが考えられないような大量のメモリーを使えはしますが、無限ではありません。 メモリー搭載量は予算次第で増減しますしね。 そして使えるメモリーの量よりも知識や想像力の欠如、考えなしのプログラミングからくる...
納品ドキュメントの作成にMarkdown+Vivliostyleを採用した話 - Qiita
こんにちは、製造業でソフト開発エンジニアをやっているとみー(@tommyecguitar)です。 会社で納品物の説明ドキュメントを作ることがあり、その時にMarkdownでの組版をやってみたので、どう運用したか、困ったところ、いい点、悪い点をまとめてみようと思います。 Vivliostyleで組版したブログはたくさんあるので、見た目がどんな感じにできるかなどはそちらを見ていただくか、Vivliostyleのサイトをご覧ください。 Wordじゃだめなのか。 製造業で何かしら長大なドキュメントを作るとなったら、大抵はWordを複数人数で編集するという運用をしているところが多いと思います。 しかし、Wordにはいろいろと悪いところがあります。 チーム内で共同編集すると、編集したところが消えたり、フォントやデザインがなぜか統一されなかったりする。 セクションごとに担当を分けても、マージが手作業にな
致命的なバグを含まない最新版MySQLを探すには？ 『MySQL徹底入門』共著者が語る、バージョン選びのポイント
MySQLの実運用とこれからについて掘り下げる「LINE Developer Meetup #73 - MySQL」。ここで登壇したのは、LINEの従業員でもある日本MySQLユーザ会のyoku0825氏。MySQL 8.0.28を選んだ経緯や評価のポイントについて説明しました。 セッションの要約と登壇者の自己紹介 yoku0825氏（以下、yoku0825）：「ぼくらが選んだ次のMySQL 8.0」の話をします。私たちは、次のMySQLを8.0.28にしました。みなさんには、それぞれ29や30や自分の使いたいバージョンについて調べてもらいたいのですが、量が膨大になるので、今いるバージョンから新しいほうに向かって調べていくのではなく、最新のものからこれはダメだというものまで遡って調べていくのがおすすめです。 パラメーターに現れない、いきなり挙動が変わるかもしれないものは「What Is N
Neovimを一瞬でVSCode並みに便利にする - k0kubun's blog
去年8年ぶりに vimrc を書き直した時はLSPの体験があんまりよくなくてLSPなしでNeovimを使い続けていたのだが、様々な言語のOSSをメンテする都合で用途に応じてIntelliJとVSCodeとNeovimの三刀流で暮らしていた結果、可能ならNeovimに寄せたいけどそれならLSPを使いたいなということになり、今回LSPの所を真面目に設定し直して、かなり良い体験になっている。 正直Neovimの設定はVSCodeのそれに比べたら面倒なんじゃないかという印象がありサボっていた節があるが、実際にやってみるとVSCodeと同程度に簡単に済む方法もあったので紹介したい。 何故Neovimなのか LSPの話の前に、タイトルだけ見た人がそもそも単にVSCode使えばいいじゃんと言いそうなので、どうしてIntelliJやVSCodeではなくNeovimに揃えようと思ったのかについて書いておく。
techに薦めている書籍｜ばんくし
お久しぶりです。CADDiの河合、もとい@vaaaaanquishです。 数ヶ月前、CADDi社内で「オススメ書籍」というものを書きました。 社内にも公開し読み会などを開いています私は前職の上司の影響でビジネス書を多く読むようになったのですが、ゴリゴリの技術書でない書籍というのはどうしてもエンジニアにとって読みにくい物も多いなと思っています（悪いと言っている訳ではなく飲み込みのために行動や知識を求められるよねという意です）。 また、エンジニア向けの書籍でも、少し概念的に古く、現代に適応しにくいものもあったりします（名著は名著である事には変わりないですがエンジニアリングもIT分野も年々進化し続けているので一部現代で扱いづらい概念が出てくるのは当たり前だよねとも思います）。 なので、なるべく「エンジニアが読みやすく」「比較的新しい環境で使える」をテーマに書籍を選び、比較的本を読む数の多くないエ
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
実践！ ユニットテスト入門
PHPカンファレンス沖縄2022の登壇資料です。 発表時間の関係で収まりきらなかった内容を大幅に加筆しています。 以下プロポーザルの内容を転記。 ---- テスト書いてますか？ テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。 テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。 サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。 ■ 概要 ・なぜテストコードを書くのか ・レガシーコードとは、テストのないコード ・テストはコストが安いフィードバックループである ■ 実践編 ・テストケースは日本語で書こう ・いろんな assertion を知ろう ・arrange / act / assertion のテストコード実装パターン ・set up / te
AndroidアプリをMaterial Designのガイドラインに準拠させるための取り組み - ZOZO TECH BLOG
はじめに ZOZOTOWN開発本部ZOZOTOWNアプリ部Android2ブロックの鈴木（@s1u2z1u3ki）です。 本投稿ではZOZOTOWN Androidアプリを、Material Designに準拠したUI/UX1とするために取り組んでいる内容を紹介します。 目次 はじめに 目次 Material Designとは？ Material Design勉強会について 勉強会の流れ 存在した課題 課題解決へのアプローチ 提案会の実施 提案会の流れ 1. 提案会の準備 2. セクションの復習 3. 提案内容の議論 実装会の実施 「結局やらない」をなくすため モブプロ形式でリリースまでのスピードを上げるため 実装会の流れ 1. タスクの共有 2. タスクを進める 3. 進捗記入 4. 進捗共有 取り組みの結果 リリースした提案 1. ログイン画面のテキストフィールドのフォーカスを強調する
セキュリティエンジニアのための English Reading | デジタル人材の育成 | IPA 独立行政法人 情報処理推進機構
背景 私たちは中核人材育成プログラム 第5期受講生として、1年間にわたり様々な講義を受け、演習を実施してきました。その過程で、変化し続けるサイバーセキュリティの世界では、世界中の情報を的確に収集し成長を続けることが大事であることを学びました。 世界中の情報を利用するためには英語の力、中でもリーディングの力が不可欠です。しかし、私たち日本のセキュリティエンジニアの多くは英語に苦手意識を持っており、的確な情報活用ができていないのが現状です。 本プロジェクトは、日本のセキュリティエンジニアの情報収集力・成長力レベルアップのため、その手段としての英語リーディングの意欲・能力向上を目指して企画されました。実務や学習にお役立ていただければ幸いです。 想定利用者 日本語話者のセキュリティエンジニア全般ですが、中でも「ユーザー企業や官公庁で働く実務担当者」を主なターゲットとしています。「英語はちょっと……
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
VScodeの設定（settings.json）まとめ【2023年4月更新】
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
ソフトウェアアーキテクチャの基礎: Software Architecture in a Nutshell
