*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

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

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

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

Their main claim to fame comes from being featured in many introductory machine learning classes available online. As a result, a lot of newcomers to the field absolutely love autoencoders and can't get enough of them. This is the reason why this tutorial exists!

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

На просторах интернетов есть очень много туториалов по автоэнкодерам, нафига писать еще один? Ну, если честно, тому было несколько причин:

• Сложилось ощущение, что на самом деле туториалов примерно 3 или 4, все остальные их переписывали своими словами;
• Практически все — на многострадальном MNIST'е с картинками 28х28;
• На мой скромный взгляд — они не вырабатывают интуицию о том, как это все должно работать, а просто предлагают повторить;
• И самый главный фактор — лично у меня при замене MNIST'а на свой датасет — оно все тупо переставало работать.

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

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

Математики считают гипотезу Коллатца «болотом», и предупреждают друг друга, что от неё стоит оставаться подальше. Однако теперь Теренс Тао достиг большего прогресса, чем кто бы то ни было за несколько десятилетий.

Возьмите любое число. Если оно чётное, поделите его на два. Если нечётное, умножьте на три, прибавьте один. Повторите. Любое ли число в итоге приходит к 1?

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

Гипотеза Коллатца, возможно, простейшая из нерешённых задач математики – именно это и делает её такой предательски притягательной.

«Это очень опасная задача. Люди становятся одержимыми ею, при том, что она совершенно невозможна», — сказал Джеффри Лагариас, математик из Мичиганского университета, эксперт по гипотезе Коллатца.

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

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

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

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

С другой стороны, элементы функционального стиля программирования уже проникли в промышленные языки программирования, такие как Swift и Kotlin. Разработчики этих языков прекрасно знакомы с функциональным программированием, поэтому смогли применить его «в малом», предусмотрев многие, хотя и не все, необходимые компоненты. Чем дальше — тем больше части ФП внедряются в промышленные ЯП, и тем качественнее и полнее реализуется поддержка.

Уметь программировать в функциональном стиле полезно, чтобы упрощать себе работу, и сейчас мы посмотрим, как этим воспользоваться!


Виталий Брагилевский — преподаватель ФП, теории алгоритмов и вычислений, автор книги «Haskell in Depth» и участник комитетов Haskell 2020 и наблюдательного комитета компилятора GHC.

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



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

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

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

Некоторые опции Bash хорошо известны и часто используются. Например, многие в начале скрипта пишут

set -o xtrace

для отладки,

set -o errexit

для выхода по ошибке или

set -o errunset

для выхода, если вызванная переменная не установлена.

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

«Мы начинаем разработку новой игры, и нам нужна классная вода. Такую сможешь?»


, — cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.

Александр Алексеев (Postgres Professional)

Отличный обзорный доклад конференции HighLoad++ 2016 о том, как надо проводить профилирование программного кода. О типичных ошибках, происходящих при измерениях. И, конечно, об инструментах:

— gettimeofday
— strace, ltrace, truss
— gprof
— gdb / lldb
— perf
— pmcstat
— SystemTap
— DTrace
— HeapTrack
— BPF / bcc



В начале у меня будет не слишком техническая часть, о том, как не надо делать benchmark’и.

Я наблюдаю, что люди часто делают типичные ошибки, когда делают benchmark’и. И вот первая из них…

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

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

Не так давно я прочёл фантастический роман «Задача трёх тел» Лю Цысиня. В нём у одних инопланетян была проблема — они не умели, с достаточной для них точностью, вычислять траекторию своей родной планеты. В отличии от нас, они жили в системе из трёх звёзд, и от их взаимного расположения сильно зависела «погода» на планете — от испепеляющей жары до леденящего мороза. И я решил проверить, можем ли мы решать подобные задачи.

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

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

Я попытался узнать, в чем причина. И вообще — кто те люди, которые на нем пишут, и зачем они это делают, если язык не нужен бизнесу? Для этого я постучался поговорить в русскоязычное сообщество F# в «Телеграме». Здесь — наш круглый стол.

Этот пост будет не о том, как «перевести» код с C# на F#: различные парадигмы делают каждый из этих языков лучшим для своего круга задач. Однако вы сможете оценить все достоинства функционального программирования быстрее, если не будете думать о переводе кода из одной парадигмы в другую. Настало время любопытных, пытливых и готовых изучать совершенно новые вещи. Давайте начнем!

Все материалы из серии переводов русскоязычного сообщества F#-разработчиков вы сможете найти по тегу #fsharplangru.

На Хабре, по меркам старожилов, я совсем недавно, всего два года, но пишу активно, по возможности каждый день. Так вот, читая статьи, да и просто прокручивая ленту свежих публикаций как на Хабре, так и на GT, я понял, что многие просто не могут совладать с версткой текста и, как следствие, достаточно часто годные публикации хоронятся их же авторами из-за нечитабельности текста. Или отпугивает кривая КДПВ, или еще что произойдет.

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

Картинка Для Привлечения Внимания и выравнивание по левому краю

Так уж сложилось, что вся лента Хабрахабра выровнена по левому краю. По этой причине опытные авторы небольшие изображения оставляют слева или используют картинки шириной в 800-1000 px. Отдельно хочется заметить, что чуть ли не лучшим является соотношение КДПВ 2 к 1, т.е. изображения 800х400 px. Подобная пропорция позволяет SMM-щику соц. сетей не изгаляться с вашей картинкой (а то и вовсе искать что-то другое, более подходящее по размерам), а использовать оригинал, не нарушая задумки автора.