Windows11(Pro以上だけ?)ではBitLockerがデフォルトで有効になっている. この状態でLinuxをインストールするために一度Secure Bootをオフにすると｢Secure Bootがオフにされた!!! デバイスを保護しなくちゃ!!!｣と言って再度Windows11を起動しようとしても暗号化を解除しないとログイン出来ない状態になる. これはSecureBootを再度オンにしても同様で大変めんどくさい.
VSCode上でJestでテストを書こうとしたらtestが見つかりません, @types/jestを入れろみたいに怒られた.
// package.json
"devDependencies": {
"@types/jest": "^29.5.10",
"jest": "^29.7.0",
"ts-jest": "^29.1.1",
"ts-node": "^10.9.1",
"typescript": "^5.3.2"
}
Jestに必要なものは一通り入っている.
詳細はよくわからん
jest.config.tsのtestMatchのコメントを外す.
それでダメなら同様にjest.config.tsのrootsのコメントも外して, テストスクリプトが保存されたディレクトリを指定する.
tsconfig.jsonを触る必要はなさそう.
農地ナビからせっせと落としてきたGeoJSON(140ファイル以上)をちまちまArcGISに入れるのはしんどいということでマージしたくなった. 調べてみるとこんなのがあるらしい.
早速入れてみたものの, こんな感じに怒られてマージ出来ない.
SyntaxError: Unexpected token in JSON at position 0
at JSON.parse (<anonymous>)
at /mnt/c/Users/sioremon/Documents/UTM/project/nouchi_pin/merge/node_modules/@mapbox/geojson-merge/geojson-merge:19:19
at Array.map (<anonymous>)
at Object.<anonymous> (/mnt/c/Users/sioremon/Documents/UTM/project/nouchi_pin/merge/node_modules/@mapbox/geojson-merge/geojson-merge:18:52)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
at internal/main/run_main_module.js:17:47
農地ナビから取得したGeoJSONはUTF-8 with BOMだった.
./node_modules/.bin/geojson-mergeの中身はこうなっている.
#!/usr/bin/env node
var geojsonMerge = require('./'),
stream = geojsonMerge.mergeFeatureCollectionStream,
merge = geojsonMerge.merge,
fs = require('fs'),
argv = require('minimist')(process.argv.slice(2));
if (!argv._.length || argv.help) {
console.log('usage: geojson-merge [-s] FILE FILE2 FILE3');
console.log('\n --stream (or -s): use streaming mode for large files');
return;
}
if (argv.s || argv.stream) {
stream(argv._).pipe(process.stdout)
} else {
process.stdout.write(JSON.stringify(merge(argv._.map(function(n) {
return JSON.parse(fs.readFileSync(n));
})), null, 2));
}
18行目でJSON.parseしているが, ただ読んでいるだけなのでBOM付きだと読めなかったという話.
自分はWSLでnodeを動かしていたのでnkfでBOMをまとめて消した
nkf --overwrite --oc=UTF-8 dir/*.geojson
WSLじゃなくてもBOM 消し方とかでググるといい感じのやり方が出てくると思う, 知らんけど
単なるつぶやきです.
それはそれは大昔に受けたことはあったが, それ以来受けていなかったコーディングテストセカンドDT君ワイ, 晴れて(?)ご卒業と相成りました.
某社の就活イベント参加のために受けたんですが, AtCoderでやってたやつと違う!!! 標準入力じゃないやつ知らん!!! となりパニクってしまった.
結局そのままテストボタンをﾎﾟﾁｰとすれば良かっただけだったんですが, それを理解するのに30分かけてしまい解き切ることができなかった.
標準入力だとかコマンドライン引数だとか気にせず, そのまま実行すれば関数が引数を受け取ってくれる, というパターンを知らなかったので勉強になりました.
2週間ほど前から下書きで温めていたやつです. 糞深夜に書いたが為, 非常に雑ですが校正が面倒なのでそのまま出します
ThunderbirdでSMTPの設定しようとしたらハマった
日本語だと メッセージは送信されましたがコピーは送信済みフォルダ（送信済みトレイ）に保存されませんでした。ネットワークエラーまたはファイルアクセスエラーが原因です。
英語だと zoho Your message was sent but a copy was not placed in your sent folder (送信済みメール) due to network or file access errors.
こういうやつ
症状はリモートの送信済みボックスには保存されるし, 配送も正しく行われるのに, Thunderbird側の(アカウント内の)送信済みメールに保存されないというやつ. (Local Foldersには手動で保存可能)
Zohoの
にアクセスして, smtpのコピーを作るみたいなやつにチェック
Thunderbirdは｢メッセージ送信時に自動的にコピーを作る｣をアンチェックする.
研究室のネットワークを構築したり, 所属プロジェクトのDXを頑張ったりと色々やってるんですがある程度知見が溜まってきたのでちょっと書いてみる.
非テック系の学生にMarkdownを覚えさせたり, ツール導入と同時にプロジェクト活動のフローを変更したり, 僕のプチDX経験を書いてみた記事. 誰かの参考になれば嬉しいです.
生物多様性とか個体群動態とか生物を扱う人が多い研究室に所属している.
みんなパソコンはある程度触れる, だけど設定とかは全然わからん, 怖い, って感じの人がほとんど.
今回は特に, 所属プロジェクトのDXについて書く.
イノシシの個体群動態とか, 獣害対策とかを扱っている.
週1回のZoomミーティングでタスクの進捗確認や仕事の割り振り, スケジュール調整等をやっている.
予算はほとんどなく, ツールに金を割く余裕はない. 所属人数は(アクティブメンバーで)7人程度.
ぱちょこん得意です, みたいな人間は僕一人, という感じ.
各々がローカルで作業しているせいで進捗状況が見えない, 情報が分散する, やっていることとツールの相性が悪く必要な情報にたどり着けない or たどり着くまでに時間がかかる, それぞれドキュメントのフォーマットが違いすぎて困る, 等々問題が山積していた.
確実に必要なのはこの4つだった. 順番に説明する.
ミーティングの度に議事録を取っていたものの, 毎週書記が気分で変わる&各々好きなサービスで書き散らしていたために情報が分散していた.
これをまず集約しよう, ということで当初は僕のHackMDアカウント上にドキュメントを作ってみんなで編集するスタイルにしていた.
ただ, 僕がミーティングを欠席したりしたら議事録が歯抜けになる, 僕以外の人達の検索性が悪すぎるという問題があった為, 本格的なWikiサービスを探した.
その結果候補に上がったのが以下の3つ(だった気がする).
- esa.io
- scrapbox.io
- CodiMD
検討の結果, 以下の理由でesa.ioを採用した.
- アカデミックプランがあり, 無料でフル機能が使える.
- HackMDで全員がMarkdownにそれなりに慣れていた.
- CodiMDは構築がめんどくさい&研究室インフラの障害が怖い
他にも色々あるとは思うが, 何より無料なのが決め手だった.
｢非テック系の人にMarkdownが受け入れられるの?｣という疑問が上がると思うが, 普通にWordやExcelが使える人達ならおそらく問題はない.
｢Markdownとは?｣から, syntaxまで丁寧に説明すれば案外すんなり理解してくれる. ただテーブルとかは拒否反応を示されがち(僕も好きではない)なので, 最初教えるのは以下の3つに絞る.
ある程度, みんなが慣れてきたら以下の3つを発展編として教える.
とりあえずリストと見出し, コードさえ覚えれば, 議事録, 研究計画書のドラフト程度の用途ではまったく問題ない.
WYSIWYG的なツールでは往々にして構造化されていないドキュメントが生成されがちで, 後で見返すと訳がわからなくなることがよくある.
｢このsyntaxは, 最低限構造化されたドキュメントを手軽に書くためのものだ｣的な感じで教えると, 案外みんな納得して使ってくれる.
最後にesaの仕様を理解してもらう必要があった.
esaはファイルパスを書くようなイメージでカテゴリ分けを行う. うちはmacユーザが多いので｢Finderでフォルダの中のフォルダを探すときみたいな, アノ感じだよ〜｣と言って徐々に理解してもらった.
議事録をはじめ, ドキュメントの確認にかかるコストが大幅に下がった. 同時編集が出来るので, 資料の提出期日前にはみんなでesaに集まって作業する, といったことが出来るようになった.
質問をURLで返すことが出来るまで情報を充実させることが, Wiki導入におけるゴールだと思っている. なにかにつけて情報を残す文化や雰囲気の醸成までやれたらいいね, というお気持ち.
ほとんどのコミュニケーションはLINEグループ上で行っていたが, LINEだと共有したファイルの保存期間がすぐに来てしまって後々参照出来ない問題が多発していた.
また, あらゆる話題が一つのチャット内に集約されるので, 過去の会話を探すだけでも一苦労, という感じで非常に体験が悪かった.
ビジネスチャットといえば, という感じで順当にSlackを導入したわけだが, 普段LINEのようなUIに慣れている人達的にSlackは使いにくいらしく, 最初は全くもって浸透しなかった.
LINEを使う弊害, Slackのメリット(チャンネルや外部アプリとの連携等)を説明し, プロジェクト活動に関わるコミュニケーションはSlack上で行うように全員にお願いした.
ただ, こうしてしまうと今度は｢Slackはミーティングのときにしか見ない｣という事態になってしまい(理由はSlackが使いにくいから, らしい), 活動が滞ってしまった.
｢通知をONにしよう｣｢Slackは怖くない(?)｣｢返信は出来る限りスレッドで｣ということをまたまた口酸っぱく言うことで, やっとSlackをコミュニケーションのベースにする体制が出来てきた.
後述するが, GitHubやesaとの連携なんかも集約出来ていて, 結果としてLINEからの移行は正解だったと感じている.
しばらくの間は, 議事録に次週までのタスクを書き出す運用をしていたが, 後々タスクを確認する時に数週間分の議事録を参照する必要があり非常に体験が悪かった.
また, 他のメンバーのタスクの進捗状況を一目で把握することが出来ず, 効率が悪かった.
このような理由から, チケット型のタスク管理をしようと思い, 以下の2つを候補に挙げた.
Redmineは存在は知っているものの, 僕自身あまり馴染みがなかった為GitHubに決定. GitHubのUIに多少抵抗された感もあったが, 使い方とどのような運用をしたいのか, 事細かに説明したところそれなりに納得してもらえたようだった.
単にGitHubを導入しても, どうせ使ってもらえないと思ったので, まずはSlackに新規issueとissueに対するコメントの更新通知を飛ばすようにした.
こうすることで, issueに進捗を書き込むと自動でSlackから通知が来るので進捗状況が見えるようになった.
誰かが進捗を生めば, それに続いて, という感じで進捗を生むペースが早くなったように感じるし, 自分がやったことをすぐ他に人に伝えることが出来る, というのも作業のモチベーションになっているかもしれない.
期日が差し迫っても進んでいなければ, 気づいた人間がアサイニーのケツを叩いてやることも出来るようになった.
各タスクの進捗を全員で確認する為に, 毎回のミーティングで15分ほどissuesを頭から最後まで舐める時間を取ることにした. 今のところ, メンバーの反応も悪くない感じ.
元々プロジェクト全体で一つのGoogle Driveを共有していた. もちろんパスワードも共有していて, 大変気持ち悪かった.
また, 誰かが卒業したり, プロジェクトを履修しなくなったりした時にパスワードを変更する, と言ったオペレーションもされていなかった為, 非常に良くない状況だった.
容量も無料版なので小さく, 動画や静止画などストレージを消費しそうなファイルはローカルに置いておく必要があった.
幸い, 大学がGoogle Workspaceを契約してくれていたので, そこで共有ドライブを作り, プロジェクト関連のデータをそっちに全部移行した. 容量無制限, ユーザ管理が可能, というあたりがとても助かっている.
どこの大学も, SharePointやBox等何かしらのオンラインストレージは持っているはずなのでそれを使うのがいいと思う.
esaの更新通知もSlackに飛ばしている. 共同で書いてるドキュメントの校正だったり確認がすぐ出来るので結構助かっている. 全部をSlackに集約した結果, プロジェクトの進捗が逐一確認しやすくなったのが一番美味しかったポイントだと思う.
やはりメンバーからはそこそこ抵抗されたりする. 単純にめんどくさいのもあるだろうし, ｢複雑化しそう｣｢ツールが増えすぎて頭がこんがらがる｣等の意見が見られた.
他にGoogle Workspace, LINEなども使っているので, 確かにパッと見では多いように思える. しかし実際やってみると皆問題なく使い分けが出来ているように思う.
Slackワンストップ, 的なことをやりたいならカスタムレスポンスで用途毎にツールのURLを表示してあげると親切かもしれない. ワンストップにすれば上記の批判はある程度緩和されるのではないかと思う.
正直, 僕以外のメンバーは全員学部生なので院生ﾊﾟｲｾﾝの権力を振りかざした強引なDXだった説も存在する. ただ結構強気で行かないと, ツールやプロジェクト活動のフローの変更はなかなか上手く行かないと身にしみて理解することが出来た.
