Umax SoftWorks

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

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

Хороша архитектура программы до тех пор, пока она безболезненно и легко расширяется, и к ней добавляются новые компоненты. Пока все выглядит органичным. Как только это условие перестает выполнятся, то система переходит в состояние «так себе», переходное такое состояние, в котором обычные проекты и находятся, во всяком случае на моем опыте так обычно и происходит :)

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

Так о чем это я, вернемся к нашим архитектурам приложений. Так как мне повезло, или нет, пока не ясно, не работать с кодом, написанным доблестными ребятами из Индии, то обычно код и архитектура были, и есть, вполне добротными, а вот некоторые свои проекты есть более чем ужасные. Но они такими и должны быть, я ведь на них учился реальным задачам. Чтобы не быть голословным, на сайте уже давно есть исходники Umax Doorway Generator, и об этом я кажется писал, много воды утекло с тех пор. А на новый год, в раннем 2012 году я выложу исходники Umax Doorway Generator 2, ведь денег он уже давно не приносит, да и смысла мне держать исходники у себя нет, учитывая то, насколько они «классные», ведь даже id Software исходники выкладывают.

Хочу сразу сказать о качестве исходных кодов Umax Doorway Generator 2. Качество там оооочень плохое, использование классов совершенно не оптимально, и вообще туда страшно смотреть. В общем от качества кода зависит и скорость работы софта, в данном конкретном случае.

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

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

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

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

Далее, хотелось бы, чтобы в проуессе разработки, становилось понятно о правильности принятия решений, и переделывалось то, что «не так», однако большинство вещей идут от заказчиков, и клиентов, которые непосредственно используют софт. Обычно, кроме сообщений о ошибках, поступают просьбы о переделке тех или иных окошек, или даже контролов, потому что они были не достаточно продуманы. Также поступают просьбы и пожелания появления тех или иных функций. Именно эти новые функции зачастую и являются поводом для выпуска новых версий.

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

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

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

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

Вроде свои мысли донес. Пойду дальше делами заниматься...

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

Хочу рассказать о своем опыте работы с разными системами контроля версий. Если кто незнает что это такое, то милости прошу в википедию, но скажу, что это очень полезная штука. Сразу скажу, такой себе, дисклеймер, что я высказываю свое мнение, и свой опыт, который может быть не объективным.

IBM Synergy

С первой системой контроля версий, с которой я когда-либо работал, стала IBM Synergy, или как она называлась Telelogic Synergy, пока компанию Telelogic не купила IBM.

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

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

Объект – любой файл или директория файловой системы. Директории могут включать в себя файлы. Файлы и директории видно на скриншоте выше.

Проект – совокупность файлов, директорий, и других проектов. Проекты видно на скриншоте выше. Такие красненькие конверты. Цвет иконки проектов устанавливается в зависимости от цели (Purpose) проекта, но об этом далее.

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

Задание (Task) – собственно задание, на скриншоте выше вы можете увидеть «Текущее задание: 845: Новое задание». Задание это такая основопологающая штуковина всей системы. Задание всегда имеет имя, номер, идентификатор базы данных, релиз задания, и может включать в себя список измененных объектов (файлов и директорий) для этого задания. В системе нельзя сделать Check-out файла, директории, удалить или добавить файл/директорию/проект, чтобы это не было отображено в задании. Без задания изменения к объектам можно производить только в одном случае, о котором ниже.

Папка – это не директория файловой системы. Папка это набор заданий. Папки бывают двух видов: Те, в которые таски нужно и можно вносить вручную, либо через API, и те, которые собирают таски из базы данных автоматически, использую SQL-подобный синтаксис. Кстати, практически все запросы на поиск данных выполняются в SQL-подобном синтаксисе, либо через элементы интерфейса, либо напрямую.

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

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

Предположим что у нас есть какая-то задача на нашем проекте. Например пофиксить баг. Вот что нужно сделать.

Зайти в Synergy – которая есть Java приложением. Чтобы зайти, надо знать свой логин, пароль, и база данных, с которой мы хотим работать, поскольку баз данных может быть несколько, и Synergy в зависимости от настроек умеет их синхронизировать, что очень круто.

Зашли в систему, воспользовались поиском, и если нашли проект, с которым нам нужно работать, то нужно сделать Check out проекта в нужную нам версию, и нужную цель. Для разработки цель обычно Insulated development, что значит – самостоятельная разработка, и никто другой не сможет взять версии файлов, которые checked out вами во время вашей работы. Если же нужного проекта нет, то нужно будет его создать вручную, а может быть даже нужно будет создать релиз, который также можно создать с нуля, или сделать Check out из другого релиза. После создания проекта ему нужно задать Work Area – место и путь на локальном или сетевом диске, где будут лежать файлы. Кстати, проекты без Work Area – вполне нормальное явление, когда проект старый, и с ним уже никто не работает.

Окошко настроек Work Area – ниже.

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

Далее мы делаем Check out файлам и директориям, если мы изменяем кол-во объектов внутри директорий. Check out, Check In, и другие действия над объектами делаются через контекстное меню, которое представлено ниже.

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

После того как таск завершен, то изменения сделанные в нем станут доступны друм людям, работающим над этим проктом.

Также у Synergy есть система контроля багов и улучшения, которая работает через Web интерфейс, и называется Change Synergy. Эта система контроля багов интегрирована с системой контроля версий, и таски можно привязывать к запросам на изменение.

Подводя итог, скажу, что это наверное самая сложная, настраиваемая и гибкая система контроля версий вообще. Из противоположной стороны. Для маленьких, и наверное средних компаний эта система скорее всего не подходит по двум причинам. Насколько я понял сервер системы выдает IBM, и его настраивать и конфигурировать желательно только специалистам из IBM. Вторая причина, это стоимость внедрения системы, подписка на поддержку и другие траты. На сайта IBM вы можете поискать IBM Rational Synergy, и посмотреть стоимость лицензии на одного юзера. Эта стоимость больше двух тысяч долларов.

SVN

Там, где я работаю сейчас используется SVN. У меня просто нет слов. Это ужас. Отголоски древних времен. Очень медленное, неудобное, нельзя быстро посмотреть какие файл были изменены. Нельзя параллелей делать, и еще много чего нельзя. Делать изменения в двух практически одинаковых проектах тоже напряжно. Надо постоянно мерджить файлы. В Synergy таск в папку закинул, и готово, а тут, много времени тратится на такие действия.

Скриншота системы не будет, хотя там и нечего показывать в общем.

Mercurial

Mercurial – интересная децентрализованная система версий, о которой я услышал в подкасте Радио-Т. Чем эта система понравилась лично мне для моиз проектов – это тем, что быстро разворачивается (не так как SVN), быстро работает на моих масштабах. Но все-же я использую лиш часть из возможностей, поскольку занимаюсь своими проектами сам.

Скриншотов Mercurial также не будет из соображений конфеденциальности моих данных. Mercurial бесплатен, быстро настраивается, смотрите сами :)

Что Mercurial, что SVN в общем довольно простые системы, по сравнению с Synergy. Что как помогает, иногда, так и раздражает, чуть более чем иногда. Например отсутствие версионности файлов, невозможности сделать параллельные версии файлов и т.д.

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

На этом и закончу сей длинный пост, который в Ворде растянулся на 4 листа.

Уже довольно долго, примерно месяц, меня муляет тема open source (свободного софта), и мое практически полное отсутствие в этой области. Но, к счастью у меня есть что открыть, и раздать за так.

Решил я отдать Umax Doorway Generator. Но был один момент, который меня останавливал, я являлся одним человеком, у которого были исходники, и у меня их небыло. Дело в том, что софтина довольно старая, и исходники были только на одной флешке, которая однажды перестала быть видимой вообще на любом PC.

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

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

Смотрите и пользуйтесь на здоровье, а я сделал что мог, написал, и пусть в голове будет на эту мысль меньше какое-то время :)

Тем временем, для текущих проектов я перешел на использование системы контроля версий. Страшно признавать, но до этого не использовал для своих дел систем контроля версий. Начал использовать Mercurial, спасибо подкасту Радио-Т, через который я и узнал о этой системе. В скором времени хочу написать пост о системах контроля версий, с которыми я работал, и о подкастах, которые я слушаю. На этом все.

Сегодня, в этот солнечный безветренный день расскажу о багах.

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

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

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

P.S. Баги – штука весьма забавная.

P.S.S. Обновил страничку документации к доргену – добавил ссылку на видео о шаблонах.

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

Язык нужно выбирать тот, который:

1. Который можно применить для той сферы, в которой вы работаете, в интернете, у нас это будет в основном PHP.
2. Язык, со знанием которого можно найти работу, при том, что нужно смотреть, ГДЕ находиться эта работа.
3. Тот, к которому у вас предпочтение, то есть, если вам что-то не нравиться, то я думаю, не стоит себя мучить.

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

Как обещал, напишу про контролы.

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

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

В ближайшем будущем вы сможете сами увидеть новый парсер, который просто офигенный :)

P.S. Я впервые делал свои контролы, поэтому не могу оценить их по достоинству пока.

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

А дорвейщики и программисты, которые пишут доргены и прочий СЕО софт, разбросаны по разным странам и городам, и не занимаются проблемой генерирования текста с такой дотошностью, чтобы сдвинутся хотя бы на 3 шага от цепей Маркова, которые всем приелись :).

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

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

Идеи о том, какой я вижу такую систему и как она будет работать, я обдумываю примерно с декабря. Нынешний дорген хорошо справляется с положенными на него задачами, и я работаю с клиентами по внедрению их идей в программу, потому как они обладают практическим опытом, чего нет у меня :( Но хочется такого чего нет еще, вроде ничего не проболтал :) если все будет отлично, то начну создавать такую штуку, при этом работа над UDG 2 будет продолжаться.

Мы все постоянно учимся разным вещам на протяжении своей жизни. Некоторые вещи мы учим только 1 раз, а другие постоянно учим и переучиваемся.

Особенно это касается тех кто пользуется новыми разработками промышленности, сфера ИТ в общем тоже промышленность ибо производит :)

Я недавно, где-то неделю назад, скачал 4 книжки по C# чтобы почитать, нового узнать. Потому что, уже 10 месяцев как работает этот сайт и я пишу на C#, а так до недавних пор ни одной книжки по этому языку и не прочитал :(

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

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

А также я смотрю один из многих видеоподкастов, майкрософта, о C# 4.0 и Microsoft .Net 4.0. Весьма интересные вещи там показываются, я даже некоторых фишек жду :)

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

Единственный нормальный способ уменьшить трату своего времени это автоматизация всего чего только можно. Автоматизация процессов в итоге приносит довольно много, с одной стороны уменьшается время, затрачиваемое на различные дела, описанные в первом абзаце, а с другой объем выполненной работы увеличивается по мере автоматизации процессов.

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

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

Но тогда я, оценивая свои возможности в программировании, понял, что пока я не смогу написать, то, что хочу. Поэтому я сделал UDG 2. Но все же время от времени думаю о будущем доргене.