Понемногу перебираюсь на JavaScript ES6 синтаксис. По мере появления его нативной поддержки в nodeJS и Chrome. ES6 таит в себе множество не очевидных вещей. Больше всего я их встретил в class-ах. Классы в ES6 это обширный набор синтаксического сахара для prototype. С ними писать код приятнее, да и сам синтаксис вынуждает подходить к этому дисциплинированнее. В этой мини-заметке я опишу пары интересных моментов:

• Синтаксис допускает только короткие имена методов;
• Тело класса описывает методы, которые будут помещены в prototype и статические методы, которые будут помещены в сам объект класса. Так вот… Таким образом вы можете поступить только с методами и generator-ми. Т.е. никаких хешей, никаких чисел, строк, регулярных выражений. Всё, что вы захотите поместить сверх методов и генераторов будет идти уже отдельными строками кода после описания класса;
• Это ограничение довольно понятно. Дескать дисциплинирует все подобные вещи определять в конструкторе и не позволяет переписывать детьми в прототипе. Но… Почему то nodejs не поддерживает статические generator-ы. Не статические поддерживает, а на статические лови syntax error. Наверное это баг (static * name());
• Для удобного доступа к родительским методам (имею ввиду наследование классов) придуман super. Но… Если вы переопределяете конструктор класса, вы:
  1. Обязаны вызвать super, чтобы получить доступ к this. 
  2. Да да. До этого момента this отсутствует как таковой. Соответственно вызвать родительский конструктор, предварительно задав какие-нибудь поля новому объекту, без бунов не получится. Зачем они так сделали? о_О.
• Методы и генераторы заданные в теле класса будут не-enumerable. Но для получения их списка можно воспользоваться: Object.getOwnPropertyNames(Object.getPrototypeOf(this)).

Пока что это все грабли на которые я наткнулся. В скором времени ожидается поддержка со стороны Firefox.

В то время как браузеры умеют WebGL, анимации и многое другое, до сих пор не вменяемой поддержки таких значимых вещей как нормальная вёрстка таблиц, переносы в тексте, полноценная поддержка unicode-а в регулярных выражениях, justify-выравнивание и т.д.. Сий пост про переносы текста.

Итак. Что мы имеем? Мы имеем css3 свойство hyphen: auto. Но довольно унылую поддержку. Во-первых его не умеет ни Chrome, ни его клоны. Во-вторых его не умеет Firefox под linux. В третьих (в чём я не уверен) поддержка идёт на уровне встроенных словарей. Т.е. если вам потребовалась поддержка переносов в, к примеру, казахском тексте, вас снова ждёт облом. Но само свойство хорошо. В идеале вбив его можно забыть про все проблемы, ибо браузер сам их порешает.

Что у нас есть ещё вналичии? Есть такие опции как word-break, word-wrap, overflow-wrap, line-break. К сожалению никакая комбинация этих свойств не позволяет добиться нормальных переносов в таблице, которую перекашивает, как раз из-за отсутствия этих переносов. Например вы можете добиться вот такого вот результата:

Подробности под катом…

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

Очень не люблю пытаться вслепую искать причину неработоспособности чего бы то ни было. Вот и сейчас. Убил по меньшей мере час, пока не узнал, в чём же дело. 

Ситуация. Сервер сайта генерирует файл и пытается отдать его как статику, задействовав заголовок ETag. Реализовывается вся необходимая логика с возвратом 304 и поглядыванием в if-none-match. Но в итоге упираюсь в то, что браузер в упор не видит ETag заголовок. Первым делом полез смотреть заголовки в curl -v. Но заголовок возвращается. Начинаю ковыряться в разных статьях про ETag на предмет подводных камней. Ничего не нашёл, всё должно работать просто и надёжно. Пробую в разных браузерах. Они в упор не видят заголовка. Начинаю эксперементировать со значением заголовка, расположением в списке других заголовков, прочей чертовщиной заниматься. Очередной подход к google-у выдал мне причину.

Оказалось, что дело в том, что в конфигурации хоста nginx у меня прописано сжимать GZip-ом все ответы с определённым content-type-ом. А nginx при этом срезает ETag. Именно поэтому я видел заголовок в ответе curl-а, но не видел в браузерах. Поправил конфиг ― заработало.

Помимо прочего, я некоторое время не мог завести базовый механизм работы Last-Modified. Браузер упорно не хотел кешировать файл, несмотря на наличие всех необходимых заголовков. Оказалось всё дело в формате даты. Найденные мною быстрые решения для momentjs были кривыми, и браузер их не понимал. В конце некоторых дат указывалось смещение в виде +00:00, и всё ломалось.

Внезапно оказался перед фактом ― закончилось место на VPS. Оказалось, что node-forever съел своими логами 21 GiB места на винте. Приложение упрямо не хотело подниматься, падало, forever это писал в логи и снова пытался его поднять. Забавно…

Как уже и писал ранее, случилась у меня проблема с удалением файлов. GoPro подключается к ПК не как USB-flash, а как MTP (Media Transfer Protocol). Это выражется в том, что не все файлы, размещённые на носителе видны, тем что не удаётся посмотреть начало какого-нибудь ролика не скачав его целиком, а также в том, что мой LinuxMint отказывается скачивать с такого вот MTP-носителя файлы, ибо соединение попросту зависает при любой операции.

Ну да ладно. Есть ультрабук с Win8 на борту. Можно качать через него, ведь он файлы видит. И дёрнул меня чёрт сократить время, и скопировать сразу на флешку. Да и не скопировать а "вырезать" и "вставить". Получив несколько невнятных ошибок я столкнулся с ситуацией, когда на SD-карте файлов уже нет, а на флешке их и не появлялось вовсе. Т.е. они утеряны.

В очередной раз высказав всё, что я думаю об MTP и GoPro я подумал, что файлы ведь можно восстановить. Ибо они не должны быть ничем перезаписаны. Должны лежать как на ладони, быстро находиться и идеально восстанавливаться. Картридера у меня увы нет, мой One PlusOne не умеет внешние SD-карты. Но старый SGS II умеет. И посему я решил воспользоваться android-восстанавливалками.

• Первым в ход пошёл DiskDigger undelete. Не сказать, чтобы софтина понравилась, но она смогла найти 1 старый 3 MiB файл, совершенно бесполезный, но это уже хотя бы отличный от 0 результат. Ушло у неё на это около часа.
• Вторым был Hexamob Recovery Lite. Первое, что он сделал ― бросил меня в Google Play покупать платную версию. Логика железная, я скачал бесплатную версию, чтобы убедиться что она хотя бы найти что-то сможет, а меня уже швыряют покупать платную. Вы за кого держите пользователя? Следующим этапом было то, что нет никаких по сути опций и настроек, он просто спрашивает где сканировать и начинает сканировать. Никакой индикации прогресса нет, просто отображении анимации, мол "я ещё не завис". Ну и всякая реклама. Потерпев минуты 3 этот идаотизм, софтина ушла в утиль. Хороший пример того, как нельзя писать подобный софт.
• Третьим был Undelete for Root Users. Порадовал вменяемый и приятный на вид интерфейс, удобное управление. Не порадовало то, что он не нашёл ничего, совсем. На 32GiB ушло 1ч 11м.

Я упустил 1 момент. Дело в том, что 1 файл из 3 мне всё таки удалось с самого начала вырезать-вставить. Его я обкромсал, как обычно ffmpeg-ом, срезав по краям лишнее и снёс оригинал через shift+delete из caja. Затем, потратив часа 3 на восстановление файлов с SD-карты,  я вернулся к обрезанному видео. И понял, что, по запарке, срезал на несколько секунд больше, очень зря… А оригинал уже удалил. Решил восстановить уже этот файл. Проблема усугублялась тем, что файл лежал не на ext3 разделе, а на ntfs. 

• Вначале я наткнулся на ntfsundelete. Это консольная утилита, которой нужно указать раздел и она найдёт все легко-восстанавливаемые файлы, указав их размер, имя по возможности, inode и пр. Мой файл там нашёлся. Восстановив его (4 GiB) я получил 4 GiB кирпич, который ничем не открывается. Я подумал, что сие же mp4, а значит его можно как-нибудь починить. Полез рыскать по сети:
  • mplayer его показывает как какую то разноцветную жуть, мечту эпилептиков.
  • ffmpeg -i грязно ругался.
  • попробовал Video Repair. С ней возникли некоторые сложности, но в конце концов она просто помирала на файле с какими-то невнятными ошибками.
  • попробовал mp4repair.org. На сайте указано, что смело указывайте ему даже huge mp4 файлы, чем я и воспользовался. На ~30% всё повисает…
• Затем, я вспомнил, что файл был удалён ещё и в USB 3.0 Flash-ки. Попробовал Recuva. Нужный мне файл она нашла дважды. 1 пометила как испорченный и переписанный (причём файлом, который был на флешке уже месяц), второй как идеальный, без повреждений. Интересная форма шизофрении. Восстановив "идеальный", я столкнулся с тем, что получил такой же кирпич, как и в случае, ntfsundelete.

Учитывая, что эти 3 видео не являются для меня чем-то жизненно важным, я, убив себе настроение, закончил истязания и забил. Разве что, вот ещё на эту заметку хватило. Пожалуй, стоит купить внешний USB кардридер.

UPD1: Купил картридер. Картридер работает без каких-либо проблем. Попробовал что-нибудь найти через testdist. Тщетно. Из Win8.1 попробовал через Recuva, она в отличии от android приложений, нашла множество файлов. Восстановил те из них, которые могут быть искомыми. Все файлы ― кирпичи. Для "откирпичивания" использовал Video Repair. Получается чёрт знает что. 30% видео (отрывками по несколько секунд) идут без помех, оставшееся ― помесь с жуткими артефактами, всякими сдвигами во времени и прочим цирком.