IT — Как докачать файл на сервер, если scp-ssh-соединение разорвалось?
Положим вы закачивали на сервер большой файл. Но с дуру выключили на ночь компьютер. Или, скажем, у вас отключили интернет. Или свет. Да мало ли что. Как докачать файл? Оказалось очень просто и без бубнов:
rsync --partial --progress -rsh=ssh %file% %destination%
Формат для %file% и %destination% тот же, что и у scp. Как всегда, спасибо stackoverflow.
IT — Подсчёт повторений слов в файле на коленке
Примитивный скрипт на JavaScript, подсчитывающий кол-во повторений английских слов без учёта морфологии и пр. лингво-хитростей:
"use strict"; /* eslint-env es6 */
const fs = require('fs');
function calculate(source)
{
const words = source
.toLowerCase()
.replace(/[^a-z0-9'’]+/gm, ' ')
.split(/\s+/)
.filter(s => s.length)
.reduce((map, word) =>
{
if(!map.get(word))
map.set(word, 0);
map.set(word, map.get(word) + 1);
return map;
}, new Map());
return Array.from(words)
.sort((a, b) => a[1] < b[1] ? 1 : -1);
}
const [,, sourceF, destinationF ] = process.argv;
if(!fs.existsSync(sourceF))
throw new Error('Couldn\'t find "' + sourceF + '" file');
const source = fs.readFileSync(sourceF).toString();
const words = calculate(source);
console.info('Found ' + words.length + ' words.');
const str = words
.map(([word, count]) => `${word} = ${count}`)
.join('\n');
fs.writeFileSync(destinationF, str);
console.info('Count-map\'s written into "' + destinationF + '" file');
Из простых, но действенных, решений можно фильтровать все слова:
- с апострофами (Mike's, I'm, You're, Can't, Don't, You'll, etc)
- отдельно стоящие числа (или вообще все слова с числами)
Если хочется больше заморочиться, то можно сподобиться и написать морфологическую "определялку" является ли слово множественной формой какого-то из других представленных слов. Но, по сути, чем глубже закопаешься, тем очевиднее будет, что для серьёзных задач стоит взять серьёзную лингво-либу.
IT — Что не так с Webpack server-ом и React Hot Loader-ом
Как минимум:
- Актуальная версия RHL в какой-то глубокой бете. Некоторые инструменты, такие как onsen monaca, в итоге, прибиты ногами к конкретной версии (иначе оно попросту не работает). Даже готовые пресеты для webpack-а завязаны на конкретные версии. Обратной совместимостью там и не пахнет. Даже сообщений внятных о том, что изменилось в stack trace-ах не ждите.
- Webpack server довольно хитро устроен внутри, поэтому такую связку очень сложно дебажить. Попробуйте ради интереса убрать [HMR] и [WDS] сообщения. В настройках плагинов такой опции нет. Попытка вырезать их из кода руками заставит вас детально разобраться в работе этого сервера. Ну или забить. Я забил :)
- Если ошибка произошла до первого успешного render-а, то stack trace показывает погоду на Марсе. Настоящая ошибка теряется в дебрях обёрток для ошибок.
- Если в Chrome Developer Tools для webpack's sourceMap-ов есть какая-то кривоватая, но поддержка, то в Firefox инструментах там просто хаос. Про stack trace-ы вообще молчу. Там просто ссылка строку в bundle.js.
- React Hot Loader по понятным причинам не перегружает обновления методов, которые были за-bind-ны в contructor-е компонента сами на себя. В итоге приходится перегружаться почти по любому поводу.
- Любые не тривиальные случаи приводят к необходимости обновить страницу.
Сложилось стойкое впечатление, что 3-ая версия React Hot Loader-а всё ещё слишком сырая, чтобы ей можно было пользоваться за пределами задач вёрстки. Но я бы не стал даже в их пределах. Этот инструмент оборачивает всё своими proxy-методами, чем сильно портит жизнь.
Поддержка sourceMap-ов тоже пока оставляет желать лучшего. Слишком часто при debug-инге проваливаешься невесть куда, не можешь поставить breakpoint, а то и вовсе наблюдаешь какие-то аномалии. Поддержка stacktrace-ов тоже пока далека от идеала.
Всё больше склоняюсь к разработке с ссылками на настоящие ресурсы, благо поддержка es6 в браузерах очень радует. Но вот JSX, я полагаю, нам в нативном виде в них не видать никогда. Так что вопрос, "а может к чёрту его этот JSX?" для меня лично достаточно актуален :)
IT — Webpack + PostCSS + SCSS
Небольшая заметка о том, как подключить в webpack и в ваше приложение postCSS с поддержкой SCSS/SASS синтаксиса.
- Устанавливаем npm i --save css-loader node-sass sass-loader style-loader postcss-loader
- Добавляем в webpack.config.js новый loader в раздел module.loaders такую вот цепочку:
{ test: /\.scss$/, loaders: ['style', 'css', 'postcss', 'sass'] }
- Подключаем в нужном JS-файле стили: import './main.scss'
- Запускаем webpack
Потребовалась вереница loader-ов. В случае необходимости можно ещё понастраивать postcss (см. документацию к postcss-loader-у).
IT — Как удалить мёртвый deb-пакет (YandexDisk)
Случилось так, что неудачное обновление YandexDisk-а, либо же их кривые dpkg-скрипты поломали мне пакетный менеджер (dpkg). Его просто парализовало. Пришлось его насильно убивать (sudo killall -9 dpkg), пытаться починить (dpkg --configure -a), но тщетно. Обновил данные с репозиториев (sudo aptitude update), и попробовал просто обновить сами пакеты (sudo aptitude upgrade). Тщетно, оно почти на любой операции дохнет на попытке обработать пакет yandex-disk. Попробовал его remove и purge. Не шмогло оно. Попробовал напрямую через dpkg, тщетно. Попробовал даже чёрную магию (sudo dpkg --remove --force-remove-reinstreq yandex-disk) всё равно зависает.
Старый добрый stack-overflow подсказал, что в таких случаях нужно править сами install-скрипты. Нужным оказался этот: /var/lib/dpkg/info/yandex-disk.prerm. Внутри буквально 1 строка. В ней killall -qw yandex-disk. Обратите внимание на флаг w. Wait. Оно ждёт смерти yandex-disk, который у меня не был запущен. Ждёт вечно. Руками убрал эти флаги и повторно заpurge-ил пакет. На этот раз всё прошло без запинки.
Дааа. Linux пока ещё сильно далёк от user-friendly интерфейсов. Как бы такую проблему смог бы самостоятельно решить не IT-ик я не представляю.