Рубрика «Delphi» - 17

image

6 декабря 2013 года в России проходила черная пятница. Было заявлено о больших скидках.
Я узнал об этом в одной статье еще за месяц до начала. Прочитав много комментариев к той статье, я понял, что все пользователи сходятся во мнении, что:

  1. Никаких грандиозных скидок не будет.
  2. Если скидки всё-таки будут, то только на те товары, которые не очень то и нужны.
  3. Сама скидка сводится к тому, что в этот день цена товара завышается, а за счет скидки понижается до первоначального уровня, но никак не меньше.

Было решено узнать, а как всё происходит на самом деле.
В той статье упоминались несколько компаний, участвующих в акции. Я выбрал 2 компании для анализа: Сотмаркет и Белый Ветер.
Читать полностью »

Я знаю людей из корпоративных разработчиков, которым outsourcing буквально «жизнь поломал». Энергичный хлопок дверью.
– Всем нужен программист, – сказал я, возвращаясь к ботинкам.

Embarcdero (Borland) не использует модель outsourcing-а в «чистом виде», однако схема привлечения внешних ресурсов вполне может считаться полезной для рассмотрения, особенно в свете backsourcing-а. Почему Embarcadero не всё делает сама? Почему базовый продукт нуждается в дополнении со стороны технологических партнёров? Как что-то отдать на сторону, а потом забрать? Нужно ли думать об backsourcing-е как неизбежном завершении outsourcing-а? Можно ли вообще обойтись без этого?

Outsourcing самим звуком вызывает негативную реакцию со стороны «собственных разработчиков», на что есть масса причин. Теперь к этому добавится ещё одно однокоренное слово – backsourcing. Чтобы это не стало «второй возможностью хлопнуть дверью», разберёмся в деталях. Хорошая команда, выполняющая работу на заказ похожа на спецназ. Каждый боец обладает несколькими компетенциями. Но куда ж без «танка»? Мягкие и изнеженные корпоративные разработчики не могут ничего противопоставить закалённому в баттлах сейлу. Такой «очаровашка» очень быстро вотрёт вашему CIO, что именно его команда сделает все гораздо лучше.

Читать полностью »

Test Driven Development (TDD) – неоспоримо выдающаяся техника, дающая ряд преимуществ. Прикладные разработчики, причём вне зависимости от масштаба проекта и количества вовлеченных специалистов, в широкой массе не следуют TDD. Но есть и ярые сторонники такого подхода, причём они готовы апеллировать не только к здравому смыслу или производственной необходимости, но и на безоговорочно успешные примеры его внедрения. Одним из таких апологетов является Александр Люлин, который не только рассказывает о степени позитивного влияния TDD на разработку, но и делится экспертизой внедрения и неукоснительного каждодневного применения этой техники вплоть до исходных кодов и примеров сценариев (в своем блоге). Однако главный тормоз на пути следования принципам TDD стоит, что предсказуемо, набор чисто психологических установок. В режиме «жёсткого разговора» мы пообщаемся с Александром на тему необходимости Test Driven Development.

Test Driven Development – попытка следования моде? Слепое копирование чужих подходов?

Давайте «сразу определимся». Я не использую TDD в его классическом понимании. И не надо здесь цитировать «википедию»! Вообще, вряд ли кто-то из профессионалов рассматривает энциклопедические статьи в качестве руководства к действию. Мы свой подход «выстрадали» в рамках реализации успешного проекта, поэтому за нами реальный опыт, а не «тупое использование чужих идей». Скорее, мы используем синтез из TDD и собственных представлений о том, как нужно разрабатывать ПО. Даже если эти «внешние идеи» исходят от очень умных идей, их следует критически осмыслить и адаптировать к реальной компании, существующей команды и стратегии развития и обеспечения качества. Но я далее буду говорить «TDD», имея ввиду тот процесс “разработки через тестирования», который близко соотносится с энциклопедическим Test Driven Development, но идёт гораздо дальше него.

TDD — это попытка поставить всё с ног на голову. В классике инженерного дела сначала создаётся установка/техническая система/машина/агрегат. Конечно, методика испытаний имеется в виду при проектировании… но всё-так, программисты – это какой-то особый вид инженеров? Генетически ущербных? Сами себя таким не считаете?

Читать полностью »

Возвращение к истокам

Delphi XE5 я взял в руки по случаю конкурса «Осенняя Мобилизация». Идея (и возможность) писать под Андроид не на си-шарпе или яве, а на знакомом вдоль и поперёк паскале мне определённо понравилась. Расскажу тут о своих впечатления, проблемах, которые встретились, а также развенчаю некоторые «городские легенды».
Читать полностью »

Одним из самых любимых хабов на хабре всегда был для меня DIY, я и сам не прочь что-то сделать своими руками. Но так, как я в большей степени программист, а в меньшей — электронщик, сделанные мной «прототипы» всегда непрезентабельны. Данный девайс не исключение. Код тоже не причесан, т.к. это больше proof-of-concept чем коммерческое решение. Тем не менее, думаю данных пост будет полезен, и даже найдутся те, кто повторит эту поделку.
Вдохновившись постом о стрелочных Vu-метрах, показывающих загрузку CPU и использование RAM, решил сделать свой вариант. Не имея миниатюрных вольтметров, но имея покоривший своей ценой и простотой протокола 16х2 экран на базе контроллера hd44780 решил организовать визуализацию на нем. Как МК был выбран ланчпад MSP430G2, коих я купил жменьку, когда они были по $4.30. Ничего не мешает реализовать это все на любой arduino, нужно лишь поменять названия пинов.
Схема очень проста(взята из интернета):
image
Читать полностью »

Компания Embarcadero всегда с радостью упоминает продукт Altimum Designer, когда речь заходит об успешных коммерческих приложениях, созданных в Delphi. Не может не поражать масштаб проекта – он насчитывает около 4 000 000 (четырёх миллионов) строк исходного кода. Altimum Designer представляет собой CAD-систему для проектирования печатных плат электронных систем, включая 3D моделирование. Сегодня мы поговорим о технической составляющей системы именно с позиции инженерии ПО.

Читать полностью »

Часто приходится слышать – «Delphi – среда для разработки «кривых» интерфейсов». Либо Delphi-разработчики какие-то генетически ущербные в плане создания интерфейсов. Либо сама среда провоцирует на плохой дизайн GUI. Есть повод сконцентрировать на данной проблематике своё внимание.

В начале «эпохи прикладного бума» за счёт использования средств визуальной разработки доминировала Delphi. Конечно, были и другие средства разработки приложений с оконным интерфейсом (Visual Basic, Visual Studio и т.д.), но, вспоминая ситуацию в России периода Delphi 1…3, можно достаточно обоснованно говорить широчайшем распространении этой среды. Продукт «выстрелил», прежде всего, из-за гигантского дефицита программного обеспечения. Но и языковая простота Delphi сыграла ключевую роль – очень много было инженеров, но мало программистов. Зато в Delphi люди после институтского курса за месяц могли если не стать программистами, то хотя бы разработчиками. В смысле, могли самостоятельно создавать программные продукты.

Читать полностью »

Валентина, Вы показывали Ваше первое приложение в Delphi for Android. Оно решает какую-то конкретную задачу или это просто – инициативная разработка, «проба пера»? Стоят ли за этим реальные бизнес-потребности?

Первое мобильное приложение, написанное в Delphi for Android, был для меня это неким пробным камушеком в сторону возможности развивать определенные части информационной структуры предприятия на мобильных платформах.

На многих предприятиях (являющихся нашими клиентами) сходу можно найти задачи, которые можно вынести на мобильную платформу. Это, в первую очередь задачи, связанные с персоналом, у которого нет возможности получить доступ к данным информационной системы с обычного компьютера или ноутбука, нет локальной сети и WiFi, только мобильная сеть. Это работники удаленных площадок, на которых нет возможности организовать стационарное рабочее место в силу определенной специфики, например, курьеры или менеджеры на выезде.
Для таких задач планшет на Android с 3G-модулем – хорошее решение. От нас требуется обеспечить связь с базой данных, удобный интерфейс, компактный трафик обмена данными.

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

Одна из задач: есть специалист, находящийся на удаленной площадке, который должен передать небольшой объем оперативной информации по заказу – текущее состояние проблемы, которую он решает, и некие выходные данные. Данные должны быть переданы в информационную систему оперативно, так как от этого зависит дальнейшее прохождение заказа по цепочке. Кроме того, для решения своих задач, он должен получить дополнительную актуальную информацию, которая вносится в систему другими специалистами, возможно, тоже с мобильного устройства. Использование мобильного устройства, а не ПК под Windows, определяется в основном весовыми характеристиками планшета. «7 дюймов» легко помещаются в большой карман или маленькую сумочку и не ощущаются человеком как дополнительный вес, что позволяет носить эти устройства всегда и везде. Да и работать они могут более 6 часов.

Как решались это проблемы раньше: либо специалист носил с собой ноутбук с возможностью подключаться к сети 3G, либо звонил или посылал SMS диспетчеру. Работа с ноутбуком не всегда возможна, а работа через диспетчера – это потеря оперативности и актуальности данных и, естественно, человеческий фактор.

Читать полностью »

В предыдущих частях цикла, посвященного созданию приложений на платформе FM (FireMonkey), мы познакомились с основными приемами и техниками, позволяющими создавать как «настольные», так и мобильные FM-приложения. И сегодня мы немного отвлечемся от создания демонстрационного приложения, и коснемся некоторых отличительных особенностях процесса разработки с использованием платформы FM. А точнее, мы хотим дать несколько советов (как практических, так и концептуальных), которые, возможно, сделают процесс разработки более комфортным.

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

Активнее используйте окно структуры объектов Structure

FireMonkey формы по своей организации несколько отличаются от VCL аналогов. Компоненты FM имеют свойство parent, и, соответственно, позиции объектов привязаны не к самой форме, а непосредственно к parent-объекту (в данном случае parent не имеет ничего общего с наследованием классов). Поэтому увидеть к какому объекту «привязан» компонент и при необходимости «привязать» его к другому объекту, зачастую проще в окне структуры, чем непосредственно в редакторе формы. Особенно это касается 3D приложений, где используется трехмерная система координат.Читать полностью »

в 13:16, , рубрики: Delphi, метки:

Embarcadero в FMX заботливо предусмотрело клонирование, которе иногда может приятно упростить жизнь разработчика. VCL же явного инструмента клонирования в run-time не предоставляет.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js