개발사례 모터사이클 위험 보고 모니터링 도구는 어떻게 개발했을까

[RAD]

• 원문제목: How This Motorcycle Hazard Reporting Monitoring Tool Was Made
• 원문: https://blogs.embarcadero.com/how-this-motorcycle-hazard-reporting-monitoring-tool-was-made/
• 작성자: Ian Barker (2023.1)

 

Today’s article is from Delphi developer Alessandro Negri. Alessandro talks us through his company’s development of a potentially life-saving reporting tool which links to a system that helps visualize hazards for motorcyclists. Alessandro describes what made them decide to step away from other programming solutions and choose Delphi for the project. He also explains why the success of this project has convinced him to use Delphi with the Skia4Delphi library for planned future cross platform apps.

델파이 개발자 Alessandro Negri가 공유해 준 사례를 정리해보았다. Alessandro는 그의 회사에서 개발한 생명을 구할 수 있는 보고 툴에 대한 사례를 들려주었다. 이 툴은 오토바이 운전자를 위한 것으로, 위험 요소를 시각화는 시스템과 연결되어 있다. Alessandro는 이 프로젝트를 위해 다른 프로그래밍 솔루션에서 델파이로 변경한 이유를 알려주었다. 그리고 이 프로젝트의 성공으로 향후 계획중인 크로스 플랫폼 앱에 Skia4Delphi 라이브러리와 델파이를 함께 사용하게 된 이유에 대해서도 언급한다.

 

목차

모터사이클 위험 보고 모니터링 도구란?

BARRACUDA 프로젝트에 대한 자세한 내용은 어디에서 확인할 수 있을까?

프로젝트 진행 시 중요시 한 설계 결정과 과정은 어떤 것이었는가?

사용한 델파이 컴포넌트와 그 컴포넌트를 선택한 이유는?

설계 프로세스 자세히 알아보기

설계 구현 과정

사용한 다른 컴포넌트들

프로젝트는 실제로 어떤 모습인가?

델파이 프로젝트에 대해 마지막으로 전하고 싶은 이야기가 있다면?

---

 

모터사이클 위험 보고 모니터링 도구란?

Through a DOT government contract, we pitched and successfully developed a motorcycle hazard reporting and alerting SDK for mobile applications called BARRACUDA. The BARRACUDA SDK was integrated into the Beta versions of the REVER Android and iOS mobile applications and launched globally. The BARRACUDA SDK was written as a native service in Kotlin for Android, Swift for iOS, and the backend using Python.

미국 교통부(DOT) 정부 계약을 진행해, 일명 BARRACUDA라고 부르는 모바일 앱 용모터사이클 위험 모니터링 및 알림 SDK를 제안해 성공적으로 개발까지 완료했다. BARRACUDA SDK는 REVER 안드로이드 및 iOS 모바일 앱 베타 버전에 적용되어 전 세계에 출시되었다. BARRACUDA SDK의 안드로이드 버전은 코틀린(Kotlin)으로, iOS 버전은 스위프트(Swift), 벡엔드는 파이썬으로 구축한 네이티브 스비스였다.

Once we have completed the development of the SDK and deployed the backend to the cloud using Microsoft Azure as a provider, we realized we needed to quickly visualize and gauge how hazards were being reported by users. We did not want to create a web application for it, as we had developed our backend as a secure REST API and did not want to add anything to it at this point.

SDK 개발을 완료하고, 마이크로소프트 애저(Azure)를 공급자로 선정해 백엔드를 클라우드에 배포하고 나서야, 사용자들이 보고하는 위험 상황을 빠르게 시각화하고 측정해야 한다는 니즈를 파악하게 되었다. 이미 안전한 REST API로 백엔드를 구축해놨었기 때문에 이를 위해 웹 애플리케이션을 만들고 싶지도 않았고, 당시 무언가를 더 추가하고 싶지도 않았다.

We needed a tool that would provide geospatial capabilities to visualize the hazards, have the tool work cross-platform between Windows and MacOs, and have the ability to develop and modify it quickly. I thought this would be a great project to level up my Delphi development and so I decided to take a plunge and build the tool using my Delphi Professional license since I knew it would support both platforms and develop the software within a couple of hours designing and implementing the tool.

위험 상황을 시각적으로 보여주기 위해 지리 안내 기능을 제공할 수 있고, 윈도우와 맥OS 간에 원활하게 작동할 수 있는 도구가 필요했다. 또한 신속하게 개발하고 수정할 수 있어야 했다. 나는 이 프로젝트에 델파이가 적합한 도구이자, 나의 델파이 개발 수준을 높일 수 있는 좋은 기회라고 생각했다. 델파이는 두 플랫폼을 모두 지원할 뿐 아니라 필요한 도구를 설계하고 구현하는 데 몇 시간이면 충분하다는 것을 알고있었기 때문에 과감히 도전했다.

 

BARRACUDA 프로젝트에 대한 자세한 내용은 어디에서 확인할 수 있을까?

다음 링크를 통해 프로젝트에 대한 자세한 내용을 확인할 수 있다: BARRACYDA - Charles River 분석

 

프로젝트 진행 시 중요시 한 설계 결정과 과정은 어떤 것이었는가?

The first steps were to do a quick outline of the features needed, and then do a mockup (on paper) of what the tool should look like for the user, in this case my small team of three. Our user requirements were as follows:

프로젝트의 첫 단계는 필요한 기능에 대한 간략한 개요를 작성하고, 사용자에게 어떻게 보여져야 하는지에 대한 목업(mockup)을 종이상에 표현하는 것이었다. 우리가 생각한 사용자 요구사항은 다음과 같았다:

1. 지도 표시하기
2. CSV 파일로 위험 요소 불러오기
3. REST API에서 위험 요소 불러오기
4. 모든 위험 요소를 구분 가능한 아이콘으로 표시하기
5. 모든 위험 요소 지우기
6. 모든 위험 요소 id 
7. 고유한 위험 요소를 보고하는 사용자들을 인쇄하기
8. 특정 위도와 경도 주위에서 지도 중앙 정렬하기
9. 위험 요소와 사용자 수 표시하기

 

사용한 델파이 컴포넌트와 그 컴포넌트를 선택한 이유는?

The next actionable step was to figure out how to use a map on a non-mobile application embedded on the application, for that we relied on the TMS Software FNC Maps component. They supported multiple providers and we were not sure on what provider to use yet. After reviewing several, we ended up using Mapbox. REVER uses Mapbox, and we wanted to reduce the differences between our tools and integrators. Our sample SDK applications were also using Mapbox.

다음 단계는 애플리케이션에 임베디드된 비 모바일 애플리케이션에서 지도를 사용하는 방법을 파악하는 것이었다. 이를 위해 TMS 소프트웨어 FNC MAPs 컴포넌트를 사용하기로 했다. 이 컴포넌트는 여러 서비스 공급사들을 지원했지만, 당시 어떤 공급사를 사용할 지는 결정하지 못한 상태였다. 여러 공급사를 검토한 후, Mapbox로 결정했다. REVER는 Mapbox를 사용하였으며, 우리의 도구와 통합체 간의 차이를 줄이고자 했다. 우리의 샘플 SDK 애플리케이션 또한 Mapbox를 사용하고 있었다.

 

설계 프로세스 자세히 알아보기

Finally, I chicken scratched in a notebook what the tool should look like. This is a step I always do since it helps me free-hand and visualize what I want to do. It isn’t a requirement to be the most artistic, but it is also a very satisfying and personal step (I do also do it when creating data models, relational databases, any type of UI, and games).

마지막으로 노트북에도 도구가 어떻게 보여져야 하는지를 대충 작성했다. 이 단계는 내가 늘 하는 일인데, 자유롭게 내가 하고자 하는 것을 시각적으로 보여줄 수 있다. 가장 예술적으로 보여야 하는 것은 아니지만, 개인적으로 하는 단계이자 매우 만족스러운 과정이다 (데이터 모델, 관계형 데이터베이스, 모든 유형의 UI, 게임을 만들 때도 이 단계를 거친다).

 

설계 구현 과정

Having a mapping component selected, a requirements list, and a chicken scratch UI design I could focus on making the tool work and make a shareable build. During the two hours I focused on the following:

확정한 매핑 컴포넌트, 요구사항 목록, 대충 작성한 UI 디자인이 있었기 때문에, 작동하는 도구를 만드는 것에 집중할 수 있었고, 공유 가능한 빌드를 구축할 수 있었다. 2시간 동안 다음 항목들에 집중했다:

1. 에디터에서 아래 그림과 같이 UI를 만든다.
2. UI 컴포넌트를 이벤트에 매핑한다. 대부분이 다음과 같은 이벤트 클릭이었다:
   • CSV 파일에서 위험 요소 로드
   • REST API 쿼리 및 최신 실시간 위험 표시
   • 위험 요소 지우기
   • 특정 위치(지정 위도/경도 편집 필드 옆 눈 아이콘)에서 맵 뷰를 중앙에 맞추기
3. 기본 기능 코드를 작성하고, 모든 단계를 테스트한다.
   • 파일 탐색 대화상자 표시 Display a browse file dialog
   • 파일 찾아보기(browse file) 화면 표시
   • CSV 파일 로드 및 구문 분석 
   • REST 컴포넌트로 백엔드에 액세스
   • JSON 데이터 파싱 
   • 전체 테스트 애플리케이션
   • 데이터 파싱 중 총 위험 수 계산
   • 사전을 활용해 고유한 사용자를 계산하여, 데이터 구문 파싱 중 사용자별로 보고된 위험 수 추적
   • TMS FNC Map 기능이 마커를 올바르게 렌더링하는지 확인하기 위해 추가 시간 소요 
4. 기본 기능 향상 및 테스트
   • 파싱 중 모든 위험의 위도, 경도 중심 평균값 파악
   • 위도와 경도 편집 필드에 제약 조건 추가 
   • 지도에서 위치를 중앙에 배치
   • Windows에서 전체 애플리케이션 테스트
   • MacOS에서 컴파일하고 테스트

 

사용한 다른 컴포넌트들

I leveraged the REST components provided by Embarcadero. Then I used the JSON libraries to parse the data from the REST API and create/add markers to the map.

엠바카데로에서 제공하는 REST 컴포넌트를 사용했다. JSON 라이브러리를 사용해 REST API에서 데이터를 파싱하고 맵에 마커를 생성/추가했다.

The TMS FNC Maps had a few gotchas, such as batching the update of the markers, if this was not done it would take a long time to load and render the map markers. There was also a bug that was quickly fixed specific to the Mapbox version of the component. The TMS devs were very good at helping on their forum and updating their components to address the bug I had encountered. This was my first real project using Delphi and the TMS components, and it proved to be a solid choice for me.

TMS FNC Maps에는 몇 가지 주의할 점이 있었는데, 마커를 일관 업데이트하지 않으면 맵 마커를 로드하고 렌더링 하는 데 시간이 오래 걸리는 문제가 있었다. 컴포넌트 Mapbox 버전 관련 버그도 있었는데, 이는 빠르게 수정되었다. TMS 개발자들은 포럼에서 계속해서 도움을 줬고, 버그 해결을 위한 컴포넌트 업데이트에 많은 지원을 해주었다. 이 프로젝트는 델파이와 TMS 컴포넌트를 실제로 사용한 첫 프로젝트였고, 나에게는 확실한 선택이었음을 증명해보이는 기회였다.

 

프로젝트는 실제로 어떤 모습인가?

The final build of the tool can be seen in the image below, where the user has queried the backend to download hazards and display them on the map.

도구의 최종 빌드된 모습은 아래 그림과 같이 나타난다. 사용자가 백엔드에 쿼리를 보내 위험 요소를 다운로드하고 지도에 표시되는 것이다.

 

델파이 프로젝트에 대해 마지막으로 전하고 싶은 이야기가 있다면?

With Delphi and FMX I was able to quickly develop an internal standalone tool to support our internal needs without adding a web dashboard to our existing REST API, without the bloat from an electron application, embedded maps, and cross-platform support for both Windows and MacOS. This simple tool not only did it fit our current needs, but also gave me a chance to increase my knowledge and development skills with Delphi. The best places to test and skill up are usually with internal tools for your company/project as it will force you to make something that others will need to use (usually it is a small user base) and failing is easier to take and recover. I am a big proponent of small internal tools to automate, validate, and monitor bigger projects.

델파이와 파이어몽키(FMX)를 사용해 기존 REST API에 웹 대시보드를 추가하지 않고도 내부 요구사항을 지원할 수 있는 내부 독립형 도구를 신속하게 개발할 수 있었다. 그리고 일렉트론 애플리케이션, 임베디드 맵, 윈도우와 맥OS를 모두 지원하는 크로스-플랫폼 지원으로 발생하는 인원과 비용의 증가없이도 이 모든 것을 해냈다. 이 간단한 도구는 우리의 현재 요구사항에 부합할 뿐 아니라, 나의 델파이 개발 지식과 기술을 향상시킬 수 있는 기회가 되었다. 테스트하고 기술을 익히기에 가장 좋은 것은 일반적으로 회사/프로젝트의 내부 도구인데, 다른 사람들이 사용해야 하는 무언가를 만들어야 하고(일반적으로 소규모의 사용자 기반) 실패하더라도 쉽게 복구할 수 있기 때문이다. 대규모 프로젝트를 자동화하고 검증 및 모니터링하기 위한 소규모의 내부 도구 사용에 적극 동의한다.

Delphi has come in very handy and paves a road to larger and more complicated projects. Currently I am using Delphi to create a mobile application for both Android and iOS, using the Skia engine, to monitor the progress of oncology patients through their 12-week recovery.

델파이는 매우 유용하고, 더 크로 복잡한 프로젝트를 수행할 수 있는 길을 열어주었다. 현재는 델파이와 Skia 엔진을 사용해 안드로이드와 iOS 모두를 지원하는 모바일 애플리케이션을 개발하고 있다. 이 애플리케이션은 암환자의 12주간의 회복 가정을 모니터링하는 데 사용될 것이다.