投稿者「teruo」のアーカイブ

プレゼン動画作りのメモ

Windows 10 の場合

  • PDF またはパワポをフルスクリーン表示して、Xbox Game Gear のキャプチャ機能で録画
    • 途中で噛んだりしても後で編集すればいいので続けて取った方が結果早い
  • Windows フォトや Adobe Premiere Pro などでトリミング&編集
  • 書き出した後、HandBrake などで再エンコードして容量削減
    • CPU でエンコードしたほうがファイルサイズは小さくなる

Adobe Premiere Pro の使い方

  • アセンブリ > メディアブラウザー から素材となるメディア(動画)を 右クリック > 読み込み
  • プロジェクト:○○ からメディアを タイムライン にドラッグして配置
  • エフェクト > オーディオエフェクト > ノイズリダクション / レストレーション から クロマノイズ除去リバーブを除去 を各メディアに適用
  • トリミングするときは、レーザーツール を使ってメディアを分割し、リップル削除 で削除と同時にタイムラインを左詰め
  • 動画の書き出しは、アセンブリ で編集済みの項目を選択した状態で ファイル > 書き出し > メディア
    • 設定は現状よくわかっていないので、H.264 でハードウェアエンコードできる設定を使用。

便利なショートカット

  • 再生、順方向加減速:L
  • 停止:K
  • 逆再生、逆方向加減速:J
  • カーソル位置でレーザーツール(編集点の追加):Ctrl + K
  • クリップ選択、移動:Ctrl + ↑ or Ctrl + ↓
  • リップル削除:Shift + Delete

参考資料

Petalinux v2018.3 をインストールするときのメモ

  • Ubuntu の場合は 16.04
  • sudo apt-get install -y gcc git make net-tools libncurses5-dev tftpd zlib1g-dev libssl-dev flex bison libselinux1 gnupg wget diffstat chrpath socat xterm autoconf libtool tar unzip texinfo zlib1g-dev gcc-multilib build-essential libsdl1.2-dev libglib2.0-dev zlib1g:i386 screen pax gzip
  • 上記だけではダメで、sudo apt-get install gawk が必要

食器洗い乾燥機を自力で設置した記録

目次

  • 必要なものの調査
  • 棚の設置
  • 分岐水栓の取り付け
  • 食器洗い乾燥機の設置

必要なものの調査

まず、購入する食器洗い乾燥機はパナソニックの NP-TA2 にすることにした。約4万5千円。

これを設置する場所をキッチンの中で探したが、そのままでは置くことができない。そこで台をキッチンに設置し、その上に乗せることにした。必要な面積はおおよそ 55 cm × 35 cm なので、アイリスオーヤマのメタルラックを利用するのが良さそう、という結論に。ちょうどよいサイズの棚板を扱っている。これに 15 cm のポールを2本取り付け、残りの2本分はキッチンの台に乗せることにした。このポールは高さを微調節することができ、水平をとるのも容易だった。平らな方が食洗機を載せやすいので硬質クリアシートを合わせて購入。棚板1枚で使うので若干強度面の不安を感じたのでサイドバーを買っておいたがこれは不要だったかもしれない。約3千円。

続いて、食洗器を水道につなぐための部品として分岐水栓が必要。我が家では TKGG31E という TOTO の蛇口が取り付けられていたので、これに合う部品をパナソニックのサイトから検索。すると CB-SSH8 という部品が適合することが分かったので、これを購入。約1万円。これを取り付けるには 2.5 mm の六角レンチとサイズの違う2つのスパナが必要。

棚の設置

棚は事前にキッチン周りの寸法を良く図っておいたおかげでかなり狙い通りになった。電源ケーブルと給水ホースを通す隙間も取れてよかったと思う。

分岐水栓の取り付け

中に説明書が入っているので、その通りにすればよい。栓を出す向きは360度自由に決めることができるようになっている(実はこれがかなり不安だった)。

水の栓を止めてから作業しないといけないが、今回は量水器ボックスの栓を締めて行った。

普通に作業するだけなら10分くらいでできると思うが、作業中にレンチが足りないことが分かって買いに走ったので少し時間がかかった。

食器洗い乾燥機の設置

重いという点を除けば特に苦労することはなかった。

給水ホース、排水ホースをそれぞれ接続し、電源を取ってアースをとるだけ。

アースは残念ながら冷蔵庫と食器棚で埋もれてしまっていたので、ドキドキしながらもシンクに接続しておいた。何かあった時は自己責任・・・。ただ、食洗器自体を台の上に載せているのと、台所マットを利用している点、一応シンクにアースを接続していることを考えると、感電リスクはそれほど高くはないと判断している。

設置を依頼したらかなり費用が掛かっていたと思うので、自力でできたのは良かったと思っている。 なにより妻が喜んでいるので良かった。 賃貸なので、退去するときに水栓を戻さないといけないのが億劫だけど。

KCU1500 環境のセットアップ方法のメモ

KCU1500 は近々 discon になると思うので今更書き残しておく意味があるかよくわからないが・・・。

  • Ubuntu を使う場合は 16.04 LTS を使う。
    • KCU1500 用のドライバが対応した Linux カーネルを動かせるのが 16.04 LTS までだから。
    • 最新の PC を使おうとすると、Ethernet ドライバがなくてはじめインターネットにつながらないかもしれない。その場合は手動でドライバをインストールする必要がある。
  • HWE には対応していないので、4.4 系のカーネルにする。
    • KCU1500 用のドライバが対応した Linux カーネルのバージョン制約
  • SDAccel は 2018.2 をインストールする

この組み合わせじゃないといけないことに気づくまでに結構試行錯誤が必要だった。

ここまでできると、あとはインストラクション通りにドライバをインストールできる。ドライバが入ると KCU1500 のファン制御が有効になって静かになる。

PYNQ ならではなスタートアッププログラムを止める方法

PYNQ  はスタートアップ時に Jupyter Notebook が起動するように設定されている。

それを止めるためには、以下のサービスを systemctl を使って止めればよい。

  • pl_server
  • pynq-x11
  • jupyter

グラフィカルなログインを止めるには、

$ sudo systemctl set-default multi-user.target

Ultra96v2 で PYNQ イメージを動かす

Ultra96v2 で PYNQ の Linux イメージを動かすまでのメモ。

WiFi のアクセスポイントに接続するようにあらかじめ設定を変更しておく。

手順

  1. PYNQ イメージをダウンロード
  2. イメージを microSD に書き込み
  3. WiFi 接続設定
  4. 起動確認

1.PYNQ イメージをダウンロード

http://avnet.me/ultra96-pynq-image-v2.4_v2 からダウンロードする。
結構時間かかる上に、チェックサムが公開されていないのでデータが壊れていないか確認できない。

2.イメージを microSD に書き込み

SD カードが /dev/sdb だったとして、

# dd bs=4M if=/path/to/ultra96v2_v2.4.img of=/dev/sdb

とする。RootFS のパーティションが小さいので、SDカードの容量に余裕があれば、パーティションを拡張後、resize2fs してファイルシステムの容量を拡張しておくとよい。

3.WiFi 接続設定

確認したところ、 Ubuntu 18.04 ベースなので、本来なら、network-manager をインストールして netplan を使って WiFi 接続設定するのだけど、インストールされていないので、別の方法で設定する。

まず、SDカードの第2パーティションを /path/to/mountpoint にマウントする。

/path/to/mountpoint/etc/wpa_supplicant.conf 作成

country=JP
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
    ssid="<SSID名>"
    psk="<パスフレーズ>"
}

(パスフレーズを平文で書きたくない人は別途調べるとやり方が出てくる。)

/path/to/mountpoint/etc/network/interfaces.d/wlan0 編集、wlan0 が自動で UP されるよう以下の内容にする

auto wlan0
iface wlan0 inet dhcp
    wireless_mode managed
    wireless_essid any
    wpa-driver wext
    wpa-conf /etc/wpa_supplicant.conf

4.起動確認

電源と、microSD、micro-USB ケーブルを接続する。

PYNQ サイトには、micro-USB ケーブルで接続すると Ethernet デバイスが認識されて、192.168.3.1 でアクセスできると書いてあるがこれはどうもうまくいかなかった。

その代わり、シリアルデバイスとしては認識されてターミナルソフトからアクセスできる。

$ ip a して wlan0 が接続できていればOK。

http://<wlan0 の IP アドレス> にブラウザでアクセスすれば Jupyter Notebook の画面が見られるはず。ちなみにパスワードは xilinx

また、この IP アドレスに SSH でもアクセスできるはず。ユーザとパスワードはともに xilinx

参考サイト

  • PYNQ 公式サイト:http://www.pynq.io/board.html
  • ドキュメント:https://ultra96-pynq.readthedocs.io/en/latest/getting_started.html#opening-a-usb-serial-terminal

mdadm + LVM の RAID1 をディスク交換して容量を増やす

概要

3 TB HDD × 2 で構築していた RAID1 を 8 TB HDD × 2 に交換した記録。

前提と作業内容

今回は、/dev/sdb1 と /dev/sdc1 の2パーティションで RAID1 (/dev/md0) を構成している前提。
ファイルシステムは XFS を使用。

手順としては、RAID 再構築 → RAID 拡張 → LVM 拡張 → ファイルシステム拡張の4ステップ。

8 TB のドライブの使い方として、 3 TB + 5 TB に分けて2つの RAID1 を作成して LVM でまとめることもできるけど、今回は 8 TB の大きなアレイを作成することにした。

手順

1.ディスク交換

1-1.1本目のディスクを故障状態にして RAID から外す

# mdadm /dev/md0 --fail /dev/sdb1
# mdadm /dev/md0 --remove /dev/sdb1
# shutdown -h now

1-2.物理的に1本目のディスクを交換

1-3.1本目のディスクのパーティション作成

今回は 8TB 全体を使う1のパーティション (/dev/sdb1) を作った。
パーティションのタイプは Linux RAID (29) を指定する。

# fdisk /dev/sdb

1-4.1本目の同期

3 TB 領域を同期する。大体5時間かかった。

# mdadm /dev/md0 --add /dev/sdb1

1-5.2本目のディスクを故障状態にして RAID から外す

# mdadm /dev/md0 --fail /dev/sdc1
# mdadm /dev/md0 --remove /dev/sdc1
# shutdown -h now

1-6.物理的に2本目のディスクを交換

1-7.2本目のディスクのパーティション作成

# fdisk /dev/sdc

1-8.2本目の同期

# mdadm /dev/md0 --add /dev/sdc1

2.RAID 領域の拡張

このままだと前の容量の 3 TB しか使えないので、RAID 領域を拡張する。
残りの 5 TB 分の同期に8時間ほどかかった。
RAID1 なので、 --assume-clean しても良かったと思うけど、今回は同期しておいた。

# mdadm --grow /dev/md0 -z max

3.LVM の拡張

Physical Volume の拡張

# pvresize /dev/md0

LV に設定する PE 数の確認(Total PE)

# pvdisplay

LV の拡張

# lvextend -l [PE数] [LV path]

4.ファイルシステムの拡張

# xfs_growfs [マウントポイント]

論文執筆を GitHub + 継続的インテグレーションで環境レス化する

概要

LaTeX での論文を Git で管理し、GitHub と継続的インテグレーション (CI) ツール を使って論文を pdf 化し、GitHub の Release ページから見られるようにすることで論文執筆を効率化する話(ただし、論文執筆速度が速くなっているかは別の話)。

これが実現したらもはや手元の環境には LaTeX 処理系はなくても論文執筆が可能なので、タイトルに「環境レス化」を入れた。手元に全く環境を持たないのは難しいとしても、複数の LaTeX 処理系を使い分けたりは格段にしやすくなる。

GitHub を使った論文執筆

論文を Git リポジトリで管理して、GitHub を用いて共著者間で共有している。主な活用法としては以下のような感じ。

  • 研究テーマ単位でリポジトリを作る。論文は papers/xxx みたいにディレクトリを掘って配置
  • Issue 機能を使って執筆上の課題を明確化し、共著者間の議論の場を作る
  • 議論に対応したコミットを Issue に結び付けることで議論が論文にどう反映されたか明確化
  • 査読対応にも Issue 機能を活用

動機

ところが、共著者の中には論文を読んでチェックできればいい、という人がいる。そういう人にとっては、わざわざ論文 pull してコンパイルする作業が面倒だったりする。.latexmkrc を書いて latexmk main するだけにしても「pdf ファイルをメールで送ってください」となるのがオチだった。

ならば、GitHub に push したら CI で自動 pdf 化できるようにしたらいいのかな、と思ってやってみた。幸い、参考になるサイト(下記)があったので、大いに参考にした。

前提

  • LaTeX 文書のコンパイルには TeXLive 環境を使う。
  • LaTeX 文書のコンパイル支援には latexmk を使用、コンパイル手順は .latexmkrc に記述し、リポジトリに含む
  • 論文のコンパイル対象は main.tex とする。
  • 一つのリポジトリに複数の論文が含まれる。papers/xxx など、ディレクトリを掘って格納する
  • CI ツールには CircleCI を使用。論文のコンパイル(pdf化)を行う。どのディレクトリをコンパイルするかは CircleCI の設定で決定

現在のところ、CircleCI は無料で月間 1000 分ジョブを実行できる。LaTeX 文書の量によるが一度に必要な時間は2分程度。したがって、CircleCI を他の用途に使っていなければ月に 500 回くらいは論文をコンパイルできる計算になる。個人的な感覚としては十分な計算時間が利用できると思う。

目標とする動作

以下のような動作を目指す。特に、自動で pdf 化された論文が Release ページに登録されるのは使い勝手が良いと思う。これができるようになれば、手元の LaTeX 環境をセットアップしなくてもクラウド論文執筆が可能。(ただし、変更をリポジトリに push してからコンパイル結果が出力されるまでに2分かかる、ほとんどは Docker 環境の立ち上げに要する時間。)

  • GitHub に論文の更新を push したときにコンパイルが通るかチェック
  • GitHub に X.X.X 形式で tag を設定または更新したときに pdf ファイルを GitHub の Release としてアップロード

CircleCI の設定

今回は、CircleCI 2.0 を使う。必要な手順は以下の3つ。

GitHub リポジトリへの CircleCI 用設定ファイルの配置

CircleCI 2.0 では、.circleci/config.yml に YAML 形式の設定を記述する。以下の例は、 build, publish-github-release の2つのジョブからなっている。また、tag に応じた処理を行うために main ワークフローを設定している。このテストは teruo41/latex-circleci-test に置いてある。

version: 2

executors:
  my-executor:
    working_directory: /root

jobs:
  build:
    docker:
      - image: teruo41/ubuntu-texlive:latest
    steps:
      - checkout
      - run:
          command: |
            cd papers/${TARGET_DIR}
            latexmk main
      - persist_to_workspace:
          root: /root
          paths:
            - project
  publish-github-release:
    docker:
      - image: cibuilds/github:0.10
    steps:
      - attach_workspace:
          at: /root
      - run:
          name: "Publish Release on GitHub"
          command: |
            cd /root/project/papers/${TARGET_DIR}
            ghr -t ${GITHUB_TOKEN} -u ${CIRCLE_PROJECT_USERNAME} -r ${CIRCLE_PROJECT_REPONAME} -c ${CIRCLE_SHA1} -delete ${CIRCLE_TAG} main.pdf

workflows:
  version: 2
  main:
    jobs:
      - build:
          filters:
            tags:
              only: /^\d+\.\d+\.\d+$/
      - publish-github-release:
          requires:
            - build
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /^\d+\.\d+\.\d+$/

build ジョブ内で papers/${TARGET_DIR} ディレクトリに移動して latexmk main を実行する。TeXLive を利用するための Docker イメージは Docker Hub の teruo41/ubuntu-texlive:latest を利用。Docker イメージについては後述。

publish-github-release ジョブはコンパイルした pdf ファイルを GitHub の Release ページに登録するためのジョブ。これには、cibuilds/github:0.10 の Docker イメージを利用。
複数のジョブ間で実行結果を受け渡すには、先行ジョブ(ここでは build)で persistent_to_workspace を指定する必要があり、後続ジョブ(ここでは publish-github-release)で attach_workspace を指定する必要がある。

main ワークフローは、X.X.X 形式のタグが GitHub 上で更新されたときに buildpublish-github-release ジョブを実行する。これにより、tag に対応した pdf ファイルが GitHub の Release ページにアップロードされる。

Circle CI 用 Docker イメージの準備

動かせればよい人は、teruo41/ubuntu-texlive:latest の使用を推奨。これは、Ubuntu リポジトリに登録されている TeXLive をインストール済みの Docker イメージ。Ubuntu がサポートしているバージョンのそれぞれについてイメージを作る(予定)。

自前で環境を作りたい人は、Dockerfile を作って手元で docker build して Docker hub に push するか、GitHub か BitBucket に Dockerfile を格納したリポジトリを作って、Docker hub 上で Automated build するかどちらかで作ることができる。ちなみに、この例で使っているイメージは Automated build で作成している。それに使用している GitHub リポジトリは teruo41/ubuntu-texlive

Circle CI 上での設定

以下の設定をする必要がある。

  • Circle CI のアカウントを作成して GitHub アカウントに接続する
  • Circle CI の環境変数を設定する。例の .circleci/config.yml で必要な変数は、 GITHUB_TOKENTARGET_DIR の2つ。

GITHUB_TOKEN は GitHub の Personal Access Token を設定する。リポジトリの Release ページに書き込むためには GitHub から適切な権限設定が必要。Public リポジトリか Private リポジトリかで必要な権限が変わる。詳しくはここを参照。

TARGET_DIR はコンパイルする論文のディレクトリを設定。papers/${TARGET_DIR} ディレクトリに移動した後 latexmk main が実行される。

テスト

ここまで設定したら使える状態のはず。論文のリポジトリを更新して push したらコンパイル可否がコミットページに表示される。また、tag を設定して push すれば、コンパイル結果の pdf ファイルが GitHub の Release ページに追加される。

tag を設定して GitHub に push する git コマンドの例。branch と同様に tag も push できる。

$ git tag -a 0.0.1 -m "Created tag 0.0.0"
$ git push origin 0.0.1

一度設定した tag を更新するためには、-f オプションを使えばOK。

$ git tag -af 0.0.1 -m "Updated tag 0.0.0"
$ git push -f origin 0.0.1

参考

HP ProLiant MicroServer gen7 Remote Access Card の KVM に Java SE 8 からつなぐ

少し前から接続できなくなって困っていたけど、今日解決方法を発見した。

733 不明なデバイスさん2018/05/05(土) 21:07:06.67ID:7Er95jKL >>734
>>729 
jre1.8.0_171\lib\security\java.securityのjdk.tls.disabledAlgorithmsから3DES_EDE_CBCを削除したらつながったよ。 
力技だけど…

https://mevius.5ch.net/test/read.cgi/hard/1468533309/733

試したところ、見事解決した。

Windows 10 の eSIM を使ったモバイル通信プラン、便利そうだけど使うまでが難しい

今持ち歩き用の PC として Surface Pro LTE Advanced を使っている。
事務作業には十分なスペックと軽さ・薄さで満足度は高い。

このモデルは、nanoSIM が挿さるのと、eSIM が内蔵されていて、モバイル通信プランを購入することで世界各地でモバイルネットワークに接続可能。

nanoSIM スロットには国内で使える年間契約の SIM を挿していて、海外渡航時に eSIM に切り替え、Ubigi などの通信プランを購入して使う、というのが便利そう。
ポケット WiFi 持ち歩かなくていいって素晴らしい。

ところがどっこい、eSIM を使うのが結構難儀だった。

eSIM でモバイル通信プランを購入する画面までたどり着けない。
eSIM には、「eSIM プロファイル」と「APN」を設定する必要がある。その両方が適切に設定されていないと圏外表示になり、何もできない。

自分の場合、デフォルトの「eSIM プロファイル」と「APN」は機能しなかったみたいで、Ubigi の問い合わせから eSIM プロファイルをダウンロードする方法を教えてもらい、さらに「APN」を設定するための情報を教えてもらって初めて圏外から脱することができた。

自分の場合、nanoSIM の設定の時もそうだったが、eSIM でも APN 設定するときに、「インターネットとアタッチ」を選ぶ必要があった。

ろくな説明をしなかったのに、適切な作業手順を提示してくれた Ubigi のサポートは素晴らしい。
(一方 Microsoft のサポート情報の役に立たなさよ・・・)

その後、さらに一つ重要なポイントとして、自分の環境では、2つの SIM を切り替える際、「詳細オプション」の「APNを添付する」から利用したい APN の「編集」を一度選択し、そのまま「保存」する必要がある。
これをしないと、アンテナピクトは立つが接続されない。

モバイルネットワークに PC 単体で接続できるのはとても便利なだけに、利用方法が難しかったり、うまくいかないときの対処法がわかりづらいのはもったいないなと思う。