разработка
Найдено: 12 записей
Реклама →
Тема главного меню за полчаса
Среди посетителей Хабра много любителей игр, встречаются и те, кто любит эти игры делать. Наверняка, многим интересно, как делается игровая музыка и что для этого нужно. Сегодня я на живом примере простым и понятным языком расскажу, как написать короткую музыкальную тему для главного меню iOs игры “Stretched”, затратив минимум времени и сил, получив при этом качественный результат.
24.12.2011 03:22+0400
Язолъ →
Немного о тестировании приложений и обратной связи с пользователями
В последнее время всё чаще встречается коммерческий софт, где находятся глупейшие ошибки, мешающие работе с ним. К сожалению в некоторой степени это касается навигационного софта. Начну с примеров.
Первый раз попался существенный косяк в ПО Навител. При вводе координат на клавиатуре отображался символ ` (обратные кавычки) вместо ', что стоило мне времени при поиске нужных координат. В багтрекере Навитела об этой ошибке знали давно, негодующих пользователей было множество, но фикс прошел только в 5-й версии. В то время как версия 3.5 разрабатывалась год как минимум. Что стоило разработчикам заменить всего лишь один символ? Пятая версия не является исключением. Почти каждую неделю выходят новые версии Navitel, где фиксится всё что угодно лишь не те проблемы, на которые жалуются пользователи.
Первый раз попался существенный косяк в ПО Навител. При вводе координат на клавиатуре отображался символ ` (обратные кавычки) вместо ', что стоило мне времени при поиске нужных координат. В багтрекере Навитела об этой ошибке знали давно, негодующих пользователей было множество, но фикс прошел только в 5-й версии. В то время как версия 3.5 разрабатывалась год как минимум. Что стоило разработчикам заменить всего лишь один символ? Пятая версия не является исключением. Почти каждую неделю выходят новые версии Navitel, где фиксится всё что угодно лишь не те проблемы, на которые жалуются пользователи.
14.12.2011 23:43+0400
Песочница →
Идеология и проблемы разработки финансовых систем. Часть 2
В прошлый раз я попытался рассказать о некоторых мелочах, связанных с авторизацией и планировании прав доступа, о которых обычно забывают при планировании структуры финансовой системы.
В этот раз я хотел рассказать о проблеме, устранение которой на поздних этапах проектирования финансовой системы будет наиболее дорогостоящим и трудозатратным.
Рассмотрим пример.
Допустим имеется несколько таблиц в базе данных вашей системы. Одна из них — справочник юридических лиц. Вам как разработчику/аналитику необходимо спроектировать функционал для работы с некоторым типом документов. Для примера предположим что вам необходимо разработать функционал для создания и редактирования платежных поручений. Допустим 1 платежное поручение должно иметь следующие поля:
1. уникальный номер
2. дата и время создания
3. дата и время оплаты
4. юридическое лицо (контрагент) которому была произведена оплата
5. сумма
6. тип платежа
Сразу отмечу что почти никогда не стоит связывать уникальный номер документа с id записи в таблице БД. Дело тут вот в чем: пользователи имеют свойство ошибаться. Логика пользователей иногда весьма своеобразна, к примеру, периодически им легче удалить неправильно созданный документ и создать его по новой (особенно это касается новых сотрудников, которые боятся “накосячить”). После подобных действий у вас в системе будет множество пустых “дыр” между номерами документов. Казалось бы мелочь, но любая проверка со стороны “заинтересованных” лиц найдет в этом тайный умысел. (Если хотите реальных примеров, погуглите “Прайм-ТАСС подало в суд на мэрию Москвы”. Вся их доказательная база — номера документов шли по порядку, но в общественном доступе есть только часть из них). Лучше всего, по нашему мнению, вновь создаваемому документу присваивать номер = максимальный уникальный номер в системе по данному типу документов + 1.
Но вернемся к нашему примеру. Обратим внимание на поле №4 — юридическое лицо. Коль скоро у нас имеется справочник юридических лиц, то очевидным является записывать в это поле ссылку на запись в этом справочнике.
А теперь представим себе несколько возможных ситуаций:
1) Платежное поручение было создано в 2009 году. Платеж был произведен ООО “Кровать”. В январе 2010 фирма была переименована в ООО “Стулья”. Получается что если мы откроем форму платежного поручения в конце 2010 года, то увидим что платеж был произведен фирме, которой в 2009 году физически не существовало.
2) Допустим в марте 2010 года произошло слияние ООО “Кровать” и ЗАО “Диваны”, результатом стало ОАО “Диваны и кровати”. Что могут сделать пользователи? А они могут переименовать фирму ООО “Кровать” в ОАО “Диваны и кровати”, а еще они могут переименовать ЗАО “Диваны” в “Диваныи кровати”. Самое интересное начнется при первом же отчете, когда окажется что все платежи между разным юридическим лицами (3мя фактическими и 4мя в базе) перемешались и отличить их могут только люди, которые производили оплату (которые, к сожалению, попали под сокращение штата и уже несколько месяцев не работают в вашей фирме).
В этот раз я хотел рассказать о проблеме, устранение которой на поздних этапах проектирования финансовой системы будет наиболее дорогостоящим и трудозатратным.
Рассмотрим пример.
Допустим имеется несколько таблиц в базе данных вашей системы. Одна из них — справочник юридических лиц. Вам как разработчику/аналитику необходимо спроектировать функционал для работы с некоторым типом документов. Для примера предположим что вам необходимо разработать функционал для создания и редактирования платежных поручений. Допустим 1 платежное поручение должно иметь следующие поля:
1. уникальный номер
2. дата и время создания
3. дата и время оплаты
4. юридическое лицо (контрагент) которому была произведена оплата
5. сумма
6. тип платежа
Сразу отмечу что почти никогда не стоит связывать уникальный номер документа с id записи в таблице БД. Дело тут вот в чем: пользователи имеют свойство ошибаться. Логика пользователей иногда весьма своеобразна, к примеру, периодически им легче удалить неправильно созданный документ и создать его по новой (особенно это касается новых сотрудников, которые боятся “накосячить”). После подобных действий у вас в системе будет множество пустых “дыр” между номерами документов. Казалось бы мелочь, но любая проверка со стороны “заинтересованных” лиц найдет в этом тайный умысел. (Если хотите реальных примеров, погуглите “Прайм-ТАСС подало в суд на мэрию Москвы”. Вся их доказательная база — номера документов шли по порядку, но в общественном доступе есть только часть из них). Лучше всего, по нашему мнению, вновь создаваемому документу присваивать номер = максимальный уникальный номер в системе по данному типу документов + 1.
Но вернемся к нашему примеру. Обратим внимание на поле №4 — юридическое лицо. Коль скоро у нас имеется справочник юридических лиц, то очевидным является записывать в это поле ссылку на запись в этом справочнике.
А теперь представим себе несколько возможных ситуаций:
1) Платежное поручение было создано в 2009 году. Платеж был произведен ООО “Кровать”. В январе 2010 фирма была переименована в ООО “Стулья”. Получается что если мы откроем форму платежного поручения в конце 2010 года, то увидим что платеж был произведен фирме, которой в 2009 году физически не существовало.
2) Допустим в марте 2010 года произошло слияние ООО “Кровать” и ЗАО “Диваны”, результатом стало ОАО “Диваны и кровати”. Что могут сделать пользователи? А они могут переименовать фирму ООО “Кровать” в ОАО “Диваны и кровати”, а еще они могут переименовать ЗАО “Диваны” в “Диваныи кровати”. Самое интересное начнется при первом же отчете, когда окажется что все платежи между разным юридическим лицами (3мя фактическими и 4мя в базе) перемешались и отличить их могут только люди, которые производили оплату (которые, к сожалению, попали под сокращение штата и уже несколько месяцев не работают в вашей фирме).
06.12.2010 10:45+0300
humour →
Обзор принципиально новой ОС Bolgenos
Привет всем! Я крайне удивлён тем, что после того, какой фурор произвела Bolgenos, до сих пор не появилось ни единого обзора. Что ж, я буду рад исправить это дело.
(Осторожно: Трафик!)
(Осторожно: Трафик!)
01.06.2010 05:51+0400
humour →
А думать-то уже зачем?
Не могу не поделиться с хабрасообществом. Уж очень сильно меня смущает ненавязчивый слоган этой египетской компании:
Источник: www.egyptdc.com
Источник: www.egyptdc.com
18.01.2010 16:07+0300
humour →
А думать-то уже зачем?
Не могу не поделиться с хабрасообществом. Уж очень сильно меня смущает ненавязчивый слоган этой египетской компании:
Источник: www.egyptdc.com
Источник: www.egyptdc.com
18.01.2010 16:07+0300
humour →
Эволюция разработки
Забавно наблюдать за прогрессом в области девелопмента. И даже страшно подумать что будет дальше — вдруг человек и компьютер вполне поменяются ролями…
06.01.2009 16:07+0300
humour →
Цикл разработки программы
Коробки с программным обеспечением не появляются на полках по мановению волшебной палочки. Программа, диск с которой упаковывается вместе с невнятным руководством и двенадцатистраничным дисклеймером, проходит тернистый путь и самый жесткий контроль качества на планете, прежде чем попасть туда.
30.11.2008 15:12+0300
humour →
О чем вы думаете во время работы?
Решили немного пошалить и переделали старый добрый мультик на свой лад.
Ну как, совпадает? :)
Ну как, совпадает? :)
26.09.2008 13:07+0400
humour →
Обзор принципиально новой ОС Bolgenos
Привет всем! Я крайне удивлён тем, что после того, какой фурор произвела Bolgenos, до сих пор не появилось ни единого обзора. Что ж, я буду рад исправить это дело.
(Осторожно: Трафик!)
(Осторожно: Трафик!)
30.11.1999 00:00+0300
humour →
Эволюция разработки
Забавно наблюдать за прогрессом в области девелопмента. И даже страшно подумать что будет дальше — вдруг человек и компьютер вполне поменяются ролями…
30.11.1999 00:00+0300