-25

Программисты оторваны от реальной жизни?

В закладках браузера наконец-то нашел пост российского ученого Николая Непейводы (фамилия ведь не склоняется?) под названием "Программирование не жизнь" - https://nepejvoda-n-n.livejournal.com/79427.html . Там идут рассуждения о предпосылках того, что мы все и так давно знали: редкий программист способен разобраться хоть в чем-то, что находится за пределами области его каждодневого красноглазого копошения в кодах. Далее приведу текст самой статьи.


Образование должно помогать в жизни. Никакая конкретная профессия не исчерпывает жизнь, а некоторые при слишком глубоком вхождении в них реальной жизни прямо мешают. И пара таких, к несчастью — математика и программирование. Обе они легко могут увести в мир иллюзий и фантомов. В частности, по этой причине выпускники МФТИ чаще добиваются больших успехов в жизни, чем выпускники ВМиК МГУ, поскольку у них математика и информатика безжалостно уравновешиваются физикой, реальными экспериментами в реальном мире.

Далее, программирование как ремесло и даже как профессия само по себе, если брать локально, действительно не требует такой уж фундаментальной подготовки. Что там говорить о студентах младших курсов, ремесленные поделки очень часто могут клепать подростки, обладающие способностью и тягой к комбинаторному мышлению. И даже системные программы порою тоже (разница в уровне ремесла, а не абстракции), но здесь уже нужен талант.


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

И математика, и программирование представляют людям великий соблазн оторваться от этого гадкого иррационального реального мира и окунуться с головой в идеальный логичный мир абстрактных сущностей. Результат мы часто видим в форме профессионального кретинизма, а то и прямой психической болезни (для математиков и для философов из МГУ в советские времена в больнице им. Кащенко были даже отдельные специальные палаты и врачи говорили о философской интоксикации и математической шизофрении).

Поэтому программирование надо рассматривать в более широком контексте. Задачи решаются для жизни, и в принципе должны браться из реальности и затем погружаться в неё. А тогда мы должны говорить не о профессии программиста, а о профессии информатика.

Информатик должен быстро осознать абстрактный информационный костяк проблемы и преобразовать её в задачу. Проблема может прийти к нему из любой, непредсказуемой заранее конкретной предметной области, поэтому необходимо быстро выделить в ней существенное и овладеть ею настолько, насколько достаточно для качественного решения задачи, не "изучая" её. Задачу необходимо структурировать, формализовать и передать для решения кодерам (включая в это понятие системных программистов), и самому принимать участие в решении, поскольку иначе эти пираты просто не станут признавать авторитет данного квартермейстера. При этом возможно придётся быстро освоить инструментарий, которым ранее не пользовался (проблема та же, что с предметной областью). Весьма выигрышно воспользоваться методами из совершенно другой предметной области, установив гомоморфизм информационных и системных структур в данном случае.

И мы видим, что это противоположная ориентация, чем программер: ориентация на жизнь. и фундаментальность здесь необходима, но намного более широкая, чем математика. Брать интегралы программа уже умеет лучше человека. а вот структурировать проблемы и переводить их в задачи не может, и информационный контекст находит по ключевым словам, а не по подобию информационных и системных структур.

Это убеждение выношено кровью, потом и более чем двадцатилетним опытом, в том числе порою и страшным (некоторые ученики, оказавшиеся неспособными подняться на очередной уровень знаний и умений, сильно повреждали своё психическое здоровье, и пришлось отслеживать состояние студентов и по мере возможности пытаться их предупредить, что дальнейшее повышение чревато. пора перейти к освоению и шлифовке уже достигнутого).

Причина, как видно, кроется в подходе к процессу получения высшего образования. Я тоже так считаю, что не должно быть чисто айтишных факультетов, изучающих сферических коней в вакууме и программирование ради программирования. Должны быть только инженерные специальности, где изучается решение поставленных задач с помощью языков программирования, либо вида "прикладная математика/информатика". А все эти новомодные "программная инженерия" (кошмар-кошмар! ведь еще у студентов создается впечатление, что программистов можно отнести к инженерам), "фундаментальная информатика", "информационные технологии", "информатика и вычислительная техника" - все в сад, лесом..

Дубликаты не найдены

+6

Странная статья. Я б так сказал "оторванная от жизни".

Начнем с того что математику не надо заниматься "жизненными задачами", у него математика ушла уже далеко вперед. Это потом физик, когда придумает какую-нибудь гипотезу, обращается к трудам математиков и говорит: "Епт, то что мне надо! Сейчас возьму пару теорем Васи Ложкина и разложу их в многомерном пространстве Козловского и смогу свою гипотезу обосновать, или же понять ее несостоятельность".

Так и с программерами. Не встречал ни одного товарища который бы знал только программирование и не более того.

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

Если сидишь и пишешь сервис для расчета данных к этому интерфейсу - то разбираешься во всей математике стоящей за конечным результатом.

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


Кстати, вся фундаментальная наука тогда также оторвана от жизни. В чем разница? )

ещё комментарии
+7

написан дичайший бред. с учетом имеющихся объемов работы - должно быть четкое разделение труда по специальностям. прикладник - общается с клиентом, составляет и описывает задачу. а дело программиста - сесть и реализовать в рамках имеющего ТЗ.

ещё комментарии
+3

"редкий программист способен разобраться хоть в чем-то, что находится за пределами области его каждодневого красноглазого копошения в кодах"
Я почему то это вижу совсем наоборот. Все мои знакомые программисты с горздо большим интересом и вовлеченностью выслушают рассказ о том, что вам интересно, в то время как представители других професий как только начинают слышать что то о программировании или математике выдают что то вроде "не грузи".
+ когда участвуешь в разработке приложений ты практически обязан разобраться в предметной области (в той области, для которой пишешь в данный момент).
Так что пост хуйня. Но можешь вбросить ещё

ещё комментарии
+2
Фамилия у мужчины склоняется, у женщины нет
раскрыть ветку 1
-3

я переправил)

+5

Полная хренотень. Нет программирования ради программирования.

Те кто лишь способен переложить на код готовый расписанный алгоритм раньше даже программистами не назывались.

Нормальный же программист разбирается в теме для которой "программирует".
И может самостоятельно решать проблемы в заданной тематике - а для этого эту тематику необходимо знать.

Уже дано нет "программистов в вакууме" - как нет универсальных врачей - идет четкое деление по специализации.

Конечно сейчас идут попытки разделить программистов на разные уровни - "джуниоры" там всякие и прочее говно но этот методы не особо эффективны. Да, уровень требуется существенно ниже - но и отдача как от кучи говна.

раскрыть ветку 20
0
Нормальный же программист разбирается в теме для которой "программирует".
разбирается на каком уровне? на уровне два-по-пять? так для этого много мозгов не надо. только вот на то, чтобы сесть и разобраться н-р в бюджетном законодательстве - у программиста тупо не будет времени - иначе он не будет выполнять свои обязанности.
раскрыть ветку 19
0

да шо ты говоришь? только вот недавно сидел и решал с главбухом одной "маленькой" конторки вопросы по бюджетному учету.

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

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

раскрыть ветку 9
0
Частенько разбирается лучше, чем люди, которые потом этими программами пользуются
раскрыть ветку 8
0

По комментариям ТС в этом посту создается впечатление, что он имел неудачный опыт работы с IT-специалистом. Похоже на то будто ТС не смог сформулировать четкое тз для какой-то его "хотелки" и виноваты вдруг стали все до кого можно дотянуться. Типичный Д'Артаньян.

А чего только стоит то, что ТС считает, что программист не может быть инженером. Или же: "редкий программист способен разобраться хоть в чем-то, что находится за пределами области его каждодневого красноглазого копошения в кодах." Это как сказать что гуманитарий не способен считать без калькулятора. Просто смешно.

В интересном вы мирке живете, dimtester.

раскрыть ветку 6
-1

я почти отправил вам большущий комментарий по поводу того, что программисты никак не инженеры. но удалил, потому что давно собираюсь разразиться постом на эту тему. ссылки собраны, перевод небольшой статьи с собственными комментариями готов - никак не дойдут руки до оформления этого. давайте я в обозримом будущем (в сентябре точно) выложу пост, если есть желание - приходите дискутировать, я могу напомнить комментарием здесь. небольшой спойлер уже был в ветке #comment_119411735


касательно создания впечатлений - не надо додумывать, фантазировать. Не надо и все. Один уже тут есть #comment_121269392 на основе абзаца с перечислением технологий в резюме, как газетная гадалка выдал жизненный путь: "Выглядит что это сначала был QA. Потом решил что ему маловато денег и пошел в программисты. Как видим, ему это дело отвратительно и он пошел в менеджеры. В итоге имеем в посте классических взгляд манагера считающего своих подчиненных живтоными за которыми нужен глаз да глаз." Неблагодарное это дело, спросите просто, чего не знаете, я не кусаюсь и не баню. Не угадали, тем более.

Про редкого программиста (перелетающего середину Днепра) оставайтесь при своем мнении, пожалуйста. Смысл слова "разобраться" там не забудьте, что означает успешное применение материала для решения ежедневных задач, а не бросание выученными словами в курилке и опенспейсе. 

раскрыть ветку 5
0

Тогда задам вам один простой вопрос: как называется специалист, который проектирует микропроцессорные системы и пишет для них прошивку?

раскрыть ветку 4
-4

кого это так бомбануло, что наставил минусы каждому моему комментарию в посте, а заодно десятку моих последних постов (даже не связанным с айти)? satisfactor,  MyckyL? какой-то злой молчаливый аутишник?

Похожие посты
2119

2 года разработки - AIWM Hexapod

Два года разработки с 0, вот прям с чистого чертежа в КОМПАС 3Д. Всю электронику, прошивку, программу управления, механику, математику и дизайн - всё сам и всё с нуля. Наконец-то я сделал это - проект достиг версии 1.00. Не буду голословным, результат работы показан на видео. Надеюсь всем понравится :)

Вот тут можно узнать о ходе разработки подробнее. Там есть ссылки на различные этапы разработки.

https://habr.com/ru/post/493304/

151

Войти в айти. Часть 5

Привет, Пикабу! Да, да.. это очередной пикабушник с кризисом среднего возраста, который вдруг осознал и понял, что с детства мечтал быть программистом. Давненько не было отчёта о моём пути в профессиональный мир разработки. Если вдруг Вам интересен мой опыт, то предыдущие срезы тут:

Часть 0

Часть 1

Часть 2

Часть 3

Часть 4


Вкратце, с чего всё начиналось:

0) Увольнение с военной службы по контракту

1) 31 год

2) Высшее образование (заочное) по направлению "Информатика и вычислительная техника"

3) Выучил Java, сейчас изучаю Kotlin и Swift

4) Есть несколько карманных проектов в Play Market, всё довольно простенькое, но стараюсь развивать

5) Женат, детей нет, кот есть

6) В it не работал

Цель - к декабрю 2020 набрать в сумме 1.000.000 загрузок на Android, выучить Swift и выпустить приложение на ios.


Первый пост был написан 10 месяцев назад, в котором я ставил себе рубеж - декабрь 2020. Но не дотянув 2 месяца я схожу с дистанции. Причина этому довольно меркантильная, но приятная - пора устроиться на работу, нужны деньги так как ждём пополнения.

Давайте подведу итоги того, что я имею на данный момент:


- Выучен язык программирования и технологии, позволяющие писать под Android всё, что приходит в голову. Ограничен только временем. На любой вопрос уже есть ответ, стоит только почитать, поэкспериментировать, вникнуть.

- На создании собственных приложений жить можно. Деньги не большие, но на жкх и холодильник хватает. Доход постоянно растёт, если не останавливаться, создавать что-то новое и поддерживать старое.

- Физкультура важна не менее умных книг. Мало движения - тает мотивация, появляется прокрастинация.

- 1.000.000 загрузок набрать не удалось. Цифры гораздо скромнее. На данный момент в сумме загрузок около 240.000, активных пользователей в сумме по приложениям около 83.000

- если из 100 скачавших приложение человек 30 не удаляют его, то это вполне хороший показатель, значит его можно и нужно развивать!

- гайды создания интерфейсов не всегда работают. Порой плюнув на рекомендации корпораций можно сделать что-то, что "зайдёт" людям.

- после 30 на работу в it устроиться можно!


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


Результаты по Android меня вполне удовлетворили, чего не сказать о ios. Времени и сил не хватило на всё, буду заниматься им в рамках общего развития. Надеюсь что к весне смогу сделать что-то простенькое.


В итоге вчера мне сделали предложение на вакансию разработчика, которое меня полностью устроило как в плане зп, так и перспектив развития. Впереди знакомство с коллективом и вход в серьёзную разработку. Надеюсь задачи будут интересные, а кофе вкусным 😊 Если будет интересно и я успешно справлюсь с испытательным сроком, то обязательно поделюсь впечатлениями.


Если мечтаете сменить род деятельности, выделите время, составьте план, определите сроки и вперёд! Другой жизни не будет, а занятие любимым делом профессионально - это очень, очень круто!

Показать полностью
174

Фулл-стек матрос

— Почему вы хотите работать палубным матросом именно на "Мести рекрутера Веры"?

Я вытянулся в струнку и заученно (в каждом порту работодатель обязательно задаёт этот вопрос) ответил:

— У вас прекрасная команда и корабль собран по последнему слову техники, это возможность получить полезный опыт и навыки, и я хочу быть частью вашей миссии своевременной доставки пассажиров по всему миру.

— Кем вы видите себя через пять лет?

"Кормом для рыб", хотелось ответить мне на второй набивший оскомину вопрос, но, увы, пришлось сказать, что я прежде всего хочу стать очень профессиональным палубным матросом, и уже потом смотреть, куда приведёт меня карьера — может, вперёдсмотрящим, а, может, и боцманом.

— Что ж, кажется, мы можем взять вас с испытательным сроком в качестве фулл-стек разработчика.

— Кого? — переспросил непонятное слово я.

— Палубного матроса. Вы же на эту должность обращались? Что за странная потеря слуха?

— Извините, послышалось что-то другое.

***

Корабль был... монументален. Борт вздымался над причалом на три десятка человеческих ростов. Поднявшись на него, я увидел боцмана, который пробурчав что-то непонятное, кивнул на доску, закреплённую на одном из бортов, сказал:

— Я там кинул тебе в спринт пробные задачи, осваивайся. Если что-то непонятно, спрашивай.

"Спринт?"

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

***

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

— А как мы будем держаться в шторм? — спросил я у боцмана как-то. — Ведь кораблики будут стукаться друг об друга, если там гибкое соединение, а жёсткое соединение вообще сломается. Схема, когда каждый гребец сидит в своей вынесенной за борт капсуле тоже не кажется мня такой уж надёжной.

— Не трусь, матрос! Мы постоянно проводим нагрузочное тестирование, и результаты обнадёживают.

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

— Как там твоя задача по замене тросиков на двойные с автоматической проверкой, что трос привязан к нужному кораблю? Мы тут в следующем порту берём на борт первую группу пассажиров, пора бы доделать.

— Работаем!

— Обнови оценку в Джире, пожалуйста.

Это непонятное слово я уже точно ассоциировал с доской, где боцман и капитан записывали задачи.

***

Это была катастрофа.

Пользователи (тьфу, сам заговариваться начал, пассажиры) изменили осадку кораблей, и те совсем не так держались на воде. К тому же прыгать с корабля на корабль, когда палуба постоянно уходит из-под ног, оказалось очень сложно, а это приходилось делать постоянно, потому что столовая была вынесена на отдельную лодку, то же самое с туалетом, библиотекой (без которой многие пассажиры не мыслили дальнейшее плавание), и много ещё чем. А пассажиров было много...

Ветер дул беспощадно, море разыгралось не на шутку, многие жёсткие соединения треснули, а тросы угрожали разорваться. Вперёдсмотрящий не всегда мог докричаться до рулевого. Впервые за всю карьеру мне было страшно. Вместе с остальными джуниорами я затыкал пробоины в трюме. Капсулы с гребцами постоянно смывало за борт, капитан с криком "перезапустить сайдкик" дёргал рычаг, выпускались новые капсулы, гребцы прямо из воды забирались в них и начинали грести дальше.

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

***

— Матрос, можешь откатить свою фичу с прода? — услышал я голос капитана из трюма.

Ситуация не располагала переспрашивать, и надо было соображать.

— Исполняю, капитан!

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

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

***

Над головой был белый потолок, вокруг — белые стенки, я был привязан, а за стеной кто-то обсуждал меня.

— Курс азалептина даёт неплохие результаты, и он уже начинает видеть реальный мир, — незнакомый голос продожил, — но всё же забирать его отсюда еще нельзя.

— Но он очень нужен в проекте! У нас не хватает рук, можно ли как-то ускорить выздоровление? — а вот этот голос я знал. Это был боцман.

Фулл-стек матрос Программист, Разработчики, IT юмор, Длиннопост

https://m.facebook.com/story.php?story_fbid=1022029940525391...

Показать полностью 1
34

Blueprints и C++ в Unreal Engine: плюсы и минусы

Epic Games последовательно развивает систему визуального программирования Blueprints в Unreal Engine. Она продвигается как полноценная рабочая среда, в которой любой новичок может освоиться и собрать свою игру. Но действительно ли «блюпринты» ни в чём не уступают классическому программированию?


Александр Балакшин, программист AAA-игр, внёсший значительный вклад в разработку сезонных обновлений для Tom Clancy’s Rainbow Six Siege в роли старшего инженера-разработчика и лида геймплейной команды, разбирает плюсы и минусы Blueprints и объясняет её отличия от «чистого» C++.


Автор: Александр Балакшин

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Источник


Блюпринты выигрывают у C++ на начальных этапах разработки, особенно если код игры пишется с нуля. Они не требуют установки дополнительной среды, к тому же предлагают быстрые итерации. А блочный синтаксис блюпринтов понятен не только программистам, но и тем, кто знаком с аналогичными системами в программах для создания контента — например, художникам.


Но если рассматривать разработку игры в целом, в долгосрочной перспективе, то классический подход к программированию показывает свои преимущества. Даже сами Epic Games заостряют внимание на том, что блюпринты — это не код, а данные, поэтому и относиться к ним нужно соответственно. Например, некоторая общая логика всё равно должна выноситься в код.

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Источник


По этой же причине блюпринты невозможно толком «мёрджить», то есть соединять результаты разработки. Поэтому их приходится отдельно блокировать, чтобы не создавать конфликтов и не терять проделанную работу. С классическим же кодом могут работать даже несколько человек одновременно, но результат их работы в одном файле обычно всё равно очень просто совместить.


Наконец, блюпринты бьют по производительности, так как компилируются в байт-код, который работает на встроенной в движок виртуальной машине. Да, их можно нативизировать, — то есть преобразовать Blueprint-логику в файлы C++, но даже разработчики из Epic рекомендуют этим не злоупотреблять.


Да и с точки зрения GOMS-анализа нажатие на клавишу клавиатуры оказывается быстрее, чем перемещение мышки. Это ни в коем случае не отменяет удобство визуального редактора, но, по моему опыту, с автодополнениями и прочими синтаксическими функциями современных IDE писать код удобнее и быстрее, чем создавать граф в блюпринтах. Хотя полезные сочетания клавиш и шорткаты в Unreal Engine тоже облегчают жизнь.

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Источник


Я считаю, что если программисту нужно работать с Tick-функциями, или он использует какую-то сложную математику и пространственные запросы (например, LineTrace), всё это лучше вынести в С++. Отчасти из-за всех перечисленных особенностей Epic Games раздумывают над созданием отдельного скриптового языка для реализации игровой логики в Unreal Engine.


Тем не менее, блюпринты — достаточно мощный инструмент, который в Unreal Engine 4 используется не только для построения игровой логики, но и для работы с анимацией и системой эффектов Niagara. Поэтому каждая студия должна сама найти подходящий баланс между Blueprints и С++. Например, технические дизайнеры Riot Games использовали блюпринты в Valorant только для создания способностей игроков.

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Valorant


Сами Epic Games рекомендуют использовать блюпринты, когда в проекте очень много ссылок на контент, а его логика работает в первую очередь на визуальную составляющую. Также они пригодятся в создании прототипов, прямолинейной или редко используемой логики, которая не является частью основной архитектуры. Всё, что не получит преимуществ в С++ с точки зрения производительности, масштабируемости и стабильности, тоже может быть создано в Blueprints.


Ну а с С++ лучше работать, если функционал используется более чем в одном месте и включает в себя сложные элементы — например, сохранение игр или сетевой код. Если проект в дальнейшем будет расширяться, то его тоже лучше создавать с помощью классического программирования — оно помогает тщательно поддерживать логику и стабильность кода.


Словом, с любыми важными переменными, перечислениями и типами данных C++ работает лучше. Но и работа в Blueprints не отменяет классический подход, а только органично дополняет его в необходимых случаях. Так что разработчикам от визуального программирования никуда не деться.

Показать полностью 3
2205

Ответ на пост «Что получается в результате работы программиста» 

Ребенку 5 лет. Детский сад. Изучаем профессии. В гостях дедушка и бабушка.Начинается допрос.

- Папа, а ты кто?

- Охранник...

- Чего ты делаешь на работе?

- Охраняю людей...

-Это же полезная работа?

- Конечно! (как сказать....)

- Деда, а ты кто?

- Водитель

- А чего ты делаешь?

- На машине грузы перевожу... (далее следует рассказ минут на 20 о веселой жизни дальнобойщика... все слушаем, не перебиваем, дед зарабатывает авторитет у ребенка).

- Бабуля, а ты кто?

- Учитель (ну, здесь все понятно)

- Мама, а ты кто?

Все время, пока шел допрос я судорожно думала а чего же ответить  так, чтобы пятилетний "хочувсезнать" понял про полезность работы юристом. Не смогла. Пришлось импровизировать.

- Юристом... (Штирлиц никогда так близко не был к провалу)))

- А чего ты делаешь?

- Ну... на компьютере...

-ААААА, ты в игрушки играешь!

- Ну, еще с разными людьми разговариваю...

- Ты им сказки рассказываешь?!

Во взрослом семействе началась повальная укатайка... Ничем наша мама не занимается на работе! Муж свалил ржать на кухню под предлогом налить чаю. (вернется - убью, подумала я).

Разговор быстро свернули.

Потом, когда чадо уже был в 1 классе мне прислали юридическую энциклопедию для детей, где в стихотворениях прикольно рассказывают про профессию. Ребенку понравилось, утащил в школу, на следующий день мне звонит учительница и слезно просит не давать книжки ребенку в школу, потому что они все читают и срывают учебный процесс, устроили показательный суд над одним из хулиганов, приговорили к стоянию в углу, учительница не смогла вытащить его из угла даже на уроке - "судьи" были против всем классом!

#юрист #профессияюрист

13919

Что получается в результате работы программиста

Дочь учит профессии в школе. Задание - рассказать о работе родителей.

Вопросы:

Кем работает твой папа?

Какие инструменты он использует в работе?

Какие использует материалы?

Что получается в итоге?

Дочь отвечает:

- Программистом.

- Компьютер, клавиатуру, мышь, монитор.

- Чай.

- Ничего.

394

Замкнутый круг - Siemens вокруг!

В последнее время для меня очень остро встал вопрос о смене места работы. По специальности я инженер в области электропривода и автоматики. Стаж по профессии инженера-электроника 10 лет. Ну и решил пойти по собеседованиям. Так вот практически везде, где з/п выше 35000 (на руки), требуются специалисты со знаниями Siemens Simatic Step 7. В институте этому мало обучают, а без этих знаний особо никуда не устроишься. Знания можно получить на специальных курсах, которые стоят в среднем 45-50 тыс. руб. Обычно, за специалиста платит предприятие, но меня на такие предприятия не берут, потому что у меня нет знаний по Siemens. Короче, замкнутый круг. На семейном совете было принято решение самому найти курсы и обучиться за свой счёт. Пока ещё молодой, и есть тяга к знаниям. Мне 32. Ещё лет десять и останусь я киповцем на веки вечные, с обязанностями дышать перегаром на контакты. Уважаемые Пикабушники, есть ли среди Вас кто-нибудь, кто обучался на таких курсах? От предприятия или самостоятельно. Буду рад любой информации, ибо курсов много, стоят недешево и не хочется промахнуться с выбором. Заранее спасибо )

70

Нейронные сети. Градиентный спуск: как учатся нейронные сети

Обучение — сложный процесс не только для человека, но и для сущностей, порожденных разумом человека.

Мы подготовили долгожданное продолжение лекций по нейросетям. Градиентный спуск: как учатся нейронные сети.


https://www.youtube.com/watch?time_continue=1&v=f9oDe4Yq...


Благодарим за участие в выпуске:

Переводчика – lenablur;

Редакторов – Дмитрия Титова, Михаила Коротеева, Дмитрия Мирошниченко;

Корректора – Дмитрия Мирошниченко;

Дикторов – Никифора Стасова, Дарью Яговкину;

Монтажера – Олега Жданова.

1248

Когда потомки увидят твой говнокод

Когда потомки увидят твой говнокод Картинки, Юмор, Программирование, Разработка, Github, IT юмор

Перевод:
"Загрязнение Арктики - это серьезная проблема"
Я, после того как мой говнокод поместили в арктическое хранилище

Компания GitHub рассказала в своем блоге, что 8 июля 2020 года архив открытых исходных кодов сервиса был успешно размещен в арктическом хранилище Arctic World Archive на острове Шпицберген.

Чтобы заархивировать и перевести на физических носителях весь GitHub понадобилось более пяти месяцев кропотливой работы. 2 февраля 2020 года специалисты компании сделали копию всего открытого исходного кода, хранившегося на сервисе — это вклад работы более 37 миллионов пользователей, который включает около 100 миллионов активных публичных репозиториев.

Ссылка на новость - https://habr.com/ru/news/t/511402/

31

Тесты ПУЭ на Xamarin

Не так давно я опубликовал пару постов о приложениях для подготовки к тестированию по электробезопасности. Это простые одностраничные приложения в которых крутятся вопросы по электробезопасности. На странице показывается вопрос и несколько вариантов ответа. Пользователь жмёт в выбранный им вариант. Правильный ответ показывается сразу после выбора варианта ответа. Приложение написано на Xamarin, поэтому среди прочих тегов присутствовали Xamarin и CSharp. Но, как справедливо заметили в комментариях, о Xamarin не было ничего. Исправляюсь.

Ссылки на посты:

Запилил тесты ПУЭ

Выкатил вопросы на 5 группу электробезопасности

Решение на XamarinForms содержит несколько проектов. Главный проект и проекты для каждой выбранной на этапе создания решения платформы.

Здесь была выбрана только одна платформа, поэтому решения два.

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Каждый вопрос с вариантами ответов хранится в классе QuestCase.

Переменная errors - счётчик до выхода вопроса из списка чаще показываемых вопросов. Когда происходит неправильный ответ, errors становится 5. С каждым правильным ответом errors уменьшается на 1. Когда errors становится 0, вопрос исключается из списка чаще показываемых.

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Интерфейс IFileWorker нужен для работы с файлом вопросов/ответов.

Этот интерфейс описан в главном проекте

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

а реализован в проекте для Android в классе FileWorker.

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

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Текст каждого ответа размещается в MyLabel наследованном от Label.

MyLabel знает какой ответ в нем - верный или неверный - свойство isAnswer,

MyLabel запоминает клик по нему - свойство isClicked.

Я использовал BindableProperty для реализации этих свойств.

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Это первая часть поста. Планирую ещё как минимум две.

Показать полностью 5
463

Проект «Качок»

Поступил от одной фирмы заказ. Нужно было разработать мозги для электрической помпы, которую они проектировали. Предназначалась эта штука для проверки датчиков давления в полевых условиях. Собственно, помпа уже была. Ручная. Но, оказалось, что, для того, чтобы накачать 40 атмосфер вручную, нужно быть качком. Качки среди тетенек-метрологов — редкость. Следовательно, ручной труд нужно было срочно механизировать!


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

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

А вот с электронной начинкой что-то пошло не так. Инженеры заказчика сначала попытались сделать все сами. Конечно же на ардуино. Прицепили к ней силовую часть на реле, кнопки, токовый датчик… И, получили что-то очень грустное, и упорно не желающее работать как надо. Но общий принцип и бета версия прототипа у меня была. Осталось все воплотить на более достойном уровне.


По идее, схему сначала как-то прототипируют, пишут софт, а уже потом разводят плату. Но, можно сделать наоборот. В данном случае, схемотехника была примерно понятна. Есть готовый драйвер коллекторного двигателя. Есть контроллер, функционал которого, в любом случае, задается софтом. А это позволяет подключать его ноги практически произвольно. Есть цепи питания и всякой периферии. Проще, сразу развести всё на плате, чем делать двойную работу, собирая на проводках похабную макетку.


Плату буду делать в EagleCAD.


Платка была мелкая, в ограничение демоверсии влезала легко. Первым делом, решил нарисовать цепь питания. Контроллер потребляет мало. Значит, хватит обычного линейного стабилизатора. Делаем ему обвязку из конденсаторов на входе и выходе. Не забываем зашунтировать электролиты керамикой, а то у них огромная индуктивность, и наносекундные импульсы они почти не фильтруют.Так… А чем включать? Актуатор жрёт довольно неслабый ток. А заказчик дал нам гламурную кнопочку, чтоб было красиво. Что делать? Будем усиливать. В разрыв цепи ставится Р-канальный мосфет, который открывается кнопкой. Современные транзисторы могут схавать дикие токи при очень мелких габаритах. Заодно, получаем халявную защиту от переполюсовки.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Чтобы совсем не запутаться, разводим часть платы. Переходим в трассировщик, и ужасаемся. Первое ощущение — ступор и паника. На экране девственно пустая плата. В углу, кучкой, навалены детали, а между ними ктулхическое переплетение соединений. Спутанные наушники видели? А теперь, представьте, что их полный рюкзак.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Растаскиваю компоненты по плате, и начинаю рисовать дорожки. Вроде получается. Часть схемы постепенно обретает вменяемый вид. Переношу на плату стабилизатор. Рисую. Смотрю на результат. Нецензурно ругаюсь. Удаляю часть дорожек и переделываю. Кажется, внутренний перфекционист удовлетворен. Можно идти дальше.


Перехожу обратно к схеме. Впихиваю контроллер. И сразу разъем для программирования. Надо, чтобы чип прошивался прямо на плате. Шить их перед запайкой было бы ни разу не технологично. Рисуем разъемы под кнопки и светодиод индикации. Добавляем делитель напряжения, чтобы измерять, что у нас там по питанию. И, обязательно, гнусную пищалку!

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Снова разводим дорожки. Выясняется, что разъем для программатора впихивается ужасно неудобно. Сейчас бы двустороннюю разводку! Но, прототип решили делать односторонним. Все равно, потом допиливать. Наконец, с помощью такой то матери удается все красиво скомпоновать.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Настало время впихнуть на плату драйвер двигателя. Взяли готовый модуль. По странному стечению обстоятельств, модуль оказался дешевле, чем компоненты, которые на нем распаяны. Причем раза так в три дешевле.


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

Разумеется, модуля в библиотеке EagleCAD нет. Придется рисовать.


Задаем условное обозначение на схеме. Перерисовываем плату, стараясь не ошибиться с габаритами. Игл радует тем ,что координаты начал и концов можно прям цифрами вносить в свойства линий. И не надо ничего подгадывать и считать клеточки. Затем вбиваем соответствие ног на схеме и на плате. Готово!


Впихиваем модуль на плату. Важно правильно развести силовые цепи. Если пустить землю одной линией, то модуль будет создавать помехи контроллеру. Дело в том, что дорожки отнюдь не сверхпроводящие, и при большом токе через земляную линию между её участками может получится неслабый потенциал. Чтобы этого не было, ведем силовую землю прям от источника питания.


Еще несколько штрихов. Разглядываю плату. Правлю мелкие косяки. Кажись, можно воплощать в железе.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

жЫрно печатаю маску с дорожками на бумаге. Через неё мы будем засвечивать фоторезист!

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Если посмотреть бумагу на просвет, видно, что тонер закрашивает её недостаточно плотно. Это плохо. Скорее всего, через такую маску засветится что не надо, и будет брак. На этот случай есть специальная жижа, которая вызывает набухание тонера и его уплотнение. Зовется она Density Toner и купить ее можно в фирмах продающи расходники для типографий. Рублей 400 за баллон стоит, хватает очень надолго. Еще можно шаблон подержать в парах ацетона, от них тонер тоже набухает знатно.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Фоторезист выглядит как тонкая пленка. Её накатывают на плату, засвечивают через маску, и смывают. Там, где на неё воздействовал ультрафиолет, она стабилизируется и так просто уже не смывается. В результате, у нас получается рисунок дорожек.


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

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Фоторезист засвечен и смыт проявителем. Остается протравить плату в хлорном железе.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Полчаса ожидания, и плата готова. Быстро запаиваю все детали. Результат мне нравится. Физически это уже готовое изделие, но без прошивки — труп.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Шел второй час кодинга. Устремив взор в белое безмолвие монитора я пытался разобраться с регистрами незнакомого мне ранее контроллера. В какой-то момент мне захотелось бросить всё, и написать программу на Ардуино… Я обернулся. Ди Хальт смотрел на меня, и с укоризной во взгляде правил лезвие своего кукри, как бы намекая, что не стоит его разочаровывать.


Главная проблема устройства в том, что все надо делать быстро. Помпа давит гидравлику и там, за считанные доли секунды, может накачать огромное давление и все поломать. И надо одновременно и интерфейс обрабатывать и замерять давление. Датчика давления там нет, но косвенно его можно понять по току двигателя. Он ведь напрямую зависит от момента, а момент от сопротивления.


У контроллера нет никакой многозадачности. По кругу выполняется одна единственная программа, в которой и происходит всё интересное. Чтобы многозадачности, все таки, добиться, есть особые приемы. В первую очередь, прерывания.


Прерывания — это особые события, на которые контроллер отвлекается и быстро выполняет куски кода, возвращаясь потом к основной программе. Допустим, прилетел байт в UART. Надо скопировать его в какой-нибудь буфер. Ждать нельзя, а то прилетит следующий, вытолкает из регистра тот, что был, и мы его потеряем. А вот если вынести код, пихающий байты в буфер, в прерывание, то в момент прихода байта контроллер будет его быстренько сохранять, почти не тормозя выполнение основной программы.


Так вот. Я благодарен Ди Хальту, за то, что он сразу заставил меня писать на чистом Си. Начинающие ардуинщики обычно не умеют в прерывания. Так и случилось. В той проге, что написали заказчики, крутился основной цикл. В нем была куча задержек. Они нужны, так как, контроллер тикает миллионы раз в секунду, а переходные процессы в кнопках и датчиках происходят намного медленнее, и на полной скорости он будет ловить кучу ошибок.


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


Пока программа прокручивала цикл с задержками, контроллер безответственно профукивал бросок тока. Уменьшить задержки? Тоже плохо.


Вообще, ардуино не запрещает делать все на прерываниях. Проблем тут две.


Первая — обычно, те, кто учится прогать на ардуино, не копают глубоко. Они просто не знают, что вообще бывают прерывания, регистры, и все такое. Бабуино — это такой особый путь.


Ну и вторая — библиотеки ардуино делают без ведома программиста кучу неведомой хрени, стараясь упростить ему жизнь. В результате, попытки напрямую обратиться к аппаратным ресурсам могут привести к неожиданным глюкам и непонятному времени исполнения. А нам, напомню, надо все делать очень быстро.


(Ну ну, я тут расхвастался зря. Я очень начинающий разработчик, и нифига не умею. Проект то простой. В то время, как есть те, кто делает на ардуино вещи гораздо более крутые. Но, это как раз люди, знающие архитектуру контроллера и копающие глубоко. Ну, или грамотное использование библиотек, написанных такими людьми.)


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


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


АЦП контроллера тикает с определенной частотой. Как только он померял, что на него приходит, он выдает прерывание. Вот в это прерывание я и засунул кусок кода, отвечающий за измерение тока. Туда же засунул измерение напряжения питания. Сварганив простенький конечный автомат. Пригодится.


Получается, что пока основная программа работает с какой-то своей скоростью и задержками, контроллер много раз успевает быстро посмотреть, какой ток у нас в двигателе. И, к тому времени, как программа доходит до условия по току, у нас всегда есть его текущее значение.

Теперь нужно было разобраться с кнопками. У нас целых три таймера. Их можно заставить выполнять что-то в прерывании, в то время, как основной цикл занят своими делами.


Заказчик хотел две сенсорные кнопки. Одна должна включать привод, пока на нее давишь. Вторая включать и выключать.


С первой все совсем просто. Кнопка нажата — есть флаг разрешения работать. Основной цикл врубает движок. Нет — вырубает.


Со второй все чуть сложнее. Простейшее решение, сделать так, чтобы нажатие кнопки инвертировало какой-то флаг. Тычешь один раз — он сменяется с «выкл» на «вкл». Еще раз — наоборот.


Работать это будет. Но, криво. С ложными срабатываниями. Чтобы всё было идеально четко, нужно реализовать конечный автомат. В общем, логику как у авторучки с кнопкой. Нажимаешь один раз, алгоритм поднимает флаг, и переключается в следующее состояние, в котором ждет отпускания кнопки. Нажимаешь второй — флаг сбрасывается, и программа снова ждет отпускания. При этом, нажатие кнопки срабатывает четко, и её не трясет как от болезни Паркинсона.


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

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


Программа уже почти готова. Основной цикл получился не сложный. Но, оброс процессами, вынесенными в прерывания. По сути, это уже многозадачность.


Загружаем код в контроллер. Подаем питание. РАБОТАЕТ!!!

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

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


Настало время допиливания. Первым делом надо было как то нагрузить актуатор, чтобы понять насколько адекватно у нас идет измерение тока. Ведь от тока зависел и момент. Ага, легко сказать. У него усилие в несколько сот килограмм. И я, даже навалившись на него всем весом, не смог бы создать сколь-нибудь ощутимой нагрузки. Ди посмотрел на это, схватил нож и куда то убежал. Вернулся через пять минут с обрезком толстого резиного шланга, сантиметров на 10. Я даже думать не хочу у кого он его отрезал. Натянули шланг на шток актуатора, на манер крайней плоти. Осталось только воткнуть отвертку в отверстие на конце штока, чтобы шлангу не куда было деваться и попробовать его сжать. Сопротивление кусок резины оказал достойное, удалось даже заклинить актуатор, выведя его на максимальную нагрузку.


Нагрузка есть, первым делом, я решил откалибровать датчик тока. Ноги UARTа очень удачно оказались на разъеме, к которому должен цепляться светодиод. Ничто не мешало врубить его в режиме отладки, и подключиться к компу.


Оказалось, что сигнал довольно зашумлен. График слегка колбасило.


Чтобы это побороть, я сделал кольцевой буфер. Контроллер при каждом измерении тока записывает результат в массив, пока не наберется 32 значения. Когда нам нужно узнать ток, мы перемножаем их все, и вычисляем среднее арифметическое. Получился простенький аналог RC цепочки.


Шумы исчезли, осталась только плавная линия, рисующая график того, как мы нагрузили двигло.


А главное, интегрирование значений помогло избавиться от проблемы пускового тока. В момент запуска двигателю нужно преодолеть инерцию, чтобы стронуться с места. В этот момент, он жрет столько, сколько может проглотить. То есть, намного больше, чем при работе. Это мешало откалибровать защиту по току. В момент изменения направления система думала, что у нас перегрузка, и начинала дергать движок в разные стороны, вместо того, чтобы проявить целеустремленность. Интеграция сгладила этот пик, и проблема пофиксилась.


Допилил еще кучу мелочей. Результат мне уже нравился. В какой-то момент, стало ясно, что он соответствует техзаданию, а в чем-то его даже превосходит.


Настало время суровых испытаний.


В торжественной тишине мы внесли устройство в лабу к заказчику. Под барабанную дробь подключили помпу, которой оно должно было рулить. И…


Оно заработало.


И тут выяснилось, что есть одна проблема. Помпа работает как с воздухом, так и с жидкостью. Воздух сжимается. Качать его нужно долго. Жидкость же накачивается до нужного давления буквально мгновенно.


Так вот. Движок давит со всей дури. И пока сработает защита по току (у нас же кольцевой буфер с интеграцией, и заполняется он не сразу), он успевает накачать слишком много.

Уменьшить буфер? Система начинает реагировать на пусковой ток, как на превышение нагрузки.

Начался мозговой штурм. Как бы это быстро поправить прям тут, не переписывая всю программу полностью.


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


Мне представилась пирамида из костылей. Ага. Нужно построить зиккурат.


И тут…


Это похоже на луч света, внезапно озаривший пасмурное небо. Инсайт! Я дописал одну… Всего одну строчку кода! И двигатель стал плавно разгоняться ШИМом, и развивать строго определенное усилие.


При этом, в программе никакой плавной регуляции не было. Никаких таймеров с ШИМ выходом. Никаких циклов, медленно добавляющих ток двигателю. Ничего.


Просто, в прерывание АЦП я добавил строку, которая, если ток становился больше определенного, отключала его до следующей итерации. И этого оказалось достаточно. АЦП тикает с довольно высокой частотой. Значит, он, совершенно естественным образом будет обрезать большой пусковой ток, автоматически создавая ШИМ с нужной скважностью. А индуктивность двигателя его сгладит. Если же движок упрется в препятствие, его усилие, так же, будет ограниченно заданным током.


А что с реверсом по превышению тока? А он никуда не делся. Пока ШИМ ограничивает пиковый ток, кольцевой буфер заполняется его значениями. И, как только, среднее арифметическое станет больше заданной величины, сработает реверс.


Решение оказалось настолько простым и изящным, что я не мог поверить. А что, так можно было?!


Оказалось, да.


Устройство уехало на выставку.


Функциональный прототип готов. Впереди допиливание, ресурсные испытания, ловля оставшихся багов, и, если повезет, предсерийный образец.


Источник

Показать полностью 11
40

Что находится между идеей и кодом? Обзор 14 диаграмм UML

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Аве Кодер! Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?


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


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


UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.


Для тех, кому лень читать и кто предпочитает смотреть и слушать: https://youtu.be/0I9aIP5gKCg


Основные цели дизайна UML:

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

Обеспечить механизмы расширяемости и специализации для расширения основных понятий.

Быть независимым от конкретных языков программирования и процессов разработки.

Обеспечить формальную основу для понимания языка моделирования.

Поощрять рост рынка объектно-ориентированных инструментов.

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

Интегрировать лучшие практики.


Диаграммы UML подразделяют на два типа - это структурные диаграммы и диаграммы поведения.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации.


Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени.


Теперь пару слов о каждой из них


Диаграмма классов

https://youtu.be/sVVJp5a41o4


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


Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

-- Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.

-- Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

-- Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма компонентов

https://youtu.be/OiVyha3sf_I


На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.


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

Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма развертывания

https://youtu.be/Yz8phtJoP7I


Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.

Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.


Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.

В большинстве случаев это включает в себя моделирование конфигураций оборудования вместе с компонентами программного обеспечения, на которых они размещены.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма объектов

https://youtu.be/tVW5oHNfAvc


Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.

Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно - чтобы показать примеры структуры данных.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма пакетов

https://youtu.be/237BWanM4Ak


Диаграмма пакетов - это структурная схема UML, которая показывает пакеты и зависимости между ними.

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма составной структуры

https://youtu.be/nsuJcMNaKeE


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


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма профилей

https://youtu.be/qBws7AfvDL8


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма прецедентов

https://youtu.be/BdAcxboG5No


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

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма деятельности

https://youtu.be/Z8PHBsNXAgc


Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма.

Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.

В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма состояний

https://youtu.be/ojCcUvGfpi8


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма последовательности

https://youtu.be/ycg3njrkk1c


Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма Коммуникации

https://youtu.be/KVLJj9xOq0E


Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма обзора взаимодействия

https://youtu.be/E0OJG8ojEAg


Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Временная диаграмма

https://youtu.be/NKTyDQUkLoM


Временная диаграмма показывает поведение объекта (ов) в данный период времени. По сути - это особая форма диаграммы последовательности и различия между ними состоят в том, что оси меняются местами так, что время увеличивается слева направо, а линии жизни отображаются в отдельных отсеках, расположенных вертикально.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма
Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Зачем в UML столько диаграмм?


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

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

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

Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.

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



Аве!

Показать полностью 17
Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: