Вы хотите работать с современными Agile подходами к разработке, используя их и учась им? Ставите целью саморазвитие и стремитесь реализовывать свой потенциал? Желаете быть частью динамичного e-commerce бизнеса, жить внутри развитой корпоративной среды, предоставляющей возможность профессионального и личностного развития? Тогда эта вакансия для Вас!

Преимущества работы у нас:
1.    Внутренний заказчик - основную часть бизнес-инициатив мы получаем от сотрудников бизнес-подразделения нашей компании. Внутренняя коммуникация для уточнения требований и деталей реализации позволяет нам разрабатывать более точный и востребованный бизнес-продукт.
2.    Современные методологии - такие как Agile, Scrum, Kanban и DevOps позволяют нам успешно реагировать на изменяющиеся требования бизнеса и современного рынка e-commerce.
3.    Большая честная компания - социальная защита сотрудников нашей компании является залогом стабильной работы. Оформление по ТК РФ. Белая зарплата выплачивается по графику, без задержек и в полном объеме. Годовой бонус по достижению целей компании. Добровольное медицинское страхование (ДМС), страхование жизни, страхование от несчастного случая (после испытательного срока). Налоговые вычеты по НДФЛ, справки для ипотеки.
4.    Развитие и обучение - повышаем квалификацию специалистов, проводим внутренние и внешние обучения. Компенсируем корпоративное обучение английскому и немецкому языкам.

О нас:
Мы, компания eSolutions, входим в немецкий холдинг Otto Group - мировой лидер дистанционной торговли и электронной коммерции, компания с 60-летней историей, офисы которой расположены в 20 странах мира, а общая численность сотрудников превышает 53 000 человек.

Наша цель - построение успешного онлайн-бизнеса. Наш сервис уникален тем, что предоставляет клиентам модульное решение для электронной коммерции. Мы предлагаем решения по запуску интернет-магазинов для производителей и крупных брендов из fashion индустрии, интегрированные с системами склада, учета, логистики и оказываем маркетинговую поддержку.

Мы обладаем большим практическим опытом и использует современные технологии, чтобы помочь нашим клиентам стать лидерами в своей сфере и обеспечить увеличение дохода и продаж.

Задачи, которые Вам предстоит решать:
1.    Разрабатывать внутренние веб-сервисы в учетной системе 1С для получения данных из внешних источников.
2.    Интегрироваться с внешними веб-сервисами для отправки данных из учетной системы 1С.
3.    Разрабатывать реализацию бизнес-логики в учетной системе 1С.
4.    Разрабатывать сводные аналитические отчеты в учетной системе 1С с разным количеством источников данных.
5.    Повышать общую отказоустойчивость учетной системы 1С через оптимизацию запросов и процессов, рефакторинг.
6.    Изучать и использовать новые эффективные подходы в разработке, использовать встроенные инструменты и реализовывать интеграции с внешними инструментами, повышающими качество, скорость разработки, тестирования и внедрения, а также качество поддержки.

Качества, которыми Вы обладаете:
1.    Вы хотите работать на крупном проекте, в команде с разделенным функционалом, состоящих из менеджера проекта, разработчика 1С, разработчика web, аналитика, тестировщика, с применением современных методов разработки и ведения проектов.
2.    Вам нравится решать сложные задачи в срок.
3.    Вы активно предлагаете решения задач на обсуждениях.
4.    Вы стремитесь создать стабильно работающий продукт.
5.    Вам нравится изучать новые методологии, подходы, системы, фреймворки, языки программирования.
6.    Вы мыслите категориями, где 1С может быть одной из группы систем.

Мы ценим наших сотрудников, поэтому дополнительно предоставляем следующие льготы:
Полная оплата по больничному листу до 30 дней в году.
Корпоративное обучение английскому/немецкому языку.
Частичная компенсация расходов на питание.
Скидка 15% на бренды группы – OTTO, Quelle, WITT и bonprix и в в интернет-магазинах наших клиентов.
Гибкий график работы (начало рабочего дня с 7 до 10 утра), 9 часовой рабочий день, обеденный перерывы 45 минут, рабочий день в пятницу сокращен на 1 час. Место работы – ст.м. Савёловская, Бизнес Центр «Фактория».

Резюме можно присылать на [email protected]

Кстати, по той же СКД, давно просят по составному типу сделать дефаултное добавление тип значения реквизита, чтобы можно было пользователю в настройках компоновке отбираться не задумываясь о том, есть ли поле с типом в полях компоновки. В 8.3.11 такого еще нет. В .12 - хз. Мож кто в курсе уже? :)

(239)"Как только, ты его изменишь на объект, сразу получаешь болтом, потому что ты уже не сможешь определить тип передаваемого значения, и как следствие, ты не сможешь сделать отбор по типу."
Почему не смогу? Если ТЗ, которая является объектом сразу при создании типизировать, то можно и на тип проверить.

(243) Тебе нужно добавить тип значения поля отдельным полем в объект. Сечешь фишку? Трабл.

(244)Зачем? Проверить сейчас не на чем, но по моему когда создаешь ТЗ, и ее колонки, каждой колонке через ОписаниеТипов задаешь свой тип, и в запросе спокойно работаешь с типами.

Кстати да, (207) а вот это двойное фаталити.

Так как на собеседовании то отвечать?А то вдруг я пойду и меня спросят?

(241)в пункте 2.2 не seek where ли будет?

(247)На мисту отправляй, пусть тут спрашивают, если чего-то не знают.

(245) =) Чувак, ты не можешь "спокойно работать с типами", т.к. для того, чтобы сделать отбор по типу в настройке компоновке или в схеме компоновке у тебя должно быть это поле для отбора. У тебя его не будет. И поэтому ты можешь обтипизировать колонки объекта сообразно твоему понятию о хорошем и плохом, но отдельного поля тип у тебя не будет. И, соответственно, ты не сможешь сделать отбор. Так понятнее?

(250) Вычисляемое поле в СКД не предлагать?

(40) Рекламодатель всегда прав.

(251) есть две вещи, которые тебе надо знать про вычисляемые поля:
1. они появляются в отборах, когда ты укажешь для них тип. Мы говорим про случай, когда тип - неизвестен, соответственно отбор по такому полю ты не сделаешь.
2. пользовательские поля (выражение) в настройках компоновки при наборе данных объект, когда ты получаешь его по ТипЗначения(ТвоеПоле) аналогично не доступны в отборе.

Выше, предлагалось добавить в набор отдельное поле ТипПоля и при формировании набора делать ТипЗнч(НоваяСтрока.ТвоеПоле); - мы сейчас забьем даже на то, что вроде как по условию задачи этого делать нельзя (у нас уже есть готовый набор, есть готовый отчет и мы просто хотим отобраться). Мы видим, да наше отборочное поле появилось в отборах и вроде победа. Но как отобраться по ТИПУ? Если бы набор данных был запрос, вопросов нет - платформа предложит тебе тип в параметра отбора. Если набор данных - объект, она тебе этого не предложит, и как ты отберешься в этом случае? :) Это общая проблема, которая по крайне мере в 8.3.11 не решена в той формулировке, в которой она поставлена.

(253) Как это тип не известен? Тип будет "Тип"

(254) отберись по нему.

(0) Это еще что за сетевой маркетинг?

(253)(250) Может я не совсем понял в чем суть дискусии но запрос типа
ВЫБРАТЬ ПЕРВЫЕ 1
    ЗаказыПокупателей.Период,
    ЗаказыПокупателей.Регистратор,
    ТИПЗНАЧЕНИЯ(ЗаказыПокупателей.Регистратор) КАК ТипРегистратора
ИЗ
    РегистрНакопления.ЗаказыПокупателей КАК ЗаказыПокупателей
засунутый в СКД позволяет в пользовательском режиме делать отбор по полю ТипРегистратора. И не надо пользовательских полей.

(257) Конечно не понял. У тебя набор данных - запрос. Измени на объект, подсунь туда его и предложи - как отобраться по типу.

(255) Да, с вычисляемым полем СКД борода.
С полем, выбранным в запросе, проблем нет - в отборе можно выбирать тип, как и пишет товарищ (257).
С набором данных "Объект" тоже, выходит, борода.
Однако, даже если тип значения в самом запросе выбирается, то и там не все гладко :) Если вид сравнения отбора СКД сделать "В списке" или "Не в списке" и засунуть в список значений тип, который в результате запроса не фигурирует, то результирующий запрос СКД ругается "Неверные параметры в операции сравнения. Нельзя сравнивать поля неограниченной длины и поля несовместимых типов". Такие дела, надо будет запомнить )

(259) >>С полем, выбранным в запросе, проблем нет
Чувак, все таки - на самом деле, есть проблема то. Тебе нужно это поле протащить в поля набора :) Т.е. сделать, как выше чел пишет ТИПЗНАЧЕНИЯ(ЗаказыПокупателей.Регистратор) КАК ТипРегистратора. Пользователю такая вундер-вафля не нужна, он хочет просто в отборе раскрыть плюс, вытащить поле и сделать уже свой отбор. Чтоб такое было, нужно чтобы платформы автоматом добавляла в поля набора (явно или нет) для каждого поля его фантом ТИПЗНАЧЕНИЯ(ЭтоПоле), тогда эта проблема уходит. Пока, в 8.3.12 я не смотрел, такой фичи нет, и приходится везде где есть схема компоновки, а это не только сама отчет - это учитывать. Но сам этот эпичный диспут начался с того, что выше чел вел политику про отбор по ГДЕ через ССЫЛКА. Вот этот диспут наглядно показывает, что такое не катит в общем случае в компоновке вообще никак.

(260) Не понял, в чем проблема

(261) сделай простейшую схему компоновки с набором - запрос. В полях сделай ОДНО поле (Реквизит1), в котором укажи реквизит составного типа, при этом тип не указывай в настройках.

Задача: сделать на уровне пользователя отбор по этому полю.
Решение: в пользовательском поле, сделать поле, в котором указать в качестве выражения ТипЗначения(Реквизит1). Иду в отбор и? БОЛТ. Там нет этого поля. Таки как отобраться бедолаги?

(262) А, Я-то в (259) веду речь об отдельном поле, содержащем тип значения. А ты проблемой называешь то, что в изходный запрос нельзя добавлять новые поля, так?

Друзья! я просмотрел всю ветку, но не нашел хотя бы примерных цифр по зп... что я упустил?

(263) совершенно верно. Представь - есть конфа, ее купили, челы там сами варятся. Они привыкли, что в каких-то отчетах, где есть такая возможность - можно фильтроваться по типу. Но в любом произвольном отчете (согласно логике здравого смысла, конечно) - они по типу отфильтроваться не могут, т.к. они понятия не имеют, что есть конфигуратор, есть отчет, его как-то надо там открыть, что-то сделать и т.д. и т.п. Коробочный отбор (типа коробочный) при отборе по типу показывает болт. Т.е. без движений специалиста по внедрению или программиста, такой отбор пользователь не сделает. Вот в чем трабл.

(264) Анна, эйчар этой конторы, не считает правильным озвучивать вилку, т.к. с ее личной точки зрения, это бестолковое занятие и бессмысленное. Если у тебя есть желание, можешь сам первый ценник в почту ей скинуть, и она тебе скажет - ты угадал или нет. Таковы реалии, друже :)

(264) Цифр нет. Они не хотят, чтобы другие сотрудники знали уровни зарплат программистов 1С, и завидовали :)

(265) Кстати, такое пожелание для СКД у 1С, с их слов, давно записано :)
https://partners.v8.1c.ru/forum/t/1502045/m/1580932

(264) Лотерея.
Я сознательно игнорировал вакансии, где з/п не указана.

(264) Что? Забыли времена когда 1С-ники работали за доширак? Так вот они вернулись.

(267) я в курсе :) Поэтому и предположил, что возможно в .12 это уже есть. Но судя по описанию, нет. Кстати, выше показывалось что отбор в запросе по ССЫЛКА и ТИПЗначения = Тип одинаков на уровне СУБД. Это с 8.3.6 началось.

(269) Никогда такого не было

(270) "отбор в запросе по ССЫЛКА и ТИПЗначения = Тип одинаков на уровне СУБД. Это с 8.3.6 началось" // Раньше тоже вроде одинаков всегда "результирующий" запрос был в обоих случаях

(264) Игорь, добрый день! Если вакансия Вам интересна,пожалуйста, присылайте резюме на [email protected]. Я буду рада ответить на Ваши вопросы, обсудить вакансию и компенсацию.

а кстати почему обеденный перерыв всего 45мин?

(274) Видимо потому что в пятницу сокращенный день )

(264) Это аукцион. Продавцы кидают резюме и цену, а покупатель выберет наиболее выгодное предложение.

(275) Тогда, перерыв должен быть 48 минут, а не 45. Где три минуты?

(277) Три минуты за день, 15 минут в неделю ворует работодатель у РАБотника

(272) не всегда. Что-то переделывали, ведь не спроста несколько лет об этом где с ссылка трубилось везде :)

(279) А где например об этом говорилось?

(280) в апдейтах к платформе в 8.3.6 косвенно вброс есть на эту тему. Про где ссылка - статьи были на итс тех периодов, ну и опять же косвенно, не зря ж грабли вышеописанные всплыли про где ссылка в запросе к параметру в виде таблицы, при неизвестном (в общем случае) типа. Почему то так же сделано в некоторых местах в типовых и на это обращали внимание. Скорее всего - тоже привели к рекомендации. Но если что - это не более чем гипотеза, может просто челу так было удобнее :)

(276) Или а-ля Джон Краммер: "Привет, я хочу сыграть с тобой в одну игру "угадай вилку".

Ну что, кто-нибудь уже прикиньтесь кандидатом и озвучьте нам вилку.

(276) >Это аукцион. Продавцы кидают резюме и цену, а покупатель выберет наиболее выгодное предложение.

Подобная схема называется тендер. В аукционе наоборот, идет повышение цены.

(234) Есть очень тонкий ньюансы:
1) Для каждого количества в списке будет формироватся свой план запросов, что в итоге может приводить к переполнению кэша плана запросов и можно получить нехилую нагрузку где не ждали (а может и не приводить)
2) При количестве элементов в списке более 1000 происходит следующая трансформация: Список предварительно загружается в Таблицу и потом идет уже соединение с таблицей, а не where.

(86) Какая прелесть :))

Что-то фабрикант мышей вообще не ловит

в тематических ветках обсуждение запросов

(287) Ушел в запой на радостях

Без фотки не взлетит!

https://life.ru/t/новости/1110387/intierniet-maghaziny_otto_i_quelle_ukhodiat_iz_rossii

Видимо,им 1сники желаемые зарплаты прислали

(285) Не смог пройти мимо, т.к. всё сказанное абсолютнейшая дичь:
1. Не будет. План зависит от количества значений в IN по определенной логике, например до 16 констант в IN будет  scan, от 16 до 65 filter + scan. А больше 65 будет сканирование таблицы констант и вложенные циклы с соединяемой таблицей к которой будет seek. И все варианты работают нормально. И никакого переполнения кэша (это вообще без комментариев) не будет.
2. См. п. 1.

(293) В обще - то будет, на обучении кстати приводятся все примеры. Под каждое количество параметром создается свой план запроса, что может и на реальных системах иногда приводит к переполнению кэша плана запросов.
Во вторых поведение оператора В зависит от релиза платформы, ранее оно было действительно от 65, но потом это число увеличили.
Было забавное видео от суровых MSSQL админов, в котором данная фича обсуждалась, там при различии текста запроса на символ формируется новый план запроса.
Вот статейка в тему http://www.queryprocessor.ru/fast-in-ssms-slow-in-app-part3/

И да на реальных системах бездумное применение данного оператора может приводить к латчам.

(101) единственный вариант без использования сторонних утилит - EDT + GIT. Ну соответственно разрабатывая в разных ветках реально вести параллельную работу, и потом произвести слияние.
Наверное от старшего разработчика хотели широкий кругозор и знание современных трендов, на том же ИС вроде как отписывались люди которые небольшие проекты уже полностью на EDT перевели.

(293) Чет какая-то дичь

(293) ms sql server страшно логичная штука, в которую "до 16 констант в IN будет  scan" никак не укладывается

(294) Ты всё смешал в кучу. Похоже наблюдается эффект от обучения людьми из 1С, которые сами в этом ничего не понимают.

1. >Под каждое количество параметром создается свой план запроса

Не создается. Читаем пост того же Пилюгина http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1082155&msg=15712697

Скуль не настолько тупой что будет под каждый параметр создавать новый план и забивать кэш.

>что может и на реальных системах иногда приводит к переполнению кэша плана запросов.

Что значит переполнение? Старые планы из кэша планов вытесняются новыми. В скуле есть отдельная оптимизация для ad hoc запросов, но для 8.3 это неактуально, т.к. ввели переиспользование пула временных таблиц.

2. >Во вторых поведение оператора В зависит от релиза платформы, ранее оно было действительно от 65, но потом это число увеличили.

речь вроде бы про запрос SQL, и его план, при чем здесь платформа?

3. >Было забавное видео от суровых MSSQL админов, в котором данная фича обсуждалась, там при различии текста запроса на символ формируется новый план запроса.

Какая фича? Какое отношение это имеет к 1С, которая тексты запросов генерирует автоматически и не может  поставить лишний пробел или написать разным регистром?

4. >Вот статейка в тему http://www.queryprocessor.ru/fast-in-ssms-slow-in-app-part3/

Статья не имеет к кол-ву параметров и влияние на планы вообще никакого отношения.

(298) http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1082155&msg=15712697

(300) У них там проблема в select *

select * from t1 where b in
заменить на
select b from t1 where b in

(301) я не про проблему, раскрой плюсик в посте 15712697

На самом деле будет 1 из 3-х вариантов и вы это знаете, потому что это тупая физика.

Цикл по таблице констант (перебор/scan) и поиск по индексу (seek) в основной таблице.

Цикл по основной таблице (перебор/scan) и цикл по таблице констант (перебор)

Одновременный перебор 2-х таблиц отсортированных таблиц (merge)

Просто в плане запроса этого не покажут.

(303) Я в курсе, я про это и говорю.
Я повторял их опыт, у меня всегда выходил вариант 3, если я выбирал поле, по которому проходил поиск.

Я правда выбирал не из временной таблицы, а из физической.

Но даже 3 вариант - это по факту nested loops

Надеюсь вы это понимаете

Конечно, мы можем ползти по дереву индекса всей толпой искомых значений (хвала программистам Microsoft) но ровно до тех пор, пока не разделимся по ветвям. Интересно, реализовано ли это.

(304) - (307) Да пофиг какой там план, это не имеет никакого значения, т.к. это работает, и то как оно работает скулю виднее. Главное что не создается никакого нового плана если в условие IN добавляется новый параметр. Есть определенная логика, основанная на "магических числах", откуда берут бред про переполнение кэша? Чуваки на 1С-овских курсах явно дурачат людей.

(310) Про переполнение кэша это конечно дичь, но где вы нашли, что это курсы от 1С?

(293) по 2 - все верно. Когда значений в IN() мало - 1с подставляет их в скрипт литералами,  когда много - инсёртит в темп.

(312) Это вы про платформу, а systemstopper ведет речь про движок sql.

(312) П.2. упоминался в контексте планов запросов, а это всегда запрос скл. Когда я говорю про запросы, я имею в виду те с которыми работает скуль.

(313) Так palsergeich же посещал курсы какого-то эксперта 1С, вот про них стало быть и говорю

+(315) вроде только УЦ № 1 эти курсы проводит, значит это и есть курсы от 1с, не?

Удаленка?

"Повышать общую отказоустойчивость учетной системы 1С через ... рефакторинг" Это как?

(315) (316) Да, УЦ №1 проводит. Нормальные там курсы. Но, возможно, есть путаница в том, что значения параметров прописываются динамически в тексте запроса 1С, например

Где Номенклатура.Код=%ЗначениеКода%

Запрос.Текст=СтрЗаменить(Запрос.Текст,"%ЗначениеКода%",Значение);

Тогда да, план запроса будет компилироваться для каждого нового значения параметра, но переполнения кэша конечно не будет, будет вытеснение из кэша.

(319) >>Тогда да, план запроса будет компилироваться для каждого нового значения параметра

не будет, учим матчасть https://docs.microsoft.com/ru-ru/previous-versions/sql/sql-server-2008-r2/cc645887(v=sql.105)

ссылка криво вставилась, правильная ссылка https://docs.microsoft.com/ru-ru/previous-versions/sql/sql-server-2008-r2/cc645887(v=sql.105)

Тоже кривая

https://docs.microsoft.com/ru-ru/previous-versions/sql/sql-server-2008/cc645887(v%3dsql.100)

пипец...короче ищите по словам "Поиск и настройка сходных запросов с помощью хэширования запросов и планов запросов"

(8) >>На практике - ребята просто тупо пишут код.

это не так

Чушня какая то в результате поиска

(326) Запросы, которые отличаются только литеральными значениями, будут иметь одинаковые хэш-значения. Например, следующие два запроса будут иметь одинаковые хэш-значения, поскольку они отличаются только литеральными значениями, присваиваемыми объектам FirstName и LastName.

USE AdventureWorks;
GO
SELECT I.CustomerID, C.FirstName, C.LastName, A.AddressLine1, A.City
FROM Person.Contact AS C
    JOIN Sales.Individual AS I ON C.ContactID = I.ContactID
    JOIN Sales.CustomerAddress AS CA ON CA.CustomerID = I.CustomerID
    JOIN Person.Address AS A ON A.AddressID = CA.AddressID
WHERE C.FirstName = 'Amanda' AND C.LastName = 'Allen';
GO
SELECT I.CustomerID, C.FirstName, C.LastName, A.AddressLine1, A.City
FROM Person.Contact AS C
    JOIN Sales.Individual AS I ON C.ContactID = I.ContactID
    JOIN Sales.CustomerAddress AS CA ON CA.CustomerID = I.CustomerID
    JOIN Person.Address AS A ON A.AddressID = CA.AddressID
WHERE C.FirstName = 'Logan' AND C.LastName = 'Jones';
GO

(327) Буду знать.

(0) Прочитал описание.
Всё что вы там написали можно заключить в одну фразу "мы пилим маркетплейс", только видимо ещё вместо "витрины" фронт отдельный даете. Lamoda с wb занимаются этим с 15го года.
Интеграция со всем через web-сервисы, куча поделок на php ещё. Ох уж этот "ecommerce" аж ностальгия нахлынула.)

(299) > Старые планы из кэша планов вытесняются новыми.

статистика устарела - план апается разве не только так?

(0) удаленщиков рассматриваете?

(319) Стоп! Мне именно там, видимо на тех самых курсах Виктор Богачев именно так рассказывал: план строится при первом вызове исходя из тех параметров которые передаются и далее именно этот план и используется... и только так! И не так и это потенциальный источник проблемы

* и это потенциальный источник проблемы

(330) какая разница как это происходит если мы всё равно не можем на это повлиять при работе с 1С, да и вообще, не только с 1С.
(332) Виктор Богачев сам потенциальный источник проблем. Он наверно имел в виду parameter sniffing, но это всё настолько экзотический случай что я даже представить себе не могу зачем на это обращать такое пристальное внимание. Видимо рассказывать больше не о чем.

(334) если дерьмо может случиться - оно когда-нибудь случится, если есть возможность предупредить такое событие или быстро пофиксить - это ценно.

В вакансиях немецких предприятий никогда не указывается зарплата.

(90) в вакнсиях немецких холдингов нет понятия вилки

Вы бы еще спросили, сколько на руки будут платить

Предлагаю ввести премию за самую информативную "рабочую" ветку. Я информации полезной узнал намного больше, чем из других "рабочих" веток. Голосую:))
(336)(337)(338) и иже с ними... Чего так возбуждаться на отсутствие вилки? Может быть они действительно несколько человек могут взять? Написали - рыночная з.п. Не ВЫШЕ рыночной, не НИЖЕ рыночной. Вилку з.п. 1Сника в Мск. все знают - от 60(джуниор) до 180-200(мегапрофи). Ну вот и вилка :))

(327)Спасибо просветил

Я же говорил что без фотки не взлетит