Работа для вас

[kika]

Нужен программист в стартап.

Желаемые скиллы:
1. Многоплатформенное программирование (мы ведем разработку одновременно на Windows, Linux, MacOS/X)
2. Хорошее знание принципов работы TCP/IP, IPv6.
3. Крайне приветствуется хороший математический бэкграунд, теория графов, комбинаторика, кодирование и т.д.
4. Опыт и знания в области низкоуровневого программирования для Windows/Linux/Darwin/*BSD тоже будут задейстованы при наличии.
5. Языки программирования, которые мы сейчас используем - С и С++. Желательно знакомство с Qt. Если вы любите (и умеете) Лисп или Хаскель, то вы сможете попробовать нас убедить применить и его.
6. Обязателен хотя бы какой-то английский.
7. Обязательно умение работать дома (это не так просто как кажется) ибо у нас пока нет офиса и не будет пока не наберем достаточно людей чтобы его оправдать.

Плюсы:
1. Свободный график. В прямом, оригинальном смысле этого слова - вы работаете тогда когда хотите и столько сколько хотите, главное делать работу и делать ее хорошо.
2. Даже если мы пролетим по полной программе и перевернемся кверху пузом через год - этой работой можно будет гордиться и она займет весьма достойное место в вашем резюме. Это не очередной вариант Wiki или клон LinkedIn, количество наших конкурентов исчисляется на пальцах (если реальных, то одной руки, если потенциальных - то двух).
3. Вы получаете заметную долю в компании, которая обеспечит вам безбедное существование в случае даже среднего успеха.
4. Если у вас есть математические или вообще исследовательские амбиции, то мы изо всех сил постараемся их удовлетворить, ибо это в наших лучших интересах. Вы будете авторами или соавторами патентов, если захотите - пишите статьи в журналы и т.д. Тема, которой мы занимаемся, сейчас весьма горячая и паблисити вам гарантировано.
5. Нас не интересует ваш пол, сексуальная ориентация, формальное образование, наличие московской прописки, российского гражданства или еще чего-то, не относящегося к работе как таковой.
6. Мы приветствуем самостоятельную работу. Чем больше вы думаете своей головой, сохраняя при этом полноту коммуникаций с остальной командой тем лучше.

Минусы:
1. Свободный график. Не так много людей обладают достаточной самодисциплиной чтобы организовать свою работу без внешней плетки.
2. Деньги. Меньше $1.5K мы скорее всего платить просто не захотим. Идеальному кандидату мы сможем платить и $5K, но у нас довольно высокие стандарты идеальности, что в частности означает что мы пятерку заплатим с радостью, было бы кому. Вообще в общем и целом денег у нас сейчас немного. Мы получили хорошее финансирование в Штатах с учетом рискованности проекта и того что мы русские, но это хорошее финансирование в абсолютных цифрах невелико.
3. У нас нет ресурсов заниматься социальными гарантиями, страховками, бесплатными обедами и прочим. В будущем - возможно, я сторонник "инфраструктурной любви" ©cherjr к сотрудникам, но сейчас на это в первую очередь нет времени. Вообще ценители социалки и стабильности не найдут у нас желаемого, это работа для авантюристов. Единственная социальная гарантия, которую мы вам можем пообещать - это доля в компании, которая может оказаться пшиком.
4. Работы много и она тяжелая и сложная. Надо и хорошо и быстро кодировать и много думать верхней головой. Ценители неспешной долбежки по хорошим детальным спекам тоже не найдут у нас удовлетворения. Эти спеки могут появиться _после_ долбежки, но вряд ли до.
5. Самостоятельность не исключает субординации. У нас есть достаточно четкая картинка того что мы хотим получить на выходе и если ваше свободное творчество пойдет вразрез с картинкой, придется наступить песне на горло. Возможно временно, но придется.

Ну если после всего желающие еще остались - mailto:kika@kika.ru Резюме желательно в тексте и приложите кусочек своего кода на С/С++ (желательно и на С и на С++) строк в 1000 (программку, пару-тройку классов, etc). Интервью мы проводим в кафе и ресторанах г. Москвы за казенный счет (должно же быть что-то хорошее). Сцылки на этот пост приветствуются. Каменты не скринятся, а к следующему dummy посту - скринятся.

Comments

[109.livejournal.com]

это под моно, видимо. я же не сказал - невозможно. сказал - тяжеловато. понятно же, что всё равно код под моно на линухе будет работать немножко не так, как на родных виндах. то есть багфиксы будут платформо-специфичны. то есть либо код будет пухнуть от ифдефов, либо от фабрик, неизвестно ещё что лучше.

[ifp5.livejournal.com]

Ну программу на C как грится, можно написать на любом языке программирования, только зачем так писать не очень понятно. Надо, наверное, ограничиваться тем подмножеством, которое присутствует в обоих средах, оно обладает свойством тьюринговской полноты и содержит все необходимые операции ввода/вывода.

[kika.livejournal.com]

А Windows Forms как поддерживаются? В смысле гуй этот дотнетовский. Или разговор сугубо о серверсайде?

[ifp5.livejournal.com]

В каком-то виде они в mono присутствуют, но живьем не видел. Про наличие гуя на юниксах все время забываю. :>

[pzz.livejournal.com]

Наверное, с помощью GTK+ :-)

[109.livejournal.com]

подмножество-то присутствует. только работает несколько по-другому.

Это общая проблема.

[ifp5.livejournal.com]

Например:
- JVM даже одной и той же версии под Windows работает "несколько по-другому" чем под Linux, а под Linux "несколько по другому" чем под Solaris
- JVM версии 1.4.x работает под одной и той же ОС "несколько по-другому" чем версии 1.4.y
- JVM на однопроцессорной машине работает "несколько-по другому" чем на многопроцессорной
- JVM разных производителей работают "уж совсем по-разному"

При наличии желания возможно использовать эти различия, безусловно, можно, так что будет работать только на конкретной машине с конкретной ОС и конкретной (вплоть до каждой цифры в версии) JVM.

Но не уверен, что это делать нужно.

Re: Это общая проблема.

[109.livejournal.com]

про переход количества в качество слышали? гегель, всемирная история, банк империал.

Re: Это общая проблема.

[ifp5.livejournal.com]

Ну слышал, конечно, только не очень понимаю, какие это создает проблемы использованию шарпа под юниксы.

Реально проблема есть только одна единственная (и она та же самая что препятствует использованию OCaml, Haskell, LISP и пр) - что решение выбора языка принимают люди (такие бывают толстые и важные начальники), которые уже решили, что проект будет на жабе. Никаких других проблем в использовании шарпа (или хаскеля) нет. Если имеется в виду именно это, то, как я понимаю, к исходному письму это не очень применимо.

Re: Это общая проблема.

[kika.livejournal.com]

Ну это на самом деле далеко не так. Это черезвычайно распространенное мнение, которое на самом деле базируется на такой красивой гиковской картине мира, в которой есть good programmers and evil managers. И все плохое проистекает из менеджеров, а все хорошее пишется умными программистами, которые вникают в проблему с полувзгляда и выбирают идеальный инструмент.
Попробуйте написать полезную программу на лиспе и продать ее пользователям (продать в широком, хорошем, смысле - пусть даже и забесплатно). Чтобы она была как программа на С++/Win32 или там на сишарпе/дотнете. Чтобы у нее был гуй, какой модно в этом сезоне (совершенно необязательно, кстати, чтобы он был один в один стянут с последнего оффиса), чтобы у нее был нетворкинг, чтобы она работала с трехмерной графикой под DX9/10 и использовала многоядерные процессоры. По-моему я описал гамез, сам того не желая, ну да ладно. Пусть это будет не гамез, а САПР.

Ровно та же самая проблема у всех на свете "скриптовых языков, лучших чем Перл". Они все безусловно лучше чем Перл (трудно быть хуже с точки зрения среднего программиста), но у перла есть CPAN. End of story here.

P.S. Всех, кто напишет что у Автокада в пузе как раз лисп - сразу забаню. Настолько short minded тут не нужны :-)

Re: Это общая проблема.

[ifp5.livejournal.com]

Что делать с 3d-графикой не знаю. Я в ней мало что понимаю и не пользуюсь (если раз в полгода возникает желание поиграцца, то, как правило, в nethack). С нетворкингом проблем, по-моему, нет нигде, с использованием многопроцессорности... гм, как я понимаю, вопрос в том, чтобы триды в языке дружили с многопроцессорностью... проблема местами существует, но кроме совсем консервативных товарищей (типа X.Leroy), либо уже решена, либо решается.

Допустим, с 3d графикой проблемы есть.

Кроме нее существует масса задач с интерфейсом типа WWW или VNC, для написания которых хоть на чем угодно я не вижу никаких технических проблем. Например: софтсвич, генератор телефонного трафика, интелектуальная платформа (интелектуальная в телефонистском смысле, для обычного человека интелекта там кот наплакал), система мониторинга, медиатор для биллинга, система управления чем-либо (например, кластером MCU) и многое другое. И, в общем то, пишут, и на жабе и на шарпе, может даже на хаскеле :> С языками типа LISP, OCaml, Haskell и пр. (к шарпу это не относится) проблема встает исключительно организационная, т.к. носители этих языков предпочитают заниматься R&D, а не промышленным программированием, что ставит вопрос с кадрами (например, кто будет поддерживать код, если некий камлово-хаскельный гений умрет или хотя бы уволится).

P.S. Кстати, Perl, по-моему, не самый худший скриптовый язык, TCL или scheme с точки зрения удобства писания кода гораздо хуже. (хотя с точки зрения встраивания в железо наоборот)

Re: Это общая проблема.

[rblaze.livejournal.com]

Не может ли такого быть, что это решение они не высасывают из пальца, а принимают с учетом некоторых важных факторов?

Re: Это общая проблема.

[kika.livejournal.com]

Нет©

Re: Это общая проблема.

[rblaze.livejournal.com]

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

Re: Это общая проблема.

[ifp5.livejournal.com]

Ну да, иногда соображения бывают. В основном характер у них такой: начальник решил расширить свой кругозор и почитать глянцевый журнал про компьютерные технологии. А там про хаскель написано мало, в основном, плюсы да жабы да еще вот шарп (написано обычно бывает что "язык XYZ - самый мощный и перспективный", не поясняя деталей). Вот он и принимает решение в зависимости от того что мощнее и перспективне. Начальство уровнем-двумя-тремя пониже (которое может отличить программиста от уборщицы) обычно руководствуется соображениями типа этого (http://kika.livejournal.com/32433.html?thread=309169#t309169), то есть оценкой того, стоит ли преимущество в скорости разработки и качестве кода предполагаемых рисков. Обычно считает что не стоит.

А ведь бывают еще всякие интересные вещи типа сертификации. Назовите мне лабораторию, которая даст заключение на софт на Хаскеле.

Насколько я представляю себе процесс сертификации, если бабла заплатить достаточно, сертифицируют хоть на Brainfuck :) Хотя смотря что. Я сталкивался, например, с сертификацией решений СОРМ.

Re: Это общая проблема.

[rblaze.livejournal.com]

"Достаточно" может означать очень разные суммы, в зависимости от того, насколько сотрудники лаборатории способны разобраться в коде. А еще меня сертифицировало прямо ФСБ, это отдельная песня.

[109.livejournal.com]

нет, имеется в виду не это. имеется в виду, что отличий между версиями jre 1.4.x и 1.4.y мало, а между тем, как работает шарп под моно, и как он работает на родной платформе, существенно больше. настолько больше, что количество различий переходит в качественное решение "уж лучше писать на С++".

[ifp5.livejournal.com]

jre 1.4.x и 1.4.y

Корректным сравнением с этой парой будет сравнение mono 1.1.x и mono 1.1.y

Если же хотеть чтобы некий продукт работал под Sun JRE 1.3-1.5, да еще под гнутыми, IBM'ерскими и еще кое-каковскими JRE, думать головой и сравнивать что где и как реализовано все равно придется (как придется это делать в случае mono + CLR), разницы никакой.

Большинство разработчиков на жабе этого не делают (большинство из того, с чем приходится сталкиваться мне лично, в целом, возможно, картина другая) и предлагают в нагрузку к продукту еще и саму JRE, операционную систему, а зачастую и сервер, на котором это будет работать. Иначе возникают случаи вроде того что некий мегапродукт работает только на многопроцессорной конфигурации и не работает на однопроцессорной или наоборот (версия OS и JRE при этом одинаковые).

настолько больше, что количество различий переходит в качественное решение "уж лучше писать на С++".

То есть вы хотите сказать что между C++ (вкл. системные библиотеки) на различных платформах (например, между MSVC/Win32 и gcc/Linux) и различий меньше чем между mono и CLR?

[109.livejournal.com]

вашими бы устами да мёд пить. я сам-то всеми руками за многоплатформенный девелопмент на шарпе, особенно учитывая место своей работы. но ведь прецедентов мало, а серьёзных и вообще нет.

[ifp5.livejournal.com]

Гм. SIPRise - несерьезный пример? У нас есть проектик на его базе (я там выступал в роли правда не программиста, а человека, который постоянно занимается тем, что объясняет разработчикам, что они идиоты, как это называется, QA?), разработка его обошлась примерно в поллимона баксов. Целевая платформа - линукс, fault-tolerant кластер из нескольких серверов, пока загрузка небольшая и серверов всего шесть. Ну не очень серьезный проект, согласен, а вы только с миллиардными бюджетами работаете? :)