Насколько полезно знание внутреннего устройства iOS

Прислали мне тут вопрос по почте, относительно полезности знания низкоуровневого устройства iOS. Не пропадать же добру, пусть будет общественным достоянием

Я прочитал эти темы, созданные Вами:
http://www.rsdn.ru/forum/apple.os/4951747.flat
http://www.rsdn.ru/forum/apple.os/4336664.1
1) Хочу спросить у Вас, полезно ли вообще среднестатистическому программисту iOS знать все эти вещи про устройство ядра? Я никогда не видел вакансий системного iOS-программиста (может потому, что живу в Минске =) ). Большинство вакансий связаны с вэбом, GUI или играми.

Знание внутреннего устройства среднестатистическому iOS разработчику совершенно бесполезно. Вакансий системного iOS-программиста нигде, кроме как в Купертино нет и, скорей всего, не будет, так как на не разлоченом iOS устройстве установить что-либо системное не представляется возможным, а разлоченых устройств не так уж и много.
Единственный плюс в понимании внутреннего устройства iOS в том, что сама iOS ничто иное как урезанная OSX, так что если ты имеешь представление об одной системе, то эти знания помогут и со второй. Только тут возникает еще одно “но” – вакансий для системного разработчика OSX тоже по пальцам пересчитать можно, в той же Мск люди с таким знанием нужны в паре-тройке компаний. Удаленной работы по данному направлению лично я найти не смог.

 2) Я как-то встречал такое мнение, что “и Линукс и Мак являются Юникс-системами (POSIX). С одного на другой [имеется в виду программирование] перейти несложно”. Насколько это верно?

Отчасти верно. Обе системы – UNIX-like системы, но при этом внутреннее устройство Darwin (ядро Mac OS X) и Linux кардинально различаются. Хотя, в Darwin много общего с BSD системами. Если говорить точнее, схоже все кроме управления памятью, процессами и потоками.
Так что, перейти с Mac OS X на Linux, если заниматься не ядром, а низкоуровневыми сервисами довольно легко, правда аналогичный переход с Windows на Linux, при условии что на Windows занимался низкоуровневыми вещами не на много более сложен.

Тестовые задания в Яндексе. Часть 2.

Как и планировал, опробовал второй способ сортировки, а именно сортировку подсчетом. Кода в разы меньше, сам код куда проще, но… Крайне плохо масштабируемое решение с сильной зависимостью от количества доступной памяти. Так при использовании максимального количества доступной памяти в 256 Мб, приходится делать 64 прохода по файлу. Если же попытаться разнести чтение и запись (как я писал раньше, асинхронная запись дает ускорение приблизительно в 10-15%) то количество проходов вырастает до 128 и итоговая скорость оказывается даже меньше чем при последовательной обработке. Так же, мое решение не будет корректно работать в том случае, если количество одинаковых элементов превысит максимальное значение помещающееся в size_t.
Тем не менее, сортирует довольно быстро: 1 Гб, в среднем, обрабатывается за 108 секунд.

P.S. а вообще, я выдохся с данной задачкой (как делать ясно, побочные эффекты алгоритмов тоже очевидны), так что вернусь ней… через еще пару лет?

Тестовые задания в Яндексе

Когда-то, давным-давно, в разгар активного поиска работы я написал в Яндекс. Не то что бы я думал туда пройти, все же алгоритмы не моя сильная сторона, но мне подумалось “а почему бы не попробовать, особенно с учетом того, что на РСДНе ходят легенды о полнейшей невменяемости собеседующих там товарищей”. Вобщем решил сходить и чисто позырить. Позырить мне так и не удалось, т.к. яндексовцы дали тестовое задание на дом, а на такое я принципиально не соглашаюсь. Но, надо признать, задание было интересное, и я его прикопал с целью когда-нибудь, когда будет соответствующее настроение, решить. Соответствующего настроения не было у меня два года, и вдруг оно появилось! Continue reading

Переход из C++ в Java.

Так как в последние пол года, или даже больше, я активно работаю с Java, у меня родился вопрос целесообразности полного перехода с одного языка программирования на другой. С одной стороны, при том что я как работал с сетевыми приложениями, так и работаю, мне совершенно фиолетово на каком языке эти самые сетевые приложения писать. С другой стороны, потенциальным работодателям, обычно, это не все равно, а их мнение приходится учитывать.

Так что, я решил подойти к вопросу просто. А что может быть проще и логичнее чем поинтересоваться у HR о текущем спросе на Core Java разработчиков? Что я и сделал.

Хотя каких-то дельных ответов в самой ветке обсуждения я не получил, довольно много кто отписался лично. Несколько человек спросило не интересна ли мне работа связанная с C++ на суммы от 150 до 180, что, живи я в МСк, могло бы быть интересным. А еще несколько человек поделились по секрету информацией о том, что Core Java разработчик, обычно, претендует на 100-150, само собой, в той же МСк.

Так что, никакого экономического смысла в таком переходе нет. Специалисты со знанием C++ как были нужны, так и будут нужны еще много лет. А мне только-только начала нравиться Java %)))

Зачем пишут OpenSource приложени и что же можно написать…

На днях на РСДН всплыли сразу две интересные темы Для чего создаются Open Source проекты Задачки для самообразования. Лично у меня давно сформировалось мнение относительно этих вопросов, которым мне и хочется поделиться.

Начну с того, зачем вообще нужно писать OpenSource приложения и что это может дать обычному разработчику. Да, именно обычному разработчику, а не некой компании.

Во-первых, наличие OpenSource проектов это – огромный бонус при приеме на работу. Несмотря на то, что среди разработчиков ходит довольно нелепый миф про работодателей, которым совершенно плевать на OpenSource проекты потенциальных кандидатов, дела обстоят совершенно иначе. OpenSource проект – это код, который всегда можно легко оценить, глянуть историю изменений и, как следствие, легко составить мнение о потенциальном кандидате. Сразу видно как человек пишет код, как он думает и как он делает рефакторинг, если, конечно, он его вообще делает. Так же видно, какие у человека интересы и взгляды на прекрасное.

Во-вторых, OpenSource проект это – экономия времени при поиске работы. Довольно часто потенциальный работодатель просит пример кода либо выполнить тестовое задания. Так как при отсутствии собственных проектов такой код взять неоткуда, разве что украсть у предыдущего работодателя, то приходится или делать тестовое задание, или отказываться от вакансии. В то же время, вместо выполнения тестового задания всегда можно прислать ссылку на собственный OpenSource проект.

Continue reading

Обзор от PRUFFI

PRUFFI последнее время стал делать какое-то подобие обзора ЗП на IT рынке. В целом обзор не шибко информативен и, как мне кажется, несколько оторван от жизни. Я, вобщем-то представляю, где можно найти работу тимлида с оплатой в 150-170 тыр, но вот где дают 200-250? Теряюсь в догадках.

Многообещающе

Открылся, как мне кажется, довольно многообещающий сервис по поиску работы Карьера 2.0 на небезызвестном StackOverflow. Регистрация соискателей либо по приглашению, либо за заслуги “перед отечеством”, в моем случае проекты на GitHub зачлись. С учетом бешенной популярности StackOverflow, думается, что данный сервис может очень пригодиться в поиске работы.

Mac разработчики редки и ценны :)

На РСДН-е появилась вакансия Mac OS X разработчика в Каспер. Что странно, денег дают даже больше чем разработчикам вендовых драйверов. Честно сказать, меня это удивляет, с учетом того, что требования к разработчикам под MacOS довольно низкие. Ни у кого нет Маков? Ни кому под них не интересно писать?

Но в любом случае: добро пожаловать

Классическая задача для собеседования в реальной жизни

Случилось странное – я столкнулся с буквально классической задачей с собеседования в реальной жизни. Задача состоит в том, что необходимо найти первый не нулевой бит в массиве. Поиск должен происходить максимально быстро, скорость поиска желательно получить приближённую к линейной. Никаких правил по распределению единиц в массиве нет. Массив не велик и должен не вылезать за пределы одной кэш-линии.
Родились 3 варианта алгоритма, одна часть которого общая во всех случаях, вторая специфическая.
Общая часть сводится к поиску первого 32 разрядного слова с хотя бы одним не нулевым битом. Дальше, в найденном 32 разрядном слове ищем первый не нулевой бит. Я не знаю как можно оптимизировать первую часть алгоритма, так что ищу простым перебором. Continue reading