если рассмотреть один и тот же уровень квалификации, то чел без особых технических знаний, со знанием языка и шаблонным мышлением в банке зарплатой скорее будет доволен, а в современную оборонку без технического бэкграунда шансов и без того мало (а на такую же з/п - вообще под сомнением)
Тут до смешного: любые попытки удешевления труда ведут к его удорожанию. Придумали всякие инструменты, фреймворки и т.д. с целью увеличить количество разработчиков, и за счет увеличения конкуренции и снижения трудозатрат/сокращения времени разработки сократить расходы, это отыграло в короткой перспективе, а потом напротив привело к резкому росту оплаты труда тех самых разработчиков
Это всё манипуляции сознанием. Уже запретили использовать образ врача в рекламе для лекарств. Спасибо за дизлайки конечно, но использование старых добрых мульфильмов, картин и т.д. для рекламы (в т.ч. саморекламы ютуберов) - это уже слишком. Я против.
В каком-то смысле и правильно, что блокируют. То что стало общественным достоянием надо и использовать достойно, как элемент культуры прошлого, а не в качестве инструментов рекламы или раскрутки разного сорта ютуберов.
Хуже-лучше, это очень субьективно. зависит больше от писателя, чем от читателя. Бывает изучаешь какой-нибудь проект на гитхабе и думаешь: о господи, лучше бы тут классов не было, когда на входе в класс у тебя 5-7 строк - френдзона.
Для коллекции Хабра материал весьма ценный. Никогда с Иксами не приходилось на столько низком уровне работать (только через XLib), но в случае если вдруг потребуется - статья есть. Часто находил по другим технологиям ответы на свои вопросы, когда приходилось копать до самых глубин.
Не везде реализовано ООП, если брать мои проекты - то тогда надо всё переводить на C++, а это налагает доп.требования, т.к. используются инструменты статического анализа. Это оборачивание в данном случае не даёт ничего кроме понятного ООПшникам исходного текста и лишних трудозатрат на удовлетворение анализаторов (а без них смысла применять C++ нет, т.к. на нём прострелить себе ногу в разы проще, чем на голом Си). Я кстати очень резкий противник оберточного программирования, и пресекаю любые попытки команды в него скатиться.
Если первая статья - то поздравляю с боевым крещением. А по теме - как раз интересно было бы узнать, почему производитель превращает такие изделия в кирпич.
Только личный опыт. Я видел как подобные вещи люди пытались утрамбовать в классы, в итоге больше половины времени убивали на организацию ООП, от чего страдала реализация, и в последствии структура классов признавалась неудачной. Один из модулей за год пережил 4 варианта - причем крайний был признан руководителем менее удачным по сравнению с предыдущим.
Тут мораль такова, что ООП - это шаблон мышления, и если он прибит гвоздями - то пиши пропало. А в остальных случаях он является лишь инструментом, и разработчик сам выбирает, использовать его или нет.
Как пример(из последнего с чем работал), есть EGL, DRM, X11 и некая аппаратура, которая делает из RGB/RGBA h.264, при этом наиболее комфортным вариантом использования этого было бы собрать всё в некое GUI дав управляющий фассад + полную свободу использования OpenGL не оборачивая его ни во что. С другой стороны крайне интересна работа самой аппаратуры сжатия, т.к. в режимах DRM и X11 там используются принципиально разные подходы, и это никак не приводится к общему знаменателю (можно конечно, но здесь придется очень пожертвовать производительностью ради красовости кода, либо создать псевдо-аналог Qt, где под капотом имплементоры будут очень тесно связаны друг с другом, и оверхед от использования классов будет чудовищным, и внутреннее взаимодействие зафренденых классов будет настолько сложным, что перевод всего на обычный процедурный стиль значительно упростит как разработку, так и дальнейший анализ написанного). Но это справедливо для Embedded, где решает не проц, а аппаратура. На ПЭВМ с этим проще(там как раз решает проц) - но она и дороже на порядок. Что мы имеем на выходе: некий прединициализированный UI с фассадным интерфейсом, набор ВУ-логики, где активно применяется MVC/MVP, SOLID и т.д. и набор процедур, которые всё это поднимают и работают под капотом, написанных в стиле близких к ядру Linux (т.е. С-интерфейсы без ООП вообще)
к сожалению, в бизнесе это очень оправданно, т.к. с одной стороны заказчик внятно не может объяснить, чего он хочет в долгосрочной перспективе, а с другой - команде разработки надо его грамотно "подоить". Agile - как раз для этого удачный инструмент :)
нет. у меня мышление не ООПшное изначально, и подход к разработке аппаратно-зависимый, т.к. аппаратура связана между собой и требует тесного межмодульного взаимодействия(некоторые вещи инкапсулировать не получится, а если имплиментацию зафрендить - то будет совсем дремучий лес). в ООП выносится уже совсем высокоуровневый слой, но если взять по количеству исходных текстов, то это процентов 30-40.
Я нашел баланс путем перехода на процедурный стиль без использования классов. Классы - интеграционная вещь, на голом Си - функциональная. В одном модуле можно спокойно разложить по функциям то, что спокойно заняло бы 3 уровня иерархии.
В погоне за прибылью человек совсем забывает о том, что смертен. Сеньёрами сразу не рождаются. Не будет джунов - придет время, что не станет и сеньеров, и человечество рискует потерять целые отрасли, отдав сейчас их более "дешевой" рабочей силе.
Вот что значит по настоящему талантливый разработчик. Жизнь пропадает в вебе, а мог бы творить чудеса
если рассмотреть один и тот же уровень квалификации, то чел без особых технических знаний, со знанием языка и шаблонным мышлением в банке зарплатой скорее будет доволен, а в современную оборонку без технического бэкграунда шансов и без того мало (а на такую же з/п - вообще под сомнением)
Нет, я против того, чтобы фирмы и ютуберы разного разлива использовали предметы культуры для саморекламы
Тут до смешного: любые попытки удешевления труда ведут к его удорожанию. Придумали всякие инструменты, фреймворки и т.д. с целью увеличить количество разработчиков, и за счет увеличения конкуренции и снижения трудозатрат/сокращения времени разработки сократить расходы, это отыграло в короткой перспективе, а потом напротив привело к резкому росту оплаты труда тех самых разработчиков
Это всё манипуляции сознанием. Уже запретили использовать образ врача в рекламе для лекарств. Спасибо за дизлайки конечно, но использование старых добрых мульфильмов, картин и т.д. для рекламы (в т.ч. саморекламы ютуберов) - это уже слишком. Я против.
В каком-то смысле и правильно, что блокируют. То что стало общественным достоянием надо и использовать достойно, как элемент культуры прошлого, а не в качестве инструментов рекламы или раскрутки разного сорта ютуберов.
Хуже-лучше, это очень субьективно. зависит больше от писателя, чем от читателя. Бывает изучаешь какой-нибудь проект на гитхабе и думаешь: о господи, лучше бы тут классов не было, когда на входе в класс у тебя 5-7 строк - френдзона.
Для коллекции Хабра материал весьма ценный. Никогда с Иксами не приходилось на столько низком уровне работать (только через XLib), но в случае если вдруг потребуется - статья есть. Часто находил по другим технологиям ответы на свои вопросы, когда приходилось копать до самых глубин.
так цена китайской платы с картоприемником и bluetooth 300р
Не везде реализовано ООП, если брать мои проекты - то тогда надо всё переводить на C++, а это налагает доп.требования, т.к. используются инструменты статического анализа. Это оборачивание в данном случае не даёт ничего кроме понятного ООПшникам исходного текста и лишних трудозатрат на удовлетворение анализаторов (а без них смысла применять C++ нет, т.к. на нём прострелить себе ногу в разы проще, чем на голом Си). Я кстати очень резкий противник оберточного программирования, и пресекаю любые попытки команды в него скатиться.
Если первая статья - то поздравляю с боевым крещением. А по теме - как раз интересно было бы узнать, почему производитель превращает такие изделия в кирпич.
Только личный опыт. Я видел как подобные вещи люди пытались утрамбовать в классы, в итоге больше половины времени убивали на организацию ООП, от чего страдала реализация, и в последствии структура классов признавалась неудачной. Один из модулей за год пережил 4 варианта - причем крайний был признан руководителем менее удачным по сравнению с предыдущим.
Тут мораль такова, что ООП - это шаблон мышления, и если он прибит гвоздями - то пиши пропало. А в остальных случаях он является лишь инструментом, и разработчик сам выбирает, использовать его или нет.
Как пример(из последнего с чем работал), есть EGL, DRM, X11 и некая аппаратура, которая делает из RGB/RGBA h.264, при этом наиболее комфортным вариантом использования этого было бы собрать всё в некое GUI дав управляющий фассад + полную свободу использования OpenGL не оборачивая его ни во что. С другой стороны крайне интересна работа самой аппаратуры сжатия, т.к. в режимах DRM и X11 там используются принципиально разные подходы, и это никак не приводится к общему знаменателю (можно конечно, но здесь придется очень пожертвовать производительностью ради красовости кода, либо создать псевдо-аналог Qt, где под капотом имплементоры будут очень тесно связаны друг с другом, и оверхед от использования классов будет чудовищным, и внутреннее взаимодействие зафренденых классов будет настолько сложным, что перевод всего на обычный процедурный стиль значительно упростит как разработку, так и дальнейший анализ написанного). Но это справедливо для Embedded, где решает не проц, а аппаратура. На ПЭВМ с этим проще(там как раз решает проц) - но она и дороже на порядок. Что мы имеем на выходе: некий прединициализированный UI с фассадным интерфейсом, набор ВУ-логики, где активно применяется MVC/MVP, SOLID и т.д. и набор процедур, которые всё это поднимают и работают под капотом, написанных в стиле близких к ядру Linux (т.е. С-интерфейсы без ООП вообще)
к сожалению, в бизнесе это очень оправданно, т.к. с одной стороны заказчик внятно не может объяснить, чего он хочет в долгосрочной перспективе, а с другой - команде разработки надо его грамотно "подоить". Agile - как раз для этого удачный инструмент :)
нет. у меня мышление не ООПшное изначально, и подход к разработке аппаратно-зависимый, т.к. аппаратура связана между собой и требует тесного межмодульного взаимодействия(некоторые вещи инкапсулировать не получится, а если имплиментацию зафрендить - то будет совсем дремучий лес). в ООП выносится уже совсем высокоуровневый слой, но если взять по количеству исходных текстов, то это процентов 30-40.
эмбеддед в последнее время
Я нашел баланс путем перехода на процедурный стиль без использования классов. Классы - интеграционная вещь, на голом Си - функциональная. В одном модуле можно спокойно разложить по функциям то, что спокойно заняло бы 3 уровня иерархии.
В погоне за прибылью человек совсем забывает о том, что смертен. Сеньёрами сразу не рождаются. Не будет джунов - придет время, что не станет и сеньеров, и человечество рискует потерять целые отрасли, отдав сейчас их более "дешевой" рабочей силе.
К сожалению, подобная политика производителей напрочь убивает интерес как к отечественным изделиям, так и к отечественной элементной базе.
Статья хорошая, работа проделана колоссальная, но как потенциальному пользователю с таким подходом - в принципе не интересно.