Буквально пару дней назад прочитал, что физики смогли доказать, что луч лазера при определенных условиях имеет тень. Это означает, что он становится непрозрачным для других световых волн.
Сходил специально в магнит, чтобы проверить. Новый интерфейс действительно поприятнее. Но долго работал сервис проверки марок, или как то так назывался.
Наверное, в плане удобства достаточно выровнялись с конкурентами
Из всех касс самообслуживания (Пятёрочка, магнит, Ашан, Леруа, Вкусвилл) - магнит самый раздражающий. Ну это ладно. Хуже другое - из 4 или 5 касс работает от силы только одна. Причем постоянно. На остальных - горят ошибки
1) enum применять только в тех случаях, когда добавление нового значения влияет на изменение кодовой базы сервиса.
2) использование только внутреннее, без демонстрации пользователю. Чтобы, например, не заморачиваться с тем, откуда достать текстовое описание значения.
Если хоть одно из условий не выполняется, нужно использовать таблицы. То есть примерно в 99% случаев, если не больше
Задача была именно такая: найти запись по сотруднику с максимальным score
Решение изумило: скачивали на клиента при каждом запросе (нагрузка была примерно 200 tps) около 20 строк, руками пробегали этот список и находили строку с максимальным значением, и брали все атрибуты именно с неё.
Любой инструмент должен быть применен по назначению. В том числе и хранимые процедуры.
Текст процедур вообще ничем не отличается от текста на, к примеру, Java. Его можно прекрасно положить в GIT и так же версионировать. И точно так же документировать, точно так же тестировать на тестовой бд.
Единственный значимый аргумент - это привязка к конкретной СУБД. И то каждый сам для себя определяет допустимую степень риска. Кому было нужно - потратили время и деньги и перешли с oracle/mssql. Значит, задача не является нерешаемой.
Паническое нежелание работать с ХП иногда приводит к маразму. Настолько разработчики боятся малейшей логики в бд, что вместо select max(...), загружают список записей на клиента и уже там находят максимальное значение нужного поля (сам видел)
А вы можете показать хоть одну закладку? Или включаете вашу фантазию?
Спасибо, про ограничения serial не знал
Spring state machine? ))
Язык Дракон. Вполне себе промышленный.
https://ru.m.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D
Оказывается, Тинькофф подключает услугу информирования т-банка, без разрешения оформляя номер телефона в т-мобайл.
Вот, спасибо гоуслугам, узнал о существовании номера, который был на меня оформлен без моего ведома
И тем не менее, книжка от банды 4 - очень познавательная.
Я бы добавил ещё разрешение длинных имён файлов + отключение верификации ssl, если используется самоподписанный сертификат
Событийная модель и микросервисы полностью перпендикулярны друг другу. Между ними нельзя ставить ИЛИ.
Кстати, реактивная модель прекрасно работает с событиями.
Это оффер. Ничего секретного в нем нет. Персданные убрал
При всем уважении, то что вы выдаете за оффер, таковым не является
Оффер - это такой документ, где прописываются название должности, график работы и зарплата. Типа такой:
Лет 10 назад сделал Ласик. До сих пор единичка (было -3).
Доволен как слон
Буквально пару дней назад прочитал, что физики смогли доказать, что луч лазера при определенных условиях имеет тень. Это означает, что он становится непрозрачным для других световых волн.
Сходил специально в магнит, чтобы проверить. Новый интерфейс действительно поприятнее. Но долго работал сервис проверки марок, или как то так назывался.
Наверное, в плане удобства достаточно выровнялись с конкурентами
Из всех касс самообслуживания (Пятёрочка, магнит, Ашан, Леруа, Вкусвилл) - магнит самый раздражающий. Ну это ладно. Хуже другое - из 4 или 5 касс работает от силы только одна. Причем постоянно. На остальных - горят ошибки
Из своего опыта:
1) enum применять только в тех случаях, когда добавление нового значения влияет на изменение кодовой базы сервиса.
2) использование только внутреннее, без демонстрации пользователю. Чтобы, например, не заморачиваться с тем, откуда достать текстовое описание значения.
Если хоть одно из условий не выполняется, нужно использовать таблицы. То есть примерно в 99% случаев, если не больше
Платные версии в первую очередь приобретают из-за технической поддержки
Можно и так. В любом случае, запрос будет быстрее и нагляднее, чем грузить рекордсет на клиента. Даже странно, что приходится объяснять очевидное
Типа такого:
Select *
From example_table t1
Where t1.empl = 123
And t1.score = (select max(score) from example_table t2 where t2.empl = 123)
Order by id desc
Limit 1
Пишу с телефона, уж простите, не форматирую текст
Задача была именно такая: найти запись по сотруднику с максимальным score
Решение изумило: скачивали на клиента при каждом запросе (нагрузка была примерно 200 tps) около 20 строк, руками пробегали этот список и находили строку с максимальным значением, и брали все атрибуты именно с неё.
Любой инструмент должен быть применен по назначению. В том числе и хранимые процедуры.
Текст процедур вообще ничем не отличается от текста на, к примеру, Java. Его можно прекрасно положить в GIT и так же версионировать. И точно так же документировать, точно так же тестировать на тестовой бд.
Единственный значимый аргумент - это привязка к конкретной СУБД. И то каждый сам для себя определяет допустимую степень риска. Кому было нужно - потратили время и деньги и перешли с oracle/mssql. Значит, задача не является нерешаемой.
Паническое нежелание работать с ХП иногда приводит к маразму. Настолько разработчики боятся малейшей логики в бд, что вместо select max(...), загружают список записей на клиента и уже там находят максимальное значение нужного поля (сам видел)