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

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

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

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

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

Эта статья о том, как извлечь максимум пользы из статической системы типов при дизайне вашего кода. Статья пытается быть language agnostic (получается не всегда), примеры на Java и взяты из жизни.

Привет, друзья!

Представляю вашему вниманию первую часть перевода этой замечательной книги по WebRTC. Данная часть посвящена тому, что такое WebRTC, процессу сигнализации и установки соединения (первые 3 части оригинала).

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

Ссылка на вторую часть перевода.

Если вам это интересно, прошу под кат.

Долгое время Rust позиционировался исключительно как язык для системного программирования. Попытки использовать Rust для высокоуровневых прикладных задач зачастую вызывали усмешку у значительной части сообщества: зачем использовать инструмент в том качестве, на которое он не рассчитан? Какая польза от возни с типами и анализатором заимствований (borrow checker), если есть Python и Java со сборкой мусора? Но другая часть сообщества всегда видела потенциал Rust именно как языка прикладного, и даже находила его удобным в использовании для быстрого прототипирования — во многом благодаря его особенностям, а не вопреки им.

Что делать, если накануне переезда повысилась тревожность, а привычные методы не приносят успокоения?

Конечно же вырабатывать дофамин через решение упоротых инженерных задач!

Мне стало интересно - насколько тяжко было бы сделать свой интерпретатор байт-кода Java? И насколько сложно было бы научить его “новым трюкам”?

Писать я буду на Rust, поэтому и проект, не мудрствуя лукаво, назвал Rjava.

В предыдущей статье блога мы обсудили краткую историю системного вызова select(2). В ней делается вывод, что для эмуляции консолей, игр и нетривиальных TCP/IP-приложений было необходимо определенное мультиплексирование ввода-вывода.

Разработчики BSD (Berkeley Software Distribution) выбрали модель мультиплексирования select, и за ними последовали другие Unix-подобные системы. Но является ли select единственной моделью мультиплексирования?

Тема эта стала неинтересной, всё то же и так же из раза в раз

Сеньоры начинают и проигрывают пенсионерам.

Это уже третий раз и должны уже наверно свыкнуться. ))

FizzBuzz по-сениорски

FizzBuzz по-пенсионерски

Продолжаем разгонять FizzBuzz

FizzBuzz по-македонски

Немного лирики. Хабр из места, где пишут в стиле "смотрите коллеги, можно и так ..." превратился в место хвастовства и рекламы. Пенсионеры хорошо знают, что невозможно написать код, который нельзя улучшить. И реальные сеньоры только рады, когда им пишешь про то, как можно улучшить их код. Я проверял ))

«Но за всей этой красотой скрывается хаос и безумие». — Tanner Walling

Почему?

1. Пролог

Сказ про то, как повысить надежность фронтенда с помощью CSS Modules, TypeScript и Webpack.

Вы задумывались, что такое объект? Что-то из реального мира: человек, машина, здание? Почему?

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

Хочу поделиться своим ООзарением с вами.

https://fakt309.github.io/thisisthewall/

В языках программирования строки сравниваются очень просто, если строка отличается хотя бы на один символ, то возвращает false.

Но вот что если мы хотим не просто получать дискретное значение (true / false), а дифференцированное, например в процентах. Ведь согласитесь строки test и testing гораздо ближе к друг другу, чем test и abcd. Для данной проблемы существует множество решений, мы поговорим о самый популярных алгоритмах (также об их модификациях):

Расстояние Хэмминга

Расстояние Левенштейна

Сходство Джаро — Винклера

Коэффициент Сёренсена

Задача

Решение

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

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

Но если внимательно посмотреть на эту схему, то можно заметить, что сами элементы очереди A, B, C линейно упорядочены. Так нельзя ли использовать в качестве очереди обычный массив с его .push() и .shift()?..

Насколько это будет эффективно, какие грабли встретятся на этом пути, и как их можно обойти - сегодня об этом.

Сегодня рассказ пойдет о двух удобных способах сократить рутину в Redux, которые мы используем в разных частях собственного проекта. Речь пойдет о малоизвестной библиотеке Type to reducer и довольно функциональном Redux toolkit. Почему нам было трудно жить с чистым Redux, зачем нужны вспомогательные инструменты и как они облегчают жизнь, читайте под катом.

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

Спор "Java vs. C#" существует чуть меньше, чем вечность. Есть много статей, затрагивающих разные участки его спектра: Что есть в C# чего нет в Java, что языки друг у друга позаимствовали, у одних LINQ, у других обратная совместимость, в общем, тысячи их.

Однако, я никогда не видел, чтобы писали о чём-то, что в Java, с точки зрения фич языка есть, чего в C# нет. Впрочем, я здесь не для того, чтобы спорить. Эта статья призвана выразить моё субъективное мнение и заполнить небольшой пробел по теме, озвученной в заголовке.

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

За основу статьи взяты советы из классики “Роберт К. Мартин: Чистый код”. Отобрал из них те, которые наиболее часто встречались в виде проблем у студентов. Приведенные советы написаны с учетом моего опыта разработки коммерческих Android приложений. Поэтому не ко всем Android-проектам приведенные ниже советы подойдут, я уже не говорю про другие системы.

Советы в основном приводил с примерами кода как НЕ НУЖНО делать. Как ни странно, у большинства студентов были одни и те же ошибки. Все примеры кода были придуманы, любые совпадения с реально существующим кодом случайны.

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

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

В данном топе книги не упорядочены по важности, они все очень хорошие, но есть одна книга, которая равнее других.