Smalltalk обычно воспринимается как старый, умирающий язык – антиквариат из ушедшей эпохи. Нет ничего более далёкого от истины.

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

Эра фулстэк фрэймворков в прошлом. Современные разработчики фрэймворков разделяют свои монолитные репозитории на компоненты с помощью ответвлений в Git, позволяя разработчику выбрать то, что действительно необходимо его проекту. Это означает, что вы можете построить свое приложение на топовых Zend Service Manager, Aura Router, Doctrine ORM, Laravel (Illuminate) Eloquent, Plates, Monolog, Symfony Cache или любых других компонентах, которые можно установить через Composer.

В начале...

… не было ни композиции, ни наследования, только код.

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

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

Мрачные были времена.

Но вот лучик ООП воссиял над миром… Правда, несколько десятилетий¹ никто этого не замечал. Покуда не появился графический интерфейс², которому, как выяснилось, очень-очень не хватало ООП. Когда нажимаешь на кнопку в окне, что может быть проще, чем отправить кнопке (или ее представителю) сообщение "Нажатие"³ и получить результат?

И вот тут ООП взлетел. Было написано множество⁴ книг, расплодились бесчисленные⁵ статьи. Так что сегодня-то каждый может в объектно-ориентированное программирование, так?

25 марта университет интернет-профессий «Нетология» совместно с сообществом ruby-разработчиков Moscow.rb провел митап на тему альтернативных решений в мире Ruby. Выясняем, есть ли нетривиальный Ruby и что-то кроме «рельсы», а также за что любить этот язык программирования.

Или как можно проще об основных принципах ООП в Lazarus и FreePascal

Часть I

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

Во всех книгах, посвященных паскалю, delphi и lazarus (я нашел аж целых две о последнем), очень схожая часть, посвященная ООП. По этим книгам можно много узнать о том, насколько круче ООП устаревшего структурного подхода, но так и не получить достаточных навыков применения этого на практике. Конечно, любой программист, использующий визуальные IDE, уже по умолчанию использует ООП, так как все компоненты и структурные элементы визуального приложения представляют собой объекты, однако свои собственные структуры и абстракции перенести в парадигму ООП бывает очень сложно. Чтобы понять всю прелесть и оценить открывающиеся перспективы, я решил сделать небольшое приложение, которое в конечном итоге превратилось в простенький screensaver. Заодно вспомнил о существовании тригонометрии.

Приложение будет рисовать на экране в случайных местах пятьдесят полярных роз с разными характеристиками: размер, цвет, количество лепестков. Потом их же затирать и рисовать новые, и т.д. Используя принципы структурного программирования, можно, конечно, сделать обычный многомерный массив объемом на 50 и в нем сохранять все уникальные характеристики. Однако стоит вспомнить, что паскаль подразумевает строгую типизацию данных, а, следовательно, массив не может состоять их элементов с разными типами. Можно сделать массив из записей (record), но чего уж мелочиться, от записи до класса — один шаг. Вот его мы и сделаем.

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

И, разумеется, какими бы вам странными и некорректными ни казались вопросы на собеседовании, приходить нужно всё-таки подготовленным, зная тот язык, за программирование на котором вам собираются платить.



Третья часть серии статей посвящена одному из самых объемных понятий в современном PHP — итерации, итераторам и итерируемым сущностям. Я постарался свести в один текст некий минимум знаний об этом вопросе, пригодный для самоподготовки к собеседованию на позицию разработчика на PHP.

Две предыдущие части:

• Готовимся к собеседованию по PHP: ключевое слово «static»
• Готовимся к собеседованию по PHP: псевдотип «callable»

Сайдбары хороши в двух случаях: если на них расположено что-то настолько важное, что они должны всегда быть перед глазами (взять, к примеру, любой почтовый клиент, да хотя бы и Gmail) или если нужно иметь возможность это самое важное спрятать для экономии места (опять же, как в Gmail, но уже в мобильной версии). Браться за создание сайдбаров с нуля – задача не для средних умов, да и вообще бессмысленно. Для такой задачи лучше употребить соответствующий фреймворк. Об одном из таких примеров мы сегодня и поговорим.

Вступление

Недавно при работе над проектом учебной практики возникла потребность из своего кода порождать произвольный процесс и одновременно читать его stdout и stderr. Так как приложение пишется исключительно для linux, я решил заодно разобраться с epoll. Для запуска процесса на просторах интернета была найдена маленькая библиотека, делающая как раз то, что нужно, да еще и оборачивающая ввод-вывод в привычные потоки из стандартной библиотеки (речь о <iostream>).


Вооружившись несколькими статьями про epoll, я уже было собирался писать код, если бы не одно «но» — для epoll нужен доступ к «сырым» файловым дескрипторам, а автор библиотеки не предоставляет public-доступа к ним. Методы класса, возвращающие дескрипторы, скрыты под грифом «protected».

Что делать?

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

Поэтому в голову пришла безумная третья мысль: почему бы не попытаться как-то красиво «взломать» ООП и «легально» получить доступ к protected-методу без вмешательства в исходный код библиотеки? О том, какие преграды возникли на этом пути и как помог C++14 в их преодолении, и пойдет рассказ в данной публикации.

Привет, Хабр! Не так давно в издательстве «Manning» вышла непростая, но долгожданная и выстраданная автором книга о функциональном моделировании предметных областей.



Поскольку у нас готовятся книги как по Scala, так и по паттернам предметно-ориентированного проектирования, опубликуем одну из статей сахиба Гоша об идеях, заложенных в его книгу, и спросим, насколько эта книга была бы вам интересна

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

Как и в прошлый раз, статья будет полезна для ознакомления разработчикам младшего и среднего звена. В процессе изучения материала, Вы узнаете как можно обращаться к низкоуровневым DLL WinAPI в C# с помощью P/Invoke, как установить, настроить и удалить из системы мониторы печати, драйвера принтера, само устройство печати, открыть и связать порт для перенаправления входных данных с устройства печати на монитор, познакомитесь с ключевыми моментами применения маршалирования. Так же мы на практическом примере разберёмся, как с помощью нашего API можно удобно манипулировать устройствами печати в системе, узнаем как можно перехватить обработанные данные после печати с принтера и, например, отправить их на сервер.

После прочтения статьи Введение в проектирование сущностей, проблемы создания объектов на хабре, я решил написать развернутый комментарий о примерах использования Domain-driven design (DDD), но, как водится, комментарий оказался слишком большим и я посчитал правильным написать полноценную статью, тем более что вопросу DDD, на Хабре и не только, удаляется мало внимания.

Рекомендую прочитать статью о которой я буду здесь говорить.
Если вкратце, то автор предлагает использовать билдеры для контроля за консистентностью данных в сущности при использовании DDD подхода. Я же хочу предложить использование Data Transfer Object (DTO) для этих целей.

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

Хотелось бы поделиться мыслями об ООЯП и ООП в целом, а также что можно (и, как мне кажется, нужно) сделать на этой основе.

Основные идеи: В современных ООЯП отсутствует чётко выделенное и обязательное ядро моделирования для создания абстракций, основанных только на "чистых" концепциях ООП. Концепция ООП "всё есть объект" не практична. Концепция обмена сообщениями жёстко связана с её реализацией.

Вступление

Наверняка первый вопрос, который возник у вас при взгляде на заголовок, был "Шта?". На самом деле я просто перевел фразу "Инверсия управления, внедрение зависимости" в Google Translate на китайский, а затем обратно. Зачем? Затем, что на мой взгляд, это хорошая иллюстрация того, что происходит на самом деле. Люди вокруг путают, коверкают и извращают эти понятия. По долгу службы я провожу много интервью, и 90% того, что я слышу, когда задаю вопрос про DI — честно говоря, откровенный бред. Я сделал поиск по Хабру и нашел несколько статей, которые пытаются раскрыть эту тему, но не могу сказать, что они мне сильно понравились (ладно, ладно, я проглядел только три первых страницы, каюсь). Здесь же на Хабре я встречал в комментариях такую расшифровку IoC, как Injection of Container. Кто-то всерьез предполагает, что есть некий механизм инъекции контейнеров, который сосуществует где-то рядом с DI, и, видимо, даже делает нечто похожее. Только с контейнерами. Мда. На самом деле понять внедрение зависимости очень просто, надо всего лишь…

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

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

Дверь.Замок.Повернуть(
обычныйКлюч, 
обороты: 2, 
контекстЗдания: мойДом.мояКвартира.ПолучитьКонтекст());

Встречали подобное в реальной жизни? Я тоже нет.

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

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

Доброго времени суток обитатель habrahabr, сегодня я хочу тебе рассказать о новом релизе ffcms — 3.0.0 и кратко осветить кардинальные изменения, которые претерпела система с момента предыдущего релиза — 2.0.4.

Система сохранила бесплатную модель распространения и открытый исходный код (MIT), но исходный код был полностью переписан под MVC архитектуру и автозагрузку PSR-0. Многие «велосипеды» были убраны из системы, а их место заняли популярные компоненты: symfony http foundation, laravel eloquent и многие другие.

В одном из недавних проектов мы реализовывали взаимодействие Android-приложения с ejabberd-сервером через кастомизированный XMPP-протокол.

В этой статье приведены примеры как можно отправлять/получать кастомизированные пакеты XMPP-протокола в Android-приложении.

Для работы с XMPP протоколом была выбрана библиотека Smack 4.1.8.

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

private double fBm(Vector2D v, int y)
{
    double result = 0f;
    double freq = Frequency;

    for (int i = 0; i < Octaves; ++i)
    {
        result += NoiseFn(permutation, v * freq) * Amplitude;
        freq *= Lacunarity;
        Amplitude *= Gain; // <-- Вот тут.
    }

    return result;
}

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

Преамбула

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

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

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