検索条件

から
検索タグ 開発
タグで絞り込み Node.js(24) Node.js::Jest(20) Node.js::SWC(4) Node.js::webpack(1) Node.js::その他(1) OS(2) OS::Android(1) OS::Windows(2) サービス(8) サービス::AWS(1) サービス::GitHub(7) サービス::GitHub::GitHub Actions(6) サービス::Slack(1) ジャンル(6) ジャンル::トラブルシューティング(1) ジャンル::名前(1) ジャンル::疑問(1) ジャンル::調査(3) ソフトウェア(6) ソフトウェア::Docker(1) ソフトウェア::Git(1) ソフトウェア::VisualStudio(1) ソフトウェア::その他(3) ライブラリ(10) ライブラリ::Next.js(2) ライブラリ::React(9) 言語(24) 言語::C#(2) 言語::JavaScript(5) 言語::JavaScript::CommonJS(3) 言語::JavaScript::ES Module(2) 言語::PowerShell(1) 言語::TypeScript(18) 言語::batファイル(1) 開発::その他(1) 開発::テスト(24) 開発::自動化(12) 開発::設計(7)
日付で絞り込み 2020年(1) 2021年(14) 2022年(7) 2023年(15) 2024年(5)
全42件 (3/9ページ) 一覧表示に切り替え

お知らせ

現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。

Android Studioを導入してHello World

投稿日：
ソフトウェア::その他開発::その他OS::WindowsOS::Android

なんとなくアプリを作りたくなったので。Hello worldするとこまで。

確認環境

Env Ver
Windows 11 Pro 22H2
Intel VT-x 有効
Hyper V 有効

手順

  1. 公式サイトからインストーラーを落としてくる
  2. NextとAgree連打でインストールする
  3. Empty Activityを選ぶ
    1. 作成するプロジェクトはEmpty Activityを選ぶ
  4. Tools→Device Managerでデバイスがなんか入ってるのを確認する
    1. Tools→Device Managerでデバイスがなんか入ってるのを確認する
  5. 再生ボタンみたいなやつを押す
    1. 再生ボタンみたいなやつを押す
  6. しばらくするとエミュレーターが起動するのでドロワー中央のAndroidアプリを起動
    1. ブランクのアプリみたいなアイコンをタップ
  7. 画面が出てくればOK
    1. Hello worldが表示される
コメント（0件）

JenkinsのGroovy ScriptでlookupCredentialsを使って指定したCredentialsを取得するメモ

投稿日：
開発::自動化ソフトウェア::その他

Groovy Scriptの読み方が分からなかったので読み解き方のメモ。全て憶測

確認環境

Env Ver
Jenkins 2.249.1
Groovy Script 不明

サンプルコード

def credentials = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(
    org.jenkinsci.plugins.plaincredentials.StringCredentials.class,
    jenkins.model.Jenkins.instance.getItemByFullName("ここにフォルダパス")
)

def cred = credentials.findResult { it.id == "ここに取得したいやつのCredentials ID" ? it : null }

読み解き方

個人的な解釈なので特に根拠はない。全て憶測。

lookupCredentialsの部分

端的に言うとデータ型とストア名のようなものを指定し、認証情報を取得する機能であると思われる。Groovy Script的にはCollectionが返ってくる。

findResultの部分

コメント（0件）

JavaScriptのundefined判定の処理速度比較

投稿日：
言語::JavaScriptジャンル::調査開発::設計Node.js

undefinedの判定方法が複数あるということでundefined判定の処理速度比較をしてみたのでその結果。

端的に言うと、hoge === undefinedとtypeof hoge === 'undefined'の二方式がある。後者は原則考慮不要だが、言語仕様上存在しているので比較したが、現実的に見た場合、どちらで記述した場合でも処理速度に有意な差はないように感じた。

確認環境

Env Ver
Node.js 20.1.0
TypeScript 4.9.5
@swc/core 1.3.8

比較結果

hoge === undefinedの方が早く見えるが実行するタイミングで変わるので誤差の範疇だと思う。

方式 ms
hoge === undefined 4,514
typeof hoge === 'undefined' 4,515

確認コード

const tyof = (param?: string) => {
  return typeof param === 'undefined';
};

const undef = (param?: string) => {
  return param === undefined;
};

const tyStart = +new Date();
for (let i = 0; i < 10000000000; i++) {
  tyof();
}
console.log('typeof', +new Date() - tyStart);

const unStart = +new Date();
for (let i = 0; i < 10000000000; i++) {
  undef();
}
console.log('undefined', +new Date() - unStart);

TSから生成されたJS

"use strict";
Object.defineProperty(exports, "__esModule", {
    value: true
});
const tyof = (param)=>{
    return typeof param === 'undefined';
};
const undef = (param)=>{
    return param === undefined;
};
const tyStart = +new Date();
for(let i = 0; i < 10000000000; i++){
    tyof();
}
console.log('typeof', +new Date() - tyStart);
const unStart = +new Date();
for(let i = 0; i < 10000000000; i++){
    undef();
}
console.log('undefined', +new Date() - unStart);

あとがき

MDNを読む限りtypeof hoge === 'undefined'は該当変数が存在しない場合に有用なようであるが、TypeScriptで書いている場合、通常このようなコードが生まれることがなく、仮に起きるとした場合、次のようなコードになるため現実的に考慮する必要はない。なおMDNにも「こんなことはしないこと」と書いてあるので、一般的なコードでないことは客観的にも伺えるだろう。

(() => {
  const undefined = 123;
  const hoge = undefined;

  if (typeof hoge === 'undefined') {
    console.log('hoge is undefined');
  } else {
    console.log('hoge is not undefined');
  }
})();

上記コードの実行結果としてはhoge is not undefinedが出力される。

このコードの主な問題点

  1. const undefined = 123;というコードは予約語を変数名にしているため、混乱を招くコードであり、書かないことが好ましい
    1. MDNには予約語ではないとあるが、一般的には予約語の一つとして解釈して支障ないと考える
  2. このコードはESLintのeslint:recommendedで検知されるため、通常であれば書かれることはない
    1. no-shadow-restricted-namesに引っかかる

なお、このコードは例示のために即時実行関数形式で記述しているが、必要がない限りこの形式での実装は避けたほうが問題が少なくなると思う。これは不必要なネストが生まれたり、スコープの混乱を生むためである。

コメント（0件）

Huskyって本当に必要ですか？

投稿日：
Node.jsジャンル::疑問ソフトウェア::その他開発::自動化

HuskyとはNode.jsを利用した開発で非常によく使われているGit hooksのユーティリティだが、個人的にはこのツールの存在価値に疑問を感じている。

という訳で、この記事ではHuskyのメリデメを考えた結果と、Huskyが何をしているか、Huskyの必要性について書いてゆく。

Huskyがあるメリット

Huskyは極めて有名なツールであるため、Huskyが入っているとこのプロジェクトはGit hooksで管理されており、標準化されていることが確認できるだろう。恐らくHuskyのメリットはこれ以外に存在しないと考えている。

Huskyがあるデメリット

Huskyの管理をしないといけない、Huskyも地味にアップデートするからだ。これは明確なコストである。

そしてHuskyのコードやリポジトリを見たことがある人は多分ほとんどいないと思う。更に言えばHuskyが何をしているかすらも知らない人だっているはずだ。そんな得体の知れないものを使うのは怖いというところだ。

Huskyは何をしているか？

端的に言えばGit hooksのパスを .husky/ に設定しているだけである。
要するに git config core.hooksPath .husky を叩いているだけだ。
もう少し細かく言えば以下に相当する処理を実行している。

mkdir -p .husky/_
cp husky.sh .husky/_
git config core.hooksPath .husky

勿論、ソースコードには他の処理も書かれているのだが、実質的には上記三行が全てと言って良い。

husky.sh を活用しているケースがどれほどあるか怪しいことを考えると、本質は git config core.hooksPath .husky だと思うので、正直あるだけ邪魔では？と考えている。

Huskyの必要性

ここまででHuskyがしていることは git config core.hooksPath .husky だということが解ったが、だとしたらHuskyは本当に必要なのだろうか？私は特に理由がないのであれば package.json で husky install と書いてあるところに git config core.hooksPath .githooks とでも書いておけば良いのではないか？と思っている。恐らく何も不都合はないはずだ。

ただ世の中には色々な事情があり、使わざるを得ないケースもあると思う。しかし、可能であれば排除してもいいのではないか？個人的にはそう思っている。

何故この記事を書いたか

「この世からHuskyを滅ぼすため」というのはまぁ冗談だが、個人的にHuskyの存在価値があまり良くわかっておらず、多分世間の人もあまり理解できていないと勝手に考えていて、可能であればプロジェクトに入れたくないと考えているので、そのお気持ち表明というか、そんな感じだ。

ここからは余談だが、Huskyには結構な数のスポンサーが付いていて、恐らく毎月それなりの収入があると思われる。以下はHuskyのスポンサーである。

Huskyのスポンサー

個人的にHuskyは最も成功したOSSの一つではないかと考えている。理由としてHusky自体は非常に単純なプロダクトであり、コミット履歴を見てもさしたるメンテナンスがされておらず、ほぼ手放しで維持されていると思われるからだ。

しかし、Huskyはそれなりの額の寄付を集めており、この記事を書いた時点で確認できるだけでも最低 10USD * (4 + 16) + 100USD * (4 + 2) の寄付がされており、つまり800USD、日本円にして11.2万円ほどだ。何もしてないのに毎月この収入があるのは大分ありがたいだろう。他のOSSならIssueやPull Requestsに対して対応したり、コード本体のメンテナンスがあるはずだが、Huskyにそんなものはないため、プロダクトの維持コストに対して非常によく寄付を集められていると感じる。

コメント（0件）

Jestのメモリリークを解消する

投稿日：
Node.js::SWCNode.js::Jestジャンル::トラブルシューティング開発::テスト

TypeScript + SWCと組み合わせてJestを回してるとテストケースの増加に伴いメモリリークが発生する現象が起きます。メモリに余裕があれば問題にはならないですが、開発機のメモリが足りないとかCIで使ってるECSのメモリが足りないとか、引っかかるケースもあると思います。

今回はこの問題に対する対処法を書いていきます。完全には改善されませんが、かなりマシになります。参考までに今回の検証では283MB使ってたのが67MBまで減りました。

この現象はNode.js 16.11.0以降で発生するらしいので、それ以前の環境では起きないかもしれません。

確認環境

Node.js v20.0.0

module version
@swc/cli 0.1.62
@swc/core 1.3.59
@swc/jest 0.2.26
@types/jest 29.5.1
@types/node 20.2.3
jest 29.5.0
jest-watch-typeahead 2.2.2
typescript 5.0.4

確認用のテストコード

以下のテストコードを書いたファイルを100ファイル作り、それを流して確認しています。

describe('example1', () => {
  it('1', () => {
    expect(1).toBe(1);
  });
  it('2', () => {
    expect(2).toBe(2);
  });
  it('3', () => {
    expect(3).toBe(3);
  });
  it('4', () => {
    expect(4).toBe(4);
  });
  it('5', () => {
    expect(5).toBe(5);
  });
});

describe('example2', () => {
  it('1', () => {
    expect(1).toBe(1);
  });
  it('2', () => {
    expect(2).toBe(2);
  });
  it('3', () => {
    expect(3).toBe(3);
  });
  it('4', () => {
    expect(4).toBe(4);
  });
  it('5', () => {
    expect(5).toBe(5);
  });
});

確認環境一式

以下のリポジトリに確認したソースコードを一式格納しています。

[blogcard https://github.com/Lycolia/jest-memory-leak-example]

メモリリークしていく様子

(41 MB heap size)
(42 MB heap size)
(52 MB heap size)
(51 MB heap size)
(37 MB heap size)
(47 MB heap size)
(47 MB heap size)
(50 MB heap size)
(60 MB heap size)
(60 MB heap size)
(62 MB heap size)
(71 MB heap size)
(73 MB heap size)
(74 MB heap size)
(84 MB heap size)
(85 MB heap size)
(86 MB heap size)
(96 MB heap size)
(97 MB heap size)
(99 MB heap size)
(108 MB heap size)
(110 MB heap size)
(111 MB heap size)
(120 MB heap size)
(122 MB heap size)
(124 MB heap size)
(75 MB heap size)
(83 MB heap size)
(84 MB heap size)
(86 MB heap size)
(96 MB heap size)
(96 MB heap size)
(97 MB heap size)
(107 MB heap size)
(108 MB heap size)
(109 MB heap size)
(118 MB heap size)
(120 MB heap size)
(121 MB heap size)
(130 MB heap size)
(132 MB heap size)
(133 MB heap size)
(143 MB heap size)
(144 MB heap size)
(145 MB heap size)
(154 MB heap size)
(156 MB heap size)
(157 MB heap size)
(166 MB heap size)
(168 MB heap size)
(169 MB heap size)
(179 MB heap size)
(181 MB heap size)
(182 MB heap size)
(191 MB heap size)
(193 MB heap size)
(194 MB heap size)
(203 MB heap size)
(205 MB heap size)
(207 MB heap size)
(216 MB heap size)
(217 MB heap size)
(219 MB heap size)
(228 MB heap size)
(230 MB heap size)
(231 MB heap size)
(240 MB heap size)
(242 MB heap size)
(243 MB heap size)
(252 MB heap size)
(254 MB heap size)
(255 MB heap size)
(264 MB heap size)
(266 MB heap size)
(267 MB heap size)
(277 MB heap size)
(278 MB heap size)
(280 MB heap size)
(195 MB heap size)
(204 MB heap size)
(203 MB heap size)
(212 MB heap size)
(213 MB heap size)
(214 MB heap size)
(223 MB heap size)
(224 MB heap size)
(226 MB heap size)
(235 MB heap size)
(237 MB heap size)
(238 MB heap size)
(247 MB heap size)
(249 MB heap size)
(250 MB heap size)
(259 MB heap size)
(261 MB heap size)
(262 MB heap size)
(271 MB heap size)
(273 MB heap size)
(274 MB heap size)
(283 MB heap size)

Test Suites: 100 passed, 100 total
Tests:       1000 passed, 1000 total
Snapshots:   0 total
Time:        11.347 s, estimated 12 s

解消方法

npm i -D @side/jest-runtime などで@side/jest-runtimeを導入し、jest.config.jsに以下の行を追加することで改善します。

  runtime: '@side/jest-runtime',

このコードで何か既存の実装やテストに影響が発生するかどうかは確認していませんが、後述する@side/jest-runtimeが生まれる切欠になったPRの様子を見る限り大丈夫なんじゃないかなとなんとなく思っています。

メモリリークが改善したあとの様子

(39 MB heap size)
(39 MB heap size)
(47 MB heap size)
(47 MB heap size)
(34 MB heap size)
(42 MB heap size)
(41 MB heap size)
(49 MB heap size)
(51 MB heap size)
(59 MB heap size)
(59 MB heap size)
(60 MB heap size)
(68 MB heap size)
(69 MB heap size)
(77 MB heap size)
(77 MB heap size)
(85 MB heap size)
(86 MB heap size)
(95 MB heap size)
(95 MB heap size)
(95 MB heap size)
(103 MB heap size)
(104 MB heap size)
(112 MB heap size)
(112 MB heap size)
(120 MB heap size)
(121 MB heap size)
(31 MB heap size)
(38 MB heap size)
(37 MB heap size)
(44 MB heap size)
(46 MB heap size)
(54 MB heap size)
(54 MB heap size)
(54 MB heap size)
(62 MB heap size)
(62 MB heap size)
(70 MB heap size)
(71 MB heap size)
(79 MB heap size)
(79 MB heap size)
(87 MB heap size)
(88 MB heap size)
(96 MB heap size)
(96 MB heap size)
(97 MB heap size)
(105 MB heap size)
(105 MB heap size)
(31 MB heap size)
(39 MB heap size)
(37 MB heap size)
(44 MB heap size)
(46 MB heap size)
(54 MB heap size)
(54 MB heap size)
(54 MB heap size)
(62 MB heap size)
(62 MB heap size)
(70 MB heap size)
(70 MB heap size)
(78 MB heap size)
(79 MB heap size)
(87 MB heap size)
(88 MB heap size)
(96 MB heap size)
(96 MB heap size)
(96 MB heap size)
(104 MB heap size)
(105 MB heap size)
(31 MB heap size)
(39 MB heap size)
(37 MB heap size)
(45 MB heap size)
(46 MB heap size)
(54 MB heap size)
(54 MB heap size)
(54 MB heap size)
(62 MB heap size)
(63 MB heap size)
(70 MB heap size)
(71 MB heap size)
(78 MB heap size)
(79 MB heap size)
(87 MB heap size)
(88 MB heap size)
(96 MB heap size)
(96 MB heap size)
(97 MB heap size)
(105 MB heap size)
(105 MB heap size)
(30 MB heap size)
(37 MB heap size)
(45 MB heap size)
(43 MB heap size)
(44 MB heap size)
(51 MB heap size)
(51 MB heap size)
(59 MB heap size)
(59 MB heap size)
(67 MB heap size)

Test Suites: 100 passed, 100 total
Tests:       1000 passed, 1000 total
Snapshots:   0 total
Time:        9.071 s, estimated 11 s

参考記事

メモリリークバグに関するIssue
https://github.com/jestjs/jest/issues/11956

@side/jest-runtimeが出来る元になったPR
https://github.com/jestjs/jest/pull/12205

コメント（0件）