Во-первых, я не защищаю косяк компании (да, это косяк и они должны его исправить как можно скорее, имхо), я описываю что, по моему мнению, должен делать в такой ситуации пользователь, и как это работает для меня.
По поводу «дождаться смс» — я как раз говорил о том, что по моему мнению стоять у велопарковки и ждать смс — бессмысленно, гораздо проще позвонить им и в крайнем случае вернуться в той редкой ситуации, если что-то пойдёт не так. Единственное, что надо всегда проверять — что велосипед действительно заблокировался. Он при этом пищит при завершении и не вытаскивается больше из слота, очевидно. Если пользователь не заблокировал велосипед (вставил криво, например) — это косяк пользователя, и потом фиг докажешь, что это не ты его угнал, если велосипед таки сопрут. Всё остальное — косяк парковки.
Кстати, именно смысла стоять и ждать у станции я не вижу. Дождаться писка, проверить, что велосипед заблокирован (приподняв за переднюю часть рамы и легонько потянув), идти по своим делам. А вот если затем смска не придёт в положенный срок (просрочка на который уже будет волновать вас) — звонить в поддержку, жаловаться. И вернуться на станцию всегда можно.
Я так один раз не дождался смс в прошлом году и позвонил им.
Они меня спросили только о том, точно ли заблокирован велосипед и был ли писк, спросили номер станции. Я сказал — да, точно, велосипед заблокирован.
Судя по всему они отправили в тот день человека чинить станцию. Смс пришла только вечером (ездил я утром), но посчитали всё правильно.
Те, кто уже использует старые тарифы, могут продолжать использовать их, и даже могут переходить на другой тариф из старой сетки.
А вот для новых команд из сотни пользователей — будет дорого, да. С другой стороны — $9 за человека в месяц это копейки по сравнению с з/п человека, а если это делается в других целях (образовательных, например) — там есть отдельные скидки (в том числе и на 100%).
А у нас всё такое (анекдот про верблюдов помните?) — fb2, xmpp, http, tcp, html, x11, c/c++, много чего ещё.
Но для части из этого адекватной замены либо вообще нет, либо есть, но полностью перейти пока ещё нельзя.
Что конкретно бы вы предложили вместо fb2 в данный момент?
> К слову, в Node.js всё же можно написать блокирующий код.
Вы это подаёте так: «в Node.js по умолчанию всё асинхронное, но можно использовать *Sync методы и будет как вы привыкли», не упоминая про то, что использование синхронных методов на сервере в процессе работы — выстрел себе в ноги из гранатомёта. В первую очередь в статье для новичков стоило бы на этом акцентировать внимание, а то пойдут же *Sync вызовы втыкать.
> Чтобы справиться с адом callback’ов, или пирамидой погибели (pyramid of doom), применяются эмиттеры событий.
Как уже сказали — Promises, async/await. Не надо городить ад на эмиттерах =).
> Буферы
Очень важный момент (не упомянутый в этой статье) — Buffer(number) фактически выделяет кусок памяти, в которым могут быть чувствительные данные. Именно поэтому в новой версии его разделили на Buffer.from(val) и Buffer.alloc(number)/Buffer.allocUnsafe(number) — чтобы случайно не вызвать Buffer(number) при передаче числа там, где предполагался вызов Buffer(val). Buffer.alloc(number), кстати, теперь зануляет выделяемую память (allocUnsafe — нет, но его стоит использовать очень осторожно).
> Где хранить пароли?
> Для этого существует глобальный объект,
Нет, глобальный объект существует не для этого. Вынесите ваш конфиг в модуль/файл.
Они все — undefined, в вашей статье ошибка.
Эти переменные определяются не на глобальном объекте, а как аргументы функции-обёртки require.
> pm2
В прошлый раз, когда я про это упоминал, местной аудитории это очень не понравилось (вплоть до ограничения на комментирование), но я всё равно повторю: не стоит думать, что pm2/forever в вакууме — надёжный способ перезапуска приложения в продакшне. Чтобы гарантировать перезапуск, надо построить цепочку ватчеров вплоть до системного инита (и до аппаратного watchdog), и никак иначе. pm2/forever тоже могут упасть (и делают это). А если вы используете pm2/forever _исключительно_ для перезапуска — тогда он вам вообще не нужен, скорее всего.
Нет, единственное, что стоит делать при возникновении uncaughtException — закрывать всё и завершать процесс, вы же сами это упоминали.
А для красивой обработки асинхронных ошибок есть Promises, можно в сочетании с async/await.
> Аддоны на C++
Первое, на что стоит смотреть для написания нативных аддонов — nan. Если вы будете дёргать v8 руками — пострадает совместимость с версиями Node.js, и при обновлении вам с большей вероятностью придётся что-то переписывать. nan берёт это на себя.
Битбакет с 100 пользователями за $100 тоже можно сравнить с виртуалкой за $10 + какой-нибудь gitlab или redmine-git-hosting не в пользу битбакета. Но у них несколько разный набор фич и отличается удобство использования.
У гитхаба несколько больше возможностей, заметно больше интеграции с сервисами, и значительно шире пользовательская база — на гитхабе есть каждый первый, а на гитлабе/битбакете — не совсем. Поэтому он может диктовать свои условия и задирать цены больше, чем у последних, и от него не убегут — так что не стоит говорить, что маркетологи идиоты.
И да, я не говорю что всё из этого — хорошо, я просто описываю ситуацию. Совсем хорошо бы было вообще в случае децентрализованной распределённой системы хранения (с шифрованием), но до этого ещё далеко.
Я про личный тариф — я как не платил за него, так и не плачу, но вместо 10 приватных репозиториев теперь стало сколько угодно + 1 пакет Git LFS на сдачу (12 — 7). Не знаю пока, буду ли я его использовать, правда.
Так-то оно так, но я бы до сих пор рекомендовал использовать Bluebird.
Во-первых, у нативных промисов всё ещё есть некоторые проблемы, связанные со скоростью работы и занимаемой памятью.
Во-вторых, пока нативной поддержки API на промисах нет — без promisifyAll весьма тяжело.
Если честно, «co» нужен только как временная альтернатива пока нет нативного async/await.
Причём остался ли он нужен сегодня, когда Babel переводит вам код с async/await в код на генераторах — тоже вопрос.
Я не говорю, что «co» плохой или что его не надо использовать, но я сомневаюсь, что это то, с чего надо сейчас начинать.
Есть ненулевой шанс, что его задепрекейтят в ближайший год.
О, а купоны тоже, кажется, перевели — был на Small, стал «$12 off». Так что пользователям с купонами (по тарифу «для частных лиц») по факту будет бесплатный апдейт на безлимит.
Но ещё не применили — «Sit tight! We’re in the process of upgrading your account to unlimited private repositories».
Уже неверно. TurboFan оптимизирует функции с with. А до TurboFan — не «внутри with», а «содержащий with».
И да, мне не очень нравится идея — так сложнее отслеживать зависимости модулей, хуже ясно что чего использует, плохо видна структура проекта.
Да, это можно исправить «соглашениями об именовании», но эти соглашения об именовании в таком случае должны в себя включать перечисление используемых модулей в шапке файла. То есть как раз то, от чего вы и избавились.
Да понятно, зачем это сделано. Но если это сделано каким-то из методов, кроме копирования ключа напрямую (причём не по сообщению от сервера, который говорит, куда копировать) — то толку от такого end-to-end шифрования не сильно больше, чем от client-server и server-client. Скорее — уже ставшее привычным «глядите, как у нас всё стало безопасно, используйте наш мессенджер».
> Для организации end-to-end шифрования каждый из клиентов использует пару ключей: открытый и закрытый. Эта пара ключей алгоритма шифрования 256-bit Curve-25519 (ID ключа) для клиента Viber генерируется при установке мессенджера на основное устройство. Публичная часть ключа отправляется на сервер Viber, а приватная хранится на устройстве клиента для расшифровки приходящих сообщений. Прочие устройства, которые работают с этим аккаунтом Viber, также получают копию закрытого ключа от основного устройства с использованием специального криптографического алгоритма.
Тут, кстати, два момента.
Первый — открытый ключ идёт через сервер, так что сервер может его вполне подменить — защиты от MitM со стороны сервера тут, очевидно, нет.
Второй — «специальный криптографический алгоритм» почти наверняка просто передёт приватный ключ (каким образом — не столь важно) по указке от сервера. Со всеми вытекающими.
По поводу «дождаться смс» — я как раз говорил о том, что по моему мнению стоять у велопарковки и ждать смс — бессмысленно, гораздо проще позвонить им и в крайнем случае вернуться в той редкой ситуации, если что-то пойдёт не так. Единственное, что надо всегда проверять — что велосипед действительно заблокировался. Он при этом пищит при завершении и не вытаскивается больше из слота, очевидно. Если пользователь не заблокировал велосипед (вставил криво, например) — это косяк пользователя, и потом фиг докажешь, что это не ты его угнал, если велосипед таки сопрут. Всё остальное — косяк парковки.
Учитывая, что Yota фактически принадлежит Мегафону, это не совсем корректное замечание.
Минифицировали и положили в http://map.vmr.gov.ua/scripts/__RasPl.js.
Копия доступна по http://pastebin.com/xww1EKP1, но за аутентичность ручаться не могу.
Теперь понял, спасибо!
Они меня спросили только о том, точно ли заблокирован велосипед и был ли писк, спросили номер станции. Я сказал — да, точно, велосипед заблокирован.
Судя по всему они отправили в тот день человека чинить станцию. Смс пришла только вечером (ездил я утром), но посчитали всё правильно.
На самом деле, это достаточно просто решается пост-обработкой.
А вот для новых команд из сотни пользователей — будет дорого, да. С другой стороны — $9 за человека в месяц это копейки по сравнению с з/п человека, а если это делается в других целях (образовательных, например) — там есть отдельные скидки (в том числе и на 100%).
Но для части из этого адекватной замены либо вообще нет, либо есть, но полностью перейти пока ещё нельзя.
Что конкретно бы вы предложили вместо fb2 в данный момент?
По пунктам:
> К слову, в Node.js всё же можно написать блокирующий код.
Вы это подаёте так: «в Node.js по умолчанию всё асинхронное, но можно использовать *Sync методы и будет как вы привыкли», не упоминая про то, что использование синхронных методов на сервере в процессе работы — выстрел себе в ноги из гранатомёта. В первую очередь в статье для новичков стоило бы на этом акцентировать внимание, а то пойдут же *Sync вызовы втыкать.
> Чтобы справиться с адом callback’ов, или пирамидой погибели (pyramid of doom), применяются эмиттеры событий.
Как уже сказали — Promises, async/await. Не надо городить ад на эмиттерах =).
> Буферы
Очень важный момент (не упомянутый в этой статье) — Buffer(number) фактически выделяет кусок памяти, в которым могут быть чувствительные данные. Именно поэтому в новой версии его разделили на Buffer.from(val) и Buffer.alloc(number)/Buffer.allocUnsafe(number) — чтобы случайно не вызвать Buffer(number) при передаче числа там, где предполагался вызов Buffer(val). Buffer.alloc(number), кстати, теперь зануляет выделяемую память (allocUnsafe — нет, но его стоит использовать очень осторожно).
> Где хранить пароли?
> Для этого существует глобальный объект,
Нет, глобальный объект существует не для этого. Вынесите ваш конфиг в модуль/файл.
> global.__filename, global.__dirname, global.module, global.require
Они все — undefined, в вашей статье ошибка.
Эти переменные определяются не на глобальном объекте, а как аргументы функции-обёртки require.
> pm2
В прошлый раз, когда я про это упоминал, местной аудитории это очень не понравилось (вплоть до ограничения на комментирование), но я всё равно повторю: не стоит думать, что pm2/forever в вакууме — надёжный способ перезапуска приложения в продакшне. Чтобы гарантировать перезапуск, надо построить цепочку ватчеров вплоть до системного инита (и до аппаратного watchdog), и никак иначе. pm2/forever тоже могут упасть (и делают это). А если вы используете pm2/forever _исключительно_ для перезапуска — тогда он вам вообще не нужен, скорее всего.
> uncaughtException
Ещё стоит упомянуть unhandledRejection.
> Обработка асинхронных ошибок
> Прослушиваем uncaughtException.
Нет, единственное, что стоит делать при возникновении uncaughtException — закрывать всё и завершать процесс, вы же сами это упоминали.
А для красивой обработки асинхронных ошибок есть Promises, можно в сочетании с async/await.
> Аддоны на C++
Первое, на что стоит смотреть для написания нативных аддонов — nan. Если вы будете дёргать v8 руками — пострадает совместимость с версиями Node.js, и при обновлении вам с большей вероятностью придётся что-то переписывать. nan берёт это на себя.
Битбакет с 100 пользователями за $100 тоже можно сравнить с виртуалкой за $10 + какой-нибудь gitlab или redmine-git-hosting не в пользу битбакета. Но у них несколько разный набор фич и отличается удобство использования.
У гитхаба несколько больше возможностей, заметно больше интеграции с сервисами, и значительно шире пользовательская база — на гитхабе есть каждый первый, а на гитлабе/битбакете — не совсем. Поэтому он может диктовать свои условия и задирать цены больше, чем у последних, и от него не убегут — так что не стоит говорить, что маркетологи идиоты.
И да, я не говорю что всё из этого — хорошо, я просто описываю ситуацию. Совсем хорошо бы было вообще в случае децентрализованной распределённой системы хранения (с шифрованием), но до этого ещё далеко.
В целом я очень рад.
Больше того, вы сможете переходить на более дешёвый или более дорогой план по старой схеме.
Во-первых, у нативных промисов всё ещё есть некоторые проблемы, связанные со скоростью работы и занимаемой памятью.
Во-вторых, пока нативной поддержки API на промисах нет — без promisifyAll весьма тяжело.
Причём остался ли он нужен сегодня, когда Babel переводит вам код с async/await в код на генераторах — тоже вопрос.
Я не говорю, что «co» плохой или что его не надо использовать, но я сомневаюсь, что это то, с чего надо сейчас начинать.
Есть ненулевой шанс, что его задепрекейтят в ближайший год.
Но ещё не применили — «Sit tight! We’re in the process of upgrading your account to unlimited private repositories».
А скорость работы вы тестировали?
> v8 не оптимизирует код внутри with
Уже неверно. TurboFan оптимизирует функции с with. А до TurboFan — не «внутри with», а «содержащий with».
И да, мне не очень нравится идея — так сложнее отслеживать зависимости модулей, хуже ясно что чего использует, плохо видна структура проекта.
Да, это можно исправить «соглашениями об именовании», но эти соглашения об именовании в таком случае должны в себя включать перечисление используемых модулей в шапке файла. То есть как раз то, от чего вы и избавились.
Тут, кстати, два момента.
Первый — открытый ключ идёт через сервер, так что сервер может его вполне подменить — защиты от MitM со стороны сервера тут, очевидно, нет.
Второй — «специальный криптографический алгоритм» почти наверняка просто передёт приватный ключ (каким образом — не столь важно) по указке от сервера. Со всеми вытекающими.