О программировании

/// @author Vital

Месяц: Июнь 2013

  • Let’s rock, everybody!

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

    Статья про рок-банды, новое время и программирование.

    rock-and-roll-xs

     

    Давно хотел провести аналогию между музыкой и программированием. Например команда разрабатывающая большие и сложные системы чем-то похожа на симфонический оркестр:
    blog_Classical_

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

    Если мы посмотрим на разработку программных продуктов по классической водопадной схеме, то состав участников также будет довольно обширным: архитектор, тим лид, ведущие программисты, несколько программистов разной специализации (java, c/с++, javascript и тд) и группа дизайнеров с верстальщиками. Естественно далеко не все компании могут себе позволить идеально укомплектованный состав. Наиболее успешные организации могут заинтересовать в профессиональном и материальном плане более сильных специалистов, остальные конторы довольствуются тем, кто соответствует их уровню.

    Тем не менее, на мой взгляд, существуют предпосылки для все большей популяризации нового формата коллективов. Во-первых это связано с большей доступностью компьютерной техники и развитием сервисов для разработчиков, во-вторых с ростом среднего уровня компьютерной грамотности, в-третьих формирование более позитивного отношения к техногикам у молодежи и общества в целом (сериал Теория Большого Взрыва, истории успеха и биографии Билла Гейтса, Марка Цукерберга, Стива Джобса и тд).

    Под новым форматом я имею в виду небольшой творческий коллективов состоящий из 3-5 человек. Это еще не “оркестр”, но уже и не соло-программист. Естественно масштаб создаваемых произведений не сопоставим с творением Классики. Другими словами, если проводить аналогии, речь идет о коллективах создающие программы “по духу” более близкие к Yesterday Битлз, чем к Хорошо темперированному клавиру И.С. Баха.
    Все идет к тому, что в программировании наступит время аналогичное музыкальной эпохи 60-70гг прошлого века.

    У кого-то может возникнуть такая ассоциация:
    blog_beatles
    у других такая: (далее…)

  • Про старый добрый RMI


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

    1. Между серверами гигабитная сеть в доверенной зоне, без доступа в интернет.
    2. Физически сервера расположены рядом (в одной стойке).
    3. Размер передаваемых в функцию данных около нескольких сотен килобайт, максимум нескольких мегабайт.
    4. Количество запросов небольшое, но возможны пиковые нагрузки.
    5. Операционная системы и оборудование позволяет установить последнюю стабильную версию Java, но по возможности следует избегать большого количества сторонних библиотек и фреймворков.
    6. Клиентская и серверная часть должны работать не столько в рамках сервера приложения/веб-сервера, а скорее как обычное приложение.

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

    Кончено RMI давно уже не в тренде, но в данном случае он очень органично подходил для решения этой задачи. Другое дело, что явно пользовался им очень давно, во времена предшествующие Java 5. С тех пор для ремоутинга чего-только не приходилось применять. В зависимости от контекста: .NET Remoting, Hessian/Burlap, GWT-RPC, SOAP, ну и конечно различные самодельные реализации.
    Сейчас большинство моих заказчиков хотят веб-службы. Бизнесу нужен SOAP и WSDL, по крайней мере сейчас.

    Еще раз повторюсь, я не смотрел на RMI много лет, с тех пор многое изменилось (для меня). В первую очередь радует то, что уже давно можно не запускать rmic и колдовать со скелетонами как нас до сих пор учит википедия.
    С другой стороны классы Remote и RemoteException остались, т.е. преемственность базовых классов естественно остается. И это хорошо!

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

    • Системное свойство java.rmi.server.logCalls = true/false полезно для отладки.
    • Если две сетевые карты, то может будет полезно посмотреть на свойство java.rmi.server.hostname.
    • Если вдруг понадобится, то можно прочитать руководство по работе RMI и SSL.
    • Подробный список свойств находится на страницах javarmiproperties и sunrmiproperties.

    Резюмируя — мне понравилось, вернулись воспоминания моей java-молодости, во времена когда клепал Applet-ы, раскладывал GridBag-ом и писал сервера на голых ServerSocket-ах. В целом, не смотря на то, что RMI уже очень много лет, оказалось, что на нем до сих пор можно быстро делать простые связки Java-to-Java фактически “из коробки”.