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

И такая "открытость" как я понял распространённая практика среди российских компаний

Соглашусь. И чуток добавлю.

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

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

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

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

Блин, во время моего обучения такого не было. Была только книга автора и не полностью документированная sdk.

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

А рассматривали вариант описания API на примере какого цельного проекта, где разные этапы реализации затрагивали разные аспекты API?

Автору за статью огромное спасибо! Жду продолжения.

PS
Когда был курсовой (где-то 2012 год) по написанию модуля для какой-то (на выбор) САПР, выбрали не КОМПАС, по причине слабой документации к API.

Нет, позвольте не согласиться.

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

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

Аргументированная точка зрения. Но позвольте вставить свои 5 копеек.

Была тут интересная статья недавно. И вот как мне кажется, автор статьи говорил про тип дельцов (ну или близких/переходящих в них). А эти люди как раз нацелены на работу.

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

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

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

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

Замечательная статья!
От себя добавлю, что не всегда получается 8 часов работать на одном запале (творческая и интеллектуальная деятельность, как ни как), как разработчик, я могу распределить рабочее время по 4 часа с перерывом в 2-3 часа (на обед + отвлечься). Но ни кто не отменяет доступность 24/7 по средствам связи и готовность включиться в работу в любой момент!

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

Если это человек связанный с ИТ, это одно дело, а если это уверенный пользователь ПК — это другое дело. Эти люди в разной степени знают азы информационной безопасности и могут реализовать разного уровня риски.

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

А можно опрос добавить опрос? Было интересно посмотреть статистику.

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

А ситуация с catch (Exception e) — это вообще из ряда вон выходящее. Хорошо если такая конструкция встречается в 1-2 местах на проекте и она обоснована, но вот в качестве архитектурного шаблона — это издевательство. Викторина какая-то, угадай что я хотел обработать...

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

Собственно первая надежда что ctop на python оттуда и зарадилась.

del

В целом интересный сервис, если еще можно было добавлять любой город и сделать интерфейс для доступа к данным (бот в какой-нибудь чатик или страничка), то было бы классно.С моей стороны могу сказать, что порогом к использованию blablacar, как инструмента для планирования поездок, является отсутствие статистики, которую реализовал автор, но чтобы она появилась надо начать пользоваться им, замкнутый круг какой-то. А вот если прикрутить статистику по произвольному городу, то можно будет пользоваться.
PS
Будете заезжать на прогулку в Брянск, пишите. Можно будет выпить чашечку кофе.

По своему опыту скажу что 1 человек — 1 пресс-форма. Но тут я думаю может быть зависимость от изготавливаемого на пресс-форме изделия.
Софт разный. В основном специализированные модули для CAD. Я встречался с SolidWorks + своя автоматизация. А так есть разные CAD со своими модулями (Creo, NX и т.д.).
Так же должны должны активно использоваться спец софт для проливаемости пластмасс. Могу навскидку сказать: Simpoe, MoldFlow, Moldex3D. Исходя из знаний о дистрибьюторах подобного софта, то отдал бы предпочтение Moldex3D. Если есть какие-то конкретные вопросы, пишите в лс с удовольствием отвечу.

Так же было бы интересно послушать, что используется на ССД.

Соглашусь. Но как говориться из "двух зол"… лучше уметь использовать станки зарубежного производства и делать на них качественную продукцию(отечественную), чем они будут проставить.

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

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

Спасибо за статью! Ждем от вас продолжения по улучшению вашего процесса!

Ну а теперь вопросы, а вы рассматривали электронные варианты досок (к примеру Trello)?
Как идею восприняли "рядовые" инженеры, какие эмоции?
Какие перспективы развития видите в этом инструменте?
А рассматривали вариант применения подходов Agile?
Может не хватает каких-то специфичных для этой сферы ИТ-инструментов в работе процесса?

Спасибо! Все это читается как какая-то магия!

А можете поделиться ссылками на репозитории, было бы очень интересно посмотреть как такие вещи реализуются?

И еще раз мои поздравления!