Каждый, использующий в каких бы то ни было целях замечательный JavaScript, задавался вопросом: мол а почему typeof null — это "object"? typeof от функции возвращает "function", но от Array — "object"? а где же getClass у ваших хваленых классов? И хотя на большую часть легко и непринужденно отвечает спецификация или исторические факты, я бы хотел немного подвести черту… в большей степени для самого себя.

Если, читатель, тебе в твоих задачах тоже недостаточно typeof да instanceof и хочется какой-то конкретики, а не "object"ы, то дальше может быть полезно. Ах да, про утки: они будут тоже, только немного неправильные.

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

Я прочитал много книг по программированию, но, часто, после прочтения у меня оставался только один вопрос — Как мне применить эти знания на практике?

Предположим, вы разработчик системы автоматизации, портала или интернет-магазина.
Добавление новой функциональности осложняется наслоениями кода. Запуск тестов занимает полчаса, а релиз — час. Идея о переходе на новую версию фреймворка вызывает нервные подергивания. Вы узнаёте, что PostgreSQL имеет поддержку массивов, jsonb, полнотекстового поиска и lateral join, но ORM не позволяет использовать их в полную силу. Вы прочитали про TDD, но как писать в таком стиле, когда аналитик описывает сценарии, а фреймворк требует создания модели, контроллера и представления?

Как применить SOLID, если сущности наследуют от ORM?

Как избавиться от боли?

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

В какой-то степени книгу можно рассматривать как практический самоучитель по Clojure,
так что знание этого языка не требуется.

Объектно-ориентированное программирование принесло в разработку ПО новые подходы к проектированию приложений. В частности, ООП позволило программистам комбинировать сущности, объединённые некоей общей целью или функционалом, в отдельных классах, рассчитанных на решение самостоятельных задач и независимых от других частей приложения. Однако само по себе применение ООП не означает, что разработчик застрахован от возможности создания непонятного, запутанного кода, который тяжело поддерживать. Роберт Мартин, для того, чтобы помочь всем желающим разрабатывать качественные ООП-приложения, разработал пять принципов объектно-ориентированного программирования и проектирования, говоря о которых, с подачи Майкла Фэзерса, используют акроним SOLID.



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

Цель статьи

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

В данной статье будут рассмотрены следующие вопросы:

• Кастомная клавиатура под Android
• Многопоточность
• Интеграция рекламы в программу

Данная статья является конспектом книги "Чистый Код" Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.

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

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

Это первая из статей, где мы рассказываем об архитектуре приложения Reddit под iOS. Здесь речь идёт о функциональности, которая работает ближе к UI. В частности, о переходе к архитектуре Model-View-Presenter (MVP). Преимущества такого рефакторинга:

• Улучшение гибкости кода, его ясности и поддерживаемости для поддержки будущего роста и ускорения итераций.
• Повышение производительности прокрутки в 1,58 раза.
• Стимуляция модульного тестирования. Количество тестов увеличилось с нескольких штук до более 200.

Здравствуйте, коллеги.



Снимок Дженни Марвин с сайта Unsplash

Сегодня мы подготовили для вас перевод статьи о принципиальном сходстве многих языков программирования на примере с Ruby и C#. Надеемся, что идеи уважаемого Северина Переса помогут многим из вас поскорее приступить к изучению нового языка программирования, и дело пойдет с толком и удовольствием.

Откуда же начинаются опасности? Допустим вы твердо решили, что будете разрабатывать проект, придерживаясь определенной концепции или подхода. В нашей ситуации это DI, хотя на его месте также может оказаться, например, Реактивное Программирование. Вполне логично, что для реализации вашей цели, вы обратитесь к готовым решениям (в нашем примере — контейнер DI Zenject). Вы ознакомитесь с документацией и начнете строить каркас приложения, используя основной функционал. Если на первых порах использования решения у вас не возникнет неприятных ощущений, то скорее всего, оно задержится на вашем проекте на всю его жизнь. По мере работы с базовыми функциями решения (контейнера) у вас могут возникать вопросы или желания сделать некоторый функционал более красивым или эффективным способом. Наверняка, в первую очередь вы обратитесь за этим к более продвинутым «фичам» решения (контейнера). И на этом этапе может возникнуть следующая ситуация: вы уже неплохо знаете и доверяете выбранному решению, в силу чего многие могут не задуматься насколько идеологически правильным может быть использование того или иного функционала в решении, или переход к другому решению уже является достаточно дорогим и нецелесообразным (например приближается deadline). Вот на этом этапе и может возникнуть самая опасная ситуация — функционал решения применяется с малой осторожностью, или в редких случаях просто на автомате (бездумно).

Что бы далеко не ходить, сразу определимся с терминами.

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

Взято с вики. В языке программирования Ruby с инкапсуляцией вроде как всё хорошо. С сокрытием на первый взгляд тоже, нам доступны локальные переменные, переменные инстансов, разные уровни доступа к методам (public, protected, private). Но иногда этого может не хватать.

Закрадывалась ли вам в голову идея переписать своё жирное энтерпрайзное приложение с нуля? Если с нуля, то это ж ого-го. Как минимум кода будет раза в два меньше, верно? Но ведь пройдёт пара лет, и оно тоже обрастёт, станет легаси… времени и денег на переписывание не так много, чтобы делать идеально.

Успокойтесь, начальство всё равно не даст ничего переписать. Остаётся рефакторить. На что лучше всего потратить свои невеликие ресурсы? Как именно рефакторить, где проводить чистки?

Название этой статьи — в том числе отсылка к книге Дяди Боба «Чистая Архитектура», а сделана она на основе замечательного доклада Victor Rentea (твиттер, сайт) на JPoint (под катом он начнёт говорить от первого лица, но пока дочитайте вводную). Чтения умных книжек эта статья не заменит, но для такого короткого описания изложено весьма хорошо.

Идея в том, что популярные в народе вещи вроде «Clean Architecture» действительно являются полезными. Сюрприз. Если нужно решить вполне конкретную задачу, простой изящный код не требует сверхусилий и оверинжиниринга. Чистая архитектура говорит, что нужно защищать свою доменную модель от внешних эффектов, и подсказывает, как именно это можно сделать. Эволюционный подход к наращиванию объема микросервисов. Тесты, которые делают рефакторинг менее страшным. Вы ведь уже знаете всё это? Или знаете, но боитесь даже подумать об этом, ведь это же ужас что тогда делать придётся?

Кто хочет получить волшебную анти-прокрастинационную таблетку, которая поможет перестать трястись и начать рефакторить — добро пожаловать на видеозапись доклада или под кат.

… а также другие страшные слова! (с)

Прежде чем мы познакомимся с некоторыми продвинутыми возможностями объектной системы типов GLib, необходимо поговорить о ряде моментов, которые мы не затронули в предыдущих двух статьях. В этот раз мы познакомимся ближе с базовым типом GObject, поговорим о том, что любой наследник базового GObject представляет собой двуединство (а зачастую триединство) отдельных объектов-структур, во что раскрываются загадочные макросы в начале заголовочных файлов и файлов с исходным кодом, при помощи какого инструментария работает суровый местный RTTI, почему у GObject и его потомков два деструктора (и три конструктора), равно как и о ряде других интересных мелочей.

Когда я, так сказать, прошёлся по Интернету, я заметил одну интересную особенность. Все парадигмы программирования, где-либо обсуждаемые, воспринимаются людьми совершенно спокойно. Если, например, говорят про процедурное программирование, то говорят про него абсолютно спокойно. То же самое — про модульное программирование. Декларативное программирование — никаких бурь, волнений или холиваров. Функциональное программирование — то же самое.

И только вокруг ООП не утихают бури.

Добрый вечер, коллеги. Ровно месяц назад мы получили контракт на перевод книги "Modern Java" от издательства Manning, которая должна стать одной из наших самых заметных новинок в будущем году. Проблема «Modern» и «Legacy» в Java настолько остра, что необходимость такой книги довольно назрела. Масштабы бедствия и способы решения возникающих проблем в Java 9 кратко описаны в статье Уэйна Ситрина (Wayne Citrin), перевод которой мы и хотим вам сегодня предложить.

Привет, Хабр! Представляю вашему вниманию перевод статьи Романа Провазника — Why FP matters even for OOP developer?

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

В этой весьма запоздалой статье я объясню почему, по моему мнению, в большинстве случаев при разработке модели данных приложения необходимо придерживаться подхода "database first". Вместо "Java[любой другой язык] first" подхода, который выведет вас на длинную дорожку, полную боли и страданий, как только проект начнет расти.

"Слишком занят, чтобы стать лучше" Licensed CC by Alan O’Rourke / Audience Stack. Оригинальное изображение

Disclaimer: Всем можно, ну а я чем хуже?!

SOLID — это набор принципов по организации кода. Фактически они декларируют некие правила, которые помогут вам сохранить свои и чужие нервы и время. А могут и не помочь.

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

Статья 2006 года.

Бьёрн Страуструп, изобретатель языка программирования C++, защищает свое наследие и рассказывает, что не так с большей частью программного кода.

В 1980-х и 90-х годах Бьёрн Страуструп разработал и внедрил язык программирования C++, который популяризировал объектно-ориентированное программирование и повлиял на многие другие языки программирования, включая Java.

C++ остается архетипическим «высокоуровневым» компьютерным языком (то есть языком, который сохраняет особенности естественного, человеческого языка), и он по-прежнему используется миллионами программистов. Многие из систем и приложений эры ПК и интернета были написаны на C++. Несмотря на это, язык остается спорным, во многом потому что его, как известно, трудно изучать и использовать, а также потому, что дизайн Страуструпа позволяет разработчикам допускать серьезные ошибки программирования в интересах сохранения их свободы.

Страуструп, на протяжении многих лет работающий в AT&T Bell Labs, теперь является профессором компьютерных наук на факультете инженерии в Техасском университете A&M, недалеко от Хьюстона.

Технологический обзор: почему большая часть программного обеспечения настолько плоха?

Бьёрн Страуструп: Некоторые программы на самом деле довольно хороши по любым стандартам. Подумайте о Mars Rovers, Google и проекте “Геном человека”. Это качественное программное обеспечение! Пятнадцать лет назад большинство людей, и в частности большинство экспертов, сказали бы, что каждый из этих примеров невозможен. Наша технологическая цивилизация зависит от программного обеспечения, поэтому, если бы программное обеспечение было бы в действительности таким же плохим, как и его наихудшая репутация, большинство из нас уже были бы мертвы.

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

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

Чтобы понять принципы SOLID, нужно чётко понимать, как использовать интерфейсы. Если у вас такого понимания нет, то сначала почитайте документацию.

Я буду объяснять SOLID самым простым способом, так что новичкам легче будет разобраться. Будем рассматривать принципы один за другим.