こんにちは、マスタケ(@mathetake)と申します。現在はTetrate.ioという米国のスタートアップで、日本からFull Remoteで働いています。特にこれと言って今のロールに名前があるわけではありませんが、Open Source EngineerとかSoftware Engineer(Open Source)という職種が正しく説明できているかなと思います。(弊社はタイトルもないので、Senior EngとかStaff Engのような区別はありません) ロールがそんな感じなので、仕事のほぼ100％がオープンソースで、GitHubの僕のプロフィールページで全て公開されています: というわけで2021年どんな仕事をしてきたのか、せっかく(?)オープンなのでオープンに振り返ってみたいと思います(プライベートなものも含みます)。最後にOSSを仕事とすることの所感もちょっと書きます。 En

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

eBPF（extended Berkley Packet Filter）という用語を著者が初めてみかけたのは、2015年ごろだった。最初は、eBPFをその字面のとおり、パケットキャプチャやパケットフィルタリングを担うだけの、Linuxの新しいサブシステムであろうと認識していた。しかし、実際にはそうではなかった。 システム性能の分析のための方法論をまとめた書籍Systems Performance 1 の著者で有名なBrendan Greggが、Linuxのネットワークサブシステムとは特に関係ない文脈で、古典的なシステム性能計測ツールでは計測できないことを計測するツールを作っていた。その計測ツールがeBPFという技術によって実装されていることを知ったときに、eBPFに興味をもったのだった。また、eBPFは、システム性能を調べる用途以外にXDP（eXpress Data Path）と呼ばれるプ

俺たちは絶対にKubernetes上の分析ログを欠損させたくないんだっ...！！その対策としてのfluent-pvc-operatorを紹介🐥kubernetes この記事はZOZO Advent Calendar 2021に出したかったけど既に枠が埋まっていたので野良で出した記事です。 はじめに こんにちは。絶対にKubernetes上の分析ログを欠損させたくない@civitaspoです。今年は社内のログ収集基盤構築プロジェクトでfluent-pvc-operatorというKubernetes Operatorを作りました。この記事ではfluent-pvc-operatorが解決する課題、及び機能や使い方について紹介したいと思います。 なお、この記事ではfluent-pvc-operatorの説明に集中するため、ログ収集基盤構築プロジェクトの全体像等には触れません。プロジェクトの全体像

株式会社ZOZO 技術本部 本部長の @sonots です。この記事は ZOZOのAdvent Calendar 2021のカレンダー1の最終回（25日目）です。 2021年度、ZOZOにとっても、私にとっても大きな変化が2つありました。1つ目が2021年3月に前CTOの今村が退任し、私が全社技術戦略を策定する役割とZOZOTOWNリプレイスプロジェクト責任者を引き継いだこと、2つ目が2021年10月にZOZOとZOZOテクノロジーズの組織が再編され、私も含む開発部門がZOZOに併合されたことです。 この記事ではその変化の中で私と組織がこの一年取り組んできたものをいくつか取り上げたいと思います。 全社技術戦略策定 2021年4月にCTO的な役割を引き継いで、個人的に一番変わったのは経営陣（当時はZOZOテクノロジーズ）との対話が増えたことだと思います。私の考えているCTOの役割と、経営陣の

※この記事は、【LayerX Advent Calendar】62日目の記事です。 どうも。すべての経済活動を、デジタル化し、ハタラクをバクラクに変えたい福島です。 今日は図々しくもアドベントカレンダー3度目の登場です。どうしても伝えたいことがありの登場です。 LayerX、決済事業やるってよLayerXで決済事業を来年はじめますというお話です。そのための立ち上げメンバーを絶賛募集します！ LayerXが決済? LayerXって請求書SaaSの会社じゃないの?と皆様の頭に「?」が浮かんでいるのが容易に想像できます。 実はLayerXがやっている「請求書受取SaaS」と「決済」はめちゃくちゃ相性が良いのです。 LayerXでは先日、ブランド名称を「バクラク」にリブランディングしました。より幅広いお客様にも覚えてもらいやすくという狙いのリブランディングです。 この記事でも触れてますが、第二章と

2020年にやったこと 2019年にやったこと 2018年にやったこと 2017年にやったこと 2016年にやったこと 2015年にやったこと というわけでこれ毎年書いてるんですけど、 なんか参戦したくなったので Rubyist近況 Advent Calendar 2021 24日目です。 入居者募集 記事があるくらいですし、自由に書こうと思います。メリークリスマス。 発表 1歳児がいる状況で家を留守にしたり夜に声を出したりすると家族に負担がかかるので、録画提出できるカンファレンスにしか基本参加しないことにしているのだけど、コロナが長引いていることにより今年も登壇しやすい状況が続いた。 とはいえ、ハイブリッド開催だったRubyConfに関しては、国内の渡航だけでShopifyのYJITチーム全員 (や当地のRubyフレンズ) と対面で話せる貴重な機会だったので、行けなかったのは惜しいなあと

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

英語で先に書いてから翻訳しています どうも個人アプリ作家のTAKUYAと申します。 Gitはコードベースや変更履歴の管理に必要不可欠なツールです。たとえ個人でアプリを開発していたとしても。 僕はデスクトップとモバイルの両方で動作する、InkdropというMarkdownのノートアプリを独りで開発しています。 当アプリはデスクトップ版はElectron、モバイル版はReact Nativeで作られています。 僕は開発作業は基本的にtmuxとvimでターミナル上で行っています。vimによるJavaScriptコーディングのためのセットアップについては前回シェアしたとおりです。 本稿では、僕のGitのワークフローについてご紹介したいと思います。 内容はすでにGitの基本をご存知の方向けとなります。 Gitの操作も基本的にはターミナル上で行っています。 色んなGUIベースのGitクライアントアプリ

この記事はモバイルファクトリー Advent Calendar 2021の25日目の記事です。 メリークリスマス🎉 エンジニアのid:kfly8です。 技術ブログの「ネタがない」といったコメントや「この記事の課題がよくわからない」といった記事レビューをすることがあります。技術アドベントカレンダーの時期は、短期間に記事が集中するので、特に困らせているように感じます。 普段から意識する習慣で、楽ができないかと考えると、「技術ブログが書ける開発をする」のが良いと思いました。 誤解しないでほしいのが、「技術ブログを書くために開発をしよう」と言いたいわけではないです。あくまで、チーム、事業の目的ありきです。 ただ「技術ブログが書ける開発をする」ことは、普段の開発の質を高めると思っています。 技術ブログが書ける開発とは？ モバファクの技術ブログでは、「課題を解決する方法や経験を発信したい」と思ってい

はじめに 皆さん、SQLチューニングしてますか？（唐突） 私は仕事柄RDBMSのSQLチューニングをすることが多いのですが、たまにチューニングの一環で SQL文の書き換え をすることがあります。 その際に問題になるのが、書き換えたSQL文が等価であるかどうかの確認が大変なことです。 SQL文を書き換えた場合には、想定通りの結果を取得できるか確認するために、テストをやり直す必要があります。 これが開発早期のフェーズならまだましなのですが、結合テスト以降だと手戻りも多くかなりコストがかかりますし、既に本番運用が始まったシステムともなると、テスト自体が困難なこともあります。 また、複雑なSQL文だと網羅的なテストケースを作成すること自体が困難であるため、完全に正しいと確信することはできません。 なので、SQL文の書き換えの正しさを証明する良い手段はないかと考えていました。 SQLチューニングとは

はじめに この記事は Fujitsu Advent Calendar 2021 25日目の記事です。（記事は個人の見解であり、組織を代表するものではありません。） さて、今年もこれまでと同じく不揮発メモリの記事を書きます。今回は以下の内容です。 不揮発メモリ周りの規格・新仕様(CXL, RDMA) メモリ不足時の不揮発メモリの活用 Filesystem-DAXの動向 不揮発メモリ周りの規格・新仕様 今年は規格回りでいくつか新仕様が策定されています。まずは、それらについてざっくりと解説していきましょう。 CXLの不揮発メモリ対応 これまではNVDIMM、すなわちDRAMと同じようにCPU中のメモリコントローラからDDR4で直接つながるデバイスであった不揮発メモリですが、ここへきて新たな接続方法が追加されようとしています。それがCompute Express Link(CXL)です。 コンピュ

このエントリはRust Advent Calendar (3) 22(-10)日目 の記事です。 5年前にxremapというLinux向けのキーリマッパーを作った (Linux向けの最強のキーリマッパーを作った - k0kubun's blog) のだが、X11のレイヤーで実装したため、GNOMEのActivitiesでリマップが効かなかったり、WaylandではXWayland内でしか動かないといった問題があった。 これらの問題を解決すべく、xkeysnailやwayremapといったツールが後に作られたのだが、xkeysnailはWaylandで動かずwayremapはX11で動かない方針なのと、やはり全てのキー入力を中継するようなツールはPythonのような遅い言語よりRustみたいな速い言語で書かれるべきだと思ったので、後発のツール*1の良いところ取りをしながら今回xremapを作

移行ツールを使うと余計なものが色々入ってしまうため、 Intel Macbook ProからApple Silicon Macbook Proへと手動で移行した。 移行元: Macbook Pro 13” Intel Core i7 32GB 2020 移行先: Macbook Pro 14” Apple M1 Max 64 GB 2021 最初にやっておくと便利なこと それぞれのmacでユニバーサルクリップボードを有効化 ファイルとか文字列のやりとりが楽になる ユニバーサルクリップボードを使って Apple デバイス間でコピーアンドペーストする - Apple サポート (日本) 適当に元macでファイルをコピー、新しいmacでペーストするだけでファイルコピーできる scpやrsyncでファイルを渡せるようにする

はじめに こんにちは、Google Cloudでオブザーバビリティを担当しているものです。Cloud Operations suiteをよろしくおねがいします。（宣伝終わり） この記事はGo Advent Calendar 2021 その1の22日目の記事です。昨日は @sago35tk さんの「ESP32 向けに TinyGo をセットアップする」でした。TinyGoのコアな情報を日本語で教えてくれるtakasagoさんには本当にいつも感謝しています。 さて、今日はGo製のアプリケーションをdockerlessでコンテナ化できるkoの紹介をします。koは本当にイチオシのツールで、みんなに使ってもらいたいのでぜひ使ってください。 github.com DockerによるGo製アプリのコンテナ化 まず最もポピュラーと思われるDockerを用いた場合のGo製アプリケーションのコンテナ化の方法に

こんにちは。Yowkeesです。 この記事は、「キーボード #2 Advent Calendar 2021」の21日目の記事です。 昨日の記事はjigya♧kkumaさんによる「プロダクトを始めたきっかけと伝えたいこと」でした。 2021年のプライベート時間のほとんどを捧げたKeyball46を発売するまでの活動をまとめます。 目次 １．自作キーボードデビュー ２．アイデアを試したくてKeyball初号機作ってみた ３．Keyball46の試作 ４．ここまで来たら止めれない！射出成型！ ５．Keyball46の販売開始 ６．実は実店舗を準備中 １．自作キーボードデビュー デビューについて書くために少々自己紹介を。僕Yowkeesは人生を電気に捧げた回路エンジニアです。1か月間ぶっ続けでオシロスコープの前で高密度基板を手半田なんてザラでしたが、電子回路大好き人なので楽しく(？)仕事してきまし

はじめに 皆さんこんにちは．3回生のらん（@hoshina350）です． 文字列マッチングに便利な正規表現ですが，テキトーに書くと脆弱になり得るという情報を耳にしてから色々と原因や対策を調べていました． しかし，多くの記事で紹介されていた対策方法は，「独自の正規表現を使用しないー」とか「 * や + などの繰り返し表現はなるべく使わないー」とかいう なんともふわっとしたものでした．これでは「いやぁ確かにそうなんかもしれんけど…そうゆう訳にはいかんやんか…」と納得できません． つまり，「本質的に何が問題」で，「具体的にどんな特徴のある正規表現が脆弱になり得るのか」を知りたい訳です． そこで，様々な文献を調査してみました．本記事では調査して溜まった知見を紹介していきます． 本記事は， Purdue大学のJames Davis教授による “The Regular Expression Denia

はじめに 「Goの正規表現は遅い」 そんなふうによく言われていました。（最近はあまり聞かなくなりましたが） たとえば、↓の記事ではPythonの正規表現と比較して1.5倍くらい遅いという結果になっています： この話には「Goの正規表現は最悪時間が短くなるように安定したアルゴリズムを採用しているから」という回答があります： ↑の記事の比較では、GoがPerlに対して約10倍以上高速という結果が出ているので、「Goの正規表現は遅くない！はい、論破ー！」というわけですね。 なんでこうなるのかも↑の記事で説明されているとおりですが、Perl（などのバックトラック型エンジン）が入力長に対して指数関数的に実行時間が伸びていくのに対し、Goの正規表現エンジンは入力長に対して線形時間で実行時間が伸びていくアルゴリズムを採用しているため、入力が長くなると急激にGoのほうが有利になるからです： 一方で、入力が

Mercari advent calender の21日目を担当します@sanposhihoです。現在大学の学部4回生で、メルカリでは内定者インターンとして、メルカリのホーム画面などのバックエンドを担当するチームに所属しています。 また、最近は個人的にKubernetesやその周辺のOSSにコントリビュートをしていて、特にKubernetesのコントロールプレーンのコンポーネントのうちの一つであるkube-scheduler周りを触ってることが多いです。 後で詳しく説明しますが、kube-schedulerはPodをどのNodeで実行するかを決定しているコンポーネントです。NodeAffinityや比較的新しいものだとPod Topology Spread Constraintsなど、Podのスケジュールの制約を指定できる機能も基本的にこのkube-schedulerに実装されています。

このエントリはRust Advent Calendarの2日目の記事です。 空いてる日を埋める担当のκeenです。2日目が空いてたので遡って記事を投稿します。 最近v1.0.0がリリースされたリンカ、moldを使うとビルドが高速化するよというお話です。 Rustのビルド、特にインクリメンタルビルドにおいてはRustコンパイラの速さと同じくらいリンカの速度がコンパイル時間に影響します。 この最後のバイナリを作る時間は意外と効いてきます。 具体例としてActix Webにあるexample、 basic をインクリメンタルビルドする例をみてみましょう。 この basic はたった42行の小さなアプリケーションです。 ただし、依存に Actix Webという巨大なライブラリを使っているので最終的なバイナリには非常に多くのコードが含まれます。フレームワークを使ってアプリケーションを開発してるときに