Pull to refresh
-12
0
Юрий @YChebotaev

Фронтенд разработчик

Send message
Юлмарт, ситилинк и вилдберис делают приличные деньги, потому что они вкладывают бешеные деньги в каналы привлечения клиентов и осознанно занимаются анализом и оптимизацией конверсии.
Посмотрите на старые версии юлмарта и ситилинка (вилдберис исключен из индекса), и увидите, что дело не в продукте.
Очень сложно предсказать такого рода экономию точно. То есть, опытному программисту очевидео, что одно решение приведет к проблемам в будущем, а другое — нет. Это скорее личный опыт и интуиция, нежели строгие расчеты и теорвер.
Действительно, единственный адекватный подход к защите от чего угодно — это закрыть все векторы атак. А можно просто не позволять пользователю передавать на сервер ничего, что может быть исполнено в браузере (ну и, соответственно, не выполнять на сервере ничего, что было прислано пользователем).
Скорее, от msgpack-а.
Да, каюсь, это я не внимательно прочитал, думал, что речь идет о вообще любых типах.

Чуть выше уже ответил: речь об удобстве чтения формата человеком.
А никак. Единственное полезное, что можно сделать с полем _id — это прочитать его, и, в крайнем случае, сконструировать новый такой же объект:
ObjectId(data._id)


Понятно, что вы это делаете без особого смысла, но по пути вы потеряли очень полезное, на мой взгляд, свойство JSON-а: человекочитаемость.
Один способ, как сохранить это свойство и передать тип я уже назвал. Только что придумал еще один:
{
    "_id": ["objectid", "562d2063bc0f12de6a000001"],
    "array": ["array", []]
}

{
  "": ["null"]
}


Не так сильно раздувается размер, и не так сильно страдает читаемость.
Я думаю потому, что приведенное решение не только не нормально, но еще и поставленную вами же задачу не решили.
Вы решали задачу, как представить в JSON произвольные типы, но получилось у вас только усложнить синтаксис, а произвольные типы все еще представить не удалось (корежить человекопонятный жисон, и все равно передавать не тип, а строку — это не решение).

Встроить в жисон интерпретатор брейнфака, и декодировать им значения — отличная идея. Превращать старый добрый словарь в массив объектов — нет.
Только вот
ObjectId("562d2063bc0f12de6a000001").str === "562d2063bc0f12de6a000001"


Cледовательно,
{
  "_id": "562d2063bc0f12de6a000001"
}


И никакой магии.

Но уж если хочется странного, то логичнее:

{
  "_id": {"$objectid": "562d2063bc0f12de6a000001"}
}


Тогда будет много проще написать свой сериализатор/десериализатор как функцию второго аргумента JSON.stringify(value[, replacer[, space]])/JSON.parse(text[, reviver]).
Готов взяться за проект.

Планы развития такие:
— Автоопределение языка для разметки синтаксиса,
— Исходные текст копировать в буфер обмена по кнопке,
— Загрузка и выгрузка текстовых файлов,
— Приватная безопасность по-умолчанию,
— Опциональная стеганография в картинку.

Уверен, что эти фичи сделают проект достаточно отличным от зарубежного аналога и сервис займет свою нишу.
Попробуйте описать вашу проблему более подробно в трекере, уверен, что команда проекта уделит этой проблеме внимание, мне было бы самому интересно узнать правильный ответ, почему так происходит.
Довольно странно, на самом деле. Если вы запускали кластер на нескольких независимых машинах, и писали поочередно то в один, то в другой инстанс, то это должно было бы увеличить производительность инсертов. Вы не написали, что именно таким образом пробовали делать.
Ну а так, да, особой производительностью rethinkdb не блещет, но я лично никогда и не рассматривал ее как замену mongodb.
А какая настройка durability у вас? Если hard, то ничего удивительного, а вот если soft, то хотелось бы чуть подробнее узнать о вашей установке: вы пишете в один инстанс, или в разные?
Хорошее решение. Но в ресинке мне больше всего нравится именно безболезненное масштабирование и более высокая надежность. Ну и еще джоины: не нужно городить огород, чтобы вытащить из базы с целью анализа необходимые данные, как в случае с более популярными бд.
Ну и если бы в ней не было обновлений, то такая же фича есть у редиса, да и не проблема настроить какое-нибудь другое решение, например, nsq.
Отличная база данных, рекомендую. Больше всего, по сравнению с остальными NoSQL базами радует наличие традиционных джоинов, легкое масштабирование, язык запросов гораздо приятнее SQL, и простота в настройке и обслуживании.
А вот рекламируемые в статье функции по уведомлению об изменениях, на мой взгляд, далеко не главное достоинство, скорее прилепили, чтобы было, а потом сделали на этой фиче маркетинговый акцент.
Возможно, вы это имели в виду, но написали другое. В моем случае все ровно так как вы написали, но с противоположным знаком. «Мне не задали ни одного вопроса, чтобы проверить, что я действительно знаю своё дело.». Не могу утверждать наверняка, но, возможно, если бы такие вопросы задали, это бы повлияло на итог. А так получается, по каким-то формальным признакам отбраковка, как будто бы на работу принимают не живого человека, а резюме.

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

Что касается моего резюме, то что делать, если я действительно все, что у меня там указано, продуктивно применял, умею с этим работать, и могу сделать с места в карьер то, чего еще не делал? Строчка «все умею, все могу», ироничная, разумеется, но и во многом правдива.
Повторюсь. Я не жалуюсь на то, что не подошел для вакансии, я думаю, что это нормально — подходить не везде.
А вот ваша статья, размещенная в блоге компании явно не соответствует принятой в вашей же компании практике:
Вот например, 1. «Какое ещё техническое собеседование?». Со мной не проводили технического собеседования.
Пункт 2. «Ну и чем вы там занимались в этом своём…». Технического специалиста явно оторвали от очень важных дел, и всем своим видом он показал, что тратит напрасно свое время.
Пункт 5. «Неправильно. Дальше.». Выслушав мой рассказ о том, где я работал и что делал (что и так было написано в резюме), ваш технический специалист просто выгнал меня, даже не обмолвившись почему я, в итоге, не подхожу.
Проблема заключается в том, что вакансии составляют тоже не очень разбирающиеся, и требования часто противоречивые и не соответствуют реальности.
Как раз-таки к тому, что мое резюме не соотнесли с вакансией я не жалуюсь. А жалуюсь я на то, что то, что происходило во время интервью прямо противоречит статье в блоге компании за вашим авторством.
У вас так принято — смеяться над резюме соискателей?
Я не знаю, на какую вакансию меня пригласили. Мне это не сообщили, а я понадеялся, раз люди звонят, значит, прочитали резюме и им понравилось то, что они прочитали (можно еще статью дополнить: не говорят, на какую вакансию, и не говорят какие обязанности).
По факту выяснилось, что ни резюме ни читали, ну и почти что все антипаттерны из вашей статьи на этом собеседовании со стороны вашей компании были применены. И, между прочим, это было в екатеринбурге, так, что, скорее всего, прямо в вашем офисе, и я не уверен, что это были не вы.
Вы бы сами для начала своим же статьям следовали.
Извините, конечно, но конкретно в этой компании процесс прохождения резюме построен просто отвратно: вначале hr не прочитал мое резюме и пригласил на собеседование, затем, «технический специалист» — тимлид тоже не удосужился прочитать резюме, да еще и нахамил.

Information

Rating
Does not participate
Location
Екатеринбург, Свердловская обл., Россия
Date of birth
Registered
Activity