На pg базовое время выполнения оптимального для mysql запроса
А оптимального для mysql?
Я ни в коем случае не пытаюсь похвалить mysql, я просто хочу сказать, что есть случаи, когда возможность корректного scale out (и внезапно здесь в этой роли mysql) важнее возможности scale up и перфоманса одной конкретной ноды.
Имхо, мне кажется тут самый главный затык именно в репликации. В реляционках оно исторически сложнее по многим причинам, и если в MySQL репликация действительно лучше, стабильнее и "правильнее" чем в Postgre, то еще очень большой вопрос что лучше -30% на ноду из-за странного оптимизатора (проценты), или невозможность распределять корректно чтения в кластер (разы).
Рискну словить минусов, но почему не док-станция к современному макбуку с нормальной клавиатурой, отличным экраном и прекрасной автономность, который умеет usb type-c? Ну кроме того, что макбуки — это для нежных девочек, а взрослые половозрелые админы предпочитают корпус из бетона марки M600?
Строить с нуля ноутбук настолько нишевый и нафаршированный интерфейсами — определенно нереальная с экономической точки зрения задача. И технически не самая простая (там вот про пылевлагозащиту уже упоминали).
А вот убер-переходник, который одни проводом подключается по usb type-c, а с другой изобилирует всем невероятным спектром интерфейсов — уже выглядит как даже для наколенного производства посильная задача.
Кстати, про косяки дизайна гита. У меня тоже был исключительно положительный опыт с Mercurial, пока не случилось так, что пришлось пользоваться гитом. Мыши плакали, кололись, а потом почитали инструкцию и немного о том, как он внутри устроен. И косяки дизайна уже не выглядят такими уж и косяками. WAT-ов конечно хватает, но не так всё страшно на самом деле ( кроме git checkout -b разумеется :) )
у hg была "проблема" (надеюсь починили давно) с тем, что в нём нельзя отслеживать удалённые ветки из других репозиториев. Только репозитории целиком.
Для home brew разработки это ни разу не проблема, а вот для более взрослой — уже сложнее.
Опять же, были некие костыли которые решали проблему, но уже не помню деталей.
Хотя Mercurial нежно люблю за его человеко-ориентированный интерфейс :)
Ох, если бы в распределенных системах всё было так просто.
Во-первых, нужно понимать, что практически всегда распределённые коммуникации в разы затратнее централизованных. Если в централизованных для передачи единицы данных необходимо выполнить одну посылку (условно один tcp пакет по установленному соединению), то в распределенных средах нужно сразу озадачиваться роутингом, надёжным релеем (вы же не хотите передавать данные кредитной карты через хакера Васю), и подтверждением доставки. Кстати, внезапно, часть этих проблем решена в TCP.
Во-вторых скорость и стабильность передачи данных. Благодаря сильно неоднородной среде добиться приемлемой скорости коннекта будет крайне сложно. Если где-то на 33-м хопе от меня до вас у пользователя села его нокия, то увы, придётся подождать либо обратного распространения ошибки (а оно еще и может не дойти обратно:) ), либо таймаута, либо сигнального костра.
Ну и самое главное, в-третьих, интернет и сейчас работает примерно схожим образом.
Вообще, велкам в мир распределённых систем. Здесь очень весело :)
Ну вот еще раз скажу, вопрос у вас не про CI, а про то как вы проект собираете. CI — это просто автоматический билд-инженер, которые делает ровно то, что мог бы сделать разработчик, только ему лень делать это на каждый чих, а CI понятие "лень" неведомо.
Т.е. если у вас разработчик руками после изменения прогоняет только некоторый сабсет тестов — то же самое должен делать и CI.
CI — это не абы какая магия. С переменным успехом он прекрасно заменяется хуком в гите (не надо так делать конечно).
Ну это же не про CI вопрос, а про то как вы вообще разрабатываете.
Разработчик поправил пару строчек кода и дальше ждёт 3-4 часа чтобы как-то увидеть не допустил ли он опечатку? Есть подозрение что нет.
Вот и с CI то же самое. Инкрементальные билды, или проект на части надо резать и тестировать отдельные изменения.
Ну а полный ребилдолл уже конечно как-то по расписанию по ночам или ближе к релизу, или как у вас это происходит обычно.
Имхо, это один из вариантов "преждевременная оптимизация — корень всех зол".
Далеко не всегда однозначно можно сказать, что C нужно выделять. Кроме того, нужно понимать, что выделение C — это не столько про скорость разработки (это надо еще подумать, что быстрее — копипаста или унести кусок функционала в отдельный класс/модуль), а про стоимость поддержки.
Соответственно, вариант "пишем в лоб два куска со сходным функционалом, не гнушаясь копипастой — проверяем боем — оптимизруем/реорганизуем" вполне себе годный вариант, который благодаря фазе "проверяем боем" отлично покажет есть ли смысл выносить C, да и вообще, есть ли это общее C.
Разумеется, это не касается совсем уж очевидных случаев, когда декомпозиция понятна заранее.
Забавный нюанс, не знал и в дикой природе не встречал ни разу (к счастью?). Но если немного поразмыслить, то a и b имеют немного разное поведение. Мне вот например не кажется очевидным, что во всех случаях надо ловить исключение, которое происходит в функции, промис из которой я возвращаю (function a).
В данном случае более чем несёт. При return await промис, созданный getFullPost, будет заполнен массивом с двумя значениями, а без return будет заполнен undefined.
Нет, разницы никакой нет. return await "дождется" результата Promise.all и "завернёт" его в промис, return ничего ждать не будет и сразу вернёт промис.
В кавычках, потому что это чуть иначе работает на самом деле, но смысл именно такой.
вернет системный промис, если немного не постараться. А на системных промисах некоторых bluebird-специфичных вещей нет. И когда не знаешь про это (а дебагер и то и другое показывает как Promise), то самый первый дебаг получается увлекательный.
Что-то не то с названием. Мне кажется, что когда пишут "магия внутри", то в статье будет про то, как это внутри работает (а там довольно интересные дела внутри с точки зрения оптимизации происходят), а не вольный пересказ api reference.
Внутри докера linux ( и вроде windows с недавних пор). Поэтому если цель — проверить, собирается ли проект на всех трёх платформах, то только виртуалки, если нужна макось.
А оптимального для mysql?
Я ни в коем случае не пытаюсь похвалить mysql, я просто хочу сказать, что есть случаи, когда возможность корректного scale out (и внезапно здесь в этой роли mysql) важнее возможности scale up и перфоманса одной конкретной ноды.
Имхо, мне кажется тут самый главный затык именно в репликации. В реляционках оно исторически сложнее по многим причинам, и если в MySQL репликация действительно лучше, стабильнее и "правильнее" чем в Postgre, то еще очень большой вопрос что лучше -30% на ноду из-за странного оптимизатора (проценты), или невозможность распределять корректно чтения в кластер (разы).
Рискну словить минусов, но почему не док-станция к современному макбуку с нормальной клавиатурой, отличным экраном и прекрасной автономность, который умеет usb type-c? Ну кроме того, что макбуки — это для нежных девочек, а взрослые половозрелые админы предпочитают корпус из бетона марки M600?
Строить с нуля ноутбук настолько нишевый и нафаршированный интерфейсами — определенно нереальная с экономической точки зрения задача. И технически не самая простая (там вот про пылевлагозащиту уже упоминали).
А вот убер-переходник, который одни проводом подключается по usb type-c, а с другой изобилирует всем невероятным спектром интерфейсов — уже выглядит как даже для наколенного производства посильная задача.
Кстати, про косяки дизайна гита. У меня тоже был исключительно положительный опыт с Mercurial, пока не случилось так, что пришлось пользоваться гитом. Мыши плакали, кололись, а потом почитали инструкцию и немного о том, как он внутри устроен. И косяки дизайна уже не выглядят такими уж и косяками. WAT-ов конечно хватает, но не так всё страшно на самом деле ( кроме
git checkout -bразумеется :) )у hg была "проблема" (надеюсь починили давно) с тем, что в нём нельзя отслеживать удалённые ветки из других репозиториев. Только репозитории целиком.
Для home brew разработки это ни разу не проблема, а вот для более взрослой — уже сложнее.
Опять же, были некие костыли которые решали проблему, но уже не помню деталей.
Хотя Mercurial нежно люблю за его человеко-ориентированный интерфейс :)
Ох, если бы в распределенных системах всё было так просто.
Во-первых, нужно понимать, что практически всегда распределённые коммуникации в разы затратнее централизованных. Если в централизованных для передачи единицы данных необходимо выполнить одну посылку (условно один tcp пакет по установленному соединению), то в распределенных средах нужно сразу озадачиваться роутингом, надёжным релеем (вы же не хотите передавать данные кредитной карты через хакера Васю), и подтверждением доставки. Кстати, внезапно, часть этих проблем решена в TCP.
Во-вторых скорость и стабильность передачи данных. Благодаря сильно неоднородной среде добиться приемлемой скорости коннекта будет крайне сложно. Если где-то на 33-м хопе от меня до вас у пользователя села его нокия, то увы, придётся подождать либо обратного распространения ошибки (а оно еще и может не дойти обратно:) ), либо таймаута, либо сигнального костра.
Ну и самое главное, в-третьих, интернет и сейчас работает примерно схожим образом.
Вообще, велкам в мир распределённых систем. Здесь очень весело :)
Ну вот еще раз скажу, вопрос у вас не про CI, а про то как вы проект собираете. CI — это просто автоматический билд-инженер, которые делает ровно то, что мог бы сделать разработчик, только ему лень делать это на каждый чих, а CI понятие "лень" неведомо.
Т.е. если у вас разработчик руками после изменения прогоняет только некоторый сабсет тестов — то же самое должен делать и CI.
CI — это не абы какая магия. С переменным успехом он прекрасно заменяется хуком в гите (не надо так делать конечно).
Ну это же не про CI вопрос, а про то как вы вообще разрабатываете.
Разработчик поправил пару строчек кода и дальше ждёт 3-4 часа чтобы как-то увидеть не допустил ли он опечатку? Есть подозрение что нет.
Вот и с CI то же самое. Инкрементальные билды, или проект на части надо резать и тестировать отдельные изменения.
Ну а полный ребилдолл уже конечно как-то по расписанию по ночам или ближе к релизу, или как у вас это происходит обычно.
Flow очень правильная штука с очень грустным туллингом и процессом разработки. Настолько грустным, что тайпскрипт, похоже, победил. А жаль.
Вот эти?
Имхо, это один из вариантов "преждевременная оптимизация — корень всех зол".
Далеко не всегда однозначно можно сказать, что C нужно выделять. Кроме того, нужно понимать, что выделение C — это не столько про скорость разработки (это надо еще подумать, что быстрее — копипаста или унести кусок функционала в отдельный класс/модуль), а про стоимость поддержки.
Соответственно, вариант "пишем в лоб два куска со сходным функционалом, не гнушаясь копипастой — проверяем боем — оптимизруем/реорганизуем" вполне себе годный вариант, который благодаря фазе "проверяем боем" отлично покажет есть ли смысл выносить C, да и вообще, есть ли это общее C.
Разумеется, это не касается совсем уж очевидных случаев, когда декомпозиция понятна заранее.
А можно подробнее про родовые травмы moment.js ?
Забавный нюанс, не знал и в дикой природе не встречал ни разу (к счастью?). Но если немного поразмыслить, то
aиbимеют немного разное поведение. Мне вот например не кажется очевидным, что во всех случаях надо ловить исключение, которое происходит в функции, промис из которой я возвращаю (function a).Но пример годный :)
А тут чуть хитрее:
Promise<Promise<A>> === Promise<A>Нет, разницы никакой нет.
return await"дождется" результатаPromise.allи "завернёт" его в промис,returnничего ждать не будет и сразу вернёт промис.В кавычках, потому что это чуть иначе работает на самом деле, но смысл именно такой.
Да, стандарт требует одинакового поведения для
{...a, ...b}иObject.assign({}, a, b)Более того,
return awaitсчитается антипаттерном, ибо не несёт никакого смысла.Можно, но не совсем прямо. Например конструкция
вернет системный промис, если немного не постараться. А на системных промисах некоторых bluebird-специфичных вещей нет. И когда не знаешь про это (а дебагер и то и другое показывает как
Promise), то самый первый дебаг получается увлекательный.Что-то не то с названием. Мне кажется, что когда пишут "магия внутри", то в статье будет про то, как это внутри работает (а там довольно интересные дела внутри с точки зрения оптимизации происходят), а не вольный пересказ api reference.
Внутри докера linux ( и вроде windows с недавних пор). Поэтому если цель — проверить, собирается ли проект на всех трёх платформах, то только виртуалки, если нужна макось.