Ищу разработчика PHP на стартап с функциями архитектора

dvo77

Новичок
Описание проекта:
коммуникационный сервис в сфере интернет-продаж.

Этапы проекта:
- достаточный функциональный минимум PHP+MySQL;
- проработка дизайна + натягивание верстки;
- монетизация;
- расширение функционала.

Общий срок: 2-3 года.

Условия работы:
удаленно, с возможностью личных встреч (Москва)

Оплата:
сдельная, из расчета трудозатрат и среднемесячного уровня заработка в 100тыс.р.
для уменьшения рисков разработчика, со второго задания возможна авансовая система расчетов.

Необходимые навыки:
- опыт разработки от 3-х лет;
- уверенные знания PHP, JavaScript;
- знания MySQL на уровне умения вызывать процедуры, функции, использовать представления;
- понимание принципов построения высоко-нагруженных приложений. Подтвержденный опыт будет преимуществом;
- обязателен опыт разработки в одном из фреймворков: Zend Framework 2, Symfony 2, Yii;
- желателен опыт работы с oAuth2;
- умение покрывать код тестами;
- навыки постановки задач.

Особые условия:
предполагается личная финансовая заинтересованность в виде процента от дохода. Для скептиков) - обсуждение на этапе монетизации.

Нам не важен Ваш пол, возраст, где и кем Вы работали / работаете.
Нам важен результат.

Поэтому вместо резюме предлагаю первую простую) задачу:

- форма быстрой регистрации (e-mail)
- форма аутентификации

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

Форма технического решения:
1) Фреймворк
2) Трудозатраты (1д=8ч)
3) Срок выполнения
4) Размер вознаграждения
5) Особенности реализации

ПС: Задача тестовая. Приветствуется многовариантность решения. Четвертый пункт для тех, у кого размер вознаграждения отличается от указанного выше.

Вячеслав Данилов
e-mail: [email protected]
tel: +7 916 574-92-57
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
в реальной жизни подобное ТЗ требует уточнения:

>Ссылка живет не более трех дней.
крон и cli работают? можно и без них, конечно
>отправляет ее на почту
какая почтовая система: mail(), smtp, mandrill?

>2) Трудозатраты (1д=8ч)
2 часа :) эту хрень можно скопипастить из любого проекта
5) Особенности реализации
а что, здесь могут быть какие-то варианты, кроме метода отправки email и способа очистки устаревших ключей?
 

С.

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

Redjik

Джедай-мастер
5) Особенности реализации
а что, здесь могут быть какие-то варианты, кроме метода отправки email и способа очистки устаревших ключей?
ну да, еще id сессии нужно хранить в базе, чтобы
При аутентификации создается сессия по принципу: один уникум - не более одной сессии.
 

dvo77

Новичок
в реальной жизни подобное ТЗ требует уточнения
как и любое другое, каким подробным бы оно ни было. это нормально.

крон и cli работают? можно и без них, конечно
крон. не подумал - в задаче не нужно было писать фразу про время жизни.

какая почтовая система: mail(), smtp, mandrill?
на усмотрение разраба, как и многое о чем не будет в задачах. Единственное пожелание - необходимость разумного согласования.
Если от решения зависят дополнительные работы, например, по настройке сервера, по обеспечению безопасности, то лучше решения принимать совместно.
Чем меньше новостей на этапе ввода в эксплуатацию, тем лучше.

2 часа :) эту хрень можно скопипастить из любого проекта
я понимаю, что при такой постановке задачи, даже тупой копипаст выдаст результат.
но это больше тестовое задание, чем промышленная версия.

а что, здесь могут быть какие-то варианты, кроме метода отправки email и способа очистки устаревших ключей?
мемкэш, вопросы безопасности, например.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
С. речь про разработчика с функциями архитектора ;)

Redjik хеш ip+sessionID+UserAgent, тут и вариантов-то нет

dvo77, инфраструктура не может быть "на усмотрение разраба" - она определяется целевым количеством писем, а не желанием или умением.
Если цель - до 100 регистраций в день, сойдет и локальный sendmail, а если 1000 - надо идти в mandrill.

мемкэш для этой задачи как корове седло :) [cut]. можно Handler Socket
[cut]
удалил обоснование, а то я скоро все решение задачи напишу
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Absinthe если уж не портить жизнь, то не запрещать множественный вход в приницпе,
а если это платежная система, пользователи ТОРа и всех открых проксей идут лесом
 

Redjik

Джедай-мастер
я вот тоже подумал, зачем сессии в мемкеш кидать, это же сколько гемора с дублированием сессий
 

Redjik

Джедай-мастер
какого гемора?
куда их еще кидать, если вебов не один и не два?
ну в этом случае да и это логично, просто в задаче нет этого условия
+ я с распределенными системами не работал, везде хватало APC (то есть это 99.999% всех сайтов я думаю)

UPD. вообще думаю highload специалисты вымрут как класс максимум лет через 20, если уже добились 1го петабита, а железо дешевеет и развивается до неприличия быстро
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
highload специалисты вымрут как класс максимум лет через
лет так 8 назад мой коллега, начальник IT в банке, где я работал, высказывал мнение, что веб-разработка станет никому не нужна "лет через..." - все станут делать сайты из коробок, и custom будет не востребован
и правда, каждый школьник делает портал на Jooml-е, визитки клепаются за день, но программисты все-равно нужны
 

fixxxer

К.О.
Партнер клуба
UPD. вообще думаю highload специалисты вымрут как класс максимум лет через 20, если уже добились 1го петабита, а железо дешевеет и развивается до неприличия быстро
да хрен там;) просто появится возможность делать такие вещи, для которых нужны петабитные кластеры

в 80х никто не мог себе представить ютуб
 

dvo77

Новичок
инфраструктура не может быть "на усмотрение разраба" - она определяется целевым количеством писем, а не желанием или умением.
Если цель - до 100 регистраций в день, сойдет и локальный sendmail, а если 1000 - надо идти в mandrill.
тогда тем более такие моменты должны быть обсуждаемы, а инициировать их как раз и должен архитектор.
"на усмотрение разраба", имеется ввиду как раз процесс принятия решения, начиная от определения необходимости согласований.

удалил обоснование, а то я скоро все решение задачи напишу
спасибо)

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

~WR~

Новичок
highload специалисты вымрут как класс максимум лет через
Придерживаюсь того же мнения.

Осталось буквально 1-2 больших шага в развитии процессоров и, особенно, жестких дисков.
И тогда любой желающий сможет получить огромные мощности в облаке по копеечным ценам.

Не нужен будет никакой шардинг и noSQL. То, что сейчас крутится на сотне серверов, легко поместится на одном.
Вероятно, даже исчезнет необходимость в кешировании. Настолько дешева будет прямая работа с данными.
 

zerkms

TDD infected
Команда форума
Не нужен будет никакой шардинг и noSQL. То, что сейчас крутится на сотне серверов, легко поместится на одном.
Вероятно, даже исчезнет необходимость в кешировании. Настолько дешева будет прямая работа с данными.
Потребности растут вместе с возможностями.
 

Breeze

goshogun
Команда форума
Партнер клуба
И тогда любой желающий сможет получить огромные мощности в облаке по копеечным ценам.

Не нужен будет никакой шардинг и noSQL. То, что сейчас крутится на сотне серверов, легко поместится на одном.
Вероятно, даже исчезнет необходимость в кешировании. Настолько дешева будет прямая работа с данными.
Хехе, а сервера в облаке с каждый днем дешевеющее электричество из воздуха будут брать? Да и капитализом не позволит обойтись без оверселлинга, слишком соблазн велик =)
К тому же, учитывая то, что мощности растут, а общее быстродействие систем остается не таким уж и высоким, количество прослоек и прочего говнокода растет. Будет проц мощнее, будет очередная прослойка, пожирающаяя мощности =)

В общем все разговоры об ожидании одной кнопки "сделать зашибись" дешево и моментально ведутся с начала it-эпохи, но общий бардак в индустрии еще долго не позволит это сделать, несмотря на мощности и реальный прогресс.
 
  • Like
Реакции: Gas
Сверху