Не так давно испытала в себе желание заняться низким уровнем и сейчас радостно обнимаюсь с книжкой по Ассемблеру.
Хотелось бы узнать, на сколько сложно не сильно опытному программисту найти работу в области низкоуровневого? И какие соопутствующие темы имеет смысл подтянуть? Имею С/С++ ный опыт 2 года.
Из просмотренных предложений о работе нашла лишь одну вакансию явно предполагающую джуниора, получается что — нужны исколючительно гуру, а для новичков места нет?
В общем, как вы думаете имеет смысл соваться в эту область?
Здравствуйте, Relati, Вы писали:
R>В общем, как вы думаете имеет смысл соваться в эту область?
Можно попробовать вирусного аналитика в Dr. Web. Там как раз и ассемблер нужен, и опыт в C\C++ пригодится.
Подтянуть нужно внутреннее устройство ОС, формат исполняемых файлов.
Никуда не нужен.
Там, где требуется ассемблер — низкоуровневое\системное программирование, реверсинг — ожидают крутых спецов в этих областях (реверсинг, системное программирование), а ассемблер там — это как само собой разумеющееся бесплатное приложение к этим скиллам.
Здравствуйте, Relati, Вы писали:
R>Не так давно испытала в себе желание заняться низким уровнем и сейчас радостно обнимаюсь с книжкой по Ассемблеру. R>Хотелось бы узнать, на сколько сложно не сильно опытному программисту найти работу в области низкоуровневого? И какие соопутствующие темы имеет смысл подтянуть? Имею С/С++ ный опыт 2 года. R>Из просмотренных предложений о работе нашла лишь одну вакансию явно предполагающую джуниора, получается что — нужны исколючительно гуру, а для новичков места нет?
Здравствуйте, _Ursus_, Вы писали:
_U_>Никуда не нужен. _U_>Там, где требуется ассемблер — низкоуровневое\системное программирование, реверсинг — ожидают крутых спецов в этих областях (реверсинг, системное программирование), а ассемблер там — это как само собой разумеющееся бесплатное приложение к этим скиллам.
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, Relati, Вы писали:
R>>В общем, как вы думаете имеет смысл соваться в эту область? T>Можно попробовать вирусного аналитика в Dr. Web. Там как раз и ассемблер нужен, и опыт в C\C++ пригодится. T>Подтянуть нужно внутреннее устройство ОС, формат исполняемых файлов.
Да, и в drweb и касперского смотрела вакансии ))) на это пока ориентируюсь.
Но! Меня немного напрягает, что например, потратив какое-то время подтягивая нужные темы я могу пролететь мимо желаемой вакансии(по самым разным причинам от — "мы закрываем набор" до "просто не день Бэкхема") и получится, что никакой альтернативы нет.
Еще вроде нужны драйверописцы, но тут похоже нужно будет немного другие темы подтягивать в поддержку.
Здравствуйте, antirest, Вы писали:
A>В вирусные аналитики можно...
На это пока и ориентируюсь... ) Но вирусных аналитиков надо едва-едва, к тому же нифига не ясно насколько гуру им нужны или готовы брать и обучать. И куда можно будет податься, если не сростется по какой-то причине.
Т.е. расширить кругозор в эту область может и полезно будет. Но не продвинет к цели — поиску интересной работы.
Здравствуйте, Relati, Вы писали:
R>Не так давно испытала в себе желание заняться низким уровнем и сейчас радостно обнимаюсь с книжкой по Ассемблеру. R>Хотелось бы узнать, на сколько сложно не сильно опытному программисту найти работу в области низкоуровневого? И какие соопутствующие темы имеет смысл подтянуть? Имею С/С++ ный опыт 2 года.
Программисту (т.е., человеку, который пишет программы) надо знать ассемблер в таком объеме, чтобы понимать на концептуальном уровне, во что его программа превращается после того, как над ней поработал компилятор. И тут важнее не исчерпывающее знание системы команд, а понимание, опять же, на концептуальном уровне, как работает процессор. К примеру, важнее понимать, что такое memory barrier и синхронизация кешей, чем знать, как это выразить на ассемблере собственными руками.
Кроме того, иногда бывает полезно посмотреть собственно на сгенерированный код, чтобы понять, почему место, которое выглядит нормально написанным, не работает, как ожидается. Возможно, вам повезет, и вы найдете ошибку в компиляторе — хотя это редкое явление, и мне за 20 лет программисткого опыта так повезло всего раза три.
Ну и наконец, отлаживая программу, не исключено, что вы доберетесь отладчиком до каких-нибудь внутренностей системных библиотек или операционной системы, от которых нет ни исходников, ни отладочной информации — тогда тоже придется понимать, глядя на дизассемблированный код, что здесь происходит и как это сопоставить с последними действиями уже вашего кода.
В общем, уметь читать ассемблер невредно, но не обязательно уметь это делать со скоростью процессора
Бывают еще всякие виды деятельности, которые требуют лучшего понимания ассемблера, но при этом не являются, собственно, программированием. Например, reverse engineering или анализ вирусов. Там умение читать ассемблер может оказаться значительно полезнее.
R>В общем, как вы думаете имеет смысл соваться в эту область?
В обшем и целом, умение программировать универсально, а занимаетесь вы при этом высоким или низким уровнем не так уж важно. Кроме того, большая часть низкоуровневой работы, навроде писания драйверов, интересна только первые три раза, а потом, как руку набьете, обнаружите, что это довольно скучная рутина.
Здравствуйте, Relati, Вы писали:
R>На это пока и ориентируюсь... ) Но вирусных аналитиков надо едва-едва, к тому же нифига не ясно насколько гуру им нужны или готовы брать и обучать. И куда можно будет податься, если не сростется по какой-то причине.
Как вам кажется, после какого количества проанализированных вирусов вас начнет от них тошнить? Я бы больше трех точно не выдержал
Здравствуйте, Pzz, Вы писали:
Pzz>Как вам кажется, после какого количества проанализированных вирусов вас начнет от них тошнить? Я бы больше трех точно не выдержал
Вы разрушаете мою веру в светлую работу рыцарей, защищающих простых пользователей от злобных вирусов, так и норовящих угробить систему
Думаете от этого может тошнить больше, чем от рутинного баг-фикса?
Здравствуйте, Relati, Вы писали:
Pzz>>Как вам кажется, после какого количества проанализированных вирусов вас начнет от них тошнить? Я бы больше трех точно не выдержал
R>Вы разрушаете мою веру в светлую работу рыцарей, защищающих простых пользователей от злобных вирусов, так и норовящих угробить систему
Это не лыцари. Это скорее ассенизаторы
R>Думаете от этого может тошнить больше, чем от рутинного баг-фикса?
Ну, я думаю, кроме рутиного баг-фикса есть много другой работы.
Ну в том, что это полезно — я даже не сомневаюсь ))) Очень радуюсь, когда светлеют некоторые моменты, которые при отладке ранее просто проходили мимо.
Pzz>Ну и наконец, отлаживая программу, не исключено, что вы доберетесь отладчиком до каких-нибудь внутренностей системных библиотек или операционной системы, от которых нет ни исходников, ни отладочной информации — тогда тоже придется понимать, глядя на дизассемблированный код, что здесь происходит и как это сопоставить с последними действиями уже вашего кода.
Вот с такой ситуацией как раз сталкивалась ) Только библиотеки не системные, а закрытые индуские, что только усугубляет ситуацию...
Pzz>В обшем и целом, умение программировать универсально
Умение программировать, конечно универсально в целом, а вот когда доходит до конкретики — неплохо бы знать пачку библиотек и поюзать в работе конкретный язык пару лет
Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )
Здравствуйте, Pzz, Вы писали:
R>>Думаете от этого может тошнить больше, чем от рутинного баг-фикса?
Pzz>Ну, я думаю, кроме рутиного баг-фикса есть много другой работы.
Значит я возможно, где-то не там смотрю... потому что по моему опыту — рутинного баг-фиксинга как раз много( по крайне мере в больших компаниях.
Ну в том, что это полезно — я даже не сомневаюсь ))) Очень радуюсь, когда светлеют некоторые моменты, которые при отладке ранее просто проходили мимо.
Pzz>Ну и наконец, отлаживая программу, не исключено, что вы доберетесь отладчиком до каких-нибудь внутренностей системных библиотек или операционной системы, от которых нет ни исходников, ни отладочной информации — тогда тоже придется понимать, глядя на дизассемблированный код, что здесь происходит и как это сопоставить с последними действиями уже вашего кода.
Вот с такой ситуацией как раз сталкивалась ) Только библиотеки не системные, а закрытые индуские, что только усугубляет ситуацию...
Pzz>В обшем и целом, умение программировать универсально
Умение программировать, конечно универсально. В целом. А вот когда доходит до конкретики — неплохо бы знать пачку библиотек и поюзать в работе конкретный язык пару лет
Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )
Здравствуйте, Relati, Вы писали:
Pzz>>Ну, я думаю, кроме рутиного баг-фикса есть много другой работы.
R>Значит я возможно, где-то не там смотрю... потому что по моему опыту — рутинного баг-фиксинга как раз много( по крайне мере в больших компаниях.
Ну, начинающему трудно найти работу...
Если вы целитесь в программисты, лучше все же искать работу по созданию нового кода, пусть не очень сложного и не за очень большие деньги, чем по починке чужого кода. Ибо работа программиста заключается именно в создании кода.
Ищите, такие места есть. Многие большие компании, типа Интела и Гугля, сознательно набирают неопытных но талантливых студентов "на вырост" — при наличии ресурсов, в т.ч. временнЫх, это более надежный способ получить квалифицированного специалиста, чем попытаться найти готового. Поработаете годика два за умеренную зарплату, но зато уму-разуму научитесь.
Здравствуйте, Relati, Вы писали:
Pzz>>В обшем и целом, умение программировать универсально R>Умение программировать, конечно универсально. В целом. А вот когда доходит до конкретики — неплохо бы знать пачку библиотек и поюзать в работе конкретный язык пару лет
Умение изобретать самостоятельно средней сложности алгоритмы гораздо полезнее, чем знание любой библиотеки. Библиотеку всегда можно изучить, а вот мозги, если их нет, не отрастишь.
Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,
Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM
R>Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )
Учитесь программировать — т.е., писать новый код. Совершенно не важно, в какой области. Важно, чтобы сложность кода росла по мере обучения (сложность не в смысле вычурность, а в смысле сложность и объем задач, которые вы способны решать).
R>Не так давно испытала в себе желание заняться низким уровнем и сейчас радостно обнимаюсь с книжкой по Ассемблеру.
Проблема в том, что "низкий уровень" это далеко не только асм. А обниматься лучше с любимым мужем и ребёнком, правда.
R>Из просмотренных предложений о работе нашла лишь одну вакансию явно предполагающую джуниора, получается что — нужны исколючительно гуру, а для новичков места нет? R>Хотелось бы узнать, на сколько сложно не сильно опытному программисту найти работу в области низкоуровневого?
Очень сложно, — системщики-джуниоры, как правило, никому не нужны. Если только в подмастерья к кому, но пойди найди ещё желающего тратить на это своё время.
R>И какие соопутствующие темы имеет смысл подтянуть? Имею С/С++ ный опыт 2 года.
Сами по себе C и асм ничего не дают, если только ты не собираешься компиляторы писать или в разного рода malware ковыряться. Определись со своей специализацией, потому что ты не сможешь быть "просто низкоуровневым разработчиком". Это обусловлено тем, что каждая из специализаций сама по себе достаточно объёмна: например, человек всю жизнь писавший драйвера для чипсетов nVidia не сможет с разбегу "въехать" в сетевой стек Windows, ему в любом случае понадобиться какое-то время. Равно как и человек, всю жизнь писавший компиляторы, вряд ли осилит написание драйвера-фильтра файловой системы. Т.е. определись сначала с теми задачами, которые привлекают тебя больше всего, и развивай в себе умение решать их и только их, это более эффективная стратегия, чем попытки освоить много и сразу.
R>В общем, как вы думаете имеет смысл соваться в эту область?
Если ты не понимаешь чётко, что делаешь и зачем тебе это, если не чувствуешь, что "лежит душа" к этому, — то однозначно не надо. Как ни крути, всё же это весьма объёмная область и нужно быть готовым к тому, что можешь не стать здесь "гуру" даже и через 5 лет.
Здравствуйте, Relati, Вы писали:
R>Мне бы хотелось понять какие перспективы(в плане работы и задач) есть в этой области и решить двигаться к ним или нет. Потому что сейчас я как бы на распутье — в какую сторону развивать себя как профессионала, чтобы и работу интересную можно было найти и денег )
Pzz сказал все абсолютно верно.
Знание ассемблера само по себе вряд ли принесет тебе работу и много денег. Точнее, такие работы, где кроме ассемблера ничего не нужно, существуют, но их мало, и ориентироваться на них не стоит.
Ассемблер важен как дополнительный скилл, который помогает тебе выполнять свою основную работу быстрее и эффективнее.
Важность ассемблера, как дополнительного умения, зависит от твоей основной работы. Знание ассемблера более важно, если ты программируешь в ядре или на Win32 API и менее важно, если ты пишешь бизнес логику на джаве.
Стоит ли заниматься ассемблером вообще?
Если ты junior developer, и хочешь максимизировать соотношение польза/потраченное время, то лучше займись чем-нибудь другим. Если ты более продвинутый разработчик и начинаешь ощущать, что некоторые вещи тебе сделать сложно без знания ассемблера, а вещи эти важны и тормозят твое развитие, то займись ассемблером.
Здравствуйте, Relati, Вы писали:
R>Подтверждаете мои опасения(
Немного из жизни.
Так сложилось, что ассемблер был моим практически первым языком программирования. На практике несколько раз приходилось подключать нестандартный принтер к компу, делал это на ассемблере (это было во времена DOS). На высокоуровневые языки и высокоуровневые вещи смотрел свысока — это типа не работа для настоящих мужчин, круче меня только скалы, я нахожусь на самом низком уровне и могу все. Кроме ассемблера уважал Си, Си++, но меня крайне беспокоил огромный размер исполняемого файла после компиляции . Соответственно хотел становиться именно системным программистом. Судьба сложилась так, что этому не удалось сбыться — каждый раз, когда я менял работу, меня брали на совершенно новый язык. И вот на практике оказалось, что в большинстве случаев важно не знание низкого уровня (под низцим уровнем я часто подразумеваю сам язык программирования), а именно умение программировать, умение так спроектировать, чтобы изменяющиеся требования реализовывать с минимальными усилиями. И важным скилом оказывается умение эти трубования предугадать.
Ну и далее, делят тут народ смотрю вещи так же, как делил раньше я. Кто занимается системными вещами — тот презирает прикладной уровень. И наоборот. А на деле то именно при разработке особой разницы то нет. API различается, в одном случае это порты контроллера, и надо в нужной последовательности к ним обратиться чтобы достичь результата, во втором случае это набор функций ядра ОС, а в ьретьем случае под API подразумевается набор сущностей предметной области, выраженное через классы и методы, которые тоже в нужный момент надо дернуть в определенной последовательности. Приемы программирования те же, разница в том, что у системщиков предметная область меняется незначительно со временем, за счет чего они могут позволить себе ее знать гораздо лучше.
По поводу ассемблера. Знать полезно всегда. Чем больше языков и подходов знаешь, тем лучший ты программист, тем лучше ты потенциально сможешь программировать на любом языке, хоть и на собеседованиях эти взгляды не разделяют, а считают основным знание своего языка. Тот, кто знает ассемблер, при необходимости мысленно всегда сможет спуститься на уровень процессора и мысленно представить, во что превратится его код. При этом вполне будет уметь выслить высокоуровневыми абстракциями. Тот, кто о низком уровне не знает, будет ограничен исключительно своим языком. Но, так как он не способен спуститься ниже уровня языка, он может не понимать почему язык спроектирован именно так, а не иначе. Он вынужден практически вызубривать некоторые особенности языка, вместо того, чтобы понять принципы. Знание принципов освобождает от необходимости запоминания мелких деталей.
