В статье прямо говорится: прийти хотя бы к грубому заключению
Вот мне и интересно исходя из каких цифр выводится это заключение. Стратегий можно придумать множество, но никакие из них не дают даже примерных результатов, если вы не обладаете входными данными
Например, вы можете оттолкнуться от того, что Манхеттен занимает площадь примерно в 23 квадратных мили, и прикинуть количество пиццерий на единицу площади. А затем оценить, сколько доставок ежедневно осуществляет каждое заведение, и прийти хотя бы к грубому заключению.
Интересно каким образом можно прикинуть количество пиццерий на единицу площади и количество ежедневных доставок
Согласен. И стоит учитывать что отчет Facebook (о котором тут правда ничего не сказано) скорее всего основан на их аудитории, логично что большая часть ЦА социальных сетей использует смартфоны.
Очень сильно сомневаюсь в правдивости данной статьи. Скорость взаимодействия с колесиком мыши зависит не только от конфигурации оси и железа, но еще и от того с какой скоростью пользователь непосредственно крутит колесико мыши (а это зависит от уровня вовлеченности, настроения и кто знает чего еще). Ну вот вы видите числа от 0 до 150 (допустим), в зависимости от того, как быстро пользователь крутит колесо, как это поможет его вычислить?
Бенчмарк процессора из той же серии. Главное упомянуть чтобы пользователь не забыл выключить видео/стрим в соседней вкладке, а лучше вообще все приложения закрыл, а то вдруг вместо Core i7 бенчмарк выдаст Core i5
Ну, суть статьи видимо в том, чтобы ткнуть носом, мол обещали свою разработку а компоненты используете заморские. Главное чтобы дальше не пошли, а то ведь колесо, например, тоже изобретение не наше.
А железо все равно работает с машинными кодами. Язык — это всего лишь инструмент, не более того. У каждого инструмента свои преимущества и недостатки, и именно наличие недостатков или отсутствие преимуществ вызывают появление новых языков. С никуда не денется, но сейчас он не нужен в тех количествах, в каких был нужен раньше, а вопросы о «учить/не учить» поднимаются в основном для молодых разработчиков.
Ну тут следует учесть что шанс этот напрямую зависит от кол-ва записей в базе. Если у вас в базе уже есть несколько сотен миллионов GUID'ов, то шанс нарваться на коллизию значительно выше чем в случае «сгенерировать два идентичных ключа». Интересно кстати было бы посчитать вероятности
Я конечно понимаю, что шанс сгенерировать два одинаковых GUID'a очень мал, но что будет если это все-таки произойдет? Отловить ошибку и попытаться вставить с новым GUID'ом? А если и тогда сгенерирует существующий?
Лично я вот например не могу понять каким образом люди наталкиваются на «все больше и больше» блокировок. Я провожу в интернете больше 12 часов в сутки, и при этом могу припомнить только недоступный менее суток гитхаб. И это с момента введения закона. Именно поэтому меня (как и абсолютное большинство) мало волнует проблема блокировок.
Не всегда можно описать проблему скрином. Скрин хорошо помогает когда есть что-то чего не должно быть («Вот тут кнопка активная, а должна быть неактивная»). А как вы будете скринить то чего нет, да еще и с последовательностью действий которая к этому привела? («Не появляется окно 'свойства' при нажатии кнопки свойства в контекстном меню более одного раза»)
Возможно в случае хабра действительно не потребуется много работы. Однако лично мне все равно неприятна идея совмещения Markdown и HTML, видимо слишком сильна привычка единого style-guide'а.
И помимо парсера Markdown нам еще нужен парсер кастомных тегов. Да и выглядит это не очень эстетично. Мне кажется лучше уж тогда использовать wysiwyg-редактор.
С моей точки зрения Markdown хорошо подходит для написания небольших статей с минимум оформления. Как только у вас начинается вложенность стилей или нестандартные теги (какой аналог для <video></video> или <spoiler></spoiler> вы предлагаете?) ваша разметка перестанет быть читабельной очень быстро.
Буквально пару недель назад столкнулся с этой проблемой в форумном движке NodeBB, где Markdown является по сути дефолтным видом разметки. Пришлось писать свой BBCode-плагин, чтобы не городить синтаксические конструкции в духе
!>{name}(value)
У меня такое ощущение что это инструкция для людей которых палками заставляют писать модули (да и любые программы в принципе).
Обычно если проект ваш — вы уже имеете идею, представляете себе примерные пути решения, возможно даже имеете какие-то тестовые куски кода (а иногда и вполне рабочие) еще до того как зашла речь о публикации вашей разработки.
Если же проект не ваш — тогда обычно сначала нужно пообщаться с заказчиком, составить список требований, выбрать технологии, набросать ТЗ, в общем сделать кучу увлекательных дел.
Хотя это конечно мое личное мнение, быть может у многих людей другая методология разработки.
Было бы неплохо периодически говорить зачем мы начинаем те или иные преобразования. Я потерял смысловую нить уже к 5 уравнению, а когда взгляд упал на «Введем матрицу» (11), я совсем потерялся. Для меня все это выглядит как математика ради математики.
Потому что мы надеемся, что она станет началом продуктивной дискуссии о том, как разработчики браузерных игр могут противостоять кибер-мошенникам.
Мне не очень нравится определение «кибер-мошенник». Я например считаю логичным, что человек должен использоваться свои сильные стороны. У кого-то есть отличная реакция, у кого-то сутки свободного времени, а я предпочитаю использовать ум.
Защиту от хаков сделать не так уж и сложно. Уже упомянутый вами эмулятор, полное недоверие к получаемым данным, грамотный серверсайд-код — дефолтные практики в этом деле.
Защиту от ботов сделать невозможно в принципе, можно лишь усложнить разработку. В конечном счете затраченные усилия должны окупаться, хотя это уже зависит от разработчика бота.
Из необычны могу вспомнить небольшую флеш-игру, которую мэйловцы делали, когда разыгрывали ключи раннего доступа к Archeage. Игрок видел N одинаковых статуй и должен был выбирать «правильную» для получения очков. Когда я посмотрел код я обнаружил, что при нажатии на сервере банально кидается рандом независимо от статуи на которую ты кликал, создавая иллюзию выбора. Это конечно не помешало создавать сотни аккаунтов и «брутфорсить», но тем не менее «иллюзия управления» очень меня удивила, т.к. игрок действительно считал что его выбор значим.
Браузерные игры основаны на временных затратах и переводе времени в деньги. Боты несомненно дают в них профит, но как правило донат все равно позволяет обогнать бота, да и разработка бота тоже стоит времени / денег.
Лично я использую телефон только для звонков, т.е. вообще не использую карту памяти. Для музыки — плеер. Если иду куда-то где надо будет долго чего-то ждать — планшет. Единственное возможное применение телефона кроме звонков я вижу в фото/видео съемке, но я очень редко пользуюсь этими функциями.
Вот мне и интересно исходя из каких цифр выводится это заключение. Стратегий можно придумать множество, но никакие из них не дают даже примерных результатов, если вы не обладаете входными данными
Интересно каким образом можно прикинуть количество пиццерий на единицу площади и количество ежедневных доставок
Бенчмарк процессора из той же серии. Главное упомянуть чтобы пользователь не забыл выключить видео/стрим в соседней вкладке, а лучше вообще все приложения закрыл, а то вдруг вместо Core i7 бенчмарк выдаст Core i5
<video></video>или<spoiler></spoiler>вы предлагаете?) ваша разметка перестанет быть читабельной очень быстро.Буквально пару недель назад столкнулся с этой проблемой в форумном движке NodeBB, где Markdown является по сути дефолтным видом разметки. Пришлось писать свой BBCode-плагин, чтобы не городить синтаксические конструкции в духе
!>{name}(value)Обычно если проект ваш — вы уже имеете идею, представляете себе примерные пути решения, возможно даже имеете какие-то тестовые куски кода (а иногда и вполне рабочие) еще до того как зашла речь о публикации вашей разработки.
Если же проект не ваш — тогда обычно сначала нужно пообщаться с заказчиком, составить список требований, выбрать технологии, набросать ТЗ, в общем сделать кучу увлекательных дел.
Хотя это конечно мое личное мнение, быть может у многих людей другая методология разработки.
Мне не очень нравится определение «кибер-мошенник». Я например считаю логичным, что человек должен использоваться свои сильные стороны. У кого-то есть отличная реакция, у кого-то сутки свободного времени, а я предпочитаю использовать ум.
Защиту от хаков сделать не так уж и сложно. Уже упомянутый вами эмулятор, полное недоверие к получаемым данным, грамотный серверсайд-код — дефолтные практики в этом деле.
Защиту от ботов сделать невозможно в принципе, можно лишь усложнить разработку. В конечном счете затраченные усилия должны окупаться, хотя это уже зависит от разработчика бота.
Из необычны могу вспомнить небольшую флеш-игру, которую мэйловцы делали, когда разыгрывали ключи раннего доступа к Archeage. Игрок видел N одинаковых статуй и должен был выбирать «правильную» для получения очков. Когда я посмотрел код я обнаружил, что при нажатии на сервере банально кидается рандом независимо от статуи на которую ты кликал, создавая иллюзию выбора. Это конечно не помешало создавать сотни аккаунтов и «брутфорсить», но тем не менее «иллюзия управления» очень меня удивила, т.к. игрок действительно считал что его выбор значим.