エンジニア3年目までに読んで良かった書籍 - Yuki Watanabe's Blog
未経験からエンジニアになり3年が経ちました。 この3年間はベテランエンジニアとの差を埋めるべく、プライベートの時間の大半を学習に充ててきました。幸い少しずつ成長を感じられ、業務では難易度の高い仕事を任せてもらえるようになったと感じます。このキャッチアップのために100冊以上の技術関連書籍を読んだことでしょう。 ここ最近、知人やTwitter経由で知り合った方から、私が学習に使った書籍について質問を頂くことが多いです。そこで、今後参照していただきやすいように、これまで私が読んで良かった書籍を1つの記事にまとめようと思います。 前提：エンジニアとして経験した技術 書籍について 全エンジニア向け Web / インターネット イラスト図解式 この一冊で全部わかるWeb技術の基本 (★) HTMLコーダー＆ウェブ担当者のための Webページ高速化超入門 (★) Webを支える技術 -HTTP、URI
より良い Git コミットメッセージを書こう - Qiita
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか？ それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール （「How to Write a Git Commit Message」の和訳記事） https://
主にたかし君が活躍するIT応用問題 (2ページ目)
こめ @come25136 #IT系応用問題 たかし君は納期が迫っているプロジェクトの仕様変更を受け入れてしまいました 納期日のたかし君の生存確率を求めなさい。 2018-02-13 14:22:38 倉瀬美都 @clausemitz #IT系応用問題 たかし君はSES会社員で出向先で１ケ月後に発売予定の組み込み機器の新聞記事を持った担当者から開発を命じられました。ところが仕様書と称するのは前の機種のソースで「これを解析して作って」と言われました。 たかし君が担当者に暴力をふるう確率を求めてください。 2018-02-13 14:30:49 手動人形 @Manualmaton #IT系応用問題 たかし君は念願叶って独立系のソフトウェア開発会社に入社しました。最新で高速の開発機に囲まれ、優しく教えてくれる先輩たちとホワイトな社風の中、ふとたかし君が言い放った 「皆さんオススメのエディタを教え
主にたかし君が活躍するIT応用問題
黒ブラ @Clorets8lack たかしくんは派遣先が独自に開発したフレームワークを使ってプログラム開発をしています。 たかしくんがフレームワークの問題点を修正したり、便利にする活動を通じてスキルアップし、今よりも条件の良い会社に転職できる確率を求めなさい。（5点） #IT系応用問題 2018-02-12 12:51:48 黒ブラ @Clorets8lack たかしくんは情報システム部員です。 監査部からシステムのログを送って欲しいとの依頼を受け、社内メールに添付して送りました。 監査担当者から添付ファイルの開き方が分からないというクレームを受ける確率を求めなさい。（5点） #IT系応用問題 2018-02-12 13:06:31 黒ブラ @Clorets8lack たかしくんはユーザー企業の情報システム部員です。 現状問題なく稼動している通信回線を同グループの系列ベンダに切替えるよう、
漫画編集者の端くれだったことがある
青年向け漫画の編集者をしていた。といっても若い頃の話だ。都内にある編集プロダクションを辞めて田舎に帰ったのが36の時だから、おじさんの入り口に立った頃か。今では完全なるおじさんである。 ※本日記は『セクシー田中さん』の件とは関係ありません。 働いていた会社というのは、講談社とか小学館とか秋田書店とか、そういう大手出版社ではない。あくまで編集プロダクションである。出版社と編プロがどう違うのかって……ざっくり言うと元請けと下請けだ。出版社が出版事業（今回だと青少年向けの漫画作りや商業展開）の企画をして、漫画家が作品そのものを作って、編プロは雑誌本体を作って、その制作過程で印刷所やデザイン事務所といった専門集団と関係することになる。 イマイチな説明になってしまった。一般社会の例で説明する。民法でいうところの委託(準委任契約)に当たる。公共建築の分野でいうと、公共機関の建築技師が新しい建築物のマン
本当に効く！アンガーマネジメント！
俺は新入社員時代、上司との相性が悪くて毎晩社宅のゴミ箱を蹴っていたり、酒飲みまくって奇声を上げたり、上司との電話直後にスマホを遠投したりといった伝説を数多く持つ本物の奇行種なんだが。 そんな俺が精神科医に薦められてやったことでマジで聞いたことを教える。 会社のカウンセラーが言ってた「７秒耐えろ！無限に耐え続ければいつか収まる！」はマジで無駄だった。 １位 カルシウムの錠剤を飲む。 ２位 ７時間以上寝る ３位 バナナを食って太陽光を浴びる ４位 朝と晩に「俺がよくやっているのは俺が知っているので、理解する気のない他人に認められる必要は実はそんなにない」を１０回唱える ５位 仕事終わりに明日会社に来たら思い出すべきことを書き出してそのことは忘れて家に帰る ６位 酒とカフェインは元気の前借りなので用法を守る ７位 過ぎたことに考え始めたら「もう諦めろ。取り戻そうとするな」と唱える ８位 どうして
チームで仕事をするなら、リアクションし続けよ｜森 一貴（Mori Kazuki）
チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
秩序があると混沌よりも良いんじゃ(プロジェクト遂行における創発段階においても段取りや問題探索空間の縮小が必要という話) - Lambdaカクテル
同僚と1on1していて面白い話をしたのでメモ。 プロジェクトの不確実性 前提として、自分はソフトウェアエンジニアとして働いているのだが、0→1的な仕事の場合、プロジェクトは最初は不確実で混沌とした状態にあり、しばらくの創発的な状況を通過していくことでいずれ不確実性が減っていき、最終的にはプロダクトとして結実する、という流れを辿る。 最初のうちは不確実だし、様々な可能性に目を向けることが必要な段階なので、ブレインストーミング的な感じでランダム性やクリエイティビティを誘導したりすることが多い。一方、これはビジネスなので、最終的にはプロダクトとして結実させなければならない。したがって道筋を描くための段取りはしなければならない。 よくある不確実性コーンみたいなのを思い描いてほしい。 不確実性へのアプローチ 自分は理数系の正式な教育を受けておらず、どちらかといえばいわゆる人文系な発想をしがちである。
エンジニアのMP切れについて考える - IT業界で気づいたことをこっそり書くブログ
初めて長時間残業をしたとき、不思議な現象に襲われました。 眠いわけでもなく、肉体的に疲れているわけでもなく、精神的に苦しいわけでもない なのに脳が動かない。 そんな状態です。 それを何回か繰り返すうちに 自分は仕事をしているうちに何かよくわからない謎の力を消耗していっているんだな ということに気付きました。 この謎の力を、とりあえずゲームに例えてマジックポイントと呼称してみます。 （仕事体力、バイタリティ、ストレス耐性力なんて言ったりもしますね） MP ≠ 集中力 MPが切れると起こること MP切れはうつ病に似ている MP消費するもの 何をやるにしてもMPは消費する アニメ視聴１話あたりMP30くらい 仕事でも、MP消費量はタスクによって違う MPは時間経過で回復していっている 最大MPは個人差がある？ 消費MPは慣れることで減る MP切れで起こる弊害：やれることが減る MPが世間で認知さ
会議全部ふっとばして社員の集中力を10xした話(ビッグバン) - 10X Product Blog
こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ
[研究室向け]なぜ君はソースコードのエラーを自分で解決できないのか？ - 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)
t-wadaさん「質とスピード」カケハシ社内講演会 - KAKEHASHI Tech Blog
2023年9月25日、和田卓人さん（t-wadaさん）をお招きし社内講演会を開催しました。 和田 卓人さん / プログラマー、テスト駆動開発者 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ「power-assert-js」 作者。 Twitter: @t_wada GitHub: @twada 開催のきっかけ カケハシでのシステムの質とスピードの前提知識を理解し、改めてシステムの質についてチームで会話するきっかけにな
クラスメソッドのテレワークを支える仕組みをご紹介します | DevelopersIO
クラスメソッドでは様々なSaaSサービスを組み合わせて、テレワークを実現しています。そこでこの記事では、クラスメソッドが利用している各種SaaSサービスをご紹介し、どのような仕組みでテレワークを実現しているのかをお伝えします。 はじめに 現在、新型コロナウイルス対策として多くの企業がテレワークを推奨しています。クラスメソッドも1月末より原則テレワークとしており、現在では全てのオフィスを閉鎖し、98%の社員がテレワークで働いています。残り2%は郵便物の受け取りや工事立ち会い等、必要な場合のみ出社するケースです。 しかし様々な報道を見ると、テレワーク自体は多くの企業で導入され、世界全体では80%の人がテレワークを実施しているものの、日本企業においては未だに出勤していたり、とても制限された環境の中でテレワークを実施し成果を発揮できなかったり、様々な問題が発生しています。 ヌーラボがテレワークの導
中年会社員が部署異動してつらかった話 - やしお
会社で部署異動になって5ヶ月超が経った。経験のない業務分野で係長クラスになっている。 今まで会社勤めをしていて、業務内容に特にこだわりもなく、それなりにやれてきたから、まあ大丈夫かと思っていたけど、あまり大丈夫じゃなかった。結構つらかったし、割と嫌な気分になっていた。（今は割と大丈夫。） どの辺が辛かったかとかメモに残しておこうと思って。 異動前 大手メーカーに新卒で入社して15年ほど勤めている。 前の職場（比較的製造現場に近い技術系職場）では、4年ほど担当者として働いた後、係長ポジションになって4年ほど働いた（係のメンバーは10名弱）。 異動 同じ事業部門の中で別の課に異動した。異動先の課の業務内容は、漠然とした理解しかなかった。 30名程度の課で、25名の係の係長をしろとのことだった。もともと課の管掌範囲が広いこともあり、十分にマネジメントが機能しておらず、その辺りを助けてほしいみたい
曖昧なタスクへの耐性が下がってしまった、一時期の話
この記事で書きたいことは、大筋以下のようなことです。 ・「曖昧さ耐性」についての記事を読みました ・部下の曖昧さ耐性の有無と状況に合わせて指示の出し方をコントロールする必要がある、というのはその通りだと思います ・ところで私には、自分の「曖昧さ耐性」を顕著に下げてしまった経験があり、「部下の曖昧さ耐性を下げない為にはどうすればいいか」を常々考えています ・重要なのは、チーム内での「成果物のフェーズ」に関する意識の統一ではないかと思います ・成果物のフェーズ認識に不一致があると、作業者が無駄に疲弊するし曖昧耐性が毀損される場合があります ・「今は成果物の曖昧さを許容するフェーズ」という意識統一がとても大事です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 *** 先日、logmiBizさんでこんな記事を拝読しました。 曖
OSSをベースにしたサービス提供の難しさ - knqyf263's blog
背景 難しさ 利益相反になりがち 競合OSSの存在 コミュニティからのPull Request 競合サービスによる利用 レベニューシェアにならない 利用統計が取れない やっておくべきこと お金を払いたい機能を見極める 境界線を決める ライセンスについて考える 利用統計の取得方法について考える OSSから有償版へのスムーズな移行を考える まとめ 背景 弊社（Aqua Security）ではOSS開発をしており、そのOSSを組み込んだ有償サービスを売ることで利益を上げています。 自分はその中のOSS開発をフルタイムで担当しています。 会社は何を目的としてOSS開発をしているのか、というのは以前発表しました。 speakerdeck.com フルタイムOSS開発者をやってみての感想なども昔書いています。 knqyf263.hatenablog.com 今回はOSSをベースにしたサービス提供の難し
リーダーっぽい人が忙しくても、忙しいって言ってると感じが悪い - hitode909の日記
すみません、私から発表があります！忙しくて、マジむかつくんですけど、とかチームの朝会で発表してしまうと、一緒にやってるメンバーからすると、そんなに忙しいのなら声かけるのを遠慮しとこう…となり、会話タイミングが減ったりして、それによってあとで来月そのリカバリでさらに大変なことになり、さらに忙しく、こんなことなら先月のうちにしっかりやっておくべきでしたな、ということがありえるので、あまり、忙しくしていても、忙しすぎる、って言えない、という問題がある。 よく、ここは問題VS私たちでいきましょう、とか言うけど、主にメンバーたちと仕事している場合は、問題←→私たち←→私、で、私は直接問題と繋がっていない、私たちの手助けをしている、ということがあって、問題の先が私たちにいきつくので、あまり具体的なProblemを連発しづらくて、毎日の会話の実りが少ない、とか、ペアプロの進捗が悪い、とか言うと、個別のメ
デバッグが早い人と遅い人の違い
会社にデバッグの早い人と遅い人がいる。 二人を観察していると、色々な違いが見れて勉強になる。 いくつかまとめてみる。 ・デバッグが早い人はコードに着手する前に状況を整理する 期待動作はどのようなものか、現状の動作（バグ）はどんなものか、どんな条件でバグが生じるか、生じないかを整理する 他人からアサインされたタスクの場合、手早くこれらを質問して状況を確認する。 デバッグが遅い人は何も考えずにコードを触り始める。 「何をデバッグしているの？」と聞くと言語化出来ない。 場当たり的、五月雨式に質問する。 ・デバッグが早い人は仮説を持っている。 ざっくりと全体像を把握し、当たりをつけてから作業する。 全ての作業が仮説の検証作業。結果が出た時に次に何をすべきかも把握している。 デバッグが遅い人は自分でも何をやっているか分かっていない。 「よくわからないけど一応2回試してみた」とか言う。 「それは今何を
米谷昂@FastAPIガチ勢 on Twitter: "話題になっている内定取消しの件 まず全ての就活生に言いたいのは、ホームページなんて見ても良いことしか書かないので、厚生年金の事業所検索をした方が良いということ。 被保険者数2、というのは社会保険加入者が2名しかおらず概ね役員、… https://t.co/1B4id1rbqo"
話題になっている内定取消しの件 まず全ての就活生に言いたいのは、ホームページなんて見ても良いことしか書かないので、厚生年金の事業所検索をした方が良いということ。 被保険者数2、というのは社会保険加入者が2名しかおらず概ね役員、… https://t.co/1B4id1rbqo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
