Как оказалось в 2023 году, ваше размышления о размещении серверов в Европе были стратегически ошибочны. А парень хот и неправильно, но мыслил в нужную сторону.
Справедливости ради себя поправлю: в 2022 году в приложение честный знак завезли наконец-то проверку крипто хвостов. Как и в кассовые аппараты с появлением ФН-М.
Я так не писал. Я делился своим личным опытом. Мы отбираем кандидатов, вы отбираете работодателей. Я хотел донести причину, по которой работодатели, как и например преподаватели, бесконечно принимающие рефераты/зачеты по одним и тем же темам, допускают себе право не вчитываться в текст, а выносить оценку по двум трем вопросам сразу понять уровень владение темой студентом.
Я продаю свой труд за деньги
Все продают труд за деньги. Но продавать труд, можно в комфортном помещении и в комфортном коллективе, ведь на работе мы проводим треть жизни. И наши психологи хотят сохранить комфортные условия коллективу. И дело не в обязанности любить друг друга, а в том, что за свою историю мне приходиломь пересекаться с разными программистами и у всех, как и у меня, свои тараканы в голове, от мелких и приятных, до МЕШАЮЩИХ БИЗНЕСУ натуральных членовредителей (вписывали в код "таймеры ошибок" и "закладки для себя", использовали ненормативную лексику в комментариях и в названиях объектах/функций, вдруг переставали приходить на работу и т.п.). В жизни все бывает, и с каждым следующим работником ты понимаешь, что скилл программиста это конечно хорошо, но не менее важным является его человеческие качества.
Согласен с вашем утверждением, но только по рядовым вакансиям.
Топовых ИТ руководителей/программистов/инженеров как правило тянут за собой сменившие работу HR директора или ТОП менеджеры. В HR агенствах они в особом списке, их передают из рук в руки, их знают по именам. Такими сотрудниками не бросаются. Их не ищут на HH.RU, а всегда переманивают, оплачивая релокацию, переезд семьи, в особых случаях покупку жилья. По крайней мере так поступают в нашей компании.
Именно потому, что я руководитель, я знаю стоимость времени. Тратить свое время на заучивание резюме кандидатов непозволительная роскошь. Мой комментарий был нацелен на указание альтернативного мнения к комментарию "... почему таких HR-ов не объявляют проф-непригодными и не гонят в шею".
Мой опыт мне подсказывает, что "красивые" резюме чаще коррелируют с отказами при дальнейшей проверки навыков кандидатов и человеческих качеств, а вот нестандартные резюме всегда привлекают внимание. Для меня, при принятии решения о приеме на работу, важнее послушать о том, как, каким способом и какие проекты реализовывал кандидат, чем какие звания или аттестаты он указал в резюме, поэтому и читаю резюме "подиагонали".
PS// Очень показательно: Делая предыдущий комментарий, я аргументировал свое мнение и не бросался минусами... в ответ получил минуса и только один аргумент. На этой волне добавлю: Кандидаты, успешно прошедшие HR тестирование, решившие задачи программирования, после очного собеседования часто "бракуются" нашими психологами (патологическая нелюбовь к работодателям, готовность "подкинуть мину" работодателю).
Я, как руководитель ИТ, несогласен с вами и позволю себе перефразировать вас : "ваши резюме один к одному как под копирку ... есть ощущение, что вы их берете там же, где качали рефераты, когда учились на программистов" ;)
А если серьезно, то мне, как руководителю, нет времени чтения пачек резюме, прошедшие отсев HR службы. Не завидую HR. Просматриваю резюме кандидата по диагонали и отмечаю интересных на мой взгляд. Уже потом, после проверки СБ и тестовых заданий, изучаю подробно резюме оставшихся кандидатов на финальной - личной стадии собеседования.
UPPER и LOWER предназначены для другого и добавляет SQL дополнительную работу. Для поиска правильно использовать COLLATE.
Но в нашем примере новые функции не спасут отца демократии, поскольку изначально база 1С создана в рекомендуемом режиме сортировки: CYRILLIC_GENERAL_CI_AS (Порядок словаря, без учета регистра).
Вот если бы 1C предложила в язык запросов такое: "ПОДОБНО_С_РЕГИСТРОМ"
SELECT * FROM myTable WHERE myField = 'sOmeVal'
COLLATE CYRILLIC_GENERAL_CS_AS
Как же не делать, если функция НАЙТИ вместо запроса, которую тут "заклеймили ректальной", единственная функция в языке 1С которая позволяет вести поиск данных с учетом различий в регистре.
Вот и приходится делать сразу два "ректальных" решений в одном куске кода (ВЫГРУЗИТЬ И НАЙТИ):
Запрос = Новый Запрос("ВЫБРАТЬ
| РеализацияТоваровУслугИТ_КодыМаркировок.Ссылка
| РеализацияТоваровУслугИТ_КодыМаркировок.СерийныйНомер
|ИЗ
| Документ.РеализацияТоваровУслуг.ИТ_КодыМаркировок КАК РеализацияТоваровУслугИТ_КодыМаркировок
|ГДЕ
| РеализацияТоваровУслугИТ_КодыМаркировок.СерийныйНомер = &КодМаркировки");
Запрос.УстановитьПараметр("КодМаркировки",ИскомыйКМ);
ТаблицаНайденныхКодов = Запрос.Выполнить().Выгрузить();
//а теперь ищем еще раз, уже через регистрозависимый способ поиска
НайденныеСтроки = ТаблицаНайденныхКодов.НайтиСтроки(Новый Структура("СерийныйНомер",ИскомыйКМ);
Если НайденныеСтроки.Количество() Тогда
//Действительно найденны КМ именно те
КонецЕсли;
Пример поиска ошибок в заполнении ставки НДС для не резидентов.
ВЫБРАТЬ
РеализацияТоваровУслугТовары.Ссылка КАК ДокументПродажи,
РеализацияТоваровУслугТовары.Номенклатура,
РеализацияТоваровУслугТовары.СтавкаНДС,
РеализацияТоваровУслугТовары.НомерСтроки
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
НЕ РеализацияТоваровУслугТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0)
И РеализацияТоваровУслугТовары.Ссылка.Контрагент.НеЯвляетсяРезидентом
"РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон" в запросе.
Комментарий 1С: Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности.
Мой комментарий: Каждый программист, при написании кода, стоит перед выбором: повысить производительность или читаемость кода. Каждый случай индивидуален.
20.11.2020. Агрегировать промаркированные остатки из пачек в блоки до сих пор нельзя.
И это не смотря на то, что существует инструкции TrueAPI, где описаны процедуры агрегации.
Ох сразу не обратил внимание… ну держитесь, членовредители…
Дорогие сотрудники компании «Клеверенс», прежде чем всех поучать читать стандарты, вы бы лучше сами их почитали.
В частности:
Состав кода маркировки жестко регламентирован для блоков и пачек.
Состав кода маркировки для транспортных упаковок условно регламентирован обязательным наличием полей 01 и 21. Производители сигарет ВПРАВЕ!!! самостоятельно определять состав кода маркировки для транспортной упаковки.
Соответственно мы, как производители сигарет, решили добавить для маркировки коробов такие поля, как 8005 и 37.Тут пример есть.
Пользователь ПО от Клеверенс решает просканировать коробку сигарет для приемки, а ваше ПО дезинформирует пользователя — «Не является КМ Ч3! Имеет признаки КМ табачного блока.». Как говорится все мимо кассы. Разъясните программисту, что поле 8005 встречается не только в блоках, но и в кодах маркировки коробов.
И длина поля 21 у коробов не ограничена 7 символами.
Но вы не волнуйтесь, не Вы одни испортили нам, производителям, жизнь, создавая свое ПО для «сферических коней в вакууме».
Какие цели декларируются:
Цель: безопасность потребителей.
Какая безопасность?
Криптохвосты до сих пор не проверяются нигде, а в документах ЭУПД и чеках ККМ принудительно обрезаются. Задним числом сказать, легальный были сигареты или нет — невозможно.
Если не сохранена упаковка, уже ничего доказать нельзя. Можно только пытаться «раскуривать» прослеживаемость движения серийного номера в недрах ЦРПТ.
Вы можете вместо криптохвоста написать любые 4 символа и проверка на валидность будет пройдена!
Кто не верит, прошу испытать свой экземпляр «честного знака» на смартфоне:
Как оказалось в 2023 году, ваше размышления о размещении серверов в Европе были стратегически ошибочны. А парень хот и неправильно, но мыслил в нужную сторону.
Справедливости ради себя поправлю: в 2022 году в приложение честный знак завезли наконец-то проверку крипто хвостов.
Как и в кассовые аппараты с появлением ФН-М.
Я так не писал. Я делился своим личным опытом. Мы отбираем кандидатов, вы отбираете работодателей.
Я хотел донести причину, по которой работодатели, как и например преподаватели, бесконечно принимающие рефераты/зачеты по одним и тем же темам, допускают себе право не вчитываться в текст, а выносить оценку по двум трем вопросам сразу понять уровень владение темой студентом.
Все продают труд за деньги.
Но продавать труд, можно в комфортном помещении и в комфортном коллективе, ведь на работе мы проводим треть жизни. И наши психологи хотят сохранить комфортные условия коллективу.
И дело не в обязанности любить друг друга, а в том, что за свою историю мне приходиломь пересекаться с разными программистами и у всех, как и у меня, свои тараканы в голове, от мелких и приятных, до МЕШАЮЩИХ БИЗНЕСУ натуральных членовредителей (вписывали в код "таймеры ошибок" и "закладки для себя", использовали ненормативную лексику в комментариях и в названиях объектах/функций, вдруг переставали приходить на работу и т.п.). В жизни все бывает, и с каждым следующим работником ты понимаешь, что скилл программиста это конечно хорошо, но не менее важным является его человеческие качества.
Согласен с вашем утверждением, но только по рядовым вакансиям.
Топовых ИТ руководителей/программистов/инженеров как правило тянут за собой сменившие работу HR директора или ТОП менеджеры. В HR агенствах они в особом списке, их передают из рук в руки, их знают по именам. Такими сотрудниками не бросаются. Их не ищут на HH.RU, а всегда переманивают, оплачивая релокацию, переезд семьи, в особых случаях покупку жилья.
По крайней мере так поступают в нашей компании.
Именно потому, что я руководитель, я знаю стоимость времени. Тратить свое время на заучивание резюме кандидатов непозволительная роскошь. Мой комментарий был нацелен на указание альтернативного мнения к комментарию "... почему таких HR-ов не объявляют проф-непригодными и не гонят в шею".
Мой опыт мне подсказывает, что "красивые" резюме чаще коррелируют с отказами при дальнейшей проверки навыков кандидатов и человеческих качеств, а вот нестандартные резюме всегда привлекают внимание. Для меня, при принятии решения о приеме на работу, важнее послушать о том, как, каким способом и какие проекты реализовывал кандидат, чем какие звания или аттестаты он указал в резюме, поэтому и читаю резюме "подиагонали".
PS// Очень показательно:
Делая предыдущий комментарий, я аргументировал свое мнение и не бросался минусами... в ответ получил минуса и только один аргумент.
На этой волне добавлю:
Кандидаты, успешно прошедшие HR тестирование, решившие задачи программирования, после очного собеседования часто "бракуются" нашими психологами (патологическая нелюбовь к работодателям, готовность "подкинуть мину" работодателю).
Я, как руководитель ИТ, несогласен с вами и позволю себе перефразировать вас : "ваши резюме один к одному как под копирку ... есть ощущение, что вы их берете там же, где качали рефераты, когда учились на программистов" ;)
А если серьезно, то мне, как руководителю, нет времени чтения пачек резюме, прошедшие отсев HR службы. Не завидую HR. Просматриваю резюме кандидата по диагонали и отмечаю интересных на мой взгляд. Уже потом, после проверки СБ и тестовых заданий, изучаю подробно резюме оставшихся кандидатов на финальной - личной стадии собеседования.
А теперь сравните читаемость запросов.
Ответьте себе честно..."сколько секунд вам нужно, что бы понять что делает запрос первый и второй?"
UPPER и LOWER предназначены для другого и добавляет SQL дополнительную работу.
Для поиска правильно использовать COLLATE.
Но в нашем примере новые функции не спасут отца демократии, поскольку изначально база 1С создана в рекомендуемом режиме сортировки: CYRILLIC_GENERAL_CI_AS (Порядок словаря, без учета регистра).
Вот если бы 1C предложила в язык запросов такое: "ПОДОБНО_С_РЕГИСТРОМ"
Как же не делать, если функция НАЙТИ вместо запроса, которую тут "заклеймили ректальной", единственная функция в языке 1С которая позволяет вести поиск данных с учетом различий в регистре.
Вот и приходится делать сразу два "ректальных" решений в одном куске кода (ВЫГРУЗИТЬ И НАЙТИ):
Просто когда шутят над тем, что ты используешь каждый день и при этом называют твой труд "ректальным" - немного обидно.
В целом я поддерживаю Grigorenkovic во всех пунктах его комментария, кроме 9, в ней автор статьи просто наступили на больной мозоль.
Пример поиска ошибок в заполнении ставки НДС для не резидентов.
Если у вас есть доступ к ИТС, то тут много примеров:
https://its.1c.ru/db/metod8dev/content/2662/hdoc
"РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон" в запросе.
Комментарий 1С:
Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности.
Мой комментарий:
Каждый программист, при написании кода, стоит перед выбором: повысить производительность или читаемость кода. Каждый случай индивидуален.
И это не смотря на то, что существует инструкции TrueAPI, где описаны процедуры агрегации.
Можно открыть для себя много нового:
Маркировка сигарет. Хотели как лучше, а получилось как всегда.
Дорогие сотрудники компании «Клеверенс», прежде чем всех поучать читать стандарты, вы бы лучше сами их почитали.
В частности:
Состав кода маркировки жестко регламентирован для блоков и пачек.
Состав кода маркировки для транспортных упаковок условно регламентирован обязательным наличием полей 01 и 21. Производители сигарет ВПРАВЕ!!! самостоятельно определять состав кода маркировки для транспортной упаковки.
Соответственно мы, как производители сигарет, решили добавить для маркировки коробов такие поля, как 8005 и 37.Тут пример есть.
Пользователь ПО от Клеверенс решает просканировать коробку сигарет для приемки, а ваше ПО дезинформирует пользователя — «Не является КМ Ч3! Имеет признаки КМ табачного блока.». Как говорится все мимо кассы. Разъясните программисту, что поле 8005 встречается не только в блоках, но и в кодах маркировки коробов.
И длина поля 21 у коробов не ограничена 7 символами.
Но вы не волнуйтесь, не Вы одни испортили нам, производителям, жизнь, создавая свое ПО для «сферических коней в вакууме».
Какая безопасность?
Криптохвосты до сих пор не проверяются нигде, а в документах ЭУПД и чеках ККМ принудительно обрезаются. Задним числом сказать, легальный были сигареты или нет — невозможно.
Если не сохранена упаковка, уже ничего доказать нельзя. Можно только пытаться «раскуривать» прослеживаемость движения серийного номера в недрах ЦРПТ.
Вы можете вместо криптохвоста написать любые 4 символа и проверка на валидность будет пройдена!
Кто не верит, прошу испытать свой экземпляр «честного знака» на смартфоне:
04610030140247BrEimn40P93000004610030140247BrEimn40P93z/OKИ вы должны понимать еще по прошлой статье, а вернее причин ее отзывы, я ограничен в высказывании о проблемах.