Москва.
Ваши мысли об окладе девелопера на Mac/Unix C/C++ Boost/STL , среднего уровня, с опытом 5+ лет. В основном системный девелопмент, но ничего сложного.
Насколько редок данный тип девелопера в Москве? Как лучше его искать?
Здравствуйте, test1234, Вы писали:
T> Москва. T> Ваши мысли об окладе девелопера на Mac/Unix C/C++ Boost/STL , среднего уровня, с опытом 5+ лет. В основном системный девелопмент, но ничего сложного. T> Насколько редок данный тип девелопера в Москве? Как лучше его искать?
Первая мысль — зачем компании нужен девелопер "на Mac/Unix C/C++ Boost/STL ..."?
Здравствуйте, test1234, Вы писали:
T> Москва. T> Ваши мысли об окладе девелопера на Mac/Unix C/C++ Boost/STL , среднего уровня, с опытом 5+ лет. В основном системный девелопмент, но ничего сложного. T> Насколько редок данный тип девелопера в Москве? Как лучше его искать?
Тип, по совершенно непонятным мне причинам, крайне редкий. Просто за рекомендацию такого человека сейчас дают 1000 евро
Самому же человеку с такими знаниями дают около 120-150 тыр.
Где искать совершенно не понятно (если узнаешь где искать — ты напиши), т.к. похоже что их просто нет
T> Насколько редок данный тип девелопера в Москве? Как лучше его искать?
Да практически не встречается.
Можете поискать, от 130 тысяч чистыми на руки.
Основной вопрос — вам _ТОЧНО_ нужен такой специалист? Редкая штука же. Может, возьмете обычного Unix C/C++ тысяч за 100-120 на руки, и пущай подучится специфике MacOS.
Здравствуйте, test1234, Вы писали:
T> Москва. T> Ваши мысли об окладе девелопера на Mac/Unix C/C++ Boost/STL , среднего уровня, с опытом 5+ лет. В основном системный девелопмент, но ничего сложного. T> Насколько редок данный тип девелопера в Москве? Как лучше его искать?
Здравствуйте, test1234, Вы писали:
T> Москва. T> Ваши мысли об окладе девелопера на Mac/Unix C/C++ Boost/STL , среднего уровня, с опытом 5+ лет. В основном системный девелопмент, но ничего сложного. T> Насколько редок данный тип девелопера в Москве? Как лучше его искать?
А у вас надо обращать списки и есть ли у вас 23х летние манагеры,программирующие с 12 ти лет?
B>Ну хоть гномиков считать или гору фудзияму двигать?
Кажется, мудрый собеседователь может уже использовать знание этих задач как признак "профессионального кандидата" . Я про этих гномиков не знаю, и знать не хочу.
А системных программистов много, просто они реже меняют работу, чем прикладники, поэтому меньше отсвечивают.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, test1234, Вы писали:
T>> Москва. T>> Ваши мысли об окладе девелопера на Mac/Unix C/C++ Boost/STL , среднего уровня, с опытом 5+ лет. В основном системный девелопмент, но ничего сложного. T>> Насколько редок данный тип девелопера в Москве? Как лучше его искать?
KP>Тип, по совершенно непонятным мне причинам, крайне редкий. Просто за рекомендацию такого человека сейчас дают 1000 евро KP>Самому же человеку с такими знаниями дают около 120-150 тыр. KP>Где искать совершенно не понятно (если узнаешь где искать — ты напиши), т.к. похоже что их просто нет
Ну я например такой. Только с одной оговоркой — если под Мак надо разрабатывать на Objective-C, то я пас. Так как во-первых скорее всего гуй, а во вторых не люблю я эту надстройку над С.
Здравствуйте, kaa.python, Вы писали:
T>> Москва. T>> Ваши мысли об окладе девелопера на Mac/Unix C/C++ Boost/STL , среднего уровня, с опытом 5+ лет. В основном системный девелопмент, но ничего сложного. T>> Насколько редок данный тип девелопера в Москве? Как лучше его искать?
KP>Тип, по совершенно непонятным мне причинам, крайне редкий. Просто за рекомендацию такого человека сейчас дают 1000 евро KP>Самому же человеку с такими знаниями дают около 120-150 тыр. KP>Где искать совершенно не понятно (если узнаешь где искать — ты напиши), т.к. похоже что их просто нет
Вот любите вы, работодатели, искать себе проблемы на ровном месте. Ну возьмите просто среднего девелопера, без Mac. Да даже и без Unix. Тысяч за сто или даже меньше. И за месяц-другой в рабочем процессе обучите основам Mac\Unix — закройте вакансию и получите профит! Так нет же, будете годами искать и плакаться.
Здравствуйте, pvirk, Вы писали:
P>Вот любите вы, работодатели, искать себе проблемы на ровном месте. Ну возьмите просто среднего девелопера, без Mac. Да даже и без Unix. Тысяч за сто или даже меньше. И за месяц-другой в рабочем процессе обучите основам Mac\Unix — закройте вакансию и получите профит! Так нет же, будете годами искать и плакаться.
Вместо вступления: я не работодатель и даже (сейчас) не участвую в поиске сотрудников
, чуть раньше тебя запостили. Этот ответ очень показателен, кстати. Чем брать людей которым все будет не нравится, а на такое уже при переходе Юникс/Виндоуз программистов на Мак было, лучше уж взять готового.
Здравствуйте, kaa.python, Вы писали:
KP>Вместо вступления: я не работодатель и даже (сейчас) не участвую в поиске сотрудников
Пардон, мне так показалось.
KP>По делу. Погляди на вот этот ответ
, чуть раньше тебя запостили. Этот ответ очень показателен, кстати. Чем брать людей которым все будет не нравится, а на такое уже при переходе Юникс/Виндоуз программистов на Мак было, лучше уж взять готового.
Так если нет готовых? А несогласных можно элементарно отсеять — главное сразу в вакансии описать ньюансы, они и сами не придут.
Здравствуйте, pvirk, Вы писали:
P>Так если нет готовых? А несогласных можно элементарно отсеять — главное сразу в вакансии описать ньюансы, они и сами не придут.
Если юниксоид хочет пойти в Мак разработчики — он просто пришлет резюме на такую вакансию, различие межде BSD и маком не шибко уж великие. А если не шлет — значит не так то и хочется.
KP>Тип, по совершенно непонятным мне причинам, крайне редкий. Просто за рекомендацию такого человека сейчас дают 1000 евро KP>Самому же человеку с такими знаниями дают около 120-150 тыр. KP>Где искать совершенно не понятно (если узнаешь где искать — ты напиши), т.к. похоже что их просто нет
Несколько месяцев назад знакомый в Москве искал. Больше 10 лет опыта, Windows / Mac / Nix / C / C++ / Objective-c / еще-дофига-всего. Cocoa лучше меня знает . Так ему больше 110к нигде не предложили, в результате продлил контракт на текущем месте работы .
, чуть раньше тебя запостили. Этот ответ очень показателен, кстати. Чем брать людей которым все будет не нравится, а на такое уже при переходе Юникс/Виндоуз программистов на Мак было, лучше уж взять готового.
Классно — человек говорит, что гуем заниматься нет желания, а ему ярлык всем недовольного навешивают
Здравствуйте, MTD, Вы писали:
MTD>Классно — человек говорит, что гуем заниматься нет желания, а ему ярлык всем недовольного навешивают
Какой смысл в Мак разработчике, который наотрез отказывается работать с GUI? Для работы исключительно с демонами/XNU хватит BSD-разработчика.
А то, придется написать/поправить что-то гуевое, а тут тебе "я же предупреждал что не буду!".
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, MTD, Вы писали:
MTD>>Классно — человек говорит, что гуем заниматься нет желания, а ему ярлык всем недовольного навешивают
KP>Какой смысл в Мак разработчике, который наотрез отказывается работать с GUI? Для работы исключительно с демонами/XNU хватит BSD-разработчика. KP>А то, придется написать/поправить что-то гуевое, а тут тебе "я же предупреждал что не буду!".
Да, в маленьких командах, где каждый то гуй, то демоны пишет, нужны универсалы. Теперь понятно почему, вы говорите, что таких не найти — не могу представить скажем специалиста по сетевым приложениям, который стал бы писать гуй и наоборот. Мое мнение — каждый должен заниматься своим делом.
Здравствуйте, kaa.python, Вы писали:
KP>Какой смысл в Мак разработчике, который наотрез отказывается работать с GUI? Для работы исключительно с демонами/XNU хватит BSD-разработчика. KP>А то, придется написать/поправить что-то гуевое, а тут тебе "я же предупреждал что не буду!".
Objective-C это капролит мамонта, вот человек и не хочет копаться не пойми в чём.
Здравствуйте, kaa.python, Вы писали:
KP>Очень не профессионально.
Смысл осваивать и писать на Obj-C если работы на C/C++ в разы больше? На C/C++ можно писать под виндой, никсами, линухой, маком, а Obj-C для гуя и ORM это только на маке.
Здравствуйте, MTD, Вы писали:
MTD> Теперь понятно почему, вы говорите, что таких не найти — не могу представить скажем специалиста по сетевым приложениям, который стал бы писать гуй и наоборот.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, MTD, Вы писали:
MTD>> Теперь понятно почему, вы говорите, что таких не найти — не могу представить скажем специалиста по сетевым приложениям, который стал бы писать гуй и наоборот.
KP>Я Не люблю, но пишу, если надо.
Ой, вот не надо делать из себя героя. Я тоже могу написать все, что потребуется, при этом отдаю себе отчет, что человек специализирующийся на чем то конкретном, сделает это лучше универсала. Или в вашей компании нет задачи делать по настоящему качественные продукты, достаточно чтобы просто работало?
Здравствуйте, MTD, Вы писали:
MTD>Ой, вот не надо делать из себя героя. Я тоже могу написать все, что потребуется, при этом отдаю себе отчет, что человек специализирующийся на чем то конкретном, сделает это лучше универсала.
Однозначно. Только подход "не буду", на мой взгляд, крайне не профессионален. Вот и все. И да, я, при наборе специалистов, предпочел бы не брать человека с подобной позицией.
MTD>Или в вашей компании нет задачи делать по настоящему качественные продукты, достаточно чтобы просто работало?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, MTD, Вы писали:
MTD>>Ой, вот не надо делать из себя героя. Я тоже могу написать все, что потребуется, при этом отдаю себе отчет, что человек специализирующийся на чем то конкретном, сделает это лучше универсала.
KP>Однозначно. Только подход "не буду", на мой взгляд, крайне не профессионален. Вот и все. И да, я, при наборе специалистов, предпочел бы не брать человека с подобной позицией.
Значит я плохой профессионал — полы например мыть не буду, хоть и умею. И на работу, где требуется то на С писать, то на Бейсике в зависимости от лунных фаз, тоже устраиваться не буду
Здравствуйте, MTD, Вы писали:
MTD>Значит я плохой профессионал — полы например мыть не буду, хоть и умею. И на работу, где требуется то на С писать, то на Бейсике в зависимости от лунных фаз, тоже устраиваться не буду
Передергиваешь, аналогия с уборкой не уместна. Речь лишь о том что ситуации в проекте бывают разные. Обычно ты делаешь что-то в одной области, тем не менее иногда, бывает надо сделать что-то в другой области. А может и не бывает, как получится.
Здравствуйте, kaa.python, Вы писали:
KP>Передергиваешь, аналогия с уборкой не уместна. Речь лишь о том что ситуации в проекте бывают разные. Обычно ты делаешь что-то в одной области, тем не менее иногда, бывает надо сделать что-то в другой области. А может и не бывает, как получится.
Передергивание началось раньше. Я могу написать скрипт на Питоне, могу накидать гуй на Cocoa, но заниматься постоянно (ключевое слово) этим я не хочу, так как позиционирую себя как С++ разработчика и именно это моя сильная сторона.
Здравствуйте, MTD, Вы писали:
MTD>Ну я например такой. Только с одной оговоркой — если под Мак надо разрабатывать на Objective-C, то я пас. Так как во-первых скорее всего гуй, а во вторых не люблю я эту надстройку над С.
а почему не любишь Objective C?
я вот тоже как-то криво смотрел на ОБжектив С мол надстройка над С и т.д.
тут недавно почитал доки по Обжектив С — поменял свое мнение на противоположное — очень неплохой язык.
посему, еще раз, в чем кривизна Обжектив С ?
Здравствуйте, oncer, Вы писали:
O>посему, еще раз, в чем кривизна Обжектив С ?
Например, механизм сообщений позволяет посылать сообщения объекту который их не поддерживает (аналог вызовов методов в С++), что приводит к сущему аду из-за опечаток.
Здравствуйте, MTD, Вы писали:
MTD>Например, механизм сообщений позволяет посылать сообщения объекту который их не поддерживает (аналог вызовов методов в С++), что приводит к сущему аду из-за опечаток.
Ничего такого и близко не наблюдается, все подобные ошибки отлавливаются компилятором. Другое дело, что несмотря на кучу достоинств при разработки UI, язык действительно выглядит как копролит мамонта.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, MTD, Вы писали:
MTD>>Например, механизм сообщений позволяет посылать сообщения объекту который их не поддерживает (аналог вызовов методов в С++), что приводит к сущему аду из-за опечаток.
KP>Ничего такого и близко не наблюдается, все подобные ошибки отлавливаются компилятором.
Всегда приятно поговорить с настоящим профессионалом-универсалом
#import <objc/Object.h>
#include <stdio.h>
@interface Bar : Object
{
}
- (void) justPrintHello;
@end
@implementation Bar
- (void) justPrintHello
{
printf("Hello!");
}
@end
int main()
{
id obj = [[Bar alloc] init];
int i = 5;
if (i == 7)
[obj justPrinthello];
return 0;
}
Ты из тех разработчиков, которые считают "если компилирует — значит работает"? Но этот подход ни с C++, ни с C ни с Objective-C не работает. Ты уверен что на C++ пишешь? Итак, если забить на использование Object вместо NSObject, на что, кстати, компилятор выдал вот такое предупреждение:
Class method '+alloc' not found (return type defaults to 'id')
То остается следующее предупреждение:
Instance method '-justPrinthello' not found (return type defaults to 'id')
Которое нам как бы намекает на то, что такого метода, там, где ты его пытаешься вызвать, нет. Чего в нем загадочного и не понятного?
Здравствуйте, MTD, Вы писали:
MTD>Я уже что понял, что ты Objective C знаешь на уровне "Программирование на Маке за 20 минут" MTD>Универсалам физкульт-привет!
Про второе предупреждение компилятора комментарии будут, или ты таким странным способом признаешь то что слил в данном вопросе?
, чуть раньше тебя запостили. Этот ответ очень показателен, кстати. Чем брать людей которым все будет не нравится, а на такое уже при переходе Юникс/Виндоуз программистов на Мак было, лучше уж взять готового.
Дык в вакансии и на собеседовании нужно прямым текстом говорить чем прийдется заниматься и не будет недовольных. Типа вот так (для вашего случая):
"Требуется маковый разработчик или разработчик с с юниховым бекграундом для разработки (гуевого приложения? системного сервиса? драйвера? игрушки? нужное подчеркнуть) на Мак. Знакомство с маком на уровне пользователя, с ифоном, обжектив-с на уровне программиста приветствуется".
А не так как у нас народ любит делать: крупный интересный проект, мультимедия, сервер-сайд, хайл-лоад, булшит паттерн; приходишь: вот тут у нас есть легаси овно, в котором надо бы баги в гуях пофиксить.
Здравствуйте, kaa.python, Вы писали:
KP>Про второе предупреждение компилятора комментарии будут, или ты таким странным способом признаешь то что слил в данном вопросе?
Ох уж эти универсалы Боюсь у нас не получится дискуссии без понимая основ, например статической и динамической типизации. Можешь считать, что я слил, но лучше купи хорошую основательную книгу по Objective C и вдумчиво прочитай.
Здравствуйте, MTD, Вы писали:
MTD>Например, механизм сообщений позволяет посылать сообщения объекту который их не поддерживает (аналог вызовов методов в С++), что приводит к сущему аду из-за опечаток.
С тем же успехом можно сказать, что C++ — кривое овно, т. к. в нем можно влегкую вызвать непереопределенную чистую виртуальную функцию. На практике же, что там, что там компилятор выдаст предупреждение.
Чтобы ты не думал, что я зря наезжаю, вот тебе для затравки информация из википедии:
Одной из отличительных черт Objective-C является его динамичность — целый ряд решений, обычно принимаемых на этапе компиляции, здесь откладывается непосредственно до этапа выполнения.
Ещё одной из особенностей языка является то, что он message-oriented в то время как C++ — function-oriented. Это значит, что в нём вызовы метода интерпретируются не как вызов функции (хотя к этому обычно все сводится), а именно как посылка сообщения (с именем и аргументами) объекту, подобно тому, как это происходит в Smalltalk-е.
Такой подход дает целый ряд плюсов — так любому объекту можно послать любое сообщение. Объект может вместо обработки сообщения просто переслать его другому объекту для обработки (так называемое делегирование), в частности именно так можно легко реализовать распределенные объекты (то есть объекты, находящиеся в различных адресных пространствах и даже на разных компьютерах).
Привязка сообщения к соответствующей функции происходит непосредственно на этапе выполнения.
Я понял, ты не слил, это только кажется. Поэтому ты ничего не можешь сказать про предупреждение компилятора о том, что используемого тобой метода не существует. И по этой же причине ты пытаешься перевезти тему на мое незнание Objective-C, типов типизации и прочее. Кстати, тебя кто-то советовать что мне прочитать просил? Если нет, то лучше не советуй.
Здравствуйте, MescalitoPeyot, Вы писали:
MP>Здравствуйте, MTD, Вы писали:
MTD>>Например, механизм сообщений позволяет посылать сообщения объекту который их не поддерживает (аналог вызовов методов в С++), что приводит к сущему аду из-за опечаток.
MP>С тем же успехом можно сказать, что C++ — кривое овно, т. к. в нем можно влегкую вызвать непереопределенную чистую виртуальную функцию.
Нельзя в легкую вызвать. Для этого надо хачить с приведением типов.
MP>На практике же, что там, что там компилятор выдаст предупреждение.
Разницу между статической и динамической типизацией понимаешь?
Здравствуйте, kaa.python, Вы писали:
KP>Я понял, ты не слил, это только кажется. Поэтому ты ничего не можешь сказать про предупреждение компилятора о том, что используемого тобой метода не существует. И по этой же причине ты пытаешься перевезти тему на мое незнание Objective-C, типов типизации и прочее.
Так и есть
KP>Кстати, тебя кто-то советовать что мне прочитать просил? Если нет, то лучше не советуй.
Извини, не буду. Но без определенных знаний дискуссии не получится
Здравствуйте, MTD, Вы писали:
MTD>Чтобы ты не думал, что я зря наезжаю, вот тебе для затравки информация из википедии:
Я отлично знаю что написанно в Википедии по поводу Objective-C, как не крути, изрядный кусок этой статьи мой.
Так же я знаю то, что в случае с Objective-C компилятором от Apple, производится проверка типов на этапе компиляции. Я допускаю что не всегда и не везде, тем не менее, твой "трюк" с приведением к id компилятор отловил. А вот что бы отловил компилятор с приведением к void* в C++? И при этом я не утверждаю что Objective-C это верх совершенства, я просто говорю о том, что наделать в нем ошибок в той части, про которую ты говоришь довольно трудно.
Здравствуйте, kaa.python, Вы писали:
KP>Я отлично знаю что написанно в Википедии по поводу Objective-C, как не крути, изрядный кусок этой статьи мой.
Это хорошо. Тогда не понимаю причин непонимания
KP>Так же я знаю то, что в случае с Objective-C компилятором от Apple, производится проверка типов на этапе компиляции. Я допускаю что не всегда и не везде, тем не менее, твой "трюк" с приведением к id компилятор отловил.
Никакого трюка не было.
KP>А вот что бы отловил компилятор с приведением к void* в C++?
За приведение к void* на С++ отрывают руки.
KP>И при этом я не утверждаю что Objective-C это верх совершенства, я просто говорю о том, что наделать в нем ошибок в той части, про которую ты говоришь довольно трудно.
Наделать очень легко. Мой опыт разработки под Мак позволяет мне уверенно говорить об этом.
Здравствуйте, MTD, Вы писали:
MTD>Нельзя в легкую вызвать. Для этого надо хачить с приведением типов.
Можно. Притом в разных позах и без приведений http://codepad.org/4CkK5neC
MTD>Разницу между статической и динамической типизацией понимаешь?
Мой телепатический модуль подсказывает мне, что этот вопрос возник из-за непонимания вами механизма сообщений и принятых в Objective-C практик кодирования.
Здравствуйте, MTD, Вы писали:
MTD>Никакого трюка не было.
Трюк был. А судя по тому, что ты использовал Object, а не NSObject, можно предположить что ты используешь какой-то нестандартный Objective-C компилятор, например из GCC. И этот компилятор не проводит более-менее вменяемой диагностики ошибок.
MTD>За приведение к void* на С++ отрывают руки.
Тоже самое можно сказать в случае с Objective-C. Да, иногда подобное преобразование это вынужденная мера, но никак не нормальный код.
MTD>Наделать очень легко. Мой опыт разработки под Мак позволяет мне уверенно говорить об этом.
Мой опыт разработки под Мак говорит об обратном. Единственное потенциальное хранилище граблей в Objective-C — это управление памятью, все остальное, по количеству граблей на квадратный метр, не хуже чем в случае с C++.
Здравствуйте, MescalitoPeyot, Вы писали:
MP>Можно. Притом в разных позах и без приведений http://codepad.org/4CkK5neC
Во-первых, вызывать виртуальные функции в конструкторах/деструкторах нельзя — это азбука. Во-вторых, обрати внимание на реакцию компилятора.
MTD>>Разницу между статической и динамической типизацией понимаешь?
MP>Мой телепатический модуль подсказывает мне, что этот вопрос возник из-за непонимания вами механизма сообщений и принятых в Objective-C практик кодирования.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, MTD, Вы писали:
MTD>>Я тебе больше скажу — это нигде не работает.
M>В Scala работает, в Haskel работает, в Ada работает, а ты говоришь нигде.
Это мягко говоря лукавство. На Аде пишут софт для спутников, а они падают, из-за этих самых ошибок
Здравствуйте, MTD, Вы писали:
MTD>Во-первых, вызывать виртуальные функции в конструкторах/деструкторах нельзя — это азбука.
Ну да, азбука. А в Objective-C другая азбука: нефиг чему попало посылать какие попало сообщения, даже если язык это позволяет.
MTD>Во-вторых, обрати внимание на реакцию компилятора.
Реакция точно такая же как и в Objective-C: предупреждение. К слову, его могло бы и не быть http://codepad.org/MRuqVFOl
MTD>Не понял ответ. Пояснишь?
Несмотря на то что выбор непосредственного метода для обработки сообщения происходит в рантайме (как и выбор виртуального метода в плюсах, замечу), во-первых, компилятор все равно проверяет наличие обработчика в компайл-тайме и в случае чего выдаст предупреждение и, во-вторых, нормальные люди просто так от нефиг не кастят объекты до id с тем чтобы послать им потом сообщения предназначенные наследникам. Если же им все-таки непоходимо докастится до id, то используется id<SomeProtocol> или селекторы.
В общем, все один в один как в плюсах: в ногу выстрелить разрешено, но целиться туда считается плохим тоном и обижает компилятор.
Здравствуйте, MescalitoPeyot, Вы писали:
MP>В общем, все один в один как в плюсах: в ногу выстрелить разрешено, но целиться туда считается плохим тоном и обижает компилятор.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, MTD, Вы писали:
KP>Я понял, ты не слил, это только кажется. Поэтому ты ничего не можешь сказать про предупреждение компилятора о том, что используемого тобой метода не существует. И по этой же причине ты пытаешься перевезти тему на мое незнание Objective-C, типов типизации и прочее. Кстати, тебя кто-то советовать что мне прочитать просил? Если нет, то лучше не советуй.
У типа id этих методов нет. Вот и матерится. Но если в рантайме метод будет найден, то всё шоколадно.
Эх, люблю выпить и переспать с кем нибудь!
Но чаще выходит перепить с кем — нибудь и выспаться...
Не люблю, но пишу, если надо.
