Небольшая заметка о том, как подключить в 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-у).

Случилось так, что неудачное обновление 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-ик я не представляю.

Столкнулся с неожиданной для себя проблемой. Сборка проекта под Windows шла криво, в то время как под Linux без проблем. Вначале грешил на обратные и прямые слеши (/ & \). Беглый поиск по этой проблематике дал мне понять, что никаких проблем с unix-like слешами под Windows быть не должно. Оказалось, что всё немного хитрее. Я в некоторых местах работах с путями как со строками, игнорируя тот факт, что пути в процессе работы могут быть сторонним кодом преобразованы. 

Скажем был у вас путь path/path/path. В процессе работы какого-нибудь gulp-плагина он исправился на windows-правильный путь path\path\path. А у вас далее по коду какой-нибудь .replace('path/path', ''). И вот оно сломалось. 

Чемпионаты Казахстана и России по дельтапланеризму 2016 в г. Алматы. 

подробности…

В августе сего года заканчивается поддержка GraphAPI 2.0 версии. Facebook уведомляет об этом прямо в своих стандартных уведомлениях соц. сети заголовком %app has a new Developer Alert, за которым следует текст:

%app has been making recent API calls to Graph API v2.0, which will reach the end of the 2-year deprecation window on Monday, August 8, 2016. Please migrate all calls to v2.1 or higher in order to avoid potential broken experiences.

Что именно, касательно OAuth, изменилось? А вот что:

• В graph.facebook.com/… следует добавить v2.6:
  • https://graph.facebook.com/v2.6/oauth/access_token
  • https://graph.facebook.com/v2.6/%uid%/picture
  • etc…
• /oauth/access_token теперь возвращает не queryString, а нормальный JSON