ozawaのブログ

本ブログは、PC関連について投稿します

Windows10でサインインが異常に遅くなる問題の備忘録

はじめに

本件は備忘録として残します。

事象

windows10でサインインがある時から以上に遅くなり、5分以上かかるようになりました。

原因

色々原因を探ると、C:\Users\<USER>\AppData\Local\Tempフォルダー配下が100GB近い容量に膨れ上がっていました。
どうやら、Windows10はTempフォルダーが肥大化するとサインインが遅くなる仕様のようです。

そのTempフォルダーを調べると、DismHost.exeという謎のアプリケーションを含んだUUIDのようなランダムなフォルダーが大量に存在しました。

根本原因

下記のサイトがヒントになりました。

memo.kuraba.com

このDismHost.exeというアプリケーションはSilentCleanupと呼ばれるwindowsの一時ファイルを削除するタスクスケジューラによって作成されるようです。
タスクスケジューラのログを見ると私の場合は失敗していたので、もしかしたら、このSilentCleanupが失敗して一時ファイルが削除されずに蓄積され続けたと考えています。

解決方法

まず、サインインの遅延の原因となっているC:\Users\<USER>\AppData\Local\Temp配下のデータを全て削除しました。
これで、私の場合はサインイン遅延は解消されて、5分以上かかっていたサインインは30秒程度になりました。

次に、一時フォルダーを圧迫していたSilentCleanupを無効化しました。
これでTempフォルダーの容量の肥大化は軽減出来ると考えています。

webpackからviteに移行した際の備忘録

はじめに

webpackが開発終了をしてNext.jsのturbopackに開発チームが移ったそうで、
AWS Lambdaのnode16のサポート期限期限短縮でnode18へのランタイムのバージョンアップ対応を機にviteへの移行を検討始めました。

vitejs.dev

turbopackではなくviteに移行をするのは、turbopackはNext.jsがメインで他のフレームワークだったり汎用的に使えそうな仕様ではまだ無かったためです。
コミュニティによればturbopackは将来的に汎用的に使えるようになるようですが、
現時点ではwebpackの移行先として、turbopack vs viteのような比較がされるような対抗馬的な存在のviteが勢いがあるので採用しました 。

Turbopack We are in active discussions with other frameworks to bring Turbopack to their users. We're excited to see what we can build together!

turbo.build

webpackからviteへの移行時の問題点

大きな問題点ですと私の場合は下記がありました

  1. viteのビルド設定
  2. viteのデフォルトがesbuildでreflect-metadataを利用するライブラリ群が使えない

1. viteのビルド設定

webpackではいくつかのプラグインが世に出ていて、
例えばgulpとの連携プラグインだったりがありましたが、viteは2021年からβリリースされた比較的新しいのでそのあたりがまだ整っていません。 gulpのビルド/デプロイ周りを書き直すのが面倒だったので、webpackプラグインのビルド部分を削除して単純にシェルコマンドでvite buildを叩くような形で暫定対応しました。
個人的にはvite + gulpのプラグインは余裕があれば作りたいなとは思っていたりしますね。

あとは、lambdaは複数の関数ファイルを出力する形式にするところで詰まったり、
バンドルする際に特定のライブラリは動的インポートをするようにする設定だったりを探すのにドキュメント類が少ないので困りましたが、
下記のオプションでやれます。

  • build.rollupOptions.external
    • ここに指定したライブラリは動的インポート対象になりバンドルされないので別途node_moduleもデプロイが必要です。
  • build.rollupOptions.input
    • 複数のエントリーポイントでファイルを出力する際に利用。これはwebpackでも同じような感じですね
  • build.rollupOptions.output.chunkFileNames
    • ここでエントリーポイントから呼び出すviteでビルドして分割されたファイルを呼び出すファイル名を適当に記載

viteはrollupと呼ばれるバンドラーを利用しているようです。

rollupjs.org

2. viteのデフォルトがesbuildでreflect-metadataを利用するライブラリ群が使えない

この記事の本題で一番考えたところです。
viteではデフォルトでesbuildを利用していて、このesbuildがemitDecoratorMetadataのオプションをサポートしていません。
そのため、emitDecoratorMetadataを利用するreflect-metadataやそれを利用する各種ライブラリ群(TSyringeやTypeorm..etc)などは型情報を参照出来ない?のでビルドエラーになります。

これに対する対応策として下記の2つがとりあえずありました。

  1. esbuildに対してemitDecoratorMetadataを有効化するプラグインを利用
  2. esbuildを止めてviteのビルドをswcを利用して行う

諸々検討した結果ですが私は「2.」の方法を採用しました。
viteのswcを利用するプラグインも一応あってvite-plugin-react-swcというモノもありますが、
reactを利用していなかったのでunplugin-swcを参考に自前でviteでswcビルドをするプラグインを書きました。
unplugin-swcのそのまま使わなかったのは2022年からメンテがされておらず、私の環境では動かなかったからです。

github.com github.com

色々な設定がこのunplugin-swcにかかれていますが、
とりあえずビルドに必要そうなのは下記の部分です。(記憶を頼りに抜粋しているので動作確認はしていないです)

// unplugin自体はRollupのプラグインのユティリティ? or インターフェース? の漠然としたイメージで私はいます   

export default createUnplugin(
  (option : any = {}) => {

    const filter = createFilter(
      include || /\.[jt]sx?$/,
      exclude || /node_modules/,
    )
    return {
      name: 'swc',
     // resolveIdはいらなそう
          async transform(code, id) {
        if (!filter(id)) return null

        // swcのビルド設定
        let jsc: JscConfig = {
          parser: {
            syntax: 'typescript',
            decorators: true,
            legacyDecorator: true,
            decoratorMetadata: true
          },
          transform: {},
        };
        
        /// ... 省略
       
        const result = await transform(code, {
          filename: id,
          sourceMaps: true,
          ...options,
          jsc,
        })
        return {
          code: result.code,
          map: result.map && JSON.parse(result.map),
        }
     },

     vite: {
        config() {
          return {
            // これでesbuild無効
            esbuild: false,
          }
        },
      },

});


あとは、書いたプラグインをvite.configのbuild.rollupOptions.pluginsで指定すれば良いです。

おわりに

とりあえずviteに移行しました。
十秒程度、webpackよりもビルド時間が短縮された気がします。 webpack + typescript + ESMのセットでAlias解決がうまく出来ずに自前のwebpackプラグインを書いた時よりも、 vite移行は比較的楽に対応出来たなと思っています。

今はNode16 -> Node18になることでメンテが数年以上されていないライブラリがopensslの互換性エラーに苦しんでいて、
オプションの--openssl-legacy-providerで暫定対応は出来ますが、今後を考えて自前で書かないといけないかな〜と考えています。

以上です、ありがとうございました。

Macの入力キーボード設定でGUIからでは削除が出来ないUnicode Hex Inputを削除する方法

ハマったので備忘録として残します。

com.apple.HIToolbox.plistを編集

~/Library/Preferencesのcom.apple.HIToolbox.plistにキーボード設定が記載されているので編集します。 とりあえずバックアップを作成しましょう。

% cp ~/Library/Preferences/com.apple.HIToolbox.plist ~/Library/Preferences/com.apple.HIToolbox.plist.bk

そしたらcom.apple.HIToolbox.plistをPlistBuddyで開きます。 PlistBuddyの使い方はググってQiitaとか参照。

/usr/libexec/PlistBuddy com.apple.HIToolbox.plist

com.apple.HIToolbox.plistの下記の項目を編集します。

AppleCurrentKeyboardLayoutInputSourceID = com.apple.keylayout.UnicodeHexInput AppleEnabledInputSources > KeyboardLayout Name = Unicode Hex Input AppleInputSourceHistory > KeyboardLayout Name = Unicode Hex Input

Command: print AppleEnabledInputSources:{KeyboardLayout Name = Unicode Hex Inputがある番号}  // printで確認しながら編集すると安全だと思います。 

Command:  delete AppleEnabledInputSources:{KeyboardLayout Name = Unicode Hex Inputがある番号}
Command:  delete AppleInputSourceHistory:{KeyboardLayout Name = Unicode Hex Inputがある番号}
Command: set AppleCurrentKeyboardLayoutInputSourceID com.apple.keylayout.US
Command: save
Command: exit

反映には再起動が必要です。 ログアウトではキャッシュが残っている影響なのか、com.apple.HIToolbox.plistがロールバックされます。

以上


更新

上記の対応をした後に入力ソースを何かしら編集して保存しないと、ログイン画面の入力ソースが反映されません。 私は一度、キーボード設定の入力ソースの一つを削除して、再度追加をして保存をして再起動したら正常にログイン画面の入力ソースも更新されました。

Win10をgrubでブート

始めに

久ぶりの更新です。
今回の内容はGrubを使ってwin10をブートさせます。

毎回、設定するたびにやり方をいろいろググるのが面倒になったので、手順のメモを残します。

手順

目標は、LinuxGrubからWin10のブートができるようにします。
前提として、今回はLinuxWindowsがインストールされているHDDは別であるとします。(デュアルブートでもいけると思いますが)
また、今回はCentosです。

まず初めに、lsblkでブートローダが入っているパーティションを確認します。

% lsblk

f:id:d-ozawa940:20170701040256j:plain

上記の場合だと、sda/sda2にブートローダが入ってます。

自分の場合は、Win10のブートローダが入ってるのは100MBのパーティーションでした。
そして、次のように/etc/grub.d/40_customを編集します。

$ sudo vim /etc/grub.d/40_custom


menuentry "Win10" {
set root=(hd0,2)
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

ここで注意なのが(hd0,2)の部分で、最初の0がデバイス番号を表し、次の2がパーティションを表していて、デバイスはsda, sdb..が0, 1, ….となるのに対して、パーティションはsda1, sda2, …が1, 2, ….となっています。

編集した後は下記のコマンドを打ち、grub.cfgと呼ばれるgrubの設定を更新します。
この時、ディストリビューションやブートの仕方によって場所が違うので要確認。

# Centosの場合
% grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

# UEFIモードの場合
% grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg

# 上記以外  
% grub-mkconfig -o /boot/grub/grub.cfg  

最後に再起動して、確認する。

Seasar2 + eclipseの設定

はじめに

どうも、今回の内容はSeasar2であるSAStruts(Super Agile Struts)という割と古めのフレームワークの導入です。
SAStrutsJavaのWebフレームワークの一つで、Strutsの拡張です。
なんで、Springじゃないの?とかあると思いますが、使う機会があったためメモ代わりに残しておきます。

目標は、eclipseSAStrutsフレームワークのプロジェクトを新規作成できるようにすること。

下記のサイトを参考にしました。

The Seasar Project(公式)
Java + Tomcat + Eclipse + Seasar2 + MySQL 環境構築手順 まとめ(Javaっと。)

導入手順

本環境はArch Linuxです

基本的にSeasar2のプロジェクトを新規作成するために用いるDoltengというプラグインを利用します。
まずは、eclipse、jdk7のインストールです。

pacman -S eclise-java  
pacman -S jdk7-openjdk  

ここで、なぜjdk8ではないかと言うと、Doltengというプラグインがjdk8だと正常動作しないためです。
jdk8の場合は、"Project Facet Setting"の項目がNone以外選択できず、空のプロジェクトが作成されます。 jdk8を使いたい場合は、一度、jdk7でDoltengを用いてプロジェクトを新規作成してから、若干の設定が必要みたいです。

Seasar2でJava8対応した時の流れ(Qitta)

↓JDK8

f:id:d-ozawa940:20170517231506p:plain

↓JDK7

f:id:d-ozawa940:20170517231649p:plain

さて、次に下記のeclipse プラグインをインストールします。

始めに、SAStrutsPluginを入れるために、"Web, XML, Java EE and OSGi Enterprise Development"を入れる
これは、Help>Install New Softwareを開き、Work withの右のプルダウンをクリック、その中に、"All Available Sites"ある選択すると表示されるのでインストールをする

次に、Help>Install New Software>Add…を開き下記を入力する

Name: Seasar2(適当)  
Location: http://eclipse.seasar.org/updates/3.3/  

その後、DoltengKijimuna、SAStrutsPluginにチェックを入れてインストールする

あとは、下記のように"Project Facet Setting"をすることでSAStrutsフレームワークを新規作成することができる

f:id:d-ozawa940:20170517235515p:plain

まとめ

jdkのバージョンでプロジェクトを作るプラグインが使えないので、そこだけ注意

word2vecを利用したツイート解析

久々の更新です
今回の内容は、自分が研究したことです

分野は言語処理でツイートの解析を行いました
目標は、文章分類で、この文章はどのような属性を持っていかを分類します

ぶっちゃけ、研究し終わってから結構時間たっていたり、そもそも理論を勘違いしていたり、割と適当に書いているので、あらかじめご了承ください

 理論

主に単語の分散表現を利用します
単語の分散表現とは、単語の意味をn次元のベクトルで表現するもので、ある規模のテキストデータがあれば下記のような意味演算が可能になります。

王-男+女=妃

f:id:d-ozawa940:20170407234856p:plain

さて、ここで本研究ではword2vecを利用しました
word2vecは、テキストデータを与えると、n次元のベクトル空間上に類似した単語を近くに配置していく特徴があります

f:id:d-ozawa940:20170407235142p:plain

この近くに配置する作業では、分布仮説という同じ文脈上では同じ意味の単語が出現することを利用して、ある単語の前後n字の単語に対して、近くになるように配置していきます

単語の分散表現をある程度のデータ量で作れば単語の意味関係を表すことができる
ここに着目して次のようなことを考えました

ベースラインとなる単語の分散表現から、ある属性の文章を加えて再配置させると、単語の意味の変化に関する何か有用な特徴が得られるのではないだろうか?

例えば、下記のようなイメージです

ベースラインとなる分散表現: U(ある程度、単語の意味関係が正確になっているもの)
10代が書いたテキストデータで、Uを再配置したもの: U10
20代 〃 : U20
30代 〃 : U30
40代 〃 : U40

とする

そして、この各々の属性のテキストデータで再配置したものをベースラインで引くことで、ベースラインからの変化量が得られる
U10 - U = X10
U20 - U = X20
U30 - U = X30
U40 - U = X40

X10~X40は、各々の属性に関して何かの特徴になっていると考えられる
このX10~X40機械学習を利用することで、何らかの特徴を学習して、文章を与えることで属性分類ができたらな、というのが研究する前に自分が思いついたことでした


と、気力が尽きたのでここまでにします
結果は、男女合わせて2000件のデータを10-fold交差検証したところ、属性平均F値が男女平均して0.92ぐらいです。
また、性別ほど綺麗なデータが取れなくて、ノイズを含む年代では4クラスで0.58なので実用性があるのかは自分では判別できませんでした

f:id:d-ozawa940:20170408000512p:plain

以下の画像は、試験的に分類したものの例でテストデータと学習データの半分に分けて分類した結果です
分類結果は、性別、年代、現住所で一時的によかったものです(交差検証をしていないので評価には使えないが….)

f:id:d-ozawa940:20170407235705p:plain f:id:d-ozawa940:20170408000639p:plain f:id:d-ozawa940:20170408000850p:plain

最後に

自分にとってこの研究の始まりはビッグデータ解析をしたい!!という思いで始めました
しかし、容易に取得できるツイートデータを分析しているうちに自然言語処理の面白さに触れられたと思います
研究した自分としては、単語の分散表現を利用した属性分類は、言葉遣いに違いが現れるような属性のテキスト分類に有効だと信じたい..(自分的には悪くない手法だと思います)

もし、時間に余裕があって、実験ソースが残っていたらアップでもしようかな

ということで、以上となります

Dockerの容量を上げるときのメモ

はじめに

どうもこんにちは。
今回の内容は、「Dockerの容量をあげる時について」です。

この内容を記事にする理由は、久々にDockerの容量を上げることがあり、色々ハマったため手順をまとめることにしたためです

ちなみに作業環境はArch linuxで、Systemdを使っているためコマンド等の違いがあるので注意。

あと、色々な設定等についてはここを参照してください。
Docker ドキュメント日本語化プロジェクト

手順

作業の前に、現在のイメージファイル等は作業中に削除されてしまうため、docker saveでファイルにしておきます。

% docker save 保存するイメージファイル名 >> 保存する時のファイル名

まず、稼働中のdocker.serviceを停止させます。
その後に、それまで使っていたイメージファイル等が入っているディレクトリを削除します。(デフォルトでは/var/lib/docker)
この作業でイメージファイルや起動中のコンテナなどが消えるので注意が必要。

% sudo systemctl stop docker.service  
% sudo rm -R /var/lib/docker  

その後で、/etc/systemd/systemにdocker.service.dがなければ作成します。
systemctl editを使うと編集画面になり、編集後は自動でdocker.service.dと編集したファイルがその中に保存されます。

% sudo systemctl edit docker.service

自分は以下のように編集しました。
dm.basesizeが起動中のコンテナの容量の上限です。
また、自分はDockerのイメージファイル等が入るディレクトリの場所を変更しました。

#/etc/systemd/system/docker.service.d/test.conf

[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -g /home/docker --storage-opt dm.basesize=50G

ここで、空の"ExecStart="を書かないとエラーになるので注意。
編集後は、/etc/systemd/system/docker.service.d/[変更後のファイル名].confがあるか確認をして、daemon-reloadをします。
その後で、docker.serviceを起動して、容量が増えているか確認。

% sudo systemctl daemon-reload
$ sudo systemctl start docker.service
$ sudo docker info

以上で容量を上げることができました。