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

Я уже пытался лечить «механический» scrum (часть 1, часть 2, часть 3), а в этой статье постараюсь выписать универсальное лекарство от «подгорания». Само по себе «подгорание», «бурление» и т.п. — это хорошо, это значит вам не все равно (а ведь безразличие — это шаг к унынию, или, как принято в IT — к выгоранию). На тему вреда выгорания написано и снято много материалов, например: вот, вот, вот или вот.

Одна распространенная мудрость гласит: «Баттхёрты — двигатель прогресса». Но часто бывает так: пригорело => быстро принимается поверхностное решение, маскирующее проблему => решение воплощается в жизнь => пригорать продолжает. Другими словами, вместо того, чтобы разобраться и поставить диагноз, мы сразу приступаем к лечению. Попытаюсь это проиллюстрировать примерами.

Предисловие

Не так давно пришлось поработать с упрощением полигональной цепи (процесс, позволяющий уменьшить число точек полилинии). В целом, данный тип задач очень распространен при обработке векторной графики и при построении карт. В качестве примера можно взять цепь, несколько точек которой попадают в один и тот же пиксель – очевидно, что все эти точки можно упростить в одну. Некоторое время назад я практически ничего не знал об этом от слова «совсем», в связи с чем, пришлось в быстром темпе восполнять необходимый багаж знаний по этой теме. Но каково было мое удивление, когда в интернете я не нашел достаточно полных руководств по этому вопросу… Мне приходилось отрывками искать информацию с совершенно разных источников и, после проведенного анализа, выстраивать все в общую картину. Занятие не из самых приятных, если честно. Поэтому мне хотелось бы написать цикл статей, посвященных алгоритмам упрощения полигональной цепи. Как раз-таки начать я решил с наиболее популярного алгоритма Дугласа-Пекера.

Эволюция — дело тонкое. Медленный и сложный процесс адаптации какого-либо организма к условиям окружающей среды, появление одних и вымирание других видов, генетические мутации и т.д. Мы частенько слышим слово «эволюция», но сам процесс ввиду его продолжительности наблюдать воочию не можем. Нам остается только рассматривать окаменелости и сравнивать их с современными организмами, выискивая общие черты и отличия, возникшие с течением времени. Либо сравнивать разные виды из одного семейства, обитающие в разных регионах. Эволюция также не лишена чувства юмора, ибо как иначе объяснить существование утконосов, кенгуру, рыбы-капли, гарпий, единорогов и т.д. Так, кто-то тут явно лишний.

Время, как мы привыкли его понимать, линейно и движется вперед, как и эволюция. Однако не всем организмам это по душе, посему некоторые делают шаг или несколько шагов назад, возвращаясь к предыдущим стадиям своего развития. Этот процесс называют ре-эволюцией. Самыми же любопытными являются существа, находящиеся где-то вне всех этих понятий. К таким относятся и ящерицы вида Saiphos equalis, самки которых способны как откладывать яйца, так и рожать детенышей. Такая материнская неопределенность, что удивительно, не распределена между особями, а может быть присуща одной и той же самке: захотела — сделала кладку, захотела — родила. Сегодня мы с вами познакомимся с наблюдением, в котором впервые детально изучили эту особенность. Какие структурные изменения присутствуют в скорлупе, почему ученые не готовы отнести данный вид ящериц к ре-эволюции и при каких условиях самки предпочитают кладку яиц, а не роды? Ответы ждут нас в докладе исследовательской группы. Поехали.

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

Глава отдела разработки и вычислительного дизайна в Automattic (материнской компании WordPress) считает, что дизайнерам следует быть кем-то вроде вспомогательных актёров в технологических компаниях, оставляя главную роль разработчикам и менеджерам по продукту.

Жил был моряк. У него было две любимых женщины в разных портах, и он хотел детей – вот только не решил, одного или двух. Он решил кинуть монету. Орел – будет один ребенок от одной из женщин (к которой первой зайдет в порт по работе – это уж как получится), решка – сделает по ребенку каждой женщине. Неизвестно, как выпала монета, и как его бросала судьба по миру, но вы – его ребенок. Какова вероятность, что вы – его единственный ребенок?

Обложка книги Electric State. Источник: Amazon

Думаю, многие знают цифрового художника Саймона Сталенхага, рассказывающего в своих работах немного странную, но завораживающую историю приключений девочки и жёлтого робота в некоем постапокалиптическом\киберпанковом мире.

Не раз и не два доводилось видеть дискуссии на тему «как же правильно переводить слово state?».

А я подумал: почему бы не спросить самого автора?

Часть 1. Вобще-то уже все поделили до нас!
Часть 2. Истина где-то рядом

В прошлой части мы расширяли алгебру и смогли делить на ноль арифметически. В качестве бонуса, способ оказался не единственным. Однако, все эти алгебры не дали ответа на вопрос: “Что там внутри или почему нам это не показывают?”

Пока древние вязали узелки, такой вопрос возникнуть не мог. Сейчас, куда не глянь, “бла-бла, для а≠0”. Значит ответ затаился где-то между узелками и настоящим. В математике все строго и последовательно, а значит и ответ не мог потеряться.

Часть 1. Вобще-то уже все поделили до нас!
Часть 2. Истина где-то рядом

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

Добрый день, друзья. Сегодня мы подготовили для вас перевод первой части статьи «Лямбды: от C++11 до C++20». Публикация данного материала приурочена к запуску курса «Разработчик C++», который стартует уже завтра.

Лямбда-выражения являются одним из наиболее мощных дополнений в C++11 и продолжают развиваться с каждым новым стандартом языка. В этой статье мы пройдемся по их истории и посмотрим на эволюцию этой важной части современного C++.



Вторая часть доступна по ссылке:
Lambdas: From C++11 to C++20, Part 2

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



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

И этот тест, который, судя по большей части рассуждений об этом, люди исключительно фейлят.

И автор поста «Быть технофобом бессмысленно, даже если технофобия оправдана», несмотря на многообещающее название, похоже, не стал исключением, дойдя до торга, то есть, на стадии, когда люди пытаются make sense в привычном им значения этого понятия в обстоятельствах, отрицающих саму возможность подобного, путём рационализации. arttom сторговался на идее «чёрного ящика», по условиям которой:

1. люди соглашаются, чтобы непознаваемое осталось непознаваемым, и даже, в подтверждение своей добросовестности, соглашаются при этом ещё и немножко коллективно немножко отупеть — что, впрочем, не имеет никакого смысла с точки зрения интересов непознаваемого, которое от этого непознаваемее не станет;
2. взамен, люди получают это непознаваемое, каким бы они ни было непознаваемым, contained — внутри этого самого «чёрного ящика», то есть, всё-таки, до какой-то степени под контролем, ограниченным — и в этом смысле, всё же, осознаваемым, и не таким уже жутким, а буквально ограниченным.

То есть, тоже пока не справились с этим упражнением. И это очень плохо.

(Нашёл в твиттере тред с очень крутым объяснением работы симметричных шифров. Его написал Colm MacCárthaigh один из основных контрибьюторов Apache. Я спросил разрешение Колма на перевод, он любезно согласился).

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

Итак, симметричное шифрование — это именно то, что мы используем в большинстве случаев, когда хотим зашифровать кучу данных. Ваш браузер отправляет и получает данные, используя симметричное шифрование. Если вы шифруете файлы или диск, в этом случае тоже работает симметричное шифрование. iMessage, Signal, WhatsApp — все они используют симметричное шифрование для безопасности вашей переписки.

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

Вот простой пример. Допустим, у меня есть строка "Ovaltine" и я хочу её зашифровать. Я мог бы воспользоваться rot13 — очень простым олдскульным шифром Цезаря, который делает хоровод из букв, где a и z держатся за ручки, и заменяет каждую букву другой буквой алфавита, которая находится от заменяемой буквы на расстоянии 13 символов. Таким образом "O" превращается в "B", а "v" становится "i", в итоге "Ovaltine" превращается в "Binygvar". Конечно, это не очень безопасно. Это наивный пример, который очень легко взломать, так как атакующий может выяснить, какая буква встречается чаще всего (обычно в оригинальном тексте это "e") и найти оставшиеся буквы подобным образом.

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



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

Блоки информации (chunks)

Чтобы свободно пользоваться новыми знаниями, к ним нужно привыкнуть. А привычка, как известно, дело времени. В книге Learning How to Learn (или на замечательном курсе на Coursera) блоки информации называются chunks, и в курсе рассказывается про их формирование. На это уходит время, которое на практике нельзя существенно ускорить.

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

Чтобы немного отвлечься от физики, временно сменим тему. Мне понадобится концепция “философского зомби” — ее бы, вероятно, пришлось бы долго объяснять, но на помощь пришел сериал “Мир Дикого Запада”:

Представьте себе задачу: у вас есть игра, и вам нужно, чтобы она работала с частотой 60 fps на 60-герцовом мониторе. Ваш компьютер достаточно быстр для того, чтобы рендеринг и обновление занимали несущественное количество времени, поэтому вы включаете vsync и пишете такой игровой цикл:

while(running) {
    update();
    render();
    display();
}

Очень просто! Теперь игра работает с 60fps и всё идёт как по маслу. Готово. Спасибо, что прочитали этот пост.


Ну ладно, очевидно, что всё не так хорошо. Что если у кого-то слабый компьютер, который не может рендерить игру с достаточной для обеспечения 60fps скоростью? Что если кто-то купил один из тех крутых новых 144-герцовых мониторов? Что если он отключил в настройках драйвера vsync?

Часть I
Часть II

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

---

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

Рассмотрим метод оценок при решении неравенств.
Дать оценку сверху означает определить максимальное значение, которое может принимать искомая величина.

Предположим, что цена за одну единицу товара может колебаться в пределах от 5 до 10 RUB. Для двух единиц товара оценка сверху составляет 10+10=20 RUB, оценка снизу 5+5=10 RUB.

Рассмотрим задачу из задачника профильной направленности М.И. Башмакова
37. Известны оценки для переменных $$ и $$

Дайте оценки сверху для следующих выражений:
1. $$
2. $$

5. $$
6. $$

8. $$
9. $$

Советы по грамотному написанию технической документации для пользователей.
Часть 2

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

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

В этой части мы подробно разберем топики, из которых в основном состоит пользовательская документация (особенно User’s Guide) – а именно task-топики, в которых рассказывается, как решить конкретную задачу.

Здравствуйте!

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

В первой статье явление естественной смертности мы рассматривали, так сказать, с самой высокой точки биологической организации. С этого уровня хорошо видно, за что могла «зацепиться» эволюция и начать устанавливать норму жизни для того или иного вида. С точки зрения создания эликсира бессмертия этот уровень нам совершенно не интересен, потому как к бессмертию мы хотим привести конкретную особь, а конкретные особи как известно не эволюционируют в биологическом смысле. Нам интересен механизм, посредством которого приговор приводится к исполнению и то, как сломать этот механизм. А значит в этой статье мы будем рассматривать проблему с более «низкой» точки зрения – индивидуальном и клеточно-молекулярном (я постараюсь сделать это как можно понятнее без зубодробительных биохимиоругательных слов).

Новый взгляд на извечный вопрос: следует ли переписывать приложение с нуля или это «самая худшая стратегическая ошибка, которую может сделать разработчик программного обеспечения»? Оказывается, при работе со зрелой кодовой базой есть более двух вариантов ответа.

«Исходный код словно заржавел!» — Джоэл Спольски

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

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