Да, а 500 фунтов — 28300 рублей. Супер-премии — без верхней границы. Причина такой сетки — мы принимаем и оплачиваем даже мелкие недоработки. Все серьезные уязвимости с причинением заметного вреда потенциальным пользователям и компании — все пойдут по максимальной категории или как супер-премия.
Вы, вероятно, занимаетесь поиском уязвимостей, а Вы не сидели на приёме потока изнутри больших компаний? Мы получаем большой поток обращений и даже очень мелкие баги иногда засчитываем за уязвимость. Хороших уязвимостей, действительно зная которые можно причинить ущерб компании или пользователям — исчезающе мало. Для них у нас предусмотрена особенная супер-премия, и там нет верхней границы. Несколько таких премий мы выдали в прошлый месячник. Опишите, пожалуйста, примерный тип уязвимости и ожидаемую оплату. Спасибо.
У нас пара-тройка миллиона разных временных рядов для анализа — это не считая метрики ITOPS типа по десяток на сервак умножить на пару тысяч серверов ;) Приведу один простой пример. У нас есть отдел биллинга. Это примерно 1/10 нашей девелоперской мощности. У ребят задача — покрыть платежами все страны (есть статья в этом блоге). По миру вариантов взять денег — очень много. Там где-то сто различных интеграций (подробнее может рассказать кто-то из биллинга). Каждая интеграция — это фактически отдельный софт на встраивание конторой-агрегатором, например. Если что-то где-то не работает — у нас убытки типа десятки тысяч нерублей в час.
1. До 50% на кадровые вещи, включая отсмотр соц-сетей, пингование людей, телефонное интервью — короче, рекрутинг, самая затратная часть всего времени компании на найм — это очень много времени, его можно было потратить с большей пользой для проекта. Тут было два решения: активный пиар (чтобы был поток извне, сами люди приходили) + отстраивание HR и перекладывание рекрутинговой части на него. Был заход в кадровые агенства, девочки хорошие, но в целом выхлоп слабый, мы — неудобный клиент с очень высокими запросами, зарабатывать на нас сложно. 2. Нет, нам важно чтобы юниты покрывали. 3. сценариев. Возможно по 2-3 ещё кто-то из тестирования добавит.
Сейчас не обладаю полной информацией, к сожалению. Что могу сказать: проект у нас очень большой и триггеров/чеков просто огромное количество, как раз совсем недавно мы превысили некоторую критическую массу плотности событий, это создает определенное давление на команду, но мы боремся. У нас смена всего один-два человека. Касательно формирования: «стандартный» рекрутинг обеспечил примерно треть, две трети — знакомые. Насчет того, нравится народу или нет — у ребят разные навыки и стремления, кто-то доволен, кто-то вообще хочет стать программистом, кто-то ещё выполняет админские задания и хочет стать админом — я думаю, что у каждого своё видение. Времени прошло мало, чтобы сделать выводы. Важно: если без саппорта можно обойтись, то без мониторинга — нельзя. Так что так или иначе роль «расставлять триггеры, втыкать в дашборды и быстро реагировать на проблемы» — такая роль должна быть всегда.
Вы правы, что такой метод определения ботов может сработать, но в нашем случае форма очень простая и всего одна, так что скорее всего бото-писатель напишет не код, который старается автоматом пробиться через форму (как это может сделать поисковый бот, например) — а будет запрограммирован так, чтобы передавать только нужные поля.
Почти все все ответы будут «нет» = нет информации. Чтобы было «да» — нужно сильно больше испытаний. Можно так подобрать разделение на уровни, что ждать надо будет _очень_ долго. Но ты прав про регрессионный анализ, он не сложнее решения уравнений, и будет работать.
Это все варианты адаптивных методов, решение должно работать. Но думаю, что Вам только кажется, будто сходимость будет лучше. Именно потому, что «в математику вдаваться не стал».
Погоди. Если у тебя каждый вариант ответа — случайная величина, то скорее всего при четких баллах ты попадешь в интервал от 0 до 12. А теперь представь, что тебе вместо 0...12 будут отвечать всегда одно «не прошел». Какая регрессия? У тебя просто нет информации, никакой. Весь прикол не в том, что метод не сработает — сработает и тот же адаптивный — а в том, что требуется значительно бОльшее число испытаний, чтобы получить «разные» варианты.
Отличные доподнения, спасибо! Насчет модификации: возможно, но у меня не было цели найти наиболее эффективный алгоритм, я просто хотел показать математически, как интуиция подводит :) Что касается генетических алгоритмов: именно с них я и начал, но там тяжело показать сходимость. Фактически я случайно придумал вот этот другой способ, и он оказался куда более наглядным.
Пол-цента за капчу, да, но послушай: это же надо значительно сильнее заморочиться :) Что касается пузомерки: её и так пришлось ограничить из-за хэд-хантеров, так что со временем топскор сделаем и всё.
С новыми тестами (у меня куплено уже под сотню новых) наверняка четкий фидбек уберу — это самое действенное.
Методом, который я привёл — никто не воспользовался пока. Я его сам придумал, пока пытался оценить сходимость адаптивного метода. Что касается Ваших советов, они все по делу, спасибо.
Я, ребят, наверное, сейчас немного нас всех подставлю, но это очень хороший кейс, самое интересное было в 2008-2009, когда проект фактически стал отходить к Майклу Шаддлу и умирать. Можете считать меня тщеславным ублюдком, мне всё равно — это просто очень хороший кейс для всех красноглазых заек. В 2009-м году если бы я вас не распинал и не выделил официально время внутри Badoo на порт fpm в ядро пхп (Антон Довгаль официально на работе имел проект номер один — перенос FPM в ядро PHP), — так вот сидели бы мы, вероятно, до сих пор с неподдерживаемым патчем, с собственным либевентом, и странным мейнтейнером микро-хостером, которому просто очень нужен process spawning. Ну и очень-очень большой вклад в проект сделал Jerom Loyet.
Думали, и пока думаем. Причины две: (1) стоимость перехода, риски и (2) неопределенность на рынке.
1) Badoo — проект с одним из крупнейших в мире кластеров БД — много сотен серверов. Поэтому стоимость любого проекта по миграции будет для нас очень высока.
2) Мы используем дистрибутив Percona. За последний год-полтора развернулась плотная борьба трех дистрибутивов MySQL. Три-четыре года назад (когда мы пересели на Percona) был вечно-тормозящий с патчами Oracle (заблудившийся в бранче 6.0, с массовым исходом окешихся и не очень сотрудников), странная Maria и слизанный с Oracle, но не тормозящий со сторонними патчами XtraDB. Теперь же многое поменялось. Сейчас мы видим, что Percona реально отстаёт. И очень хорошо набирает Oracle (я где-то читал, что у них уже работает под 200 человек над MySQL уже). У нас также есть свой патч (его сделал Костя Осипов, это фикс давнишней проблемы со вложенными пользовательскими блокировками), — этот патч, кстати, быстро приняла только Maria. Oracle и Percona тупят. То есть сигналы о том, что Maria хороша — они идут где-то последние полгода. Плюс неожиданная поддержка гигантов (вероятнее всего когда они поняли, что Oracle очень хорошо прёт). Но и Oracle не отстает. Так что скорее всего мы немного подождем, посмотрим, что происходит, как будет реагировать Percona. Для нас если уж делать переход, то года на три, а то и на пять. Очень важный шаг.
Ясно, соглашусь с Вами. Для меня «небольшой» = с небольшой нагрузкой. Это некорректно, Вы правы. У нас десятки тысяч запросов в секунду на кластер приложений, порядок запросов к кластеру баз — примерно такой же. Меня смутило, что Вы написали про «десятую долю».
огласите, пожалуйста
1) какую СУБД вы используете
2) число запросов в секунду на
* application server/cluster
* database server/cluster
3) какие аналитические задачи решаются через Hibernate
4) размер команды, поддерживающей проект
5) время жизни проекта
6) приблизительное число сущностей (таблиц)
7) приблизительное число строк java-кода
спасибо
Меняйте работу и прислушайтесь к себе. Если Вы уже перешли на темную сторону — назад дороги нет. Если сомневаетесь — может быть, не поздно в девелоперы назад. А вообще аутсорсинг — так себе бизнес. Лучше работать в продуктовой компании.
С новыми тестами (у меня куплено уже под сотню новых) наверняка четкий фидбек уберу — это самое действенное.
1) Badoo — проект с одним из крупнейших в мире кластеров БД — много сотен серверов. Поэтому стоимость любого проекта по миграции будет для нас очень высока.
2) Мы используем дистрибутив Percona. За последний год-полтора развернулась плотная борьба трех дистрибутивов MySQL. Три-четыре года назад (когда мы пересели на Percona) был вечно-тормозящий с патчами Oracle (заблудившийся в бранче 6.0, с массовым исходом окешихся и не очень сотрудников), странная Maria и слизанный с Oracle, но не тормозящий со сторонними патчами XtraDB. Теперь же многое поменялось. Сейчас мы видим, что Percona реально отстаёт. И очень хорошо набирает Oracle (я где-то читал, что у них уже работает под 200 человек над MySQL уже). У нас также есть свой патч (его сделал Костя Осипов, это фикс давнишней проблемы со вложенными пользовательскими блокировками), — этот патч, кстати, быстро приняла только Maria. Oracle и Percona тупят. То есть сигналы о том, что Maria хороша — они идут где-то последние полгода. Плюс неожиданная поддержка гигантов (вероятнее всего когда они поняли, что Oracle очень хорошо прёт). Но и Oracle не отстает. Так что скорее всего мы немного подождем, посмотрим, что происходит, как будет реагировать Percona. Для нас если уж делать переход, то года на три, а то и на пять. Очень важный шаг.
1) какую СУБД вы используете
2) число запросов в секунду на
* application server/cluster
* database server/cluster
3) какие аналитические задачи решаются через Hibernate
4) размер команды, поддерживающей проект
5) время жизни проекта
6) приблизительное число сущностей (таблиц)
7) приблизительное число строк java-кода
спасибо