• Гитхаб начал блокировать репозитории пользователей из Крыма, Кубы, Ирана, Северной Кореи и Сирии
    0
    airtable достаточно серьезная контора, в США они на слуху:
    www.crunchbase.com/organization/airtable#section-overview
  • Гитхаб начал блокировать репозитории пользователей из Крыма, Кубы, Ирана, Северной Кореи и Сирии
    0
    Отжимать танкеры в международных водах должно быть недопустимо на международном и государственном уровне.
    Иран нарушил этот закон. 3 или 4 раза за последний месяц. Что делать?

    Не говоря уже о полуостровах с миллионами жителей.

    Ничего лучше чем санкции, который бьют по всем бизнесам и гражданам целиком, пока не придумали.
  • Гитхаб начал блокировать репозитории пользователей из Крыма, Кубы, Ирана, Северной Кореи и Сирии
    0
    Предполагаю, там счас очередь этих Appeal Requests сформируется на месяцев 5…
  • Гитхаб начал блокировать репозитории пользователей из Крыма, Кубы, Ирана, Северной Кореи и Сирии
    +1
    Но в Сирии ими бомбили террористов.

    нет.
    Карта расположения террористов — Игил на востоке Сирии, что логично, поскольку они пёрли с Ирака cofda.files.wordpress.com/2015/01/syria-territory-map-jan-2015.jpg

    РФ же бомбила запад, к примеру Идлиб: www.independent.co.uk/news/world/middle-east/syria-russian-air-strikes-kill-at-least-73-people-in-rebel-held-idlib-a6780741.html

    Скорее всего основная цель не столько защита Ассада как создание потока беженцев чтобы Европе и Турции было чем заняться.
  • Microsoft блокирует аккаунты иранцев по национальному признаку
    0

    Пишут что также в «счастливчиках» Крым, Сирия, Северная Корея и Куба.
    Сам гит достаточно децентрализован, по сравнению с другими сервисами, но сколько инструментов построено вокруг него!

  • РКН заблокировал несколько КРУПНЫХ подсетей Amazon и Google (UPD.: и продолжает блокировать новые!)
    0

    А swift еше не заблокировали?

  • Сервис нагрузочного тестирование loadme
    0
    Добавлен новый регион — Франкфурт.
    Пинг к Российским/Украинским ресурсам уменьшился на 20-30 милисекнунд.
  • Рейтинг скорости загрузки интернет-магазинов
    0
    Так и есть.
    И хотя среднюю скорость загрузки уложить в 2-3 секнуды не так уж сложно, добиться этого от первой загрузки хотя бы для 90% клинетов довольно сложно.
  • Сервис нагрузочного тестирование loadme
    0
    Поддержка HTTPS исправлена!

    Однако, сертификаты сгенерированные самостоятельно, или же с истекшим срок действия, не поддерживаются.
  • Сервис нагрузочного тестирование loadme
    0
    не знал, но 150 баксов в месяц за один load generator…
  • Сервис нагрузочного тестирование loadme
    0
    1. скорость канала компьютера, с которого проводится тест:
    Распределяем тест на до 25 серверов. К примеру, если результирующая скорость 250 мегабит то сетевая нагрузка каждого сервера-агента была всего 10 мегабит.

    2. Проблема кеширования
    а) Можно подмешивать второстепенные url: к примеру, 5 основных ссылок и 5 второстепенных
    б) использование $RND дает случайный запрос к серверу и к базе данных. Да, поиск будет идти по одним и тем же индексам, но в базе будут найдены другие результаты, в памяти будут десериализированы другие объекты, отрендерена новая страница, системы кеширования ввода вывода не сработают
  • Кондолиза Райс, бывшая глава госдепа США, вошла в совет директоров Dropbox
    +1
    С точки зрения борьбы с монополистами я бы стразу выбросил Google drive (я им еще google reader не простил), OneDrive и Yandex.

    С точки зрения NSA и ко — они работают на сетевом уровне — это проще, тем более о дыре в openssl они знали.

    Для Dropbox пользователи их системы это все, они будут на них молиться и защищать любой ценой. Запрет на распространение copyright контента — это защита вашего же контента от жалоб правообладателей, потому что закрытый судом dropbox явно не входит в ваши интересы. Судиться и что-то им доказывать, конечно, можно но вам то ваш файл нужен будет сегодня а не через 5 лет, когда закончится судебный процесс.
  • Корректная обработка проблем аутентификации AJAX-запросов для приложений ASP.NET MVC
    +3
    Интересный ньюанс, Спасибо.
    Однако, судя по разделу «О себе» — Microsoft MVP & Microsoft Regional Director — статья должна заканчиваться примерно так:
    «Также я создал bug в проекте MVC 5 — обещали исправить»
  • Украинский рынок разработки: кто, почем и сколько
    0
    Если вас не пугает 25% ставка по ипотечным и прочим кредитам, отсутствие дорог и избирательность правосудия — добро пожаловать!
  • Рейтинг скорости загрузки интернет-магазинов
    0
    Ваша формулировка вопроса теоретически верна, но она вступает в силу только когда требуется масштабирование и autoscaling
    При вычислительной мощности 100+ страниц в секунду и реальной нагрузке 3 страницы в секунду мы наоборот сидим и думаем — чем бы ещё пригрузить сервер, чтобы сделать лишний заказ в день?
  • Рейтинг скорости загрузки интернет-магазинов
    0
    Не знаю, как у кого, но я не вижу особого смысла кэшировать страницы кроме главной.
    К примеру, вчера сайт отдал 111 тысяч страниц.
    Из них — 40845 разных.
    Страниц, запрошенных более 100 раз за день всего 36.

    С другой стороны, ежедневно меняются цены и наличие для примерно 20000 товаров.

    Вот и какой смысл кэшировать?
    Наверно, посещаемость будет 10M страниц в день, я буду думать по другому, но сколько таких eCommerce проектов в мире — 200?
  • Рейтинг скорости загрузки интернет-магазинов
    0
    1. Данные выглядят субъективными:
    У меня boutique ~1с, sotmarket.ru — 1.5с, что не соотвтествует данным результам.

    На самом деле писать такие тесты можно только для себя. Чтобы увидеть реальную картину лучше использовать данные от реальных пользователей. К сожалению, google analytics не раскрывает таких данных о чужих сайтах, но есть и другие варианты.
    К примеру, Alexa.com — плагин, который стоит у многих пользователей и репортит время загрузки. По её данным, у пользователей sotmarket.ru открывается в среднем за 1.163 с, boutique.ru — 1.634 Seconds, что вполне неплохо. А вот Komus.ru, занявший 3е место — 1.238 Seconds?

    2. Мы для abo.ua добились отдачи страниц с скоростью порядка 100mbps (1 сервер), что в десятки раз превышает текущие потребности. По мнению алексы, пользователи получают страницу в течении 0.565 Seconds.

    Если вы хотите сделать быстрый магазин — актуальнее тестировать не закэшированную домашнюю страницу, либо простую страницу товара, а рандомную выборку товаров, которая бы показала силу «движка». К примеру, телевизоры с ценой до random().
    И тогда результаты будут совсем другими. Чтобы это тестировать мы делаем специальную «рандомную» страницу, которая каждый раз ищет разные данные и тестируем на скорость.

    И я не сказал бы, что добиться высокой скорости работы сложно, особенно, что касается времени загрузки в браузере. Достаточно воспользоваться google pagespeed insights.
    Если вдруг кому интересно как мы оптимизировали serverside — основные советы собраны в этой презентации socialtalents.com/page/100mbps (правда, на английском)

    Ну и вообще, нужно оценивать степень параллелизма — каким образом меняется скорость работы с увеличением количества клиентов. К примеру, у нас начинаеся снижение производительности после 80 параллельных юзеров в секунду, и это уже проблема, которая заставляет задуматься…
  • То, чего еще никто не писал про Нокиа, Элопа и горящую платформу
    +1
    Много интересных фактов. Выводы, как по мне, слишком стратегически, но в любом случае спасибо.
    Мне почему-то кажется, вам может быть интересно почитать историю flickr:
    gizmodo.com/5910223/how-yahoo-killed-flickr-and-lost-the-internet
  • EC2 — анализ цен для стартапа
    +1
    Математика, конечно же, представляет собой ценность, но предположение о равномерной загрузке на протяжении трех (!) лет само по себе сомнительно.
    В моем опыте:
    1) меняется ТЗ
    2) улучшается алгоритм (за год мы улучшили время работы в одном проекте раза в 4е, в другом — раз в двадцать). Т.е. одна и та же мощность может обслуживать всё большее количество клиентов
    3) меняется схема развертывания — проект/его части переписывается на другие технологии, которые могут менять желаемую конфигурацию, выделяются компоненты, и их тоже удобно размещать на отдельных серверах.
    4) А вот объем информации и трафик растёт постоянно. И это тут не учитывается.

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

    Если год назад 1.5 терабайт трафика (обычный + cloudfront) влетел нам в usd250, то с сегодняшней посещаемостью это была бы примерно тысяча долларов в месяц, и превысило бы затраты на вычислительную мощность раза в два.

    Как следствие, оказалось выгоднее перенести проект на банальный dedicated server, с тарификацией порядка $10/TB вместо $150 у амазона. Скорость выросла в 3 раза. затраты снизились в 4 раза.

    Для надёжности информация реплицируется в amazon, в котором есть snapshot приложения, которое можно стартонуть (15 минут), пользователи получат доступ к проекту в течении обновления dns (ttl у нас 15 минут). Да, не так красиво, но реальная экономия более 10 тысяч долларов в год.
  • Lenovo показала 10 килограммовый планшет
    +1
    тут пишут что 7.7 кг:
    www.trustedreviews.com/news/lenovo-ideacentre-horizon-table-pc-launched

    Думаю, за год еще клиограмм-другой скинет. Ну и может подешевеет.
  • MongoDb в действии — интернет магазин
    0
    Так это ж mysql, статья то про монго, которую, как минимум, легко раскидать по разным серверам.

    В монго у вас будет другая база, другие запросы и другие индексы.
    Вообще, когда индексов больше данных, это как-то нездорово.
  • MongoDb в действии — интернет магазин
    0
    Тогда вам один путь — искать возможность уменьшить объем данных. Когда проект станет зарабатывать данных, скорее всего, станет еще больше.

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

    Ну и на всякий случай
    — убедиться, что количество запросов при каждой загрузке страницы o(1)
    — Можно посмотреть, здесь описываются детальная оптимизация запросов: derickrethans.nl/indexing-free-tags.html

  • MongoDb в действии — интернет магазин
    0
    ссылка классная, так тоже можно работать.
  • MongoDb в действии — интернет магазин
    0
    Задумывался, но для нас вопрос транзакций вообще не актуально.

    Функция это хорошо, но ведь админ по ошибке может вырубить свет как раз в момент ее выполнения. Я бы скорее завел таблицу операций, писал бы туда всю необходимую информацию в одну запись.
    Асинхронный процесс выгребает операции и обновляет связанные объекты — habrahabr.ru/post/149047/#comment_5040625
  • MongoDb в действии — интернет магазин
    0
    Так и сколько ж там индексов?
    Выделить сервер с 8GB (лучше, конечно 16GB) памяти не такая космическая задача на сегодня.
  • MongoDb в действии — интернет магазин
    0
    Спасибо за идею, попробуем
  • MongoDb в действии — интернет магазин
    0
    Основной вывод по монго — жаль что я его не сформулировал в самой статье — что структура базы намного ближе к коду, с ней проще работать, чем sql. Хочешь реляции? Пожалуйста. хочешь словари — пожалуйста, хочешь массив с идексом — да без проблем.

    Особенно удобно в связке с основнанной на json библиотекой knockout, которая обеспечивает взаимодействие с пользователем.
  • Как, зная только имя и email человека, злоумышленники получили доступ ко всем его аккаунтам и удаленно уничтожили информацию на всех его устройствах
    +1
    Не актуально — не все помнять последние 4 цифры старых/утерянных кредиток
  • MongoDb в действии — интернет магазин
    0
    Блин, как раз в обычной реляционной.

    PS: Тот абзац чуть поправил.
  • MongoDb в действии — интернет магазин
    0
    В обычной не реляционной базе это была бы пачка запросов, а не 1:
    Запросить товар
    запросить картинки
    запросить видео
    запросить характеристики

    Особенно резко все ухудшается при необходимости показать список объектов, у каждого их которых есть подобъекты — lazy loading быстро портит сокрость выполнения
  • MongoDb в действии — интернет магазин
    +1
    Ключевая таблица — Transactions — туда пишем 1 запись с двумя (в монго можно и больше, главное чтобы сумма была 0) объектами:
    { Changes: [ { User: «User1», Amount: +X}, {User: «User2», Amount: +X } ] }

    Когда нам нужно достоверно знать количество денег на счету — находим все changes по user = myid и считаем сумму.

    Осталось только придумать (на вкус и цвет) стратэгию кэширования остатков, чтобы не делать полный пересчет каждый раз.
  • MongoDb в действии — интернет магазин
    0
    Давайте разберем пример операции, где дествительно, важно чтобы изменения нескольких объектов были сохранены именно одновременно, может что и придумаем :)
  • MongoDb в действии — интернет магазин
    –2
    Без сомнений, вы правы, но шанс с этим столкнуться в реальной жизни минимальный. С каждым новым обновлением уверенность в надежности системы растет, скорость выхода обновлений также радует.

    Пока все разборы полетов на тему «у нас пропали картинки у колясок» заканчивались выявлением неправильной работы пользователей.
  • MongoDb в действии — интернет магазин
    0
    Тормозов от количества оперативки не заметил. Сейчас mongod занимает в памяти 10G, при основной базе 14 + staging где-то столько же.

    А вот скорость выполнения как бакапов, так и восстановления базы дейстивтельно не радует и поднимает новые вопросы.
  • MongoDb в действии — интернет магазин
    0
    У всего есть предел, в том числе в том, сколько технологий можно освоить профессионально одновременно.

    Судя по сайту, neo4j не предоставляет api для .net, так что надо будет искать что-то еще [более сырое]. Вполне возможно, лучше уж забивать графы монгой.
  • Немного про повторное использование объектов
    0
    Ну, данный пример слегка упрощен.

    ЧТобы реализовать object pooling в универсальный механизм сериализации / десериализации придется попотеть.

    Много лет назад, когда каждый программист должен был написать свой ORM, я получил существенный выигрыш в реализации такого шаблона при получени данных от базы.
  • MongoDb в действии — интернет магазин
    0
    Мы наоборот, используем ms sql для ряда исключительных задач.

    Основной аргумент против двойной базы — сложность восстановление информации. Бакапы не могут быть сделаны в один и тот же момент, и после восстановления системы базы не будут совпадать.

    Я тоже переживал за категории в Монго — оказалось очень удобно, к примеру вот такую страницу в случае использования sql придется, наверно, кэшировать. Я не написал, но этот проект не использует OutputCaching вообще — все страницы, запросов бывает до 15 тысяч в час, рендерятся на лету.

    Мы же в каждой категории сохраняем id лучших 10 товара, которые ее представляют, и потом вычитываем товары, которые ее показывают.

    Запрос 1 — найти категорию
    запрос 2 — найти 44 товара

    Не помню сколько в сумме, где-то на уровне 1/20 секунды.

    Один из прошлых проектов с деревом в 100000 узлов на ms sql безбожно тормозил.
  • MongoDb в действии — интернет магазин
    0
    Как только появляется «много произвольных атрибутов» то монго резко становится намного удобнее MS SQL.

    1. Сходу, напрашивается сохранять всех предков в монго.

    2. Насколько часто происходит перемещение объектов между папками? По сути — это единственная проблема, которую я сейчас вижу. Но мне кажется для ms sql это тоже была бы проблема.

    3. 100 тысяч узлов для монго это не много. Также, за счет того что можно использовать композицию — несколько объектов в одну запись, вероятно количество объектов может быть меньшем чем в реляционном варианте.

    Если хотите — могу проконсультировать в индивидуальном порядке.
  • MongoDb в действии — интернет магазин
    0
    Это на таблицу товаров, 4GB
  • MongoDb в действии — интернет магазин
    0
    0.5 GB
    Индексов довольно много:
    — id
    — категории
    — внешнему id (товары синхронизируются с 1C)
    — цене
    — ключевым словам для поиска
    — SeoFriendlyUrl
    — приоритет показа
    — название