Буквально недавно я сообщал, что буду рулить интернет-разработкой в Фотолабе, и вот уже этот период подходит к концу. С апреля я буду заниматься другим делом (про которое пока суеверно не распространяюсь).
И отсюда вытекает то, что нам в Фотолабе нужен на мое место человек. Дальше — подробности.
А чего не сам-то
Перво-наперво хочу пояснить, что с Фотолабом мы расстаемся не ругаясь. Просто за 4 месяца я выяснил, что развитие отдела моими руками сильно отстает от моих собственных первоначальных планов. Да и планы эти в последнее время несколько поменялись.
Что такое Фотолаб
Фотолаб — московская компания, которая специализируется на профессиональной печати фотографий. "Профессиональная" здесь означает хорошее качество, большой набор методов печати, индивидуальный подход (есть отдельная услуга, когда клиент сидит с мастером рядом за Фотошопом, и мастер правит фотки как нужно клиенту) и разные дополнительные услуги (всякие рамки/багеты).
Проблема только в том, что до недавнего времени все это работало только по классической офлайновой схеме: человек пришел в офис, оформил заказ. Теперь у Фотолаба есть задача появиться в Интернете, чтобы дать возможность людям заказывать печать фотографий.
Сейчас здесь работает написанная мной система примерно такого содержания:
- центральный сервер, написанный на Django, принимающий фотографии из веба или публичных киосков
- интересный javascript'ово-ajax'овый интерфейс оформления заказов
- custom-решение с веб-сервером, работающее в публичных киосках для загрузки фотографий с флэшек, CD и прочих USB
- связь с внутренней БД Фотолаба для заведения заказов
- REST-интерфейс для связи GUI-клиента с сервером
Все это, не постесняюсь сказать, хорошо документировано. И все это мы надеемся подготовить к выкладыванию в интернет еще при моем участии.
А вот дальше всей этой системе нужен будет программист.
Кто нужен
Нужен человек, который умеет программировать. Это главное.
Также он должен хотеть программировать веб-сервисы. Если он уже умеет это делать — очень хорошо, если не умеет, но хочет научиться — тоже хорошо.
Вся серверная часть системы построена на Питоне, поэтому программист нужен для программирования именно на нем. Это не значит, что нужно уже досконально знать Питон. Достаточно, если человек хорошо ориентируется в ООП и представляет себе, что такое, например, динамическое типизирование в отличие от статического.
Важно хорошо ориентироваться в современных технологиях. Те же Ajax и REST в предыдущей главе упомянуты не для красного словца, на них действительно строится много функций.
Еще неплохо понимать, что такое XML, кодировки символов, транзакции БД.
Но еще раз повторюсь, главное — уметь программировать. Это я надеюсь выяснить в течение собеседования :-)
Условия и контакты
Условия — вопрос крайне индивидуальный, поэтому если суть предложения интересна, то пишите мне почтой, разъясню все, что могу. Что не смогу сразу — выясним при встрече в офисе Фотолаба.
Комментарии: 8
Немного не в тему, но...
Что именно вы используете/можете рекомендовать для работы с AJAX? Какие-нить стандартные библиотеки, или лучше своё писать?
А то я очень много читал о серьёзных проблемах с производительностью AJAX-решений (особенно при работе с большими таблицами), и о проблемах совместимости с разными браузерами, а у самого поковырять руки ещё не дошли...
Встретил незнакомое мне название - "REST", решил углубиться.. через 5 минут понял что у нас тоже, оказывается, есть REST-сервисы :о)
Вот, буквально на днях набросали сервис по просмотру статистики действий клиента на сайте, именно в виде REST-сервиса :)
Ну прямо таже история что с AJAX - старые добрые технологии в новой обертке, и пошло греметь..
Денис, самый классический REST у нас был — интерфейс с Samsung'ом. Я, собственно, именно под впечатлением от этой аритектуры его тогда и сваял :-). Хотя о "чистоте" тамошних реализаций можно спорить.
Ну да, меня правда смутила наша отправка заказа post'ом, хотя это тоже можно рассматривать как передачу параметров и получение состояния заказа :)
Не, это не получение состояния. Это именно POST, и это такая же неотъемлемая часть REST'а как и GET: GET'ом опрашивается состояние ресурсов, POST-ом — меняется. В нашем случае POST с телом заказа — как раз классический способ заведения нового экземпляра ресурса. Единственное, чем оно было не "чисто" с точки зрения идеологии, он отправлялся на отдельный URL (orders/new/), хотя более кошерно — POST'ить прямо в коллекцию ресурсов (orders/). Но это несущественно.
Человека нашли, вакансия закрыта. Всем (обоим :-) ) спасибо за письма!
Подскажите пожалуйста как правильно перевести на английский "динамическое типизирование" ? Заранее благодарен!
"dynamic typing", как мне всегда казалось...