Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この方法を教えると誰もが早くに出会いたかったと口を揃えて言いました こんにちは。Watanabe Jin(@Sicut_study)です。 今回はエンジニアがすべき究極の勉強法について完全解説していきます。 世の中には多くの勉強法が存在したり、インプット中心、アウトプット中心など色々な考え方があります。 ここでは実際に私が運営しているプログラミングコーチングJISOUで実際に用いている科学的根拠のある最高の勉強方法について徹底的にご紹介します。 また勉強法についての一般的な理論を紹介している記事や本は多数存在しますが、エンジニ

これまで数多くのシステム障害を復旧してきました。 障害は無いに越したことは無いですし、起こらないように最善を尽くすのが我々エンジニアの使命です。 しかし、どれだけ最善を尽くしても起こる時には起こります。 今回は、これまで数多くの障害を復旧させてきたエンジニアが、復旧作業時に何を考えているのかを改めて言語化してみたいと思います。 こういう情報ってそれぞれのエンジニアの頭の中にあってあまり共有されないので、意外に参考になるかなと思います。 障害復旧対応の醍醐味 表現が適切かは分かりませんが、僕はシステム障害を復旧させるのが大好きです。目の前に起こっている事象からヒントを集め、地道に原因を切り分けてクリティカルヒットを見つけたときは名探偵になった爽快感があります。 加えて、動いているものを常に動かし続ける日頃の保守運用とは異なり、動いてないマイナスの状況を0まで戻すということで、復旧成功した際に

はじめに こんにちは。 普段働いているとき「どうやったら生産性があがるんだろう？」と思うことが時々あります。 「生産性向上」といっても具体的にどうするのか、なかなかイメージがつきにくい方も多いと思います。 この度、最近色々なところで目にする「世界一流エンジニアの思考法」という本を読みました。 この本では主に生産性を向上させるためにアメリカの一流エンジニアが行っている習慣や考え方について書かれており、 そこから個人的に身に着けたい10のことをピックアップしました。 内容について 筆者の牛尾さんはマイクロソフトの現役ソフトウェアエンジニアです。 そこで出会う一流エンジニアたちの考え方や、実践していることについて書かれている内容となっています。 アメリカでの内容なので日本では考え方のことなる部分もあるかもしれませんが、参考になる部分は多く 働き方や思考法について考えさせられる内容です。 個人的に

1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり

はじめに 何かを学習するとき、ノートを取っているでしょうか？ 小学生の頃や中学生・高校生の時の「ノート」は紙に手書きだったかと思います。 しかし、最近になってからはパソコンを使ってノートを取る、という選択肢が増えました。 その変遷の中で生まれたパーソナル・ナレッジ・マネジメント(Personal Knowledge Management) という考え方があります。 その考え方を共有できたらと思います。 直感的なデジタルノート術の原罪 ケース1: ひたすらに手を動かす 学生の頃、黒板に書かれた内容をそのまま必死にノートに写している人がいたのを覚えていますか？ また、その人は成績が高かったでしょうか？ たいていの場合、成績は乏しい人が多かったと思います。自分もそのタイプでした。 手を動かすだけのノート術の不幸な点は、「考える」というアクティビティが行われないため、本当の意味で筋肉を動かすだけと

といった感じです。（この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。） "No.～基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20～500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。 知ってる人は知っているが、知らない人はぜんぜん知らない 最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が 「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」 と話したことがありました。その瞬間、 嫌なことを思い出したのか顔を曇らせたり苦笑いをす

TLDR AWSで2022年の1月から9月までのアップデートが多数ありました。私（と、何人かのサポーター）が考えた、この期間内の打破されたアンチパターンを紹介します。32項目ありました！ アンチパターンって何よ？ 「AWSでこうしたい」という思いからAWSを使っていく方は多いはずです。 そのなかで、数多くのAWS使いこなしの工夫が生まれ、成功例が生まれていきました。AWSのサービスとして提供されていないことを工夫でなんとかした、そんな成功例たち。それが「秘伝のタレ」となり、「さわってはいけないもの」、あるいは「ロストテクノロジー」として、封をしたパターンとなっていないでしょうか？ 動作やプロセス、構造について、当初は妥当であったのに、最終的に悪い結果が繰り返されるパターンであり、リファクタリングするための方法が存在するパターンこそがアンチパターンです。サービスアップデートされれば、いままで

WakaTimeとは？ WakaTimeは、エディタと連動してコード編集の作業時間を可視化できるサービスです。 編集したコードのプロジェクト（リポジトリ）、言語、ブランチを自動的に検出してダッシュボード化してくれます。 エディタ操作が一定時間止まると自動的に計測停止してくれます。自分でタイマー開始・停止する必要はありません。 たいていのエディタは対応しています。 https://wakatime.com/plugins この記事では、VSCode に WakaTime を導入してダッシュボード確認するまでの手順を説明します。 WakaTimeアカウント登録 https://wakatime.com/signup からサインアップしてください。 APIキー発行 https://wakatime.com/settings/account からAPIキーを発行できます。 VSCode と Wak

はじめに Amazon VPCは、AWS上で仮想ネットワークを構築できるサービスです。 VPCの概要や理論については以下の記事で詳細に解説しました。 一方で、「理論だけでなく実践も重要！」 と思われる方も多いと思いますので、 本記事では実際にVPCによる仮想ネットワークを構築する方法を解説します。 構築の指針として、以下のベストプラクティスを極力満たすよう進めていきたいと思います。 特にVPCフローログやVPCピアリング、VPN等は設定が複雑でハマりがちですが、極力分かりやすく解説したつもりなので、効率よく構築法を習得できる記事となれば幸いです。 本記事で構築するVPCの構成 下図構成のVPC (上記記事の冒頭で紹介した構成)の構築を、実際のコンソール操作方法を交えて解説します。 上記構成の意図として、VPC1 (Webアプリ用のVPC)とVPC2 (社内ネットワークを模擬したVPC)を組

はじめに AWS上で仮想ネットワークを構築できるAmazon VPCは、多くのAWSサービスが動作する基盤となる、非常に重要かつ多機能なサービスです。 多機能ゆえに公式ドキュメントやネット上の記事も断片的な機能の解説が多く、全体像を把握することが難しいサービスとも言えます。 そこで本記事はVPCの全体像を理解できるよう、各機能のつながりや動作原理を丁寧に解説し、 「VPC界の百科事典」 (あくまで例えですが…笑) となるような記事を目指したいと思います。 【追記】 実践編の記事を追加しました VPCの実画面での構築方法は、以下の別記事にまとめました。「VPCを実際に触ってみたい！」という方は、こちらもご一読いただけると嬉しいです。 VPCとは 「Virtual Private Cloud」の略で、クラウド上に仮想的なネットワークを構築するためのサービスです。 例えば、オンプレ環境でWebア

※追記: 「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 前回の記事「エンジニアの"有害な振る舞い"への対処法」では多くの反応を頂きました。 はてなブックマークのコメントやTwitterを見ると、多種多様な反応がある中で、有害な振る舞いが多くの方によって実際に観測されていること、そしてそれによって実際に心理的ダメージを受けていたり困っているというコメントがいくつもあることが印象的でした。 ただ、その一方でこれだけ有害な振る舞いに対する反発があると、自分の有害な振る舞いによってチ

Power BI はスタースキーマを目指してモデリングをする。 これは Power BI を使用するすべての人が守らなきゃいけないこと。Power BI はモデルがスタースキーマになってることを前提に作られているから、それに乗っかった方がトリッキーなことをやる必要もないし、ややこしく考えることもない。まして、複雑な DAX を書くこともなくなる。 たぶんここまでは、Power BI を使い始めて、しばらくたった人が知っていることだと思う。 でもね、モデリングって、結局何をすることなの？どうすればいいの？って思ってる人、結構たくさんいらっしゃると思う。もし、いまドキッとしたのであれば、全く問題ない。というか、まずはわからないってことを認めることがスタートだと思うのだ。というわけで、今回はスタースキーマを前提に ファクト と ディメンション をってどうあるべきなのさ？ってのを書いてみようと思う

この記事は Terraform Advent Calendar 2021 の5日目です。 Atlantis の話が書きたいけど書く場所がなくて遅ればせながら枠を探したところ、5日目の枠が空いていることに6日朝に気付いて押さえたため、投稿は遅くなっております。 ということでこのエントリーでは全力で Atlantis を推します。 Atlantis とは Terraform の自動実行にはみなさん何を用いているでしょうか。2021年現在だと HashiCorp 提供の Terraform Cloud でマネージドなパイプラインが簡単に組めますし、同じく HashiCorp が GitHub Actions を使ったワークフローを Automate Terraform with GitHub Actions | Terraform - HashiCorp Learn で公開していたりと、自動実行

はじめに Markdownって便利ですよね？ README.md、PR や Issue の本文やコメント、Qiita や Zenn はもちろん、Google Docs や Trello や Notion や Jupyter Notebook でも使えるみたいです。もっといろいろな文書を Markdown で書ければいいのになあ、あらゆる文書のソースコードを Markdown にできればいいのになあ。 さあ、Markdown の可能性を広げましょう！ 本記事では「スライド」と「(電子)書籍」をMarkdownで書く方法をご紹介したいと思います。もちろん、VSCodeでMarkdownを効率よく便利に書いていくためのチップスもご紹介していきますよ。 ご参考スライド VS Code Conference Japan 2021 で発表した際の以下スライドもご参照ください。 もちろんこのスライドもV

「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして

はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

この記事では、以下のようなチームを想定して、お金と手間をできるだけかけずにそこそこセキュリティを向上させることをまとめようと考えています。そんなんじゃだめだ！とか、こういう場合は漏れませんか？というコメント大歓迎です。 想定するチーム 営業やCS、マーケの人など全職種含めると30人前後あるいはそれ以下で、Webサービス（アプリ含む）開発を行っている 副業人材も多く、半数のメンバーは会社支給でないマシンを使っている それらのマシンは他社の業務でも使用されている Macが多めだがWindowsもいる 基本的に業務データはクラウド上にあり、PCローカルにあるのは開発途中のデータ、Biz/バックオフィス系のドキュメント、重たいデザイン系データ程度。自社データセンターや、オフィスネットワークでしかアクセスできないサーバはない。 メインの業務ツールはGoogle WorkspaceとSlackとGit

はじめに この記事は、2020年3月13日に正式出版された共著『みんなのJava』タイアップ企画としてお送りします。 英語版の記事は「Summary of information about OpenJDK and JDK Distributions」を参照ください。(リンク先も若干異なる箇所があります。) 【新刊】2020年3月13日発売『みんなのJava　OpenJDKから始まる大変革期！』本体2,280円＋税、きしだ なおき、吉田 真也、山田 貴裕、蓮沼 賢志、阪田 浩一、前多 賢太郎　著　Javaの変化を一気にキャッチアップ！ https://t.co/ec8tnNF3g7 pic.twitter.com/IMEhI3w989 — 技術評論社販売促進部 (@gihyo_hansoku) February 21, 2020 簡単に紹介したときのブログ記事はこちらですが、私の担当した2

更新記録 2021/6/17 - 「Cloud 型ベンダーロックイン」「Cloud Native DB」について加筆 2021/6/16 - 「OSS」 について加筆 2021/6/14 - 「業界標準」について補足 はじめに IT企業 = ベンダーロックインの塊 プラットフォーマー = ベンダーロックインの塊 残念ですが、その視点の方は、多くいらっしゃいます。ソフトウェア自身が期待していたほど正しく動作しなかった、もっと言うと枯れていなかった時代には、それしか選択肢が無かったかもしれません。 IT業界は Dog Year だと言われて久しいわけですが、Cloud 全盛の今。ベンダーの儲けどころは大きく変わっています。ベンダーロックインは「囲い込み戦略」であり、その負の部分の方が大きい事をベンダーは知っています。 定義 ベンダーロックインの定義を Wikipedia から拾ってみます。 W

Don't offer a Free Planという非常に力強い主張があったので紹介してみます。 著者はGuido( Twitter / GitHub / Webサイト )です。 Don't offer a Free Plan もしあなたがSaaSプロダクトを提供しているのであれば、無料プランを提供することに意味はないかもしれません。 無料プランはホスティングコストだけではなく、リアルのコストがかかります。 本サイトでは、これらの検討事項について解説し、そして無料プランにかわる手段について提案します。 The costs of a free plan 無料プランは、ユーザにプロダクトを知ってもらい、そして後に有料プランにアップグレードしてもらうことを期待します。 プロダクトにもよりますが、無料プランのユーザが増えてもサーバ代にはほとんど変化がありません。 しかし、実際には大きなコストがかか