beartamer
0
При аквизишене ни одного разработчика Моего Круга не пострадало.
beartamer
0
комментарии не читай, сразу отвечай! простите. ниже есть часть ответов на мои вопросы.
beartamer
0
Через кого эквайритесь?
Есть зарубежные банки?
Уже можете подписывать договоры с зарубежными юрлицами?
Есть какая-то тарифная сетка уже?
Есть апи или только всякие ифреймы?
Есть токенизация?
Какие еще плюшки есть?
Много вопросов )
beartamer
+1
именно так. деньги инвесторов пойдут на зарплату основателя в самую последнюю очередь.
beartamer
0
А, ну понял =) А вообще это не так важно на чем бэкэнд. Хорошая система деплоя — залог здоровья и быстрого развития
beartamer
0
А как вы деплоите свои приложения?
beartamer
+1
делаем прямо сейчас, ага )
beartamer
0
Мы знаем про кучу проблем в экстранете, особенно с производительностью. В ближайшие несколько недель выйдет большой апдейт фронтэнда, который решит многие проблемы. Большое спасибо за фидбэк, мы постараемся учесть и все остальные пожелания в будущих версиях.
beartamer
0
ок, расскажем. про процессы расскажем тоже. и про деплой.
beartamer
+1
Ага, на бэкэнде python, django, postgres, redis и celery как основной стек технологий. Есть еще всякая экзотика по-мелочи, типа эрланга )). Про бэкэнд тоже на хабре напишем еще.
beartamer
+1
Ну на самом деле используем, просто не в островке, а в некоторых наших других продуктах. Возможно и в островке будет, но пока да, на основном сайте ничего нет.
beartamer
+4
Мы посмотрели на несколько решений code review: facebook phabricator, gerrit2 и конечно github pull requests. И написали свою очень простую (особенно по-началу) систему, которая заточена под git, feature branches и continuous integration. Расскажем подробнее и не исключено что заопенсорсим.
beartamer
+3
У нас есть своя небольшая система code-review под названием WTF. Мы про нее еще отдельно расскажем, она очень клёвая.
beartamer
+2
37сигналов отличные и умные. но если вы работаете в условиях более крупной команды, большой скорости и жёсткой конкуренции, то всегда следовать такому совету нельзя, нужно соблюдать баланс. купить новый сервер — это дело одного дня, нанять сотрудника — дело месяца, новый раунд финансирования — дело полугода. начинать новый раунд только тогда, когда кончились деньги, или искать нового человека только тогда, когда все остальные перегружены работой?

В общем, сделать всё идеально не получится, но нужно стараться видеть всё на шаг вперед. И ничего не бояться )
beartamer
0
Вообще «получать доход» — это понятие очень сложное. Многие бизнесы принесли очень много денег их создателям, так никогда и не став прибыльными. Так что монетизация и доход — это далеко не одно и то же.
beartamer
+2
вероятно для начала мы расскажем о том, какие ответы на тест для бэкендеров мы получили и что нам показалось особо интересным. а потом поглядим. и да, у нас есть вакансии для бэкэндеров тоже. приходите в гости.
beartamer
0
хм, а я вот навскидку не нашел в разделе ваканский ни одного упоминания о долине. но вообще спасибо, почистим, чтобы не выглядело слишком маниакально )
beartamer
+1
просто первое задание на фронт-энд оказалось весьма сложным его сделали буквально единицы, поэтому мы решили разместить более простой вариант. сделавшие сложную задачку будут иметь некоторый бонус при оценке результатов.
beartamer
+2
очень много ответов, надеемся за выходные обработать всё )
beartamer
0
а вот есть какое-нибудь сравнение технических возможностей? к примеру вот кого лучше выбрать, если мне нужно:
1. слать порядка 100 тысяч писем в неделю,
2. минимально кастомизировать каждое письмо (уникальные урлы для каждого получателя)
3. хочется чтобы 100т уходило за час-два, при том там большой объем отдельного письма.
4. статистику собирать по открытиям, доставляемости
5. баунсы собирать и очень было бы круто сразу дёргать какую-то ручку на нашем сервисе для автоуборки

где-то есть сравнения этих сервисов по таким критериям?
beartamer
+4
мне кажется, что тогда использование криптографии очень захотят приравнять к экстремизму…
beartamer
0
ну мне кажется заголовок очень точен: у фейсбука нет qa-team. и действительно, никакой выделенной команды нет.

то что разработчики пишут юнит-тесты и даже немножко автоматические функциональные тесты (их совсем не много, основной упор на юнит-тесты), это не делает из разработчиков QA. это просто делает разработчиков более хорошими =)

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

некоторые крупные проекты отечественного рунета тоже так делают. особенно любопытна идея оптимизации UI важных страниц: миллион пользователей своим ctr за несколько часов скажут вам об эффективности изменений в UI больше и точнее, чем серьёзная юзабилити-экспертиза =)
beartamer
0
это был коммент для @blv. промахнулся
beartamer
+5
www.theinquirer.net/inquirer/news/1720797/facebook-qa-team
ну кроме того, Andrew Bosworth на РИТе в этом году лично рассказывал об этом. Кратко: «Делаем фичу, выкатываем на стейджинг, юниттесты, если надо — стресстесты, смотрим сами мельком, если всё ок — выкладываем на маленькую долю пользователей, миллиона на три =), очень быстро собираем фидбэк и либо фиксим, либо откатываем, короче действуем по ситуации. Все критичные вещи покрываются юниттестами, поэтому шанс нарваться на серьезную ошибку немногим больше, чем при тщательном функциональном тестировании».

в свою очередь могу сказать, что это работает, мы проверяли и по крайней мере вывели для себя очень большую важность экспериментов на долях аудитории и важность сбора фидбэка. но qa у нас все же есть, я ответил «менее 20%».
beartamer
0
ну а что, в фейсбуке вот нет QA отдела. есть юнит-тесты и пользователи, кто еще нужен? =))
beartamer
+18
facebook, хм?
beartamer
+10
классная штука. особенно забавно, что эта реализация интерактивной PHP консоли написана на Питоне =)
beartamer
+2
интересно, а был ли хоть один пост про яндекс.панорамы, в комментах к которому не спрашивали «а почему не замазаны лица и номера»? =))
beartamer
0
Вам хорошо, Вы читать умеете… а что делать остальным? =)
beartamer
+1
а я и говорю — и то и другое. Общее число регистраций — возросло, и одновременно с этим конверсия (не в зарегистрированных пользователей, а в посетителей) — упала. Короче, нужно быть готовым к тому, что зарегистрировавшиеся по «упрощённой» схеме люди будут гораздо реже посещать сайт, потому что бОльшая их часть пароль не помнит и не знает где искать. У нас даже почтовый трафик вырос сильно из-за постоянного использования ссылки «восстановить пароль» =))
beartamer
+1
Это всё верно, одна только проблема — вы размазываете конверсию регистрации на большее число шагов. Мы использовали подобную схему на одном более-менее крупном (150 тысяч посетителей в день) проекте и пришли к следующим выводам:
1. Количество регистраций увеличивается, люди охотнее заполняют одно поле
2. Конверсия письма «нажмите на эту ссылку чтобы подтвердить емейл» — такая же
3. В первое посещение сайта подавляющее большинство людей не меняет пароль, который мы сгенерировали, хотя мы настойчиво предлагали.
4. В дальнейшем люди, поменявшие пароль, или зарегестрированные еще по старой схеме, где они пароль вводили сами, заходили на сайт в 10 раз чаще остальных.

выводы просты — то что мы стали генерировать пароль отдельным шагом только уменьшило итоговую конверсию гостей в постоянных посетителей, хотя и увеличило число регистраций.

тогда мы сделали ввод пароля обязательным шагом после подтверждения почты. То есть по сути просто разделили один шаг на два. конверсия регистраций, прошедших два шага закономерно меньше, чем при использовании одного шага.
beartamer
+3
все дело в том, что любая сложная система внутренне заинтересована в сохранении своей сложности. пример — естественным шагом системы для борьбы с бюрократией будет создание нового «коммитета по борьбе с бюрократией» =)
beartamer
+4
расскажу по-подробнее о тех инструментах, которые используем мы в Яндексе, в команде Моего Круга
beartamer
+7
а Кевин Митник пользовался такими методами вовсю и считал их особо эффективными… вы б ему инвайт на Хабр не дали, да… =)
Комментарий из публикации, перенесённой в черновики.