1. Онтологическое наследование указывает на специализацию: вот эта штука — специфическая разновидность той штуки (футбольный мяч — это сфера и у неё такой-то радиус).
2. Наследование абстрактного типа данных указывает на замещение: у этой штуки такие же свойства, как у той штуки, и такое-то поведение (это принцип подстановки Барбары Лисков).
3. Наследование реализации связано с совместным использованием кода: эта штука принимает некоторые свойства той штуки и переопределяет или дополняет их таким-то образом. Наследование в моей статье «О наследовании» именно такого и только такого типа.

Привет!

Подумал я тут рассказать вам о том, как в JavaScript с помощью библиотеки Fluture можно создавать и использовать ленивые функции. Это будет краткий обзор на то, как создавать функции, как обрабатывать ошибки и чуть-чуть про параллелизм. Функциональным программированием мозги парить не буду! Обещаю!

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

В примерах используется JavaScript ES2015). (Почему JavaScript?)

Работа над материалом продолжается; присылайте свои пулл-реквесты в оригинальный репозиторий на английском языке.

В документе используются термины из спецификации Fantasy Land spec по мере необходимости.

Arity (арность)

Количество аргументов функции. От слов унарный, бинарный, тернарный (unary, binary, ternary) и так далее. Это необычное слово, потому что состоит из двух суффиксов: "-ary" и "-ity.". Сложение, к примеру, принимает два аргумента, поэтому это бинарная функция, или функция, у которой арность равна двум. Иногда используют термин "диадный" (dyadic), если предпочитают греческие корни вместо латинских. Функция, которая принимает произвольное количество аргументов называется, соответственно, вариативной (variadic). Но бинарная функция может принимать два и только два аргумента, без учета каррирования или частичного применения.

Пост содержит перевод статьи «Why Ramda?», которую подготовил один из контрибьютеров Скот Сайет. Статья была опубликована 10 Июня 2014 года на сайте и рассказывает о том почему стоит обратить своё внимание на библиотеку Ramda и функциональное программирование в целом.

Примечание переводчика

В связи с тем, что статья была написана в 2014 году, некоторые примеры устарели и не работали с последней версией библиотеки. Поэтому они были адаптированы под последнюю версию Ramda@0.25.0.

Почему Ramda?

Когда-то давно buzzdecafe представил миру Ramda, в тот же момент сообщество поделилось на два лагеря.

После не самого удачного опыта с Raspberry Pi 2 B в качестве домашнего сервера, я на пару лет бросил идею с домашним хостингом. Но количество PET проектов только увеличивалось. Тогда я раздобыл старенькую рабочую лошадку - полноразмерный HP сервер 1U с 8gb оперативной памяти, intel xeon. Разместил этот юнит в колокейшине и платил 35$/месяц за размещение. Помимо Ubuntu Server, там ещё стоял Windows Server для разработки и тестирования ASP.NET сервера. Пока один из проектов приносил прибыль, мне было выгодно размещать сервер в колокейшине. Через год, проект приносящий прибыль - заморозили, а привычка иметь собственный DEV сервер - осталась. Тогда я решил запустить этот сервер дома, даже не задумываясь о том, сколько шума он будет издавать. Чтобы вы понимали, я жил в панельном многоквартирном доме. И ко мне иногда приходили соседи с вопросом: «А чего у вас так долго пылесос работает?». Конечно же, мне это быстро надоело и я отключил сервер, положив на полку как сувенир. А без сервера было скучно…

Через некоторое время, один из моих проектов заинтересовал Швейцарскую компанию, которая занимается продажей золота. Если вкратце, это сервис, который выполняет работу ERP системы(учёт клиентов, контрактов, хранение документов, pdf сервис и всяческие отчёты). Этот проект необходимо было адаптировать под потенциально клиента, попутно переписать с устаревшей версии ASP.NET и всего стека Microsoft, на что-то быстрее и проще. В этот момент я выбрал GoLang, PostgreSQL, S3, Docker и парочку вспомогательных технологий, так как имел опыт работы с ними. Так вот, это эксперимент и клиент может в любой момент сказать, что ему это решение не подходит. Было решено, что хостить буду его - дома, дабы избежать лишних расходов и не тратить время на настройку облачных служб. Ну и хотелось попробовать решить проблему с предыдущей версией малинки.

TypeScript — это язык, расширяющий JavaScript, добавляя в последний типизацию. Правда, так как TypeScript не имеет runtime-а (почти), он транслируется в JavaScript, в процессе чего, вся типизация теряется. Такую типизацию можно назвать лишь инструментом статического анализа кода. Тем не менее — это очень мощный инструмент. К тому же, помимо проверки кода, типизация также и документирует его.

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

let users = ['Alice', 'Dan', 'Jessica'];
let query = 'A';
let user = users.filter(user => user.startsWith(query));

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

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

Я ни в коем случае не претендую на объективность, это моё личное мнение.

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

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

• DOM — это стейт. Поскольку у нас нет фреймворка, сразу забываем про функциональщину, и возвращаемся к императивному ООП. Веб-компоненты — это долгоживущие узлы DOM, инкапсулирующие свой стейт и имеющие публичное API. Они не пересоздаются, а изменяются. Значит DOM мы должны рассматривать не только как представление, но как хранилище бизнес-объектов, а значит и строить иерерхию компонентов нужно с учетом удобства их взаимодействия.
• Взаимодействие компонентов. Компоненты могут взаимодействовать посредством прямых вызовов, обмена колбэками, или посредством восходящих / нисходящих пользовательских событий DOM. Последний способ наиболее предпочтителен, так как снижает взаимную зацепленность (coupling), и упорядочивает граф связей (см. пример ниже).

ПривеТ! Решил поделиться с читателями своими небольшими экспериментами с системами частиц в трехмерном пространстве. За основу взял публикацию на Хабре об экспериментах с частицами в 2D пространстве.