Таймураз
Таймураз
загуглите трансорт петербурга, транспорт москвы, казани...
Вы понимаете разницу между движимостью и недвижимостью?
Таймураз
Алексей
В каждом городе свой сервис по продаже? Гоните?)
да при чём тут продажа хотя продажа тоже, возможно, подходит если яндекс недвижимость тоже агрегатор, то данные они берут из нескольких источников и более чем уверен, что источники отдают данные в разных форматах это может быть и json везде, но разный
Kons
Я к тому, что на него накинулись, как будто он против джсона. Я за объективность )
Алексей
Вы уже поискали то, что я вас попросил?
нет речь же изначально шла о транспорте зачем мне искать недвижимость?
Таймураз
Таймураз
Я к тому, что на него накинулись, как будто он против джсона. Я за объективность )
Он говорит, что json не оптимален Я говорю, что жсон стандарт, а для скорости нужно использовать решения, для этого созданные Он продолжает
Таймураз
Я к тому, что на него накинулись, как будто он против джсона. Я за объективность )
Если нужно и на спичках экономить, то CSV тут явно не лидер
CherryTea
Все начиналось так: - "смотрите, расписание на сайт приходит в csv" - "а почему это плохо?" мне кажется уже объяснили почему в данном случае плохо раз этак десяток
Aleksand
Если нужно и на спичках экономить, то CSV тут явно не лидер
текстовый формат не может быть лидером, никак
Таймураз
Но он же спорит
Dmitry
А в каком стандарте прописан json как транспорт?
Dmitry
ну формат
Алексей
Все начиналось так: - "смотрите, расписание на сайт приходит в csv" - "а почему это плохо?" мне кажется уже объяснили почему в данном случае плохо раз этак десяток
я всё-таки думаю, что вам кажется, что вы объяснили по-крайней мере аргументов за использование json кроме того, что "это стандарт" я не услышал
CherryTea
"JSON - текстовый формат, полностью независимый от языка реализации, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других. Эти свойства делают JSON идеальным языком обмена данными."
Kons
JSON такой же формат передачи данных, как и остальные. JSON так же "удобно" собирать/разбирать в не-Java* языках, как и любой другой (xml, csv, protobuf и вот это вот всё). Для JSника удобней на сервера заюзать JSON - факт.
Kons
С тем же успехом можно аргументировать, что кавычка в строке в JSON сломает парсинг.
CherryTea
я всё-таки думаю, что вам кажется, что вы объяснили по-крайней мере аргументов за использование json кроме того, что "это стандарт" я не услышал
для тех кто в танке: в браузере js, туда надо присылать json бай дефолт. Все отальное - для оптимизаций если есть такая потребность. csv не надо прислыать никогда
Таймураз
ну формат
Загуглить?:)
Kons
Напомните, как называется объект, с помощью которого запрашиваются традиционно данные в браузере
Kons
ну а головой подумать
А вот дерзить не надо. Тут не детский сад, когда в случае отсутствия аргументов, можно швырнуть говном.
CherryTea
Где это зафиксированно? Аргументацию, пожалуйста.
это же очевидно, Карл. Браузер тебе предоставляет метод для парсинга json. Смотрите, я и ссылочку вам приготовил https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse
Yuriy
Вы тут джейсон за многословность ругаете, а в том же дотнете стандартом для WCF является SOAP (XML с весьма многословными именами атрибутов и узлов). И вроде ситуация меняться не собирается. ИМХО, всякому инструменту есть своё применение. Безусловно, изначально нет смысла тащить на фронт CSV или протобуфы — но так ровно до тех пор, пока ты действительно не уверен на 100% в необходимости этого. В JS поддерживать джейсоновские апи проще и дешевле — как для бизнеса, так и для разработчиков. В том же дотнете для сервисов (не для общения с фронтом!) я бы брал только XML — это стандарт де-факто, взаимодействие через него отлажено, покрыто тестами и проверено годами использования, пусть он и куда более многословный и тяжелый в сравнении с JSON или чем-то другим. Мне кажется, что вы упускаете момент сложности поддержки апи. Что будет, если из компании уйдет разработчик, который внедрил протобуф для фронта? Сколько месяцев искать ему адекватную замену? Насколько более сложной будет использование вашего апи сторонними консьюмерами? Какую цену они заплатят за внедрение?
Yuriy
(впрочем, я таки соглашусь, что изначальный пример с CSV это боль и грусть, и так делать не стоит)
CherryTea
csv поддержки небыло никогда
Таймураз
Вы тут джейсон за многословность ругаете, а в том же дотнете стандартом для WCF является SOAP (XML с весьма многословными именами атрибутов и узлов). И вроде ситуация меняться не собирается. ИМХО, всякому инструменту есть своё применение. Безусловно, изначально нет смысла тащить на фронт CSV или протобуфы — но так ровно до тех пор, пока ты действительно не уверен на 100% в необходимости этого. В JS поддерживать джейсоновские апи проще и дешевле — как для бизнеса, так и для разработчиков. В том же дотнете для сервисов (не для общения с фронтом!) я бы брал только XML — это стандарт де-факто, взаимодействие через него отлажено, покрыто тестами и проверено годами использования, пусть он и куда более многословный и тяжелый в сравнении с JSON или чем-то другим. Мне кажется, что вы упускаете момент сложности поддержки апи. Что будет, если из компании уйдет разработчик, который внедрил протобуф для фронта? Сколько месяцев искать ему адекватную замену? Насколько более сложной будет использование вашего апи сторонними консьюмерами? Какую цену они заплатят за внедрение?
Вооо А теперь тем, кто оправдывает CSV заменить протобаф на первого в тексте и напомнить, что протобаф эффективнее
Таймураз
Ну ребят Тут не об XML речь идет
Kons
Вы тут джейсон за многословность ругаете, а в том же дотнете стандартом для WCF является SOAP (XML с весьма многословными именами атрибутов и узлов). И вроде ситуация меняться не собирается. ИМХО, всякому инструменту есть своё применение. Безусловно, изначально нет смысла тащить на фронт CSV или протобуфы — но так ровно до тех пор, пока ты действительно не уверен на 100% в необходимости этого. В JS поддерживать джейсоновские апи проще и дешевле — как для бизнеса, так и для разработчиков. В том же дотнете для сервисов (не для общения с фронтом!) я бы брал только XML — это стандарт де-факто, взаимодействие через него отлажено, покрыто тестами и проверено годами использования, пусть он и куда более многословный и тяжелый в сравнении с JSON или чем-то другим. Мне кажется, что вы упускаете момент сложности поддержки апи. Что будет, если из компании уйдет разработчик, который внедрил протобуф для фронта? Сколько месяцев искать ему адекватную замену? Насколько более сложной будет использование вашего апи сторонними консьюмерами? Какую цену они заплатят за внедрение?
Спасибо за аргументированную позицию. Соглашусь с тем, что для любого инструмента - своё применение и свой применитель )
CherryTea
(самое задавное кстати что спор возник в группе по ноде, которым json близок как брат родной. вроде-бы)
Yuriy
На самом деле, поделюсь болью, потому что вопрос нестандартного для JS формата в апи это одна из проблем, которую мне придется скоро решать. Мы пишем систему заказа для аптек, и одними из консьюмеров нашего публичного апи является 1С. Джейсон он умеет понимать только с версии 8.3, а до этого — максимум это как раз-таки приснопамятный SOAP. Учитывая «удобство» работы с XML из JS, я пока что стараюсь всеми силами оттянуть момент реализации нашего API на SOAP — это займет просто до чертиков много времени, а команда не настолько велика, чтобы выделить отдельного человека для поддержки двух вариантов — и JSON, и SOAP.
Aleksand
(самое задавное кстати что спор возник в группе по ноде, которым json близок как брат родной. вроде-бы)
самое забавное что спор возник из-за того что ты слишком вольно именуешь говном все что тебе непривычно или кажется плохим
CherryTea
самое забавное что спор возник из-за того что ты слишком вольно именуешь говном все что тебе непривычно или кажется плохим
мне кажется вы переходите на личности, и повторяетесь. Пора уже потушить что там у вас пылает )
CherryTea
конечно, ведь это ты сказал что они мудаки. а не кто-то.
я сказал что так делать жесть, перечитайте чат. Про мудаков - это ваша интерпретация
CherryTea
дальнешие выяснения отношений, если уж на то пошло, предлагаю перенести в лс
Anonymous
Привет всем, я тут на днях только node начал ковырять. Такой вопрос как деплоят приложения нодовские? Так и запускают через node <script> или вот например как в других язаках типо cgi юзают? Но потоковые сервера тут не решают, так что вопрос такой.
Dmitry
Ну для JSON и правда есть RFC, но это не STD, а значит и стандартом не является как таковым :)
Dmitry
Вот пруфы людям, которым захотят называть его стандартом: https://www.rfc-editor.org/standards
Dmitry
"Internet Standard" - стандарт, остальное - нет
CherryTea
то что его может парсить браузер стандартными методами не делает его стандартом де-факто?
Dmitry
Браузерное API для парсинга не делает не из какого формата стандарт для веба. Парсить оно может все что угодно
Kons
Там выше кажется ответили. Возможно, CSV был выбран потому, что изначально этот АПИ не предназначался для браузера. Возможно, это был формат обмена между каким-то частями каких-то систем.
Kons
Мда... Веб - это только браузеры... Так что ли?
CherryTea
да хватит уже маняврировать
CherryTea
нет это не сигнал из петнтагона и не послание инопланетян
CherryTea
это был ответ от сервера для браузера, и работал с ним js
Kons
Понятно. Спасибо, что объянили.
CherryTea
Понятно. Спасибо, что объянили.
ничего личного, просто уже много раз об этом говорилось
Andrew
а часто вы используете в своем коде ООП? прототипы всякие.
ты их даже если явно не используешь, то косвенно всегда, т.к. в JS прототипное наследование и куда ты от него денешься то? а классы 2015+ это синтаксический сахар поверх прототипов же :)
Anton
Большое спасибо за ответ. А разве мобильная разработка не идет к React Native?
хз, я этим не интересуюсь. но вряд ли, он не годится для задач требующих производительности - игры, гис, потокая обработка медиа... список задач получается довольно узкий и унылый
Anonymous
Привет всем, я тут на днях только node начал ковырять. Такой вопрос как деплоят приложения нодовские? Так и запускают через node <script> или вот например как в других язаках типо cgi юзают? Но потоковые сервера тут не решают, так что вопрос такой.
Gleb
Docker.
доня.
Полный ответ достаточно большой. Но можешь погуглить pm2
двачую pm2, удобнейшая штука, использую не только для ноды
Max
Привет всем, я тут на днях только node начал ковырять. Такой вопрос как деплоят приложения нодовские? Так и запускают через node <script> или вот например как в других язаках типо cgi юзают? Но потоковые сервера тут не решают, так что вопрос такой.
по большому счету так, только все это обернуто в достаточно большой слой всякой хрени типа демонов. Если тебе нужно поднять на боевом сервере, да так чтобы при перезагрузке сервера все заново поднималось без твоего участия, то копай в сторону systemctl
Max
Привет всем, я тут на днях только node начал ковырять. Такой вопрос как деплоят приложения нодовские? Так и запускают через node <script> или вот например как в других язаках типо cgi юзают? Но потоковые сервера тут не решают, так что вопрос такой.
вариант с пм2 плох тем что при перезагрузке серва придется заходить и поднимать все самому. так что пм 2 не вариант для серьезных работ. если свой проектик в стол, то прокатит. Встречал веселый бутерброд (вернее даже работал на этом проекте), где был демонизирован пм2), который в свою очередь уже поднимал ноду. Но после моего вопроса ЭНахуя так сделано у главного программиста вылезли глаза на лоб и он сказал что так делать не надо). До того момента он был не в курсе той каши. в итоге переделали.
Max
довольно много хорошей документации по этому поводу есть на диджидал ошен
Max
ща покопаюсь скину
Max
сам юзаю частенько
Max
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-node-js-application-for-production-on-ubuntu-16-04
Max
вот
Max
но тут с пм2