ваша концепция LIVIR очень похожа на то, что я хотел от валидации на JS с год назад. я ничего стоящего не нашёл тогда и в итоге написал свой велосипед который очень похож на ваш, но работает только на js и обладает (пока) меньшим функционалом.
вопрос: можно ли в LIVIR сделать так чтобы поле валидировалось только при определённых условиях? например, валидировать email только если пользователь подписался на рассылку. в моём велосипеде это делается как-то так:
const {
validate,
util: { when },
rules: { isBoolean, isEmail }
} = require('yeval');
const optedInForNewsletter = (value, data) => data.optedInForNewsletter === true;
validate(
// declare rules as first argument
{
optedInForNewsletter: isBoolean,
email: when(optedInForNewsletter, isEmail),
},
// pass data as second argument
{ optedInForNewsletter: true }
)
.then(errors => {
console.log(errors); // { email: 'Must be a valid email address' }
});
если честно, я совсем профан в оценках трат на сервера. но учитывая, что экономия на серверах складывается из:
— экономии на электричестве
— экономии на рабочих часах обслуживающего персонала (что скорее всего влияет слабо, ибо всё делается автоматически и не зависит от количества серверов)
— единоразовой экономии на средствах на закупку железа (что тоже ничтожно в контексте хотя бы года работы сервиса)
, то сомневаюсь, что они на электричестве сэкономили 1-100 миллионов долларов.
нет, не понимаю. спасибо, что объяснили. но судя по release history, версия 2.0 вышла в 2000 году, а версия 2.3 вышла в 2003. с тех пор прошло больше лет, чем питон существовал без GC.
ещё стоит учесть что с годами софта пишется всё больше, так что импакт доGCшного питона на инстаграм в той части, которую затрагивают эти хаки ничтожен. сомневаюсь, что какой-то используемый ими код дожил с 2003 до 2017 без изменений.
сдаётся мне, они этим шагом ещё и повысили минимальную квалификацию программиста, работающего с их code base до уровня «выше некуда». просто senior уже не канает. ибо имея такие хаки в коде не наступить на грабли становится всё труднее. так что потенциальных рисков они себе добавили ого-го, дело не только в зависимостях.
если честно, для меня выглядит как «мы потратили вагон человеко-часов и поставили под угрозу стабильность системы для того чтобы платить на 10% меньше за сервера».
конечно, в случае инстаграмма 10% экономии на серверах может стоить десятки/сотни тысяч долларов в месяц, но сколько капитализации они потеряют если их сервис упадёт на пару часиков потому что какая-нибудь dependency будет делать неочевидные вещи в деструкторе своих классов? как отмечается выше, своими действиями они выпилили защиту от такого рода проблем убрав вызов GC в finalize().
за деньги людей, которые согласовывают/меняют/утверждают иконки можно нанять хоть сколько-то программистов, которые действительно сделают продукт лучше.
почему фигня? галактика удаляется всё быстрее не потому, что она сама набирает скорость, а потому что само пространство расширяется между нами и ней. и чем больше между нами пространства, тем на большую линейную величину оно суммарно расширяется в единицу времени.
насколько я понимаю, все важные кнопочки приземления выполнены в виде хардварных тумблеров. а интерфейс на хтмл — для разного рода научных программ и прочих тестов в невесомости.
могу ещё посоветовать поиграть в q3. там за время пока ты делаешь rocket-jump, противник успевает появиться на экране, сожрать power-up, на который ты делаешь rocket-jump и ускакать дальше.
вопрос: можно ли в LIVIR сделать так чтобы поле валидировалось только при определённых условиях? например, валидировать email только если пользователь подписался на рассылку. в моём велосипеде это делается как-то так:
если вдруг нет, то вам вот сюда.
— экономии на электричестве
— экономии на рабочих часах обслуживающего персонала (что скорее всего влияет слабо, ибо всё делается автоматически и не зависит от количества серверов)
— единоразовой экономии на средствах на закупку железа (что тоже ничтожно в контексте хотя бы года работы сервиса)
, то сомневаюсь, что они на электричестве сэкономили 1-100 миллионов долларов.
ещё стоит учесть что с годами софта пишется всё больше, так что импакт доGCшного питона на инстаграм в той части, которую затрагивают эти хаки ничтожен. сомневаюсь, что какой-то используемый ими код дожил с 2003 до 2017 без изменений.
конечно, в случае инстаграмма 10% экономии на серверах может стоить десятки/сотни тысяч долларов в месяц, но сколько капитализации они потеряют если их сервис упадёт на пару часиков потому что какая-нибудь dependency будет делать неочевидные вещи в деструкторе своих классов? как отмечается выше, своими действиями они выпилили защиту от такого рода проблем убрав вызов GC в finalize().
вы хотите зачем-то знать state дочерних компонентов? зачем использовать refs для того, чтобы читать this.state?
medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.fz5k5xx7j