Pull to refresh
15
0
Commander Keen @Keenest

Инженер-программист

Send message
Благодарю за внимание к мелочам, однако скажу следующее:
Оператор delete удаляет свойство из объекта. В данном случае объектом является this, а полями — ссылка на родительскую View и функцию-обработчик. Можно присвоить и null, удалив ссылку, но само поле в объекте останется.
Весь код модуля диалога у меня практически один-в-один (за исключением бизнес-логики) совпадает с sap'овским из урока по использованию диалогов курса ui5, в т.ч. exit.
По поводу создания/удаления диалога: самая затратная операция здесь — подгрузка xml-фрагмента, и именно она выполняется лишь первый раз. Ну а инициализация начальными значениями полей объекта при новом открытии — штука необходимая.
Не понял, зачем вообще огород городить, явно указывая void/undefined. Вот же:
var f1 = () => {
    // dosmth
    return;
},
f2 = () => {
    // dosmth
};
console.log(f1(), f2());

undefined undefined
Нет.
Зачем паясничать, вроде и так понятно что я имел в виду — при продакшне и так проблем хватает, зачем «искуственно» добавлять ещё и связанных с кривостью особенностью языка?

Я сужу по своему опыту: развёртывание и сопровождение сайтов на python+django, либо node.js — значительно проще и очевиднее чем написанных на php.
Конечно, дело в опыте, но меня удивляли советы действительно опытных php-программистов по устранению тех или иных проблем — настолько это порой было неочевидно.
Я не совсем понял что вы хотели сказать, но вы достучились до моего сердца!
в php отладка — это один из основных плюсов языка, большинство разработчиком даже дебагером не пользуются, т.к. язык изначально выбрасывает всю нужную информацию.

Ну не скажите. С node.js у меня не было трудноуловимых проблем на продакшне только из-за того что где-то в каком-то конфигурационном php.ini-файле установлено значение, отличное от девелопмент-сервера.
И я всегда уверен, что js-скрипт либо отработает на «отлично», либо корректно обработает ошибку и опять же что-то ответит, а не молча проигнорирует ошибку (или не проигнорирует — надо глянуть в конфиг!) и продолжит. Или не продолжит.

К слову, Webstorm — очень удобный отладчик, и совсем не страшный даже учитвая асинхронность node.js.

PS. и вообще, в php плохо всё.
Ну на счёт востребованности всё же не соглашусь: выбирая из двух кандидатов, я бы отдал предпочтение более «сильному» javascript-программисту, которого можно легко научить coffee script'у, нежели более «слабому», но знающему CS.
Не могу себе представить более правильную IDE, нежели Webstorm :)
Отмечает как warning. И вот кроме конкретно этого случая — хендлинга ошибок экспресса — подобные варнинги очень информативны и полезны.
А если использовать ещё и встроенные JSLint и JSHint…
А уж использовать next внутри функции, или нет, это на усмотрение разработчика.

А IDE ругается — unused parameter next
и приходится ставить костыли а-ля
if (next) {}

чтобы было хоть какое-то упоминание функции, хех.
Поясните пожалуйста, зачем в функции обработок ошибок передаётся параметр next, если он не используется в теле функций?
Шикарный диалог.
Можно добавить, что всё это является частью рисёча, проводимого в коворкинге, попивая смузи.
«middleware» прослойки роутов удобнее группировать и задавать в виде массива.
например:
// ..
        mwLogged = [auth.isLogged, auth.checkUser],
        mwAdmin = [auth.isLogged, auth.checkUser, auth.isAdmin];
// ..
    app.post('/user/login', routes.user.login);
    app.get( '/user/logout', mwLogged, routes.user.logout);
    app.post('/user/list', mwAdmin, routes.user.list);
    app.post('/user/add', mwAdmin, routes.user.insert);
Ну дык это и не магия — а просто несколько нестандартное использование привычного инструмента.
Так, например ''+x всегда возвращает строку, +x — число, !!x — булевское значение. Тоже, казалось бы, ничего магического — но при этом удобная штука для быстрого приведения типов.
Ох, сколько раз я подобную ситуацию встречал, играя в стандартного виндового сапёра. Ну и в жизни тоже, хе-хе.
Ошибка 451: Поросёнок Пётр.
Это тонкий ход — дать возможность программистам и поиграть, и подзаработать (продавая скрипты игрокам).
А там, глядишь, авторов лучших скриптов и на работу позовут, хех.
В первоначальной версии программа упадёт только если ни открытие, ни запись в файл не вернули ошибку, а закрытие внезапно ДА.
Да, пожалуй, правильнее действительно использовать асинхронную версию.

Однако на практике это вряд ли даст сколько-нибудь заметный прирост в производительности — всё-таки закрытие файла — операция шустрая.

Сейчас подредактирую пост. Дьявол кроется в мелочах.
Спасибо.
Нет, дело не в этом — если бы я использовал асинхронную версию close, то ф-ию callback приходилось бы вызывать всё равно в её коллбеке:
// синхронная версия
fs.closeSync(file_handle);
callback();

// асинхронная версия
fs.close(file_handle, function () {
    callback();
});

Так что по сути разницы никакой — в обоих случаях сначала закрываем файл, и только потом рапортуем о том что можно открывать следующий.
Только тем, что не попался мне на глаза раньше. Ну а теперь и смысла в нём нет.
И до каких пор поднимать? Предпочитаю прогрессивные решения.

Information

Rating
Does not participate
Location
Белгород, Белгородская обл., Россия
Registered
Activity