Всем привет, меня зовут Сергей и я web разработчик. Да простит меня Дмитрий Карловский за заимствованное вступление, но именно его публикации вдохновили меня написание этой статьи.
Сегодня хотелось бы поговорить о работе с данными в Angular приложениях в целом и о моделях предметной области в частности.
… а также другие страшные слова! (с)
Прежде чем мы познакомимся с некоторыми продвинутыми возможностями объектной системы типов GLib, необходимо поговорить о ряде моментов, которые мы не затронули в предыдущих двух статьях. В этот раз мы познакомимся ближе с базовым типом GObject, поговорим о том, что любой наследник базового GObject представляет собой двуединство (а зачастую триединство) отдельных объектов-структур, во что раскрываются загадочные макросы в начале заголовочных файлов и файлов с исходным кодом, при помощи какого инструментария работает суровый местный RTTI, почему у GObject и его потомков два деструктора (и три конструктора), равно как и о ряде других интересных мелочей.
Когда я, так сказать, прошёлся по Интернету, я заметил одну интересную особенность. Все парадигмы программирования, где-либо обсуждаемые, воспринимаются людьми совершенно спокойно. Если, например, говорят про процедурное программирование, то говорят про него абсолютно спокойно. То же самое — про модульное программирование. Декларативное программирование — никаких бурь, волнений или холиваров. Функциональное программирование — то же самое.
И только вокруг ООП не утихают бури.Читать полностью »
Добрый вечер, коллеги. Ровно месяц назад мы получили контракт на перевод книги "Modern Java" от издательства Manning, которая должна стать одной из наших самых заметных новинок в будущем году. Проблема «Modern» и «Legacy» в Java настолько остра, что необходимость такой книги довольно назрела. Масштабы бедствия и способы решения возникающих проблем в Java 9 кратко описаны в статье Уэйна Ситрина (Wayne Citrin), перевод которой мы и хотим вам сегодня предложить.
Читать полностью »
В этой весьма запоздалой статье я объясню почему, по моему мнению, в большинстве случаев при разработке модели данных приложения необходимо придерживаться подхода "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 самым простым способом, так что новичкам легче будет разобраться. Будем рассматривать принципы один за другим.
Читать полностью »
Функциональное программирование пронизывает большую часть основного мира программирования — экосистема JavaScript, Linq для C#, даже функции высокого порядка в Java. Так выглядит Java в 2018-м:
getUserName(users, user -> user.getUserName());Функциональное программирование настолько полезно и удобно, что, насколько я вижу, проникло во все современные распространённые языки.
Но не всё так радужно. Многие разработчики сопротивляются этому тектоническому сдвигу в нашем подходе к ПО. Честно говоря, сегодня трудно найти работу, связанную с JavaScript, которая не требует знания концепций ФП.
Читать полностью »
Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.
Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.