Не могу не упомянуть мойру (https://moera.org), в разработке которой я участвую. У каждого пользователя свой сервер который держит его данные и ключи, а клиент живёт отдельно. Можно поднять всю инфраструктуру (сервера пользователей, аналог днса для нахождения серверов пользователей и клиент) у себя в сколь угодно закрытой сети.
Пока автор (не я) бесплатно хостит всех желающих у себя, но часть хостит свои ноды отдельно, и обычному пользователю это полностью прозрачно.
Всё же unspecified это не то же undefined. Первое это "мы не обещаем что получится", а второе "у вас всё поломалось и не будет работать больше никогдаа". То есть так делать можно но стандарт не обещает вам что получится то, что вы хотите.
я в нём делаю домашки для универа, мне удобно. первый редактор который я нашёл который работает с панелькой дополнения как например intellij. пойду может попробую, что тут в каментах предлагают.
сейчас в котлине очень отдельная своя модель асинхронности через suspendable функции которая совместима со всеми promise-like фреймворками для java (включая java-8 futures). но сейчас в джаве хотят сделать какую-то свою асинхронность которая магически сделает уже написанный код асинхронным (думаю не совсем так, сам не слежу, но рекламировалось похоже).
подходы явно будут разные и нельзя так легко сказать какой круче.
возможно именно это место в итоге не создаст проблем, ну так потом что-то другое создаст.
вот насколько я люблю котлин (а я его очень люблю), по сути проблема синхронизации с "родительским" языком правда может наступить в любой момент. например когда в джаве допилят наконец новую модель асинхронности, в котлине на JVM их внезапно станет две. но при этом:
нельзя просто не взять из джавы новую асинхронность, так недолго и перестать быть better java, а котлину (пока) важна эта связь
нельзя взять джавовскую взамен своей - поломаешь весь старый котлин код
и в общем нельзя просто оставить сразу две - так получается два принципиально разных способа делать одно и то же (привет проблемы джавы), но при этом только на одной из платформ котлина, что ещё хуже.
понятно, что можно найти компромисс, и в каждом случае есть сдерживающие факторы которые не дадут всему взять и развалиться. но со временем различия и несоответствия будут накапливаться. это не говорит, что котлин это плохо, и давайте вернёмся на джаву - это просто проблемы которые придётся решать рано или поздно. например как раст, но возможно это и не лучший способ.
и котлин здесь не самый особенный, у тайпскрипта тут похожие проблемы хотя и менее выраженные.
Не знаю как с точки зрения процессов, но на практике это удобно когда есть или большой кусок бизнес логики который никак не разобъёшь или нужно отдебажить/отрефакторить большой комок легаси кода - короче в любом случае когда все подробности не влезут в оперативку одному человеку. По моему опыту очень классно один за клавиатурой, другой за мышкой. Если достаточно хорошо говорить друг с другом, то в какой-то момент попадаешь на одну волну и начинаешь заканчивать действия друг друга.
Ну и понятно, что в любой момент у кого-то может выскочить идея которую проще попробовать чем объяснить - тогда можно на минуту отобрать управление, попробовать, а потом уже объяснять в чём суть. Разумеется, партнёра надо предупредить, что ты это делаешь))
так же как в xml, городить свой огород поверх или парсить из строки.
просто json ближе к нативным структурам распространённых языков программирования (java, js, c/c++, python, go - you name it) так что в среднем по больнице боли от него меньше. а так и бинарные блобы бывает нужно по сети гонять и парсить строки вообще без структуры - json не супер инструмент, он просто обычно удобнее xml.
UPD: для передачи данных по сети в среднем удобнее, задачи бывают разные. например fb2 прекрасен не вопреки а благодаря xml.
Мне кажется, что формально pretty print xml-ей без изменения семантики невозможен,потому что вайтспейсы это текстовые ноды как любые другие.
То есть с точки зрения прикладной логики они могут не иметь значения, но тогда их надо обрабатывать.
Что лично меня всегда бесило в xml, так это отсутствие встроенных типов. То есть средний парсер не может догадаться где у меня число, а где строка. Я уже не говорю про нахождения списков когда они могут быть только с одним элементом.
Всё это решается или однозначной схемой данных замапленой на нативные объекты ЯП или системой типов поверх xml. Но второе делает ещё менее возможно читать/писать данные самому, а часто отдающая сторона просто этого не делает и хоть иди вешайся. Что касается первого, то оно с любым форматом не всегда возможно/имеет смысл.
То есть json тоже имеет проблемы с типами, просто с более сложными (как дата и время например), но в среднем это решается малой кровью.
P. S. ну а trailing commas нужно, конечно же, разрешить везде. Недостатков у них нет, а польза налицо
Сначала ввели один, потом сказали ойблин, но менять было поздно, так что ввели просто второй который работает как надо :)
А удобен == не как оператор нормального сравнения, а как такое странное сокращение когда в проекте все в курсе. То есть x == nullчитается как isNullOrUndefined(x). Это не прямо хорошо, но это распространённая идеома которая не вредит когда все привыкли. Слава богу x==xкак аналог Number.isNan(x) не многим короче и не получил такого распостранения. Что ещё... Ну все знают +x. Оно настолько распространено, что я сходу и не назову "правильный" способ парсить строку в число. Number(x) кажется?
Ну ещё если знаешь, что у тебя в строках честно-честно только цифры, то пока никто не видит можно написать что-то вроде:
Не, то есть я могу сейчас загнать на пол экрана про историческую перспективу js которая привела нас туда где мы есть. Или про полтора случая когда == правда удобнее === и три с половиной когда автоприведение типов по версии js это удобно.
Но я так и не смог понять, что вас заставило задать этот вопрос именно мне :)
Кстати, под симбианы в своё время была целая культура написания любительских приложений на питоне.
Недавно вынул свой н70 из закромов, там у меня так всё обустроено было: и тебе файл менеджер, и плееры всех форматов, и таск менеджер (я им пользовался вместо стандартного меню приложений), даже эмулятор gba со всеми моими сохранениями.
Отдельно мило, что они до сих пор выпускают телефоны с совместимыми батареями, потому что их "тонкую" зарядку уже никто не делает.
Нет, is и == это аналог == и .equals() из java, а не === и == из js.
В питоне и яве есть сравнение ссылок, а есть семантическое сравнение описываемое для каждого типа отдельно. А в js есть сравнение с приведением типов, а есть с проверкой равности типа.
протокол свой. поверх http(s) разумеется.
Не могу не упомянуть мойру (https://moera.org), в разработке которой я участвую. У каждого пользователя свой сервер который держит его данные и ключи, а клиент живёт отдельно. Можно поднять всю инфраструктуру (сервера пользователей, аналог днса для нахождения серверов пользователей и клиент) у себя в сколь угодно закрытой сети.
Пока автор (не я) бесплатно хостит всех желающих у себя, но часть хостит свои ноды отдельно, и обычному пользователю это полностью прозрачно.
*micro
будь это джава я бы попытался использовать какой-то более параллельный сборщик мусора. для шарпа нет такого?
Всё же unspecified это не то же undefined. Первое это "мы не обещаем что получится", а второе "у вас всё поломалось и не будет работать больше никогдаа". То есть так делать можно но стандарт не обещает вам что получится то, что вы хотите.
я в нём делаю домашки для универа, мне удобно. первый редактор который я нашёл который работает с панелькой дополнения как например intellij. пойду может попробую, что тут в каментах предлагают.
да, спасибо, неудачный пример))
сейчас в котлине очень отдельная своя модель асинхронности через suspendable функции которая совместима со всеми promise-like фреймворками для java (включая java-8 futures). но сейчас в джаве хотят сделать какую-то свою асинхронность которая магически сделает уже написанный код асинхронным (думаю не совсем так, сам не слежу, но рекламировалось похоже).
подходы явно будут разные и нельзя так легко сказать какой круче.
возможно именно это место в итоге не создаст проблем, ну так потом что-то другое создаст.
вот насколько я люблю котлин (а я его очень люблю), по сути проблема синхронизации с "родительским" языком правда может наступить в любой момент. например когда в джаве допилят наконец новую модель асинхронности, в котлине на JVM их внезапно станет две. но при этом:
нельзя просто не взять из джавы новую асинхронность, так недолго и перестать быть better java, а котлину (пока) важна эта связь
нельзя взять джавовскую взамен своей - поломаешь весь старый котлин код
и в общем нельзя просто оставить сразу две - так получается два принципиально разных способа делать одно и то же (привет проблемы джавы), но при этом только на одной из платформ котлина, что ещё хуже.
понятно, что можно найти компромисс, и в каждом случае есть сдерживающие факторы которые не дадут всему взять и развалиться. но со временем различия и несоответствия будут накапливаться. это не говорит, что котлин это плохо, и давайте вернёмся на джаву - это просто проблемы которые придётся решать рано или поздно. например как раст, но возможно это и не лучший способ.
и котлин здесь не самый особенный, у тайпскрипта тут похожие проблемы хотя и менее выраженные.
Не знаю как с точки зрения процессов, но на практике это удобно когда есть или большой кусок бизнес логики который никак не разобъёшь или нужно отдебажить/отрефакторить большой комок легаси кода - короче в любом случае когда все подробности не влезут в оперативку одному человеку. По моему опыту очень классно один за клавиатурой, другой за мышкой. Если достаточно хорошо говорить друг с другом, то в какой-то момент попадаешь на одну волну и начинаешь заканчивать действия друг друга.
Ну и понятно, что в любой момент у кого-то может выскочить идея которую проще попробовать чем объяснить - тогда можно на минуту отобрать управление, попробовать, а потом уже объяснять в чём суть. Разумеется, партнёра надо предупредить, что ты это делаешь))
так же как в xml, городить свой огород поверх или парсить из строки.
просто json ближе к нативным структурам распространённых языков программирования (java, js, c/c++, python, go - you name it) так что в среднем по больнице боли от него меньше. а так и бинарные блобы бывает нужно по сети гонять и парсить строки вообще без структуры - json не супер инструмент, он просто обычно удобнее xml.
UPD: для передачи данных по сети в среднем удобнее, задачи бывают разные. например fb2 прекрасен не вопреки а благодаря xml.
Кстати, сам процесс написания xsd это отдельный род мазохизма :-)
Мне кажется, что формально pretty print xml-ей без изменения семантики невозможен,потому что вайтспейсы это текстовые ноды как любые другие.
То есть с точки зрения прикладной логики они могут не иметь значения, но тогда их надо обрабатывать.
Что лично меня всегда бесило в xml, так это отсутствие встроенных типов. То есть средний парсер не может догадаться где у меня число, а где строка. Я уже не говорю про нахождения списков когда они могут быть только с одним элементом.
Всё это решается или однозначной схемой данных замапленой на нативные объекты ЯП или системой типов поверх xml. Но второе делает ещё менее возможно читать/писать данные самому, а часто отдающая сторона просто этого не делает и хоть иди вешайся. Что касается первого, то оно с любым форматом не всегда возможно/имеет смысл.
То есть json тоже имеет проблемы с типами, просто с более сложными (как дата и время например), но в среднем это решается малой кровью.
P. S. ну а trailing commas нужно, конечно же, разрешить везде. Недостатков у них нет, а польза налицо
Тем более, что в вашем случае после проверки поля scenarioSuccess типы полей response и error сузятся, что не может не радовать.
Так никто и не вводил два))
Сначала ввели один, потом сказали ойблин, но менять было поздно, так что ввели просто второй который работает как надо :)
А удобен
==не как оператор нормального сравнения, а как такое странное сокращение когда в проекте все в курсе. То естьx == nullчитается какisNullOrUndefined(x). Это не прямо хорошо, но это распространённая идеома которая не вредит когда все привыкли. Слава богуx==xкак аналогNumber.isNan(x)не многим короче и не получил такого распостранения. Что ещё... Ну все знают+x. Оно настолько распространено, что я сходу и не назову "правильный" способ парсить строку в число.Number(x)кажется?Ну ещё если знаешь, что у тебя в строках честно-честно только цифры, то пока никто не видит можно написать что-то вроде:
Не, то есть я могу сейчас загнать на пол экрана про историческую перспективу js которая привела нас туда где мы есть. Или про полтора случая когда
==правда удобнее===и три с половиной когда автоприведение типов по версии js это удобно.Но я так и не смог понять, что вас заставило задать этот вопрос именно мне :)
Кстати, под симбианы в своё время была целая культура написания любительских приложений на питоне.
Недавно вынул свой н70 из закромов, там у меня так всё обустроено было: и тебе файл менеджер, и плееры всех форматов, и таск менеджер (я им пользовался вместо стандартного меню приложений), даже эмулятор gba со всеми моими сохранениями.
Отдельно мило, что они до сих пор выпускают телефоны с совместимыми батареями, потому что их "тонкую" зарядку уже никто не делает.
Прекрасно, пресс-релиз перевели чтобы использовать как контент для рекламы совсем другой фирмы
Нет,
isи==это аналог==и.equals()из java, а не===и==из js.В питоне и яве есть сравнение ссылок, а есть семантическое сравнение описываемое для каждого типа отдельно. А в js есть сравнение с приведением типов, а есть с проверкой равности типа.
Кстати, а есть смысл писать
Вроде как
existsработает и с "пустым" селектом