コロナウィルスによって、誰もがリモートワークを実施する必要があるようになりました。昔はインターナショナルチームのメンバーとして日本に住んでいましたが、今は同じチームのいるシアトルに移住してアメリカでエンジニアをやっています。正直なところ私はリモートワークより対面でコミュニケーションをとるほうが好みななのです。しかし、アメリカのマイクロソフトにいると、コロナが始まる前からそもそも通勤できる距離にないメンバーが居たり、同じチームのメンバーが別の国に住んでいたり、お客さんが別の国だったりということもしょっちゅう起こります。そんな環境のなかで、リモートワークが得意な人が共通して持っている、たった一つのポイントをご紹介したいと思いブログを書きました。 リモートワークのつらさ リモートワーク好きな人もいますが、私はできれば同じ場所で作業したいと思います。リモートワークをすると、視野が画面に限定されます

全国の nginx 職人のみなさま、こんにちは。野島(@nojima)です。 私の所属するYakumoプロジェクトでは、nginx を Go と Docker によってユニットテスト1しています。 手元で簡単に実行でき、ブランチへのpushのたびにCIでテストされるので、非常に便利です。 この記事では、このnginxのユニットテストについて紹介してみたいと思います。 背景 nginx は極めて柔軟なロードバランサであり、プロダクション環境ではその柔軟さを生かして多彩な役割を担っています。 我々の nginx は、ユーザーからのリクエストを AP サーバーに振り分け、アクセス制限を行い、リクエストをリダイレクトし、HTTPヘッダを付与したり削ったりしています。 しかし、nginx は便利な反面、その設定は極めて複雑になり、読解したり変更したりするのが難しくなっています。 そこで、nginx

こんにちは、マネーフォワード CTOの中出(なかで)です。 CTOの私が普段なにを感じて、どんなことを考えているかを、改めて言語化して、社内に共有するという取り組みをしています。 そうしたところ「当社のエンジニア組織に興味を持っている方にも読んでいただくのがいいのでは？」という社内の意見もあり、今回公開することにしました。 もちろん、日々考えていることは変化しているので、今後は四半期に一度ぐらいの頻度で、変更があれば更新していきます。 ※公開用として、社内向けの内容を一部編集しております。 これからのマネーフォワードのエンジニア組織について まず、マネーフォワードのエンジニア組織として「どこを目指すのか」という話をしたいと思います。 もちろんビジネスには「やれる・やれない」という議論も必要ですが、まずは私たちが「どこを目指すのか」という意志が必要です。 そして、「どこを目指すのか」を決めた

こんにちは、@p1assです。 世間は就活解禁日ということで少し騒がしい感じがしますね。私は既に就活を終えているためあまり関係ないのですが、思い立ったので自分の就活事情をブログにまとめておこうと思います。 就活はかなりセンシティブな話題であり、ネット上を探しても見つかる情報が少ないです。また、個人の情報は埋もれやすいという問題もあります。そのような状況では参考になる情報に出会えず、就活をどのように進めていくか悩むのではないでしょうか？自分も例に漏れず、かなり苦労しました。そのため、「後輩にはより多くの情報を手に入れてほしい！」と思っています。 そこで、本記事では私が Web 系のソフトウェアエンジニア職で就活をした結果やその過程で得た知見などを公開したいと思います。勿論 NDA がある内容は公開できないですが、私の経験が後世の役に立てば幸いです。（スコープは Web 系のソフトウェアエンジ

私は新卒で入社した会社に、 2日目で見切りをつけ、 5日目に最後の出社をし、 15日目で書類上の退職を完了しました。 退職ネタはよくツイッターで書いているのですが、昨年参加させていただいた「新卒退職本5」へ寄稿した文章を元に、ブログ用の記事にいたしました。 これから会社員になる予定の方や、退職するかどうか迷っている方のご参考になれば幸いです。 ーー 留年、そして就職活動のプロに みなさんは「禁煙のプロ」というジョークを聞いたことがあるでしょうか。 俺は禁煙のプロだ。なぜなら何度も禁煙しているからだ というような話でして、類似するものに「結婚」や「ダイエット」等があります。 このジョークになぞらえて言うと、私は「就職活動のプロ」と称してもよい人間です。 プロにならざるを得なかった経緯を告白します。 本来私は2018年の3月に大学を卒業し、内定を いただいていたメーカーへ就職するはずでした。

こんにちは。 経費精算サービス「マネーフォワード クラウド経費」の開発チームでフロントエンドエンジニアをしている坂本です。 クラウド経費ではJSのライブラリとしてReactを採用しているのですが、最近クラウド経費で React Component を実装する際のルールをまとめたので、その話を書こうと思います。 なぜルールをまとめようと思ったのか Componentの分割ルールとしてAtomic Design、スタイルの管理としてstyled-components、GraphQL用のライブラリとしてApollo Clientを導入し実装を進めています。 昨年の10月までは挙げた３つとも使用していなかったので、試行錯誤しながら進めています。 チームメンバーの各々が試行錯誤しながら実装を進めていくので、最近はチーム内で認識の齟齬や持っている情報に差が出るようになりました。 そこで一旦現状を整理し

Talked at AWS Summit Tokyo 2019 & Developers Summit 2020. 説明つきの動画にてご覧になりたい方はこちらもどうぞ → https://www.youtube.com/watch?v=ZwfdLAClzsc ※ 2019年の動画のためスライド…

2020年3月21日(土) に開催予定の React Conf Japan のキービジュアルデザインをしました。デザイン策定にいたるまでのプロセスを公開しています。 note: https://note.com/featherplain/n/na039cb933812 website: http…

初めに、そして結論 本当は冒頭にこういう言い訳がましいことを書くのは好きではないのだが、例によってディスり成分が多めなので、筆者はそういうキャラということでそこは目を瞑って欲しい。実体験に基づいて書くので業務上あまり触ってこなかった言語については記載が少ないが、読者のみなさんが詳しいことや私の記述で事実と異なる部分については謝罪して訂正したいのでプルリク、コメント等熱望している。あと筆者はサーバーサイドエンジニアであってフロントの事が全然わからんのでその辺はさっぴいて読んでほしい。結論から言うとRustを使え。 古生代 アセンブラ以外の高水準プログラム言語の歴史は1950年代から1であるが、筆者の実体験に基づいて話をするので'80年代まですっ飛ばす。 N88-BASIC N88といえばN88-BASIC(86)を思い浮かべる読者が多いと思うが、筆者はPC-8801mkIIユーザーだったので

先日、とある内容についてツイートしたのですが、それが思ってたよりいろんな反応をいただいたので今日はそれに関して、ツイートでは伝えきれなかったことなども含めてもう少し詳しく記したいと思います。 まず、ツイート自体はこちらになります。 面接してると時折、『1人で全部やりました！』『できる人が他にいないんで自分だけでやりました！』みたいな話をしてくれる人がいるんだけど、正直なところ1人で全部やるのも大変とは思うけどチームで成し遂げるほうがよっぽど大変だと思うの. 人は思う通りには動かないわけで… なので評価しづらい — Keisuke Nishitani (@Keisuke69) January 31, 2020 これは採用に関する話でして、面接などをしていく中でよく感じることについてぽろっと呟いただけです。そんな感じだったこともあって140字では詳細に文脈など伝えることは当然無理です。したがっ

気がついたら IANA の markdown variants に項目が増えてる。皆さん知ってましたか。 / Markdown Variants https://t.co/Hf2UNFlnIm — tk0miya (@tk0miya) February 3, 2020 週末に Markdown の記事を書いた流れなのか、普段まったく見向きもしない IANA の Markdown variants リストをふと開いてみました。記憶では最後にこのページにやってきたのは RFC が採用された頃ですから、4年ぶりの再訪です。 すると、なんということでしょう。つい半月ほど前の1月13日に、あたらしい variants として Markdown for SSW がリストに追加されていたのです。 Markdown variants とは 3年前に Markdown in 2016 という記事で紹介したも

この記事は npm へ公開可能なパッケージを TypeScript で作成しながら、JS/TS 開発で良く使われるツールを紹介する記事です。 typescript-npm-starter という名前の Hello, world! パッケージを公開するという体で話を進めます。

アメリカに移住してもうすぐ４ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。 最初の２ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ４ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日本で仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう？焦っていても何も改善しないので、直接仕事をしているクリスと、日本人エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。 仕事が完了しない焦り 何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみ

新しい技術が出てきたとき、大多数の若い人よりも圧倒的にスピーディーに使いこなすおっさんは珍しくない。 新技術を習得する能力は、年齢よりも、「スキルを獲得するために必要なスキル」、すなわち「メタスキル」に大きく依存するからだ。 たとえば、ある開発ツールを導入すべきかどうか若い人に相談されたので、「まず、ドキュメントを読もう」と言ったら、「ドキュメントを読んでもよくわからなくて。。」と言う。ググったらすぐに公式サイトの至れり尽くせりのドキュメントが出てきたので、「これ読めばいいじゃん」と言ったら、こんなに大量の英語のドキュメントを読むのは無理だと言う。 あるいは、AIを導入するという話になったとき、「AIがよく分からないので教えて欲しい」と言ってきた若い人に、良質の入門書を勧めたら、数式が分からないので読めないのだという。数式の読み方を教えてみたら、数式以前に、そこで使われている数学概念自体を

A fork() in the road を読んで.md A fork() in the road を読んで HotOS 2019 で Microsoft Research からの論文である．Unixの代表的なシステムコールであるfork()についての問題点を挙げている． 概要 fork()は最も基本的なシステムコールといっても良く，新しいプロセスを作るときに使われる．今回の論文の主張はfork()は1970年代のマシンではハックと呼べるものだったが，現代では過去の負債となっているというものでおり，カーネルから完全に取り除くべきであるというものである．ただし，ここでいうカーネルとはLinuxカーネルのことを直接指しているのではなく，著者の先行研究でのOSの実装のことを指している． 面白いのは，fork()は研究者にとっては研究を阻害するといったことや，教育者は歴史としては教えるべきだが最初

昔：感情があった 元々ぼくはきれいなコードを書くことへのモチベーションが高かった。 プログラマーになったばかりの頃にリーダブルコードを読んで感動したというのもあるし、ちょうどその頃DDD原理主義みたいなものが流行ってて、はてブのITタブにはきれいなコードを書くためのコーディング規約やテクニックに関するブログエントリやLT資料がたくさん流れていた。 最初にAndroidの大規模プロジェクトに関わった時は、元々のコードがかなりひどかった(初めてJavaを書く人達だけで書いたとしか思えない、現代ではおおよそあり得ないようなレベル)ため、リファクタリングをすることに非常に意義もやりがいも感じたし、どうせきれいにするのならばと張り切って出来るだけリーダブルなコードを書こうとした。 その後チームにgit化の波が訪れ(自分が推進したんだが)PRによるコードレビューなるものもやるようになった。 意識が高か

はじめに どうも、さぃと（@saitoeku3）です。 大学生はもう夏休みが終わる時期ですが、皆さんは楽しい夏を過ごせたでしょうか？ 僕は 8/19 - 8/30 の 2 週間 Wantedly のサマーインターン (フロントエンドコース) に参加してきました。 自分にとっては初めての就業形インターンだったこともあり、多くの刺激や学びを得られたので簡単に紹介させていただきます。 www.wantedly.com 会社の印象 サポーターズの面談や選考の面談では技術の話が中心だったので、参加前は技術ゴリゴリゴリラの息苦しい企業かもしれないと思っていたのですが、参加してみると大きく印象が変わりました。 実際に訪れると話しやすい人が多くて過ごしやすかったです。 知り合いの学生も何人か来ていたので、勝手にオフ会みたいな気分にもなっていました。 あとミーティングで使う部屋等に JOJO 関連の名前が付

「誰のためのデザイン?」の旧版と改訂・増補版を読みました。 以前に旧版を読んだのですが、その記憶もあやふやなくらい前だったので、あらためて読み直し、その面白さゆえに改訂・増補版も購入してこれも読み終えました。 Web システム開発を生業としているので、日々ユーザとのインタラクションが発生するプロダクト開発に関わっているわけで、ユーザがどのように製品を認知し、使うかという内容は参考になりました。 それとは別にソフトウェア開発という観点で、ソースコードを読む時に人がどのように認知するのかという点でも興味深いものでした。このエントリでは、自分なりに整理したソースコードと概念モデルについて残しておきます。 ソースコードとメンタルモデル ソースコードの概念モデル 実行モデル プログラマモデル ユーザモデル 誰のためのソースコード? さいごに メモ ソースコードとメンタルモデル ある程度、経験のあるプ