Unit4の永山です。 dotfiles弄りを趣味にしています。 世にdotfilesを題材とした記事は数多く存在していますがその大半は「dotfilesを作ってみた」「こうやって管理しています」などの表層的な部分の紹介に留まり、その奥にあるべき細部のこだわりや個人の思想にまで踏み込んだ記事は数えるほどしかありません。 そこで、本記事では私のdotfilesを題材にその各構成要素についてオススメ, TIPS, こだわりに分類し、可能な限り詳細に紹介します。 github.com 本記事は筆者の関心の都合上、Zshに関する項目に大きく比重を置いています。ご承知おきください。 dotfilesとは dotfilesを作成することの利点 記事の構成 Zsh編 [オススメ] プラグインの管理にZinitを使う 注釈: Zinitについて [オススメ] Zshプラグインは非同期読み込みする [オスス

メルカリでやっていたこと 自分がメルカリに入社したのは2017年12月で、SET(Software Engineer in Test)というポジションに応募して採用されました。 SETはその名の通りテストに対する課題を解決するための役割なのですが、当時のSETチームはテストの実装を行うわけではなく、開発環境や検証環境の運用やCI/CDツールの導入・サポートなどを主な役割としていました。 自分がSETとして応募したのは、前職までの経験で機能開発にやや飽きており、エンジニアとして品質の改善をテーマとして扱っていきたいと考えていたためでした。通常の機能開発ではプロジェクトの要件や期日に沿って開発することが求められますが、SETの業務には要件や期日はなく、何をいつどのように解決するかを自分で判断する必要がありました。チームメンバーやプロジェクトメンバーと話し合い、コードを見ながら現在の開発・運用状

しおいです。 みなさまRubyKaigi 2022お疲れ様でした! わたしはありがたいことに去年に続き、DAY2に登壇する機会をいただきました。 rubykaigi.org 今年は3年ぶり2回目となる現地参加となり、本当に楽しいあっという間の3日間を過ごすことができました。 この記事では、今回のテーマを選んだきっかけ、実際に作ったもの、登壇本番のことや会期中のあれこれを振り返ります。 Wireshark + mruby + dRubyのお話をするに至ったきっかけ 今回は「Packet analysis with mruby on Wireshark - dRuby as example」というタイトルにて「mrubyを組み込んだWiresharkでdRubyパケットを解析する」という内容でお話をしました。 こうした登壇テーマを選ぶに至ったのは、去年2021年のRubyKaigi Takeo

小学校1年生から電子工作をやっているfumiです。 散財額30万円以上の中から良かった工具類を教えます。皆さんはお金を大事にしてください。 工具は奥が深くて工具を買えただけで全然楽に作業できるようになった、きれいに実装できるようになったという話を聞きますし、私もゴミ工具を使ってたときはひどかったものです。 良いものを使って良いものを作りましょう！ 最近はCPU基板を作ってます。萌える。 はんだこて 電子工作といったらこれですね。ハンダコテです。むしろこれ以外に何が考えられるのか。 様々な小手先、熱容量、電力のものがあります。物が多すぎてどれがいいんだ...ってなると思います。ハンダコテにおいて、温度低下しないことはとても重要です。いちいち温度下がってたら基板に熱取られてハンダが全然溶けねえなんてことにもなりません。そんな私のイチオシはこちらです。 HAKKO FX600 白光(HAKKO)

圧着端子について 今回は電子工作工具第二回です．電子工作でよく使う圧着端子について書きます． ある程度電子工作をやっているとコネクタを作りたいという気持ちが出てくると思います。コネクタを使えるようになると工作の幅がグッと広がります。コネクタ付きケーブルは秋月や千石でも売っていますが、もっとたくさんのピンがあるものがほしい、この大きさのコネクタがほしいという要望がでてきます、そういった際はコネクタを自作することになります。 いざコネクタと作ろうとするとどの工具がどのピンに適合するのかよくわかりません。対応していると謳っている工具も本当に使えるのか?微妙なところはあります。 この記事では実際にいくつかの工具を試しながらおすすめの圧着工具を紹介します。 前回の記事では電子工作で頻繁に使う工具のおすすめを書いたので良ければ御覧ください． fumimaker.hatenablog.com 前回の「私

これまで何人も強いエンジニアと出会って、 「なんで自分はあの人と比べて何もできないんだ・・・。」と何度落ち込んだことか。 ただ、最近強いエンジニアの仕組みを理解してから落ち込むことは無くなった。 それについて書いていく。 （強いエンジニア達本人に聞いたわけではなく、観察してえられた個人の見解です） 気づき：強いエンジニアを見て落ち込む要因は2つありそう 1つは今の知識や技術力の差。 書くコードの違いだったり、成果物ができるまでの時間に差がありすぎたり、PRレビューで自分が思いもしなかったウルトラ解決策を何度も提示されて、自分の実力の無さを感じて落ち込む。 もう1つは新しいことを学ぶときの時間の差。 お互い知らない技術だったはずが、いつの間にか強いエンジニアはその技術に習熟(しているように見える)して、自分は理解不足で取り残されているという状況が発生しがち。 この時、自分には才能がないのかと

お久しぶりです．Fumiです．最近作ったスライドを共有しておきます． 追記 たくさんのご覧いただきありがとうございます。勉強会や学校、会社で使っても良いかというお問い合わせをたくさん頂いています。出典を示していただければCC BY-SAで使っていただいて構いません。ただ、あくまで個人向けに作ったもので著作権的に微妙な写真やイラストが結構使ってあるのでこのまま商用利用しようとは思わない方が良いと思います。今見返すと真ん中ー後ろの方とかもう作るの疲れちゃって雑になってたり、これ微妙だなっていうところも結構あって作り直したいなという気持ちもあります。使った際にはぜひ作者@fumi_makerのリプライやDMにでも報告してもらえたら嬉しいです。このブログ(fumimake.net)も色々知識を公開しているので一緒に示してくださると嬉しいです。 このスライドは何？ 研究会の輪講資料として電子回路に関

はじめてScalaに触れたとき、変数宣言(var)と値宣言（val)を使い分ける言語仕様に、なるほどなあ、と思った。簡単に言えば、変数(var)は再代入できて、値（val)は再代入できない。 プログラミングのスタイルとして、var宣言は命令的なプログラミング、val宣言は宣言的なプログラミングになる。どちらのプログラミングスタイルで書いているかを、varとvalで明示できるわけだ。 Javaだと言語の基本の仕組みはすべてが変数。final宣言をすることで再代入をコンパイルエラーにすることはできる。Javaは、C言語やC++などの命令的なプログラミングの系譜の言語なのですべて変数(variable)というのは、とうぜんの言語仕様だった。 命令的なスタイルから宣言的なスタイルに 命令的なプログラミングでは変数(variable)を使う。宣言的なプログラミングでは値(value)を使う。 再代入

2020/2にbefore 600点台（正確な値は紛失）から始めて2020/9に目標(900点以上)を達成しました₍₍ (ง´･_･`)ว ⁾⁾ うれC ₍₍ (ง´･_･`)ว ⁾⁾ ₍₍ (ง´･_･`)ว ⁾⁾ ₍₍ (ง´･_･`)ว ⁾⁾ pic.twitter.com/pKDX2mPmW6— まっちゃら (@matsu_chara) 2020年9月28日 英語学習は最初の入門のところが割と難しいなと思ったので、やったことをまとめておきます。（なお、この記事は頑張ったから自慢したい気持ちが90%、他の人に参考になったらなという気持ちが10%で提供されています。） ちなみに英語指導経験があるとか、すごいペラペラになったとかそういう感じではないので、近くに英語に詳しい人がいる場合はそちらの人の言うことに従うのがおすすめです。（あくまで素人がやったことが書いてあるだけ） 基本的にリスニ

はじめに 環境の用意 ブートプログラムを作る 動かしてみる コンパイル QEMU上で起動 GDBで制御 最後に おまけ 執筆者 : 高橋 浩和 はじめに RISC-VはMIPSアーキテクチャの流れを汲む正統派？のRISC CPUです。命令セットはシンプルですが、既存のメジャーなCPUのアーキテクチャと大きな違いがあるわけではありません。 Linux上で利用できるRISC-Vツール群も揃ってきたので、それらを使ってRISC-V用の小さなOSを実装してみようと思います。 最初は欲張らずに単純な実装を目指すことにします。 シングルコアのみサポート 64bitモードを使用 マルチタスキングを実現 タイムシェアリングスケジューリングを実装 割り込みネストは無し 保護機能は使わない 既存のBIOSやbootプログラムは利用せず、リセットエントリから全て作成する qemuの仮想マシン上で動作させる。ター

社内LTにて、ドメイン駆動設計と依存性逆転の原則を布教しましたʕ◔ϖ◔ʔ はてなブックマークのコメントもどうぞ！ なお、ドメイン駆動設計を理解するためには、依存についても知る必要があります。 是非、依存関係と依存オブジェクト注入もご参照ください👍🏻

はじめに なんらかの理由によってOSやOSカーネルに興味を持つ人は多々います。しかし、その次のステップとしてどんな本を読めばいいんだろうと思っている人はこれまたいっぱいいます。そこで、長年Linuxカーネルにかかわってきた筆者がこれまでに読んでよかったと思うものについてここの列挙しました。紹介するのは本だけであって、記事は省いています。もう一点、筆者が書いたものは省いています。 OSそのものに興味を持った人は、その後に興味の方向が次のような二つに分かれることが多いと筆者は考えています。 オレオレOSを作りたい 既存のOSを改造したい この仮説をもとに、それぞれについて筆者がかつて真面目に読んだ本の中から「自作OS」および「Linuxカーネル」というキーワードでよかったものを挙げておきます。Linux以外の既存OSについては語れるほどの知識はないので書いてません。 筆者について 本の良し悪し

TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説

TypeScript にはabstractキーワードという機能があり、これを使うことで抽象クラスや抽象メンバを宣言することができる。 この機能を上手く使ってクラスを作ることで、可読性が高く、変更にも強いコードを設計できる。 abstractキーワードを使ったクラスやメンバの詳細な挙動については、以下の記事に書いた。 numb86-tech.hatenablog.com 本記事では、架空のオンラインショップの開発現場を通して、具体的にabstractをどう使えばよいのか、どのようなケースで役に立つのか、といったことを説明していく。 動作確認はv3.8.2で行っている。 間違った共通化 このオンラインショップは書籍の販売を行っており、商品である書籍はProductというクラスで表現している。 class Product { productCode: string; title: string;

この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性

年の瀬なので、私自身が今年利用した技術をベースに技術スタックをまとめてみようと思います。 とはいえ Web Standard といった広い対象から、フレームワークやライブラリまで、粒度の違うものを全て言及するのは無理があるというもの。特に強く言及できるものは個別で説明しつつ、最後に利用する機会がなかったものも最後に記載する形で。 以下常体。 追記: マイナー企業のようなので一応書いておきますが、筆者は本業ではLINE株式会社という組織でいわゆるエンジニアリングマネージャーと言われるような業務とその採用に関わる仕事をしています。 利用した技術一覧 HTML/CSS/JS みたいなことを書いてるとキリがないので、独断と偏見で区分けして適宜漉いています。特に利用する機会が多かったものは太字でピックアップ。 Frontend Language/Platform TypeScript JavaScr

こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木（@dkfj）です。 8月25日に開催されたJAWS-UG朝会#12で、CloudFormation StackSets × AWS Organizationsの話をしてきました。JAWS-UG朝会は、朝の7:30から勉強会をしようという会で、夜の勉強会に参加できない人や、テレワーク開始前の時間を有効活用したい人に好評を博しています。そして、ラジオ体操から始まる健康的な支部です。 発表内容 発表した内容は、タイトルの通りにCloudFormation StackSets × AWS Organizationsです。CloudFormation StackSetsは、他のAWSアカウントやリージョンに対してCloudFormationのスタックを設定できる素晴

メルペイ エキスパートチームの@tenntennです。本稿は Merpay Tech Openness Month の11日目の記事です。 「プログラミング言語Go完全入門」の期間限定公開のお知らせでも書いたように、メルペイでは、社外の方向けにGopher道場という体系的にGoを学べる場を無償で提供してきました。Goの普及を目的にこれまでに8回開催し100人以上の方に参加していただきました。 また、Gopher道場の動画や資料はGopher道場 自習室として誰でも利用できるようになっており、現時点で300名以上の方が利用されています。 Gopher道場の資料のベースになっている「プログラミング言語Go完全入門」は、2020年7月31日までの限定公開になっていましたが、本日より公開期限を撤廃し、完全公開することになりました。 また、本日8月31日から始まる「Online Summer Int

今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか

今年は「組織変革」「組織マネジメント」「育成」あたりをテーマにした発表をしたり，ポッドキャストで話をしているので，最近は「マネジメント関連」で相談や質問を受ける機会が増えている．一言で表現すると？みたいに聞かれたときは 「愛情のある無茶振り」 って答えてはいるけど，そもそも一言で表現できるようなものじゃない． 44 engineering management lessons 今まで紹介したことはなかったけど，マネジメントの参考にしている “44 engineering management lessons” という記事がある．本当に大好きな記事で，記事の存在を知った2年前ぐらいから定期的に読み直すようにしている．タイトルの通り，44種類の原則が紹介されていて，大きく7種類に分類されている．どの原則も参考になるけど，その中でも特に好きなものをコメントを添えて紹介したいと思う（翻訳するわけで