Comments 75
Программирование UI и хорошие практики в нём - отдельная тема, не очень связанная с языком программирования. Хотя, безусловно, интересная, и очень важная для тех разработчиков, кому приходится этим самым UI заниматься.
Как с языка сняли! Мы с коллегами долго думали над этим вопросом, стоит ли как-то акцентироваться на тех же UI фреймворках более подробно и т.д.
Но в конце пришли ровно к тому же выводу, что и вы: UI - тема интересная, но сегодня лучше выбирать другие инструменты для их построения: делать UI на плюсах, все равно что из пушки по воробьям стрелять.
Не согласен с вами. Тащить другой язык в проект на Плюсах, только ради того, чтобы гуй отрисовать - бредятина полная. Я, как программист на языке L, хочу юзать только язык L.
Если коробочной возможности их рисовать нет, а приходится юзать всратую стотонную хрень типа кьюта - то так и скажите. Молодцы разрабы Java, которые изобрели идущий из коробки swing. Молодцы авторы python, которые внедрили tkinter в дистр. А что сделали плюсовики, кроме ещё одного стандарта и способа выстрелить себе в ногу?
Да даже у сишников (правда линуксовых), есть чуть ли не де-факто gtk. У дельфистов - vcl, который также из коробки.
Вот сделают плюсовики возможность гуй из коробки или хотя бы чем-то универсальным пилить - будет неимеоверно круто. А сейчас плюсы - для библиотек, для консольных приложений. Всё остальное (фреймворки по 400 МБ) - из пушки по воробьям, да.
Наболело.
Не думаю, что кто-то на полном серьезе использует tkinter.
Но он есть из коробки, он простой и годится для хоумбрю всякого - самое оно, когда надо наклепать гуй по-быстрому. Что может предложить C++ из коробки? Кроссплатформенные абстракции для FS, для многопоточности и даже для исключений (и все они такие разные для винды и линукса). Ну а дайте-ка мне для гуи абстракцию? - не, не слышал!
делать UI на плюсах, все равно что из пушки по воробьям стрелять
Если посмотреть исходники Виндоуз, которые утекли в сеть, то интерфейс там написан на Си. M$ выложила в опенсорс и исходники MFC, которые тоже написаны на Си / С++. Интерфейсные библиотеки mCtrl / WTL / Win32xx тоже написаны на Си, не говоря уже об интерфейсных монстрах wxWidgets и Qt.
Поэтому я бы не торопился давать оценку Си/С++ для целей создания GUI. Даже если кто-то хочет писать интерфейс на ассемблере, пусть пишет. Можно подумать, что народ не знает, что низкоуровневые языки весьма трудоемкие. Знает! Но интересы у всех разные. Если что-то не нужно одному, то это не значит, что оно не нужно другому. Вопрос не в этом, а в том, как это делать технически грамотно.
Но главную мысль я понял, в вашей «дорожной карте» нет книг по написанию интерфейса пользователя на Си/С++. Другой информации мне уже особо и не нужно. Нет прямой информации, но есть косвенная – смотреть чужой код и учиться. Для этого и книг особо много читать не нужно, главное уметь понимать тексты чужих программ.
ачевсмысле? Прекрасно все делается. Идёшь в github и ищешь c++ winapi. Находишь много разных вариантов фреймворков - на любой вкус и цвет. Другой вопрос, что мало желающих лезть в winapi, оттого в этой теме разброд и шатания.
Технически возможно все, но стоит ли стрелять "из пушки по воробьям"?
Для UI есть более доступные инструменты, на которых можно построить графический интерфейс, но гораздо быстрее/проще/качественнее. Лучше стоять на принципе - каждому инструменты - надлежащее применение. Зачем строить звездолет, когда требуется перетащить пару мешков цемента?
Боюсь даже предположить, что это за более доступные инструменты. Электрон, поди? Тащить браузерный движок для того чтобы нарисовать несколько кнопок — это даже не из пушки, это из ядерной гаубицы. Зато доступно...
Ради нескольких кнопок может быть и не стоит, тогда в рамках дискуссии стоит провести четкую границу: какой UI собираемся строить? Для какого проекта и какого размера?
Если для себя или что-то протестировать, то наверно не стоит мучаться с фронтом и втаскивать любой зоопарк в проект. Может быть и вовсе не стоит кнопки делать, можно и через консоль протестировать то что требуется.
Если это какое-то крупное коммерческое решение - то пилить UI на C++ - очень уж опрометчивое решение. За исключение можно взять легаси-наследие, которое приходится тащить, просто потому что это уже есть, а переписывать никто не берется (тот же UI на MFC и чем-то аналогичном).
В противном случае, определенно стоит смотреть в сторону других стеков, т.к. и специалистов больше, и экспертиза лучше. Все-таки большая часть IT-продуктов живет нынче не на десктопе, а в вебе/мобилках. Отрисовать json-молотилку или очередной crud на C++? Очень и очень спорное решение. Пусть все-таки язык занимается ровно тем, под что он заточен, а не "кнопки двигает" :)
Возможно в этом поле только Automotive стоит особняком, т.к. UI на Qt там прочно занял нишу. Или же Gamedev, т.к. многие вещи, либо на готовых движках пилится, либо свои кастомные велосипеды.
Так что противоречий никаких не вижу. Нужно принимать решение в каждом отдельном случае. Но зачем колхозить на плюсах то, что можно решить гораздо проще и быстрее другими инструментами - остается открытым.
Берём Rad Studio, 5 минут и интерфейс готов.
Проектирование простых интерфейсов в современных реалиях, по моему, совсем не проблема.
Тогда возникает закономерный вопрос: для чего во многих компаниях сидят десятки UI/UX специалистов, которые пытаются построить удобные и дружелюбные интерфейсы?
Я вдоволь насмотрелся на эти "5 минутные" интерфейсы, прямиком из нулевых, где представлены тысячи вкладок в одном окне, а в каждой вкладке десятки и сотни кнопок/выпадающих списков/селекторов и т.д.
Предлагаю все-таки оставить эту вотчину тем, кто лучше разбирается в вопросах взаимодействия с конечным пользователем, и не пытаться быть экспертами в любом вопросе.
Я соглашусь, что если вы делаете какую-то маленькую утилиту для внутреннего использования, то может и не стоит для этого привлекать полноценный штат фронтендеров, и решить вопрос своими силами, но если же это решение направлено на большую целевую аудиторию, то пусть этим займутся профильные специалисты.
А какие проблемы с программированием контролов на WinAPI?
Используете функцию RegisterClassEx, создаёте окно класса CHILD, во флагах указываете, что оно само себя рисует, не имеет оформления и в процедуре окна рисуете и отрабатываете всё что вам надо. Можно запихать таких окон сколько угодно в библиотеку и получится ещё один набор пользовательских элементов управления.
Это очень просто и недорго. Я так делал из интереса на чистом асме когда ещё masm'ом и tasm'ом баловался во времена динозавров (на XP точно работало). Советую найти и скачать win32api_big.chm файл, там весь API очень удобно собран и документирован, работать ничуть не сложнее чем с QT или GTK.
Перед нами стояла задача предоставить различные комментарии по темам, которые вертятся вокруг языка. Мы считаем, что это поможет гораздо больше, нежели чем попытка все запихнуть в объем, охватываемый взглядом. Дорожная карта - автономная и не подразумевает наличие ментора или кого-то ещё (т.к. не всем удается найти себе наставника на самом старте), потому чем больше комментариев - тем меньше неоднозначностей.
К сожалению задать супер четкую последовательность для C++ - довольно сложная задача. Мы начали строить что-то подобное, но в ходе работы поняли, что впихнуть "невпихуемое", не представляется возможным. Такова цена компромисса, за возможность получить обзорную информацию, что нынче ожидается от среднестатистического плюсовика (в отрыве от конкретных специализаций)
Все верно. Секции для миддлов и синьоров предназначены для того, чтобы показать дальнейший вектор развития, когда планка джуниора достигнута. Вопрос роста заботит многих джунов не меньше, чем просто "вкатиться". Так что данные ресурсы - примерный вектор направления их движения.
К сожалению мы не можем удовлетворить всех и вся. Если человек отвалится на мотивационной книге, которая призвана замотивировать, то такому человеку стоит искренне задать самому себе вопрос: "А это действительно то, чем я хочу заниматься и положить на это месяцы своей жизни? Не будет ли разочарования в конце пути?" Наш проект - не инфоцыганство, и не курсы, чтобы заманивать кого-то к себе. Мы лишь "даем удочку", а брать её или нет - решать читателю.
Увы, по плюсам к сожалению нет и не будет "серебрянной пули" (единственной книги), по которой можно будет раз и навсегда преисполниться познанием языка. Да и в других языках ситуациях идет ровно к тому же. Языки растут и развиваются, добавляются новые фичи и возможности, которые не уместить в одну книгу.
Да вы б ваше дерев миро хотя бы в виде текста бы хоть как-то оформили. Навигация по этому делу дико неудобная. Заходишь на сайт и ожидаешь, что вот тут basics, тут вот для тех кто побородатее, а видишь какие-то левые статьи про почему и куда плюсы, легенды и мифы и примерно 0 роадмапа кроме ссылки на Миро.
Надо чтобы было хотя бы какое-то оглавление, хотя бы в таком виде.
├─📁 Step 1
│ ├──📁 Basic operations
│ │ ├──📁 Arithmetic operations
│ │ ├──📁 Log operations
│ │ ├──📁 Bitwise operations
│ │ └──📁 Flow control
│ │ ├──📄 Loops
│ │ └──📄 Conditions
│ ├──📁 Functions
│ │ ├──📁 operators
│ │ └──📁 lambdas
│ ├──📁 Data types
│ │ └──...
│ └── ...
└── ...Мы готовы принять любую помощь от коммьюнити, чтобы дорожная карта приняла иной облик, отличный от текущего. Вы можете помочь нам с переформатированием дорожной карты в текстовом виде, так что с радостью ждем PR'ов.
Изначально было в планах создать дорожную карту, а затем её каждый листик сопроводить дополнительными комментариями/ссылкой на мини-статью в репозитории. В какой-то момент стало понятно, что эта задача для нас слишком масштабная, потому было решено от нее отказаться.
Базовую структуру для подобной организации комментариев мы создали в репозитории, но затем забросили. На тот момент считалось достаточным просто приложить ссылку на страничку гитхаба к каждому листику: https://github.com/salmer/CppDeveloperRoadmap/tree/main/Russian/Notes
Вы хотите сделать примерно тоже самое, или же дополнительно заняться описанием каждого листа?
По-хорошему — было бы неплохо иметь детализацию по каждому из листьев. Но самое основное — Roadmap подразумевает некоторое направление и древо в Miro его не очень-то отражает и было бы неплохо сделать из этого действительно дорожную карту как вырасти в программиста C++ за 21 день.
Плюс часть листьев определенно есть смысл детализировать, тк в вашем миро есть PIMPL, но нет RAII и SFINAE, да и STL, есть Core guidlines, но нет gsl. Фичи разных стандартов тоже в дереве никак не отображены. Есть ветка про сборочные системы, но нет ничего про компиляторы и компилирование без cmake, инфы хотя бы про gcc/llvm/msvc.
К выходным может быть в отдельной ветке намострякую какой-нибудь прототип на zola.
RAII есть - см. ветку "Идиомы", находится рядом с pimpl (Этап 4)
SFINAE есть - см ветку "Шаблоны (Этап 4, предшествует идиомам)
STL есть, названа как "Стандартная библиотека" (не очень удачное название получилось). В ней перечислены основные части STL (Этап 3)
Компиляция представлена в ветке "Компиляторы" (Этап 3 - часть 2)
Про gsl - хорошая ремарка, думаю, что стоит это добавить в карту
Соорудить иерархию - несложно, а вот детализировать листья - уже другой вопрос, да и стоит ли? Информацию по листьям уже можно поискать в книгах/интернете.
Если вы готовы заняться детальным описанием листьев, помимо генерации иерархии, то мы с радостью примем такую помощь, в ином случае - большого смысла сооружать мощную генерацию иерархии карты нет (к тому же кому-то придется это дополнительно поддерживать в будущем :) ).
Не следил за апдейтами карты, так что если появилось — отлично. Можно еще Passkey добавить к идиомам.
Базовые вещи наверное придется расписать. Да и список ссылок рекомендованных к прочтению вроде тоже не нулевой размер имеют.
Библиотеки/фреймворки тоже имеет смысл разделить по типам.
Можно бесконечно долго спорить, что язык C++ — это умирающий язык, что его победит %yet_another_brilliant_language%. Для этих обсуждений мы приглашаем вас в комментарии. Тем временем рынок и желание кандидатов говорят совершенно об обратном: специалисты, владеющие языком, по-прежнему требуются на рынке, а также ощущается их острая нехватка не только в России, но и на международном рынке
Потому что кандидаты хотят денег, а это не вписывается в философию компании?
На рынке представлена масса компаний, которые платят в диапазоне рыночных вилкок и выше. Беда тем компаниям, у которых нет возможностей/желания платить достойно. Вывод напрашивается сам собой: профессионалы сами перетекут туда, где платят хорошо, а где не платят - утекут :)
"Рыночные вилки", "платить достойно" - неопределённые и солидно звучащие термины, используемые вместо конкретных сумм в том случае, когда рабовладелец хочет найти раба. Такие часто жалуются на "нехватку специалистов".
Предлагаю остановить обсуждение этого вопроса, т.к. данная статья ровно о другом.
Если у вас есть желание обсудить несправедливость рынка и иные вопросы, связанные с ушлыми работодателями, то на хабре и других ресурсах представлено полно статей и дискуссий, где вы можете сполна высказаться.
Продолжать же полемику не вижу никакого смысла, все равно никто никому ничего не докажет :)
Мы никого никуда не привлекаем, и никого никуда не пытаемся заманить подешевле. Данный проект - исключительно альтруизм нескольких человек, которые увидели проблему и решили объединиться вокруг нее (и решали её в рамках ограниченного ресурса).
В принципе, для образовательных целей следовало бы создавать Викиучебник. Разве что, с визуализацией исполнения программного кода. Если бы такое можно было бы сделать на самом C++, то это было бы хорошей демонстрацией языка программирования.
Визуализация кода - задумка хорошая, но требует колоссальных ресурсов, времени и сил, чтобы это все довести до адекватного состояния. Да и в целом, уже есть добротные курсы, построенные на данном механизме, к примеру: те же C++ "пояса". С нашей стороны было решено не заходить на данную поляну.
Пояс?
Искусство разработки на современном C++. Курс поделен на этапы. Каждому этапу создатели присвоили "цвет пояса" (по аналогии из боевых искусств), который описывает уровень сложности. Многим этот курс известен, потому его частенько называют коротким названием "Пояса C++".
https://ru.coursera.org/specializations/c-plus-plus-modern-development
"C++ is still ..." - ну-ну, хорошее начало.
Только мне кажется, что вы переборщили с картинками в статье? Да и не техническими англицизмами тоже.
Я давно хочу научиться ++, потому что пишу на самом деле на Си с минимальными плюш-плюшками. Основная проблема с которой я сталкиваюсь — зачем мне всё это в зоопарке, т.е. язык более низкого уровня позволяет написать всё то же самое, хотя и более громоздко.
Походил по ссылкам и посмотрел. В статьях — полезные пункты 10 и 11, там где сами карты — всё ужасно монструозно и взглядом не охватывается. На моем 24" мониторе приходится всё уменьшать… и становится нечитаемо. Если распечатать на А0 и повесить на стенку только.
По моим ощущениям, базовые навыки программирования есть почти у всех — Бейсик в школе, Паскаль в институте. Дальше хочется С++. А каждая возможность С++ она ж не просто так — она зачем-то нужна, вот и хочется описание возможностей с объяснением зачем они нужны и жизненными примерами причем из разных областей. Но это большая работа и непонятно зачем её кому-то делать.
А пока… выглядит так — свалили в кучу общедоступную информацию и переструктурировали оглавления нескольких книжек по С++.
Абстракционизм, паттерны и всякое такое. В плюсах это делается чуть дешевле, но за счёт б0льшего количества "плюшек" выглядит дороже. Нужно (хотя бы вкратце) ознакомиться с историей языка, чтобы понять цель введения той или иной возможности.
Если нужен бульдозер — идешь учится на бульдозериста, а не прикручиваешь моторчик к своей лопате.
Некоторые вещи, например Bluetooth-стек просто написаны под объектную модель. Матрешка непрерывно разворачивается, а потом разрушается при каждом соединении. Также все работает когда соединений несколько. Теоретически можно написать всё на большинстве языков, но проблема в том что таких библиотек в твоем проекте могут быть десятки и каждая потребовала человеко-десятилетий разработки.
То есть проблема что это «не более громоздко», а то что ты это не напишешь никогда — не хватит жизни.
Верно и обратное. Когда кто-то в одиночку грозится переписать большой проект на Rust и С++ то что было написано на Си мне тоже очень смешно. Соревнование с человеко-тысячелетиями труда также окончится ничем, если за тобой не стоит корпорация.
валили в кучу общедоступную информацию и переструктурировали оглавления нескольких книжек по С++
Это и было фундаментальной основой проекта - собрать воедино актуальную информацию, и предоставить её для тех, кто желает изучить язык, и показать примерный вектор движения.
К сожалению, этого и не хватает многим новичками, т.к. за десятилетия жизни языка было выпущено слишком много книг и прочих материалов спорного качества. В момент выбора, новичок скорее бросит эту затею, т.к. потеряется в обилии информации.
Так что "свалить в кучу" - тоже нужно приложить массу усилий: отфильтровать и отобрать то, что в эту кучу стоит поместить, а что отбросить :)
Опять же, есть добротные курсы по C++, но конкурировать с ними - непосильная задача. Наша работа больше для тех, кто предпочитает самостоятельное обучение.
Я как-то беседовал со своим преподавателем в вузе на тему низкоуровневого программирования и плюсов в частности, и я несколько удивился его изумлению и разочарованию касательно того, что сейчас никто не выбирает плюсы в качестве языка для коммерческой работы. В данной связи, как начинающий разработчик, изучающий плюсы и по совместительству студент последнего курса технического вуза, хотел бы вкинуть несколько мыслей на этот счёт, как я это вижу.
Поверхностное изучение в ВУЗе, мнимое представление о том, что C++, это просто "Си с классами"
Именно так и происходит, просто говорят - "Вот, есть с++ и самое главное тут ООП. Можно создавать классы, объекты и в целом код писать удобнее". На этом все объяснения и заканчиваются. В ближайшем будущем ничего кардинально не поменяется, я думаю.
Страх проникаться философией языка, т.к. им была внушена различная мифология, которые отмерли и остались далеко позади
На вопросы моих однокурсников о том, почему вы плюётесь от чистой Сишки и плюсов, ответы были примерно такие:
Уродливый и сложный синтаксис по сравнению с другими языками.
Я уже поделал на нём лабы в универе, больше заниматься любовью с этим говном не хочу.
Борьба с языком, управление памятью, сырые указатели...
Как по мне, синтаксис многословный, но терпимый, мне нравится. К сожалению, STL почти не ковыряют и не знают о существовании умных указателей, как и о том, что в прикладных программах new/delete - моветон.
Лично мне C++ очень нравится и я его выбрал не потому что там в универе он идёт по стандарту, а поскольку я понимаю зачем и для чего он мне нужен. Сейчас ковыряю Unreal и в дальнейшем планирую стать рендерщиком.
Имхо, плюсы - это про идейных ребят, которые интересуются как работает ОС, железки в компьютере, любят скорость. К сожалению, сейчас это довольно нишевая технология и пользоваться спросом среди начинающих разработчиков, к сожалению, будет не очень высоким.
Для большинства джунов дорога с C++ видится либо в Qt, либо в Unreal Engine. (В геймдеве открыт вопрос о ЗП ниже, чем по рынку и возможно кранчи)
Порог входа выше, чем в остальные языки, учиться также придётся дольше. Процитирую одного дядьку из варгейминга - "Если хотите денег, человек за 6-8 мес. может более менее научиться Java, пойдёт в банк и будет получать неплохие деньги. При изучении c++ за такой же срок ты станешь только чуть-чуть джуном. Разница в подготовке программиста год-полтора." Лично пока я изучал этот язык, я забухал на две недели... Хороших и доступных материалов также меньше, как отметили в статье.
Нежелание учиться работать с указателями и памятью на первых порах. Сейчас мейнстрим таков, что GC подтирает за тобой пятую точку.
Вакансий на джуновские позиции мало, что делать для портфолио тоже не совсем понятно. Для вебера - сайт наклепать, для мобильного разработчика - какое-то приложение. На плюсах тоже можно, конечно, какой-нибудь растеризатор написать или трассировщик лучей, но всё-таки, не так очевидно.
Скорее всего потребуется знание университетской математики, поскольку плюсы - это про хайлоад и производительность. Линейная алгебра для геймдевелопера, оптика для рендер-программиста, для HTF какая-нибудь мат. оптимизация...
Для большинства, какой смысл так париться, когда можно пойти клепать формочки для мобилок или сайтов, и зарабатывать не сильно меньше.
Необходимо хотя бы базово понимать как работает железо и операционная система и вообще всем этим интересоваться, большинству это не нужно.
Иногда подобные https://habr.com/ru/post/497114/ статьи от @0xd34df00dговорят тебе в ухо шепотом - "Не лезь туда, оно тебя сожрёт"
Ну и конечно отборнейший мем, который как нельзя кстати, подходит к отладке шаблонов
Спасибо за столь развернутый ответ, что поделились своими впечатлениями про обучение и язык. Вы гораздо лучше передали то, что мы в несколько строчек упаковали в самом начале статьи!
Уродливый и сложный синтаксис по сравнению с другими языками.
Посмотрите на Objective-C и ужаснитесь)
Я бы ещё в минусы C++ добавил: медленная, очень медленная сборка приложений. Отбивает всякое желание писать что-нибудь действительно серьёзное.
Есть такая беда, согласен.
Отчасти это можно лечить грамотной декомпозицией проекта на компоненты, а также обертыванием этих компонентов в пакеты. Но для этого нужно очень много ресурсов, а также высокая культура/дисциплина среди разработчиков. Но это также вызывает другие проблемы, связанные с поддержкой единственно правильной версии компонента, когда его растащат в десятки дочерних кусков проекта.
Вечная борьба, которую пока никто так и не смог возглавить и одержать полноценную победу.
Ну то есть, разумеется, медленность сборки сама по себе — конечно, большой минус, тут и обсуждать нечего. Все хотели бы ускорить сборку.
Но всё это ведь во имя большой цели — кодогенерации и вычислений всего, чего можно, в компайл-тайме. Благодаря строгой типизации и шаблонным алгоритмам C++ позволяет наворотить абстракций, и получить почти такое же быстрое выполнение, как без них.
Поскольку всё сразу хорошо не бывает, мне кажется, к этому следует относиться именно как к двум сторонам одной медали. Ну и никто не заставляет писать на плюсах там, где они не нужны. Можно же выбирать инструмент под задачу.
Я как-то беседовал со своим преподавателем в вузе на тему низкоуровневого программирования и плюсов в частности, и я несколько удивился его изумлению и разочарованию касательно того, что сейчас никто не выбирает плюсы в качестве языка для коммерческой работы.
Зависит от компании на самом деле. Трейдинг, самоходные кареты, базы данных, антивирусы, оптимизация всего и вся - это всё C++ и коммерческая разработка. Работы на C++, безусловно, меньше чем на Java/C#, но человеку обычно нужна одна позиция.
Если вдруг нравится C++ - его вполне можно использовать как основной язык, разве что порог входа высокий, что многих отпугивает.
Хотел написать про книги.
1.
Томас Кормен - Алгоритмы. Вводный курс максимально бы не советовал эту. Она сложная. Об этом говорят и комментарии на амазоне\quora и самому мне так показалось.
Есть великолепная книга про алгоритмы для новичков, но к сожалению только на англ:
A Common-Sense Guide to Data Structures and Algorithms ( https://www.amazon.com/Common-Sense-Guide-Structures-Algorithms-Second/dp/1680507222 ).
Автор пишет, что она oversimplified, но она правда крута. Также у автора где-то есть статья про то, как проводить алгособесы, всем советую найти и почитать :)
2.
Андрей Созыкин - Компьютерные сети. Базовый курс
Слушал этот курс. Не спорю, что вещи говорятся верные, но мне кажется, что хорошим он будет казаться только, если сети уже понимаешь. Я слушал, когда не знал сети и особо пользы не нашел.
Таненбаума джунам тем более нельзя читать для базового понимания)
Мне сложно тут говорить, ибо сам в поисках, но пока, есть подозрения, что будут лучше:
2.1 Книга Олиферов по сетям (не та, которая большая, как Таненбаум, а короткая в 300 стр).
2.2. Курс ссна
3.
Эндрю Таненбаум - Современные операционные системы
Я понимаю, любовь к Таненбауму, и, что это классика, и, что во всех университетах она в списке рекомендованной литературы скорее всего, но блин - это Таннебаум. Я к своему горю прочитал его сети и архитектуру, сейчас же считаю, что лучше бы прочитал вместо каждой по две более легкие книги, а в эти бы заглядывал, как в справочник.
По операционкам есть просто великолепная (опять же без перевода на русский):
Operating Systems: Three Easy Pieces ( https://pages.cs.wisc.edu/~remzi/OSTEP/ ) - ее читать было сплошным удовольствием.
Я понимаю, что мои "советы" не будут супер полезны, т.к. про сети я толком сам не знаю, что есть хорошего, но просто против советов о Таненбауме, а остальные две книги только на английском, но надеюсь кому-то всё же пригодится.
Спасибо за подробный и развернутый фидбек! Советы подобные вашему - очень ценны для нас, т.к. вы предлагаете альтернативные источники, по которым можно изучить те или иные вещи, но о которых не слышал, ни я, ни коллеги.
Мы обязательно изучим присланные вами книги и ресурсы. Я уверен, что это сможет найти своей отражение в списке литературы :)
Про Таненбаума я с вами полностью согласен, что для джунов это будет рановато, потому эта книга и отправилась в раздел "Middle". Я полагаю, что одна из присланных вами ссылок может спокойно прикрыть нишу по ОС и сетям в разделе "Junior".
Читал архитектуру Таненбаума и очень не зашла. Прямо максимально. Но прочитав половину Современные операционные системы, был в восторге. Лучшая книга наверное про ОС.
Очень интересная идея с roadmap. Также понравилось, что єсть список рекомендованной литературы для каждого уровня скила разработчиков. Нужно будет детально изучить всё из списка, чтобы понять, насколько всё это соответствует, но думаю из вашего опыта должно быть актуально! Включение в список не техническую литературу (книги об мотивации и подобное) решение, которое достойное похвалы.
Класс! Какие же вы молодцы, ребята. Ваша работа поможет многим
Cmake, Conan и Ninja?
Зачем над людьми издеваться?
Есть premake, есть xmake (который вообще заменяет сразу несколько инструментов)? Зачем мучить людей тридцатилетним легаси?
Если скажете что "они популярные, надо чтобы люди ориентировались", то тогда обучайте сразу всей дико фрагментированной и несовместимой "экосистемой" с++:
Собственно я и начну с ответа, что "они популярны", и представлены практически повсеместно во многих крупных проектах.
Я понимаю, что модное/стильное/молодежное всегда вкуснее и приятнее, нежели чем "проклятое" легаси. Никто не запрещает изучать модные штучки, но придя на проект, скорее всего придется столкнуться с богоугодными Cmake/Conan/Ninja. Если о них не упомянуть, то может случится большое разочарование у новоиспеченного плюсовика.
Подобные штуки - факультатив, который можно будет изучить в любое время, а возможно даже внедрить в свой проект, но это совершенно другая история. Да и к тому же все эти штучки: "Старые песни о главном". Посмотрев на основы, можно спокойно преисполняться новыми реинкарнациями пакетных менеджеров/менеджеров зависимостей.
Забавно, что всем трём упомянутые в первой строке инструментам меньше 30 лет, а Conan и Ninja релизнулись раньше чем xmake с premake.
У вас вышла дорожная карта по изучению мемов.
50 комментов и никто не скинул это? Исправляю.
На мой взгляд, есть еще очень большая проблема вот какого плана: если гуглить по-английски любые вопросы по С и С++ - попадаешь на stackoverflow и cppreference, а если гуглить по-русски, то оказывается, что ресурсов-то особо и нет!
И в выдаче будет либо машинный перевод того же stackoverflow, либо какой-нибудь простите cyberforum, где точно такие же джуны обмениваются кодом даже не обернутым в теги.
Учебники вроде как есть, но их много и они большие, а вот на короткий простой вопрос ответ хрен найдешь.
И видеокурсов тоже как-то не густо русскоязычных.
Соответственно за эту дорожную карту вам большое спасибо :)
Вот есть сайт как раз для формирования подобных роадмапов с привязыванием обучающих материалов: https://infinite.education/skillset/linux_administrator
Из крутого: там можно отмечать что ты уже знаешь, а что не знаешь. Круто было бы оформить роадмап в этом формате
Спасибо за статью !
Мне кажется, что хорошая дорога в C++ лежит через другие языки (Java, C#…может быть Python или Go)…
Мне как разработчику чьи основные инструменты это Java и Python очень интересен С++ для высокопроизводительных бэкендов)
Мне кажется, что хорошая дорога в C++ лежит через другие языки (Java, C#…может быть Python или Go)…
Обратный путь еще проще. Опытный программист на C++ легко пишет на фактически любом языке (фактически - на Haskell он(а) легко не пишет). Адекватные работодатели легко берут человека с опытом в C++ на любой другой стек. В крайнем случае я так скакал и на Java, и на Elixir, и на Go. Обратных случаев не видел, к сожалению.
Я бы сказал, что это двунаправленная связь, например яндекс спокойно берёт людей с опытом на других языках для своих C++ проектов)
Спустя некоторое время работы, уже особо нет разницы на каком языке ты пишешь) Правда очень желательно чтобы языки были из одной области..Например, java разработчику особо нет смысла изучать js(другая область,специфика) ,но есть смысл изучить скажем golang (из-за его многопоточной модели)
Дорожная карта по изучению C++