все верно pg_advisory_lock только bigint примет или два int как ключ. Строковый ключ использовать не получится.
Хотя как по мне не самое критичное ограничение)
А вот Redis (и RedLock в частности ) начинает выигрывать за счет того, что уже все чаще и чаще во многих сервисах просто нет БД. Если нет и БД а есть Redis то выбор очевиден. Если нет и Redis и БД, то тоже реальней и правильней подключить корпоративный Redis для блокировки.
Хотя у коллег был забавный случай - у них Guid хэшировался и передавался в pg_advisory_lock. Зачем это было делать не ясно. Но факт имел место )
отличные факты. как раз 5-6 пусков по 16 спутников, с учетом, что какие то спутники "потеряются" то как раз получится вывести около 70-80 спутников до конца 2027.
Как слышал обещают роутеры поставить в поезда ВСМ, ее тоже обещают в 2027. Было б интересно если "Рассвет" смогли синхронизировать новыми поездами
в разных источниках пишут, что закончат развертывание к концу 2027 года. Вроде как речь идет о сотнях спутников. То есть будут еще 10ки запусков. OneWeb сделал к примеру 19 запусков судя по материал из вики https://ru.wikipedia.org/wiki/OneWeb
Работал на одном проекте. Когда я туда пришел, то там CD-процесс был реализован через excel. Выбираешь артифак, выбираешь БД на которую хочешь накатить миграция, выбираешь целевое окружение и жмешь кнопочку.
Странно что там CI был не в экселе. Не довели до совершенства немного
Еще одно практическое подтверждение книги Прохорова "Русская модель управления". Разделы "Планирование работ" и "Заключение" прям первые страницы введения книги. Рекомендую всем кто не читал.
Эх, если бы еще на груминги эти модели можно было звать :)
А так ждем новых и более удобных плагинов для популярных IDE c элементами ИИ. Кстати если у кого есть список плагинов для VS, VS Code, intellij idea и прочих, то буду признателен на ссылку
Не очень частный кейс, но может быть актуально, например, для справочников.
использует всего 64 бита (для bigint)
Увидев две цитаты выше вспомнил кейс из практики. У нас в одном легаси-приложение, попавшем к нам на редизайн, Id/PK справочников делали bigint, но значений там было обычно не более 100, а обычно и нескольких десятков. Но проблема в том что они связывались с таблицей типа "item" или "entity" у которых были внешние ключи на десятки справочников. И эти внешние ключи были тоже bigint разумеется.
А таблицы "item" или "entity" содержали миллионы записей. Как следствие они все содержали десятки bigint колонок с внешними ключами на справочники. То есть если одна из таблиц "item" содержит хотя б 10 внешних ключей на такие справочники, то мы получим 10 * 8 байт * 1000000 (число записей) = 8 * 10 ^ 7 = 80 МБайт информации. У нас таких таблиц было штук 25. Но если предположить что их хотя бы 5, то мы получим 5 * 80 Мбайт = 400 Мбайт в одной базе подобных внешних ключей. С учетом что мы использовали полные бэкапы раз в сутки и они хранились иногда до полугода, то набегал приличный бесполезный объем данных. За месяц могло набежать 12 ГБ. Конечно если вы в облаке как SaaS то проблем почти нет, а если как IaaS или у вас свои сервера, то надо внимательно следить за свободным местом на диске. А об этом как обычно забывают)) честно скажу забывали и мы и наши опсы )
Хотя если б для Id/PK справочников использовать хотя бы int (4байта), то можно итоговые 12ГБ "перегруза" перевести в 6ГБ, а если smallint (2 байта) то в 3ГБ. Tinyint использовать наверное уже рискованно, но тоже можно рассмотреть.
Это я все к чему ?) К тому что bigint способ хранения PK наверное самый популярный но далеко не самый эффективный. По хорошему нужно проводить мини анализ при его использование от таблицы к таблице. И не слушать крики коллег из разряда "у нас все Id это bigint".
Давным давно хотел провести анализ с списком рекомендаций, когда использовать bigint когда int когда smallint и так далее. Но так и сделал. Если об этом подумаете вы, раз уж взялись за эту тему, то будет замечательно )
Это конечно, поразительно, когда программисты и просто высококвалифицированные профессионалы думают, что то, что подходит сегодня им подойдет всем. И вот мы получаем попытки адаптировать lynda, pluralsight для школьников!
Т.е. ресурсы которыми пользуются инженеры с опытом работы или студенты профильных направлений адаптируются для школьников! Мне кажется это не совсем верно, т.к. людям до 18 лет нужно немного по другому структурировать и подавать учебную информацию. Всему свое место, друзья!
Именно по этому в университетах работают преподаватели, а в школах — учителя. Вроде значения слов похожи, но есть нюанс.
Это-то да. Но вам придется переписывать API под graphQL. А если бы появился HTTP/2, то вам вообще ничего не надо делать. Запросы как летели так и будут лететь, а там пусть за них сервер отвечает. Для legacy очень хорошо. А таких проектов как всегда очень много
Мне кажется, что классический REST отлично жил бы с протоколом HTTP/2 (https://habrahabr.ru/post/308846/). Новый протокол бы решил главную проблему REST — большое число запросов, т.к. позволил бы посылать их в одном TCP- соединение. Но так как HTTP/2 задерживается, то и начали появляться Odata, GraphQL и прочее. Это всё Отличные инструменты, но новый протокол бы был очень кстати. Все-так HTTP1.1 уже скоро 20 лет будет.
Ну это тоже верно и никак моему первому комментарию не противоречит.
В Бизнес-анализе девушек значительно больше чем в разработке. Тоже вполне ясно почему. Разработка более тяжелое и более творческое направление. А анализ требует больше усидчивости (оформление ТЗ, встречи с заказчиком и т.д.), внимания к мелочам + повышенной коммуникабельности.
Со специальностями кстати так же обстоит: «Информатика-экономика», «информатика и английский» это чуть ли не профильный путь для аналитиков. Диплом + 4 месяца курсов бизнес-анализа и вот вам готовый спец.
В общем то моя мысль была больше о специальностях ВУЗовских, чем о гендерном признаке.
Тут осторожней. Во многих которых нельзя разглашать вопросы и прочие подробности с собеседований. Если будете об этом писать, то согласуйте с начальством.
Это классическая итория. «Информатика-экономика», «информатика и английский» это просто базовые специальности для тестирования (по моему городу по крайней мере). Причин несколько:
1. В большинстве случаев знаний для глубокой разработке там не дают. Обычно кто хочет больше кодить идет на другие специальности.
2. Дают неплохие high level знания.
3. Большинство народу на таких специальностях девушки. А у них усидчивость больше и как результат выше эффективность в работе тестера (я в наши дни не обязательно мануального).
У нас в конторе подобные специальности рекрутеры мониторят начиная курса с 3. Так что можно сказать что вы попали по профилю.
Цена конечно не маленькая. Но я все равно собираюсь. Вопрос — есть какой-то гид с советами для тех кто приезжает в город только на dotNext? Я Питербург почти не знаю. Было бы полезно прикинуть что и как еще до приезда…
Пригодился б список ide, которые умеют хорошо работу с языком
Ссылки на GitHub (или куда то еще) на решения, которые с вашей точки зрения могли б стать эталонными для старта собственного проекта
все верно pg_advisory_lock только bigint примет или два int как ключ. Строковый ключ использовать не получится.
Хотя как по мне не самое критичное ограничение)
А вот Redis (и RedLock в частности ) начинает выигрывать за счет того, что уже все чаще и чаще во многих сервисах просто нет БД. Если нет и БД а есть Redis то выбор очевиден. Если нет и Redis и БД, то тоже реальней и правильней подключить корпоративный Redis для блокировки.
Хотя у коллег был забавный случай - у них Guid хэшировался и передавался в pg_advisory_lock. Зачем это было делать не ясно. Но факт имел место )
отличные факты. как раз 5-6 пусков по 16 спутников, с учетом, что какие то спутники "потеряются" то как раз получится вывести около 70-80 спутников до конца 2027.
Как слышал обещают роутеры поставить в поезда ВСМ, ее тоже обещают в 2027. Было б интересно если "Рассвет" смогли синхронизировать новыми поездами
в разных источниках пишут, что закончат развертывание к концу 2027 года. Вроде как речь идет о сотнях спутников. То есть будут еще 10ки запусков. OneWeb сделал к примеру 19 запусков судя по материал из вики https://ru.wikipedia.org/wiki/OneWeb
Я когда видел то видео из серверной, то эмоционировал не меньше героя видео) Поздравления!
Работал на одном проекте. Когда я туда пришел, то там CD-процесс был реализован через excel. Выбираешь артифак, выбираешь БД на которую хочешь накатить миграция, выбираешь целевое окружение и жмешь кнопочку.
Странно что там CI был не в экселе. Не довели до совершенства немного
Еще одно практическое подтверждение книги Прохорова "Русская модель управления". Разделы "Планирование работ" и "Заключение" прям первые страницы введения книги. Рекомендую всем кто не читал.
Пал Каляля забыли еще. Куда без него.
И кстати, мне показалось или этот пост был в ленте "Разработка" ?)
Эх, если бы еще на груминги эти модели можно было звать :)
А так ждем новых и более удобных плагинов для популярных IDE c элементами ИИ. Кстати если у кого есть список плагинов для VS, VS Code, intellij idea и прочих, то буду признателен на ссылку
"Берём список из самых популярных паролей" и добавляем к ним год рождения админа или опса
Увидев две цитаты выше вспомнил кейс из практики. У нас в одном легаси-приложение, попавшем к нам на редизайн, Id/PK справочников делали bigint, но значений там было обычно не более 100, а обычно и нескольких десятков. Но проблема в том что они связывались с таблицей типа "item" или "entity" у которых были внешние ключи на десятки справочников. И эти внешние ключи были тоже bigint разумеется.
А таблицы "item" или "entity" содержали миллионы записей. Как следствие они все содержали десятки bigint колонок с внешними ключами на справочники. То есть если одна из таблиц "item" содержит хотя б 10 внешних ключей на такие справочники, то мы получим 10 * 8 байт * 1000000 (число записей) = 8 * 10 ^ 7 = 80 МБайт информации. У нас таких таблиц было штук 25. Но если предположить что их хотя бы 5, то мы получим 5 * 80 Мбайт = 400 Мбайт в одной базе подобных внешних ключей. С учетом что мы использовали полные бэкапы раз в сутки и они хранились иногда до полугода, то набегал приличный бесполезный объем данных. За месяц могло набежать 12 ГБ. Конечно если вы в облаке как SaaS то проблем почти нет, а если как IaaS или у вас свои сервера, то надо внимательно следить за свободным местом на диске. А об этом как обычно забывают)) честно скажу забывали и мы и наши опсы )
Хотя если б для Id/PK справочников использовать хотя бы int (4байта), то можно итоговые 12ГБ "перегруза" перевести в 6ГБ, а если smallint (2 байта) то в 3ГБ. Tinyint использовать наверное уже рискованно, но тоже можно рассмотреть.
Это я все к чему ?) К тому что bigint способ хранения PK наверное самый популярный но далеко не самый эффективный. По хорошему нужно проводить мини анализ при его использование от таблицы к таблице. И не слушать крики коллег из разряда "у нас все Id это bigint".
Давным давно хотел провести анализ с списком рекомендаций, когда использовать bigint когда int когда smallint и так далее. Но так и сделал. Если об этом подумаете вы, раз уж взялись за эту тему, то будет замечательно )
Т.е. ресурсы которыми пользуются инженеры с опытом работы или студенты профильных направлений адаптируются для школьников! Мне кажется это не совсем верно, т.к. людям до 18 лет нужно немного по другому структурировать и подавать учебную информацию. Всему свое место, друзья!
Именно по этому в университетах работают преподаватели, а в школах — учителя. Вроде значения слов похожи, но есть нюанс.
В Бизнес-анализе девушек значительно больше чем в разработке. Тоже вполне ясно почему. Разработка более тяжелое и более творческое направление. А анализ требует больше усидчивости (оформление ТЗ, встречи с заказчиком и т.д.), внимания к мелочам + повышенной коммуникабельности.
Со специальностями кстати так же обстоит: «Информатика-экономика», «информатика и английский» это чуть ли не профильный путь для аналитиков. Диплом + 4 месяца курсов бизнес-анализа и вот вам готовый спец.
В общем то моя мысль была больше о специальностях ВУЗовских, чем о гендерном признаке.
1. В большинстве случаев знаний для глубокой разработке там не дают. Обычно кто хочет больше кодить идет на другие специальности.
2. Дают неплохие high level знания.
3. Большинство народу на таких специальностях девушки. А у них усидчивость больше и как результат выше эффективность в работе тестера (я в наши дни не обязательно мануального).
У нас в конторе подобные специальности рекрутеры мониторят начиная курса с 3. Так что можно сказать что вы попали по профилю.