Предисловие

На написание статьи меня сподвигло практически полное отсутствие материалов на русском языке про алгоритмы генерации лабиринтов. На Хабре, из того, что вообще есть по теме, можно отметить две статьи: раз и два. Ценность и пользу из которых несет лишь вторая. В первой – просто перевод формального алгоритма и небольшое его пояснение. Что, конечно, неплохо, но очень скудно и не вызывает желания изучать тему дальше.

Если моя статья Вам понравится, я продолжу писать о различных алгоритмах. Мы рассмотрим два самых примитивных и простых случая – генерация двоичного дерева и Сайдвиндер, который, по своей сути, просто чуть измененная версия двоичного дерева с одним заметным плюсом. ОСТОРОЖНО ТРАФИК.

Абстракция – это одна из основных техник в ИТ. Любой язык программирования или моделирования, любая парадигма программирования (процедурная, функциональная, ООП, …) дают ответ на вопрос, как и от чего нужно абстрагироваться. Причём, адепты каждого подхода предлагают какой-то свой вариант абстракции.

Если вы хотите увидеть истинную, универсальную абстракцию, то вступайте в нашу… изучайте теорию категорий. В статье на примере категории множеств с картинками и JavaScript-кодом объясняются самые базовые понятия теории категорий: пределы, универсальное свойство. Рассматривается вычислительный аспект теории категорий.

Также немного говорится про классы, примеси и смеси в JavaScript.

Примеры из статьи можно посмотреть тут.

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

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

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

Для начала посмотрим на экран и разберёмся, что на нём происходит и что нам
предстоит реализовать.

Доброго времени суток, дорогой Хабраюзверь. Буду краток. Немного метрик: за последние три года я увеличил свой доход в 10 раз и не превратился в дикого трудоголика, а скорее наоборот, стал больше путешествовать; при этом количество проектов, которые я успешно начал и довёл до конца, выросло втрое — я не говорю о чисто рабочих проектах, возможно Вам знакомы мои курсы по Java, которые я успешно продолжаю развивать в нерабочее время. Ключ ко всему этому состоит из трех частей:

• эффективное управление качеством времени;
• эффективный менеджмент ресурсов и проектов;
• эффективное и постоянное самообучение.

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

Давайте сразу расставим точки над «i». Это не статья о Гарвардском курсе по основам программирования CS50 как таковом. И даже не ремейк известной сказки «Золушка» на лад «пройди CS50 и стань супер-айтишником высшей категории». Здесь мы хотим рассказать о человеке с необычной историей, которой мы заинтересовались именно благодаря CS50. А точнее лишь о некоторых фактах из жизни Сьюзен Войжитски, которые показались нам интересными и в какой-то мере поучительными для тех, кто в ИТ и не только.

1. Введение в реактивное программирование

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

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

RxJava — реализация ReactiveX с открытым исходным кодом на Java. Базовыми строительными блоками реактивного кода являются Observables и Subscribers. Подробнее с базовой основой можно ознакомиться в статье Грокаем* RxJava, часть первая: основы.

RxAndroid — расширение к RxJava, которое позволяет планировщику запускать код в основном и дополнительных потоках Android приложения и обеспечивает передачу результатов из созданных дополнительных потоках в основное для агрегации и взаимодействия с интерфейсом пользователя.
С целью более полного понимания основных принципов реактивного программирования рассмотрим практический пример для платформы Android. И начнем с настройки окружения для разработки.

Часть 1 — линейная регрессия

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

Градиентный спуск

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

Прочитал весьма занимательную статью про важность алгоритмов, вывод из которой показался мне весьма спорным

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



Все дело в том, что разработка ПО — это не просто алгоритмы или языки.

"Мне надо найти девушку. Сколько времени в неделю нужно женщине? Часов 10?"

(Элон Маск)

На одном известном форуме программистов уже больше года идёт обсуждение под заголовком “Где вы находите девушек?”. Когда один тред форума начинает притормаживать от числа комментариев в ветке, участники делают новую.

То же самое мы видим в кино: Нео из «Матрицы» не хотел идти в ночной клуб, но последовав за белым кроликом, тупо стоял у стенки до самой Троицы. Леонард из «Теории большого взрыва» не понимает, почему Пенни встречается с накачанными громилами, не отягощёнными высоким IQ, а Кутрапали, оказываясь лицом к лицу с представительницей противоположного пола, вообще теряет дар речи. Аллан Тьюринг не понимал смысл флирта (хоть и «играл за другую команду»).

Получается, проблема имеет 2 стороны:

1. Ребята-интроверты, для которых это критично, не могут осознать, почему конкретно не получается,
2. А те парни, кто таких сложностей не испытывает, не могут чётко формализовать свой опыт и просто комментируют словами Барни Стинсона (из известного сериала “Как я встретил вашу маму”): «Когда мне грустно, я перестаю быть грустным и становлюсь клевым». В общем, передачи полезного знания не происходит.

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

Для решения этой проблемы мы и создали проект Girl++.

Архитектура – это про будущее…
— именно на этой мысли мы остановились в конце 1й части статьи. Продолжаем.

Что такое хорошая архитектура?

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

Задачи бывают разные. Стандартные и специфичные. Локальные и масштабные.
Но в любом случае, как вряд ли кто-то захочет дом “на один сезон” (хотя такое тоже возможно, но это как раз из разряда “специфичного”, и едва ли для подобного строительства будут прибегать к услугам архитектора) — так и сомнительно, чтобы кто-то хотел получить в итоге систему без перспективы ее развития в будущем.

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

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

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

«Хмм… правдивого архитектора… А что, такие бывают? – спросите вы и подумаете. — Врет, поди! Сейчас будет нам рассказывать очередную концепцию „бла-бла-бла.2.0“. Знаем, плавали, видали мы „витающих в небесах архитекторов“ и их умозрительные конструкции».
И будете правы: нормальный «пацанский» архитектор — человек очень занятой, и времени писать статьи у него, как правило, нет… Но! Бывает, что настает момент – и желание человека поделиться опытом, рассказать о своих удачах и сложностях миру настолько высоко, что и время находится, и присущий нашему брату-технарю страх публичных высказываний отступает. К тому же коллеги по цеху давно призывали меня начать подобную деятельность.

Стартовать я решила с темы несколько общего характера – ИТ-архитектуры в целом. Почему бы сразу не перейти непосредственно к деталям, которые наиболее занимают читателей технических блогов?
Ответ прост: уж больно много вопросов, трактовок и кривотолков возникают вокруг работы и задач архитекторов. И чтобы двигаться дальше, нужно выстроить некую «общую систему координат» — некую отправную точку.
За время моей работы сложилось некое «видение» происходящего, которым хотелось бы поделиться и обсудить с коллегами.

Итак, попробуем поискать ответы на следующие вопросы.

• Что такое архитектура?
• Что такое целевая архитектура?
• Что такое архитектурные стандарты и фреймворки и зачем они нужны?
• Кто заказывает архитектуру, какие у нашего заказчика могут быть желания и потребности, высказанные и невысказанные?
• Какую архитектуру можно назвать хорошей архитектурой?
• Зачем нужны архитекторы? Какова их роль? Чего от них ожидать и почему?
• Когда компании нужно вкладываться в архитектуру? Что будет, если этого не делать?

Если вы когда-либо задавались подобными вопросами, и они представляют для вас интерес, то эта статья для вас — приглашаю поразмыслить вместе.

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

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

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

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

Пару месяцев назад я взяла на себя обязательство по самопросвещению. Есть в иных конторах такая тема — сотрудника, раз в полгода ревьюят и говорят «давай к следующему ревью ты изучишь Spring, паттерны (какие?) и функциональное программирование!» Идея была бы неплоха если бы цели не ставили так размыто. Пропустим пока спринг и паттерны — на выходных я бросилась в атаку на ФП.

Общие-туманные сведения о ФП у меня конечно были — анонимные классы в Java я писать умею — с похожими способностями Python и JavaScript знакома.

Начну с простых упражнений на Scala — решила я. Выбрала Scala поскольку основной рабочий инструмент у нас Java — ну были еще варианты Clojure, Groovy и Java8 (что-то еще?) — но с ними авось попробую потом.

Поставила себе цели (а правильно ли я ФП поняла?):

• Решать задачи в функциональном стиле
• Т.е. по возможности не использовать явных циклов и ветвлений
• А также избегать мутабельных коллекций и т.п.

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

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

Привет, Хабр! Этой статьёй я открываю цикл материалов, посвящённых работе с большими данными. Зачем? Хочется сохранить накопленный опыт, свой и команды, так скажем, в энциклопедическом формате – наверняка кому-то он будет полезен.

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

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

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

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

«Эх, еще бы вокруг шарика махнуть…»

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

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

• Где найти эту самую удаленную работу?
• Что необходимо знать и уметь?
• Сколько получают сотрудники на удаленной работе?

Мы тоже решили заняться поисками ответов на эти вопросы. В итоге наша любознательность переросла в весьма познавательное исследование. Интересно? Тогда добро пожаловать под кат!

To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.

«Лучший способ писать — это переписывать» Пол Грэм, «The Age of the Essay»

Преред курсом Сергея Абдульманова ( milfgard) я взял для себя квест — структурировать все статьи Грэма. Пол не только крутой программист и инвестор — он мастер лаконичного письма. Если milfgard назвал свой курс для контент-менеджеров "Буквы, которые стреляют в голову", то Пол Грэм стреляет из «по глазам» (кто играл в Fallout 2 тот поймет).

А еще мне захотелось освоить Lisp. Чисто так, чтобы мозг поразвивать, потому что крутые люди — Грэм, Кей и Рэймонд, Моррис — говорят хором: «Учите Lisp».

На данный момент Пол Грэм написал (по крайней мере, я нашел) 167 эссе. Из них на русский переведены 69.74(+10). Если читать по 1 статье в день (что очень хороший результат, потому что я после одной статьи хожу задумчивый неделю — голова кипит как после отличного мастер-класса, а иногда и как после двухдневного интенсива), то процесс займет полгода.

Под катом — список всех статей со ссылками на оригинал и с переводом (если он есть). Подборка живая (так что, как обычно, добавляйте в избранное, потом прочитаете) и будет дополняться по мере обнаружения свежака. Еще вы найдете переведенную на 8/15 книгу «Хакеры и художники» и 4/25 перевода книги «On Lisp». Так же я приведу свою подборку топ-5 статей Пола Грэма, с которых я бы рекомендовал начать знакомство с этим автором.

— ООП не сможет больше спасать нас от «Облачных монстров».

Примечание переводчика: Есть два понятия — параллельность (выполнение одновременно, независимо) и конкурентность (выполнение по шагам, поочерёдно, но одновременно несколько задач) и как всегда, мне пришлось поломать голову подобрая правильные термины.

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

Возможно вы уже слышали такое выражение, вроде: “Clojure”, “Scala”, “Erlang” или даже “Java теперь имеет лямбды”. И вы имеете хоть и отдалённое представление о «Функциональном программировании». Если вы участник какого-либа программисткого сообщества, тогда эта тема могла уже вами обсуждаться.

Если вы поищите в Google по словосочетанию «Функциональное программирование», вы не увидите что-то нового. Второй язык из созданных ранее уже охватывает эту тему, он был создан в 50-ых и называется Lisp. Тогда, какого чёрта, эта тема стала популярна только сейчас? Всего то 60 лет спустя?

В начале, компьютеры были очень медленными

Верите вы этому или нет, но компьютеры были нааамного медленнее чем DOM. Нет, действительно. И в то-же время были 2 основные идеи в соглашении по дизайну и реализации языков программирования:

• Начинайте исходя из архитектуры фон Неймана и добавьте абстракцию.
• Начните с математики и удалите абстракцию.