僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職

エンジニアリンググループの冨岡です。 私は最近関数型プログラミングにハマっていて、社内でFP in Scala (訳書)の輪読会を主催するなどして関数型やScalaが好きな人を増やす活動をしています。 この輪読会ですが、本自体の素晴らしさもあって未だに参加者７人が誰一人脱落することなく読み進めています。現在８章と折返し地点なのですが、これまでの章で十分に訓練された私たち参加者は、（説明の都合上）副作用を起こす処理が教科書に出てこようものなら大ブーイング。教科書の解法を確認しては「美しい！」「エレガントだ！」と盛り上がりながら読み進めるようになりました。 中でもfoldRightは大人気で、登場のたびに場を盛り上げてくれます。この記事では、このfoldRightがなぜ美しいのかを解説します。 foldLeft / foldRight まずは、似た処理であるfoldLeft / foldRig

データを使って何かを実現したいと思った時に、扱えるデータがそもそもないといったことがあった。そのようなケースにおいては公的な機関が公開しているデータを頼りにして検索することが多いが、そもそもデータが掲載されているサイトにたどり着くのが困難であったり、たどり着いてもデータに不備があることもあった。今回は自分がいくつか当たってみて使えそうだったサイトをまとめて載せておくことにした。 Dataset Search Googleが提供しているDataset Searchは2018年に公開されたサービスで、世界中の機関で公開されているデータセットを検索できるものになっている。普通のグーグル検索よりもデータセットに特化している上に、「更新日」「データ形式」「ライセンス」といった項目で絞ることも出来るので非常に使いやすい。 datasetsearch.research.google.com 欧米のデータ

「一晩サーバーに仕事を投げて、翌日結果を見たい！」 「学校でサーバーにタスクを投げて、後で家で確認したい！」 「Windows Updateが始まってssh接続が切れてしまった…つらい…」 こんな場面はしばしばあります。普通にssh接続をしている場合、接続を切るとタスクが止まってしまいます。すると上記のような場合、sshで接続している自機を一晩中つけておいたり、学校から家までsshの接続をずっと保っておくわけには行きません。Windows Updateなどで強制的にsshが切られたらもっと嫌です。 そんな時にはtmuxを使います。tmuxはかなり多くの機能があるのですが、上記の用途だけなら2, 3個コマンドを覚えるだけで十分です。 tmuxの詳しい動作原理はtmuxを使い始めたので基本的な機能の使い方とかを整理してみた - 完熟トマトの「tmux利用のイメージ図」がわかりやすいです。ごく簡

UnicodeとUTF-8の違いを理解していない方が結構居るようなので、文字コードの考え方を元に解説してみようと思う。 文字コードとは何か？ 文字コードとは、コンピュータ上で文字を扱うために、文字に対して割り当てられた数値のことであり、文字と数値の対応付けと呼べる。 この対応付けの種類は沢山あって、Shift-JISであったり、UTF-8であったりする。 以上！と言いたいけど、文字コードはこんなに単純ではない。文字コードを複雑にする要素は沢山あるが、今回の記事ではUnicodeとUTF-8の違いに焦点を絞って解説してみたいと思う。 文字コードの構成要素 文字コードの世界は以下の2つの要素で構成されている。 この違いを意識しておかないと混乱を招くだろう。 （１）．文字集合 – 表現したい文字の範囲（”あ”、”い”・・・といった文字の集合体） （２）．符号化方式 – 文字集合を構成する個々の文

ふと思い出したので。 就活サイトの運営に携わっていたとき、多くの知人に就活や仕事の話を聞いたのですが、ベンチャーに入社した知人の多く（およそ8割）が3年以内に辞めており、ちょっと驚きました。 で。長く働いたあとの退職だと円満な感じで終わることが多いと思いますけど、3年以内だとその理由が実に種々雑多で面白かったので、気侭に列挙していきたいと思います（随時、追記するかも） しかし、追加するたびに「周りに多いなぁ。3年離職」と思います。苦笑。 ※最終更新：2024/08/09 ※あくまで「3年以内にベンチャー企業を退職した知人に理由を尋ねた結果」をまとめただけです。ベンチャーによくある退職理由、大手にはないベンチャーならではの理由をまとめた記事ではありません。 1. 周りの社員が想像以上にモチベーションが低かった 2. 昇進の可能性が（まず）ない 3. 1年たって成長が止まった 4. 自分だけ損

こんにちは、CTO歴も丸9年以上になりました @makoga です。 Podcastや勉強会で話をしたときに好評だったので、今回は私が面接時に見ているポイントを書きます。 ※この文章の元ネタは2016年1月に社内に公開したものです。 面接時に見ているポイント 3行まとめ 事実と意見を分けて説明できるか 実際の課題を解決しようとしているか 技術をどう理解しているか この文章の目的 30分から1時間の面接で一緒に働きたいかを判断するのは難しいことです。私も経験を積んで学んできました。 まだ経験が浅い面接官に私が実践していることを伝えることでVOYAGE GROUP全体の判断の精度を上げていくのが目的です。 事実と意見を分けて説明できるか 圧倒的にこれは重要。これができない人はかなり厳しい。 関わったプロジェクトのなかで、自身が一番活躍できたと思うプロジェクトについて聞く 学生の場合は1人で個人

ドワンゴ 技術コミュニケーション室の塩谷（ kwappa ) です。 2019年、ドワンゴには19名の新卒エンジニアが入社しました。一般研修やグループ会社との合同研修を経て、4/22からはエンジニア研修が始まっています。 その冒頭に「エンジニアの心技体」というテーマでぼくが話す時間を作りました。エンジニアとして成果を出し、成長し、生きのこるための心構えを「親父の小言」的に紹介しています。 スライドはこちらです。 前提知識として、ここ数年話題に上ることが増えてきた「心理的安全性」と「HRT」などを紹介し、その上でプロのエンジニアとして生きのこり成果を出すための心構えを「心技体」という軸で切り取って紹介しています。 「心理的安全性」という言葉が注目を集める結果となったGoogleのプロジェクト・アリストテレスについては時間的な都合で言及していませんが、平易に書かれた重要な文章ですので、あわせて

さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ（要素）はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ

「この本にはお世話になったなぁ〜」 「今でもたまに読み返してます」 「マジでめちゃめちゃ影響受けた」 「そう、こいつが俺のエンジニア人生を変えやがったんだ...」 ↑「こんな本を紹介してください！」と社内チャットで投げてみたら、すんごいことになったのでそのリストをシェアさせていただきます。 ※推薦理由はあくまで推薦者による個人的な意見や思い入れたっぷりなので、それを踏まえてお楽しみください。 目次 アプリケーション/プログラミング ドメイン駆動設計 Java言語で学ぶデザインパターン入門 Pro Git BINARY HACKS Effective Java リバースエンジニアリング―Pythonによるバイナリ解析技法 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 リーダブルコード メタプログラミングRuby 第2版 Head First デザインパターン テスト駆動開発 C

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 「オブジェクト指向入門 第3章モジュール性」メモ - $shibayu36->blog; の続きで、「第6章 抽象データ型」を読んだ。 この章では、オブジェクトを適切に表現する記述として、抽象データ型というものを紹介している。これが非常に参考になったので軽く読書メモをとっておく。 抽象データ型とは 抽象データ型の仕様の記述とは以下の4つを記述することであるようだ。 TYPES(型) FUNCTIONS(関数) -> その抽象データ型に適用可能な操作の集合 AXIOMS(公理) -> その抽象データ型が必ず満たす条件 PRECONDITIONS(事前条件) -> 部分的な関数のソース集合の定義域 STACKの例を見

会社のとあるプロジェクトでコーディングの可読性に関する勉強会を実施してるらしい。 そのプロジェクトはリリースは終わって保守に移行してんだけど今更そこ勉強してんのって感じが半端ない。新人向けか？ そのプロジェクトはもちろん炎上しまくってた。今も炎上してると思う。 さて、その勉強会の資料を見る機会があってだいたいはごくごく当たり前のことを書いてた。メソッドの行数とかそういうの。 でも資料の中にコメントを書けっていう項目があってJavadocを書けって言う項目がなかったのに驚きを隠せなかった。 コメントなんかよりJavadocの方が大事なんだってことがわかってないみたい。 というか、そのプロジェクトではJavadocを書かない主義だったらしい。全く意味がわからない。恐ろしい。。。 と、前置きが長くなってしまったが、 コメントを書くよりJavadoc（privateメソッドも含む）を書く方がいいん

ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい　笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。　#ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本

はじめまして。１ヶ月でエンジニアになろうとした山浦です。 先日Gitのことを突っ込んで調べる機会があり、Gitの仕組みって面白いねということを同僚に話していたら「面白いね。ところでGitって実装できる？実装できないと分かったとは言えないよね？」となぜか煽られるということがありました。 そうか、実装できないと分かったとは言えないのか、それも一理あるかもしれない。そう思い、Gitの仕組みを実装できるレベルまで掘り下げて調べてみました。 今回は実装はしないものの（過度に記事が複雑になるので）、Gitの根幹である git add コマンドと git commit コマンドの裏側で起こっていることを紹介します。 差分かスナップショットか？ ここで早速クイズです。 コミットで保存されているのはソースコードの差分でしょうか？スナップショットでしょうか？ 今回の記事の中で解説していきますので、少し考えなが

メルカリのAI EngineeringでTech Leadを務めている中河です。今回は3/18に正式リリースされた「写真検索機能」を支えるバックエンド・インフラをシステム側からの視点でご紹介します。 写真検索とは 所謂、画像検索機能で商品名を知らなくても画像から商品を検索できる機能の事です。詳しくは下記の公式リリースをご覧ください。 about.mercari.com 基本的な写真検索の仕組みは、Deep Neural Networks (DNN)を使用して商品画像から特徴ベクトルを取得し、取得した特徴ベクトルをApproximate Nearest Neighbor Index(ANN Index)に追加して画像indexを構築。 検索時には同じく商品画像からDNNを介して特徴量ベクトルを取得し、ANN Indexから検索します。 アーキテクチャの概要 Figure1 上記がアーキテクチ

他責はけしからん、自責で圧倒的当事者観を発揮するのだよ、諸君。 というのはよく聞く話です。 この他責、実は誤認のパターンもあるのではないか、ということを最近感じているので、それについてまとめます。 ビジネスの文脈において好ましくないとされる他責はおそらく以下ではないでしょうか。 ・問題を他人の責任にして、自らは他人ごとを決め込む これは、仮に本当にその相手に責任があってもなくても、同じ組織内の問題を他人事にしている状態が好ましくないという考え方です。 他者の責任だっとしても、それは本当に自身の関与で改善できないのか？ 変更できないなりによりよくする方法はないのか？ そういった考えを持っていない人に対して「他責はよくない」というのが、よくある話でしょう。 その中でも2種類に分けるとしたら 1. 自分の責任だが、他人の責任にする 2. 本当に他人の責任なので、自分は他人事を決め込む 前者の「自

フロントエンド技術は、ある時期を境に爆発的進化を遂げて、面白く・DX（開発者体験）の良い世界に発展しています。 DXはDeveloper eXperienceの略で、2017年くらいから話題になっているようです。（正しい起源はわかりませんが、雑に検索した限りは、2017年のMediumやdev.toでの英語記事がヒットします） DXに関して日本語での記事は「DX: Developer Experience （開発体験）は重要だ」を読むとわかりやすいと思います。 ウェブ技術をやっている人の中で、バックエンド側しかまだ触ってない、JavaやRuby、PHPのような言語でしかウェブに触れてない人は多く、そういった人に、今のフロントエンド情勢ってこんな感じだよ！って知ってもらいたいという思いがあり、都内の某所にある「ラボ」でモダンフロントエンドエンジニア勉強会というのをお試しで開催してみました。

Privacy-focused search engine and web browser company Brave Software is integrating search results into its Leo chatbot. Search results are based on the Brave Search API and Leo is integrated…

これはなに？ はじめに AGCあれこれ Temporary I HOPEHOPEHOPE ASTRONAUT NOW LOOK WHERE YOU ENDED UP ふと気になりました いい時代ですね 1201&1202エラー なにそれ？ カ、カルマンフィルターだー！！！ カルマンフィルターの開発経緯 その他面白コメントアウト集 TRASHY LITTLE SUBROUTINES（つまんないサブルーチン） NUMERO MYSTERIOSO（神秘の数字） OFF TO SEE THE WIZARD COME AGAIN SOON HONI SOIT QUI MAL Y PENSE（悪意を抱く者に災いあれ）、NOLI ME TANGERE（私に触れるな） PINBALL_GAME_BUTTONS_AND_LIGHTS.agc おわりに 反省 参考文献 これはなに？ この記事はeeic Adv