Проектирование корпоративного веб приложения, как и любого другого приложения, стоит начать с определения первоначальный целей и области решаемых задач. Создать реестр заинтересованных лиц.
На следующем этапе необходимо собрать требования к приложению, которое необходимо разработать. Уточнить цели и область решаемых задач и построить иерархическую структуру работ.
Рассмотрим отдельно задачу построения иерархической структуры работ. Каждое web-приложение можно представить в следующем виде:
Я занимаюсь в Яндексе продуктовой безопасностью и, кажется, сейчас самое время подробнее, чем уже было на YaC, рассказать на Хабре о том, как мы внедряем TLS в Яндексе.
Использование HTTPS-соединений является важной частью безопасного веб-сервиса, так как именно HTTPS обеспечивает конфиденциальность и целостность данных на этапе передачи их между клиентом и сервисом. Мы постепенно переводим все наши сервисы только на HTTPS-соединение. Многие из них уже работают исключительно по нему: Паспорт, Почта, Директ, Метрика, Такси, Яндекс.Деньги, а также все формы обратной связи, имеющие дело с персональными данными пользователей. Яндекс.Почта уже больше года даже обменивается данными с другими почтовыми сервисами по SSL/TLS, поддерживающими это.
Все мы знаем, что HTTPS — это HTTP, завернутый в TLS. Почему TLS, а не SSL? Потому что принципиально TLS — это более новый SSL, при этом название нового протокола наиболее точно характеризует его назначение. А в свете уязвимости POODLE можно официально считать, что SSL больше использовать нельзя.
Читать полностью »
Сегодняшняя статья будет про уведомления об изменениях в задачах Redmine. О том, какие средства есть в коробочном Redmine и о том, что мы доработали сами.
Любой task-трекер имеет средства уведомления об изменениях в задачах, и Redmine — не исключение.
Так сложилось, что моя карьера — сначала разработчика, затем архитектора, технического директора и наконец предпринимателя, развивалась преимущественно в околофинансовом секторе. Большую часть своего трудового пути я писал софт или работал в банках, брокерах и схожих с ними компаниях. Своим опытом столкновений с типичными проблемами этого сектора я и хотел бы поделиться с уважаемыми хабравчанами.
В общественном сознании образ банкира, трейдера или брокера, сформирован очень завидно. Человек — хозяин жизни в дорогом костюме, рассекающий на блестящей мощной машине, непоколебимо уверенный в себе и обладающий некими мистическими экономическими знаниями. Точно знающий, что и как нужно сделать, чтобы деньги, которых у него и так куры не клюют, превратились в еще больше денег.
Читать полностью »
Привет!
Вот так выглядит несложный интерфейс погружения и всплытия подлодки Б-413:
А вот это — монитор дизельного двигателя. Одного.
Богато. Непонятно — рубильника нет
Наши любимые стартапы — как та подлодка: в случае провала, о команде на весь мир скажут — “она утонула”. И хотя не доказано, что плохие интерфейсы напрямую отсекают путь к популярности для большинства продуктов (слагаемых успеха и провала всегда много), никто не станет спорить, что удобно — это правильно, а уязвимость UI — еще одна причина для самоторпедирования.
Проблема в том, что маленький проект часто не может привлечь специально обученного UX/UI-дизайнера, и проектируют интерфейсы в нём все подряд: разработчики, маркетологи, руководители… Поэтому соблюдение прав удобства пользователя так часто следует принципу “не стреляйте в питониста”.
К чему это ведет, и как это лечить — об этом и хотим поговорить.
Наш сайт в его первой версии, например, спроектировал наш CTO.
Читать полностью »
Здравствуйте.
К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных:
Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:
Далее с помощью механизмов ООП и реляционной модели «подсущности связываются между собой.
Причем термины „сущность“ и „подсущность“ применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины „метасущность“ и „сущность“ соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.
Используя Redmine в корпоративной среде, всегда сталкиваешься с тем, что в интерфейсе чего-то не хватает. То где-то ссылочку нужно подменить, то список задач не влазит на экран планшета, то картинки не открываются в новом окне.
Исправляя все эти мелкие неприятности, мы родили плагин Usability. Дальше я расскажу вам об этом плагине, которым готов поделиться с сообществом.
Плагин позволяет включать или отключать полезные опции. Расскажу о них и о предпосылках, в результате которых возникли опции, поподробнее.
Читать полностью »
Наша команда разрабатывает бекэнд-систему для обработки сообщений от мобильных устройств. Устройства собирают информацию о работе сложной техники и посылают сообщения в центр обработки. В этой статье я хочу поделиться подходами к построению подобных систем. Идеи достаточно общие, их можно применять для любой системы со следующей архитектурой:
По каналам связи устройства присылают сообщения на наш шлюз (gateway) – входную точку приложения. Задача приложения – разобраться, что именно пришло, произвести необходимые действия и сохранить информацию в базе данных для дальнейшего анализа. Базу мы будем рассматривать как конечную точку обработки. Звучит просто, но с ростом количества и разнообразия сообщений появляется несколько нюансов, которые я и хочу обсудить.
Читать полностью »
Время от времени вдруг начинает хотеться именованных параметров в C++. Не так давно была статья, да и сам какое-то время назад писал на эту тему. И вот что удивительно — со времен той своей статьи я участвую в новом проекте без необходимости тащить за собой старый код, и как-то удивительным образом всего этого описанного собой же не использую. Т.е. в вопросе разобрался, восхитился перспективами… и продолжил работать по-старинке! Как же так? Лень? Инерция? Ответ постараюсь дать под катом.
Читать полностью »
Статья, можно сказать, о наболевшем.
Из-за низкого порога вхождения, привычке к связке с MySQL, отсутствия необходимости сборки, отсутствия строгой типизации и других факторов, проекты, написанные на PHP, зачастую не блещут качеством и содержат много нагромождённых запросов в базу, вместо красивого чистого кода.
PHP — скриптовый язык, сервер отвечает на запрос и объекты умирают. Да, это не desktop-приложение.
Но это не значит, что объекты предметной области, с которыми мы должны работать, не нужны вовсе.
Наоборот! Они нужны, они должны помогать нам сохранять и восстанавливать их состояние, после их удаления из памяти.
На PHP можно и нужно писать качественный код, в прочем это вообще не зависит от языка!
В первую очередь статья будет полезна для новичков, но думаю не помешает и бывалым разработчикам. Возможно, и в вашем проекте всё не так, как хотелось бы?
Читать полностью »
