Ну предположим по ссылке ноутбук не на Intel Core i7-13620H, а на Intel Core i7-1260P. Еще и нераспаянная DDR-4. Еще и этот цифровой блок, из-за которого руки будут сдвинуты влево относительно оси взгляда, неудобно же. Короче я бы выбрал Xiaomi Redmibook свежий, там и память быстрая, и проц актуальный, и экран лучше, и охлаждение выглядит интереснее и аккумулятор почти в 2 раза больше. Разницу в цене в 20к это все более чем перекрывает.
Кошачья кормилка в целом тема рабочая. У меня двойня, один фанат пожрать, вторая нет. Я сделал 2 кормления в день и это такое количество корма, что толстяк не может за один присест столько сожрать (плюс там у меня две миски), поэтому все норм. Плюс две миски дают дополнительную устойчивость, перевернуть стоящий возле стены девайс будет очень сложно.
Поилка тоже более чем норм история. Воды хватает на двоих на неделю. У меня помпа в фонтанчике работает через обычный usb, не такой девайс как на картинке, так что это относительно безопасная история.
Конечно все зависит от котов, однако все это ультраудобно, можно уехать на пару-тройку дней и совершенно не испытывать страх за животных
Тогда и речь нужно вести о client-side базах и server-side, вопрос то не в языке. В браузере то у вас всегда есть IndexedDB (наверное я правильно понял что это, я довольно далек от фронта). А на сервере всегда и везде есть sqllite (и не только на сервере кстати), который уже и JSON довольно продолжительное время поддерживает.
В этом и был мой изначальный вопрос, лично я не вижу проблем, которые решает эта библиотека. Вместо нее можно ограничиться одним контекстным менеджером, который будет открывать файл, преобразовывать в словарь и закрывать-записывать.
При чем здесь синхронный модуль json и параллелизация записи в базу? У вас тут не решена проблема гонок, как ваши парсеры будут одновременно писать в файл?
Для каких целей может понадобиться такая странная библиотека? Пример с парсингом не совсем корректный, потому что запись с помощью вашей библиотеки как минимум не параллелизуется.
В связи с падением зрения, как раз решил заменить 14 дюймов хотя бы на 16, и в этой категории сплошное засилье цифровых блоков. Так сложилось, что все мои ноутбуки, начиная с 2010 года, были без этого волшебного островка. Все думал, кому они нужны, кроме бухгалтеров. Поделитесь пожалуйста, зачем они вам нужны в работе?
Звучит как какая-то узкоспецифичная вещь для вашей компании или как карго-культ. 1. Ну сбор понятен, кто-то всегда должен собрать требований. 2. Какие SRE выдаст опции, такие и подберет. Если в компании стандартный пак в виде прома с графаной, так и будет пром с графаной. Или куда и как все логи сливаются, так оно и будет в большинстве случаев. У SRE уже в любом случае есть система мониторинга как минимум железяк и системных сервисов, типа nginx. А если все развернуто в этих ваших кубернетисах, так тем более. И алерты, для всех них должно быть одно окно. 3. Непонятно о чем речь. Базово у тебя есть хранилища, куда стекаются метрики из разных мест. Есть отображалка, которая читает эти хранилища. Что именно подразумевается? 4. Свой statsd пишем? Или loki? 5. Тоже какие-то довольно общие слова. 6. Организация инфраструктуры для наблюдения за приложением -- это так же прерогатива SRE. 7. Свою графану с кибаной пишем? Или имеется в виду дашики накидать в инструменте? 8. Это что? Организация канала алертинга? Это часть инфраструктуры, это SRE-DevOpsEngineer-SysAdmin-любое другое имя, которое сейчас модно. Накидывание правил для конкретных дашбордов-панелей? Так это должны уметь все, как разработчики, которым надо следить за тем, что их приложение работает правильно, так и продактам, которые хотят следить за бизнес-метриками приложений.
Короче мне все равно непонятно, чем в итоге занимается этот инженер по мониторингу. Я в статье увидел только код, который проверяет доступность клика на странице. Это что-то вроде end-2-end тесткейса? Ок, прогнали вы его на тесте-стейдже-препроде-любое другое имя, которое сейчас модно. Можно даже на проде гонять, хотя по хорошему поломаться это может только при релизе приложения, если процессы разработки и доставки отлажены более-менее правильно.
А что такое этот "специалист по мониторингу"? Это специалист, который развернет необходимую для мониторинга инфраструктуру? Или специалист, который реализует core-компоненты, обеспечивающие прикладных разработчиков инструментарием, с помощью которого будет осуществляться отправка метрик? А возможно это бизнес-аналитик или продакт, который определит, какие отклонения в бизнес-метриках, должны приводить к уведомлениям об инцидентах?
Это и есть самая топовая причина ввода многоэтапных собесов. Отфильтровать тех, кого инфоцыгане натаскали на проход собесов по нужной профе. На тот же фронтенд приходят люди, которые отвечают на все вопросы по теории, но стоит дать задачку из реальности - упс, всё.
Здесь нет аргумента за многоэтапность, но есть аргумент за нормальные задания на собеседовании.
Можно поинтересоваться, там насколько выше рынка платили то? Ну просто если зп плюс-минус по рынку, то вписываться в такие темы -- это натурально нужно быть фанатом этой компании.
Честно говоря эта мода шестиэтапных собеседований прямо бесит. Лучше бы нормальные тестовые задания были, которые бы ты приходил защищать на единственный технический этап
Спасибо за развернутый ответ, хотя можно было ограничиться первым предложением. Я то и говорил только про продуктовую разработку, в посте кстати тоже был сделан упор именно на нее. А там проекты давно деградировали до уровня эпиков, а команда, это постоянная единица, а не то, что собирается под проект. Соответственно и роль проджекта можно размазать по другим участникам, что-то уйдет на продакта или аналитика, что-то на тимлида, что-то автоматизируется.
По остальным пунктам и спора нет, в проектной разработке/внедрении/сервисном обслуживании без проджекта никак.
Господь с вами, я в индустрии с 2008 года, это всегда было так. Собственно все эти аджайлы, как философия это и проповедуют: соберем сейчас из говна и палок, чтобы протестировать гипотезу как можно скорее. Денег инвесторы то дали только на год. Успеем заработать -- перепишем нормально потом. И это потом просто не наступает по разным причинам, но уж точно не по причине отсутствия нормального проджекта.
А зачем делать проектный график, если он сам построится в современных таск-трекерах, если нормально указывать зависимости эпиков друг от друга, нормально декомпозировать на стори и технические задачи и проставлять оценки. Этапность крупными мазками тоже прекрасно выясняется при грамотной настройке досок, тут хороший пример.
Сборка этих досок это в общем-то прерогатива тим лидов, они в первую очередь отвечают за вверенные им ресурсы и должны понимать что происходит. А далее к тим лидам приходят продакты на планирование спринта и пытаются сматчить с тим лидами ресурсы команды на выполнение самых сокровенных мечт.
Если команда слишком большая и/или не горит желанием прорабатывать задачи и писать документацию, то заводятся аналитики, которые этим и занимаются.
Такая вот продуктовая разработка, которую я видел последние лет 10-12, за это время я ни разу не встретил нужного команде проджекта, они нужны были лишь там, где недостаточно компетентное руководство не могло само взглянуть на нужную доску, чтобы понять текущий масштаб бедствий.
На самом деле круто бы смотрелось продолжение статьи, где бы была взята какая-то конкретная ситуация из реального проекта и микрофича была бы переписана с помощью этого подхода. Если еще затащить при этом в статью пример с переписыванием на дефолтном нынче FastAPI рядом, чтобы понять, когда реально игра стоит свеч, то просто огонь.
Ну предположим по ссылке ноутбук не на Intel Core i7-13620H, а на Intel Core i7-1260P. Еще и нераспаянная DDR-4. Еще и этот цифровой блок, из-за которого руки будут сдвинуты влево относительно оси взгляда, неудобно же. Короче я бы выбрал Xiaomi Redmibook свежий, там и память быстрая, и проц актуальный, и экран лучше, и охлаждение выглядит интереснее и аккумулятор почти в 2 раза больше. Разницу в цене в 20к это все более чем перекрывает.
Кошачья кормилка в целом тема рабочая. У меня двойня, один фанат пожрать, вторая нет. Я сделал 2 кормления в день и это такое количество корма, что толстяк не может за один присест столько сожрать (плюс там у меня две миски), поэтому все норм. Плюс две миски дают дополнительную устойчивость, перевернуть стоящий возле стены девайс будет очень сложно.
Поилка тоже более чем норм история. Воды хватает на двоих на неделю. У меня помпа в фонтанчике работает через обычный usb, не такой девайс как на картинке, так что это относительно безопасная история.
Конечно все зависит от котов, однако все это ультраудобно, можно уехать на пару-тройку дней и совершенно не испытывать страх за животных
ПФФФФФ, тоже мне метрика. У меня на текущем месте работы это минимальная планка, просто специфика такая.
Ну и да, вот пожалуйста, чисто питоновская микродокументо-ориентированная база.
Тогда и речь нужно вести о client-side базах и server-side, вопрос то не в языке. В браузере то у вас всегда есть IndexedDB (наверное я правильно понял что это, я довольно далек от фронта). А на сервере всегда и везде есть sqllite (и не только на сервере кстати), который уже и JSON довольно продолжительное время поддерживает.
В этом и был мой изначальный вопрос, лично я не вижу проблем, которые решает эта библиотека. Вместо нее можно ограничиться одним контекстным менеджером, который будет открывать файл, преобразовывать в словарь и закрывать-записывать.
А в чем отличие js от python в данном контексте? Речь же про js-бэкенд?
При чем здесь синхронный модуль json и параллелизация записи в базу? У вас тут не решена проблема гонок, как ваши парсеры будут одновременно писать в файл?
Для каких целей может понадобиться такая странная библиотека? Пример с парсингом не совсем корректный, потому что запись с помощью вашей библиотеки как минимум не параллелизуется.
В связи с падением зрения, как раз решил заменить 14 дюймов хотя бы на 16, и в этой категории сплошное засилье цифровых блоков. Так сложилось, что все мои ноутбуки, начиная с 2010 года, были без этого волшебного островка. Все думал, кому они нужны, кроме бухгалтеров. Поделитесь пожалуйста, зачем они вам нужны в работе?
Ну да, для более возрастной аудитории ассоциации с Тиньковым останутся
Звучит как какая-то узкоспецифичная вещь для вашей компании или как карго-культ.
1. Ну сбор понятен, кто-то всегда должен собрать требований.
2. Какие SRE выдаст опции, такие и подберет. Если в компании стандартный пак в виде прома с графаной, так и будет пром с графаной. Или куда и как все логи сливаются, так оно и будет в большинстве случаев. У SRE уже в любом случае есть система мониторинга как минимум железяк и системных сервисов, типа nginx. А если все развернуто в этих ваших кубернетисах, так тем более. И алерты, для всех них должно быть одно окно.
3. Непонятно о чем речь. Базово у тебя есть хранилища, куда стекаются метрики из разных мест. Есть отображалка, которая читает эти хранилища. Что именно подразумевается?
4. Свой statsd пишем? Или loki?
5. Тоже какие-то довольно общие слова.
6. Организация инфраструктуры для наблюдения за приложением -- это так же прерогатива SRE.
7. Свою графану с кибаной пишем? Или имеется в виду дашики накидать в инструменте?
8. Это что? Организация канала алертинга? Это часть инфраструктуры, это SRE-DevOpsEngineer-SysAdmin-любое другое имя, которое сейчас модно. Накидывание правил для конкретных дашбордов-панелей? Так это должны уметь все, как разработчики, которым надо следить за тем, что их приложение работает правильно, так и продактам, которые хотят следить за бизнес-метриками приложений.
Короче мне все равно непонятно, чем в итоге занимается этот инженер по мониторингу. Я в статье увидел только код, который проверяет доступность клика на странице. Это что-то вроде end-2-end тесткейса? Ок, прогнали вы его на тесте-стейдже-препроде-любое другое имя, которое сейчас модно. Можно даже на проде гонять, хотя по хорошему поломаться это может только при релизе приложения, если процессы разработки и доставки отлажены более-менее правильно.
А что такое этот "специалист по мониторингу"? Это специалист, который развернет необходимую для мониторинга инфраструктуру? Или специалист, который реализует core-компоненты, обеспечивающие прикладных разработчиков инструментарием, с помощью которого будет осуществляться отправка метрик? А возможно это бизнес-аналитик или продакт, который определит, какие отклонения в бизнес-метриках, должны приводить к уведомлениям об инцидентах?
Здесь нет аргумента за многоэтапность, но есть аргумент за нормальные задания на собеседовании.
Можно поинтересоваться, там насколько выше рынка платили то? Ну просто если зп плюс-минус по рынку, то вписываться в такие темы -- это натурально нужно быть фанатом этой компании.
Честно говоря эта мода шестиэтапных собеседований прямо бесит. Лучше бы нормальные тестовые задания были, которые бы ты приходил защищать на единственный технический этап
Спасибо за развернутый ответ, хотя можно было ограничиться первым предложением. Я то и говорил только про продуктовую разработку, в посте кстати тоже был сделан упор именно на нее. А там проекты давно деградировали до уровня эпиков, а команда, это постоянная единица, а не то, что собирается под проект. Соответственно и роль проджекта можно размазать по другим участникам, что-то уйдет на продакта или аналитика, что-то на тимлида, что-то автоматизируется.
По остальным пунктам и спора нет, в проектной разработке/внедрении/сервисном обслуживании без проджекта никак.
Господь с вами, я в индустрии с 2008 года, это всегда было так. Собственно все эти аджайлы, как философия это и проповедуют: соберем сейчас из говна и палок, чтобы протестировать гипотезу как можно скорее. Денег инвесторы то дали только на год. Успеем заработать -- перепишем нормально потом. И это потом просто не наступает по разным причинам, но уж точно не по причине отсутствия нормального проджекта.
А зачем делать проектный график, если он сам построится в современных таск-трекерах, если нормально указывать зависимости эпиков друг от друга, нормально декомпозировать на стори и технические задачи и проставлять оценки. Этапность крупными мазками тоже прекрасно выясняется при грамотной настройке досок, тут хороший пример.
Сборка этих досок это в общем-то прерогатива тим лидов, они в первую очередь отвечают за вверенные им ресурсы и должны понимать что происходит. А далее к тим лидам приходят продакты на планирование спринта и пытаются сматчить с тим лидами ресурсы команды на выполнение самых сокровенных мечт.
Если команда слишком большая и/или не горит желанием прорабатывать задачи и писать документацию, то заводятся аналитики, которые этим и занимаются.
Такая вот продуктовая разработка, которую я видел последние лет 10-12, за это время я ни разу не встретил нужного команде проджекта, они нужны были лишь там, где недостаточно компетентное руководство не могло само взглянуть на нужную доску, чтобы понять текущий масштаб бедствий.
На самом деле круто бы смотрелось продолжение статьи, где бы была взята какая-то конкретная ситуация из реального проекта и микрофича была бы переписана с помощью этого подхода. Если еще затащить при этом в статью пример с переписыванием на дефолтном нынче FastAPI рядом, чтобы понять, когда реально игра стоит свеч, то просто огонь.