tblsをセットアップするGitHub Actionとしてsetup-tbls（を作るツールとしてgh-setup）を作った - Copy/Cut/Paste/Hatena
タイトルが何を言っているのかよくわからないと思いますので順を追って紹介したいと思います。 tblsをセットアップするGitHub Actionとしてsetup-tbls を作った setup-tblsはtblsをインストールしてくれるGitHub Actionです。 github.com 各所で「ないの？」とは言われており（最近Issueもたった）、いつか作らないとなと思っていたのですが、いろいろ重なって作りました。 github.com 私はGoで作ったツールのActionはDocker container actionを使うのですが、tblsでそうするとDockerコンテナ上で動くtblsからデータベースサーバの名前解決ができなかったりして、それも手を鈍らせている原因でした。 今回作成した setup-tbls はComposite actionで作っているので上記のような心配もありま
GitHub Copilot のセキュリティ・ライセンスに関する懸念の調査メモ
GitHub Copilot を業務で利用するとなると、以下の 2 つの懸念がある。 自社のプライベートなコードが GitHub Copilot に送信され、学習モデルとして使われ、外部に流出してしまわないか 自動生成されたコードが学習モデルとなった public なコードのライセンスを侵害してしまわないか 1 については、コードの一部なら大きな問題にはならないと思われるが、もし一時的にエディタに貼っていたクレデンシャルが送信されて外部流出してしまう可能性があるのであればリスクが低いとは言いづらい。 2 については、ライセンスを侵害すること自体がリスクである。それに加えて、GitHub Copilot がよそのライセンスを侵害する可能性があることがあとから発覚した場合、それまでに GitHub Copilot を使って書かれたコードすべてを精査しなくてはいけなくなる可能性があるのもリスクと
コードレビュー時のコメントの意図を明確にする
コードレビューあるあるなんですけど、レビューする時に「これってなんでこうしてるんですか？」みたいなピュアなコメントを書いてしまうと、その意図がレビュイーに伝わらなくて、「詰められてる」「コードに疑念を持たれている」「修正依頼をされている」「純粋に質問されている」という解釈のブレを生んでしまって物事が円滑にいかないみたいなことは発生します。 コメントする側からするとただ単に質問しているだけなのにどうして・・・と思いがちなのですが、コードレビューに慣れていない人はこういう重要度や意図がはっきりしないコメントをたくさん書いてレビュイーを困惑させがちというのはあるんじゃないでしょうか。 重要度や意図がはっきりしないコメントを書くのが常になってしまうと、GitHubでPRを出してレビューをしてもらってマージするという開発者が何度も何度も回していくワークフローに滞りが発生してしまう、もしくはそれどころ
積極的な技術選定と消極的な技術選定 - uhyo/blog
この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される（あるいはされない）技術そのものが原因となる意思決定です。 一方、消極
“テックリードという役割”のその後 — Will Larson “Staff Engineer”
この本は大きく前半と後半にわかれていて、著者によるStaff Engineerの職務内容・昇進・会社選びなどに触れた前半、”Stories”と章立てされたStripe・Slack・FastlyといったTech企業で働く14人のインタビューを掲載した後半の構成になっています。私は前半を読みおえ、後半のインタビューを2人目まで読んだ状態です。 本書にかかれているスタッフエンジニアの職務内容や求められるものは良い意味で私のイメージしていものとは違いました。 これまで私が想像していたのは「所属する組織が使うOSSにコントリビュートして技術的な優位性を保る」「社内のツールを開発して組織全体の生産性を上げる」のような一言で言えば凄腕のエンジニアでした。 しかし、本書で紹介されるスタッフクラス以上の職務を自分なりにまとめると「チーム間・全社的な技術面でのマネジメントを行い、経営上のゴール達成に貢献する」
Create Secure Clients and Servers in Golang Using HTTPS
Overview The purpose of this article is to show how to write secure web services and clients using Go and HTTPS. In researching how to accomplish this I came across numerous articles and gists. However, none of them provided the complete picture I needed to implement a robust client or server. Most of them only provided terse code examples with equally terse examples regarding how to create the ce
リレーションとリレーションシップの誤用に注意 - 設計者の発言
RDBやデータモデリングに関する説明の中で「リレーションシップ」と言うべきところで「リレーション」と表現する誤用が目立つ。どうでもいいような違いに思われるかもしれないが、これらは明確に区別されるべきだ。そうでないと、RDBの用語の意味がわからなくなるからだ。 IBMのフェローであったE.F.コッド(1923-2003)による1970年のの歴史的論文 "A Relational Model of Data for Large Shared Data Banks" （大規模共有データバンク向けデータのリレーショナル・モデル。杉本さんによる対訳）によって、世界で初めてRDBの理論的枠組みが示された。この論文で使われている用語"relation"が、RDB（relational database)の呼称の由来である。 relationとは何か。その論文でコッド博士は、１個のテーブルに格納された行(
セキュリティエンジニアのためのKubectlプラグイン トップ15
本文の内容は、2023年1月17日にNIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/top-15-kubectl-plugins-for-security-engineers/)を元に日本語に翻訳・再構成した内容となっております。 誰にとっても、特にセキュリティエンジニアにとって非常に有用であると強く感じるこのKubectlプラグインのリストを、さらに掘り下げてみましょう。 Kubernetesは、設計上、信じられないほどカスタマイズが可能です。Kubernetesは、特定のユースケースシナリオのためのカスタム構成をサポートしています。そのため、基本的な機能にパッチを適用する必要がありません。プラグインは、Kubernetesの機能を拡張し、アウトオブボックスの提供を実現する手段です。 Kubernetesプラグインとは何ですか？ Kubern
生JSONを扱うのにちょっと便利な json.RawMessage と観測した実例 - Software engineering from east direction
TL;DR 生JSONを扱う際に、標準のjsonパッケージでは、 RawMessage という型が用意されている JSON構造の文字列を取り出して、なんらか整形して出力、といったユースケースにちょっと便利 json.RawMessage 生JSONを扱う際に、標準のjsonパッケージでは、 RawMessage という型が用意されている。 // RawMessage is a raw encoded JSON value. // It implements Marshaler and Unmarshaler and can // be used to delay JSON decoding or precompute a JSON encoding. type RawMessage []byte godoc.org RawMessage is a raw encoded JSON valu
Goでサーバを立ち上げてE2Eテストを実施するCI用のテストコードを書く - My External Storage
GoでCIで動かせるE2Eテストコードを書くための下調べをしたのでメモしておく。 TL;DR CIで動かせるE2Eテストとして、ListenAndServeしているサーバに対してHTTP通信するテストコードを書きたくなった。 ListenAndServeは通信の開始待ちができないので、Flakyなテストになってしまう。 net.Listenして取得したnet.Listenerを使うことで、待機無しでテスト対象のサーバと通信できる。 CIで実行できるE2EレベルのテストをGoのテストコードとして書きたい 柴田さんや@t_wadaさんの話を読んで、もっとE2Eテストに近いHTTPテストについてちゃんと考えたいなと思い始めた。 マイクロサービスの開発とテストファースト/テスト駆動開発 | GDG Dev Fest Tokyo 2019 https://www.slideshare.net/yos
WasmでJavaScriptを動かす意義 - id:anatooのブログ
ある時Twitterのタイムラインを見ていたら、「JavaScriptをWasm化して動かす意味がわからない」というような意見を見かけました。JavaScriptはブラウザに搭載されているV8のようなJavaScriptエンジンによって高速に動作するので、わざわざWasm化してもパフォーマンスは劣化するのになぜなのか?という話なんですが、これは「Wasm化=パフォーマンスのため」という考えだと意義がわからないのでこの記事ではそれについて解説します。 JavaScriptをWasm化して動かすツールやライブラリとしては、Shopifyが開発しているJavyやquickjs-emscriptenなどがあります。JavaScriptをWasm化して動かすためには、ある特定のJavaScriptエンジンをWasm向けにビルドして動かす必要がありますが、そのような用途ではQuickJSというJava
素のRailsは十分に豊かである（翻訳）｜TechRacho by BPS株式会社
はじめに 「Railsは関心の分離が不十分である」という批判をよく目にします。状況が深刻になったら、Railsに足りない別のピースを導入しなければならないというのです。しかし私たちはそうは思いません。 「素のRails（vanilla Rails1）ではここまでしかできない」みたいな批判を耳にすることがよくあります。Railsはアーキテクチャレベルで関心の分離が不十分なのだから、アプリはいずれメンテナンス不能になり、足りないピースを導入するという別のアプローチが必要になるというのです。 代表的なDDD（ドメイン駆動開発）書籍では、概念上の4つの層である「プレゼンテーション層」「アプリケーション層」「ドメイン層」「インフラストラクチャ層」について議論しています。 アプリケーション層は、ドメイン層と協調動作してビジネスタスクを実装します。しかし、Railsが提供しているのは「コントローラ」と「
GitHub Actions上でgit commitするときにgit userをどうするか - Qiita
GitHub Actions上で変更をコミットしたい GitHub Actions上で変更をコミットしたいケースがある。例えばGitHub Actions上でlintを実行して修正を自動反映したいケース。 このときgit configコマンドでどのユーザのcommitにするか指定する必要がある。 実際にはどのユーザを指定すればよいか。 ユーザの設定方法 GitHub Actions上で git config user.email <メールアドレス> を実行する。 GitHubではgit userのメールアドレスでユーザ識別されるので、GitHubユーザで登録したメールアドレスと一致していればよい。 on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - run: | date > g
GUIデザインのヘヴィネス、あるいはデザイナーとエンジニアの性質にみるソフトウェア開発の難しさについて｜itoh4126｜note
GUIデザインのヘヴィネス、あるいはデザイナーとエンジニアの性質にみるソフトウェア開発の難しさについて 現代におけるソフトウェアやアプリケーションの開発では分業化が当たり前になっている。たぶんスケーラビリティなどが背景にありつつ、「良い感じのものをどう作るか」以上に「良い感じの組織をどう作るか」の観点が前景化してきたのだと思う。 そして、もはや大多数が疑うことすらなく参加しているこの分業体制を前提に、しばしばデザイナーとエンジニア（脚注1）の協業や連携の難しさが取り沙汰されるような印象だ。 現代では協業をなめらかにするべく設計された様々なソフトウェアが活用されているのに、この職種間における協業の難しさや課題感については、各所で目に入る記事などの感じだと「コミュニケーションで解決しました」といった対処療法こそ見かけるものの、全体として上手くいっているような印象はあまり受けない。 なぜそうなっ
言語化する力を使って、俯瞰した自分をいたわることの話 - インターネットの備忘録
考えを言語化する力の大切さ この数年、リモートワークが加速し他人とのコミュニケーションがオンライン化するにつれ、自分の考えていることを分かりやすく伝わるよう言葉にする技術の大切さが増してきているように感じます。 会話がチャットベースになったことで曖昧な相談や気持ちも明文化する必要が増えたり、ちょっとした言葉の足りなさで相手とのコミュニケーションが行き違ってしまう経験が何度かありました。 そうなってくると、自分の考えていることをきちんと言語化して相手に伝わる言葉にしていくというのは、ある程度意識して磨かなくてはいけない技術なんじゃないかなと思っています。 言語化する技術というのは、ちょっとしたノウハウはあるものの、基本的には自分が考えていることを言葉にする、言葉にしたものが相手に伝わりやすいものになっているかを点検する、分かりにくければ修正してまた点検する、その繰り返しをしていくことでしか磨
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rust の嬉しさをより多くの日本語話者に知ってもらうためには、スタンフォードで強く敷かれている educational benefit の概念を Rust コミュニティが抱くことが大事なのではないか、という私見
[Developers Summit 2023] ソフトウェアテスト新時代の幕開け: 機械学習とデータサイエンスで実現するテスト運用の高度化![[Developers Summit 2023] ソフトウェアテスト新時代の幕開け: 機械学習とデータサイエンスで実現するテスト運用の高度化](https://cdn-ak-scissors.b.st-hatena.com/image/square/0efe72a56b9d43a41e40530a646876ce37b6a9d5/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F2037a09e17cf4398ab0006d4fcfea1f9%2Fslide_0.jpg%3F24408296)
kdmsnr - iki-iki
「DeepL Write」が登場 ～翻訳ではなく、より正確・自然な文章提案に特化したAI／Webブラウザーさえあれば誰でも無料で利用可能
なぜ変化を起こすのが難しいのか？ - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
