Сегодняшняя статья будет про уведомления об изменениях в задачах Redmine. О том, какие средства есть в коробочном Redmine и о том, что мы доработали сами.
Любой task-трекер имеет средства уведомления об изменениях в задачах, и Redmine — не исключение.
Так сложилось, что моя карьера — сначала разработчика, затем архитектора, технического директора и наконец предпринимателя, развивалась преимущественно в околофинансовом секторе. Большую часть своего трудового пути я писал софт или работал в банках, брокерах и схожих с ними компаниях. Своим опытом столкновений с типичными проблемами этого сектора я и хотел бы поделиться с уважаемыми хабравчанами.
В общественном сознании образ банкира, трейдера или брокера, сформирован очень завидно. Человек — хозяин жизни в дорогом костюме, рассекающий на блестящей мощной машине, непоколебимо уверенный в себе и обладающий некими мистическими экономическими знаниями. Точно знающий, что и как нужно сделать, чтобы деньги, которых у него и так куры не клюют, превратились в еще больше денег.
Читать полностью »
Привет!
Вот так выглядит несложный интерфейс погружения и всплытия подлодки Б-413:
А вот это — монитор дизельного двигателя. Одного.
Богато. Непонятно — рубильника нет
Наши любимые стартапы — как та подлодка: в случае провала, о команде на весь мир скажут — “она утонула”. И хотя не доказано, что плохие интерфейсы напрямую отсекают путь к популярности для большинства продуктов (слагаемых успеха и провала всегда много), никто не станет спорить, что удобно — это правильно, а уязвимость UI — еще одна причина для самоторпедирования.
Проблема в том, что маленький проект часто не может привлечь специально обученного UX/UI-дизайнера, и проектируют интерфейсы в нём все подряд: разработчики, маркетологи, руководители… Поэтому соблюдение прав удобства пользователя так часто следует принципу “не стреляйте в питониста”.
К чему это ведет, и как это лечить — об этом и хотим поговорить.
Наш сайт в его первой версии, например, спроектировал наш CTO.
Читать полностью »
Здравствуйте.
К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных:
Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:
Далее с помощью механизмов ООП и реляционной модели «подсущности связываются между собой.
Причем термины „сущность“ и „подсущность“ применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины „метасущность“ и „сущность“ соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.
Используя Redmine в корпоративной среде, всегда сталкиваешься с тем, что в интерфейсе чего-то не хватает. То где-то ссылочку нужно подменить, то список задач не влазит на экран планшета, то картинки не открываются в новом окне.
Исправляя все эти мелкие неприятности, мы родили плагин Usability. Дальше я расскажу вам об этом плагине, которым готов поделиться с сообществом.
Плагин позволяет включать или отключать полезные опции. Расскажу о них и о предпосылках, в результате которых возникли опции, поподробнее.
Читать полностью »
Наша команда разрабатывает бекэнд-систему для обработки сообщений от мобильных устройств. Устройства собирают информацию о работе сложной техники и посылают сообщения в центр обработки. В этой статье я хочу поделиться подходами к построению подобных систем. Идеи достаточно общие, их можно применять для любой системы со следующей архитектурой:
По каналам связи устройства присылают сообщения на наш шлюз (gateway) – входную точку приложения. Задача приложения – разобраться, что именно пришло, произвести необходимые действия и сохранить информацию в базе данных для дальнейшего анализа. Базу мы будем рассматривать как конечную точку обработки. Звучит просто, но с ростом количества и разнообразия сообщений появляется несколько нюансов, которые я и хочу обсудить.
Читать полностью »
Время от времени вдруг начинает хотеться именованных параметров в C++. Не так давно была статья, да и сам какое-то время назад писал на эту тему. И вот что удивительно — со времен той своей статьи я участвую в новом проекте без необходимости тащить за собой старый код, и как-то удивительным образом всего этого описанного собой же не использую. Т.е. в вопросе разобрался, восхитился перспективами… и продолжил работать по-старинке! Как же так? Лень? Инерция? Ответ постараюсь дать под катом.
Читать полностью »
Статья, можно сказать, о наболевшем.
Из-за низкого порога вхождения, привычке к связке с MySQL, отсутствия необходимости сборки, отсутствия строгой типизации и других факторов, проекты, написанные на PHP, зачастую не блещут качеством и содержат много нагромождённых запросов в базу, вместо красивого чистого кода.
PHP — скриптовый язык, сервер отвечает на запрос и объекты умирают. Да, это не desktop-приложение.
Но это не значит, что объекты предметной области, с которыми мы должны работать, не нужны вовсе.
Наоборот! Они нужны, они должны помогать нам сохранять и восстанавливать их состояние, после их удаления из памяти.
На PHP можно и нужно писать качественный код, в прочем это вообще не зависит от языка!
В первую очередь статья будет полезна для новичков, но думаю не помешает и бывалым разработчикам. Возможно, и в вашем проекте всё не так, как хотелось бы?
Читать полностью »
В статье описана очередная попытка создать систему моделирования произвольной предметной области. Будучи единожды написана, такая система не требует привлечения команды разработки для прикладного программирования под конкретный бизнес произвольного заказчика. В основе продукта лежит EAV база данных, поэтому особое внимание уделено производительности при работе со значительными объемами данных.
Кто-то сразу вспомнит эпопею двадцатилетней давности: https://www.simple-talk.com/opinion/opinion-pieces/bad-carma/ (скандально известная универсальная система с единственной таблицей). Нет, мы пойдем немного другим путем.
В нашем случае всё прикладное «программирование» выполняет бизнес-аналитик (а лучше – продвинутый пользователь), просто описывая объекты с их свойствами и связями.
Читать полностью »
В данной статье я продолжаю рассказ про физические и функциональные события. На этот раз я свяжу физические события с теми объектами, которые моделируют их в информационных системах. В этой статье рассказ пойдет про физические и только физические события:
Для начала вспомним, что такое физическое и функциональное событие в предметной области.
Событие — это экстент плюс субъективная точка зрения на него.
В итоге мы имеем такую иерархию объектов:
