Пьяный программист сидит с открытым Norton Commander на экране. На обоих панелях открыт диск С. «Ну и зачем мне два диска С с одними и теми же файлами?» — подумал он и стер все его содержимое, нажав F8 и Enter.

— анекдот конца 80-х годов

Нортон (Norton Commander) for DOS – это файловый менеджер для DOS, который существовал в 5 основных версиях – 1.0, 2.0, 3.0, 4.0, 5.0, причем только последняя версия имеет подверсию 5.5. Многие версии до сих пор используются различными энтузиастами и лежат на различных сайтах по сети Интернет.

Это был, возможно, один из самых популярных файловых менеджеров в эпоху операционной системы DOS, который наряду с XTree порвал со своими корнями DOS и в виде других программ, унаследовавших его функциональность, которые существуют на других операционных системах.

От редакции блога: наверняка многие помнят историю про поселок программистов в Кировской области — начинание экс-разработчика из Яндекса впечатлило многих. А наш разработчик решил создать свое поселение в братской стране. Передаем ему слово.



Привет, меня зовут Георгий Новик, я работаю бэкенд-разработчиком в Skyeng. В основном реализую хотелки операторов, менеджеров и других заинтересованных лиц в отношении нашей большой CRM, а еще подключаю всякие новомодные вещи для customer service — ботов для техподдержки, сервисов автоматического прозвона и пр.

Как и многие разработчики, я не привязан к офису. Что делает человек, который не обязан ежедневно ездить в контору? Один отправится жить на Бали. Другой осядет в коворкинге или на родном диване. Я же выбрал совсем другое направление и переехал на хутор в белорусских лесах. И теперь от меня до ближайшего приличного коворкинга 130 километров.

Некролог: Митчелл Фейгенбаум, (1944‑2019), 4.66920160910299067185320382…

Статья из блога Стивена Вольфрама



Она называется постоянная Фейгенбаума и равняется примерно 4,6692016. И она с завидной периодичностью возникает в определённых видах математических – и физических – систем, способных демонстрировать хаотичное поведение.

Митчелл Фейгенбаум, ушедший от нас 30 июня в возрасте 74 лет, был открывшим её человеком – в 1975 году, и сделал это, занимаясь экспериментальной математикой на карманном калькуляторе.

Это открытие стало определяющим в теории хаоса. Но когда её обнаружили впервые, этот результат был неожиданным, причудливым, не связанным ни с чем из того, что изучалось ранее. Однако некоторым образом тот факт, что её открыл именно Митчелл Фейгенбаум – с которым я был знаком почти 40 лет – кажется подобающим.

Мы потратили на создание этой игры несколько лет. От неё зависит будущее нашей семьи. Почему же она так ужасно выглядит?

Я уже 25 лет зарабатываю на жизнь написанием инди-игр. У нас с женой есть небольшой семейный бизнес. Мы создаём низкобюджетные ролевые игры в ретро-стиле с отличным сюжетом, дизайном и геймплеем.

Но все они выглядят как куча навоза.

Первая моя игра, выпущенная в январе 1995 года, тоже выглядела ужасно. Она достигла финансового успеха (очевидно, среди слепых людей), благодаря чему мне удалось профинансировать много других ужасно выглядящих игр и создать себе солидную репутацию.

Благодаря этой репутации мы провели на Kickstarter успешную кампанию по сбору средств на Queen's Wish: The Conqueror — потрясающую RPG, которая тоже будет выглядеть чудовищно. Мы надеемся, что она станет фундаментом для дальнейшего создания ужасно выглядящих игр.

Мы ни на что не жалуемся. Мы находимся на пике долгой и успешной карьеры, и всё просто чудесно. Однако иногда я люблю писать о бизнесе создания инди-игр, помогать людям понять его принципы, а также давать советы менее опытным разработчикам. Эта статья о том, почему наши игры выглядят именно так, нравится вам это, или нет (скорее всего, нет).

Самое главное заключается в том, что я хочу защитить право инди-разработчиков быть странными. Если у инди-разработчика появится безумная, творческая идея, и он испугается её реализовать, но подумает: «Это можно и сделать; по крайней мере, я не настолько сумасшедший, как Джефф Вогель», то я буду считать свою миссию выполненной.

Итак, если вам интересно, почему мы пишем игры, которые выглядят и ВСЕГДА будут выглядеть как куча навоза, то продолжайте чтение.

Год назад я начал работать на полную ставку в Bloomberg. И тогда же задумал написать эту статью. Я думал, что буду полон идей, которые смогу выплеснуть на бумагу, когда придёт время. Но уже через месяц понял, что всё будет не так просто: я уже начал забывать то, чему научился. Либо знания настолько хорошо усвоились, что мой разум заставил меня поверить, будто я всегда это знал, либо они просто вылетели у меня из головы.¹

Это одна из причин, по которой я начал вести дневник. Каждый день, попадая в интересные ситуации, я описывал их. И всё благодаря тому, что я сидел рядом с ведущим программистом. Я мог вблизи наблюдать за его работой, и видел, насколько она отличается от того, что сделал бы я. Мы много программировали вместе, что ещё больше облегчало мои наблюдения. Более того, в нашей команде не осуждается «подглядывание» за людьми, пишущими код. Когда мне казалось, что происходит что-то интересное, я поворачивался и смотрел. Благодаря постоянным вставаниям я всегда был в курсе происходящего.

Я год просидел рядом с ведущим программистом. Вот чему я научился.

Необходимое вступление

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

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

Мы разбирали старые письма и наткнулись на статью, которую писал Илья Сегалович iseg для журнала «Мир Internet» в далёком 2002 году. В ней он сравнивает интернет и поисковые системы с чудесами света, размышляет о поисковых технологиях и вспоминает их историю. Несмотря на загруженность по работе, Илья написал статью в рекордные сроки и даже снабдил достаточно подробным словарём терминов, который особенно интересно читать в наши дни. Нам не удалось найти электронную версию журнала со статьей, поэтому сегодня мы публикуем её в нашем блоге, первым автором которого, к слову, был Илья.

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

Современные часы имеют невероятные дополнительные функции

Классик писал, что счастливые часов не наблюдают. В те дикие времена ещё не было ни программистов, ни Unix, но в наши дни программисты знают твёрдо: вместо них за временем проследит cron.

Утилиты командной строки для меня одновременно слабость и рутина. sed, awk, wc, cut и другие старые программы запускаются скриптами на наших серверах ежедневно. Многие из них оформлены в виде задач для cron, планировщика родом из 70-х.

Я долго пользовался cron поверхностно, не вникая в детали, но однажды, столкнувшись с ошибкой при запуске скрипта, решил разобраться основательно. Так появилась эта статья, при написании которой я ознакомился с POSIX crontab, основными вариантами cron в популярных дистрибутивах Linux и устройством некоторых из них.

Используете Linux и запускаете задачи в cron? Вам интересна архитектура системных приложений в Unix? Тогда нам по пути!

(издание 2018)

Miguel Grinberg

---

Туда Сюда

Это девятнадцатая часть серии мега-учебника Flask, в которой я собираюсь развернуть Microblog на платформе Docker.

Рассуждая о функциональном программировании, люди часто начинают выдавать кучу «функциональных» характеристик. Неизменяемые данные, функции первого класса и оптимизация хвостовой рекурсии. Это свойства языка, помогающие писать функциональные программы. Они упоминают мапирование, каррирование и использование функций высшего порядка. Это приёмы программирования, использующиеся для написания функционального кода. Они упоминают распараллеливание, ленивые вычисления и детерменизм. Это преимущества функциональных программ.

Забейте. Функциональный код отличается одним свойством: отсутствием побочных эффектов. Он не полагается на данные вне текущей функции, и не меняет данные, находящиеся вне функции. Все остальные «свойства» можно вывести из этого.

Нефункциональная функция:

a = 0
def increment1():
    global a
    a += 1

Функциональная функция:

def increment2(a):
    return a + 1

Вместо проходов по списку используйте map и reduce

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

Многие современные исследовательские статьи активно используют байесовский формализм в сочетании с глубокими нейросетями, приходя к интересным результатам. Мы – исследовательская группа BayesGroup с помощью наших друзей из Сколтеха, а так же при поддержке Высшей Школы Экономики, Сбербанка, Яндекса, Лаборатории Касперского, JetBrains и nVidia – решили поделиться накопленным опытом и устроить летнюю школу по байесовским методам в глубинном обучении Deep|Bayes, где подробно рассказать, что такое байесовские методы, как их комбинировать с глубинным обучением и что из этого может получиться.

Отбор на школу оказался весьма сложным занятием – мы получили более 300 заявок от сильных кандидатов, но вместить смогли только 100 (приятно, что среди участников были не только жители Москвы и Петербурга, но и студенты из регионов, а так же русскоговорящие гости из-за границы). Пришлось отказать многим сильным кандидатам, поэтому для смягчения этого прискорбного факта мы решили сделать доступными максимальное количество материалов, которыми и хотим поделиться с хабраюзерами.

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

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

Программы поиска уязвимостей всегда привлекают немало внимания со стороны хакеров и специалистов по безопасности. Ведь это легальный способ неплохо зарабатывать одними только поисками багов (при условии, что есть хороший опыт и голова на плечах). На днях нам представилась возможность взять интервью у багхантера Ивана reactors08 Григорова. Он лидер нашей программы Bug Bounty и занимает 11-е место в общем рейтинге платформы HackerOne.

Как начать искать баги? Может ли это быть единственным источником дохода? В каких Bug Bounty участвовать? Сколько зарабатывают багхантеры? И почему поиском уязвимостей особенно выгодно заниматься в кризис? Ответы на эти и другие вопросы читайте в нашем интервью.

Содержание

• Часть 1: Введение
  
• Часть 2: Manifold learning и скрытые (latent) переменные
  
• Часть 3: Вариационные автоэнкодеры (VAE)
  
• Часть 4: Conditional VAE
  
• Часть 5: GAN (Generative Adversarial Networks) и tensorflow
  
• Часть 6: VAE + GAN
  

Во время погружения в Deep Learning зацепила меня тема автоэнкодеров, особенно с точки зрения генерации новых объектов. Стремясь улучшить качество генерации, читал различные блоги и литературу на тему генеративных подходов. В результате набравшийся опыт решил облечь в небольшую серию статей, в которой постарался кратко и с примерами описать все те проблемные места с которыми сталкивался сам, заодно вводя в синтаксис Keras.

Автоэнкодеры

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



Кому интересно, добро пожаловать под кат

Введение

Python, точнее его самый известный представитель CPython, не очень предназначен для каких-либо быстрых расчетов. Иначе говоря, производительность у него не такая уж хорошая. А вот скорость разработки и читаемости отличная.

О читаемости и пойдет речь, а точнее как ее увеличить.

Как получить работу инженера?

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

# x = количество компаний, в которых ты проходил собеседования

# y = количество предложений о работе, которые ты получил

рейтинг = 100 * log(x) * y / x


Если твой рейтинг < 90, обязательно прочти это. Если > 120, возможно, тебе это не нужно, но, все равно прочти.

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

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


Сцена из Minecraft, до и после добавления нескольких шейдеров.

Задача этого туториала

Иногда программирование шейдеров представляется загадочной чёрной магией и его часто понимают неправильно. Существует множество примеров кода, демонстрирующих создание невероятных эффектов, но в которых практически нет объяснений. В своём руководстве я хочу восполнить этот пробел. Я сосредоточусь в основном на базовых принципах создания и понимания кода шейдеров, чтобы вы смогли с лёгкостью настраивать, сочетать или писать свои собственные шейдеры с нуля!