Да-да, сверху выглядит очень круто. А потом начинается обмазывание явным указанием времени жизни, десятком трейтов которые нужно протащить (Debug, Send, Sync, WhoKnowWhatElse), .unwrap()-ы на пустом месте...
Мне тоже понравилась его экосистема и управление памятью. Даже сам процесс сборки можно кастомизировать раст-кодом (build.rs ) - это ж огонь! Но любить раст за то что можно сделать полиморфизм на трейтах вместо интерфейсов - странно.
Немного обобщу: Готовые решения не способны поддержать специфических нужд.
Вообще это встречается везде и всюду, но значительный эффект появляется только на масштабе.
Пример на коленке - захотелось мне прикинуться репликой mysql на rust. Нашлась готовая библиотека, на первый взгляд работает, guid поддерживает - все хорошо.
Начинаешь копаться - библиотека парсит каждое событие во внутреннюю структуру. И событий там много (всякие health-check в 90% случаев). А мне оно вот вовсе не нужно, мне достаточно create/update/delete. Вот и получается, что библиотека в 90% случаев занимается чем-то для меня бесполезным. Хочешь производительности - пиши своё (в данном случае хотя бы делай пулл-реквест).
Пока можно не экономить на таких мелочах - почему бы и нет. Если вдруг придется разворачивать кластер на 1000 машин (что и случается в больших компаниях) - экономия на этих 90% бесполезных событий может стоит 5-10 загруженных ядер.
И это не библиотека плохая. Просто она универсальна и предоставляет максимально полное решение, которое подойдет большинству.
Какая у вас забавная формула для определения количества заказов в день. Я понимаю что она правильная, но какая-то интуитивно-непонятная. Почему не 40000 * 360 / 7?
Собесите разработчика на языке, для которого самый подходящий девиз - "просто бери и пиши бизнес-логику не думая о том как оно работает", и удивляетесь что разработчики не знают как оно работает.
Пока вы теорию учили, они компаниям деньги зарабатывали
Сленг | фандрайзингом | Сперва я подумал что это какая-то шляпа.
Прямая речь | Он сказал следующее - идея ничего не стоит. Важна реализация. Чтобы была реализация, должны быть равноправные отношения партнеров. Тогда у обоих будет мотивация двигаться вперед, не будет никаких обид. Это будет устойчивый союз.
Но дело на самом деле не в грамматике. Дело в стиле написания. Публичные тексты как правило имеют отличную (от другой) стилистику, даже если это персональный блог. Выглядит так, будто это нарезка из телеграм-сообщений для друга. Читать тяжеловато.
Не понятно почему статья в минусах (работа с обратной связью в комментах все топит, но при чем тут статья?)
История довольно детальная и описывает реальный кейс, еще и в недалеком прошлом. Никогда основанием стартапов и не занимался и не планирую, но почитать было интересно. Хоть глазки и кровоточат теперь немного.
Тут будто бы боты набежали рассказывать что в европах никому денег не платят
Для мидла вилка 70-110 в Голландии окладом (это я довольно разные компании взял. В какой-нибудь конкретной вилка поуже будет). + еще 20-30% бонусами Для сеньора на вскидку 90-130
Для германии пониже, для испании наверно еще ниже
Но в статье просто какие-то случайные цифры. Может, для сотрудников поддержки. Может для программистов каких-то не-IT компаний (местный ржд Thylis например)
Достаем из сервис1 список ресурсов, и для каждого ресурса выполняем пайплайн в сервис2. Пайплайн синхронный и состоит из нескольких api-вызовов (условно, resource1/check, resource1/init, resource1/update)
Чтобы не насиловать api сервис2, запускаем пайплайн на N ресурсов параллельно, если для какого-то ресурса пайплайн завершился - может запускать для следующего
Вообще по стечению обстоятельств вот только что обсуждали мой код, где коллега убедительно убедил что использовать семафоры - хорошая затея. Код действительно стал проще.
Правда в моем кейсе на производительность наплевать, так что бонус лично для меня чисто эстетический
Если у вас благодаря посткоммитному ревью time-to-market вырос на неделю, а раз в пол года на 15 минут кладете прод - это ок
Если прод из-за такого падает регулярно - заслуженно надают по шапке
Но у нас получилось выстроить процесс так, что сервис целиком не ложился даже если ну совсем плохо все сделать (canary-deployment, вот это все). В итоге ни единого разрыва за пару лет (из-за посткоммитного ревью. В целом разрывы случались)
Аппрув зачастую часть процессов безопасников и регулярного аудита выкатываемого
Для "не важных кодов" у нас был пайплайн посткоммитного ревью - если ты уверен что это нужно катить, можешь катить. Но за тобой все-равно потом придут и посмотрят, все ли ок. Потому что если не придут и не посмотрят свои - с некоторой вероятностью потом придут смотреть чужие, и будут задавать неприличные вопросики виде "какого хрена"
Пример: Алиса поняла, что Аманда совершила ошибку в аргументации, когда утверждала, что нужно есть здоровую пищу, потому что диетолог сказал, что это популярно. Поэтому Алиса парировала, что нужно есть двойные чизбургеры с беконом каждый день.
А в чем логическая ошибка? Выглядит как хороший ход в дебатах, если доказательство строится на желудях и ветках - то неизвестно, ложно утверждение или истинно
Пример: На колесе рулетки шесть раз подряд выпало красное, поэтому Грег думал, что почти наверняка следующим выпадет черное. При таком мышлении он вскоре потерял все свои сбережения, пострадав от экономической формы естественного отбора.
Какой-то контрпример получился. Статистически парень все делал правильно. Но случилась крупная неудача.
Ошибку выжившего бы ещё сюда. Встречается довольно часто и без всякого злого умысла.
А я видел, отличный специалист. Жаль что сменил работу, надеюсь еще получится с ней вместе поработать
Да-да, сверху выглядит очень круто. А потом начинается обмазывание явным указанием времени жизни, десятком трейтов которые нужно протащить (Debug, Send, Sync, WhoKnowWhatElse), .unwrap()-ы на пустом месте...
Мне тоже понравилась его экосистема и управление памятью. Даже сам процесс сборки можно кастомизировать раст-кодом (build.rs ) - это ж огонь!
Но любить раст за то что можно сделать полиморфизм на трейтах вместо интерфейсов - странно.
Немного обобщу:
Готовые решения не способны поддержать специфических нужд.
Вообще это встречается везде и всюду, но значительный эффект появляется только на масштабе.
Пример на коленке - захотелось мне прикинуться репликой mysql на rust. Нашлась готовая библиотека, на первый взгляд работает, guid поддерживает - все хорошо.
Начинаешь копаться - библиотека парсит каждое событие во внутреннюю структуру. И событий там много (всякие health-check в 90% случаев). А мне оно вот вовсе не нужно, мне достаточно create/update/delete. Вот и получается, что библиотека в 90% случаев занимается чем-то для меня бесполезным. Хочешь производительности - пиши своё (в данном случае хотя бы делай пулл-реквест).
Пока можно не экономить на таких мелочах - почему бы и нет. Если вдруг придется разворачивать кластер на 1000 машин (что и случается в больших компаниях) - экономия на этих 90% бесполезных событий может стоит 5-10 загруженных ядер.
И это не библиотека плохая. Просто она универсальна и предоставляет максимально полное решение, которое подойдет большинству.
Так. И каким боком тут вообще хадуп и спарк?
Хороший поинт про "быстро въехать в тему"
Сам купил недавно курс по разработке потому что "а почему бы и нет":
появилось комьюнити в которое я могу задавать вопросы по технологии
мне потихоньку объясняют что же под капотом значат те слова, которые я использую в пет-проджектах "чтобы работало"
погружение в среду - люди что-то спрашивают, становится интересно, читаешь, гуглишь - учишься понемногу
(10 лет в разработке, становиться сеньором за пол года необходимости нет)
Тоже об этом сразу подумалось. А если публиковать в rabbit, то и партиционированием не нужно будет управлять
Есть более стандартные решения, которые автоматически раскладывают твой конфиг из репозитория по всем тачкам паппетом
Но эта история не сильно лучше, потому что потом на хосте нужно поработать под рутом - и привет
Так что проще привыкнуть к дефолтному поведению, навесив минимум рюшек для основного кейса (синтаксис там подсветить, строчки показать)
Какая у вас забавная формула для определения количества заказов в день. Я понимаю что она правильная, но какая-то интуитивно-непонятная. Почему не 40000 * 360 / 7?
Так конкурентное преимущество или пустая трата времени?
Собесите разработчика на языке, для которого самый подходящий девиз - "просто бери и пиши бизнес-логику не думая о том как оно работает", и удивляетесь что разработчики не знают как оно работает.
Пока вы теорию учили, они компаниям деньги зарабатывали
Сленг
| фандрайзингом
| Сперва я подумал что это какая-то шляпа.
Прямая речь
| Он сказал следующее - идея ничего не стоит. Важна реализация. Чтобы была реализация, должны быть равноправные отношения партнеров. Тогда у обоих будет мотивация двигаться вперед, не будет никаких обид. Это будет устойчивый союз.
Но дело на самом деле не в грамматике. Дело в стиле написания. Публичные тексты как правило имеют отличную (от другой) стилистику, даже если это персональный блог. Выглядит так, будто это нарезка из телеграм-сообщений для друга. Читать тяжеловато.
Не понятно почему статья в минусах (работа с обратной связью в комментах все топит, но при чем тут статья?)
История довольно детальная и описывает реальный кейс, еще и в недалеком прошлом. Никогда основанием стартапов и не занимался и не планирую, но почитать было интересно. Хоть глазки и кровоточат теперь немного.
Тут будто бы боты набежали рассказывать что в европах никому денег не платят
Для мидла вилка 70-110 в Голландии окладом (это я довольно разные компании взял. В какой-нибудь конкретной вилка поуже будет). + еще 20-30% бонусами
Для сеньора на вскидку 90-130
Для германии пониже, для испании наверно еще ниже
Но в статье просто какие-то случайные цифры. Может, для сотрудников поддержки. Может для программистов каких-то не-IT компаний (местный ржд Thylis например)
Джсоны перекладываем...
Достаем из сервис1 список ресурсов, и для каждого ресурса выполняем пайплайн в сервис2.
Пайплайн синхронный и состоит из нескольких api-вызовов (условно,
resource1/check,resource1/init,resource1/update)Чтобы не насиловать api сервис2, запускаем пайплайн на N ресурсов параллельно, если для какого-то ресурса пайплайн завершился - может запускать для следующего
Не то чтобы семафоры были изобретены только что https://pkg.go.dev/golang.org/x/sync/semaphore
Вообще по стечению обстоятельств вот только что обсуждали мой код, где коллега убедительно убедил что использовать семафоры - хорошая затея. Код действительно стал проще.
Правда в моем кейсе на производительность наплевать, так что бонус лично для меня чисто эстетический
Никто ж не указывал кто именно должен нарушить
Попытка присвоения товарного знака произошла? Произошло. Значит аккаунт можно отжимать!
Ну, фигня случается. Это ж все меряется деньгами.
Если у вас благодаря посткоммитному ревью time-to-market вырос на неделю, а раз в пол года на 15 минут кладете прод - это ок
Если прод из-за такого падает регулярно - заслуженно надают по шапке
Но у нас получилось выстроить процесс так, что сервис целиком не ложился даже если ну совсем плохо все сделать (canary-deployment, вот это все). В итоге ни единого разрыва за пару лет (из-за посткоммитного ревью. В целом разрывы случались)
Аппрув зачастую часть процессов безопасников и регулярного аудита выкатываемого
Для "не важных кодов" у нас был пайплайн посткоммитного ревью - если ты уверен что это нужно катить, можешь катить. Но за тобой все-равно потом придут и посмотрят, все ли ок. Потому что если не придут и не посмотрят свои - с некоторой вероятностью потом придут смотреть чужие, и будут задавать неприличные вопросики виде "какого хрена"
Пример: Алиса поняла, что Аманда совершила ошибку в аргументации, когда утверждала, что нужно есть здоровую пищу, потому что диетолог сказал, что это популярно. Поэтому Алиса парировала, что нужно есть двойные чизбургеры с беконом каждый день.
А в чем логическая ошибка? Выглядит как хороший ход в дебатах, если доказательство строится на желудях и ветках - то неизвестно, ложно утверждение или истинно
Пример: На колесе рулетки шесть раз подряд выпало красное, поэтому Грег думал, что почти наверняка следующим выпадет черное. При таком мышлении он вскоре потерял все свои сбережения, пострадав от экономической формы естественного отбора.
Какой-то контрпример получился. Статистически парень все делал правильно. Но случилась крупная неудача.
Ошибку выжившего бы ещё сюда. Встречается довольно часто и без всякого злого умысла.
Для таких случаев будет кстати вспомнить find и grep, чтобы не вытаскивать по директории из автодополнения)