Понимаю, что для Вашей локации это удивительно и поэтому верится с трудом. Но да! В моих реалиях действительно было невероятно сложно найти работу в IT-сфере вообще! Причём за последнее время я столкнулся с этой проблемой уже дважды.
Забавно... Сколько людей, столько и мнений. Мне показалось, что комментатор как раз не опровергает, а именно разделяет озвученную точку зрения и пока (и только ПОКА) ещё не решился сменить DevOps на что-то другое..
Выбирайте литературу под Ваш текущий уровень вовлечённости в программирование. Если можете читать на языке оригинала, то могу подкинуть ещё тонну книг на английском.
НЕ начинайте с Кернигана и Ричи, как рекомендуют многие источники. Си в той книге сильно отличается от современных компиляторов и 64-битных реалий. Даже более того, там описаны приёмы типа goto, которые давно признаны как потенциально небезопасные.
Когда я начинал, мне очень помогли на форуме https://www.cyberforum.ru/ и я рад что он поныне процветает. Там можно задавать вопросы по непонятным темам и есть много тех, кто искренне готов помочь. Конечно, есть https://ru.stackoverflow.com на русском, но там достаточно токсичное сообщество (хотя... если сравнивать с хабром...). Они тоже могут здорово подсобить — главное не напороться на уже открытую ранее тему и формулировать вопрос чётко и однозначно, чтобы не снесли карму.
Если планируете не для души, но для заработка, то помимо Си придётся доводить знание английского хотя бы до Upper Intermediate уровня. В русско-говорящих странах просто таких заказчиков найти очень сложно — у нас всё делается «хуяк-хуяк и в продакшн» чтобы побыстрее срубить бабла пока конкуренты не отжали, тонкости ни кого не интересуют.
Помимо этого интенсивно общайтесь с GPT. Бесплатный вариант последней четвёртой версии можно получить через браузер Edge, зарегистрировав через него левый аккаунт на майкрософте. На начальном этапе этот инструмент может стать просто спасательным кругом и быстро ввести в технологию. Жаль такого решения не было раньше и каждый ответ на банальные вопросы нужно было вытаскивать из сети клещами — лично у меня не было ментора, которого можно было бы пингануть в любой момент и получить поддержку.
Алгоритмы это тема, которая идёт отдельно от конкретного языка программирования, но со всеми популярными алгоритмами и их принципами из computer science нужно хотя бы ознакомиться в общих чертах, чтобы понимать для чего они и какие задачи позволяют решать.
Помимо теории ещё есть практический аспект — выберете опенсорсный проект, который лично Вам хотелось бы улучшить. Разберитесь в каждой строчке кода этого проекта. Чужие примеры многому учат. Потом реализуйте в этом проекте то самое улучшение. Далее, по мере роста знаний и умений, сами создайте свой опенсорсный проект. Добавьте документацию, автоматизацию сборки, юнит-тесты и продолжайте его развивать. Помимо личного совершенствования это даст возможность продемонстрировать потенциальным работодателям Ваши возможности как программиста.
когда есть масса мест, где используют прекрасный Ансибл
К сожалению инженеров, за последнее время рынок сильно изменился. Где раньше компании боролись за специалистов сейчас идёт борьба за тёплое место в хорошей компании — толковых и высокопрофессиональных инженеров больше чем бизнес может обеспечить. Вот представляю ситуацию, когда изо дня в день ищет DevOps работу 5 месяцев и приходит job offer от компании с puppet. Он такой: "Та ну нахер, не пойду".
Пример интересный и показательный. Долго думал каким именно образом можно проигнорировать проблему такого масштаба и гонял пример разными техническими средствами. Сделал два интересных вывода и хочу ими поделиться:
Пусть статические анализаторы не видят ничего подозрительного в коде, но компилятор явно намекает, что не всё так гладко. Да, это не фатальная ошибка по мнению компилятора, но и gcc, и шланг выдают предупреждение, которое заставляет задуматься:
warning: incompatible pointer types returning 'int *(*)()' from a function with result type 'int *' [-Wincompatible-pointer-types]
2. В нашем распоряжении теперь есть такие замечательные инструменты как ИИ. Обе версии GPT-3 и GPT-4 точно определили где именно проблема и даже предложили исправленный вариант.
Ваш код содержит ошибку. Давайте разберемся, что именно не так.
В функции generate(), вы возвращаете указатель на generate вместо generate1. Это ошибка, так как generate - это имя функции, а не переменной. Вам следует возвращать указатель на generate1.
В любом случае рад Вашему интересу к Си. Только Павел, я не справочник по основам языка и не надо меня ставить в позицию допрашиваемого. Лучше потратьте немного времени, написав несложные программы на Си. Судя по Вашим разносторонним публикациям разобраться в основах и сделать это не составит труда. Я со своей стороны готов помочь со сложностями в коде. Если Вы с таковыми столкнётесь — присылайте примеры, разберём.
Хотелось бы обосновать свой выбор. Он исключительно субъективный, но у меня есть причины.
Зачем мне Golang если я знаю Си на котором могу написать буквально всё. Те же самые "буквально всё" на Golang, к сожалению, не напишешь. Люблю свободу без ограничений.
Если смотреть с точки зрения асимптотической сложности накладных расходов в больших проектах, то производительность программ на Си почти равна возможностям железа и, например, каждое новое клиентское подключение будет потреблять линейное количество ресурсов O(n) или близкое к тому. Накладные расходы любого другого языка программирования с теми же принципами, которые заложены в Golang (например гарбидж-коллектор) никогда не будет линейной, а с значительным коэффициентом.
Упрощу объяснение на выдуманном примере:
а) Программа на Си для одного клиентского подключения потребляет 1Mb и 1/1024 CPU. Для 1024 клиентов она потребит 1Gb и 1CPU. Это, конечно, очень грубое представление — в реальной жизни может быть как меньше ресурсов, так и больше — тут целое поле для оптимизаций.
b) Программа на Golang для одного клиентского подключения потребит 1Mb и 1/1024 CPU, но для 1024 клиентов она потребит 100Gb и 10CPU. Цифры взяты от потолка, прошу не придираться, цель их присутствия только для того, чтобы передать идею накладных расходов, а не принизить достоинства ЯП.
На самом деле изучение computer science подозревается по-умолчанию. Если ставится цель профессионально работать программистом, то без знания алгоритмов, работы памяти, параллелизма и других аспектов делать нечего не только в Сишке, но и в любом другом языке программирования. Однако computer science это такой пласт знаний, в который можно углубляться бесконечно не для практических задач, но ради академических знаний.
Прошу прощения. Меня к тому моменту забанили по политической статье и я уже ничего не смог ни добавить, ни изменить. Правильная ссылка должна была вести на публикацию https://habr.com/ru/articles/656677/. Спасибо @koreecза правильную ссылку.
Если Вы ищете удалённую работу в Google из Тагила, то по очевидным причинам Ваше оформленное не по стандартам принимающей стороны резюме даже не будет рассмотрено. Тогда остаётся вариант предложить изменить локацию. Там автоматически изменится уровень доверия, схемы налогообложения и прочие мелочи жизни, которые работодателю могут быть принципиально важны. А так же откроется возможность рассмотреть варианты hybrid и on-site.
С Вашим английским можно претендовать на очень крутые компании в случае переезда в зону их интересов. А ещё есть масса нюансов типа ATS и правил оформления резюме под конкретного работодателя или правил, относящихся к конкретной стране. Они есть и иногда очень жёсткие, и даже регулируются законом. Поищите комьюнити в социалках, задавайте вопросы именно по той локации, на которую рассчитываете и Вам подскажут как избежать ошибок при подаче резюме и прохождении интервью.
В моей локации у компаний богатый выбор аутсорсеров, но они предпочитают местных только потому, что их можно будет взять за жабры и трепать до конца жизни как того Буратину, в случае если сотрудник превращается в источник проблем.
Ещё вариант присоединиться к международным галерам, специализирующимся на аутсорсе. Но там, как правило, маленькие проекты с коротким сроком жизни... ну хоть руку набить и строчку в резюме добавить и то уже неплохо! Однако... как повезёт... У меня есть друг, который в галерах не первый год и на одном и том же проекте. При этом галеры помогли ему вместе с семьёй и тремя детьми релоцироваться в страну его мечты и он работает по 4 часа в день. При этом все довольны.
Теория Дарвина не всегда работает в IT. Иногда появляются такие уродливые монстры, которые, казалось бы, не имеют права на существование. Но за неимением альтернатив они не только живут и умудряются развиваться, но на их базе строят других монстров. Пример — Java, которая написана на Си, и Scala, которая написана на Java... Почему просто не писать на Си? ;)
P.S. Чувствую, за джаву мне сразу снесут карму, несмотря на смайлики. Надо было привести другой пример... Может котика приаттачить? :-D Не не поможет?
Использование структур для определения классов и их атрибутов достаточно распространённый приём в Сишке. И я согласен что очень удобный. Кроме ядра Linux такое используются в том числе для построения GUI (где-то было упоминание тут в комментариях).
Разница в уровне сложности между нативным OOP в том же C++ и трюками в Сишке. Чтобы не многословить просто укажу ссылку на одну из статей: "Десять вещей, которые я терпеть не могу в ООП" И одной такой заметкой список не ограничивается. Есть много хейта вокруг конкретно C++ и Java именно в ключе их усложнённости ради усложнения, когда программисты с 20 летним опытом просто не могут понять чужой код.
Суть цитируемого раздела заключается в том, чтобы передать мысль: DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу же, как только запахло жареным. DevOps — это недешёвый ресурс, и от таких специалистов избавляются в первую очередь, особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится. Проект функционирует самостоятельно, принося прибыль, и для его поддержки требуется минимум усилий. Или, наоборот, если владелец бизнеса не увидел ожидаемой отдачи от своих инвестиций и начинает сокращать штат, то DevOps-инженеры улетают одними из первых, сразу после дизайнеров. Если в вашей компании начали сокращать дизайнеров — это уже первый звоночек, и пора обновить резюме. :-D Текст написан с долей юмора, но, как известно, в каждой шутке…
Понимаю, что для Вашей локации это удивительно и поэтому верится с трудом. Но да! В моих реалиях действительно было невероятно сложно найти работу в IT-сфере вообще! Причём за последнее время я столкнулся с этой проблемой уже дважды.
Между неприятием и непониманием есть большая разница.
Забавно... Сколько людей, столько и мнений. Мне показалось, что комментатор как раз не опровергает, а именно разделяет озвученную точку зрения и пока (и только ПОКА) ещё не решился сменить DevOps на что-то другое..
Начните с какой-нибудь хорошей книги по Си и алгоритмам. Вот накидал архив, но там всё вперемешку:
Выбирайте литературу под Ваш текущий уровень вовлечённости в программирование. Если можете читать на языке оригинала, то могу подкинуть ещё тонну книг на английском.
НЕ начинайте с Кернигана и Ричи, как рекомендуют многие источники. Си в той книге сильно отличается от современных компиляторов и 64-битных реалий. Даже более того, там описаны приёмы типа goto, которые давно признаны как потенциально небезопасные.
Когда я начинал, мне очень помогли на форуме https://www.cyberforum.ru/ и я рад что он поныне процветает. Там можно задавать вопросы по непонятным темам и есть много тех, кто искренне готов помочь. Конечно, есть https://ru.stackoverflow.com на русском, но там достаточно токсичное сообщество (хотя... если сравнивать с хабром...). Они тоже могут здорово подсобить — главное не напороться на уже открытую ранее тему и формулировать вопрос чётко и однозначно, чтобы не снесли карму.
Если планируете не для души, но для заработка, то помимо Си придётся доводить знание английского хотя бы до Upper Intermediate уровня. В русско-говорящих странах просто таких заказчиков найти очень сложно — у нас всё делается «хуяк-хуяк и в продакшн» чтобы побыстрее срубить бабла пока конкуренты не отжали, тонкости ни кого не интересуют.
Помимо этого интенсивно общайтесь с GPT. Бесплатный вариант последней четвёртой версии можно получить через браузер Edge, зарегистрировав через него левый аккаунт на майкрософте. На начальном этапе этот инструмент может стать просто спасательным кругом и быстро ввести в технологию. Жаль такого решения не было раньше и каждый ответ на банальные вопросы нужно было вытаскивать из сети клещами — лично у меня не было ментора, которого можно было бы пингануть в любой момент и получить поддержку.
Алгоритмы это тема, которая идёт отдельно от конкретного языка программирования, но со всеми популярными алгоритмами и их принципами из computer science нужно хотя бы ознакомиться в общих чертах, чтобы понимать для чего они и какие задачи позволяют решать.
Помимо теории ещё есть практический аспект — выберете опенсорсный проект, который лично Вам хотелось бы улучшить. Разберитесь в каждой строчке кода этого проекта. Чужие примеры многому учат. Потом реализуйте в этом проекте то самое улучшение. Далее, по мере роста знаний и умений, сами создайте свой опенсорсный проект. Добавьте документацию, автоматизацию сборки, юнит-тесты и продолжайте его развивать. Помимо личного совершенствования это даст возможность продемонстрировать потенциальным работодателям Ваши возможности как программиста.
К сожалению инженеров, за последнее время рынок сильно изменился. Где раньше компании боролись за специалистов сейчас идёт борьба за тёплое место в хорошей компании — толковых и высокопрофессиональных инженеров больше чем бизнес может обеспечить. Вот представляю ситуацию, когда изо дня в день ищет DevOps работу 5 месяцев и приходит job offer от компании с puppet. Он такой: "Та ну нахер, не пойду".
Когда же будет продолжение? Не терпится!
Главное, следить за направлением струи, когда идёшь против системы.
Пример интересный и показательный. Долго думал каким именно образом можно проигнорировать проблему такого масштаба и гонял пример разными техническими средствами. Сделал два интересных вывода и хочу ими поделиться:
1. Есть 10 постулатов NASA про безопасный кодинг на Си. Они описаны в статье "10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками" Один из этих постулатов заставляет не игнорировать ни каких warning от компиляторов и выводить их на максимальный уровень.
Пусть статические анализаторы не видят ничего подозрительного в коде, но компилятор явно намекает, что не всё так гладко. Да, это не фатальная ошибка по мнению компилятора, но и gcc, и шланг выдают предупреждение, которое заставляет задуматься:
2. В нашем распоряжении теперь есть такие замечательные инструменты как ИИ. Обе версии GPT-3 и GPT-4 точно определили где именно проблема и даже предложили исправленный вариант.
Вопрос чисто из академического интереса. За что минусуют сообщение, в котором автор статьи благодарит комментирующего за описание его личного опыта?
В любом случае рад Вашему интересу к Си. Только Павел, я не справочник по основам языка и не надо меня ставить в позицию допрашиваемого. Лучше потратьте немного времени, написав несложные программы на Си. Судя по Вашим разносторонним публикациям разобраться в основах и сделать это не составит труда. Я со своей стороны готов помочь со сложностями в коде. Если Вы с таковыми столкнётесь — присылайте примеры, разберём.
Павел, без обид, но у складывается стойкое впечатление, что про Си Вы просто когда-то услышали и услышанное не совсем хорошо запомнилось.
Для полноты набора популярных стереотипов осталось только упомянуть про простреленную ногу.
Спасибо, что поделились личным опытом. Было очень интересно прочесть.
Вот даже страшно было это читать, куда уж себе такое представить...
Ладно, добавлю смайлик. Дружелюбный. :o)
Хотелось бы обосновать свой выбор. Он исключительно субъективный, но у меня есть причины.
Зачем мне Golang если я знаю Си на котором могу написать буквально всё. Те же самые "буквально всё" на Golang, к сожалению, не напишешь. Люблю свободу без ограничений.
Если смотреть с точки зрения асимптотической сложности накладных расходов в больших проектах, то производительность программ на Си почти равна возможностям железа и, например, каждое новое клиентское подключение будет потреблять линейное количество ресурсов O(n) или близкое к тому. Накладные расходы любого другого языка программирования с теми же принципами, которые заложены в Golang (например гарбидж-коллектор) никогда не будет линейной, а с значительным коэффициентом.
Упрощу объяснение на выдуманном примере:
а) Программа на Си для одного клиентского подключения потребляет 1Mb и 1/1024 CPU. Для 1024 клиентов она потребит 1Gb и 1CPU. Это, конечно, очень грубое представление — в реальной жизни может быть как меньше ресурсов, так и больше — тут целое поле для оптимизаций.
b) Программа на Golang для одного клиентского подключения потребит 1Mb и 1/1024 CPU, но для 1024 клиентов она потребит 100Gb и 10CPU. Цифры взяты от потолка, прошу не придираться, цель их присутствия только для того, чтобы передать идею накладных расходов, а не принизить достоинства ЯП.
На самом деле изучение computer science подозревается по-умолчанию. Если ставится цель профессионально работать программистом, то без знания алгоритмов, работы памяти, параллелизма и других аспектов делать нечего не только в Сишке, но и в любом другом языке программирования. Однако computer science это такой пласт знаний, в который можно углубляться бесконечно не для практических задач, но ради академических знаний.
Прошу прощения. Меня к тому моменту забанили по политической статье и я уже ничего не смог ни добавить, ни изменить. Правильная ссылка должна была вести на публикацию https://habr.com/ru/articles/656677/. Спасибо @koreecза правильную ссылку.
Если Вы ищете удалённую работу в Google из Тагила, то по очевидным причинам Ваше оформленное не по стандартам принимающей стороны резюме даже не будет рассмотрено. Тогда остаётся вариант предложить изменить локацию. Там автоматически изменится уровень доверия, схемы налогообложения и прочие мелочи жизни, которые работодателю могут быть принципиально важны. А так же откроется возможность рассмотреть варианты hybrid и on-site.
С Вашим английским можно претендовать на очень крутые компании в случае переезда в зону их интересов. А ещё есть масса нюансов типа ATS и правил оформления резюме под конкретного работодателя или правил, относящихся к конкретной стране. Они есть и иногда очень жёсткие, и даже регулируются законом. Поищите комьюнити в социалках, задавайте вопросы именно по той локации, на которую рассчитываете и Вам подскажут как избежать ошибок при подаче резюме и прохождении интервью.
В моей локации у компаний богатый выбор аутсорсеров, но они предпочитают местных только потому, что их можно будет взять за жабры и трепать до конца жизни как того Буратину, в случае если сотрудник превращается в источник проблем.
Ещё вариант присоединиться к международным галерам, специализирующимся на аутсорсе. Но там, как правило, маленькие проекты с коротким сроком жизни... ну хоть руку набить и строчку в резюме добавить и то уже неплохо! Однако... как повезёт... У меня есть друг, который в галерах не первый год и на одном и том же проекте. При этом галеры помогли ему вместе с семьёй и тремя детьми релоцироваться в страну его мечты и он работает по 4 часа в день. При этом все довольны.
Теория Дарвина не всегда работает в IT. Иногда появляются такие уродливые монстры, которые, казалось бы, не имеют права на существование. Но за неимением альтернатив они не только живут и умудряются развиваться, но на их базе строят других монстров. Пример — Java, которая написана на Си, и Scala, которая написана на Java... Почему просто не писать на Си? ;)
P.S. Чувствую, за джаву мне сразу снесут карму, несмотря на смайлики. Надо было привести другой пример... Может котика приаттачить? :-D Не не поможет?
Использование структур для определения классов и их атрибутов достаточно распространённый приём в Сишке. И я согласен что очень удобный. Кроме ядра Linux такое используются в том числе для построения GUI (где-то было упоминание тут в комментариях).
Разница в уровне сложности между нативным OOP в том же C++ и трюками в Сишке. Чтобы не многословить просто укажу ссылку на одну из статей: "Десять вещей, которые я терпеть не могу в ООП" И одной такой заметкой список не ограничивается. Есть много хейта вокруг конкретно C++ и Java именно в ключе их усложнённости ради усложнения, когда программисты с 20 летним опытом просто не могут понять чужой код.
Суть цитируемого раздела заключается в том, чтобы передать мысль: DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу же, как только запахло жареным. DevOps — это недешёвый ресурс, и от таких специалистов избавляются в первую очередь, особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится. Проект функционирует самостоятельно, принося прибыль, и для его поддержки требуется минимум усилий. Или, наоборот, если владелец бизнеса не увидел ожидаемой отдачи от своих инвестиций и начинает сокращать штат, то DevOps-инженеры улетают одними из первых, сразу после дизайнеров. Если в вашей компании начали сокращать дизайнеров — это уже первый звоночек, и пора обновить резюме. :-D Текст написан с долей юмора, но, как известно, в каждой шутке…