Кстати, да, соглашусь: одну и ту же задачу можно решить разными способами.
Но последовательный вызов функций будет строго линейным - он не описывает, как шаги связаны между собой, а просто выполняет их по порядку.
А в цепочке обязанностей шаги становятся самостоятельными узлами, которые могут останавливать выполнение по контексту, пропускать шаги, ветвиться и выбирать другой метод, менять маршрут выполнения.
Это все можно внедрить и в линейный пример - но как только ты добавляешь туда логику переходов, условий, остановок и тд, это практически становится реализацией цепочки обязанностей.
Ради интереса попробую вспомнить теорвер: если считать создание миграции независимым событием, то вероятность создать миграцию в определённую секунду рабочего дня равна 1/8*60 (8 часовой рабочий день, 60 секунд в 1 часу).
Тогда вероятность создать две миграции двумя независимыми программистами в одну секунду будет 1/480 * 1/480 = 1/19200.
Для каждого языка можно найти свой "roadmap", с помощью которого очень легко организовать свое самостоятельное обучение. Можете загуглить тот же "roadmap flutter".
Если вы хотите закрепиться в IT нужно уходить от концепции "этот фреймворк нравится, а этот нет, поэтому сам я его не изучу". Действительно, есть то, с чем приятнее работать.
Но когда вы попадете в реальный проект, вы можете столкнуться с технологиями, с которыми никогда не работали раньше. Или например вам тимлид скажет взять в проект либу, с которой еще никто в вашей команде не работал. И нужно будет за пару дней разобраться и использовать в коде. И скорее всего вы нигде не найдете курса о том, как с ней работать, или даже туториала от индуса. Придется разбираться самостоятельно, хорошо если будет документация, а так возможно по исходному коду читать.
Именно поэтому все те, кто работает в IT всегда говорят, что нужно обучаться самим, а не на курсах.
Я считаю, что курсы - это трата денег и времени. Начните делать свой пет-проект. Нужна идея и доступ в интернет чтобы гуглить документацию и ответы в stackoverflow. Открывайте либы, написанные на нужном вам стеке, и изучайте исходники, чтобы понять как красиво писать код.
Как сделаете проект можно поискать себе ментора, чтобы он дал обратную связь по коду (можно в getmentor.dev, не реклама, там даже бесплатные есть). Это будет дешевле.
Я считаю, что лучше способ изучить язык - это реализовать какой-то пет-проект :)
Я начинала с телеграмм бота, который сообщал мне о том, когда будет прилив или отлив на том или ином пляже (я тогда как раз жила у моря, когда начала изучать язык). Кстати, до этого тоже писала на питоне.
Arena интересная фишка. Мы в своих сервисах уже перешли на 1.20, но пока Arena не трогали. У нас есть договоренность не использовать фичу ради фичи. Но если будет такая задача, где без Arena не обойтись (ну или докажем, что это целесообразно), то возьмем попробовать :) Тем более очень интересно поработать в реальных условиях.
Да, подобные регулирующие законы разрабатываются в США и Великобритании. Многие считают, что это будет отправной точкой для международной практики. В любом случае, сдвиг есть :)
Спасибо!
Ого, как у них интересно сделано. Через браузер ПЛК добавление файлов.
Да это я уже не в рабочих целях интересуюсь. Взять ли для автоматизации ПЛК Овен с модемом или китайскую коробку, которая переключает релюшечки по смс команде.
А то, раз уже знаю CoDeSys может быть в нем и работать…
А, я думала у них какой-то более удобный, типа через Codesys программируется. А если просто через RS-232 подключается, то да. Можно любой взять.
Про WirenBoard не слышала. Спасибо за наводку!)
Пс: а часто бывают готовые библиотеки для общения с модемом. То есть, все стандарные команды AT уже прописанны. Думаю у Овен тоже есть, у них с библиотеками все хорошо.
Имеешь ввиду не создаётся загрузочный проект по умолчанию?
По описанию как у тебя с 63, не опознается контроллер и приходится несколько раз пытаться залить.
Ну тогда замечательно.
А не пробовал работать с их GPRS модулями?
А как Овен работает? Я вот с ним никогда не работала, но коллеги рассказывали, что тот же ПЛК100 иногда очень сильно тупит. Например, программа заливается не с первого раза, а с третьего, контроллер зависает. Были подобные проблемы?
Я писала статью с холодным расчетом, что большинство людей об этом ничего не знает. А это так и есть, уверена :) Просто потому что профессионально не все с этим сталкиваются. Полезность в общем ознакомлении. Думаю, редкий человек, ничего не знающий об этом, в свободное время в интернете скажет себе «Погодите, а я ведь ничего не знаю о том, как делаются процессорные платы! Загуглю как я это!!»
Но если они увидят статью в общей ленте, заинтересуются и прочитают затем конкретно о том, что им инетересно. Ну или зададут вопрос.
А в чем полезность Вашего комментария, кроме оповещения, что не написано о том, что Вам интересно?
Между прочим очень зря, что не интересуетесь теорией оптики, ведь «теория» как раз и определяет то, что можно тем или иным методом посмотреть (о чем я и писала, и про рентген контроль тоже).
Кстати! Я не вижу у Вас ни одной публикации, почему бы Вам не написать о том, что Вам интересно?
Спасибо за внимательность.
Это сферический ворк-флоу заказа в вакууме. Специально описала не так, как у нас)
Кстати, да, соглашусь: одну и ту же задачу можно решить разными способами.
Но последовательный вызов функций будет строго линейным - он не описывает, как шаги связаны между собой, а просто выполняет их по порядку.
А в цепочке обязанностей шаги становятся самостоятельными узлами, которые могут останавливать выполнение по контексту, пропускать шаги, ветвиться и выбирать другой метод, менять маршрут выполнения.
Это все можно внедрить и в линейный пример - но как только ты добавляешь туда логику переходов, условий, остановок и тд, это практически становится реализацией цепочки обязанностей.
Да, я старалась, чтобы усложнить нам всем жизнь на собесах. Всегда пожалуйста!
У нас есть системные аналитики, но да, как раз это входит в зону ответственности разработчиков.
Добрый день, нет, мы сами программисты писали схемы :)
<душнила>
Ради интереса попробую вспомнить теорвер: если считать создание миграции независимым событием, то вероятность создать миграцию в определённую секунду рабочего дня равна 1/8*60 (8 часовой рабочий день, 60 секунд в 1 часу).
Тогда вероятность создать две миграции двумя независимыми программистами в одну секунду будет 1/480 * 1/480 = 1/19200.
</душнила>
Для каждого языка можно найти свой "roadmap", с помощью которого очень легко организовать свое самостоятельное обучение. Можете загуглить тот же "roadmap flutter".
Если вы хотите закрепиться в IT нужно уходить от концепции "этот фреймворк нравится, а этот нет, поэтому сам я его не изучу". Действительно, есть то, с чем приятнее работать.
Но когда вы попадете в реальный проект, вы можете столкнуться с технологиями, с которыми никогда не работали раньше. Или например вам тимлид скажет взять в проект либу, с которой еще никто в вашей команде не работал. И нужно будет за пару дней разобраться и использовать в коде. И скорее всего вы нигде не найдете курса о том, как с ней работать, или даже туториала от индуса. Придется разбираться самостоятельно, хорошо если будет документация, а так возможно по исходному коду читать.
Именно поэтому все те, кто работает в IT всегда говорят, что нужно обучаться самим, а не на курсах.
Я считаю, что курсы - это трата денег и времени. Начните делать свой пет-проект. Нужна идея и доступ в интернет чтобы гуглить документацию и ответы в stackoverflow. Открывайте либы, написанные на нужном вам стеке, и изучайте исходники, чтобы понять как красиво писать код.
Как сделаете проект можно поискать себе ментора, чтобы он дал обратную связь по коду (можно в getmentor.dev, не реклама, там даже бесплатные есть). Это будет дешевле.
Я считаю, что лучше способ изучить язык - это реализовать какой-то пет-проект :)
Я начинала с телеграмм бота, который сообщал мне о том, когда будет прилив или отлив на том или ином пляже (я тогда как раз жила у моря, когда начала изучать язык). Кстати, до этого тоже писала на питоне.
Arena интересная фишка. Мы в своих сервисах уже перешли на 1.20, но пока Arena не трогали. У нас есть договоренность не использовать фичу ради фичи. Но если будет такая задача, где без Arena не обойтись (ну или докажем, что это целесообразно), то возьмем попробовать :) Тем более очень интересно поработать в реальных условиях.
"В одном из клиентских проектов" - этот проект случайно не состоит из двух слов на "Л" и "О"?
Отличная статья, пиши еще!
Вижу на фотке светящийся кристалл. Можно подробнее, что это?
Марк, спасибо за статью!
Очень познавательная, пиши еще!
Ого, как у них интересно сделано. Через браузер ПЛК добавление файлов.
Да это я уже не в рабочих целях интересуюсь. Взять ли для автоматизации ПЛК Овен с модемом или китайскую коробку, которая переключает релюшечки по смс команде.
А то, раз уже знаю CoDeSys может быть в нем и работать…
Про WirenBoard не слышала. Спасибо за наводку!)
Пс: а часто бывают готовые библиотеки для общения с модемом. То есть, все стандарные команды AT уже прописанны. Думаю у Овен тоже есть, у них с библиотеками все хорошо.
По описанию как у тебя с 63, не опознается контроллер и приходится несколько раз пытаться залить.
Ну тогда замечательно.
А не пробовал работать с их GPRS модулями?
А еще, какие скады используете?
Но если они увидят статью в общей ленте, заинтересуются и прочитают затем конкретно о том, что им инетересно. Ну или зададут вопрос.
А в чем полезность Вашего комментария, кроме оповещения, что не написано о том, что Вам интересно?
Между прочим очень зря, что не интересуетесь теорией оптики, ведь «теория» как раз и определяет то, что можно тем или иным методом посмотреть (о чем я и писала, и про рентген контроль тоже).
Кстати! Я не вижу у Вас ни одной публикации, почему бы Вам не написать о том, что Вам интересно?