?

Log in

No account? Create an account
Хостинг Бегет предлагает веб-коммандер для работы с файлами или FTP. В FTP есть галочка «включить SSH», но не совсем понятно, как она работает. FTP - небезопасный протокол (пароль не шифруется, хочется чего-то большего). Т.е. мы обязательно хотим эту галочку.

Расследования показали, что можно следующее:

подключение по ssh



При этом мы получаем командную строку на удалённом сервере, но файлы просто так не скопируешь. Пример команды:
ssh -l ЛОГИН_ФТП ЛОГИН_БЕГЕТ.beget.tech

подключение по sshfs



Документация по sshfs устарела, а хостер не рассказывает, как именно подключаться. Есть нюаснаы. Я делал так на своей debian stretch (debian 9).
Здесь ЛОГИН_БЕГЕТ - это ваш логин как пользователя хостинрга, а БУКВА - первая буква этого логина. ЛОГИН_ФТП вы создаёте в разделе ftp (и галочку SSH включить). ИМЯ_САЙТА задаётся в разделе "сайты", а ТОЧКА-МОНТИРОВАНИЯ - существующая директория на вашем компьютере, в которой вы хотите видеть файлы с хостинга.
# включаем fuse (действует до перезагрузки, но не факт, что вообще нужно)
# упоминалось /etc/modules, в к-рое можно прописать fuse, чтобы избежать
# необходимости всегда выполнять эту команду
sudo modprobe fuse 
# устанавливает sshfs
sudo apt-get install sshfs
# монтируем
sudo sshfs ЛОГИН_ФТП@ЛОГИН_БЕГЕТ.beget.tech:/home/БУКВА/ЛОГИН_БЕГЕТ/
 ИМЯ_САЙТА/public_html ТОЧКА-МОНТИРОВАНИЯ

Теперь директория ТОЧКА-МОНТИРОВАНИЯ годится для доступа к файлам (все файлы под рутом, как сделать лучше - я не знаю). Для размонтирования делаем так:
sudo fusermount -u /y/sandro

В общем, тяп-ляп, кое-как за 2 часа удалось сделать, чтобы хоть как-то работало. Не забывайте, что все файлы от рута!

Примечание: в документации написано про какую-то группу fuse, но утверждается, что она неактуальна, начиная с 8-й версии Debian.

подключение по scp


Есть статья: https://beget.com/ru/articles/winscp
Всё просто работает (правда, вам может понадобиться сгенерировать свои ключи, но я это делал давно, у меня они уже есть. Я отключил установку putty и pageant и всё просто заработало)
Стандарты

Зачем вообще нужен обратимый транслит?

Вот зачем: есть и будут места, куда кириллицу нельзя. Важнейшие из них: E-mail, логины и имена пользователей (в том же Linux). Есть те, где она создаёт большие неудобства (cmd-файлы windows, git, bitbucket). Но мы хотим писать на русском языке (не хочешь - жми Су-Ц).

Тогда зачем нужен новый стандарт, если уже есть, к примеру, ГОСТ 7.79-2000 (системы А и Б) и ГОСТ 52535.1-2006 ? Ответим на примере:
Приходят к нам на работу Эй Даль и Ей Дал. Их нужно добавить в корпоративные информационные системы и дать им корпоративную почту. Мы транслитерируем их и получаем по ГОСТ 7.79-2000, система А: èj dal′ и ej dal. Нельзя имена с диакритикой. Выкидываем диакритику - имена начинают совпадать. Система Б: e`j dal` и ej dal. То же. ГОСТ 52535.1-2006 - ey dal и ey dal. Имена начинают совпадать. Мы, конечно, выкрутимся и одного из них переименуем. Но это означает ровно то, что принятая система кодирования не работает (неспособна точно и без искажений передавать информацию). Пример, когда это плохо, привёл автор первого обратимого транслита для кириллицы Владимир Зайцев. Ситуация такая: пришли Эй Даль и Ей Дал на томографию, и в итоге Эй Даль получил диагноз от Ей Дал и наоборот.

Да, но стоит ли ради такой, пусть и существенной, но преодолимой трудности заводить ещё один стандарт? Википедия приводит как раз 15 стандартов транслитерации, так что мы с яролитом даже в комикс попасть опоздали.

Ещё пример: мы хотим Си с русскоязычным синтаксисом. Теоретически Си поддерживает кириллицу, на практике же тот или иной инструмент обязательно сломается и придётся возвращаться к латинице. Поэтому мы сделаем утилиту, которая кодирует все идентификаторы транслитом и компилируем уже транслитерированную программу (такие утилиты уже есть). Мы захотим переводить ошибки компилятора Си обратно на русский язык. Компилятор скомпилировал транслитерированный текст и выдал сообщение "variable ej is not defined". Как мы переведём его на русский? "переменная эй не определена" или "переменная ей не определена"?

Какие костыли не придумай для решения этой задачи, они по сути всё равно сведутся к решению задачи создания обратимого транслита. Поэтому, если мы хотим использовать в ИТ русский язык (а кто не хотел, тот досюда не дочитал), то создание обратимого транслита на сегодня является неизбежным. Значит, нужно его стандартизировать, чем раньше - тем лучше. Ни один из 15 стандартов не годится для использования в программах - либо знаки препинания, либо необратимость. Так что в данном случае речь идёт не о создании «ещё одного» стандарта, а о решении актуальной задачи, которую ни один из 15 предыдущих стандартов не решил.

И последнее: зачем транслит, если есть Юникод? Повторяю ещё раз для самых маленьких: есть те места, где юникод применить на практике нельзя: имена пользователей, E-mail, идентификаторы Си, имена проектов на bitbucket, внутренние имена сайтов на хостинге Бегет, да и ещё массу других мест любой из вас при желании вспомнит.

А где применяется обратимый транслит?
Томография. ФИО пациента, забитое в томограф транслитом, позволяет врачу правильно назвать пациента по имени и скопировать ФИО в друге документы, не прибегая к суррогатным ключам и сторонним системам.

Имена в базе данных Firebird. Firebird имеет ограниченную (в мою бытность был 31 символ) длину идентификатора. При этом в Firebird нет пространств имён, а имена без учёта регистра. Имя таблицы обычно выглядит как префикспредметнойобласти_названиесущности.
Называть таблицу русскими буквами можно, но тогда лимит сократится вдвое, до 15 букв. Обратимый транслит позволяет называть таблицы по-русски, но использовать более длинные имена. Обратимость транслита помогает в ситуации, когда мы выдаём ошибку, скажем, "не удалось добавить запись в таблицу ...". Конечно, имя таблицы можно брать из каких-то внешних метаданных, но зачем это лишнее действие, если без него можно обойтись?

Логины. Одна организация (не пожелавшая назвать себя) по ТЗ получила требования, чтобы логин был в кириллице. Внутри система - на английском. Поэтому они использовали транслит для генерации логинов. При этом конечный пользователь даже не знал о том, что логины на самом деле на латинице. А теперь опять приходят наши друзья Эй Даль и Ей Дал и администратор (который тоже может не знать про латиницу) впадает в ступор, поскольку Эй Даль не добавляется. Некоторые программы (1С 7.7) показывают список возможных логинов в окне входа. Если транслит обратим, то мы можем получить список логинов с сервера и провести обратную транслитерацию. В противном случае нам нужно городить отдельную систему, параллельную системе учёта пользователей и нужную лишь для хранения русского имени. А в системе учёта пользователей далеко не всегда есть триггеры, которые позволили ли бы заметить добавление нового логина. Т.е. может возникнуть ненадёжная работа системы. Обратимый транслит легко и красиво решает эту проблему.

Бат-файлы. Яр был попыткой создать полностью русскоязычную среду. Посмотрите на 1С - там все понятия русифицированы. Так же и я попытался. Например, что такое для русскоязычного человека src? Просто набор букв. Исходные тексты можно назвать «ит», документацию «док» и т.п. Но когда мы пытаемся написать бат-файлы (для сборки системы и её запуска), там всё плохо. Начинает смешиваться юникод, 1251, 866. В итоге возникает огромное желание писать комментарии латиницей, чтобы снизить уровень сложности на 1. Соответственно возникают строчки типа @REM Ehta programma sokhranjaet obraz Jara. Также зачастую хочется назвать латиницей имена файлов, к которым мы обращаемся через call. Но среда-то должна быть русскоязычной, поэтому тут просто нет альтернативы транслиту. Обратимость здесь не так нужна, но зачем нужен необратимый транслит, если есть обратимый, который ничем не хуже?

Имена файлов и директорий. Когда я ещё пытался дружить с bitbucket, я столкнулся с тем, что некоторые имена файлов уродуются сервисом. Вплоть до повреждения репозитория. После этого пришлось некоторые директории переименовать в транслит.

Якоря в документации. Честно сказать, не помню где, но я столкнулся с тем, что в каком-то сервисе имена пунктов внутри файла (атрибут name) в кириллице не воспринимаются. Соответственно, при генерации оглавления (а она, естественно, должна быть автоматической) пришлось использовать транслит.

Имена таблиц в MS SQL. Профессионал, работая с базой из 100 таблиц, никогда не листает список мышью. Он пытается набирать название с клавиатуры. Если мы хотим начать русификацию, то назвать 101-ю таблицу в кириллице - означает разбить этот список на два. Здесь транслит нужен уже для политики. Впрочем, ту битву я вчистую проиграл, но я там уже и не работаю :)

И один гипотетический пример. Звонит Сергей Кужугетович Владимиру Владимировичу и говорит: к нам летят томагавки. Вышлите координаты целей для ответного удара на E-mail. Владимир Владимирович: а напомните ваш E-mail, у меня под рукой нет записной книжки. Ш как w? или как sh? C как русское или как доллар? И т.п. Пока происходит этот разговор, томагавки как раз успеют долететь. Это, конечно, рассказ метафорический. Но любая попытка продиктовать E-mail занимает в России много времени, а люди иногда бывают очень дорогостоящие. И каждый такой раз мы немножечко-немножечко увеличиваем своё отставание от США. А мог бы Сергей Кужугетович сказать: пишите на ФИО по Яролиту.
Во-первых, я завожу новое слово BlackBoxComponentBuilder и буду его тотально применять везде, где дело касается BlackBox Component Builder. Поскольку название BlackBox Component Builder - очень недружественное к поисковым системам. Сокращённым названием будет BBCB или Коробка Вирта.

В BlackBoxComponentBuilder - горячая замена кода на уровне отдельного модуля. Модули не могут циклически ссылаться друг на друга, хотя при интерактивной разработке это может случайно получиться. В этом случае после выхода Коробка Вирта больше не запустится.

Дальше я не очень понимаю, но модули могут быть скомпонованы в исполняемый файл или лежать в файловой системе (как dll/so). Если они лежат отдельно, то будут подгружаться по мере надобности.

Единицей компиляции является модуль, есть две команды - «Компилировать» и «Компилировать и выгрузить». Почти всегда нужна вторая из них, а горячая клавиша есть только у первой. Это странно, но исправимо, нужно открыть Dev\Rsrc\ru\Strings.odc средой и забрать подчёркнутую букву от другой команды:
<pre>
&Compile Компилировать
&Compile And Unload &Компилировать и выгрузить
</pre>

Компиляция порождает файл, в память ничего не загружает. Выгрузка модуля выгружает из памяти старую версию модуля (и всех, кто на него ссылается). После этого, при следующем обращении новая версия файла вступит в силу. Такой вот, своебразный процесс.

Модули распространяются или в виде ужасных закодированных файлов с абракадаброй. Такой файл обрабатывается так:
Меню/Файл/Новый - Вставить ужасный текст - Меню/Инструменты/Раскодировать . После этого там предлагается что-то сделать - скомпилировать или что-то. Это надо сделать.

Второй вариант - просто в виде файлов. odc, mod и т.п. Как с этим работать, я не знаю.

Связывание, компоновка, линковка. Делается тоже из среды. Для того, чтобы создать новую Коробку Вирта с вашими изменениями, иногда нужно воспользоваться файлом Dev/Docu/Build-Tool
Правая кнопка по пустому месту экрана/персонализация/ищем "подчёрк" и попадаем в нужный пункт: "подчёркивать клавиши доступа, когда они доступны", или же "подчёркивать сочетания клавиш доступа в меню, если они доступны".

Сами они инвалиды. Бл☼. 
Как и обычно, есть несколько поколений инструментов с пересекающимися областями применения. Шпаргалка.

Webpack (якобы) позволяет избавиться от bower и gulp/grunt.

Но grunt у нас есть по условию. Нам нужен bower?

Есть статья от декабря 2017 года
Bower умер, да здравствует npm. И Yarn. Что в ней?

Для чего был хорош Bower? Это - пакетный менеджер, который управляет фреймворками, библиотеками, ассетами (я так понял, ассеты - это «вручную» изготовленные (а не сгенерированные сборщиком) файлы css и js, хотя внятного определения не нашёл), утилитами. Он устанавливает их и контролирует корректность зависимостей.

Традиционно во многих проектах npm использовался для серверной стороны, а bower - для клиентской.

Основным преимуществом bower было то, что он ставит минимальный набор зависимостей, избегая дублировать библиотеки и предоставляя пользователю контроль над такими ситуациями. Например, bower позволял пользователю выбрать подходящую версию jQuery (разные библиотеки могут быть совместимы с разными дипазонами версий jQuery).

Эти возможности теперь реализованы в npm,Yarn и вебпак (каждым по отдельности или только системой из них -  об этом пока ни слова! - читаем дальше и надеемся на лучшее - прим.перев).

Далее приводится 6 причин, по которым надо отказаться от Bower. Из них вполне объективной  видится причина 2: экономичный граф зависимостей теперь
доступен в npm и yarn.

И далее - увы - веб, как обычно, разочаровал. Bower заменяется на систему из всех трёх инструментов. Никакого одного не достаточно. Про вебпак я уже составил своё мнение: пока есть возможность, я им пользоваться не буду.

На этом статья о серти bower заканчивается, и в конце даётся ссылка на статью автора bower о том, как мигрировать с bower.

Здесь автор bower даёт практические рекомендации, как выводить из bower старые проекты. 
При вводе двуязычных текстов всегда трудно узнать, является ли "а" или "с" кириллической или латинской. Я разработал для Яра режим, при включении которого латиница подчёркивается.



Однако сейчас приходится заниматься другими файлами, и их удобнее обрабатывать не в среде Яра. Соответственно, возник вопрос о реализации подобного функционала для других сред разработки.

Здесь я соберу информацию, которую удалось на эту тему найти:
https://bitbucket.org/budden/iaroklava-js/src/master/

Общая идея - пробел служит модификатором. Если пробел нажали и удерживаем, то вводятся буквы латиницы, а если нажали и отпустили - то вводится пробел. Такой способ ввода рассчитан на слепой 10-пальцевый метод ввода. Он позволяет вводить, к примеру, html или md файлы с русским языком без переключения раскладки вообще. Но он требует обучения (до нескольких недель).

Соответственно, варианты такие. Для веба - это скрипт, результат которого можно посмотреть тут:


Для Windows - скрипт для программы Autohotkey.

Для Linux - ручная настройка xkb + набор взаимодействующих программ.

Смотрите все подробности в репозитории. Смотрите также другие записи с тегом "раскладка клавиатуры".

Что это за текст


Текст написан для себя. По ходу дела я подумал, что он может быть интересен и другим (новичкам). Но редактирование поста в LiveJournal через медленную мобильную сеть не доставляет особой радости, поэтому оформление явно подкачало. И кое-где остались другие мелкие огрехи. Во всяком случае, я выполнил правило «если что-то непонятно, разберись и напиши об этом пост - когда забудешь - нагуглишь его».

Завязка


Прежде всего, о названиях. В семейство входят (как минимум) три имени: Mustache, Handlebars и Hogan.

В целом синтаксис mustache объяснён в руководстве по mustache (перевод тут, правда они не осилили перевод и перевели partials как "обособленные фрагменты" и тут же - как "частные значения"). Но есть две проблемы:



  • partials непонятны

  • не написано о наследовании шаблонов, которое, впрочем, является нестандартным расширением


В конце концов я пришёл к выводу, что partials - это вставляемые из другого места фрагменты шаблона (аналог #include в Си), которые тоже могут содержать расширяемые элементы, такие, как {{имя}}. В зависимости от реализации mustache, эти куски могут браться из файлов (по имени файла), или же они должны быть предоставлены при расширении (render) шаблона.



Наши цели



  • сделать простейший работающий пример с partials

  • сделать, чтобы имя в шаблоне, отсутствующее в данных выдавало ошибку, а не просто расширялось в пустую строку - иначе не поймать опечатки

  • компилировать partials (в документации по mustache говорится, что они расширяются во время выполнения)

  • избавиться от необходимости явно передавать partials - это дикость

  • понять варианты использования шаблонизатора и как их реализовывать



Теория


Mustache, по определению - это препроцессор, который на вход получает три вещи:



  • данные, которые по структуре представимы в виде json

  • шаблон - текст с разметкой для подстановки данных

  • реализацию всех partials, упомянутых в шаблоне


и на выходе даёт текст - расширенный шаблон. Препроцессор имеет много реализаций на разных языках программирования и много интеграций с различными средами и может называться mustache, hogan, handlebars (и ещё как нибудь?).



Процесс (на примере hogan) таков:


 Компиляция (Hogan.compile) (нужен только шаблон)
   лексический разбор (Hogan.scan)
   синтаксический разбор (Hogan.parse)
   генерация кода (Hogan.generate)
 Расширение (КомпилированныйШаблон.render)  (на входе - данные и partials)




В простейшем случае компиляция и расширение шаблона производятся клиентом. Но! Данные - каждый раз разные (допустим, это товары или люди), а шаблон - одинаковый. Поэтому логично делать компиляцию пореже, запоминать и повторно использовать её результаты. Обычный Mustache может генерировать код расширения шаблона на Ruby (с помощью утилиты mustache). Hogan (с помощью утилиты hulk) генерирует код на JavaScript. Этот код может выполняться как на клиенте, так и на сервере (в случае node.js). Для PHP я нашёл библиотеку lightncandy, которая декларирует возможность генерировать PHP файлы по шаблону - так достигается серверное кеширование результатов компиляции. GRMustache для Swift не декларирует возможность сгенерировать код расширения шаблона. CL-mustache для common lisp порождает функцию, но по сути внутри неё - интерпретация, partial-ы не прекомпилируются. Есть реализация и для моего любимого tcl.



Так получилось, что для моей текущей работы был выбран Hogan.js - и это хорошо. В нём нет лишнего и он позволяет сохранять результат компиляции.


Пишем «Привет, мир!»



Скачиваем hogan.



> mkdir mu
> cd mu
> npm init 
> npm install hogan.js






Эти строки уже не совсем тривиальны. Если собираетесь использовать express, прочитайте все ответы на этот вопрос на stackoverflow - может быть, вам нужен hogan-express.



Создадим два файла - для шаблона и для фрагмента (partial).



шаблон.хш:



{{! это - файл шаблон.хш }}
Подставляемый говорит: '{{> подставляемый}}' 





подставляемый.хш:



Я - подставляемый и говорю: "{{Приветствие}}"





Это - файлы шаблонов. Обычно они имеют расширение .mustache или .hgs. Но мы, квасные патриоты, всему пытаемся дать русские названия. PhpStorm можно научить, что .хш - это файл mustache, для этого открываем файл, щёлкаем правой кнопкой мыши по его "табу" в списке файлов, далее - Associate with file type и выбираем Handlebars/Mustache.



Прекомпилируем шаблоны и сохраняем результат в файл «скомпилированный-шаблон.js»



> node_modules/.bin/hulk шаблон.хш подставляемый.хш > скомпилированный-шаблон.js





Заглянем в этот «скомпилированный-шаблон.js»:



if (!!!templates) var templates = {};
templates["шаблон"] = new Hogan.Template({
    code: function (c, p, i) {
        var t = this;
        t.b(i = i || "");
        t.b("Подставляемый говорит: '");
        t.b(t.rp("<подставляемый0", c, p, ""));
        t.b("'");
        return t.fl();
    }, partials: {"<подставляемый0": {name: "подставляемый", partials: {}, subs: {}}}, subs: {}
});
templates["подставляемый"] = new Hogan.Template({
    // и т.п.
});






Забавно, что вместо достаточно компактного шаблона получился гораздо больший по размеру код (который клиент должен скачать, скомпилировать и выполнить). На знаю-не знаю, всегда ли так уж хороши их рекомендации по предварительной компиляции.



Собираем всё воедино, в файл «тест-хогана.html»:



<html><head><meta charset=utf-8>
<script src="node_modules/hogan.js/dist/hogan-3.0.2.js"></script>
<script src="скомпилированный-шаблон.js"></script>
<script>
  let Данные = { "Приветствие": "Привет, мир!" };
  let РезультатРасширения = templates["шаблон"].render(Данные, templates);
  console.log(`РезультатРасширения: ${РезультатРасширения}`);
</script>
</head><body>Смотри сообщения консоли разработчика</body></html>





Открываем файл, переходим в инструменты разработчика (F12) и видим в консоли сообщение:



РезультатРасширения: Подставляемый говорит: 'Я - подставляемый и говорю: "Привет, мир!"'





Ловим ошибки


Теперь наша задача - выбрасывать исключение, если имя не существует. Мы запретим отсутствующие имена вообще. Если мы хотим пустоту, то нужно будет явно передать Null.



Во-первых, опции описаны на github. Среди них опции отлова ошибок нет. Смотрим исходник и видим недокументированную опцию doModelGet. Но суть не в том. Судя по коду, можно либо модифицировать код "на горячую", либо форк. Форк плох, т.к. ломается npm install и прочая. Попробуем горячую замену. Вставим в начало нашего скрипта следующие строки:



    // спасибо https://learn.javascript.ru/decorators
  let Старая_rp = Hogan.Template.prototype.rp;
  let Старая_d = Hogan.Template.prototype.d;
  let Старая_f = Hogan.Template.prototype.f;

  Hogan.Template.prototype.rp = function Декорированная_rp() {
    let фр = Старая_rp.apply(this,arguments);
    if (!!!фр) {
      throw new Error(`Не найден подставляемый фрагмент (partial) - ищите ключ отладчиком`);
    }
    return фр;
  };

  Hogan.Template.prototype.d = function Декорированная_d() {
      let зн = Старая_d.apply(this,arguments);
      if (!!!зн) {
          let key = arguments[0];
          throw new Error(`Не найдено имя «${key}»`);
      }
      return зн;
  };


  Hogan.Template.prototype.f = function Декорированная_f() {
      let зн = Старая_f.apply(this,arguments);
      if (!!!зн) {
          let key = arguments[0];
          throw new Error(`Не найдено имя «${key}»`);
      }
      return зн;
  };





Вроде оно работает для нашего простейшего примера, дальше пока не тестировал. Для локализации ошибки нужно с помощью dev tools поставить точку прерывания на место, откуда вылетает исключение, перегрузить страницу. Точка прерывания сработает. Тогда в стеке находим сгенерированный hulk-ом код и по его виду пытаемся понять, в каком месте у нас проблема, а по контексту смотрим, чего не хватает. Не слишком удобно, но лучше, чем ничего. Что делать, если шаблон представлен в виде строки - я не знаю, но, вероятно, где-то на стеке можно будет увидеть текст шаблона.



Наследование шаблонов


Это - ещё одна возможность, не упомянутая в «man 5 mustache», но описанная в непринятом предложении (pull request) для спецификации mustache. Попробую перевести суть сопроводительного письма своими словами:
«Мы часто хотим иметь базовый шаблон, в котором хранится скелет страницы, а каждая настоящая страница просто заменяет секции в этом скелете своим содержимым. Скелет может включать все скрипты аналитики и общую для всех страниц разметку, при этом остаётся возможность заменить заголовок на любой другой. Возможные решения здесь - копировать скелет в каждую страницу или генерировать страницу за два прохода, оба не идеальны. Поэтому мы хотим `наследование' страниц в стиле ООП»

Детали смотрите в самом  предложении - на мой взгляд, очень полезно с точки зрения компактности, но может привести к дальнейшему затруднению отладки. Я не проверял, помогают ли мои декораторы искать ошибки в наследуемых шаблонах - думаю, нужно что-то к ним добавить.

Варианты использования

С этим мы толком не разобрались и примеры не были разработаны. Ясны следующие варианты:

  • Шаблоны передаются текстом на клиента, где и расширяются. В SPA могут кешироваться.

  • Шаблоны компилируются во время сборки сайта и превращаются в Javascript, который загружается клиентом и исполняется на им (это вариант нашего "приветмира"). По заверениям Twitter, это лучше, чем передавать шаблоны в виде текста и разбирать их на стороне клиента, но я сомневаюсь - как минимум, размер передаваемых данных увеличивается. Нужно проверять.

  • Шаблоны полностью расширяются на сервере, при возможности результаты расшерения кешируются с помощью утилит, генерирующих код на языке серверной стороны. Это возможно для PHP, Node.js, Swift.

Чего не хватает


  • В проекте https://github.com/kupriyanenko/jsttojs обещают предкомпиляцию в js для нескольких разных шаблонизаторов, включая mustache, но я не смотрел.

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

  • Предложенный патч толком не протестирован


Полезные ссылки по теме:

SlickGrid

Набор ссылок к выбору грида, и набор ссылок конкретно по SlickGrid

К выбору грида

Выбираем грид для админки - LOR

Хабр - обзор библиотек виджетов

SlickGrid

SlickGrid documentation improvement

Tags:

Учим JavaScript

Учим JS и собираем сюда всю толковое, что удаётся найти.

Собеседование на должность программиста JS (2014 год, явно устарело).

ООП - ссылка с "собеседования" - очень познавательно и хорошо разъясняет взаимосвязь "обычного" ООП и ООП в JS.

Что такое strict mode
Ссылка

'use strict'


По умолчанию применяется внутри модулей, т.е. внутри функций.
Разные глупости, типа присвоения константам, обращения к несуществующим переменным, удаления неудаляемых свойств, приводят к ошибке, а не молча игнорируются. Исключены или сделаны менее уязвимыми способы обращения к arguments, caller. Исключено создание переменной присваиванием. eval не может создать новых переменных в окружении.



Что нового в ES 6
Ссылка

  • let - переменные в текущем блоке, а не в текущей функции; const

  • Обратная кавычка - интерполяция (многострочных) строк

  • Destructuring

  • Классы - синтаксический сахар для конструкторов

  • Обещания

  • Стрелочные функции - сахар для bind. Позволяют использовать в качестве this значение this из текущей области видимости, а не this, определяемый по а.функция()

  • for .. of

Tags: