Надежность системы: проблемы наблюдались в июле 2019-го — заказы не оформлялись в течении часа. Но это было до глобального переезда. В дальнейшем крупных инцидентов не наблюдалось.
Не сочтите за попытку дискредитировать, но просто вот 14 февраля 2020 года мы с женой решили провести романтический вечер, тогда еще COVID-19 был далеко и домашний вечер со свечами казался чем-то очень необычным, но как всегда помешали «тупые проблемы», пришлось даже написать в маркетинг Тануки. Правда ответа так и не последовало…
Расскажите что за проблемы были в этот день?
Ввиду последних событий, мне почему-то кажется, что смотреть нужно в сторону Mail.ru Group и выше. Можно даже прикинуть кто этими «своими» может оказаться в итоге.
Про тестирование на 2% аудитории вы хорошо вспомнили: 200Гб на Яндекс.Диске мне очень пригодились, спасибо!
А если серьезно, я бы еще вспомнил про платформу «Атом», которую как раз из Метрики предлагалось обучать, поэтому подобная «мотивация» для привлечения новых площадок вполне логична.
Я думаю что все чуть хуже, т.к. uid-vk-злоумышленника будет привязан к аккаунту жертвы в базе сайта (в моем случае мне нужна своя база юзеров). И когда злоумышленник зайдет на сайт «войти через ВКонтакте», то сайт достанет по полученному vk-uid аккаунт жертвы. Таким образом, злоумышленник будет авторизован под видом жертвы. Кажется так.
Решил проникнуться атмосферой OAuth 2.0 и посмотрел как он реализован у разных сервисов. Когда изучал документацию Mail.ru, обратил внимание на примечание по безопасности внизу страницы. Решил попробовать проделать подобное на своем сайте через «ВКонтакте». В результате мой UID-контакта привязался к профилю другого пользователя («жертвы»).
Посмотрел документацию для FaceBook, там описан пример и используется параметр «state», в котором передается ключ (сессия пользователя). Потом посмотрел проект спецификации OAuth 2.0 и в ней параметр «state» тоже предусматривается.
Затем я решил воспользоваться этим параметром и для «ВКонтакте», однако сервер проигнорировал его и вернул ответ без него. Предложенный Mail.ru вариант уникального «request_uri» кажется мне не очень удобным. Может быть есть какие-то еще предложения?
P.S. Думаю, что если спецификация будет окончательно утверждена, то все-таки получится что-то удобное, но пока очень много расхождений в реализации OAuth 2.0 у разных сервисов.
Спасибо за эту подборку. Ее, конечно, можно еще расширять и расширять. На мой взгляд, mockflow.com — гораздо богаче чем Frame Box. Но нет русскоязычной поддержки.
Не стоит смешивать понятия концепции и ТЗ. На мой взгляд, концепция — систематизированные «желания заказчика». ТЗ — план работы для разработчика. Если угодно, концецпция должна дать качественный ответ на вопросы «Что будем делать?» и, иногда, «Кто будет делать?», а ТЗ — на вопрос «Как делать?».
В случае с небольшими проектами, когда заказчик — это два или три человека, а разработчики — группа людей, которые могут разместиться в одной комнате, то концепция и ТЗ могут быть объединены. Если же «заказчик» — большая организация с внутренними подразделениями и им нужен серьезный web-инструмент удобный для всех, тогда надо делить концепцию и ТЗ. При этом, концепция должна быть полностью понятна людям сторонним от мира разработки, но написана не в виде эссе, а быть логичным структурированным и систематизированным документом. Любой, кто будет работать с web-ресурсом, прочитав концепцию, должен четко понять как он будет работать с ресурсом и какие возможности ему будут предоставлены. В свою очередь, ТЗ должно разрабатываться на основании концепции и, в первую очередь, оно предназначено для разработчиков. Естественно, ТЗ должно быть максимально конкретизировано.
В статье и в комментариях прочел много здравых мыслей, даже сделал себе тезисный конспект из наиболее лаконичных и важных высказываний.
Эта статья дает лишь один ответ на вопрос из заголовка — «Разработка Концепции/ТЗ — обязательна для любого проекта», но этот ответ слишком бесформенный и всеобъемлющий, практически как 42.
Кстати, раз уже были упомянуты мокапы, кто-то может поделиться линокм на хороший обзор существующих средств для создания макетов интерфейса?
Давно ждал этого события, созидал муки и радости разработчиков, видел их переживания, связанные с постоянными переносами релиза. Но теперь, хочу их сердечно поздравить и, надеюсь, что они получать полный NIXProve вложенных усилий и затрат! Ура! Ура! Ура!
ну так элемент с ID «w» может быть только один на странице. Поэтому, в лучшем случае, css получиться примерно таким #w1, #w2, #3 {background:#fff;}. А если мы создадим просто класс .w{background:#fff;} и для всех белых пикселей будет указывать его, то это даст большую экономию, если рассматривать итоговый результат.
Кстати, в тему про капчи, можноли с помощью php генерить анимированный gif? Если можно, тогда надо сделать чтобы символы в капчи появлялись поочередно. Причем скорость появления была различной.
Ну id точно нет, т.к. для иконок 16X16, в рамках одного дизайна, впринципе можно выделить каждый цвет в отдельный однобуквенный класс, и потом использовать повторно. А id — это для каждого пикселя (читай блока) нужен будет свой класс, что повлечет за собой еще css-ину куда большего размера.
Не сочтите за попытку дискредитировать, но просто вот 14 февраля 2020 года мы с женой решили провести романтический вечер, тогда еще COVID-19 был далеко и домашний вечер со свечами казался чем-то очень необычным, но как всегда помешали «тупые проблемы», пришлось даже написать в маркетинг Тануки. Правда ответа так и не последовало…
Расскажите что за проблемы были в этот день?
А если серьезно, я бы еще вспомнил про платформу «Атом», которую как раз из Метрики предлагалось обучать, поэтому подобная «мотивация» для привлечения новых площадок вполне логична.
Посмотрел документацию для FaceBook, там описан пример и используется параметр «state», в котором передается ключ (сессия пользователя). Потом посмотрел проект спецификации OAuth 2.0 и в ней параметр «state» тоже предусматривается.
Затем я решил воспользоваться этим параметром и для «ВКонтакте», однако сервер проигнорировал его и вернул ответ без него. Предложенный Mail.ru вариант уникального «request_uri» кажется мне не очень удобным. Может быть есть какие-то еще предложения?
P.S. Думаю, что если спецификация будет окончательно утверждена, то все-таки получится что-то удобное, но пока очень много расхождений в реализации OAuth 2.0 у разных сервисов.
В случае с небольшими проектами, когда заказчик — это два или три человека, а разработчики — группа людей, которые могут разместиться в одной комнате, то концепция и ТЗ могут быть объединены. Если же «заказчик» — большая организация с внутренними подразделениями и им нужен серьезный web-инструмент удобный для всех, тогда надо делить концепцию и ТЗ. При этом, концепция должна быть полностью понятна людям сторонним от мира разработки, но написана не в виде эссе, а быть логичным структурированным и систематизированным документом. Любой, кто будет работать с web-ресурсом, прочитав концепцию, должен четко понять как он будет работать с ресурсом и какие возможности ему будут предоставлены. В свою очередь, ТЗ должно разрабатываться на основании концепции и, в первую очередь, оно предназначено для разработчиков. Естественно, ТЗ должно быть максимально конкретизировано.
В статье и в комментариях прочел много здравых мыслей, даже сделал себе тезисный конспект из наиболее лаконичных и важных высказываний.
Эта статья дает лишь один ответ на вопрос из заголовка — «Разработка Концепции/ТЗ — обязательна для любого проекта», но этот ответ слишком бесформенный и всеобъемлющий, практически как 42.
Кстати, раз уже были упомянуты мокапы, кто-то может поделиться линокм на хороший обзор существующих средств для создания макетов интерфейса?