タグ

ブックマーク / songmu.jp (17)

  • 雌伏の時 | おそらくはそれさえも平凡な日々

    カッコつけたタイトルを付けてしまった。中二っぽい。 強がりと言うか、自分に言い聞かせている部分もあるのだと思う。 有り体に言うと、新しい環境にまだ苦しんでいて、上手く動けていない。こんなことを書くと同僚に心配されてしまいそうだが、同僚には現状を伝えていて、その上で信頼してくれているとも感じている。会社に不満があるわけではなくて満足している。 少し精神的に参っていたので、今週前半は少し休ませてもらった。これは休んだほうが良いな、と思ってyoshioriさんに相談したところ、こちらから休みについては何も言わずとも「休んだほうが良いよ」と言ってくれた。話が早くてありがたかった。 現状意識していることや感じていることについて書き留めておく。 成果を完璧に出せてはいないが淡々とやる 現状、社内では成果目標を定めて、達成度を振り返るというのを毎月やっているが、1月に関しては100%をつけることができた

    雌伏の時 | おそらくはそれさえも平凡な日々
  • MacBook Proに復活したSDカードスロットでタイムマシンバックアップする | おそらくはそれさえも平凡な日々

    M1 ProのMacBook Pro '14を買いました。ちょうど業務PCとして買えるタイミングだったのでラッキーだった。多少トラブルはありますが、それも含めて楽しんでいます。 SDカードスロットが復活したことも話題でしたが、正直要らんなと思っていました。しかし @yamaz さんの以下のツイートを見て、確かにTime Machine運用するのは面白いかもしれない、と思ってやってみた。 なんでなんで!?みなさん、Timemachineのディスクは外付けのSDカードじゃないの?? https://t.co/YTj4QNixNm — 最速配信研究会 山崎大輔 (@yamaz) October 18, 2021 これまでTime Machineは自宅のQNAPに取っていたのだが、正直Time Machineが役に立ったことは全く無い割にはメンテナンスコストがかかっていたので微妙に思っていた。正直

    MacBook Proに復活したSDカードスロットでタイムマシンバックアップする | おそらくはそれさえも平凡な日々
  • 41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々

    最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果

    41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
  • Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々

    tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で

    Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
  • 同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々

    tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,

    同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
  • GoでSQLにトレーシングコメントを埋め込んで実行する | おそらくはそれさえも平凡な日々

    アプリケーションが発行するSQLにコメントが埋め込めると便利です。例えば、 /* path/to/logic.go:334 */ SELECT ... のようにSQLに発行元の情報をコメントとして埋め込んでからExecすれば、DB側のログ(general log等)にも記録されるため、SREやDREサイドからも、負荷の高いSQLがアプリケーションのどこから発行されているかが分かりやすくなります。 Goには github.com/shogo82148/go-sql-proxy という、SQL実行をトレースし、フック処理を差し込める便利なライブラリがありますが、今回それにpull requestを送って、SQL実行前にクエリの書き換えができるようにしました。 https://github.com/shogo82148/go-sql-proxy/pull/61 https://github.co

    GoでSQLにトレーシングコメントを埋め込んで実行する | おそらくはそれさえも平凡な日々
  • あなたは本当に文章を書くのが遅いのか | おそらくはそれさえも平凡な日々

    このエントリーは、Mackerel Advent Calendar 2020 5日目の記事です。 さて、多くの人が「自分は文章を書くのが遅い」と思っているのではないでしょうか。僕もそう思っていました。 ブログエントリーを書き出すと得てして思っていた以上の時間がかかります。書くことがだいたい決まっているちょいネタのつもりであっても書き出してみたら数時間かかってしまう、大作であれば丸一日潰れてしまったり、しばらく寝かして数日がかりになることも珍しくありません。そして「ああ、自分は文章を書くのがなんて遅いのだ」と嘆いてしまうのです。 そして、見事な大作ブログ記事をバンバン投稿している人を見ると「書くのが速い人は羨ましいなー」と羨望してしまいます。また故栗薫氏が、一時間に原稿用紙96枚分を書いたなどの伝説を聞くに、圧倒されて唖然としてしまい、やる気を失ってしまいそうになります。 しかし果たして

  • Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々

    追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST

    Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々
  • RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々

    RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_

    RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
  • 「コンテナ物語」は破壊的イノベーションと人間たちの物語だった | おそらくはそれさえも平凡な日々

    これは、ITエンジニアが真っ先に想起するアプリケーションコンテナではなくて「物理コンテナ」の物語です。以前、コンテナに関するイベントに登壇させていただいた際に読んでいたのですが、やっとこさエントリを書きます。 このについて このには、コンテナが「20世紀最大の発明」と言われるくらい、如何に革新的であったか、どのように普及していったかが書かれている。これは是非ITエンジニアに読んで欲しい。今のアプリケーションコンテナとの類似点が非常に多いからだ。原題は「The Box」であるが、日語訳の「コンテナ物語」は僕らにとってはナイス訳だと言わざるを得ない。 コンテナが発明され、世界の船やトラック、鉄道のコンテナ運送が共通化される中で、どのような変化が起こったかについて、具体的には以下のようなことが書かれている。 そもそもどうしてそのようなアイデアが出てきたのか どのように規格化が進行したのか

  • Nature Remo作ってる会社のCTOになったのでみんな買ってくれよな! | おそらくはそれさえも平凡な日々

    6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社

    Nature Remo作ってる会社のCTOになったのでみんな買ってくれよな! | おそらくはそれさえも平凡な日々
  • えるしっているか、Lは便利 | おそらくはそれさえも平凡な日々

    Perl Advent calendar 2017の6日目です。 LというCPANモジュールがありまして、これはPerlのコマンドラインワンライナーを書きやすくするためのモジュールです。 % perl -MString::Random -E 'say String::Random->new->randregex("[0-9a-z-A-Z]{12}")' あるモジュールを読み込んでクラスメソッドを呼び出したい時には、上記のように、モジュール名を2回打ち込まないといけないのが難点ですが、それを以下のように書くことができる。 % perl -ML -E 'say "String::Random"->new->randregex("[0-9a-zA-Z]{12}")' 便利。 このモジュールは僕が5年前にCPANに上げたモジュールなのですが、Perl 5.27.1で失敗するテストケースがあり、今年

    えるしっているか、Lは便利 | おそらくはそれさえも平凡な日々
  • 恐らくそれなりに正確なGoのApacheログパーザーを書いた | おそらくはそれさえも平凡な日々

    https://github.com/Songmu/axslogparser/ 下記のようにすれば、ApacheログかLTSVログをよしなにパーズしてくれます。 import "github.com/Songmu/axslogparser" log, err := axslogparser.Parse(line) Apacheのログ形式として知られるアクセスログはいろいろな形式があり、正確なパーズが何気に困難であることが知られています。よく使われるのは以下のような形式です。axslogparserはこれらの形式をサポートしています。 commonログ commonログの先頭にvhostが付いたもの combinedログ combinedに独自フィールドが追加されたもの フィールドの区切り文字は一般的には半角スペースが使われますが、パーズし易さのためにタブ文字が使われることもあります。現在は

    恐らくそれなりに正確なGoのApacheログパーザーを書いた | おそらくはそれさえも平凡な日々
  • Mac上にGoの開発環境を構築する〜下準備編 | おそらくはそれさえも平凡な日々

    同僚がGoを始める上で、案外まとまった資料が無さそうだったので書いてみることにしました。 Macでhomebrewが入っていることが前提です。事前に brew update をおこない formula を最新のものにしておくと躓くことが少ないでしょう。 Goのインストール % brew install go エントリ執筆時点では、1.6.2 が入ります。Goはメジャーバージョンが同じ場合は、後方互換が保たれているので、基的に新しいやつを入れて問題ありません。 環境変数の設定 $GOPATH だけを決めればOKです。$GOPATH はどこでも良いのですが、ここでは $HOME/dev を $GOPATH に設定します。また、 $GOPATH/bin に $PATH も通しておきます。 export GOPATH=$HOME/dev export PATH=$GOPATH/bin:$PATH

    Mac上にGoの開発環境を構築する〜下準備編 | おそらくはそれさえも平凡な日々
  • 「nginx実践入門」は紛うことなき「実践」の本だった | おそらくはそれさえも平凡な日々

    nginx実践入門 技術評論社様よりご恵贈頂きました。著者の1人である cubicdaiya さんより、いただけるというお話をもらった時は非常に光栄でした。ありがとうございます。 思っていたとおり非常に良いでしたが、特に良かった点としては、章立てを含めた構成の素晴らしさ、そしてまさに「実践」を意識したインフラアーキテクチャのになっている点だと思う。 Nginxのアーキテクチャ 静的ファイル配信 リバプロ構成 コンテンツ配信システム モニタリング LuaとかOpenRestyとかによる拡張 という章立てになっていて、流れが非常にわかりやすい。Nginxを軸にした、様々なインフラのデザインパターンの説明になっている。これは紛うことなき「実践」のであり、イマドキのインフラアーキテクチャについて学ぶ上でも良である。 静的ファイル配信、リバプロ構成、コンテンツ配信システム、それぞれの構成にお

  • ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々

    あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか?もしくはコードカバレッジだけにとらわれすぎていないでしょうか? 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に番用の設定ファイルを使うことはないため、番用の設定ファ

    ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
  • クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々

    デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

    クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
  • 1