комментарий создает впечатление, как-будто он написан из идеального мира, где все попадают в компанию которую хотят по 1 отклику - он написан от лица работодателя в частности, и просто честного человека в целом, которому мерзко от преподнесения таких кейсов как чего-то "правильного и позитивного".
Не было такого, что я придумывал опыт в реальной компании и дописывал себе опыт - странно было бы в коммерческой статье признаваться во вранье, ага :)
не переубедить - так ничего не было, что могло бы переубедить, ни единого аргумента.
люди не все одинаковые - это утверждение ложное. Значительно отличаются только люди с патологиями, физическими или ментальными.
Бетонщик учился в техникуме, а затем на практике как подмастерье - пару-тройку лет - за зарплату подсобника, а не бетонщика. Я, кстати, - как раз строителем был раньше.
гнобить других людей
а это, простите, с каких пор "уличать во лжи" == "гнобить"?)
Сейчас в ай ти не пробиться
это повод врать, или набираться опыта? По-моему второе. И никогда не было иначе - сейчас просто огромный вал таких вот, кого облапошили "легким входом в it", десятки тысяч, из которых реально могут стать программистами или тестировщиками, ну, от силы, десятки - зато всем им внушили "ты все можешь", и научили "как проходить собеседования". Даже термин такой есть "жертва курсов" - это, как правило, даже не джун, но с ожиданиями миддла и какого-то особого отношения к себе.
Какой выбор у людей
А что изменилось-то? Тебя на топовые ЗП кто-то должен ждать с распростертыми объятиями? Никогда такого не было, и не будет. Это сложная высококвалифицированная работа, которую нужно уметь делать, а не "пытаться".
Как "не выдавали", если стучались на "миддла", не являясь даже джуном?
Прямое противоречие, совмещенное с неуважениемк тем организациям, на вакансии которых вы откликались, к труду HR, которые были вынуждены просматривать и детализировать ваш отклик. И вы осознанно шли на такой шаг, потому что если перебрать 1000 вариантов - хоть один "выстрелит". Потребительская логика "ну мне же надо а с вас не убудет". Соответственно, отношение у такого человека к самой работе будет не лучше.
Вы бы взяли на работу бетонщика, сделать ремонт в своей квартире, скажем, за свои деньги, если он при этом замешивать бетон умеет чисто в теории, потому что вообще столяр по образованию? А если он к вам постучится 1000 раз? Человек в здравом уме - не возьмет, потому что ему ремонт в квартире нужен, а не эксперименты за его счет.
А сам этот "столяр" - после первой сотни отказовначнет "приукрашивать" - у нас, людей, в целом мозги одинаково работают.
Одно из ваших утверждений ложно:
либо вы не откликались 1000 раз и собеседовались
либо вы не говорили "как есть", а приукрашивали
ну, либо вы задались целью откликнуться 1000 раз , а не "найти работу" (феерично, да, верится с трудом).
Целенаправленно старался не пропустить
ни одной, даже отзывался на позиции
middle-тестировщиков.
И эта стратегия сработала.
Конкретный такой минус в карму.
Не удивительно, что с такими "спецами" OZON планомерно превращается в помойку?
Куда хуже, что в банкингах таких "спецов" тоже много.
К нам как-то один такой прорвался на middle frontend, - хорошо пыль в глаза пускал, готовился к собеседованию, врал безбожно, тестовое выполнил не своими руками.
Три месяца кровь пил и ЗП жрал, пока я думал "человек в новый проект въезжает". Потом уволил к черту, когда правда раскрылась. Ошибка ценой в полмиллиона)
Мысль понятна. Не понятно, как автор к ней пришел, точнее к ситуации, когда появилась потребность анализировать подход настолько поверхностно. Тема не развернута, лично я до конца не понял, что именно автора так задело, т.к. проектирование "от ui" является наиболее логичным, когда создаёшь продукт, т.е. отправной точкой для mvp должно быть удовлетворение конкретных потребностей продукта (сервиса), а все навороты и фичи - уже потом?
При этом сам не раз сталкивался, и, можно сказать, специализируюсь даже, на случаях когда "под капотом все не очевидно", но и тут всегда все отталкивается изначально от покрытия потребностей, а код - всего лишь способ реализовать это покрытие, теми или иными путями.
Всегда пожалуйста. С ростом нагрузок, SKU, вариативности продаж, внедрения маркировки, открытия филиалов и точек продаж, РЦ и т.д., вы также узнаете, что битрикс не тянет от слова "совсем", и нужно будет отдельное решение, скорее всего двухкомпонентное. В общем, впереди много нового, если что пишите, подскажу что знаю из практики.
Надеюсь, что вы вскоре с этим столкнетесь, т.к. это будет означать бурный рост ;)
Не знаю, насколько у вас большая и нагруженная база 1С, у нас более 1Тб постоянно в оперативке приходится крутить, так что всегда приходится отталкиваться от постулата "лучше отдать сырые данные и обработать их вовне".
Копию логики создать и поддерживать в актуальном состоянии не так сложно (с учетом собственной команды разработки), и именно из-за необходимости учета не-линейных показателей - это наиболее актуально, т.к. веб-сервер математику исполняет не хуже самой 1С, а вот с выгрузками масштабных данных у 1С проблемы, и, как следствие, возможны проблемы:
в процессе выгрузки гигантского массива происходит сбой:
1.1. со стороны 1С - отрубился интернет
1.2. со стороны веб-сервиса - недоступность
1.3. со стороны веб-сервиса - в процессе приема и разбора данных появились ошибки и некоторые блоки не были записаны / обновлены
1.4. и так далее, вариантов масса
пока на стороне 1С формируются данные на отдачу - могут возникать конфликты блокировок.
пока на стороне 1С формируются данные на отдачу - могут быть произведены изменения в записях самой 1С. И это не будет исправлено до следующего обмена.
любые попытки снизить риски предыдущих трех пунктов без изменения глобального подхода - это временные костыли, которые сломаются в самый неподходящий момент (дело пошло в гору, много пользователей, много заказов - и привет)
По акциям, спецценам, индивидуальным скидкам и т.д. - обычная работа с матрицами, ничего особенного. Работает математика на веб-сервере не хуже чем в 1С, с той разницей, что горизонтально масштабировать его кудааааааа как проще, чем 1С (на случай наплыва пользователей).
Складывается впечатление, что, либо у вас не такая нагруженная система как вы описываете в статье, которая чувствует себя вальяжно, либо вам еще предстоит узнать все "прелести" проблем, о которых я пишу :)
3500 клиентов * 10000 един ц sku = большие таблицы, с которыми, мало того что Битрикс работает с трудом, так ещё и 1с грузить такими масштабными выгрузками... Ну нецелесообразно точно =)
Берём матрицу исчисления цен (тупо математика, та же что и в 1с), и считаем на лету при формировании страницы. Не нужно конструировать статического монстра, одновременно нагружая 1с.
Мне кажется, это все же вопрос системы управления: либо нацеленность на результат и свободное время как поощрение эффективности, либо классическое "высиживание" времени (что, к счастью, отмирает).
Кажется, это вопрос лидеров команд, ведь при любом раскладе - низкая эффективность - это проблема построения мотивации программистов к достижению цели. Либо не корректное (в парадигме рабочего процесса конкретной компании) планирование. И в том и в другом случае - рыба гниёт с головы =)
Весной делал несколько интернет-заказов. Каждый раз единственным вариантом, чтобы получить заказ, было - докопаться до усталых и злых ребят на стойке информации/кассе, получить порцию молчаливой ненависти, и ждать 15-30 минут, пока они найдут хоть кого-то способного найти и выдать заказ. Дело было в трёх разных городах, из которых два - мегаполисы.
Для своей компании, в т.ч. для розничной сети, внедрял телеграм-бота для уведомлений, много всего для информационного обмена и постановки задач на протяжении последних четырех лет.
И главный вывод, к которому пришел - это работа с персоналом, и только потом технологии, потому что если конечный пользователь-сотрудник не будет замотивирован в использовании сервиса, если он будет неудобен и не нужен ему - все пойдет прахом.
комментарий создает впечатление, как-будто он написан из идеального мира, где все попадают в компанию которую хотят по 1 отклику- он написан от лица работодателя в частности, и просто честного человека в целом, которому мерзко от преподнесения таких кейсов как чего-то "правильного и позитивного".Не было такого, что я придумывал опыт в реальной компании и дописывал себе опыт- странно было бы в коммерческой статье признаваться во вранье, ага :)не переубедить- так ничего не было, что могло бы переубедить, ни единого аргумента.люди не все одинаковые- это утверждение ложное. Значительно отличаются только люди с патологиями, физическими или ментальными.Бетонщик учился в техникуме, а затем на практике как подмастерье - пару-тройку лет - за зарплату подсобника, а не бетонщика. Я, кстати, - как раз строителем был раньше.
гнобить других людейа это, простите, с каких пор "уличать во лжи" == "гнобить"?)
Сейчас в ай ти не пробитьсяэто повод врать, или набираться опыта? По-моему второе. И никогда не было иначе - сейчас просто огромный вал таких вот, кого облапошили "легким входом в it", десятки тысяч, из которых реально могут стать программистами или тестировщиками, ну, от силы, десятки - зато всем им внушили "ты все можешь", и научили "как проходить собеседования". Даже термин такой есть "жертва курсов" - это, как правило, даже не джун, но с ожиданиями миддла и какого-то особого отношения к себе.
Какой выбор у людейА что изменилось-то? Тебя на топовые ЗП кто-то должен ждать с распростертыми объятиями? Никогда такого не было, и не будет. Это сложная высококвалифицированная работа, которую нужно уметь делать, а не "пытаться".
Как "не выдавали", если стучались на "миддла", не являясь даже джуном?
Прямое противоречие, совмещенное с неуважением к тем организациям, на вакансии которых вы откликались, к труду HR, которые были вынуждены просматривать и детализировать ваш отклик. И вы осознанно шли на такой шаг, потому что если перебрать 1000 вариантов - хоть один "выстрелит". Потребительская логика "ну мне же надо а с вас не убудет". Соответственно, отношение у такого человека к самой работе будет не лучше.
Вы бы взяли на работу бетонщика, сделать ремонт в своей квартире, скажем, за свои деньги, если он при этом замешивать бетон умеет чисто в теории, потому что вообще столяр по образованию? А если он к вам постучится 1000 раз? Человек в здравом уме - не возьмет, потому что ему ремонт в квартире нужен, а не эксперименты за его счет.
А сам этот "столяр" - после первой сотни отказов начнет "приукрашивать" - у нас, людей, в целом мозги одинаково работают.
Одно из ваших утверждений ложно:
либо вы не откликались 1000 раз и собеседовались
либо вы не говорили "как есть", а приукрашивали
ну, либо вы задались целью откликнуться 1000 раз , а не "найти работу" (феерично, да, верится с трудом).
Конкретный такой минус в карму.
Не удивительно, что с такими "спецами" OZON планомерно превращается в помойку?
Куда хуже, что в банкингах таких "спецов" тоже много.
К нам как-то один такой прорвался на middle frontend, - хорошо пыль в глаза пускал, готовился к собеседованию, врал безбожно, тестовое выполнил не своими руками.
Три месяца кровь пил и ЗП жрал, пока я думал "человек в новый проект въезжает". Потом уволил к черту, когда правда раскрылась. Ошибка ценой в полмиллиона)
Потерпевшей стороны нет, значит, не попадает
Мысль понятна. Не понятно, как автор к ней пришел, точнее к ситуации, когда появилась потребность анализировать подход настолько поверхностно. Тема не развернута, лично я до конца не понял, что именно автора так задело, т.к. проектирование "от ui" является наиболее логичным, когда создаёшь продукт, т.е. отправной точкой для mvp должно быть удовлетворение конкретных потребностей продукта (сервиса), а все навороты и фичи - уже потом?
При этом сам не раз сталкивался, и, можно сказать, специализируюсь даже, на случаях когда "под капотом все не очевидно", но и тут всегда все отталкивается изначально от покрытия потребностей, а код - всего лишь способ реализовать это покрытие, теми или иными путями.
Всегда пожалуйста. С ростом нагрузок, SKU, вариативности продаж, внедрения маркировки, открытия филиалов и точек продаж, РЦ и т.д., вы также узнаете, что битрикс не тянет от слова "совсем", и нужно будет отдельное решение, скорее всего двухкомпонентное. В общем, впереди много нового, если что пишите, подскажу что знаю из практики.
Надеюсь, что вы вскоре с этим столкнетесь, т.к. это будет означать бурный рост ;)
Не знаю, насколько у вас большая и нагруженная база 1С, у нас более 1Тб постоянно в оперативке приходится крутить, так что всегда приходится отталкиваться от постулата "лучше отдать сырые данные и обработать их вовне".
Копию логики создать и поддерживать в актуальном состоянии не так сложно (с учетом собственной команды разработки), и именно из-за необходимости учета не-линейных показателей - это наиболее актуально, т.к. веб-сервер математику исполняет не хуже самой 1С, а вот с выгрузками масштабных данных у 1С проблемы, и, как следствие, возможны проблемы:
в процессе выгрузки гигантского массива происходит сбой:
1.1. со стороны 1С - отрубился интернет
1.2. со стороны веб-сервиса - недоступность
1.3. со стороны веб-сервиса - в процессе приема и разбора данных появились ошибки и некоторые блоки не были записаны / обновлены
1.4. и так далее, вариантов масса
пока на стороне 1С формируются данные на отдачу - могут возникать конфликты блокировок.
пока на стороне 1С формируются данные на отдачу - могут быть произведены изменения в записях самой 1С. И это не будет исправлено до следующего обмена.
любые попытки снизить риски предыдущих трех пунктов без изменения глобального подхода - это временные костыли, которые сломаются в самый неподходящий момент (дело пошло в гору, много пользователей, много заказов - и привет)
По акциям, спецценам, индивидуальным скидкам и т.д. - обычная работа с матрицами, ничего особенного. Работает математика на веб-сервере не хуже чем в 1С, с той разницей, что горизонтально масштабировать его кудааааааа как проще, чем 1С (на случай наплыва пользователей).
Складывается впечатление, что, либо у вас не такая нагруженная система как вы описываете в статье, которая чувствует себя вальяжно, либо вам еще предстоит узнать все "прелести" проблем, о которых я пишу :)
Выгружать индивидуальные цены, серьезно?
3500 клиентов * 10000 един ц sku = большие таблицы, с которыми, мало того что Битрикс работает с трудом, так ещё и 1с грузить такими масштабными выгрузками... Ну нецелесообразно точно =)
Берём матрицу исчисления цен (тупо математика, та же что и в 1с), и считаем на лету при формировании страницы. Не нужно конструировать статического монстра, одновременно нагружая 1с.
Мне кажется, это все же вопрос системы управления: либо нацеленность на результат и свободное время как поощрение эффективности, либо классическое "высиживание" времени (что, к счастью, отмирает).
Кажется, это вопрос лидеров команд, ведь при любом раскладе - низкая эффективность - это проблема построения мотивации программистов к достижению цели. Либо не корректное (в парадигме рабочего процесса конкретной компании) планирование. И в том и в другом случае - рыба гниёт с головы =)
Весной делал несколько интернет-заказов. Каждый раз единственным вариантом, чтобы получить заказ, было - докопаться до усталых и злых ребят на стойке информации/кассе, получить порцию молчаливой ненависти, и ждать 15-30 минут, пока они найдут хоть кого-то способного найти и выдать заказ. Дело было в трёх разных городах, из которых два - мегаполисы.
Для своей компании, в т.ч. для розничной сети, внедрял телеграм-бота для уведомлений, много всего для информационного обмена и постановки задач на протяжении последних четырех лет.
И главный вывод, к которому пришел - это работа с персоналом, и только потом технологии, потому что если конечный пользователь-сотрудник не будет замотивирован в использовании сервиса, если он будет неудобен и не нужен ему - все пойдет прахом.
А вы, ребята, похоже об этом совсем забыли)