Наивное понимание прикладной социологии гиков характерно для Авторов. Попробуем разобраться. Речь пойдет не о клинических социопатах, зачехлите свои огнеметы.

Мне нравятся модели Венката и Чепмена: the Gervais Principle и MOPs. Ниже вольный перевод модели Чепмена об эволюции субкультур с моими комментариями.

I.

Гиковские сообщества умерли в конце 2000-х. Не так давно сдался последний из могикан, Скотт Александр. С ним ушел целый праксис гиков. Один редактор из NYT играючи свалил мощное генеалогическое древо информационных гигантов, корни которого уходят в гимназию Фашори в Будапеште. Венгерские марсиане дали нам фон Ноймана и [вставить любого крупного математика и физика 20 века], Интернет, Фидо, Хабр.

Мне повезло, я еще застала агонию lesswrong сообщества, где каждый юзер чекал свои Байесовы прайоры перед тем, как начать пост или комментарий. Скотт был одним из самых заметных писателей на lesswrong после Элиэзера Юдковски. Его блог slatestarcodex был последним убежищем рационалистов и эффективных альтруистов в сети. Все рационалисты знают его настоящую фамилию, но упоминать ее в приличном обществе не принято. Скотт понял, что после статьи в NYT его мирок будет доступен казуалам и сознательно ушел в подполье.

Никакой воды в этой статье, только описание конкретного плана действий в случае если вы перегорели, у вас дедлайн, прокрастинация, депрессия, а также методики и советы, помогающие привести этот план в действие.

Привет Хабр! Это мой первый пост, и я хотел бы поделиться опытом создания IF-игры на Twine. Рассказать о преимуществах и недостатках инструмента, которые заметил во время работы, ну и немного о самой игре.



Началось все пять месяцев назад, когда мне предложили сделать IF-игру.

За 15 лет работы разработчиком я обнаружил, что ложные убеждения о человеческой природе — основные враги хорошей декомпозиции. Если знать о них и стремиться не угодить к ним в ловушку, со временем можно сформулировать советы по созданию качественной декомпозиции. Так произошло со мной, и я спешу поделиться этим знанием.

Привет, Хабр!

По моим наблюдениям, всех людей можно разделить на три категории: счастливчиков с нормальным телосложением, худых, кто не знает как бы поправиться, и полных, кто не знает как бы похудеть. Мне угораздило попасть в третью категорию, и всю взрослую жизнь мой вес колебался в районе 95кг при росте 1.74м, что соответствует BMI=31.4 или ожирению. И хотя в принципе, это ничуть не мешало, но все же лишний вес накладывает определенные ограничения, как в перспективе состояния здоровья, так и в плане личной жизни. Наконец, в один прекрасный день я решил что «пора», и занялся этим вопросом более серьезно.



Думаю, среди IT-шников, работающих в офисе, немало людей с похожими проблемами, и надеюсь, мой опыт будет им полезен.

2,4 ГГц — это плохо. 5 ГГц — это хорошо. 6 ГГц — это ещё лучше, но послезавтра. Все это знают, кого я тут учу, в самом деле. Всё это хорошо, только делать-то что, когда ты такой, как умный, открываешь какой-нибудь Wi-Fi Explorer, а там сатанизм и этажерки, как на скриншоте?



Шаг первый — поплакать. Шаг второй — нырнуть под кат. Вопрос простой, а ответ — нет.

Три года назад ведущий геймдизайнер ArenaNet Дженнифер Шойрле завела в Твиттере очень интересный тред на тему «отличных игровых механик, скрытых от глаз игрока с целью достижения определенного эмоционального эффекта, реакции или поведения», где любой геймдизайнер мог поделиться своими внутриигровыми «фишками».

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

• В Hellblade предупреждение перед игрой было тщательно продумано, чтобы заставить игроков поверить, будто в игре срабатывает система permadeath в случае, если игрок умирает слишком часто, хотя на самом деле ее там нет.
• Pacman может огибать углы более резко, чем это делают призраки, тем самым наделяя игрока небольшим преимуществом.
• Во многих шутерах последние очки здоровья стоят больше всей остальной шкалы, чтобы усилить чувство «выживания на грани». С той же целью в System Shock последняя пуля нанесет урон в 4 раза более сильный, чем остальные.
• И, напротив, Shadow of Mordor слегка увеличивает здоровье некоторых врагов, чтобы бои длились дольше.
• В Bioshock и Devil May Cry, находясь за спиной игрока, противники замедляют свою атаку.
• В Xcom, если промахнуться много раз подряд, игрок получит скрытый бонус для последующих выстрелов. Кроме того, если игроки остаются пассивными слишком долго, враги усиливают свою агрессивность.
• Похоже, что в Heartstone есть pity timers ― таймеры жалости. Многие другие игры позорно использовали их в более ранние годы.
• В Resident Evil 4 после слишком большого количества смертей заспавнится меньше врагов, чтобы дать игроку больше шансов пройти трудный для него эпизод.
• В любой гоночной игре реализован адаптивный ИИ, чтобы сделать соревнование более жестким.

Список можно продолжать и продолжать. Это настоящий кладезь подсказок от успешных геймдизайнеров.

В данной статье мы еще больше углубимся в эту тему и попытаемся уловить смысл таких трюков сквозь призму опыта игрока.

В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам "Дядя Боб" пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).

Сейчас же я хочу рассказать, что такое монады на самом деле, чем они полезны для обычного практикующего разработчика, и приведу примеры, почему недостаточная поддержка их в распространенных языках приводит к копипасте и ненадежным решениям.

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

Получается, что первые обычно полезны тем, кто и так знает обсуждаемую тему, а вторые даже не знаю на кого рассчитаны: сколько я их не прочитал, ничего полезного понять из них мне не удалось.

Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.

«Какой толк в книге, — подумала Алиса, — если в ней нет ни картинок, ни разговоров?»
Льюис Кэрролл, «Алиса в Стране чудес»

Всем привет!

Мы уже привыкли к тому, что все чаще информацию нам стараются подать с элементами инфографики. Визуальные материалы воспринимаются и запоминаются быстрее, чем символьные. Образы подтягивают в нашем мозге эмоции и аналогии, с символами все намного сложнее.

К визуализации данных в СМИ, интернет-ресурсах, печатных изданиях часто привлекают дизайнеров и художников. Но нередко инфографика нужна в более «скромных» ситуациях — например, для представления информации в отчетах организации или отдела, подведения итогов этапа или проекта, анализа результатов определенного периода. Для этих целей привлечение дизайнеров может быть слишком затратно по финансам и времени. 

Я работаю преподавателем и руководителем группы разработки учебных материалов в учебном центре «Сетевая Академия ЛАНИТ» более 10 лет и, когда провожу разработанный нами курс по инфографике, то обычно начинаю так: «Наш курс не для дизайнеров, а для тех сотрудников, которым нужно научиться правильно применять доступные средства для быстрого и качественного представления данных».

И в статье будет не про космические корабли, бороздящие просторы вселенной, а про кастрюли…

Источник

Невозможно полноценно тестировать и отлаживать мобильные приложения без тестовых устройств. Таких устройств должно быть много, потому что один и тот же код на разных моделях ведёт себя по-разному. Но как организовать учёт устройств? Как сделать так, чтобы разработчики и тестировщики быстро и без волокиты получали конкретный смартфон в необходимой конфигурации?

Меня зовут Алексей Лавренюк. Вы можете знать меня как одного из авторов Яндекс.Танка и докладчика на тему нагрузочного тестирования. Потом я измерял энергопотребление мобильных телефонов. Теперь я делаю Яндекс.Ровер в команде беспилотных автомобилей (и иногда подрабатываю Дедом Морозом). А между телефонами и Ровером был Гиперкуб.

Пару лет назад в наш отдел нагрузочного тестирования зашёл руководитель мобильной разработки и пожаловался на ситуацию с тестовыми устройствами. Телефоны кочевали из рук в руки, выбрать и быстро найти телефон было проблемой. У нас уже был опыт работы с мобильными устройствами: мы строили цифровой амперметр, чтобы измерять их энергопотребление. Поэтому мы решили помочь коллегам и быстро сделать классную штуку: казалось, работы всего на три месяца. Смеюсь над собой, наивным, из 2020 года и рассказываю, что нас ждало на самом деле.

Привет, Хабр!

Я потихоньку перевожу статьи Маркуса Винанда из блога use the index luke.

Первой статьей в цикле был манифест Маркуса о важности использования безофсетной пагинации на ключах. Мы рассмотрели всего один пример, как этот подход работает на практике. В этой и следующих статьях я буду обосновывать такой подход — с графиками и примерами, как все любят.

У нас, айтишников, часто возникает задача напечатать что-то простое и одноразовое – например, логин и пароль новому сотруднику, тикет для монтажника или что-то в этом роде. Тратить бумагу и картридж на подобное очень дорого. При этом есть принтеры с ультрадешёвой скоростной печатью, про которые редко кто вспоминает, хотя видим мы их все каждый день по много раз. Речь про чековые термопринтеры.

На хабре не нашлось обзоров «более быстрой альтернативы Redis» — KeyDB. Получив достаточно свежий опыт его использования, хочется восполнить этот пробел.



Предыстория достаточно банальна: однажды с большим наплывом трафика была зафиксирована значительная деградация производительности приложения (а именно — времени ответа). На тот момент, к сожалению, не удалось провести нормальную диагностику происходящего, поэтому впоследствии запланировали ряд нагрузочных тестирований. После их проведения удалось обнаружить узкое место, коим стал кэш базы данных в Redis. Как это часто бывает, проблему нельзя было решить сию секунду и правильным путём — силами разработчиков (изменением логики работы). Поэтому включилось любопытство и желание побороть ситуацию обходным путём. Так и появилась эта статья.

Избегаем оценочных суждений! Дробим предложения. Выкидываем ненужное. Не льем воду.
Факты. Цифры. И без эмоций.

«Информационный» стиль, прилизанный и гладкий, накрыл технические порталы с головой.
Привет постмодерн, теперь наш автор мертв. Уже взаправду.

В экосистеме PHP существует много инструментов, обеспечивающих удобное тестирование на PHP. Одним из самых известных является PHPUnit, это почти синоним тестирования на этом языке. Однако о хороших методиках тестирования пишут не так много. Есть много вариантов, для чего и когда писать тесты, какого рода тесты, и так далее. Но, честно говоря, не имеет смысла писать тест, если позднее вы не сможете его прочесть.

Тесты — это особая разновидность документации. Как я ранее писал о TDD на PHP, тест всегда будет (или хотя бы должен) ясно говорить о том, в чём заключается задача конкретной части кода.

Если один тест не может выразить эту идею, то тест плохой.

Я подготовил набор методик, которые станут подспорьем для PHP-разработчиков в написании хороших, удобочитаемых и полезных тестов.

Что такое магия в PHP? Обычно под этим подразумевают методы вроде _construct() или __get(). Магические методы в PHP — это лазейки, которые помогают разработчикам выполнять удивительные вещи. В сети полно инструкций по их использованию, с которыми вы наверняка знакомы. Но что если мы скажем, что вы даже не видели настоящую магию? Ведь, чем больше вам кажется, что вы знаете все, тем больше магии ускользает от вас.



Давайте отбросим установленные рамки правил ООП и сделаем невозможное возможным в школе магии PHP. Главный и первый волшебный преподаватель школы — Александр Лисаченко (NightTiger). Он научит магическому мышлению и, возможно, вы полюбите магические методы, нестандартные способы доступа к свойствам, изменение контекстов, аспектно-ориентированное программирование и потоковые фильтры.

Как изменилась структура российского (постсоветского) общества с середины XX века. Спойлер: она изменилась кардинально.

Поделиться моими исследованиями половозрастной пирамиды России с общественностью посоветовали мои знакомые и друзья. Некоторые из них утверждают, что в исследованиях есть научная ценность. Хотя я не демограф, а просто любопытный программист.

Введение

Зашел тут на Хабр и нашел в черновиках не опубликованную статью про капчу, хотел было её оформить и опубликовать, но решил написать новую статью немного поменяв механизм и используемый инструментарий. Старую статью по моему мнению будет полезно почитать, хуже не будет.

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

Прошёлся недавно по поисковой выдаче гугла и выяснил, что регистрация прав на программу для ЭВМ стоит около 15 тыс. рублей. 15 тыс. рублей! И это ещё без пошлины.

Я удивился, потому что подготовка документов занимает минут тридцать. Чёрт с ним, пускай даже один час, но 15 тыс. рублей за час — это более чем достойное вознаграждение.

Зашёл на сайт Роспатента: инструкции там есть, но четкой картины не дают. На месте руководителя маленького IT-проекта я бы не стал подавать заявление сам — вдруг что-то сделаю не так.

Но я же юрист, и процедуру эту проходил не раз. Так почему бы мне не помочь стартаперам? Подумал-подумал, и не нашёл аргументов против. Так что давайте вместе попробуем подготовить документы и направить их в Роспатент, сэкономив при этом в среднем 15 тыс. рублей.

Функциональное программирование — это очень забавная парадигма. С одной стороны, про неё все знают, и все любят пользоваться всякими паттерн матчингами и лямбдами, с другой на чистом ФП языке обычно мало кто пишет. Поэтому понимание о том, что же это такое восходит больше к мифам и городским легендам, которые весьма далеко ушли от истины, а у людей складывается мнение, что "ФП подходит для всяких оторванных от жизни программок расчетов фракталов, а для настоящих задач есть зарекомендовавший себя в бою проверенный временем ООП".

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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