タグ

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

  • 静的サイトをFediverseに対応させる | おそらくはそれさえも平凡な日々

    当サイトをFediverseに対応させました。 @songmu.jp@songmu.jp でMastodonなどでリモートフォローできます。 やったことは、 このブログがFediverseに対応しました というtyageさんのエントリーをそのままなぞっただけです。このエントリーはh-cardのサイトトップへの掲出に関する説明が書き漏れていそうでしたが、それも実施しました。 当サイトは静的サイトであり、付随機能は外部サービスに頼りたいと考えている。例えば、コメント機能はDisqusを使っている。Fediverseに関しても何かそういうサービスがないかと思っていたが、Bridge Fedというサービスがあり、上記のエントリー内で懇切丁寧に解説されていたので導入は比較的簡単で、作業時間は小一時間でできた。大まかな手順は以下。 Bridgy Fed というサービスを利用してサイトをFedivers

    静的サイトをFediverseに対応させる | おそらくはそれさえも平凡な日々
    mapk0y
    mapk0y 2024/02/04
  • コミュ力が無いのはいつだって自分 | おそらくはそれさえも平凡な日々

    突然何を言い出すのかという話ですが、対話相手にコミュニケーション能力を求める醜さについて書きたくなったので書きます。 僕はオタクだったしスクールカーストで言うと下の方を彷徨ってきた。地元でもいろいろあって浮いていた。新卒時の就活も散々だった。なので、コミュ力がないことは自覚しているし、だからこそ「コミュニケーション能力」という言葉には警戒心があります。 比較的マイノリティであったことが多かった経験上分かったのは、相手とコミュニケーションが取りづらいな、と思うときは、そもそもプロトコルが異なる、ということです。 これは、話している自然言語が違うようなものだと考えるとわかりやすい。例えば、自分が日語しか話せず、相手がロシア語しか話せないのであれば、まともなコミュニケーションが成り立たないのは明らかです。そして、その時に、日語が話せない相手にコミュ力がないと思うような人はいないでしょう。 そ

    コミュ力が無いのはいつだって自分 | おそらくはそれさえも平凡な日々
  • リリース用のpull requestを自動作成し、マージされたら自動でタグを打つtagpr | おそらくはそれさえも平凡な日々

    常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr

    リリース用のpull requestを自動作成し、マージされたら自動でタグを打つtagpr | おそらくはそれさえも平凡な日々
  • git-pr-releaseとGitHub Actionsでワンクリックデプロイを実現する | おそらくはそれさえも平凡な日々

    突然ですが、git-pr-releaseのなんちゃってコラボレーターである私が僭越ながら、その王道の使い方を皆様に伝授していきます。何番煎じかの記事ではありますが、現代の、特にGitHub Actions出現以降の使い方をまとめたいというのが動機です。 https://github.com/x-motemen/git-pr-release https://rubygems.org/gems/git-pr-release git-pr-releaseはGitHubを業務開発で利用している場合に便利なツールで、デフォルトブランチにマージされたpull requestをリリース項目として一覧し、それをpull request化してくれるものです。これにより以下のことが実現できます。 リリース項目が一覧されることによるリリース内容の明確化 マージボタンによる明快なワンクリックデプロイの実現 pul

    git-pr-releaseとGitHub Actionsでワンクリックデプロイを実現する | おそらくはそれさえも平凡な日々
  • GitHub Actionsのmatrixを動的に生成してGoの最新安定バージョンでテストする | おそらくはそれさえも平凡な日々

    Goのライブラリを提供している場合、Goの最新の安定バージョンでテストしたくなることがあるでしょう。具体的にはマイナーバージョンの直近2バージョン、今だと1.18と1.17です。GitHub Actions定義への記述は以下のようになるでしょう。 jobs: test: runs-on: ubuntu-latest strategy: matrix: go-version: ['1.17', '1.18'] steps: - uses: actions/setup-go@v3 with: go-version: ${{ matrix.go-version }} - run: go test ./... しかしこのようにベタに書いてしまうと、Goのバージョンが上がったときにチマチマ上げるのが地味にめんどくさい。なのでこれを動的に生成したい。 これは事前にGoの安定バージョン一覧を取得するjo

    GitHub Actionsのmatrixを動的に生成してGoの最新安定バージョンでテストする | おそらくはそれさえも平凡な日々
  • 雌伏の時 | おそらくはそれさえも平凡な日々

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

    雌伏の時 | おそらくはそれさえも平凡な日々
  • Montereyと(After)Shokzの相性問題とその解決方法 | おそらくはそれさえも平凡な日々

    macOSをMontereyにあげてからShokzの骨伝導ヘッドフォンが不調になる、具体的にはミーティング中に突然ミュートになるという問題がある。ボヤキや暫定解決方法含めてTwitter上に書き散らしていたが、困っている人が相変わらずいるようなのでまとめておく。と言っても、以下のredditに書かれている内容そのままです。 https://www.reddit.com/r/Zoom/comments/qhmpkg/aftershokz_aeropex_on_zoom_and_macos_monterey/ 自動音量調整が効いている場合それが悪さをする サウンド環境設定を開いて観察するとよく分かる マイク音量がどんどん下がっていってミュートされてしまう 音量自動調整を無効にすれば暫定解決 会議ツールの設定でそれができればOK (zoom等) 設定できない場合もChromeであれば以下の拡張を

    Montereyと(After)Shokzの相性問題とその解決方法 | おそらくはそれさえも平凡な日々
  • 体重体組成計を買い替えてSlack投稿を自動化した | おそらくはそれさえも平凡な日々

    だいたい以下の様な話です。 TANITAの体重体組成計を買った 100g単位で計測ができる ヘルスプラネットサービスでAPIから値の取得ができる https://www.healthplanet.jp APIクライアントを作った https://github.com/Songmu/healthplanet これは結局自動化のためには使わなかった 体重体組成計を買い替えた。元々TANITAのやつを10年以上使っていたが、最近脚が一つだめになってガタつくようになったので買い換えた。 減量のモチベーション維持のためもある。最近は計測値をiPhoneのヘルスケアに手動でちまちま入力していたが、その辺りを自動できて、APIで値が取れたりして、グラフ等で見やすくしたいとは常々思っていた。そして、最近社内に体重をシェアするSlackチャンネルが作られたのもあって、自動化モチベーションが更に高まっていたの

    体重体組成計を買い替えてSlack投稿を自動化した | おそらくはそれさえも平凡な日々
    mapk0y
    mapk0y 2022/01/17
    BC-768 よさそう
  • VPSを解約してFirebase Hostingにブログを移した | おそらくはそれさえも平凡な日々

    タイトルの通り。なんとなく自分のサイトを自分で運用したいと思っている。それはWebエンジニアとしてのポートフォリオ的な側面もあるし、それに加えて、自分の書いた文章を自分の管理下におきたい欲求があるのだと思う。 サブブログを、はてなブログに持っていますが(https://blog.song.mu)、これもまた、コンテンツはblogsync を使って管理しています。 このサイトはもともとVPS上のNginxから静的配信されており、 VPS上のgit bareリポジトリに直接push post-receive Hook で riji を呼び出してサイト再構築 という結構カッコいいフローを組んでいて 、これがなかなか気に入っていた。以下のような点が良かった。 国内のVPSへのgitリポジトリへのpushはかなり早い GitHubへのpushに少し引っかかりを感じるレベル とはいえコンマ数秒程度の違

    VPSを解約してFirebase Hostingにブログを移した | おそらくはそれさえも平凡な日々
  • GitHub上でGoプロジェクトを正しくTransferする | おそらくはそれさえも平凡な日々

    tl;dr リポジトリを新オーナーにTransferする 返す刀でTransferしたRepositoryを元オーナー側にForkしもどす Forkしたものをアーカイブする Transfer先のモジュール名を変更し、新しいタグを打って開発を継続する GitHubのリポジトリのオーナー変更 この記事はGo Advent Calendar 2021カレンダー2の10日目の記事です。 さて、オーナー変更や個人プロジェクトをオーガニゼーションに移行したい等の理由で、GitHub上のリポジトリのオーナーを変更することがあるでしょう。 GitHubにはTransferring a repositoryの機能があり、それを使えば簡単です。issueやpull request等の履歴も含めて引き継いでくれますし、旧リポジトリから新リポジトリへのリダイレクトも自動的におこなわれます。なのでこれで解決なのです

    GitHub上でGoプロジェクトを正しくTransferする | おそらくはそれさえも平凡な日々
  • 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カードスロットでタイムマシンバックアップする | おそらくはそれさえも平凡な日々
    mapk0y
    mapk0y 2021/12/02
  • 41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々

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

    41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
  • Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々

    Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな

    Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
    mapk0y
    mapk0y 2021/05/19
  • 続・マンション購入記(売買契約から内覧まで) | おそらくはそれさえも平凡な日々

    前回、購入を決めたところまで書いたが、今回は家ができて内覧するところまで。 ローン審査と団信 前回通ったのは仮審査なので、次は売買契約と住宅ローン審査となる。 住宅ローンには団信(団体信用生命保険)というやつが含まれている。これは、人が死んだり、障害を抱えるなどして返済能力が無くなったときにローンの残債がチャラになるという強力な保険だ。それだけの優遇があるので、その分、ある程度健康であることが求められる。審査申込時に健康状態の記入項目がある。 それまでは比較的健康には自信があり、実際その前年までは健康診断で引っかかったことはなかった。しかし、前年から外的要因の変化が色々あり、体重増加等が気になってはいたのだ。 果たして、その年の健康診断は初めての再検査となった。LDLコレステロール値が正常値範囲外になっていたのだ。焦ってすぐに再検査を申し込み、再検査までの1ヶ月の間、酒を断ちジム通

    続・マンション購入記(売買契約から内覧まで) | おそらくはそれさえも平凡な日々
    mapk0y
    mapk0y 2021/05/17
  • NatureのVP of Engineeringになっていました | おそらくはそれさえも平凡な日々

    Nature社は今年の頭にはスタッフが20人を超え(内ハードウェアエンジニア2人、ソフトウェアエンジニア8人)、いよいよ組織らしくなってきました。そして、この4月の期替わりから組織体制が見直され、各専門領域にVPを置くことになりました。目的としては、社内のリーダーシップの強化による組織の成長や、権限を明確化することにより、それぞれのチームが自律的に速度を落とさず動けることなどが挙げられます。 それにより、僕もCTOからVPoE (VP of Engineering) という立場になりました。テック関連のVPは以下の3つに役割分担することにしたのです。ソフトウェア開発とハードウェア開発でも分かれているところがIoT企業ならではとも言えるでしょう。 VP of Engineering VP of Software Development VP of Hardware Development 僕

    NatureのVP of Engineeringになっていました | おそらくはそれさえも平凡な日々
  • 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のルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
  • マンション購入記(勢いで購入を決めるまで) | おそらくはそれさえも平凡な日々

    家を買うつもりはあまりなかったが、ライフステージの変更に伴い買った、という良くある話です。2016年までの昔話です。 一応今の住所はあまり積極的にはネット上では公開していません。ただ、分かる人にはどのあたりか分かってしまいそうなので、その場合はそっとしてもらえると嬉しいです。 二子新地時代の購入未遂事件 結婚当初は僕は持ち家志向は強くなく、の方が比較的強かった。ただ、当時住んでいた二子新地が非常に気に入っていたこともあり、一度、近くの不動産屋に行ったことがあった。2011年頃の話。 確か二子玉の再開発絡みで周辺にマンションや建売住宅が建ちはじめていて、その中で当時の近所に建設中の分譲住宅が悪くない金額で売りに出されていたことがあった。それをふらっと内見させてもらい、それが良かったため、興奮したに連れられて不動産屋にまでも行くことになった。 「あーこれは買わされる流れかもな」と思っていた

    マンション購入記(勢いで購入を決めるまで) | おそらくはそれさえも平凡な日々
  • 同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々

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

    同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
    mapk0y
    mapk0y 2021/03/08
  • 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枚分を書いたなどの伝説を聞くに、圧倒されて唖然としてしまい、やる気を失ってしまいそうになります。 しかし果たして