Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: '현대화'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. 엠바카데로 블로그에 Atanas Popov 본부장이 쓴 "Modernize Your Apps"를 번역한 글 (원문 작성일: 2018년 2월 12일, 번역일: 2018년 2월 19일) 애플리케이션의 현대화는 델파이/C++빌더 개발자 대부분이 가장 중요하게 생각하는 주제 중 하나이며 꾸준하게 이야기 되고 있다. 지금까지 상당한 기간동안 델파이가개발자와 함께 있었고, 주위에는 델파이로 만들어진 훌륭한 "레거시" 앱들이 매우 많다. 오래 전인 델파이 7 시기에 만들어진 앱들도 여전히 사용 되고 있다. 이런 사실은 델파이가 개발 프레임워크로써 얼마나 품질 수준이 높은 지를 보여주는 증거이기도 하지만, 만들어 진지 10년이 넘은 앱 입장에서 보면, 글쎄... 너무 오래된 것이라는 점 역시 사실이다. 개발자들은 고객들에게 현대적이고 경쟁력 있는 앱을 제공하기 위해 델파이를 최신 버전으로 옮기고 있다. (역자 주: 델파이는 델파이로 만들기 때문에) 우리 역시 내부적으로 RAD 스튜디오 자체를 현대화하기 위해 같은 여정을 밟아 오고 있다. 현대화가 늘 쉽기만 한건 아니지만, 노력할 가치가 있다. 나는 엠바카데로가 이 과정에서 어느덧 상당한 진전을 이루었다고 생각한다. 그리고, 현대화의 여정을 계획하는 델파이 개발자들에게 도움이 될 수 있도록, 우리가 현대화 여정을 통해 직접 얻은 몇가지 교훈을 정리하여 공유해야겠다는 자신감이 생겼다. UI를 현대식으로 업데이트 하십시오 내 생각에 현대화 프로젝트에서 내가 가장 어려운 부분은 UI 현대화를 설득력있게 주장하는 것이다. 잘 작동한다면, 아이콘이 낡아 보이는 걸 신경쓸 사람이 누가 있냐고 말하는 사람들도 분명히 있다. 개발자 역시 종종 룩앤필(look and feel)을 신경쓰지 않는 경향이 있어서, UI 현대화에 열정을 쏟기 어렵다. 하지만, 현대화된 룩앤필(look and feel)의 영향은 너무나 크다. 우리는 지난 2년간 점진적으로 많은 현대화를 해왔으며 더 할 것들도 있다. 우리가 진행한 설문 조사에서 RAD 스튜디오의 룩앤필이 더 높은 우선 순위를 차지하는 경우는 거의 없다. "외형이 예뻐보인다"는 이유로 기업용 소프트웨어를 구입한다고 말하는 고객 역시 거의 없다. 하지만, UI 개선이 완성되면, 그것이 끼치는 영향은 놀랄만큼 크다. 특히 델파이로 만든 앱에서 그 영향이 더 큰데 그 이유는 "레거시"라는 편견이 함께 있기 때문이다. UI 현대화라는 싸움은 할 만한 가치가 있고 다행스럽게 VCL과 FMX 도구가 업데이트 되면서 UI 현대화를 구현하는 것이 더 쉬워졌다. 시간을 가지고 옳은 일을 하자. 전문 디자이너의 도움을 받는 것은 정말 가치있는 일이다 (다시 말하지만, 많은 개발자들이 잘 하지 못하는 분야이다). 멋진 고품질 아이콘의 영향을 간과하지 않도록 주의하자. 아래 그림은 우리가 10.2.2 버전을 만들 때 새로 업데이트한 아이콘(들) 중 일부이다. 델파이 바깥에도 값이 매우 싸면서도 좋은 것들이 정말 많다. 예를 들어, 나는 www.icons8.com 을 좋아한다. 모바일로 가십시오 델파이의 가장 큰 장점 중 하나는 바로 파이어몽키(FMX)이다. 스마트 폰 채택율이 증가함에 따라 (2018년까지 70% 수준까지 예상됨), FMX 또한 크게 증가할 것이다. VCL을 이미 알고 있다면, 비교적 자연스럽게 FMX를 사용하여 개발할 수 있다. 물론 FMX 만의 고유한 특징이나 스타일이 있으며, 솔직히 말해서 RAD스튜디오 작업 흐름은 좀더 더 개선될 여지가 있기도 하다. 하지만, RAD 스튜디오의 생산성은 놀라운 수준이다. RAD 스튜디오가 아닌 다른 기술인 경우에는 대부분 플랫폼 별로 팀을 따로 꾸리고 투자도 따로 하게 된다. 과거에는 모바일 앱을 하나의 패키지로 외부에 맡겼지만 지금은 달라지고 있다. FMX를 사용하면 해당 모바일 앱을 델파이 팀이 개발할 수 있다. 오래된 앱을 FMX로 다시 만들 필요는 없지만, 모바일로 갈 수 있도록 의미있게 확장하는 것은 필수다. 개발자는 엄청난 존경을 받게 될 것이고 델파이 기술은 현대적인 것이라고 당당하게 인식될 것이다. 개발팀이 꾸려질 수도 있다. FMX를 시작하는 데 도움이 되는 교육 자료들도 많다. 나는 개인적으로 델파이 스타일(Delphi Styles)를 좋아한다. 아주 매끈하게 맞춤형 룩앤필을 구현할 수 있기 때문이다 (아래 그림은 www.delphistyles.com 에서 골라 온 FMX 스타일 템플릿이다). "멀티-티어(Multi-Tier)"로 만드십시오 아키텍처(구조)는 간단한 문제가 아니다. 안타깝지만, 훌륭한 개발자 조차도 다른 분야에 대한 지식이 없을 수도 있다. 이건 그저 소프트웨어 개발 안에 워낙 방대한 분야가 있다는 단순한 이유 때문이다. 따라서 데스크탑 앱을 멀티-티어로 옮기기 등 아키텍처 변경을 해내는 것은 경험이 가장 많은 개발자에게 조차도 새로운 학습 경험이 될 수도 있다는 의미이다. 학습한다는 것 또는 도움이 되는 외부 지원을 받는 다는 것은 언제나 좋은 일이다. 엠바카데로는 쉽게 아키텍처를 전환할 수 있도록 하는 것을 목표로 한다. 예를 들어, RAD 서버는 멀티-티어 아키텍처를 지원하는 능력이 뛰어나다. 오래된 앱을 멀티-티어 관점에서 다시 생각하는 것이 (과거에 어떻게 구축되었는 지에 따라 다르기 때문에) 아무런 보장이 없긴 하지만 그다지 벅차거나 두려운 일은 아니다. 처음에는 겁이 많이 났지만, 일단 들어가 보니, 전환 작업이 예상보다 훨씬 적었다고 나에게 말한 개발자들이 많았다. 확실히, 이렇게 전환하면 자바 등 완전히 다른 언어로 플랫폼을 바꾸는 것에 비해 비용이 훨씬 적게 든다. 다시 말하지만, 한가지 간단한 접근 방식은 가능한 작게 시작하고 가능한 많이 모듈화하는 것이다. 또한 너무 서두르느라 VCL 고객을 잃지 않도록 하자. 애플리케이션이 제공하는 속도는 복제되지 않는다. 특히 몇초가 매우 중요한 민감한 환경이라면 더욱 주의해야 한다. VCL 앱을 자바로 재구축하고도, 사용자들이 받아들이지 않은 몇백억원 짜리 프로젝트는 내가 아는 것만 몇개나 된다... 엄청난 낭비이다. "웹화(Webify)" 하십시오 아마 무슨 의미인지 바로 이해했을 것이다. 델파이로도 할 수 있는 방법이 오늘날 많이 있다. 가장 이상적인 방법은 계층으로 나눠진 앱을 만들고 독립적인 웹 클라이언트를 구축하는 것이다. 물론 우리는 Ext JS를 추천한다. 우리 제품 중 하나이기 때문이다. 하지만, 다른 클라이언트 웹 기술도 좋은 것들이 많다. 또 다른 방식이 더 빠를 수도 있는데 UniGui와 같은 도구를 사용하는 것이다. UniGui는 VCL 방식으로 개발하면서도 웹 클라이언트를 빌드할 때 Ext JS를 활용한다. 모든 경우에 효과가 있지는 않지만 매우 빠르고 생산적이다. 개발자가 앱의 모듈을 빠르게 만들어서 웹에서도 델파이가 잘 그리고 빠르게 효과를 발휘한다는 것을 보여 줄 수 있다는 점은 확실하다. 오늘날 델파이 앱과 연결되는 웹 인터페이스들은 닷넷(.NET)으로 구축된 것이 많다. 둘 다 윈도우와 연관되어 발전했기 때문이다. 물론 이것도 효과는 있지만, 우리의 최근 경험과 새 JS 기술을 바탕으로 볼 때, JS를 통해 얻을 수 있는 속도와 유연성은 엄청나다. 통합하십시오(Integrate) RAD스튜디오에는 가장 뛰어난 통합 프레임워크(들)과 컴포넌트(들)이 들어있다. 다른 기술(들)이 가장 어려워하는 점들 중 대표적인 것이 바로 '통합'이다. 이점에서 우리는 정말 우월하고 빠르다. 최근 설문 조사에서 우리 고객 중 FireDAC을 채택한 고객의 비중이 엄청 높았다. 멋진 일이다. 개발한 현대식 앱이 더 많은 통합을 할 수 있도록 하는 새로운 방식을 찾아야 한다. ERP 시스템에서 재고를 가져와서 보여주거나 정보를 받아본다면 어떨까? 엔터프라이즈 커넥터스(Enterprise Connectors)는 FireDAC 프레임워크를 기반으로 한다. 그리고 이런 통합을 매우 잘 해낸다. 우리는 ExtJS로 포탈을 만드는 내부 프로젝트를 할 때 엔터프라이즈 커넥터스를 사용하여 우리의 SFDC(세일즈포스, Salesforce.com)에 연결했다. "와!" 하는 탄성이 나오는 개발 경험이었다. 혁신하십시오(Innovate) 델파이에는 푸쉬알림, 비콘, Woll2Woll 모바일 편집기(www.woll2woll.com/beam) 등 많은 기능이 새로 추가되었다. 윈도우 10의 새 기능을 사용하는 개발자가 거의 없다는 점은 매우 놀랍다. 잘 활용되지 못하고 기술 중에서 내가 가장 좋아하는 것은 비콘(Beacons)이다. 이것들은 지금 "무료로" RAD 스튜디오 엔터프라이즈 에디션 안에 들어있다. 비콘 모바일 편집기는 이 비콘 기술을 사용하는 모바일 앱을 개발하는 속도를 높인다. 위치 데이터 수집을 활용하는 기업용 델파이 앱들이 매우 많다는 점을 감안하면, 델파이 앱 안에 넣는 것이 당연할 만큼 쉽고 멋진 기능이다. 그리고 델파이에서 최고 장점은 이런 혁신을 실현하기 위해 수억원의 비용을 들일 필요가 없다는 점이다. 레거시라는 주장을 넘어서십시오 이점은 엠바카데로가 RAD스튜디오에 들이는 노력과는 관계가 없는 내용이겠지만, 어쨌든 델파이 고객들 각자가 극복해야 할 장애물이다. 델파이는 레거시라는 인식은 여전하다. 최근 이런 인식을 극복하려는 노력이 있긴 하지만 아직까지도 마찬가지이다. 최근, 나는 살짝 다르게 접근해보았는데 매우 성공적이었다. 이제 나는 델파이가 가진 많은 장점들을 변호하려고 깊이 들어가지 않고, 사실 몇가지만 말한다. 그리고 더는 변호하지 않는다. 효과가 있다! 오늘날 델파이는 가장 큰 상업용 개발 생태계 중 하나이다 - 경기가 악화되고 지원이 감소함에 따라 많은 오픈 소스들이 추진력을 잃었다. 델파이가 가장 빠르고, 가장 사용하기 쉽고, 가장 기능이 뛰어난 개발 도구라는 사실은 말할 필요가 없다 (약간 주관적이긴 하지만.. 사실이다!). 윈도우 개발용인 VCL 프레임워크는 MS 윈도우를 네이티브로 지원하는 기능을 가장 많이 유지해오고 있다. VCL을 이기는 건 없다. FMX는 잠마린(Xamarin) 보다 네이티브 크로스 플랫폼 지원 능력이 더 좋다. 그 인기는 특히 안드로이드 앱 개발 측면에서는 빠르게 증가하고 있다. 내 생각에 기술 위험을 관리하고자 하는 회사라면 델파이와 VCL을 선택하는 것이 시중에 있는 최신 기술과 최신 프레임워크를 선택하는 것보다 훨씬 더 안전하다.앵귤러(Angular)를 여러번 반복하거나 Java 마이그레이션에 엄청나게 쏟아 부어본 경험을 해 본 사람에게 물어보기만 하면 바로 알 수 있다. 매우 생산성이 높은 언어와 재사용할 수 있고 프론트-엔드와 백-엔드에 유연하게 작업할 수 있다는 점이 델파이에게 강력한 기술 경쟁력을 제공한다. 글쎄, 처음 의도보다 글이 다소 길어졌다. 하지만 현대화(Modernization)에서 넘어서기에 아마도 가장 어려운 점이 하나가 있는데, 다시 말하지만, 기술이라기 보다는 오히려 인식의 문제이다. 고객은 델파이 교육을 받은 쓸만한 개발자가 부족하다는 점을 계속 주장한다. 안타깝지만, 여전히 사실이다. 숙련된 델파이 개발자 수는 다른 인기있는 기술에 비해 더 적다. (역자주: SI 업체 등) 아웃소싱 회사는 델파이 같은 도구에 특히 부정적인데, 델파이의 생산성이 자신들의 사업 모델과 직접적으로 반대되는 경향이 있기 때문이다. 자바 개발자 50명을 팔 수 있는데 그 대신 델파이 개발자 5명을 팔 이유가 없다. 이것 역시 우리가 이기는 주장이다. 델파이 개발자는 그렇게 많이 필요하지 않다 - "그만큼" 좋다. 델파이 개발자가 자신의 기술을 닦아야 하거나 새 팀을 교육해야 하는 한, 우리는 엠바카데로 아카데미(Embarcadero Academy)를 계속해서 발전시키고 더 많은 컨텐츠와 과정을 붙여나갈 것이다. 우리 경험 상 고급 개발자라면 델파이를 정말 빠르게 익힌다. 현대적인 멋진 앱을 만들어서 기술 비관을 날려버리자.
  2. 엠바카데로 마이그레이션 센터 홈페이지에서 가장 강조하는 비디오인 Top 5 Considerations when Migrating Your Projects to RAD Studio 10.4 Sydney를 한글로 요약 번역한 글 (비디오 게시일: 2020년 7월 21일, 번역일: 2020년 9월 5일) Al Mannarino와 Mary Kelly는 고객사 수백곳에서 델파이 업그레이드 컨버전 작업을 도왔습니다. Al과 Kelly가 꼽은 "델파이 마이그레이션 프로젝트에서 당면한 Top 5 고려사항과 대응책"을 5등부터 1등까지 알아봅니다. 델파이 마이그레이션 프로젝트에서 당면한 Top 5 고려사항 Al Mannarino Mary Kelly 5. Runtime 오류 해소 4. 미들웨어 3. 데이터베이스 전환 2. 유니코드 1. 써드파티 라이브러리 5. UI 현대화 (윈도우10 포함) 4. 미들웨어 3. FireDAC 2. 유니코드 1. 써드파티 라이브러리 5위 (Al 선정) Runtime 오류 해소 마이그레이션 후, 경우에 따라 Runtime 오류가 발생할 수 있다. 런타임 오류가 발생하는 경우는 주로 폼의 프로퍼티가 이전 버전에는 있었지만 새 버전에서 없어졌거나, 윈도우에서 더이상 제공되지 않는 오래된 dll을 사용하는 경우이다. 이런 오류는 애플리케이션을 실행해보기 전에는 알 수 없다. 까다로운 경우의 예를 들면, 오래된 써드 파티 라이브러리를 사용했는데 이 오래된 컴포넌트가 폼 디자이너에서 (제작 당시에는 델파이 폼디자이너에 있던 속성인) 그리드의 ColumnCount 속성을 사용했다면 애플리케이션을 실행하면 “그리드에서 ColumnCount라는 프로퍼티를 찾을 수 없습니다”라는 오류가 발생한다. 소스 코드에서 ColumnCount라는 변수를 찾으려고 해도 소스 코드에서 찾을 수 없는데, 왜냐하면 ColumnCount는 소스 파일 (델파이라면 .pas)이 아니라, 폼 파일(델파이라면 .dfm)에 있기 때문이다. 따라서 dfm 파일을 열어서 ColumnCount를 찾아서 삭제 또는 수정해야 한다. (Mary 선정) UI 현대화 (윈도우10 포함) UX는 뜨거운 관심을 받고 있다. 사용자에게 최상의 UI나 UX를 제공하는 것은 이제 매우 중요해졌다. 오래된 애플리케이션은 윈도우 10에서 작동된다고 해도 화면이나 사용 방식이 윈도우 10과 이질적이다. 개발자는 마이크로소프트에서 새로 소개한 기능을 반영, VCL 스타일 적용, 모바일 환경에 맞게 변화 등을 원한다. 마이그레이션이 끝나고 사용자가 가장 먼저 만나는 것은 화면이다. 화면을 봤을 때 매력적이지 않다면, 아무리 많은 개선이 있었다고 해도 사용자에게 전달되지 않는다. 개발자는 사용자가 새 애플리케이션을 기쁘게 받아드리기를 바라기 때문에 시작적으로 매력적인 애플리케이션을 제공하고 싶어한다. 10.4에는 여러가지 VCL 스타일들이 들어 있다. 원하는 것을 선택하면 사용자에게 새로운 룩앤필을 적용할 수 있다. (Stephan Ball의 의견: 화면 변경은 사실 매우 큰 변경 작업이라서 5위보다 순위가 높을 것이라고 생각했다. 하지만, RAD 스튜디오에서는 스타일을 이용하여 반영하면 쉽게 해소되는 문제라서 5위인 것으로 생각된다) 4위 (Al 선정) 미들웨어 오래전 델파이에서 사용된 미들웨어는 COM기술을 기반으로 한 Midas였다. 하지만 지금은 데이터스냅(DataSnap)과 RAD서버가 사용된다. Midas를 사용하여 구축된 멀티티어 애플리케이션은 COM에 대한 종속성을 없애야 한다. 대응책으로 반제품인 데이터스냅 또는 완제품인 RAD서버로 마이그레이션을 들 수 있다. 전환 방법은 “Midas에서 데이터스냅으로 전환하기” 와 “데이터스냅에서 RAD서버로 전환하기” 기술 백서에 잘 설명되어 있으므로 잘 활용하기 바란다. (Mary 선정) 미들웨어 애플리케이션을 웹과 모바일로 확장하는 추세이다. RAD서버나 데이터스냅을 도입하게 되면 기존의 애플리케이션 기술 뿐만 아니라 사용자 기반까지도 웹과 모바일로 확장할 수 있기 때문에 미들웨어에 대한 요구가 많다고 생각한다. 3위 (Al 선정) 데이터베이스 전환 마이그레이션을 할 때, 항상 데이터베이스 마이그레이션이 수반된다. BDE를 사용하는 애플리케이션이 아직도 얼마나 많은지 알고 놀랐다. BDE는 델파이 3,4,5 시절의 엔진이고 당시의 파라독스나 dBAse를 연결할 때 사용되었다. BDE는 지원이 중단된지 15년이 넘었고, 그동안 계속해서 BDE에서 벗어날 것을 권장해왔는데도 불구하고 (각자 나름의 이유가 있었겠지만) 여전히 BDE가 많이 사용되고 있다. BDE는 사용하지 말아야 한다. 왜냐하면 15년 전에 중단되었을 뿐만 아니라, 유니코드와 64bit를 지원하지 못하기 때문이다. BDE는 훨씬 새로운 고성능 컴포넌트인 파이어닥(FireDAC)으로 전환해야 한다. reFind라는 유틸리티는 BDE 구문을 찾아서 FireDAC으로 전환하기 때문에, BDE를 FireDAC으로 매우 쉽게 거의 자동으로 전환할 수 있다. 시간 낭비할 필요없이 reFind를 사용하자. (Mary 선정) FireDAC으로 이전 나도 역시 여전히 BDE 사용자가 많아서 놀랐다. 마이그레이션 시에는 반드시 BDE를 제거해야 한다. 특히 윈도우10에서 BDE는 완전히 멸종된 기술이라서 항상 문제가 될 것이다. reFind를 사용하면 쉽게 FireDAC으로 전환할 수 있다. 게다가 파라독스 같은 오래된 DB에서 사용하던 방식 즉 테이블을 열어서 필터링을 하는 방식을 벗어나야 한다. SQL구문을 활용해 DB를 다루고, 데이터 액세스 방식과 내용 면에서 보다 효율적으로 데이터베이스를 사용하기 바란다. 요즘은 데이터 보안이 강조된다. 따라서, 파일과 데이터 액세스 암호화에 대한 관심이 매우 높다. FireDAC으로 전환하면 SQL서버, 인터베이스, 오라클 등 견고한 데이터베이스를 사용할 수 있고 이런 DB들이 제공하는 수준 높은 기능을 사용할 수 있게 된다. (tephan Ball의 의견: BDE 이외에도 DBExpress와 ADO도 여전히 사용되지만 역시 보안 등의 측면에서 FireDAC으로 전환할 것을 권장한다) 2위 (Al 선정) 유니코드 유니코드는 흥미로운 주제이다. 개발자들은 유니코드 반영이 매우 어려울 것이라고 생각하지만 실제로는 그렇게 어렵지는 않다. 가장 먼저 해야할 질문은 “유니코드가 꼭 필요한 애플리케이션인가 아니면 영어버전으로만 계속 사용해도 충분한가”이다. 만약 영어버전만 사용한다면 String 이나 Unicode String 대신, Ansi string 타입을 사용하면 된다. 하지만 유니코드로 가고 싶다면 Unicode Statistics라는 도구를 사용하라. 이 도구는 유니코드 전환 복잡도를 측정하고, 전환 시 변환되어야 하는 코드가 무엇인지를 알려준다. String을 많이 사용했다고 걱정하는데 오해이다. 전혀 손댈 필요가 없는 경우도 많다. 유니코드 변환은 string을 어떻게 사용했는가에 따라 달라지는 것이지 코드의 모든 string을 변환해야 한다는 의미는 아니다. 컴파일러는 똑똑해서 유니코드 변환이 필요한 곳을 알려준다. 경험 상 유니코드 전환은 생각보다 훨씬 쉽다. 일단 유니코드로 전환하고 나면 영어권 밖으로 진출할 수 있다. 컴파일을 하면 컴파일러가 ansi string과 string 타입이 서로 맞지 않는다는 오류를 표시하므로 쉽게 파악할 수 있다. 컴파일러는 타입 변환(캐스팅, casting)을 할 수 있다. 하지만, 컴파일러가 확신할 수 없기 때문에 에러를 표시하는 것이다. 따라서, 가장 쉬운 방법은 컴파일러가 알려주는 해당 타입으로 변환하는 것이다. (Mary 선정) 유니코드 유니코드 반영은 작업이 크고 가장 어렵다. 예를 들어 C++을 업그레이드 하려다보면 C++03 표준에서 C++17 표준으로 크게 넘어가는 경우가 많다. 이때 언어 표준에서 그동안 어떤 변화가 있었는지를 알아야하고,단순히 에러만 해소하도록 고쳐나가는 것이 좋을 지 아니면 코드 일부를 아예 다시 작성하여 유니코드 반영 뿐만 아니라 C++의 새 기술을 적용하여 향상할 수 있도록 하는 것이 좋은지를 고민하게 된다. (Mary의 의견: docwiki에는 유니코드 전환 시 제공되는 컴파일러의 에러 코드에 대한 설명과 해소법이 있다. 이것을 활용하면 좋다) 1위 (Al 선정) 써드파티 컴포넌트 마이그레이션을 준비할 때 가장 먼저 해야 할 질문은 “사용하고 있는 써드파티 컴포넌트가 무엇인가?” 이다. 써드파티 라이브러리와 플러그인 역시 모두 다시 컴파일되어야 하기 때문이다. 소스코드가 있다면 더 쉽다. 소스를 가져와서 다시 빌드하면 된다. 소스코드가 없는 것들은 현재 개발툴에서 작동하는 버전을 찾아서 그 버전을 사용해야한다. RAD스튜디오(델파이, C++빌더) 개발툴 안에 있는 겟잇 패키지 매니저에서는 써드파티 기술 250여가지가 제공된다. 여기에서 검색을 하면 해당 개발툴에서 작동이 보장되는 버전을 찾아을 수 있으며 겟잇에서 바로 설치할 수도 있다. 겟잇 패키지 매니저를 잘 활용하면, 각 써드파티 마다 새 버전을 찾기 위해 인터넷을 뒤지는 수고 뿐만 아니라 찾아낸 버전이 현재 개발툴에서 작동되는 지를 일일이 확인 하는 수고를 덜 수 있다. JEDI, 터보파워 등 오픈 소스 써드파티 뿐만 아니라 TMS, Woll2Woll 등등 상업용 유료 써드파티인 경우 평가판이 제공된다. (Mary 선정) 써드파티 컴포넌트 동감이다. 마이그레이션을 준비할 때 가장 먼저해야 할 작업은 사용하고 있는 써드파티 컴포넌트를 확인하는 것이다. 소스 코드가 있으면 다시 컴파일을 하면되지만, 소스 코드가 없는 것들은 업그레이드된 버전을 찾아야 한다. 만약 이 두 경우에 해당되지 않는다면 곤란할 수 있다. 이때는 고생해서 억지로 끼워맞추기 보다는 오히려 TMS, DevExpress, JEDI 등으로 옮기는 것이 더 쉽고, 마이그레이션 후 결과적으로 더 애플리케이션이 더 향상된다. 엠바카데로 마이그레이션 센터(영문) : https://www.embarcadero.com/rad-in-action/migration-upgrade-center 데브기어 마이그레이션 센터(한글): https://www.devgear.co.kr/rad-in-action/migration-upgrade-center * 데브기어 마이그레이션 센터(한글)는 엠바카데로(EN)의 정보를 번역한 곳이 아닙니다. 따라서 두 곳을 모두 참고하면 도움이 됩니다.
  3. 이 문서의 목적: DocWiki에 있는 [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC) 문서가 실제로 따라하기에 다소 불편하게 되어 있어서, 내용과 틀을 유지하면서, 따라하기 쉽게 보강함 중요! 미리 알아둘 점: Hub 페이지: BDE 애플리케이션을 FireDAC으로 이전하는 방법: 이 문서의 상위 문서로써 실습 뿐만 아니라 팁과 대응 요소 등이 잘 정리되어 있다. 이 문서와 비슷한 문서: [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC): 두 문서 모두 1~ 8단계와 동일하다. 이 실습의 "1~8 단계"는 필요하면 비교해 보기 좋다. 이 실습의 "9단계" (윈도우 11 스타일 적용하기)는 이 글에만 있다. (기능 뿐 아니라 화면까지 멋지면 마이그레이션 만족도가 더 높아진다) 이 실습을 따라가는 도중에 에러 메시지를 만날 수 있다: 해당 부분에 설명되어 있지 않다면, 맨 뒤에 있는 "예상되는 오류와 처리"를 보고 해소하자. (그래도 해소되지 않으면, 답글을 남겨서 다른 개발자의 도움을 받기 바란다) 이 글의 기대 효과: RAD 스튜디오 설치 시 함께 제공되는 reFind와 변환 규칙 파일(FireDAC_Migrate_BDE.txt)을 통한 자동 변환 방법 학습 아래의 마이그레이션 방법을 직접 경험 데이터 액세스 기술: BDE에서 FireDAC으로 데이터베이스: 파라독스에서 인터베이스(InterBase)로 사용자 화면(UI): 윈도우 95 에서 윈도우 11 화면 스타일로 델파이 버전: 구버전에서 최신 버전으로 목차 1단계. 실습에서 사용할 구버전 소스 파일을 복사하여 프로젝트 준비 2단계. 코드 자동 변환: reFind를 사용하여BDE 컴포넌트를 FireDAC으로 변환 3단계. FireDAC에서 사용할 데이터베이스 연결 정의 생성 4단계. FireDAC의 필수 컴포넌트 추가: DBMS에 맞는 드라이버와 Wait 커서 5단계. FireDAC.FDConnection에 연결 설정 6단계. 데이터베이스 타입 맵핑 변경 7단계. 불필요한 코드 제거: 파라독스 관련 코드 8단계. 인터베이스에 맞게 관련 코드 정비 9단계. 윈도우 11 스타일 적용 예상되는 오류와 처리 방법 [FireDAC][Comp][Clnt]-340. Driver ID is not defined. Set TFDConnection.DriverName or add DriverID to your connection definition The EditUpdateError method referenced by Parts.OnupdateError has an incompatible parameter list. Remove the reference? [dcc32 Fatal Error] EDOrders.pas(21): F2613 Unit 'DBLookup' not found. Project mastapp.exe raised exception class EIniFileException with message 'Unable to write to RPTSMITH.CON' [Break] Project mastapp.exe raised exception class EIBNativeException with message '[FireDAC][Phys][IB]Dynamic SQL ErrorSQL error code = -206Column unknownA.FULLNAME'. [FireDAC][Phys][IB] Unable to complete network request host "127.0.0.1/3050". Failed to establish a connection. 참고한 자료 1단계. 실습에서 사용할 구버전 소스 파일을 복사하여 프로젝트 준비 RAD 스튜디오를 설치하면, 이 실습에서 사용할 BDE를 사용하는 소스 전체가 아래 경로에 있는 Demo 폴더에 있다. C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Object Pascal\Database\FireDAC\Tool\reFind\BDE2FDMigration 위 경로 중 \22.0\은 RAD 스튜디오 11.0 인 경우임. 이 숫자는 버전에 따라 달라짐. 그림. RAD 스튜디오에서 reFind 용으로 제공하는 Sample 파일의 기본 경로와 해당 파일 원본을 손상시키지 않고, 한 곳에 작업할 모든 내용을 모아두기 위해 다음과 같이 한다. [진행 절차] 원하는 곳에 원하는 이름 (예: "My_FireDAC_2_BDE")으로 새 폴더를 만든다. 앞으로 모든 작업 파일은 이 새 폴더에 두기로 한다. 위에서 안내한 Sample 폴더 안에 있는 Demo 폴더와 FireDAC_Migrate_BDE.txt 파일을 복사하여, 방금 새로 만든 "My_FireDAC_2_BDE" 폴더 안에 붙여넣는다. 복사해 넣은 폴더와 파일의 이름을 바꾼다. Demo (폴더) --> My_FireDAC_MastApp (FireDAC을 사용하는 MastApp 프로젝트의 폴더이며 여기의 코드가 변경된다) FireDAC_Migrate_BDE.txt (파일) --> My_FireDAC_Migrate_BDE.txt (이 파일도 조금 수정할 것이다) 2단계. 코드 자동 변환: reFind를 사용하여BDE 컴포넌트를 FireDAC으로 변환 1단계에서 복사한 FireDAC_Migrate_BDE.txt 파일에는 BDE를 FireDAC으로 변환하는 규칙이 정의되어 있다. 아래와 같이 변환 규칙 파일과 reFind(코드의 텍스트 자동 변환 도구)를 사용하면, 코드에 있는 BDE 컴포넌트(와 해당 프로퍼티)가 모두 해당 FireDAC 컴포넌트(와 해당 프로퍼티)로 변경된다. 명령창에서 직접 입력하는 방식으로 reFind를 실행하면 되지만, 타이핑할 내용을 .bat 파일로 만들어서 명령을 실행하는 것이 더 편하고 간단하므로 이 방식으로 설명한다. [진행 절차] "My_FireDAC_2_BDE" 폴더 안에서 마우스 오른쪽 클릭 > 새로 만들기 > 텍스트 문서를 선택한다. "새 텍스트 문서.txt"가 만들어지면 파일 명을 "Run_FireDAC_Migrate_BDE.bat"로 변경한다. (주의! 파일 확장자도 .txt가 아니라 .bat가 되어야 한다 메모장을 열고, 방금 만든 "Run_FireDAC_Migrate_BDE.bat" 파일을 메모장으로 드래그 드롭하여 파일 내용을 연다 (아직은 아무 내용도 없다) 이 파일에 아래 내용을 넣고 저장한다. (내용을 이해하고 싶으면 reFind 설명을 참고) refind My_FireDAC_MastApp\*.pas My_FireDAC_MastApp\*.dfm /X:My_FireDAC_Migrate_BDE.txt pause 방금 만든 "Run_FireDAC_Migrate_BDE.bat" 파일을 더블 클릭하여 이 배치파일을 실행한다. 실행한 결과가 아래 그림과 같으면, 아무 키나 눌러서 명령창을 닫는다. 그림. Run_FireDAC_Migrate_BDE.bat 이 실행된 결과 화면 3단계. FireDAC에서 사용할 데이터베이스 연결 정의 생성 FireDAC에서 사용할 연결 정의를 생성해야 한다. 이 예제에서는 FDExplorer 유틸리티, 즉 'FireDAC Explorer'를 사용하기로 한다. [진행 절차] RAD 스튜디오에서 메인 메뉴 > Tools > FireDAC Explorer를 클릭한다. FireDAC Explorer 창에서 메인 메뉴 > File > New > Connection Definition Ctrl+C를 클릭한다. FireDAC Explorer 창의 왼쪽에 있는 Object Explorer 트리뷰에 "ConnectionDef1"이라는 새 연결 정의가 생기고, 타이핑하면 바로 이름을 바꿀 수 있도록 이름이 선택된 상태일 텐데, "MASTSQL"이라고 타이핑하여 이 연결 정의의 이름을 지정한다. FireDAC Explorer 창의 오른쪽 그리드에서는 방금 만든 "MASTSQL" 연결 정의의 프로퍼티를 설정할 수 있다. 연결 정의 파라미터를 아래와 같이 지정한다. DriverID=IB Protocol=TCPIP Server=127.0.0.1 DataBase=C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Data\MASTSQL.GDB *(아래 "주의 " 참조) User_Name=sysdba SQLDialect=3 CharacterSet=UTF8 ExtendedMetadata=True FireDAC Explorer 창에서 메인 메뉴 > Edit > Apply를 클릭하여 저장한다. RAD 스튜디오를 종료하고 다시 시작한다. (그래야 새로 만든 연결 정의가 반영된다) 그림. FireDAC Explorer를 열고, 인터베이스 데이터 연결을 정의 *주의: 이 예제에서 사용된 소스는 데스트탑 데이터베이스인 파라독스(Paradox)를 사용하고 있었다. 위에 있는 "MASTSQL" 연결 정의의 파라미터 중 DataBase에 그 데이터 파일인 MASTSQL.GDB의 전체 경로를 지정하고 있는데, 이 파일은 해당 파라독스(Paradox)를 엠바카데로에서인터베이스로 이미 전환해 놓은 데이터 파일이다. RAD 스튜디오 11.0를 Sample 까지 모두 설치했다면 위의 전체 경로를 보면 MASTSQL.GDB 파일이 있을 것이다 (설치한 RAD 스튜디오 버전이 다르다면, 경로 중간의 /22.0/ 대신 다른 숫자로 되어 있을 것이다) 참고로, 파라독스의 데이터를 인터베이스로 옮길 때는 Clever Components InterBase DataPump를 사용할 수 있다. 4단계. FireDAC의 필수 컴포넌트 추가: DBMS에 맞는 드라이버와 Wait 커서 Docwiki 원문의 4단계에서는 변환한 소스가 있는 폴더에서 프로젝트 파일인 "mastapp.dproj" 를 두 번 클릭하여 프로젝트 파일을 열고 uses 에 FireDAC.Phys.IB, FireDAC.VCLUI.Wait 를 추가하라고 되어 있다. 원문의 안내 대로 진행해도 좋지만, 이 4단계를 생략해도 된다. RAD 스튜디오(델파이, C++빌더) 11.0 버전에서는 컴파일 할 때 프로젝트에서 사용하고 있는 데이터베이스 (이 예제에서는 인터베이스)를 감지하여 자동으로 uses에 FireDAC.Phys.IB 유닛과 FireDAC.VCLUI.Wait 유닛을 추가하고 해당 드라이버를 반영하기 때문이다. 게다가 이 유닛들은 프로젝트 소스가 아니어도, 메인 폼이나 데이터 모듈이어도 상관없다. 5단계. FireDAC.FDConnection에 연결 설정 Docwiki 원문의 5단계에서는 DataMod.dfm (데이터 모듈의 폼파일)을 열고, 폼 파일 코드에서 TFDConnection 컴포넌트를 찾아서 연결 정의를 타이핑하여 넣으라고 되어 있다. 원문의 안내 대로 진행해도 좋지만, 아래 방법이 보다 쉽고 정확하다. [진행 절차] RAD 스튜디오 오른쪽의 프로젝트 관리자에서 DataMod.pas를 더블 클릭하여 연다. (오류 처리 방법 보기) 코드 에디터가 열리고, 해당 소스 코드가 보이면, 화면을 폼 디자이너로 바꾼다 (코드 에디터에서 폼 디자이너로 화면을 바꾸는 방법: 코드 에디터 화면의 맨 아래 오른쪽에 있는 탭에 Code가 선택되어 있을 것이다. 그 옆에 있는 Design 탭을 선택 또는 단축키 F12 사용). 폼 디자이너에는 DataMod의 컴포넌트들이 보일 텐데, 2단계를 통해서 이미 FireDAC 컴포넌트로 변환된 것을 알 수 있다. 폼 디자이너에 있는 컴포넌트 중에 "Database" 컴포넌트 (이름이 Database인 FDConnection 컴포넌트)를 한번 클릭하여 선택한다. RAD 스튜디오 왼쪽의 오브젝트 인스펙터에서 ConnectionDefName 프로퍼티를 찾아서, 그 값에 앞의 3단계에서 만든 "MASTSQL" 연결 정의를 선택하여 지정한다. 폼 디자이너에서 "Database" 컴포넌트를 더블 클릭하여 FireDAC Connection Editor 창을 연다. FireDAC Connection Editor 창에서 Test 버튼을 클릭한다. 로그인 창이 나타나오 이미 3단계에서 지정해둔 연결 정보가 들어가 있을 것이다. OK를 클릭한다. ("Connection established successfully" 라는 메시지가 나오면 성공한 것이다. 만약 실패해서 에러 메시지가 표시된다면, password등이 잘못되었다는 오류가 나오면, 앞의 3단계로 돌아가서 연결 정의를 다시 정확히 만들어야 한다. 만약 연결이 거부 된다면, 인터베이스 서버가 동작하는 지를 확인해야 한다 (오류 처리 방법 보기) 6단계. 데이터베이스 타입 맵핑 변경 BDE와 FireDAC은 둘다 애플리케이션과 데이터베이스를 서로 연결해 주기 위해 그 사이에 위치하는 계층이다. 이 계층은 데이터베이스 테이블의 컬럼의 데이터 타입을 FireDAC BDE 또는 FireDAC 의 데이터베이스 클라이언트 드라이버에서 지정한 타입으로 가져오고 나서, 이것을 다시 애플리케이션에서 사용할 타입 전환한다. 이때 BDE와 FireDAC의 타입 맵핑이 조금 다르다. FireDAC의 타입 맵핑에 대한 도움말: [DocWiki 번역] 데이터 타입 맵핑 (FireDAC) 위 도움말에 의하면 오라클 데이터베이스의 NUMBER 타입을 FireDAC의 오라클 클라이언트 드라이버에서는 dtFmtBCD으로 취급한다는 것을 알 수 있다. 이와 달리 BDE에서는 오라클 데이터베이스의 NUMBER 타입을 dtInt32나 dtDouble로 취급한다. BDE에서는 DateTime 타입으로 취급하는 것을 FireDAC에서는 DateTimeStamp 타입으로 취급한다는 점도 다르다. 그런데, 이 예제의 기존 소스는 BDE를 사용했었기 때문에, 앞의 2단계에서 BDE 컴포넌트를 모두 FireDAC 컴포넌트로 변경하였다고 해도, 개발자가 작성한 코드는 BDE에서 다루는 데이터 타입에 맞춰져 있을 것이다. 예를 들어, 개발자가 영속 필드를 넣었다면, 이 필드들은 기존에 BDE에서 설정한 데이터 타입을 받도록 되어 있으므로, FireDAC과 BDE에서 서로 다르게 취급하는 데이터타입을 다룰 수 없다. 다행히 FireDAC에는 이런 문제를 유연하게 처리할 수 있도록 데이터 타입 맵핑 규칙을 개발자가 지정할 수 있도록 되어 있다. 우리는 이 단계에서, FireDAC의 유연한 데이터 맵핑을 이용하여, FireDAC의 인터베이스 클라이언트 드라이버에서 지정한 디펄트 데이터의 타입이 기존에 BDE에서 처리하던 타입으로 처리되도록 맵핑 규칙을 넣기로 한다. (참고! 이 맵핑 규칙을 넣지 않아도 된다. 하지만, 그 대신, 애플리케이션에서 기존의 BDE 데이터 타입을 다루게 되어 있는 것을 모두 찾아서 FireDAC 데이터 타입을 다루도록 바꿔야 한다. 예를 들면 모든 영속 필드를 찾아서 모두 지운 다음 다시 추가하여 FireDAC 타입을 다루는 필드가 되게 해야 한다. 따라서, 맵핑 규칙을 넣는 것이 훨씬 편하고 유연한 방법이다.) 이제 Docwiki 원문의 6단계에서 있는 절차를 진행할 텐데, 원문의 안내대로 코드 에디터를 열어서 변경해도 좋지만, 우리는 FireDAC Connection Editor를 사용하여 보다 쉽게 진행하겠다. [진행 절차] 폼 디자이너에서 "Database" 컴포넌트를 더블 클릭하여 FireDAC Connection Editor 창을 연다. FireDAC Connection Editor 창에서 Options 탭을 클릭한다. Options 탭 내용에서 Format Options 아래 Data Mapping Rules 아래에 있는 Ignore inherited rules를 체크한다. 그리드에서 아래 설정을 한다. SourceDataType = dtFmtBCD TargetDataType = dtInt32 PrecMin = 0 PrecMax = 10 ScaleMin = 0 ScaleMax=0 그리드 바로 아래에 있는 Add Rule을 클릭하고, 그리드에서 아래 설정을 한다. SourceDataType = dtFmtBCD TargetDataType = dtDouble 다시 한번 그리드 바로 아래에 있는 Add Rule을 클릭하고, 그리드에서 아래 설정을 한다. SourceDataType = dtDateTimeStamp TargetDataType = dtDateTime FireDAC Connection Editor 창이 아래 그림과 같이 잘 되었다면 OK를 클릭하여 저장한다. 그림, FireDAC의 데이터 타입 맵핑 설정 마지막으로, 폼 디자이너에서 "Database" 컴포넌트가 선택된 상태에서, RAD 스튜디오 왼쪽의 오브젝트 인스펙터에서 FormatOptions 프로퍼티를 확장하고 , 하위 프로퍼티인 StrTrim를 False로 지정한다. (이 프로퍼티의 값을 BDE의 기본값에 맞추기 위함) 7단계. 불필요한 코드 제거: 파라독스 관련 코드 FireDAC은 파라독스 또는 DBase 같은데스크탑 DB를 지원하지 않는다. 따라서 파라독스 데스크탑 DB 관련된 모든 코드를 애플리케이션에서 제거해야 한다. 이 애플리케이션에서 Local Data를 처리하는 코드를 모두 지우자 (또는 주석 처리 하자). (참고: 원하는 코드 블록을 선택하고 Ctrl+/ 단축키를 누르면 선택된 블록의 모든 줄이 주석처리 된다. 이미 주석인 상태였다면 다시 주석이 풀린다) [진행 절차] 프로젝트 관리자에서 DataMod.pas를 더블 클릭하고, 코드 에디터를 열어서 TMastData.UseLocalData 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 프로젝트 관리자에서 Main.pas를 더블 클릭하고, 코드 에디터를 열어서 TMainForm.ViewLocalClick 핸들러 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 단축키 F12를 눌러서, Main.pas를 연 코드 에디터를 폼 디자이너로 전환한 후 스트럭처 뷰에서 아래 그림과 같이 Mainform - MainMenu - View - Local Data를 선택한 후, 오른쪽 클릭 > Edit > Delete (또는 키보드 Delete 키)를 이용하여 메뉴에서 Local Data를 아예 제거한다. (주의! 경고도 없이 제거되고, 되돌리기 어려우므로, 스크럭처 뷰에서 삭제하려는 오브젝트가 정확히 선택되어 있는 지를 먼저 확인해야 한다) 8단계. 인터베이스에 맞게 관련 코드 정비 이제 데이터베이스를 코드에서도 연결할 때에도 새 인터베이스에 연결 할 수 있도록 코드를 변경한다. [진행 절차] 프로젝트 관리자에서 Main.pas를 더블 클릭하고, 코드 에디터를 열어서 TMainForm.ViewRemoteClick 메서드 변경 (Local Interbase)"라는 문자열을 찾아서 "(InterBase)"로 변경한다. 여전히 Main.pas가 코드 에디터를 열린 상태에서, TMainForm.ViewMenuClick 핸들러 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 단축키 F12를 눌러서, Main.pas를 연 코드 에디터를 폼 디자이너로 전환한 후 스트럭처 뷰에서 아래 그림과 같이 Mainform - MainMenu - View를 선택한 후, 오브젝트 인스펙터에서 Events 탭을 선택하고 OnClick 이벤트에 연결된 "ViewMenuClick"을 지운다. (로컬 데이터와 원격 데이터를 구분하지 않으므로 더이상 필요없다) 프로젝트 관리자에서 DataMod.pas를 더블 클릭하고, 코드 에디터를 열어서 TMastData.DataDirectory 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 여전히 DataMod.pas가 코드 에디터에 열린 상태에서, TMastData.UseRemoteData 메서드의 코드를 아래와 같이 변경한다. procedure TMastData.UseRemoteData; var Params: TStringList; begin { ConnectionDef가 있는지 촥인한다. 없으면, 추가한다 } if not FDManager.IsConnectionDef('MASTSQL') then begin Params := TStringList.create; try Params.Values['Protocol'] := 'TCPIP'; Params.Values['Server'] := '127.0.0.1'; Params.Values['DataBase'] := 'C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Data\MASTSQL.GDB'; // 실제로 MastApp.GDB (인터베이스 데이터 파일)이 있는 전체 경로 Params.Values['User_Name'] := 'sysdba'; Params.Values['SQLDialect'] := '3'; Params.Values['CharacterSet'] := 'UTF8'; Params.Values['ExtendedMetadata'] := 'True'; FDManager.AddConnectionDef('MASTSQL', 'IB', Params); finally Params.Free; end; end; SetDatabaseAlias('MASTSQL'); //역자주: 원문에는 MastApp.SetDatabaseConnectionDef('MASTSQL');로 잘못 기재되어 있어서 정정함 end; DocWiki에서는 CustByLastInvQuery에 있는 SQL문에서 키워드인 DESCENDING을 DESC 로 변경하라고 되어 있지만, 지금은 DESCENDING 키워드도 작동하므로, 굳이 바꾸지 않아도 된다. DocWiki 원문에는 이 8단계까지만 설명되어 있다. 하지만, 실행하려고 하면 몇가지 오류가 생길 것이다. RAD 스튜디오에서 메인 메뉴 > Run > Run (또는 단축키 F9)를 사용하여 마이그레이션이 완료된 애플리케이션을 빌드하고 실행한다. 아마 컴파일이 실패하거나, 실행 중에 오류가 발생될 것이다. 이 실습 중에 이슈를 만나면 "예상되는 오류와 처리 방법"에 있는 설명을 참고하여 해소하자. 9단계. 윈도우 11 스타일 적용 사용자는 애플리케이션이 바깥으로 보이는 모습에 민감하게 반응하는 경향이 있다. 클릭 몇번으로 애플리케이션의 모습을 현대식 UI로 바꿀 수 있다면, 하지 않을 이유가 없다. 이제 최신 윈도우 11 다크 스타일을 적용하자. [진행 절차] RAD 스튜디오에서 메인 메뉴 > Project> Options를 클릭한다. Project Options 창에서 Application > Appearance를 선택하고 아래 그림과 같이 Custom Styles와 Default Style 모두 "Windows11 Modern Dark"를 선택한다. (만약 이 스타일이 없다면 겟잇 패키지 매니저를 이용하여 받고 나서 진행한다) RAD 스튜디오에서 메인 메뉴 > Run > Run (또는 단축키 F9)를 사용하여 마이그레이션이 완료된 애플리케이션을 빌드하고 실행한다. BDE와 파라독스를 사용하던 델파이 7으로 되어있든 애플리케이션이 이제 FireDAC과 인터베이스 그리고 델파이 11.0 알렉산드리아로 완전히 옮겨졌다. 예상되는 오류와 처리 방법 당연하지만, 프로젝트는 저마다 다르기 때문에 모두에게 적용되는 규칙 만으로 변환 할 수는 없다. 이 예제에서 발생되는 오류와 이것을 방지 또는 해소하는 방법을 적용하자. 마이그레이션 할 때 생기는 오류에 대응하는 경험을 할 수 있다. [FireDAC][Comp][Clnt]-340. Driver ID is not defined. Set TFDConnection.DriverName or add DriverID to your connection definition 의미: TFDConnection에 연결 정의가 지정되지 않았으니 지정하시오. 발생: 이 오류는 5단계의 가장 첫 진행을 하기위해 프로젝트 관리자에서 DataMod.pas 파일을 더블 클릭해서 열려고 할 때 생길 것이다. 이유/조치: 5단계가 바로 연결 설정이므로 5단계를 마치고 나면 해소된다. [진행 절차] 걱정하지 말자. 이 메시지 창이 더이상 나타나지 않을 때가지 X버튼이나 엔터 키를 여러번 눌러서 창을 닫는다. The EditUpdateError method referenced by Parts.OnupdateError has an incompatible parameter list. Remove the reference? The EditUpdateError method referenced by Cust.OnupdateError has an incompatible parameter list. Remove the reference? 처럼 Parts.OnupdateError 대신 Cust.OnupdateError에서도 같은 메시지가 표시될 것이다. 의미: EditUpdateError 메소드는 Parts.OnupdateError (또는 Cust.OnupdateError) 이벤트를 처리하는 핸들러 메소드로 참조되고 있는데, 이벤트에서 전달하는 파라미터 목록이 서로 달라서 작동하지 않으니, Parts.OnupdateError (또는 Cust.OnupdateError) 이벤트에서 EditUpdateError 메소드를 이벤트 핸들러로 참조하지 않도록 제거할까요? 발생: Run > Run (또는 단축키 F9)로 실행할 때 표시될 것이다. 이유/조치: 위 의미에서 설명한 바와 같다. BDE와 FireDAC에서 데이터 업데이트 오류 처리 이벤트는 "OnUpdateError"로 동일하지만, 이 이벤트에서 전달하는 파라미터는 서로 다르기 때문이다. 일단 No (참조를 제거하지 않음)를 선택하여 그대로 남겨둔다. 그리고 파라미터를 일치시키는 작업을 진행한다. 2단계에서 reFind와 변환 규칙 파일(FireDAC_Migrate_BDE.txt)를 통해 자동 변환하였지만, 아래와 같이 완벽하게 변환되지 않았다. 예제에서 BDE를 자동 변환한 결과(파라미터) FireDAC의 기본 파라미터 DataSet: TDataSet; E: EDatabaseError; UpdateKind: TFDUpdateRequest; var UpdateAction: TFDErrorAction ASender: TDataSet; AException: EFDException; ARow: TFDDatSRow; ARequest: TFDUpdateRequest; var AAction: TFDErrorAction 잘 보면, EDatabaseError 타입이 EFDException 타입으로 변환되지 않았다. ARow: TFDDatSRow; 파라미터는 아예 생성되지 않았다 (reFind는 찾아/바꾸기 도구이므로 이런 한계가 있다) 이제 코드에서 이 부분을 수작업으로 수정하자. [진행 절차] 코드 에디터에서 DataMod.pas 파일을 열고 EditUpdateError 이벤드 핸들러 메소드의 파라미터를 아래와 같이 변경한다. [변경 전] (DataSet: TDataSet; E: EDatabaseError; UpdateKind: TFDUpdateRequest; var UpdateAction: TFDErrorAction); [변경 후] (DataSet: TDataSet; E: EFDException; ARow: TFDDatSRow; UpdateKind: TFDUpdateRequest; var UpdateAction: TFDErrorAction); Interface 부분에서 EditUpdateError 선언의 파라미터 부분을 변경 Implementation 부분에서 TMastData.EditUpdateError 구현의 파라미터 부분을 변경 (원한다면, 다시 변환할 때 자동 처리되도록) 변환 규칙 파일을 보강한다. (ARow: TFDDatSRow; 파라미터를 넣는 것은 조금 부담되지만, 적어도 EDatabaseError를 EFDException로 바꾸는 규칙을 넣을 수는 있다) My_FireDAC_Migrate_BDE.txt(변환 규칙 파일)을 열면, 맨 아래에 #migrate 가 모여있다. 그곳에 아래와 같이 한줄 추가하고 저장한다. (찾아서 바꾸라는 규칙) #migrate EDatabaseError -> EFDException [dcc32 Fatal Error] EDOrders.pas(21): F2613 Unit 'DBLookup' not found. 의미: RAD 스튜디오에 'DBLookup' 유닛이 없다. 발생: Run > Run (또는 단축키 F9)로 실행할 때 컴파일이 실패하면서 메시지 창에 표시될 것이다. 이유/조치: FireDAC에서 이 유닛을 사용하지 않기 때문이다. 우리도 uses 절에서 DBLookup을 제거하자. [진행 절차] 오류 메시지 창에서 OK를 클릭하면, 해당 오류가 있는 코드가 열린다. uses 절에 DBLookup에 빨간색 밑줄이 있을 것이다. DBLookup을 지운다. 다시 단축키 F9를 눌러 실행(Run) 한다. 그러면 DBLookup가 uses에서 사용되는 다른 파일이 열리고 마찬가지고 빨간색 밑줄이 보인다. 이 DBLookup 역시 지운다. (원한다면, 다시 변환할 때 자동 처리되도록) 변환 규칙 파일을 보강한다. My_FireDAC_Migrate_BDE.txt(변환 규칙 파일)을 열면, 맨 위에 #unuse 가 모여있다. 그곳에 아래와 같이 한줄 추가하고 저장한다. (uses에서 DBLookup을 제거하라는 규칙) #migrate EDatabaseError -> EFDException Project mastapp.exe raised exception class EIniFileException with message 'Unable to write to RPTSMITH.CON' [Break] 의미: "RPTSMITH.CON"에 쓰기를 할 수 없어서 IniFileException이 발생했다. 발생: 리포팅 도구에서 사용하는 "RPTSMITH.CON" 파일이 쓰기가 금지된 폴더에 있기 때문이다. 이유/조치: "RPTSMITH.CON" 파일의 위치를 쓰기가 허용되는 폴더로 변경한다. [진행 절차] 메시지 창에서 Break 버튼을 클릭하면, 이슈가 발생하는 코드가 표시된다 (아래 코드이다). RSCon.WriteInteger(MASTSQLSection, TypeKey, SQLTypeVal); 이 코드를 잘 보면 TMainForm.UpdateRSConnect 메소드 안에 있을 텐데, 여기에는 "RPTSMITH.CON" 파일의 전체 경로가 상수(const)로 정의 되어 있다. 이 부분을 변경한다. [변경전] procedure TMainForm.UpdateRSConnect(const Dbpath: string); const TiniFilename = 'RPTSMITH.CON'; {ReportSmith connections file} ... [변경후] procedure TMainForm.UpdateRSConnect(const Dbpath: string); const TiniFilename = 'D:\RPTSMITH.CON'; {D 드라이브가 아니어도 쓰기 가능한 위치를 잡으면 된다: ReportSmith connections file} ... Project mastapp.exe raised exception class EIBNativeException with message '[FireDAC][Phys][IB]Dynamic SQL Error SQL error code = -206 Column unknown A.FULLNAME'. 의미: "[FireDAC][Phys][IB]" 드라이버에서 동적 SQL을 실행하는 도중 오류 발생. "A.FULLNAME"이라는 컬럼을 알 수 없음 발생: 리포팅 도구에서 사용하는 "RPTSMITH.CON" 파일이 쓰기가 금지된 폴더에 있기 때문이다. 이유/조치: DataMod.pas 내의 Orders (TFDTable) 컴퍼넌트에는 "SalesPerson"이라는 영속 필드가 있다. 이 필드는 계산되는 필드라서 실제로 필드가 없는데, BDE 방식으로 lookup 찾기를 하려고 해서 오류가 발생한다. 이 필드를 계산 필드로 지정하자. [진행 절차] 폼 디자이너에서 DataMod.pas를 열고, "Orders" 컴포넌트를 찾아서 (아마 가장 위 왼쪽에 있을 것이다) 더블 클릭한다. 필드 에디터에 목록이 표시되면, 맨 밑에 있는 "salesperson" 필드를 한번 클릭하여 선택한다. 오브젝트 인스펙터에서 Properties 탭을 선택하고, FieldKind 프로퍼티를 찾는다. fkLookup이 지정되어 있을 텐데, fkCalculated로 변경한다. [FireDAC][Phys][IB] Unable to complete network request host "127.0.0.1/3050". Failed to establish a connection. 의미: "[FireDAC][Phys][IB]" 드라이버가 대상 컴퓨터에서 연결하려고 했으나, 거부되어서 연결하지 못했다. 발생: 서버가 작동하지 않거나 원격 연결을 거부하면 발생한다. 이유/조치: 로컬 IP이고와 3050은 인터베이스 기본 PORT로 현재 모두 정확하므로, 인터베이스 서버가 동작하고 있는 지를 확인하자. [진행 절차] 윈도우 버튼 (모니터 가장 아래줄의 가장 왼쪽 아이콘) > 시작 > 프로그램 > Embarcadero InterBase [버전] > InterBase Server Manager를 실행한다. InterBase Server Manager 창에서 인터베이스 서버가 Stopped 상태로 표시된다면, Start 버튼을 클릭하여 서버를 시작한다. 참고한 자료 [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC) https://community.embarcadero.com/blogs/entry/delphi-c-builder-bde-japan BDE 애플리케이션을 FireDAC으로 이전하는 방법에는 "BDE에서 FireDAC으로 이전" 관련 사항이 잘 정리되어 있다.
  4. << 더 많은 엠바카데로 기술백서 보기 스테픈 볼은 15년 이상 영국, 유럽 등에서 다양한 우량 기업들과 많은 작업을 해오며 개발 경험을 쌓아온 IT 전문가입니다. 이 기술백서에는 RAD 스튜디오를 사용하는 조직의 관리자가 알고 있어야 할 수준높고 핵심적인 요점을 정리되어 있습니다. 예를 들어, 소프트웨어 개발 역사의 변화 속에서 RAD스튜디오가 어떻게 발맞춰 왔는 지, 툴과 프레임워크를 어떤 방식으로 새롭게 그리고 지속적으로 발전시켜 왔는지, 최신 개발 방법론과 프로토콜을 어떻게 지원하고 담아 내고 있는 지를 자세히 다루었습니다. 이 기술백서를 무료로 다운로드하기 View full 엠바카데로 기술자료
  5. << 더 많은 엠바카데로 기술백서 보기 이 기술백서 (PDF)를 무료로 다운로드하기 꼼꼼히 모두 읽는 데 걸리는 시간: 약 25분 (총 24쪽) [대상] 누가 이 기술백서를 읽으면 좋은가? CTO 소프트웨어 기술팀의 리더 특히, 델파이 또는 C++빌더로 작성된 시스템과 그 코드를 오랜 기간 관리하고 있는 리더 [이유] 이 기술백서를 읽으면 좋은 이유 시장 트렌드에 대한 이해를 기반으로, 데스크톱과 모바일 모두에 적합한 현실적인 해법이 제시된다. 코딩이 진화해 온 방향을 이해하고, 현재 보유한 코드의 가치를 파악하고 활용하는 방안이 제시된다. 최신 개발 절차와 현장의 관행을 RAD 스튜디오의 프레임워크와 도구에서 어떻게 혁신적으로 반영하는 알 수 있다. 현대화와 재구축을 비교하고 보다 안전한 프로젝트를 계획하는 데 도움이 된다. 모바일 등 멀티-플랫폼 구현 전략에 대한 통찰력을 가질 수 있다. 클라우드 등 다양한 데이터 통합, 로우-코드(Low-Code), RAD, 데브옵스(DevOps) 등 현재와 미래를 위한 방안이 제시된다. 이 기술백서 (PDF)를 무료로 다운로드하기 << 더 많은 엠바카데로 기술백서 보기
  6. 이 문서의 목적 데브기어 마이그레이션 지원 사업(TODO 링크 넣기)을 통해 진행한 현대화 프로젝트 사례(TODO 링크 넣기)를 기록함으로써, 델파이/C++ 현대화 마이그레이션 (TODO 링크 넣기)을 고려하는 개발자가 참고할 수 있도록 한다. 목차 사용 기관 및 프로젝트 소개 현대화 마이그레이션을 계획하게된 동기 마이그레이션 프로젝트 개요 마이그레이션 프로젝트 진행 단계 주요 작업 (및 참고 자료) 코드 변환 BDE를 FireDAC으로 교체 (64비트 윈도우 지원, 배포 편이성 향상, 데이터 처리 성능 향상) 윈도우 10 스타일 적용 (일관성 있고 세련된 현대식 디자인) 사이드바 메뉴 구현 (사용성 향상) 퀵리포트(Quick Report) 업그레이드 (엑셀 내보내기 등 기능 향상) 학생 프로필 사진 DB화 (관리 편이성과 관련 기능 향상) 데이터베이스를 호출하는 모든 SQL 구문을 기록 (보안 감사 능력 향상) 사용 기관 및 프로젝트 소개 사용 기관: 감리교 신학대학교 1887년 설립된 국내최초의 신학교 대상 시스템: 학사 관리 시스템 학부, 대학원, 평생교육원, 행정 등 대학교 업무 전반을 지원하는 종합 전산 프로그램 델파이 3 버전으로 개발된 후 20년 간 유지해 온 시스템 현대화 마이그레이션을 계획하게된 동기 윈도우 10이 보편화 됨에 따라 이에 대한 원활한 지원이 필요 윈도우 10에서 기존 사용자 프로그램의 알수없는 오류 발생 (특히 BDE가 가장 문제임) 품질 향상이 필요 기존 서비스를 모두 제공할 수 있으면서도 디자인, 사용성, 기능, 성능을 향상하고자 함 투자 대비 효과 지속 유지 인력 및 비용 측면에서, 이 시스템은 지난 20년 간 충분히 투자 대비 효과를 실현해 왔으며, 현대화를 통해 장점을 유지 마이그레이션 프로젝트 개요 목표 (와 기대 효과) BDE를 완전히 제거하고 FireDAC으로 교체 (64비트 윈도우 지원, 배포 편이성 향상, 데이터 처리 성능 향상) 윈도우 10 스타일 적용 (일관성 있고 세련된 현대식 디자인) 사이드바 메뉴 구현 (사용성 향상) 퀵리포트(Quick Report) 업그레이드 (엑셀 내보내기 등 기능 향상) 학생 프로필 사진 DB화 (관리 편이성과 관련 기능 향상) 데이터베이스를 호출하는 모든 SQL 구문을 기록 (보안 감사 능력 향상) 개요 기간 : 총 3개월(2016년 5월 ~ 7월) 투입 인원 외부 : 1명(데브기어 컨설턴트 방문 컨설팅 / 상주) 내부 : 1명(담당자) 대상 프로젝트 델파이 프로젝트 : 27개 .pas 파일 : 3,000여개 .dfm 파일 : 3,000여개 델파이 버전 현대화 델파이 개발 환경을 3 버전에서 10.1 베를린 버전으로 이전 조언 또는 팁 현대화 마이그레이션의 프로젝트에서 소스 코드 변환 작업은 가장 기본적이고 가장 많은 부분을 차지한다. 하지만, 프로젝트 계획에 아래 사항을 반영하면, 프로젝트 완료 후 사용자의 만족도는 더 높아진다. 사용자들이 주로 사용하는 화면을 몇개 선정하여 디자인과 기능을 집중 강화한다. 사용자들이 가장 원했던 기능의 우선 순위를 정하고 가장 높은 몇개의 기능 강화에 집중한다. 마이그레이션 프로젝트 진행 단계 이 프로젝트는 데브기어 마이그레이션 프로젝트 절차 - 1.1 버전에 따라 진행되었다. 그 결과, 전체 프로젝트 기간 (3개월) 중 코드 변환 작업 기간은 15% (1~2주) 만으로 충분했다. 나머지 85% 기간 (2.5 개월)은 이슈 해소, 자동화 방안 수립, 테스트, 목표한 향상 작업을 진행했다. 주요 작업 (및 참고 자료) 코드 변환 자동 변환 도구(들) (TODO 자동 변환 도구 소개 링크) 마이그레이션 가이드 문서(TODO 마이그레이션 가이드 소개 링크) BDE를 FireDAC으로 교체 (64비트 윈도우 지원, 배포 편이성 향상, 데이터 처리 성능 향상) BDE (Borland Database Engine) 윈도우 3.1이 사용되던 1995년에 나온 기술 유니코드를 지원하지 않으며 윈도우 10 등 최신 64비트 윈도우에서 "알 수 없는 오류"를 일으킴 프로그램 배포 시 번거로움 (BDE Admin을 별도로 설치해야 함) "작업을 따로 하지 않고 FireDAC으로 교체" 만으로 얻은 효과 배포 간소화: FireDAC은 BDE보다 오라클 클라이언트 배포가 간편 프로그램 배포 시 Oracle thin client 관련 dll 몇개 만 포함하면 됨 [따라하기] FireDAC으로 오라클(Oracle) DB와 연결하기 데이터 처리 성능 향상 FireDAC 성능 비교: BDE, dbGO(ADO), dbExpress, FireDAC FireDAC 주요기능 10가지를 예제와 함께 살펴보기 reFind 도구를 사용하여 BDE에서 FireDAC으로 자동 변환하는 방법 델파이: reFind.exe: 마이그레이션 작업에서 수작업을 줄여주는 도구 C++빌더: (영문) "reFind" 도구를 사용하여 BDE를 FireDAC 으로 마이그레이션 하기 (델파이 10.1 환경에서 설명) 윈도우 10 스타일 적용 (일관성 있고 세련된 현대식 디자인) 델파이에서 프로젝트 옵션 설정 만으로 프로그램의 컨트롤, 테두리, 배경색 등등 모든 화면 요소에 일관성있고 현대적인 디자인을 적용 VCL 스타일을 적용해 1분만에 윈도우 10 최신 룩앤필 적용하기 사이드바 메뉴 구현 (사용성 향상) 델파이에 들어있는 VCL 윈도우 10 컨트롤 중 슬라이드 메뉴를 제공하는 TSplitView를 이용해 업무별 바로가기 기능을 구현 윈도우 10 용 새 VCL UI 컨트롤로 윈도우 10 UI를 손쉽게 적용하기 퀵리포트(Quick Report) 업그레이드 (엑셀 내보내기 등 기능 향상) "작업을 따로 하지 않고 퀵리포트 업그레이드" 만으로 얻은 효과 보고서 내보내기 (저장) 기능 추가 기능 추가 작업: 퀵리포트 보고서를 엑셀로 내보내기 보고서 화면에 엑셀 저장 필터 컴포넌트(TQRXLSXFilt)를 추가 해당 보고서 화면이 많았으므로, 텍스트 에디터의 여러파일 찾기 기능과 치환 기능을 이용해 폼파일(*.dfm)과 소스파일(*.pas)에 컴포넌트를 추가하는 코드 삽입 작업을 자동화 학생 프로필 사진 DB화 (관리 편이성과 관련 기능 향상) 오라클 DB에 사진 테이블 생성하고 BLOB 컬럼을 추가하여 학생 프로필 사진을 관리하도록 하여, 프로그램에서 사진을 표시하기 위해 수행되던 성가신 수작업을 해소함 BLOB 컬럼에 (이미지 등의)데이터 읽고 쓰기 퀵레포트(Quick Report)에 사진 출력하기 데이터베이스를 호출하는 모든 SQL 구문을 기록 (보안 감사 능력 향상) 요구 사항: "DB에 호출하는 모든 SQL 문을 로그로 남긴다." TFDQuery 컴포넌트 (DB에 전달되는 SQL을 담당하는 컴포넌트)를 상속받고, 메소드 덮어쓰기 (Override)를 이용하여 로그 기록 기능을 삽입 그 결과, 이렇게 커스터마이징 된 컴포넌트를 사용하는 모든 SQL은 자동으로 로그를 남기게 됨 (참고자료는 작성 중)
  7. 이 문서의 목적: 마이그레이션을 할 때 수작업을 없애는 도구 중 RAD 스튜디오에 들어있는 reFind.exe를 알고 싶은 사람들이 가장 먼저 찾는 글 애플리케이션 현대화에 대한 관심은 매우 높다. 특히 델파이와 C++빌더의 코드를 현대화 마이그레이션할 때는 코드 대부분을 자동 변환 할 수 있다. 자동화 도구도 여러가지인데, 엠바카데로 MVP인 Oren Aviram이 소개한 델파이 파서 (Delphi Parser) 처럼 수준높은 유료 도구도 있고, 지금 소개하는 reFind.exe처럼 강력하고 간단한 명령줄 유틸리티도 있다. reFind 사용법 [DocWiki 번역] reFind.exe, Perl 정규 표현식을 사용하는 찾기 바꾸기 유틸리티 reFind 요약 reFind는 RAD 스튜디오를 설치하면 사용할 수 있다. 설치하면, RAD 스튜디오 설치 경로의 bin 폴더에는 RAD 스튜디오 실행 파일 뿐만 아니라 reFind.exe도 들어있다. 이 경로는 PATH 환경 변수에 자동 등록되므로, 명령줄에서 따로 경로를 지정하지 않고 reFind 라고만 입력하면 실행된다. reFind는 지정된 "변경 대상"에 지정된 텍스트 "변환 규칙"을 적용한다. (예: reFind *.pas *.dfm /X:FireDAC_Migrate_BDE.txt ) 변환 규칙은 명령줄에서 일일이 규칙을 지정해도 되지만, 위 예의 FireDAC_Migrate_BDE.txt처럼 규칙을 담은 별도의 텍스트 파일을 지정하는 것이여러모로 좋다. reFind는 몇가지 변환 규칙 파일이 함께 제공된다. [공용 문서]\Embarcadero\Studio\22.0*\Samples\Object Pascal\Database\FireDAC\Tool\reFind 아래에 마이그레이션 목적별 폴더에 있다. *이때 22.0은 RAD 스튜디오 11.0 알렉산드리아 기준이며, 버전에 따라 숫자가 달라진다 AnyDAC, BDE, DbExpress을 FireDAC으로 변환하는 규칙 파일과 FireDAC을 (XE7에서 XE8으로) 버전업하는 규칙 파일이 들어 있다. 여기를 클릭하면 깃허브에 있는 FireDAC_Migrate_BDE.txt을 열어 볼 수 있다. 변환 규칙 파일을 열어보면 규칙을 쉽게 이해할 수 있다 (복사 후 필요한 부분을 변경하여 재사용하기도 좋다) 활용 예시 reFind.exe를 이용해 BDE 프로젝트를 FireDAC으로 마이그레이션 따라하기 참고 이미지 그림1. reFind용 변환 규칙 파일과 데모 프로젝트 Sample이 있는 기본 경로(그림 맨위의 경로)와 각 목적별 폴더 (선택된 폴더는 BDE 마이그레이션 Sample 폴더) 그림2. FireDAC_Migrate_BDE.txt 파일에 담긴 변환 규칙 (이 파일은 위 그림1에서 선택된 폴더 안에 있다.
  8. Top 10 How-To’s: Modernization (원문 작성: Hagop Panosian | 2022년 2월 13일)을 번역한 글 (번역일: 2022년 2월 18일) Application modernization, also known as legacy modernization, involves updating existing software and its features to benefit from technological advances and maintain performance. Modernization can involve making apps cloud-native to lower cost and increase scalability and agility, and to enable remote teams to maintain and update it. Besides improving performance, modernization extends the lifespan of any application as performance requirements dictate change. 애플리케이션 현대화(또는 레거시 현대화)는 사용 중인 소프트웨어와 그 기능을 업데이트함으로써 발전된 기술의 장점을 취함과 동시에 성능 유지하는 작업이다. 앱을 클라우드-네이티브하도록 만들어서 비용을 절감하고, 확장성과 민첩성 높이고, 팀이 원격에서 유지하고 업데이트할 수 있도록 하는 것도 현대화라고 할 수 있다. 단순한 성능 향상 이외에도, 현대화는 성능 요구 사항에 의해 변화를 해야하는 상황에서도 애플리케이션의 수명을 연장한다. Here are 10 great How-To’s on modernization. 현대화를 어떻게 할 것인지를 알려주는 훌륭한 10 방법 10 가지를 여기에 모아두었다. 1. 윈도우 11 용으로 앱을 현대화하는 방법 5가지 (5 Ultimate Ways To Modernize Your Apps For Windows 11) Delphi offers a modern, robust & enterprise-grade UI developer environment with Visual Component Library (VCL) for Windows only and FireMonkey (FMX) for cross-platform development. Delphi VCL offers the latest features and modern UI controls for your Windows app development. 델파이는 현대적이고, 견고하고, 엔터프라이즈 수준의 UI 개발 환경을 제공하기 위해 윈도우 전용인 VCL(비주얼 컴포넌트 라이브러리)과 크로스-플랫폼 개발용인 FMX(파이어몽키)를 제공한다. 델파이 VCL을 활용하면 최신 기능과 현대적인 UI 컨트롤을 당신의 윈도우 앱 개발에 적용할 수 있다. 자세히 보기: https://welcome.devgear.co.kr/topic/155-윈도우-11-용으로-앱을-현대화하는-방법-5가지 2. RAD 서버를 활용하여 현대화할 때 알아야 할 모든 것 (Everything You Need To Modernize With RAD Server) In the modern age, isn’t it true to say we are completely surrounded and immersed in the technology of diverse forms? Much of it now is entirely cloud-based, but there’s still a substantial proportion that employs a mix of both cloud and more physical hardware computing resources. However, the common thread among all of these technologies, even the most recent ones, is the certainty of them becoming obsolete. After all, even though all technologies evolve rapidly, they are eventually replaced by something which is either an evolutionary step thanks to advances in technological offerings or because new and more potent ways of providing a service or solving a problem emerge. 현대 사회에서 우리는 기술에 둘러싸여서 파묻혀있고 그 기술의 형태도 다양하다. 전적으로 클라우드에 기반을 둔 기술이 대부분이긴 하지만 여전히 상당 부분은 클라우드와 물리적인 하드웨어 컴퓨팅 장비가 함께 섞여 있기도 하다. 하지만 지금 아무리 최신 기술이어도 결국에는 반드시 더 최신 기술에 의해 밀려나고 시대에 뒤쳐지게 되는 때가 온다는 사실 하나는 분명하다. 모든 기술이 각각 급격하게 발전하지만, 결국 발전된 기술 덕분에 더 발전한 단계에 의해서 교체되거나 또는 문제 해결이나 서비스 제공 방식 자체를 바꾸는 새롭고 강력한 그 무언가가 나온다. 자세히 보기: https://welcome.devgear.co.kr/topic/163-rad-서버를-활용하여-현대화할-때-알아야-할-모든-것 3. 레거시 닷넷 프레임워크를 델파이로 마이그레이션하기 (A Guide To Migrating From Legacy .NET Framework To Delphi) The application migration process can be easy or tedious, depending on the technology you are migrating. Moreover, migrating legacy projects to a new development environment might take a vast amount of time because of new software-from-scratch – re-engineering. 애플리케이션 마이그레이션 과정은 쉬울 수도 있고 지루할 수도 있다. 이것은 마이그레이션 대상 기술이 무엇인가에 달려있다. 게다가, 레거시 프로젝트를 새 개발 환경으로 마이그레이션하려면 엄청난 시간이 소요된다. 그 이유는 소프트웨어를 처음부터 새로 만드는 리엔지니어링 작업이기 때문이다. Application migration is a broad term in the technological realm. Application migration can involve moving the app to a different cloud service provider. It can also be a migration from one technology to another, such as.NET to Delphi FireMonkey. It is possible to migrate from legacy to a completely new up-to-date technology from the ground up. Furthermore, this can be database migration and platform migration, but with the use of IDE software, it will be simple and fast to migrate. 애플리케이션 마이그레이션이라는 용어는 기술 분야에서 넓은 의미로 사용된다. 다른 클라우드 서비스로 앱을 옮기는 것을 의미하기도 하고, 다른 기술로 이전하기(예를 들어, 닷넷에서 델파이 파이어몽키로 이전 등)를 의미하기도 한다. 레거시 애플리케이션을 버리고, 전혀 새로운 기술을 도입하여 바닥부터 아예 새로 만들거나, 심지어 데이터베이스를 다른 플랫폼으로 옮길 때에도 마이그레이션이라는 용어를 사용한다. 하지만, IDE 소프트웨어를 사용하면 마이그레이션이 간단하고 빠르게 진행될 수 있다. 자세히 보기: https://devgear.co.kr/archives/5201 4. 플루언트 디자인 시스템으로 애플리케이션 현대화하기 (Modernize Your Applications With The Fluent Design System) Just recently there have been some great webinars and posts on how to modernize your applications. We’ve gathered together a collection of the most recent ones which focus on Microsoft’s gorgeous Fluent Design System. 얼마 전에 애플리케이션 현대화 방법을 다루는 다양한 기술 기고와 웨비나가 있었다. 여기에는 그 중에서도 매력적인 마이크로소프트 플루언트 디자인 시스템(Fluent Design System)에 중점을 둔 최신 기술 자료들을 모아서 정리했다. Visitors to the Desktop First Conference were able to hear directly from Microsoft Engineer Matteo Pagani. In this video Matteo describes Fluent UI in particular from Microsoft’s perspective and how it can help add that superb look and really modernize your applications. 데스크탑 퍼스트 컨퍼런스(Desktop First Conference) 참석자는 마이크로소프트 엔지니어인 마테오 파가니(Matteo Pagani)가 플루언트 UI를 직접 설명하는 세션을 들을 수 있었다. 아래 비디오에서는 마테오가 플루언트 UI를 마이크로소프트의 관점에서 설명하고, 플루언트 UI를 사용하여 어떻게 애플리케이션을 멋지게 현대화하고 월등한 모습을 추가하는 지를 알려준다. 자세히 보기: https://devgear.co.kr/archives/4534 5. 멀티-디바이스 파이어몽키 앱을 현대화하기 - 사용하기 쉬운 카드 뷰 마법사 템플릿 (Modernize Your Multi-Device Fire Monkey App Easy To Use Card View Wizard Layout Template) User experience is the key thing to be considered while building a modern Multi-Device application. Lots of layout templates were available in GetIt Package Manager to design responsive, ultra-modern, cross-platform FireMonkey applications. This post helps to understand one of the FireMonkey Layout templates, the Card View Wizard. 사용자 경험 (UX, User Experience)은 현대적인 멀티-디바이스 애플리케이션을 구축할 때 중요하게 고려해야 한다. 겟잇 패키지 매니저 (GetIt Package Manager) 안에는 레이아웃 템플릿들이 많이 들어 있어서 무척 현대적이고, 반응형인 디자인을 크로스 플랫폼 파이어몽키 애플리케이션에 적용할 수 있다. 이 글은 파이어몽키 레이아웃 템플릿 중에서 카드 뷰 마법사 (Card View Wizard)를 설명한다. Card View Layout Template is a Fire Monkey template that incorporates a number of card view pages that can be navigated forward and backward, though one would use this as an in-app tutorial. 카드 뷰 레이아웃 템플릿은 파이어몽키 템플릿 중 하나이다. 이것은 카드 뷰 페이지를 여러개 넣고 각 페이지 간에 앞뒤로 이동할 수 있도록 하는 화면 템플릿이다. 이 템플릿은 튜토리얼 화면을 구현할 때 활용되기도 있다. 자세히 보기: https://welcome.devgear.co.kr/topic/319-멀티-디바이스-파이어몽키-앱을-현대화하기-사용하기-쉬운-카드-뷰-마법사-템플릿/ 6. FastReport를 사용하는 델파이/C++ 앱을 빠르게 윈도우의 High DPI 설정에 맞춰 마이그레이션하고 현대화하기 (Quickly Migrate and Modernize Your Delphi/C++ Apps Using FastReport With Windows High DPI Setup) Display panel manufacturers have packed an increasing number of pixels into each unit of physical space on their panels resulted in the dots per inch (DPI) of modern display panels. In the past, most displays had 96 pixels per linear inch of physical space (96 DPI); in 2017, displays with nearly 300 DPI or higher are readily available. Variety of monitors like SD, Full HD, 4K Ultra HD, 8K Ultra HD in the market. 디스플레이 패널의 물리적 공간 당 픽셀 수는 점점 더 많아지고 있어서 DPI (인치 당 도트수)가 높은 모니터가 많아졌다. 예전에는 디스플레이 대부분이 96 DPI 즉, 1 인치 당 96 픽셀이 들어있었지만, 2017년에는 300 DPI 또는 그 이상인 패널들도 꽤 사용되기 시작했다. 이제 시중에는 SD, Full HD, 4K 울트라 HD, 8K 울트라 HD 등 다양한 모니터가있다. We have laptops, desktops with small screens, and without display scale factor/DPI changes it’s very hard to use it and this can be even more complicated when talking about Full HD, 4K Ultra HD, 8K Ultra HD. Our application should be able to handle them. You cannot be sure what every user prefers. 우리가 사용하는 노트북 또는 화면이 작은 데스크탑에서 화면 배율 팩터/DPI를 변경할 수 없다면 사용하기가 매우 어렵다. 더 나아가 Full HD, 4K 울트라 HD, 8K 울트라 HD 모니터에서는 훨씬 더 복잡해진다. 우리가 제공하는 애플리케이션은 이 모든 것을 다룰 수 있어야 한다. 어떤 사용자가 어떤 사양의 모니터를 사용하고 싶어할 지를 모르기 때문이다. 자세히 보기: https://welcome.devgear.co.kr/topic/157-fastreport를-사용하는-델파이c-앱을-빠르게-윈도우의-high-dpi-설정에-맞춰-마이그레이션하고-현대화하기 7. WINAPI, COM, SHELLAPI, WINRT와 윈도우 VCL 애플리케이션의 통합 & 현대화 방법 (Learn How To Modernize And Integrate WinAPI, COM, ShellAPI, And WinRT Into Your Windows VCL Applications) In this webinar, learn how to access all the APIs on Windows 10 from RAD Studio, Delphi, and C++Builder. 이 웨비나를 통해, 윈도우 10의 모든 API들을 RAD스튜디오, 델파이, C++빌더에서 접근하는 방법을 배울 수 있다. 주제 (Overview) Traditional Core APIs Shell Integration WinRT and more 전통적인 Core API(들) Shell 통합 WinRT 기타 등등 자세히 보기: https://devgear.co.kr/archives/4607 8. 오래된 레거시 델파이, C++ 애플리케이션을 최신 스타일의 초고속 앱으로 마이그레이션하기 (A RoadMap To Migrate Your Legacy Delphi And C++ Applications To The Latest Blazing-Fast Version) Thinking to migrate your Legacy Delphi/C++Builder Applications to the Latest Delphi? Curious to know the things to do and tips to do effortless migrations ? This post will guide you through the considerations for successful migrations. 오래된 레거시 델파이/C++빌더 애플리케이션을 최신 버전으로 마이그레이션하려는 생각이 있는가? 무슨 작업을 해야하고 크게 힘들이지 않고 마이그레이션하는 팁이 궁금한가? 이 글에서는 성공적인 마이그레이션을 위해 고려할 사항들을 따라가면서 안내한다. Things to consider : 고려해야 할 것(들): Unicode Compatibility – Unicode support was added to RAD Studio, Delphi and C++Builder starting with the 2009 version. Many migration resources were developed at that time but are still useful today if upgrading from a pre-Unicode (2007 or earlier) version. Unicode Statistics Tool on your Delphi application and check if any Unicode changes are needed.This Unicode Statistics Tool will assist you in collecting useful statistics for the time and effort needed to migrate your Delphi applications to Unicode. More Resources for Unicode. 유니코드 호환성 - 델파이, C++빌더, RAD 스튜디오에서 유니코드를 지원하기 시작한 해는 2009년이다. 그 당시에 많은 마이그레이션 자료들이 만들어졌는데, 지금도 여전히 유니코드 이전인 2007 버전 또는 그 이전 버전에서 마이그레이션할 때 유용하게 활용된다. 유니코드 분석 도구(Unicode Statistics Tool)를 이용해 델파이 애플리케이션을 분석하면 유니코드 변경이 필요한 부분이 있는지를 점검할 수 있다. 이 유니코드 통계 도구는 델파이 애플리케이션을 유니코드로 마이그레이션할 때 시간과 노력이 얼마 필요한 지에 대한 유용한 통계를 수집할 수 있도록 도와준다. 유니코드용 리소스에 대한 더 많은 내용은... 자세히 보기: https://devgear.co.kr/archives/3630 9. 윈도우 앱을 적시에 예산 범위 안에서 현대화하는 방법 (This Is How To Modernize Your Apps On Time And Under Budget) We know that technology is progressing at a rapid pace. The software systems built five years ago using the then-modern technologies might not be relevant today due to outdated versions. Every software that aims to scale and provide effective services to its consumers must be open to modernization. Modernization of software systems enhances their longevity and keeps them relevant to the technological age in which they are operating. 우리는 기술이 빠르게 발전하고 있다는 것을 잘 안다. 5년 전에 구축한 소프트웨어 시스템은 당시에 통용되던 기술을 사용했음에도 불구하고 오늘날에는 버전이 오래되어 적합하지 않은 경우가 생긴다. 확장 가능하면서 효과적인 고객 서비스를 제공하기를 목표로 하는 소프트웨어라면 현대화에 개방적이어야 한다. 현대화는 소프트웨어 시스템의 수명을 강화하고 시대에 적합한 기술을 유지하도록 한다. 자세히 보기: https://welcome.devgear.co.kr/topic/325-윈도우-앱을-적시에-예산-범위-안에서-현대화하는-방법/ 10. 엠바카데로 DEV-C++: 성공적인 현대화 작업을 위한 윈도우 C++ IDE (Embarcadero Dev C++: Successfully Modernizing A Popular Windows C++ IDE) In October of 2020, Embarcadero sponsored and released a new fork version 6.0 of Dev C++ with improvements that included an updated GCC 9.2.0 compiler with support for Windows 10 and C++17/C++20, high DPI, UTF8 files and improved icons, and a dark theme option. An earlier update in July featured an upgrade of the Dev C++ code to Delphi 10.4. 2020년 10월, 엠바카데로는 Dev C++의 새 버전인 6.0 버전을 후원하고 출시했다. 여기에는 GCC 9.2.0 컴파일러 업데이트, 윈도우 10 지원, C++17/C++20, high DPI, UTF8 파일, 아이콘 개선, 다크 테마 선택 등이 포함되었다. 그 이전인 7월 업데이트에서는 Dev C++ 코드를 델파이 10.4로 업그레이드하는 작업을 먼저 마쳤었다. 자세히 보기: https://devgear.co.kr/archives/3885
  9. "This Is How To Modernize Your Apps On Time And Under Budget" (원문 작성자: Emad Bin Abid, 작성일: 2021년 9월 14일)을 번역한 글 We know that technology is progressing at a rapid pace. The software systems built five years ago using the then-modern technologies might not be relevant today due to outdated versions. Every software that aims to scale and provide effective services to its consumers must be open to modernization. Modernization of software systems enhances their longevity and keeps them relevant to the technological age in which they are operating. 우리는 기술이 빠르게 발전하고 있다는 것을 잘 안다. 5년 전에 구축한 소프트웨어 시스템은 당시에 통용되던 기술을 사용했음에도 불구하고 오늘날에는 버전이 오래되어 적합하지 않은 경우가 생긴다. 확장 가능하면서 효과적인 고객 서비스를 제공하기를 목표로 하는 소프트웨어라면 현대화에 개방적이어야 한다. 현대화는 소프트웨어 시스템의 수명을 강화하고 시대에 적합한 기술을 유지하도록 한다. This thought process is equally valuable to desktop apps. Application stakeholders have an imperative to recognize the need to modernize desktop software in a timely manner to efficiently continue providing services that remain competitive in the face of competition; embracing new technologies, advancements in techniques and user interface design and even fashions for UX paradigms which wax and wane. In this blog post, we’ll look at how you can use Windows application development to modernize your Windows apps on time and within your budget. 이점은 데스크탑 앱에서도 똑같이 중요하다. 애플리케이션 이해관계자에게는 데스크탑 소프트웨어를 현대화해야 할 필요성을 적시에 인식해야 할 사명이 있다. 그래야 서비스 제공을 효율적으로 지속할 수 있고 치열한 시장에서 경쟁력을 유지할 수 있다. 새 기술, 발전된 기술, UI (사용자 인터페이스) 디자인에서부터 유행하고 사라지는 UX (사용자 경험) 패러다임 유행까지 수용해야 한다. 이 글은 윈도우 애플리케이션 개발도구를 사용하여 당신의 윈도우 앱을 적시에 예산 범위 안에서 어떻게 현대화하는 지 그 방법을 살펴본다. 내 델파이 앱을 현대화하는 방법은? (How can I modernize my Delphi app?) Embarcadero Technologies published a whitepaper titled “Successfully Modernizing A Popular Windows C++ IDE” that discusses the aspects and strategies used to modernize DevC++ IDE. This migration and up-gradation activity is an extremely important and valuable learning resource for the teams that plan on app migration. 엠바카데로는 “인기있는 윈도우 C++ IDE를 성공적으로 현대화하기 (Successfully Modernizing A Popular Windows C++ IDE)”라는 제목의 기술백서에서 DevC++ IDE를 엠바카데로에서 현대화할 때 사용한 관점과 전략을 설명한다. 여기에서 다루는 마이그레이션 업그레이드 활동은 애플리케이션을 마이그레이션하려고 계획하는 팀에게 너무나도 중요하고 배울 것이 많은 귀중한 학습 자료이다. The upgrade of DevC++ IDE was done in two phases. The first phase aimed at making the least possible changes to make the application compile with the newer version of Delphi. After that, the second phase involved changes such as compiler upgrade, Unicode support, and full support for Windows 10 with Embarcadero DevC++ 6.0. DevC++ IDE는 두단계로 나누어 업그레이드 되었다. 첫번째 단계에서는 새 델파이 버전에서 컴파일이 되는 것을 목표로 하고 변경은 최소화 했다. 그리고 나서 두번째 단계에서는 컴파일러 업그레이드, 유니코드 지원, 윈도우 10 완전 지원을 DevC++ IDE에 반영했다. The case study mentions that there were some important third-party upgrades as well. The most important of all were SynEdit, FastMM4, AStyle, and TDM-GCC. The Embarcadero team identified the components to be upgraded and that is indeed one of the essential and crucial steps towards any third-party migration. DevC++ 사례 연구에서는 몇가지 중요한 써드-파티들에 대한 업그레이드도 언급한다. 가장 중요한 것으로는 SynEdit, FastMM4, AStyle, TDM-GCC가 있었다. 엠바카데로 마이그레이션 팀은 업그레이드가 필요한 컴포넌트를 찾아냈는데, 이 과정은 써드-파티를 마이그레이션하기 위해 실제로 꼭 필요하고 가장 중요한 단계이다. The upgrade, as a result, provided a new and modern interface along with a faster and smoother Windows development in C++. 업그레이드 결과, 새롭고 현대적인 인터페이스를 갖추고, 더 빠르고 원활하게 윈도우 개발을 할 수 있는 C++ IDE가 되었다. Just like the DevC++ IDE upgrade, you can also follow similar steps to migrate your Delphi application for a smoother and better developer and user experience. DevC++ IDE 업그레이드 사례와 비슷하게 단계를 진행하면, 당신의 델파이 앱이 더 원활하고 더 좋은 UX (사용자 경험)을 제공할 수 있도록 마이그레이션 할 수 있다. Read the Successfully Modernizing A Popular Windows C++ IDE whitepaper to explore more about the DevC++ IDE upgrade. “인기있는 윈도우 C++ IDE를 성공적으로 현대화하기" 기술 백서를 보면, DevC++ IDE 업그레이드에 대해 더 자세히 알 수 있다. 마이그레이션 및 업그레이드를 위해 꼭 필요한 요소는 무엇인가? (What are some of the essential elements for migration and up-gradation?) If you are considering modernizing your legacy Delphi desktop application, you might think of the following essential migration and modernization strategies, to begin with. 레거시 델파이 데스크탑 애플리케이션을 현대화하려는 생각이 있다면, 마이그레이션과 현대화를 위한 아래의 필수 전략(들)부터 시작하기 바란다. 유니코드가 왜 중요한가? (Why was Unicode important?) Prior to the mid 2000s, Unicode was not often considered a technology of enough importance to include in most systems available on the market. With a more widespread adoption and availability of internet connectivity support for character sets which were able to render a broad range of languages became a pressing issue. People wanted their programs to be displaying text in the language they spoke and read rather than English which had become the Internet’s Lingua Franca (an ironic phrase if you think about it). Unicode allowed, for example, Russians to read and use Cyrillic characters or Japanese users to choose to display screens using Kanji should they choose to do so. 유니코드는, 2000년대 중반 이전까지, 시장에 있는 시스템 대부분에 꼭 들어가야 할 만큼 중요한 기술 이라고 간주되지는 못하는 경향이 있었다. 인터넷 연결이 더 널리 채택되고 사용됨에 따라 언어를 폭넓게 표현할 수 있는 문자 세트 지원이 널리 퍼지게 되고, 유니코드는 시급한 문제가 되었다. 사람들은 프로그램에 있는 텍스트가 더이상 영어만이 아니라 자신들이 말하고 읽는 언어로 표현되기를 원했다 -인터넷 세상에서 영어가 공통 언어(Lingua Franca)가 된 현실을 생각하면 좀 아이러니이기도 하다. 유니코드는 예를 들어 러시아 사람들은 키릴 문자(Cyrillic)를 사용하여 읽고 사용하고, 일본 사용자들은 일본 한자(Kanji)로 표현되는 화면을 선택하는 것을 가능하게 한다. Unicode support was added to Delphi, C++ Builder, and RAD Studio in 2009. There are multiple resources that help with the migration and upgrading of legacy Delphi applications to a newer version which supports Unicode changes. 델파이, C++빌더, RAD 스튜디오에서 유니코드를 지원하기 시작한 해는 2009년이다. 레거시 델파이 애플리케이션을 유니코드를 지원하는 새 버전으로 마이그레이션 업그레이드할 때 도움을 받을 수 있는 자료는 많다. For more information about Unicode resources, you may visit the Unicode section of our Migration and Upgrade Center resource. 유니코드에 대한 자세한 내용은 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 유니코드 섹션에 있다. 64비트 마이그레이션이 중요한가? (Is 64bit migration important?) When dealing with legacy applications built for 32-bit operating systems you might think that modernizing your applications for a 64-bit operating system will be a troublesome and labor-intensive task to do. In many cases, can be true; but not with Delphi and RAD Studio. 32비트 운영 체제용으로 구축된 레거시 애플리케이션을 다룰 때, 당신은 아마 64비트 운영 체제용으로 현대화하기는 번거롭고 많은 수고가 들어가는 작업이 될 것이라고 생각할 수 있다. 많은 경우에 이것은 사실이지만, 델파이와 RAD 스튜디오에서는 그렇지 않다. Beginning the emergence of Delphi XE2 and continuing to this day, it is now extremely simple to generate 64bit applications using the same codebase as that for 32bit applications. This migration process is significantly easier compared to other languages that require changes to variable and record/structure types to bridge the gap and resolve differences between the 32 and 64 bit platforms. Delphi XE2 출시 이후 지금까지, 델파이에서 32비트 애플리케이션을 만든 동일한 코드를 그대로 사용하여 64비트 애플리케이션을 만드는 것은 너무 간단하다. 다른 언어에서는 32비트와 64비트 플랫폼의 격차를 메우고 차이점을 해결하기 위해 변수, 레코드/구조체(structure) 등을 바꿔야 하지만, 이와 달리 델파이에서는 64비트 마이그레이션 작업이 현격하게 더 쉽다. For more information about 64bit migration, you may visit the 64bit migration section of our Migration and Upgrade Center resource. 64비트 마이그레이션에 대한 자세한 내용은 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 64비트 마이그레이션 섹션에 있다. 데이터베이스와 미들웨어를 현대화에 적합하게 맞추는 방법은? (How does database and middleware fit into modernization?) Database migration is probably one of the most crucial elements for evolving software applications. The teams that look for database migration and optimization opportunities remain successful in the long run as they can more easily adapt to newer market requirements for the most critical part of application experience: data. 계속 진화하는 소프트웨어가 되기 위해 가장 중요한 요소 중 하나를 꼽자면 아마도 데이터베이스 마이그레이션일 것이다. 데이터베이스를 마이그레이션하고 최적화할 수 있는 기회를 찾는 팀은 장기적으로 성공을 지켜갈 수 있다. 그 이유는 애플리케이션 경험 중에 가장 중요한 부분인 데이터를 시장의 새로워진 요구 사항에 맞게 적응하는 것이 더 쉽기 때문이다. The older-style desktop databases, Borland Database Engine (BDE) and dbExpress have been removed from Delphi installation in favor of a new, feature-packed and vastly more powerful FireDAC. The migration is simple, easy, and straightforward. BDE (볼랜드 데이터베이스 엔진)과 dbExpress는 오래된-스타일인 데스크탑 데이터베이스이고, 이제는 델파이 설치에서도 빠져있다. 그 대신 기능이 풍부하고 훨씬 더 강력한 새 엔진인 FireDAC이 들어갔다. FireDAC으로 마이그레이션하기는 쉽고 간단하고 명료하다. For more information about database and middleware, you may visit the database and middleware section of our Migration and Upgrade Center resource. 데이터베이스 및 미들웨어에 대한 자세한 내용은 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 데이터베이스 및 미들웨어 섹션에 있다. 앱을 현대화할 때 도움이 되는 써드-파티 컴포넌트는 무엇이 있는가? (What 3rd party components are available to help modernize our apps?) If your legacy Delphi application is using 3rd party components and libraries, they need to be rebuilt for the current Delphi version. If you already have the source code of third-party components, then this becomes easier as you will just need to rebuild your application. 당신의 레거시 델파이 애플리케이션이 써드-파티에서 제공한 컴포넌트와 라이브러리를 사용하고 있다면, 델파이 현재 버전에서 이것들을 다시 빌드해야 한다. 써드-파티 컴포넌트의 소스 코드를 가지고 있다면, 다시 빌드를 하기만 하면 되므로 더 쉽다. On the other hand, if your legacy application is using third-party resources without the availability of the original source code then you will have to use updated versions of those components that are compatible with newer Delphi. 반면에, 사용하고 있는 써드-파티의 원본 소스 코드를 가지고 있지 않다면, 새 델파이 버전과 호환될 수 있는 업데이트 버전을 찾아서 사용해야만 한다. For more information about 3rd party components, you may visit the 3rd party components section of our Migration and Upgrade Center resource. 써드-파티 컴포넌트에 대한 더 많은 정보는 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 써드-파티 컴포넌트 섹션에 있다. Here is an interesting video that talks about modernizing your legacy Delphi projects in great detail. 아래 비디오에서는 레거시 델파이 프로젝트를 매우 상세하게 다루고 있다. Also, this recent webinar about automation, workflows, and modernization involving Embarcadero MVPs Glenn Dufke and Wagner Landgraf can also help you figure migration and modernization strategies for your legacy Delphi projects. 또한, 자동화, 워크 플로우, 현대화에 대해서 엠바카데로 MVP인 Glenn Dufke와 Wagner Landgraf가 진행한 최근 웨비나는 당신의 레거시 델파이를 대상으로 마이그레이션 현대화 전략을 그려보는 데 도움이 된다. 델파이 애플리케이션 현대화 아이디어 몇가지를 꼽아 본다면? (What are a few modernization ideas for a Delphi application?) In-app payments and ads – Delphi has components for this Data connection security with SSL Create and deploy icons for your app App activation and deactivation events – a standard Event mechanism in modern Delphi versions Business analytics Multithreading for better responsiveness – recent version of Delphi have really great libraries and classes which make threading a much easier task than in years past Read more about interesting and cool modernization ideas here. 인-앱 결제, 인-앱 광고 - 델파이에는 이를 위한 컴포넌트가 있다 SSL을 통한 데이터 연결 보안 앱 아이콘(들)을 만들어서 배포 앱 활성화 및 비활성화 이벤트 - 최신 델파이 버전에는 표준 이벤트 메커니즘이 있다 비즈니스 분석 멀티-쓰레드를 통해 반응 능력 향상 - 최신 델파이 버전은 쓰레드를 훨씬 더 쉽게 다룰 수 있는 멋진 라이브러리와 클래스가 있다 그 외에도 흥미롭고 멋진 현대화 아이디어(들)이 있다.
  10. Anbarasan가 2020년 12월 7일에 기고한 Modernize Your Multi-Device Fire Monkey App Easy To Use Card View Wizard Layout Template을 번역한 글 사용자 경험 (UX, User Experience)는 현대식 멀티-디바이스 애플리케이션을 구축할 때 중요하게 고려해야 한다. 겟잇 패키지 매니저 (GetIt Package Manager) 안에는 많은 레이아웃 템플릿들이 들어 있어서 디자인이 무척 현대적이고, 반응형인 디자인을 크로스 플랫폼 파이어몽키 애플리케이션에 적용할 수 있다. 이 글은 파이어몽키 레이아웃 템플릿 중에서 카드 뷰 마법사 (Card View Wizard)를 설명한다. 카드 뷰 레이아웃 템플릿은 파이어몽키 템플릿 중 하나이다. 이것은 카드 뷰 페이지를 여러개 넣고 각 페이지 간에 앞뒤로 이동할 수 있도록 하는 화면 템플릿이다. 이 템플릿은 튜토리얼 화면을 구현할 때 활용되기도 있다. 설치 방법: 이 템플릿은 "IDE 플러그인"이므로 겟잇 패키지 매니저 (GetIt Package Manager)에서 손쉽게 설치할 수 있다. 설치 단계는 다음과 같다. RAD 스튜디오 IDE에서 >Tools > GetIt Package Manager > Categories에서 Sample Projects를 선택 > Card View Wizard 1.0 by Embercadero Technologies 를 찾아서 Install 버튼을 클릭. 라이선스 정책을 읽고 Agree All을 클릭. ‘Requires a restart of RAD studio at the end of the process. Do you want to proceed?' 라는 대화 창이 표시되면 yes and continue를 클릭. 그러면, 해당 플러그인이 다운로드 된다. 설치가 되면 Restart now를 클릭. 겟잇 - 카드 뷰 마법사 1.0 카드 뷰 마법사 예제 앱에 구현되어있는 핵심 코드 설명: 카드 뷰 마법사 예제 앱에는 TTabControl이 하나가 들어있고, TabItem들의 목록이 들어있다. 각 TabItem 안에는 TFrameCard의 인스턴스가 들어있다. TFrameCard는 uCardFrame.pas 파일에 정의되어 있으며, 자신의 CardTitle과 CardText를 설정할 수 있고, 카드 레이아웃을 구성할 수 있다. procedure TMainForm.FormCreate(Sender: TObject); begin {$IFDEF FIRSTSET} // first set FrameCard1.SetCardTitle(WIZARD_TITLE_1); FrameCard1.SetCardText(WIZARD_TEXT_1); FrameCard1.ConfigureCard(TCardButton.Inner, TCardBGImage.Inner, TCardLayout.TextImage); FrameCard2.SetCardTitle(WIZARD_TITLE_2); FrameCard2.SetCardText(WIZARD_TEXT_2); FrameCard2.ConfigureCard(TCardButton.Inner, TCardBGImage.Inner, TCardLayout.TextImage); FrameCard3.SetCardTitle(WIZARD_TITLE_3); FrameCard3.SetCardText(WIZARD_TEXT_3); FrameCard3.ConfigureCard(TCardButton.Inner, TCardBGImage.Inner, TCardLayout.TextImage); FrameCard4.SetCardTitle(WIZARD_TITLE_4); FrameCard4.SetCardText(WIZARD_TEXT_4); FrameCard4.SetNextButtonText(WIZARD_NEXT_BUTTON_4); FrameCard4.ConfigureCard(TCardButton.Inner, TCardBGImage.Inner, TCardLayout.TextImage); {$ENDIF} WizardTabControlChange(Sender); end; WizardTabControlChange 이벤트가 발생하면, 해당되는 카드의 제목과 배경 이미지가 화면에 표시된다. procedure TMainForm.WizardTabControlChange(Sender: TObject); var I: Integer; begin for I := 0 to WizardTabControl.TabCount-1 do begin if TTabItem(WizardTabControl.Tabs[I]).TagObject is TRectangle then begin TButton(TTabItem(WizardTabControl.Tabs[I]).TagObject).Visible := False; end; end; if WizardTabControl.TabIndex>-1 then if WizardTabControl.ActiveTab.TagObject is TRectangle then begin TButton(WizardTabControl.ActiveTab.TagObject).Visible := True; end; end; 카드 뷰 마법사 1.0 데모 이 카드 뷰 마법사 예제는 델파이 코딩을 배우기에도 매우 좋다. 이외에도 좋은 예제 애플리케이션들이 많다. 모두 살펴보는 것도 잊지말자: "예제 프로젝트" 목록 보기
  11. 실제 브라질의 운송회사에서 20년된 델파이 프로그램을 현대식 마이크로서비스 아키텍처로 전환한 사례를 바탕으로 진행한 세미나 자료입니다. 당면과제 브라질에서 가장 큰 로컬 운송회사에서 델파이6로 구축한 시스템을 15년간 회사의 매우 중요한 파트에서 운용해 왔다. 그간 회사는 크게 성장했지만, 클라이언트/서버 구조인 이 시스템으로는 더 이상 회사의 성장에 맞추어 확장하기 어려운 상황에 이르렀다. 시행착오 2014년 이후 회사는 두 번에 걸쳐 델파이가 아닌 다른 기술로 완전히 교체하려는 시도를 했다. 한 번은 SAP로, 다른 한 번은 Java(자바)로 시도했으나, 두 프로젝트 모두 실패했다. 그 기간 동안 기존 시스템은 20살이 되었고, 세번째는 더 이상 실패하면 안 되는 다급한 상황이 되었다. 해결 방안 및 결과 2019년 새롭게 구축한 시스템은 유연하면서도 확장성있고, 견고하며, 비용까지 절감해주고 있다. 현대식 시스템이며, 마이크로서비스 아키텍처가 적용되었다. 도커(Docker), 쿠버네티스(Kubernetes), 데브옵스(DevOps) 원칙이 반영되었다. 그리고 무엇보다 이 새 시스템은 델파이(Delphi)로 구축되었다. 이 영상을 통해 알 수 있는 내용 왜, SAP와 Java 두 번의 재구축 프로젝트가 실패했을까? 어떻게, 델파이 개발자 단 8명으로 구성된 팀만으로 외부 훨씬 더 큰 규모의 개발팀보다 빠르고 획기적인 결과를 만들어 낼 수 있었을까? 왜, 전환 프로젝트 비용이 시트릭스(Citrix) 비용 절감만으로도 충당되었을까? (다른 시스템에서는 못했는데) 이 새로운 시스템은 유연하게 확장되고, 빠르게 개발될 수 있었다. 아키텍처는 어떻게 되어 있을까? 이 영상을 통해 기존 시스템의 가치를 인식하고, 기존 시스템에서 마이그레이션 하는 것이 완전히 새로 구축하는 것보다 어떻게 그리고 얼마나 더 빠르고 더 안전한지를 확인할 수 있다. 시스템 아키텍처 해당 세미나에서 소개한 아키텍처를 조금 구체적으로 그려보면 다음과 같다. 이해하기 쉽도록 계층을 구분하고, 각 계층의 역할과 서비스 구성, 서비스들의 역할을 설명했다. 해당 세미나의 아키텍처 중 시스템 아키텍처를 제외한 개발 도구와 배포 환경은 다음과 같다. 사용된 기술 Access Layer 클라이언트 요청을 분산하고, 요청에 대한 서비스로 연결하는 게이트웨이 역할 Reverse Proxy & Load Balancer : REST API의 경로에 따라 구현된 마이크로 서비스와 연결 및 요청 분산 HTTPS : 보안 프로토콜 지원 Traefik : HTTP 리버스 프록시 및 로드 밸런서. REST API 수신 시 설정에 따라 하위 마이크로 서비스와 연결 HAProxy : 소프트웨어 로드 밸런서, 네트워크 스위치에서 제공하는 L4, L7 기능 및 로드 밸런서 기능 제공 참고> Naver D2 - L4/L7 스위치의 대안, 오픈소스 로드 밸런서 HAProxy Certbot : HTTPS 지원 Let's Encrypt : HTTPS 지원 Business Layer 운용에 필요한 기능을 마이크로 서비스 기반으로 제공. 핵심적인 비지니스 로직이 포함되며 다른 서비스들과 연동해 운용 RAD 서버 : REST API 서비스를 손쉽게 개발할 수 있는 턴키방식 미들웨어 서버. 델파이, C++빌더로 개발 Persistance Layer 서비스 운용에 필요한 데이터를 제공하는 역할 RDBMS, NoSQL : 마이크로 서비스는 서비스 분리와 함께 데이터 분리가 가능하다. 서비스 필요에 따라 RDBMS와 NoSQL 사용가능 Data Grid(IMDG: In Memory Data Grid) : 일종의 메모리 클러스터. 여러 서버와 메모리를 연결 수십기가의 메모리 저장소를 만들고, 애플리케이션 서버에서 접근해 사용하는 방식 Message Queue : 비동기 요청 처리. 클라이언트 요청을 메시지 큐에 넣고 응답 후 다른 서비스에서 메시지 큐의 내용을 처리 Oracle - RDBMS PostgreSQL - RDBMS MongoDB - NoSQL / BigData Redis - 메모리 기반 데이터 그리드. 서비스간 공유할 데이터를 메모리 기반으로 빠르게 조회 및 저장 RabbitMQ - 오픈소스 메시지 브로커. 서비스간 메시지를 큐잉하고 변경 시 이벤트를 받아 처리 가능 Analystics Layer 서비스 운용 시 발생하는 로그를 수집 분석하고, 서비스를 모니터링 및 장애 감지 역할 Log gathering / Analysis : 서비스들로 부터 로그를 수집, 저장, 분석 해 시각적으로 제공. Elastic(ELK) Stack 사용됨 Monitoring : 네트워크 및 서버 모니터링 및 장애 감지 및 알림 Logstash - 실시간 파이프라인 기능을 가진 데이터 수집 엔진 ElasticSearch - 분산형 RESTful 검색 및 분석 엔진 Kibana - ElasticSearch에 저장된 데이터를 검색 및 분석, 시각화 플랫폼 Zabbix - 네트쿼크 서비스, 서버 등을 감시, 추적 및 장애 알림 Grafana - 데이터를 시각화하여 효과적으로 데이터기반 의사결정 및 모니터링 가능 Prometheus - 이벤트 모니터링 및 경고. HTTP 풀 모델 사용이 특징 참고> 오픈소스 모니터링 시스템 prometheus #1 DevOps/Dev tooling RAD Studio Ranorex docker Sonar Gitlab Jenkins Deployment environment Ansible Kubernetes Ubuntu Rancher docker 다시보기
  12. << DelphiCon 2021 목록으로 이동 원본 비디오(YouTube) 보기 (30 min) DelphiCon 의 2021 시리즈 중, Leaving Delphi 7 - A Success Migration Case - Dion Carlos Mai & Rafael Pereira (30 min) 의 한글 요약본입니다. 20년이 넘었고, 델파이 7로 운영하던 대형 시스템을 델파이 10으로 마이그레이션한 프로젝트를 정리한 내용을 공유합니다. 발표자 Rafael은 이 소매점 시스템 제공자인 Stone Co의 개발자입니다. 목차 회사 및 프로젝트 소개 현대화 마이그레이션을 계획하게 된 동기와 결과 마이그레이션 프로젝트의 개요 마이그레이션 프로젝트의 진행 단계 1단계 (분석 단계) 2단계 (실행 단계) 3단계 (검증 단계) 4단계 (배포 단계) 프로젝트를 통해 배운 점 참고 자료 그림 자료 회사 및 프로젝트 소개 회사 소개: Stone Co Linx: 뉴욕 증시에 상장된 브라질의 소프트웨어 기업. 브라질의 소매점 소프트웨어 시장에서 점유율 45.6% Stone: 뉴욕 증시에 상장된 브라질의 Stone Co.의 핀테크 기업. 지불 관리 도구와 유연한 금융 상품을 제공 Stone Co: 2012년에 시작하여 브라질 전역을 커버하고 있다. 2020년 11월, Stone Co는 Linx를 인수 대상 시스템 소개: Linx Big 20년이 넘은 소매점 소프트웨어. 약국에서 주로 사용 현재 3,000개가 넘는 고객사와, 5,000개가 넘는 소매점에서 사용 중 (2개 이상을 사용하는 점포가 많으므로, 배포된 소프트웨어는 훨씬 더 많음) 현대화 마이그레이션을 계획하게 된 동기와 결과 윈도우10은 2021년 10월 현재 전세계 데스크탑 점유율의 80%이상을 차지하고 있고 계속 증가하는 추세임 (관련 통계 보기) 윈도우 10에 집중해야 하는 상황 윈도우 10의 새 운영체제 기능을 충분히 지원하는 IDE 기능이 필요 윈도우 10에 맞는 더 좋은 시각적인 UI가 필요 (그림 참조: 예전 화면과 새 화면 비교) 스타일, 대시보드, 그래프, 메뉴 등 더 풍부한 화면을 제공하여 외관상 완전히 다른 새 소프트웨어로 보임 (그림 참조: 새 화면) 델파이 10에 내장된 컴포넌트와 스타일만 사용하여 화면 개발 새 UI를 구현하기 위한 코드는 새로 작성 하지만, 모든 클래스와 소스 코드는 예전 델파이 7과 거의 같음 스레드가 필요 요즘 소프트웨어는 API 통합이 많다. 델파이 7에서도 스레드를 구현할 수 있다. 하지만, 델파이 7은 소프트웨어를 개발하기에 여전히 매우 훌륭한 도구이지만, 20년 전에 나온 오래된 버전이다. 델파이 최신 버전을 사용하지 않으면, API 통합을 모두 지원하거나 JSON 직렬화하기 등 새 기술을 반영하기가 어렵다. 기타 개선 델파이 10의 장점을 가질 수 있게 됨: 64비트 지원, 윈도우 10 지원, FireDAC으로 데이터 연결, 다른 운영체제에서 접근 등등 델파이 10 시애틀을 선택한 이유 당시 우리 개발자 대부분이 사용할 수 있는 라이선스를 이미 가지고 있었기 때문 마이그레이션 프로젝트의 개요 목표 델파이 7에서 델파이 10 시애틀로 이전 마리아DB 10.4.13과 MySQL 8.0.21 지원 개요 기간: 총 7 개월 투입 인원 외부: 3명 (아쿠아소프트 개발자, 마이그레이션에만 집중) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 마이그레이션 대상 (소매점 관리 시스템)의 규모 델파이 프로젝트: 65개 모듈: 194개 .PAS 파일: 6,000개 .DFM 파일: 2,000개 코드 줄 수: 2백만줄 써드 파티 컴포넌트 세트: 23가지 마이그레이션 프로젝트의 진행 단계 총 4단계로 나누고, 앞 단계 완료 시 다음 단계를 진행: 분석, 실행, 검증, 배포 1단계 (분석 단계) 개요 기간: 3.5개월 투입 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 2명 (개발자 1명, QA 1명) 목표 측정 / 식별 / 문서화 델파이 10으로 마이그레이션이 끼칠 영향 새 데이터베이스와의 호환성 프로젝트로 인해 달라지는 점과 문제점 변경으로 인해 발생될 것으로 예상되는 문제 해소 자동 변환 도구 개발 작업 내용 외부 인력 (아쿠아소프트) 합류 전환할 컴포넌트를 3가지로 나누어 분석하고 대비 버전의 수명이 다한 컴포넌트 마이그레이션 시 문제가 많고, 작업도 많이 해야 하는 것들임 이 프로젝트에서 많이 사용될 컴포넌트 프로젝트에서 사용되는 비중이 크기 때문에, 그 만큼 프로젝트에 끼치는 영향도 큰 것들임 소스코드가 없는 컴포넌트 매우 이상하게 작동할 수 있고 마이그레이션 작업을 까다롭게 만들기 때문에 주의해야 할 것들임 예: Zeos (2003년부터 사용한 오픈 소스 데이터베이스 컴포넌트) [에러가 발생되는 코드] QPrincipal.FieldByName('datapre').AsDateTime :=now; 짐작하겠지만, 상업용 시스템에서 매우 많이 사용되는 코드이며, 모두 수정해야 하므로, 에러 해소 작업이 많다. 델파이 버전 간의 차이와 충돌을 식별하고 해소 유니코드 (영향 받는 dll이 있는 지까지도 파악할 필요가 있음) 자동 변환 도구 개발 ("마이그레이션 찾아 바꾸기"라고 이름 지음) 소스 변환 자동화 도구 개발을 이 분석 단계 안에서 완성 (그림 참조: 소스 변환 자동화 도구와 변환 결과) Zeos에서 UniDAC으로 마이그레이션하는 도구 마법사가 발생시키는 버그 수정 자동화 사용되는 모든 컴포넌트 마이그레이션 자동화 (많은 컴포넌트에서 일부 프로퍼티가 변경되었기 때문) 델파이 10과 델파이 7과의 차이로 인해 필요한 코드 변환 자동화 "모든" 소스를 변환할 수 있는 "맞춤" 도구 완성 소스 코드 동기화 소스 코드 동기화는 매우 중요! 마이그레이션 프로젝트 진행 중에도 전체 배포까지 완료되기 전까지는 전환해야 할 코드가 계속 변하기 때문이다. 분석 단계가 진행되는 중에도 내부 개발자 20명은 여전히 기존 코드나 화면을 변경하고 새 기능을 추가한다. 즉, 마이그레이션 대상인 델파이 7 소스 코드가 계속 변한다. 2단계 (실행 단계) 모든 코드를 변경하는 단계 개요 기간: 2일 (사전 준비가 완료되었으므로 가능) 참여 인원 외부: 1명 (아쿠아소프트 개발자) 내부: 1명 (개발자) 목표 코드 "전체"를 자동 변환 도구를 사용하여 델파이 7에서 델파이 10으로 변경 작업 내용 진행 전 실행 단계 직전에 기존 프로그램 변경을 금지 1일차 자동 변환 도구를 사용하여 변환 개발자 2명이 6시간 만에 완료 총 4,678개 소스 파일을 변경 2일차 컴포넌트 적합성, 데이터베이스 적합성이 파악된다. 모든 변경이 계획대로 되었는 지를 검증 3단계 (검증 단계) 개요 기간: 2.5 개월 참여 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 목표 모든 델파이 프로젝트와 모든 작동을 검증, 버그 파악 및 해소 팀 구성 개발자 (버그 픽스 전담) 그룹 개발자 (일반) 그룹 QA 그룹 델파이 프로젝트 별 책임자 그룹 작업 내용 검증 단계 시작 전 (즉, 실행 단계인 2일 간) 델파이 10 사용자 교육 이유: 모든 개발자는 이 검증 단계 시작을 기준으로, 그 이후에는 델파이 10만 사용 (그 이전에는 델파이 7만 사용) 내용: 델파이 10 사용법, 새 기능, 검증 단계 및 이후 유지 보수 시 작업 절차 결과: 개발자 등 모든 참여 인원이 검증 단계에 참여할 준비를 완료 검증 단계 시작 직후 버그가 매우 많이 보고되었고, 버그의 대부분을 신속하게 해소했다. 자동 변환 도구를 이용했기 때문이다. 버그 발생: 변환 도구에 버그가 있으면, 변환된 시스템에도 버그가 생긴다. 버그 해소: 변환 도구의 버그를 수정하면, 변환된 시스템의 해당 버그도 해소된다. 앞 단계에서 접근할 수 없었던 것들에서 발생되는 버그를 QA들이 찾아냈는데, 이런 검증은 도움이 되었다. 검증 결과 모든 기능 중 97% 검증 완료 나머지 3%는 외부 API라서 내부 테스트 불가 이유: 실제 운영 환경에서 테스트할 수 밖에 없는 외부 데이터) 대책: 외부 API 목록 작성과 운영 환경에서 완벽한 테스트를 할 수 있도록 미리 준비 (매우 중요) 이 단계에서는 버그 해소 작업에 큰 수고가 들지 않았다. 버그 등록이 지속적으로 줄어듬 종료 시점에 모두 해소 4단계 (배포 단계) RC (Release Candidate, 출시 후보) 버전 배포, 합격 판정 후 전체 배포 개요 기간: 5주 참여인원 내부: 2명 (QA 1명, 개발자 1명) 고객: 선정된 고객사 104곳 (사용 점포 브라질 18개 주에 있는 소매점에 총 184개 배포) 브라질 소매점 특성 상, "모든 지역"에서 문제가 없는 지 검증해야 함 (브라질은 각 주마다 세금과 규제가 다름) 작업 내용 4-1 단계: RC(Release Candidate, 출시 후보) 버전 배포 준비 RC (Release Candidate, 출시 후보) 버전 합격 기준 설정 중요도 0 (우회 해소 방법이 없는) 버그: 최대 5개 이내 중요도 1 (우회 해소 방법이 1가지인) 버그: 최대 20개 이내 위 기준 중 하나라도 통과하지 못하면 이 RC 버전은 불합격으로 판정하고 즉시 배포를 중단하기로 함 RC 버전 최대한 완벽한 버전을 준비 RC 버전을 배포 고객 "모든" 기능이 검증될 수 있도록 "세심하게" 고객을 선정 (고객마다 사용하는 기능, 방식, 환경이 제각각일 수 있다) 4-2 단계: RC 버전 배포 및 판정 배포 후 보고된 버그의 갯수 (모두 14개, 그림 참조: 버그 발견 및 해소 추이) 중요도 0: 1개 (기준치인 5개 이내, 통과) 중요도 1: 4개 (기준치인 20개 이내, 통과) 중요도 2: 7개 중요도 3: 2개 기준에 의거 성공 판정 4-3 단계: 전체 배포 100% 델파이 10으로 전환 완료 해소해야 할 마이그레이션 관련 버그가 없음 처음 계획한 데이터베이스를 지원 확인 현재, 99% 고객이 업데이트된 시스템을 사용 프로젝트를 통해 배운 점 분석 단계 (자동 변환 도구 개발 포함)에서 QA는 한두명만 참여하면 된다. 이 단계에서 QA가 많고, 버그를 많이 찾아낸다고 해서 무조건 좋은 것은 아니다. QA는 자동 변환 도구의 결과를 테스트 주의! 이 단계에 QA를 많이 투입할 것인지 아닌 지에 대한 결정은 프로젝트에 따라 다를 수 있으므로 매우 조심해야 한다. 써드-파티 컴포넌트는 분석이 매우 잘 되어야 한다. 심지어 프로젝트 전부터 미리 충분히 파악해야 한다. 마이그레이션 프로젝트가 시작되면 써드-파티 컴포넌트에 대한 작업과 부담이 많기 때문이다. 마이그레이션을 자동화하는 "맞춤" 변환 도구를 개발한다. 프로젝트가 많고 규모가 커도 처리할 수 있다. 검증 단계는 매우 중요하다. 충분한 테스트 시간이 필요하다. 검증 단계를 거치지 않고 바로 배포로 넘어가면 운영 시 문제가 많을 수 있다. 그러면 경영진은 이 프로젝트가 실패했다고 판정할 수 있다. 그러면, 검증 단계 하나의 실패로 끝나지 않는다. (우리는 검증 단계에 충분한 시간을 계획하였기 때문에 문제가 없었다) 프로젝트 중 소통이 매우 중요하다. 모든 팀원들이 진행 중인 작업을 항상 업데이트할 수 있는 절차와 환경이 구축되어야 한다. 그래야, 서로 다른 사람의 작업에 어떤 영향을 주거나 받는 지를 미리 파악할 수 있다. 프로젝트 평가 기준을 구체적이고 명확히 정하고 모니터링해야 한다. 계속 앞으로 갈 것인지 아니면 중단해야 하는 지에 대한 기준을 정하는 것은 매우 중요하다. 마이그레이션 목적이 분명해야 한다. 프로젝트 진행 중에 목적이 변경되면, 3-4개월 이상 지체될 수 있다. 목적과 목표가 분명해야 계획된 일정을 준수할 수 있다. 델파이 7은 매우 훌륭한 도구이지만, 거기에 머물고 있을 수 만은 없다. 머물러 있고 싶어도, 우리가 앞으로 가야할 시간은 언젠가 오게되어 있다. 20년 전에 출시된 델파이 7로는 지금 시점에서 필요한 기술 모두를 지원하지 못한다. 시스템 운영에 크리티컬할 기술에서도 그렇다. 구버전에서 벗어나서 최신 기술에 맞춰가자. 참고 자료 What's New in Delphi 10 Seattle https://www.embarcadero.com/products/delphi/whats-new Embarcadero Update Center https://www.embarcadero.com/rad-in-action/migration-upgrade-center Desktop Windows Version Market Share Worldwide http://gs.statcounter.com/windows-version-market-share/desktop/worldwide/#monthly-201509-202110 Delphi Unicode: https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf 그림 자료 마이그레이션 전과 후의 UI 비교: 로그인 화면 새 UI에서 사용자 테마 선택 지원: 설정 화면 새 UI에서 사용자 테마 선택 지원: 다크 테마 적용 시 화면 마이그레이션 전과 후의 UI 비교: 일반 화면 새 UI에서 대시보드 구현 새 UI에서 실시간 그래프 구현1 새 UI에서 실시간 그래프 구현2 "맞춤" 자동 변환 도구 예시: 써드 파티 컴포넌트의 경우 프로퍼티 변환이 필요함 3단계 (검증 단계)의 버그 발견 및 해소 추이 << DelphiCon 2021 목록으로 이동
  13. << DelphiCon 2021 목록으로 이동 원본 비디오(YouTube) 보기 (30 min) DelphiCon 의 2021 시리즈 중, Leaving Delphi 7 - A Success Migration Case - Dion Carlos Mai & Rafael Pereira (30 min) 의 한글 요약본입니다. 20년이 넘었고, 델파이 7로 운영하던 대형 시스템을 델파이 10으로 마이그레이션한 프로젝트를 정리한 내용을 공유합니다. 발표자 Rafael은 이 소매점 시스템 제공자인 Stone Co의 개발자입니다. 목차 회사 및 프로젝트 소개 현대화 마이그레이션을 계획하게 된 동기와 결과 마이그레이션 프로젝트의 개요 마이그레이션 프로젝트의 진행 단계 1단계 (분석 단계) 2단계 (실행 단계) 3단계 (검증 단계) 4단계 (배포 단계) 프로젝트를 통해 배운 점 참고 자료 그림 자료 회사 및 프로젝트 소개 회사 소개: Stone Co Linx: 뉴욕 증시에 상장된 브라질의 소프트웨어 기업. 브라질의 소매점 소프트웨어 시장에서 점유율 45.6% Stone: 뉴욕 증시에 상장된 브라질의 Stone Co.의 핀테크 기업. 지불 관리 도구와 유연한 금융 상품을 제공 Stone Co: 2012년에 시작하여 브라질 전역을 커버하고 있다. 2020년 11월, Stone Co는 Linx를 인수 대상 시스템 소개: Linx Big 20년이 넘은 소매점 소프트웨어. 약국에서 주로 사용 현재 3,000개가 넘는 고객사와, 5,000개가 넘는 소매점에서 사용 중 (2개 이상을 사용하는 점포가 많으므로, 배포된 소프트웨어는 훨씬 더 많음) 현대화 마이그레이션을 계획하게 된 동기와 결과 윈도우10은 2021년 10월 현재 전세계 데스크탑 점유율의 80%이상을 차지하고 있고 계속 증가하는 추세임 (관련 통계 보기) 윈도우 10에 집중해야 하는 상황 윈도우 10의 새 운영체제 기능을 충분히 지원하는 IDE 기능이 필요 윈도우 10에 맞는 더 좋은 시각적인 UI가 필요 (그림 참조: 예전 화면과 새 화면 비교) 스타일, 대시보드, 그래프, 메뉴 등 더 풍부한 화면을 제공하여 외관상 완전히 다른 새 소프트웨어로 보임 (그림 참조: 새 화면) 델파이 10에 내장된 컴포넌트와 스타일만 사용하여 화면 개발 새 UI를 구현하기 위한 코드는 새로 작성 하지만, 모든 클래스와 소스 코드는 예전 델파이 7과 거의 같음 스레드가 필요 요즘 소프트웨어는 API 통합이 많다. 델파이 7에서도 스레드를 구현할 수 있다. 하지만, 델파이 7은 소프트웨어를 개발하기에 여전히 매우 훌륭한 도구이지만, 20년 전에 나온 오래된 버전이다. 델파이 최신 버전을 사용하지 않으면, API 통합을 모두 지원하거나 JSON 직렬화하기 등 새 기술을 반영하기가 어렵다. 기타 개선 델파이 10의 장점을 가질 수 있게 됨: 64비트 지원, 윈도우 10 지원, FireDAC으로 데이터 연결, 다른 운영체제에서 접근 등등 델파이 10 시애틀을 선택한 이유 당시 우리 개발자 대부분이 사용할 수 있는 라이선스를 이미 가지고 있었기 때문 마이그레이션 프로젝트의 개요 목표 델파이 7에서 델파이 10 시애틀로 이전 마리아DB 10.4.13과 MySQL 8.0.21 지원 개요 기간: 총 7 개월 투입 인원 외부: 3명 (아쿠아소프트 개발자, 마이그레이션에만 집중) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 마이그레이션 대상 (소매점 관리 시스템)의 규모 델파이 프로젝트: 65개 모듈: 194개 .PAS 파일: 6,000개 .DFM 파일: 2,000개 코드 줄 수: 2백만줄 써드 파티 컴포넌트 세트: 23가지 마이그레이션 프로젝트의 진행 단계 총 4단계로 나누고, 앞 단계 완료 시 다음 단계를 진행: 분석, 실행, 검증, 배포 1단계 (분석 단계) 개요 기간: 3.5개월 투입 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 2명 (개발자 1명, QA 1명) 목표 측정 / 식별 / 문서화 델파이 10으로 마이그레이션이 끼칠 영향 새 데이터베이스와의 호환성 프로젝트로 인해 달라지는 점과 문제점 변경으로 인해 발생될 것으로 예상되는 문제 해소 자동 변환 도구 개발 작업 내용 외부 인력 (아쿠아소프트) 합류 전환할 컴포넌트를 3가지로 나누어 분석하고 대비 버전의 수명이 다한 컴포넌트 마이그레이션 시 문제가 많고, 작업도 많이 해야 하는 것들임 이 프로젝트에서 많이 사용될 컴포넌트 프로젝트에서 사용되는 비중이 크기 때문에, 그 만큼 프로젝트에 끼치는 영향도 큰 것들임 소스코드가 없는 컴포넌트 매우 이상하게 작동할 수 있고 마이그레이션 작업을 까다롭게 만들기 때문에 주의해야 할 것들임 예: Zeos (2003년부터 사용한 오픈 소스 데이터베이스 컴포넌트) [에러가 발생되는 코드] QPrincipal.FieldByName('datapre').AsDateTime :=now; 짐작하겠지만, 상업용 시스템에서 매우 많이 사용되는 코드이며, 모두 수정해야 하므로, 에러 해소 작업이 많다. 델파이 버전 간의 차이와 충돌을 식별하고 해소 유니코드 (영향 받는 dll이 있는 지까지도 파악할 필요가 있음) 자동 변환 도구 개발 ("마이그레이션 찾아 바꾸기"라고 이름 지음) 소스 변환 자동화 도구 개발을 이 분석 단계 안에서 완성 (그림 참조: 소스 변환 자동화 도구와 변환 결과) Zeos에서 UniDAC으로 마이그레이션하는 도구 마법사가 발생시키는 버그 수정 자동화 사용되는 모든 컴포넌트 마이그레이션 자동화 (많은 컴포넌트에서 일부 프로퍼티가 변경되었기 때문) 델파이 10과 델파이 7과의 차이로 인해 필요한 코드 변환 자동화 "모든" 소스를 변환할 수 있는 "맞춤" 도구 완성 소스 코드 동기화 소스 코드 동기화는 매우 중요! 마이그레이션 프로젝트 진행 중에도 전체 배포까지 완료되기 전까지는 전환해야 할 코드가 계속 변하기 때문이다. 분석 단계가 진행되는 중에도 내부 개발자 20명은 여전히 기존 코드나 화면을 변경하고 새 기능을 추가한다. 즉, 마이그레이션 대상인 델파이 7 소스 코드가 계속 변한다. 2단계 (실행 단계) 모든 코드를 변경하는 단계 개요 기간: 2일 (사전 준비가 완료되었으므로 가능) 참여 인원 외부: 1명 (아쿠아소프트 개발자) 내부: 1명 (개발자) 목표 코드 "전체"를 자동 변환 도구를 사용하여 델파이 7에서 델파이 10으로 변경 작업 내용 진행 전 실행 단계 직전에 기존 프로그램 변경을 금지 1일차 자동 변환 도구를 사용하여 변환 개발자 2명이 6시간 만에 완료 총 4,678개 소스 파일을 변경 2일차 컴포넌트 적합성, 데이터베이스 적합성이 파악된다. 모든 변경이 계획대로 되었는 지를 검증 3단계 (검증 단계) 개요 기간: 2.5 개월 참여 인원 외부: 3명 (아쿠아소프트 개발자) 내부: 22명 (개발자, QA, 델파이 프로젝트 별 책임자) 목표 모든 델파이 프로젝트와 모든 작동을 검증, 버그 파악 및 해소 팀 구성 개발자 (버그 픽스 전담) 그룹 개발자 (일반) 그룹 QA 그룹 델파이 프로젝트 별 책임자 그룹 작업 내용 검증 단계 시작 전 (즉, 실행 단계인 2일 간) 델파이 10 사용자 교육 이유: 모든 개발자는 이 검증 단계 시작을 기준으로, 그 이후에는 델파이 10만 사용 (그 이전에는 델파이 7만 사용) 내용: 델파이 10 사용법, 새 기능, 검증 단계 및 이후 유지 보수 시 작업 절차 결과: 개발자 등 모든 참여 인원이 검증 단계에 참여할 준비를 완료 검증 단계 시작 직후 버그가 매우 많이 보고되었고, 버그의 대부분을 신속하게 해소했다. 자동 변환 도구를 이용했기 때문이다. 버그 발생: 변환 도구에 버그가 있으면, 변환된 시스템에도 버그가 생긴다. 버그 해소: 변환 도구의 버그를 수정하면, 변환된 시스템의 해당 버그도 해소된다. 앞 단계에서 접근할 수 없었던 것들에서 발생되는 버그를 QA들이 찾아냈는데, 이런 검증은 도움이 되었다. 검증 결과 모든 기능 중 97% 검증 완료 나머지 3%는 외부 API라서 내부 테스트 불가 이유: 실제 운영 환경에서 테스트할 수 밖에 없는 외부 데이터) 대책: 외부 API 목록 작성과 운영 환경에서 완벽한 테스트를 할 수 있도록 미리 준비 (매우 중요) 이 단계에서는 버그 해소 작업에 큰 수고가 들지 않았다. 버그 등록이 지속적으로 줄어듬 종료 시점에 모두 해소 4단계 (배포 단계) RC (Release Candidate, 출시 후보) 버전 배포, 합격 판정 후 전체 배포 개요 기간: 5주 참여인원 내부: 2명 (QA 1명, 개발자 1명) 고객: 선정된 고객사 104곳 (사용 점포 브라질 18개 주에 있는 소매점에 총 184개 배포) 브라질 소매점 특성 상, "모든 지역"에서 문제가 없는 지 검증해야 함 (브라질은 각 주마다 세금과 규제가 다름) 작업 내용 4-1 단계: RC(Release Candidate, 출시 후보) 버전 배포 준비 RC (Release Candidate, 출시 후보) 버전 합격 기준 설정 중요도 0 (우회 해소 방법이 없는) 버그: 최대 5개 이내 중요도 1 (우회 해소 방법이 1가지인) 버그: 최대 20개 이내 위 기준 중 하나라도 통과하지 못하면 이 RC 버전은 불합격으로 판정하고 즉시 배포를 중단하기로 함 RC 버전 최대한 완벽한 버전을 준비 RC 버전을 배포 고객 "모든" 기능이 검증될 수 있도록 "세심하게" 고객을 선정 (고객마다 사용하는 기능, 방식, 환경이 제각각일 수 있다) 4-2 단계: RC 버전 배포 및 판정 배포 후 보고된 버그의 갯수 (모두 14개, 그림 참조: 버그 발견 및 해소 추이) 중요도 0: 1개 (기준치인 5개 이내, 통과) 중요도 1: 4개 (기준치인 20개 이내, 통과) 중요도 2: 7개 중요도 3: 2개 기준에 의거 성공 판정 4-3 단계: 전체 배포 100% 델파이 10으로 전환 완료 해소해야 할 마이그레이션 관련 버그가 없음 처음 계획한 데이터베이스를 지원 확인 현재, 99% 고객이 업데이트된 시스템을 사용 프로젝트를 통해 배운 점 분석 단계 (자동 변환 도구 개발 포함)에서 QA는 한두명만 참여하면 된다. 이 단계에서 QA가 많고, 버그를 많이 찾아낸다고 해서 무조건 좋은 것은 아니다. QA는 자동 변환 도구의 결과를 테스트 주의! 이 단계에 QA를 많이 투입할 것인지 아닌 지에 대한 결정은 프로젝트에 따라 다를 수 있으므로 매우 조심해야 한다. 써드-파티 컴포넌트는 분석이 매우 잘 되어야 한다. 심지어 프로젝트 전부터 미리 충분히 파악해야 한다. 마이그레이션 프로젝트가 시작되면 써드-파티 컴포넌트에 대한 작업과 부담이 많기 때문이다. 마이그레이션을 자동화하는 "맞춤" 변환 도구를 개발한다. 프로젝트가 많고 규모가 커도 처리할 수 있다. 검증 단계는 매우 중요하다. 충분한 테스트 시간이 필요하다. 검증 단계를 거치지 않고 바로 배포로 넘어가면 운영 시 문제가 많을 수 있다. 그러면 경영진은 이 프로젝트가 실패했다고 판정할 수 있다. 그러면, 검증 단계 하나의 실패로 끝나지 않는다. (우리는 검증 단계에 충분한 시간을 계획하였기 때문에 문제가 없었다) 프로젝트 중 소통이 매우 중요하다. 모든 팀원들이 진행 중인 작업을 항상 업데이트할 수 있는 절차와 환경이 구축되어야 한다. 그래야, 서로 다른 사람의 작업에 어떤 영향을 주거나 받는 지를 미리 파악할 수 있다. 프로젝트 평가 기준을 구체적이고 명확히 정하고 모니터링해야 한다. 계속 앞으로 갈 것인지 아니면 중단해야 하는 지에 대한 기준을 정하는 것은 매우 중요하다. 마이그레이션 목적이 분명해야 한다. 프로젝트 진행 중에 목적이 변경되면, 3-4개월 이상 지체될 수 있다. 목적과 목표가 분명해야 계획된 일정을 준수할 수 있다. 델파이 7은 매우 훌륭한 도구이지만, 거기에 머물고 있을 수 만은 없다. 머물러 있고 싶어도, 우리가 앞으로 가야할 시간은 언젠가 오게되어 있다. 20년 전에 출시된 델파이 7로는 지금 시점에서 필요한 기술 모두를 지원하지 못한다. 시스템 운영에 크리티컬할 기술에서도 그렇다. 구버전에서 벗어나서 최신 기술에 맞춰가자. 참고 자료 What's New in Delphi 10 Seattle https://www.embarcadero.com/products/delphi/whats-new Embarcadero Update Center https://www.embarcadero.com/rad-in-action/migration-upgrade-center Desktop Windows Version Market Share Worldwide http://gs.statcounter.com/windows-version-market-share/desktop/worldwide/#monthly-201509-202110 Delphi Unicode: https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf 그림 자료 마이그레이션 전과 후의 UI 비교: 로그인 화면 새 UI에서 사용자 테마 선택 지원: 설정 화면 새 UI에서 사용자 테마 선택 지원: 다크 테마 적용 시 화면 마이그레이션 전과 후의 UI 비교: 일반 화면 새 UI에서 대시보드 구현 새 UI에서 실시간 그래프 구현1 새 UI에서 실시간 그래프 구현2 "맞춤" 자동 변환 도구 예시: 써드 파티 컴포넌트의 경우 프로퍼티 변환이 필요함 3단계 (검증 단계)의 버그 발견 및 해소 추이 << DelphiCon 2021 목록으로 이동 View full 엠바카데로 기술자료
  14. Emad Bin Abid 가 작성한 Everything You Need To Modernize With RAD Server (영문 원본 보기) 를 번역했습니다. 현대 사회에서 우리는 기술에 둘러싸여서 파묻혀있고 그 기술의 형태도 다양하다. 전적으로 클라우드 기반인 기술이 대부분이긴 하지만 여전히 상당 부분은 클라우드와 물리적인 하드웨어 컴퓨팅 장비가 함께 섞여 있기도 하다. 하지만 아무리 최신 기술이라도 결국은 더 최신 기술에 의해 밀려나고 시대에 뒤쳐지게 되는 때가 반드시 온다는 사실 하나는 분명하다. 모든 기술이 각자 급격하게 발전하지만, 결국 이런 발전된 기술이 제공하는 더 발전된 단계에 의해서 또는 문제를 해결하거나 서비스를 제공하는 방식 자체가 더 새롭고 강력한 그 무언가에 의해 교체되고 만다. 기술과 애플리케이션이 뒤안길로 사라지지 않도록 지키려면, 끊임없이 기능을 업드레이드하고 다가올 트렌드와 사용 방식을 예측하여 반영해야 한다. 단순 명쾌하다.그리고, 이 과정에서 어떤 작업은 매우 고될 수도 있다. 애플리케이션이 복잡하고 코드 기반이 너무 광범위한 경우에는 특히 그렇다. 또한 애플리케이션에서 사용된 많은 라이브러리와 프레임워크들 중에는 단종되거나, 쓸모없어지거나 업데이트가 필요한 것들도 있다. 애플리케이션을 업그레이드하고 현대화하는 어려움을 극복하려면, RAD 서버와 같이 그 과정을 세련되게 진행할 수 있는 강력한 수단을 제공하는 견고한 개발 솔루션이 필요하다. 우리는 이런 수단을 통해서 변경을 어떻게 해낼 것인 지에 대한 감을 잡을 수 있다. 그리고 이런 수단들 자체가 직접 현대화 작업 자체를 가이드하는 역할을 하기도 한다. 이 글은 RAD 서버를 사용하여 현대화 하는 것이 어떤 것인지 왜 애플리케이션에서 필수 요소이고 최우선으로 고려해야 하는 지를 들여다 본다. 애플리케이션을 현대화 해야하는 이유는? 불과 5년 전과 비교해도, 소프트웨어 개발 분야는 상당히 달라졌다. 운영체제의 추상화와 지원 능력이 발전함에 따라 애플리케이션은 하드웨어 장비의 리소스를 훨씬 더 효율적으로 사용한다. 컴포넌트 생태계가 풍부해 지고, 개발 도구 업계가 더 성숙해졌고, 프로그래밍 언어의 범위도 넓어짐에 따라 애플리케이션이 복잡한 처리를 이전보다 더 잘 수행할 수 있도록 하는 코드를 구현하는 과정 역시 더 최적화되었다. 이런 환경에서 우리의 애플리케이션이 살아남기 위해서는, 현대화를 해야 하고, 이전보다 더 많은 서비스를 제공해야 한다. 웹 애플리케이션 개발을 살펴보면, 웹 브라우저와 그 렌더링 능력이 발전함에 따라 웹 애플리케이션은 훨씬 더 동적이고 견고해졌다. 웹 애플리케이션을 개발 속도 역시 엄청나게 빨라졌다. 또한 화면 렌더링 측면에서는 반응형 UI 기술이, 그리고 장비의 센서 활용 면에서는 여러 하드웨어 센서와 기능의 최소한의 공통 분모를 다룰 수 있는 속성과 메소드를 제공하는 API와 같은 기술이 나온 덕분에, 제대로 만든 웹 애플리케이션이라면 모든 장비에서 사용할 수 있다. 모듈화는 마이크로서비스를 통해 실현되었고, 서버리스(Serverless)를 통해 운영 경제성까지 갖추었다. 보안성과 확장성 역시 애플리케이션 개발과 관련하여 매우 중요한 요소가 되었다. 사이버 공격이 증가함에 따라, 애플리케이션은 모든 면에서 보안성이 확보해야 하고, 관련된 베스트 프랙티스 (가장 좋다고 검증된 조치법)를 반영해야 한다. 또한 애플리케이션의 확장성을 확보하여 많은 사용자를 품을 수 있고 필요할 때 바로 사용될 수 있어야 한다. 이런 것들이 없이는 경쟁에서 밀리고 결국 잊혀지게 될 수도 있다. RAD 서버는 무엇인가? 어디에 사용되는가? RAD 서버는 현재 백-엔드 개발 애플리케이션 분야에서 앞서가는 솔루션 중 하나로서, 애플리케이션 서비스를 구축하고 배포할 수 있도록 하는 플랫폼이다. 여러 뛰어난 장점들을 갖추고 있으며 특히 백-엔드를 구축하려고 마음 먹으면 RAD 서버를 사용하여 바로 시작할 수 있다. API를 개발하고 애플리케이션을 서비스 하는데 필요한 기능 대부분이 이미 준비되어 있기 때문에 백-엔드 서버 전체를 맨 처음부터 시작하지 않아도 된다. 필요한 외부의 서버와 서비스는 RAD 서버를 통해 손쉽게 연결할 수 있다. MySQL, 오라클, SQL 서버, 인터베이스(Interbase) 등 거의 모든 엔터프라이즈 데이터베이스 기술에 연결할 수 있다. RAD 서버에는 사용자 관리 서비스, 디렉토리 서비스 등의 중요한 백-엔드 기능이 이미 들어 있다. 특히 정기적으로 솔루션을 개발하고 재배포하는 소프트웨어 제조사에게는 가장 도움이 되는 도구가 될 것이다. RAD 서버를 사용하면 REST API와 해당 엔드포인트를 작성, 공개, 관리를 빠르게 할 수 있다. 더 나아가 API 분석 기능, 성능과 이슈 모니터링 등의 기능이 내장되어 있어서 바로 사용하면 된다. 또한 사용자 관리, 그룹관리, 접근 제어를 할 수 있는 관리 포털도 제공된다 RAD 서버를 사용하여 애플리케이션을 현대화하는 방법은? RAD 서버에 내장되어서 바로 쓸 수 있는 백-엔드 개발과 플랫폼 모니터링 기능은 제쳐두고, 기존의 델파이와 C++빌더로 만든 기존의 클라이언트/서버에 있는 비즈니스 로직을 RAD 서버를 통해 어떻게 현대화 할 수 있는 지를 살펴보자. RAD 서버를 사용하면 기존의 애플리케이션 로직을 보안성과 확장성이 높은 서비스 기반 아키텍처로 손쉽게 마이그레이션 할 수 있다. 서비스 기반 아키텍처는 애플리케이션이 원활하게 작동할 수 있도록 하기 위해 서비스가 필요한 애플리케이션 구성 요소에게 해당 서비스를 제공하는 것에 촛점을 맞춘다. 애플리케이션이 일단 RAD 서버로 옮겨서 현대화되고 나면, 많은 이점을 누릴 수 있으며 이전보다 훨씬 많은 것을 제공할 수 있다. 전용 관리 콘솔, 배포 간편, 내장된 통계 콘솔 역시 RAD 서버의 장점이다. 또한 마이그레이션된 기존의 비즈니스 로직을 서비스하는 엔드포인트를 생성하고 관리할 수 있다. RAD 서버를 사용하여 현대화를 하면 다음과 같은 장점들 역시 갖출 수 있다. 클라우드 서비스 연결 능력: 거의 모든 기술 분야에서 클라우드 컴퓨팅과 여기에 연결하는 능력이 생존을 결정하게 될 미래가 빠르게 다가오고 있다. RAD 서버를 사용하면 구글, 아마존, 등등 대표적인 클라우드 플랫폼에서 제공하는 REST 클라우드 서비스를 수용할 수 있다. 도커(Docker)를 견고하게 지원: 컨테이너 기술은 최근의 소프트웨어 개발 산업에서 가장 큰 혁신이다. 그 중에서도 도커(Docker)는 거의 모든 곳에서 사용되는 지배적인 컨테이너 서비스이다. RAD 서버를 사용하면 도커 이미지를 만들고 도커 허브 (Docker Hub)에 올려둘 수 있어서 구글 클라우드, 마이크로소프트 애저, AWS로 간단하게 배포할 수 있다. 사물인터넷 장비 연결 능력: 사물인터넷은 강력한 네트워크 그리고 속도가 빠른 데이터 전송 환경을 바탕으로 하는 멋진 기술이다. 사물인터넷을 지원하는 장비는 필요한 애플리케이션과 바로 연결되어 작동할 수 있다. RAD 서버를 사용하면, 사물인터넷 장비를 여러분의 애플리케이션 서비스에 손쉽게 연결할 수 있다. 위 기능들은 오늘날의 디지털 시대의 첨단 기술이다. RAD 서버로 마이그레이션을 하면, 이제 여러분도 이런 첨단 기능을 갖출 수 있으며 서비스 기반 접근을 반영할 수 있다. RAD 서버의 능력을 살펴볼 수 있는 사례는? 초창기의 RAD 서버는 가장 먼저나온 백-엔드 개발 플랫폼은 아니지만, 그 서비스와 기능을 통해서 백-엔드의 기준을 세웠다. 많은 기업과 개발자들이 비즈니스 로직 처리를 담당하는 백-엔드 서비스를 제공하는 견고한 애플리케이션을 만들기 위해 RAD 서버를 사용해오고 있다. RAD 서버를 활용하는 아래의 프로젝트를 보면, 여러분이 바랬던 어플리케이션이 어떤 모습일지에 대해좋은 아이디어를 얻을 수 있을 것이다. 아래 내용은 RAD 스튜디오에 들어있는 예제들이다. RAD 서버가 애플리케이션에 어떻게 생명을 주는 지를 볼 수 있다. RAD 서버 멀티-테넌시 예제: 일반적인 소매점을 위한 예제이다. 여기에는 EMS(enterprise management system)을 활용하며, 파이어닥(FireDAC) 컴포넌트를 사용하여 데이터베이스에 연결한다. 또한 RAD 서버 콘솔을 통해 엔드포인트의 갯수와 사용 빈도 등의 통계를 보는 기능도 볼 수 있다. RAD 서버 파이어닥(FireDAC) 리소스 예제: 파이어닥(FireDAC)은 델파이에서 데이터를 연결할 때 사용하는 컴포넌트 세트로써 엔터프라이즈 데이터베이스 연결 속도가 빠르다. 이 예제는 EMS서버와 여기에 연결하는 클라이언트를 만드는 프로젝트이며, 파이어닥(FireDAC)을 사용하여 SQLite 데이터베이스에 연결한다. RAD 서버 콘솔은 별도로 하고, 이 예제의 EMS 서버는 RAD 서버 엔진을 기반으로 작동한다. 따라서, 해당 서버 호스트를 클라우드에 둘 수도 있고, 온프레미스에 둘 수도 있다. 위 예제와 별개로, 이와 비슷하게 RAD 서버를 충분히 활용하는 사례 템플릿들도 있고 원하면 가져다 쓸 수도 있다. 예를 들어, RAD 서버 간호사실(RAD Server Nurses Station) 템플릿은 병원/의원에서 환자 데이터를 자동으로 수집하는 기능이 구현되어 있다. 이 템플릿에는 사용자 관리, 데이터 수집과 배포, 알림 서비스 등 RAD 서버가 이미 내장하고 있는 기본 기능들도 사용하고 있다. 또한 다른 시스템이 연결할 때 REST HIPPA(미국의 개인의료 정보 보호 규정) 연결을 활성화하는 기능도 있다. 당신의 델파이 애플리케이션을 현대화하고 마이그레이션 할 준비가 되었다면, RAD 서버를 살펴보자. 어떻게 활용하면 원하는 목적을 이룰 수 있는 지를 알 수 있다.
  15. Anbarasan의 Quickly Migrate and Modernize Your Delphi/C++ Apps Using FastReport With Windows High DPI Setup 을 번역했습니다. (원문 작성 시기: 2020년 11월) 디스플레이 패널의 물리적 공간 당 픽셀 수는 점점 더 많아지고 있어서 DPI (인치 당 도트수)가 높은 모니터가 많아졌다. 예전에는 디스플레이 대부분이 96 DPI 즉, 1 인치 당 96 픽셀이 들어있었지만, 2017년에는 거의 300 DPI가 넘는 것들도 생겨났다. 이제 시중에는 SD, Full HD, 4K 울트라 HD, 8K 울트라 HD 등 다양한 모니터가있다. 우리가 사용하는 노트북이나 화면이 작은 데스크탑에서 화면 배율 팩터/DPI를 변경할 수 없으면 사용하기가 매우 어렵다. 더 나아가 Full HD, 4K 울트라 HD, 8K 울트라 HD 모니터에서는 훨씬 더 복잡하다. 우리의 애플리케이션들은 이 모든 것을 다룰 수 있어야 한다. 어떤 사용자가 어떤 사양의 모니터를 사용할 지 모르기 때문이다. 화면 배율 팩터/DPI가 변경되는 일반적인 상황 몇 가지를 살펴보자: 모니터 여러 대를 사용하는데, 각 모니터의 화면 배율이 서로 다르고, 애플리케이션이 한 모니터에서 다른 모니터로 옮겨지는 경우 (예. 모니터 1은 4K이고 모니터 2는 1080p 화면) DPI가 낮은 외부 모니터를 DPI가 높은 노트북에 연결 또는 연결 해제하는 경우 (또는 그 반대의 경우) DPI가 높은 노트북/태블릿에서 원격 데스트탑을 통해 DPI가 낮은 장비를 연결하는 경우 (또는 그 반대의 경우) 애플리케이션이 작동하고 있는 중에 윈도우의 화면 배율 팩터 설정을 변경하는 경우 데스크탑 애플리케이션은 자신이 DPI Scaling을 지원하는 지를 윈도우에게 알려야 한다. 이 정보가 전달되지 않으면 윈도우 시스템은 일단 해당 데스크탑 애플리케이션은 DPI를 인식하지 않는다고 간주하고, 화면에 맞게 비트맵을 확대/축소 한다. 애플리케이션은 자신의 DPI 인식 모드를 Unaware, System, Per-Monitor, Per-MonitorV2 중에서 하나로 설정함으로써 윈도우가 해당 애플리케이션을 화면에 표현할 때 DPI 확장을 어떻게 처리할 지 명확하게 알려주게 된다. 일반 애플리케이션을 Per-MonitorV2 인식으로 업데이트할 때에는, UI 레이아웃을 제어하는 코드 역시 업데이트 되도록 해야 한다. 이 처리는 애플리케이션이 초기화되는 시점 뿐만 아니라 DPI 변경 (Win32의 경우 WM-DPICHANGED 윈도우 메시지) 알림을 받을 때마다 반영되어야 한다. 델파이 애플리케이션을 High DPI로 마이그레이션 할 때 꼭 알아두어야 하는 점들은 무엇일까? DPI Awareness 모드를 설정한다: Project > Options > Application > Manifest-DPI Awareness 에서 Per-MonitorV2를 선택한다. Screen.PixelsPerInch 에 주 모니터의 DPI를 사용한다. TImagesList 대신 TVirtualImageList를 사용한다. 모든 사용자 정의 그리기 작업에서 절대 위치를 확인한다. Control.CurrentPPI를 사용하여 각 컨트롤들이 표현되는 현재 PPI값을 받아낸다. 대화상자 혼합 모드 (SetThreadDPIAwarenesscontext) 폼의 OnBeforMonitorDPIChanged / OnAfterMonitorDPIChanged 이벤트를 사용한다. 주의: 플랫폼과 애플리케이션을 개발한 델파이 버전 호환성을 확인해야 한다. 델파이와 패스트리포트(FastReport)의 High DPI 컨트롤들: TControl: ScaleforPPI, ChangeScale, ScaleControlsForPPI와 같은 프로시저들은 High DPI 변경을 도와준다. TFrxBAseForm: UpdateResources, UpdateFormPPI, ProcessPreferences와 같은 프로시저와 WM_DPICHANGED 윈도우 메세지는 패스트리포트 폼의 DPI 변경을 도와준다. TFrxDPIAwareCustom: DoPPIChanged, GetScale과 같은 프로시저와 WM_DPICHANGED_AFTERPARENT 윈도우 메세지는 패스트리포트의 사용자 지정 컨트롤 DPI 변경을 도와준다. Fast Migration to Windows 10 High DPI 비디오에서 데모를 확인해보자!
  16. Muminjon의 5 Ultimate Ways To Modernize Your Apps For Windows 11 를 번역했습니다. 현대적이고 견고하고 엔터프라이즈급 UI를 구현할 수 있도록, 델파이는 윈도우 전용인 VCL (Visual Component Library)과 크로스-플랫폼 개발용인 파이어몽키 (FMX)를 제공한다. 델파이 VCL에는 윈도우 앱 개발에 필요한 최신 기능과 현대식 UI 컨트롤이 들어있다. 또한, 델파이로 만든 앱은 네이티브 성능을 발휘한다. 그리고 델파이를 사용하면 윈도우의 최신 기능과 하드웨어를 빠르게 반영할 수 있다. 이 글에서는 당신의 앱을 윈도우 11 용으로 현대화하는 핵심 방안 다섯가지를 정리해보았다. 1. 사용자를 포용하는 디자인(Inclusive Design)을 만들었는가? 사용자들은 앱이 어떤 정보를 수집하는 지 그리고 개인 정보 정책 안내가 잘 되어 있는 지를 쉽게 알을 수 있는 앱을 좋아한다. 따라서 사용자에게 이 모든 정보를 알려주고, 수집 정보를 제조사로 전송하는 기능을 직접 끄거나 켤 수 있도록 하는 것은 언제나 환영받는 요소이다. 종합적인 디자인 (Comprehensive Design)은 제품의 신뢰도를 더욱 높이고 누구에게나 알맞은 환경을 제공한다. 예를 들어, 앱의 내용이 수많은 글자로 되어있다면, 화면을 읽어주는 스크린 리더 기능을 추가하면 한결 좋아질 것이고 장애가 있는 사용자들도 만족할 것이다. UI 컨트롤과 메뉴에는 단순하고 아름다운 애니메이션 안내를 제공하자. 가능한 가장 좋은 배율 조정과 반응을 앱에 실현하자. 폰트 크기를 사용자가 직접 변경할 수 있도록 하자. 사용자마다 사용하는 화면의 크기가 제각각이다. 따라서 개발자는 앱이 어떻게 표현될 지를 모조리 알 수는 없다. 당신의 앱이 첫 화면에서 여러가지 정보를 제공하고, 이 정보가 여러 프레임으로 나누어져 있다면, 사용자가 직접 프레임을 재배치/재구성 할 수 있도록 하자. 그림. 델파이 11 IDE는 사용자가 레이아웃을 변경할 수 있도록 되어있다. 윈도우 11에서는 아이콘 대부분이 업데이트 되었다. 윈도우 11의 아이콘들은 반짝이고 질서정연하다. 게다가 UI 글꼴은 Segoe UI Variable 글꼴이 새로 도입되어서 당신의 앱이 사용하는 활자 역시 더 부드러워지고 가독성도 더 높아진다. 그림. 윈도우의 새 Segoe 폰트 (출처: 윈도우 문서) 2.현대식 UI 컨트롤을 사용하고 있는가? 그림. 델파이 VCL은 현대식 윈도우 UI 컨트롤들과 네이티브 성능을 제공한다. 아름답고 현대적인 UI 컨트롤들을 사용함으로써, 윈도우 11에서 당신의 앱은 더욱 멋지고 최첨단이라는 느낌을 준다. 윈도우 11 자체의 UI에 이미 수많은 혁신이 반영되었으므로, 당신의 앱 역시 윈도우 11의 UI와 잘 어우러질 필요가 있다! 게다가, 가벼우면서도 확대할 수 있는 애니메이션이 앱에 구현되어 있으면 사용자 경험(UX)을 향상시킬 수 있다. 애니메이션을 애플리케이션에 추가할 때 가장 널리 사용되는 방식 중 하나는 로티(Lottie) 애니메이션 파일을 사용하는 것이다. 그림. Skia4Delphi 그래픽 라이브러리를 사용하자. 로티(Lotti) 애니메이션 파일을 델파이 앱에 추가하는 방법을 알고 있는가? 쉽다! 델파이 커뮤니티가 개발 생태계에 기여하고 있기 때문이다. Skia4Delphi는 델파이에서 사용할 수 있는 크로스 플랫폼 2D 그래픽 API로써 구글의 스키아 그래픽 라이브러리(Skia Graphic Library)를 기반으로 한다. 델파이에서 SVG와 로티(Lotti)를 사용하는 방법은 Desktop First UX Summit에서 짐 맥키트가 진행한 세션에서 볼 수 있다. 3. 현대적인 시각 효과를 당신의 앱에서 사용하고 있는가? 윈도우 11은 다양한 UI 요소와 둥근 모서리를 데스크탑 운영 체제에 새로 도입했다. 일반적으로 사용되던 각진 모서리는 이제 둥글고 부드러운 모서리로 바뀌어서 데스크탑 앱에서 전과는 다른 느낌이 난다. 윈도우 11을 활용하다 보면, 모서리가 둥근 UI 컨트롤들이 다크 모드와 라이트 모드 양쪽에서 모두 멋지게 표현되는 것을 알 수 있다. 윈도우 11 둥근 모서리를 코드를 사용해 다루는 방법은 다음 글을 통해서 배울 수 있다. 윈도우 11 둥근 모서리를 내 앱에 적용하기 델파이 VCL에는 당신의 앱이 현대적인 모습을 갖출 수 있도록 하는 VCL Styles 라는 탁월한 옵션이 있다. 수십 가지 독특한 스타일이 제공되기 때문에, 원하는 스타일들을 당신의 윈도우 앱에 적용하기만 하면 현대적인 UI를 몇 초만에 완성할 수 있다. 플루언트(Fluent) 앱을 델파이로 디자인하려면 어떻게 할까? - 아크릴 재질 (Acrylic material) 디자인 하기 플루언트 디자인 시스템을 당신의 앱에 적용하고 싶다면, StyleControls VCL 패키지를 사용하면 된다. StyleControls VCL 패키지는 클래식 드로잉(classic drawing), 시스템 테마, GDI+, VCL 스타일을 사용하여 독특한 사용자 인터페이스를 만든다. 그림. StyleControls VCL 패키지는 마이크로소프트 플루언트 UI 디자인이 반영된 컨트롤을 제공한다. 4. 당신의 앱은 현대식 하드웨어와 기능 모드를 사용하고 있는가? 최근 몇년간, 터치스크린 용으로 디자인된 앱들도 많이 나왔다. 예를 들어, 투인원(2-in-1) 노트북을 사용하면, 앱의 UI 컨트롤이 더 크고, 더 정확한 위치에 있어야 사용하기 좋다. 게다가, 알림이나 공유 등의 훌륭한 베스트 프랙티스를 활용하지 않고 있는 애플리케이션들도 아직 꽤 많은데, 당신의 앱에서 이런 기능을 사용할 수 있으면, 당신의 앱은 보다 효율적으로 작동될 것이고 개발자는 그저 해당 API를 사용하기만 하면 된다. 만약, 델파이 VCL이나 FMX를 사용하고 있다면 마우스로 필요한 시스템 컴포넌트를 끌어다 놓기만 하면 된다! 윈도우 10 알림 기능 구현 샘플을 살펴보자. 또한, 윈도우 스토어(Windows Store)로 앱을 배포하려면 MSIX (오른쪽 그림. 출처: 마이크로소프트) 기능을 활용해야 한다. 윈도우 스토어는 당신의 윈도우 앱 전체를 아무런 변경도 하지 않고 그대로 스토어로 가져온다. 당신의 델파이 앱을 MSIX로 패키징을 통해 배포하는 방법을 살펴보자. 더 나아가, 델파이에는 시스템 센서 컴포넌트들이 들어있다. 센서 컴포넌트는 물리적 양을 측정하고 이것을 신호로 변환하여 애플리케이션에서 읽을 수 있도록 해준다. 센서 컴포넌트 몇가지를 소개한다. TBiometricSensor TElectricalSensor TLocationSensor TMotionSensor TOrientationSensor 센서 컴포넌트를 내 앱에서 넣고 사용하는 방법을 어디에서 배울 수 있는가? 센서 컴포넌트 대부분을 다루었던 이 CodeRage X 세션이 있다. 5. 윈도우 앱 현대화와 개발 트렌드을 따라잡기 위해, 앞서 나아가는 기업들을 보고 배우고 있는가? 현대화를 주제로 진행된 엠바카데로의 온라인 세미나는 윈도우 앱 개발을 배울 수 있는 가장 좋은 자료들 중 하나이다. 데스크탑 용 최신 UI/UX 패턴, WinAPI, COM 과 ShellAPI, WinRT 활용 방안 등등을 배울 수 있다. 마이크로소프트 스토어에 배포하기 보편적인 데이터베이스 액세스를 위한 파이어닥 (FireDAC) 윈도우 High DPI 윈도우 런타임 활용 마찬가지로, 가장 최근에 진행된 Desktop First UX Summit도 온라인에 오픈되어 있다. 업계 리더들과 소프트웨어 엔지니어들이 소프트웨어 개발에 관한 훌륭한 워크샵과 실제 사례를 제공한다. 이 웨비나는 디자인 절차, 디자인 시스템, 인공지능(AI), 비주얼 디자인, 정보 아키텍처 등등을 다룬다. Desktop First UX Summit 2020 (한글 정리본) Desktop First UX Summit 2021 (한글 정리본)
  17. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Giving your Apps the Fluent UI Look and Feel with Delphi - Ian Barker 의 한글 요약본입니다. 발표자 (Ian Barker)는 델파이 개발자에게 잘 알려진 엠바카데로 MVP입니다. “Git과 Github를 사용해야하는 이유와 델파이 개발자가 꼭 필요한만큼만 사용하기”도 많은 관심을 받았습니다. 발표자 이안 바커(Ian Barker) 웹사이트 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 보기 (1편: 52분, 2편: 47분) 이 문서는 핵심 정리에 초점을 맞추었습니다. 비디오와 함께 보기를 권합니다. 1편에서는 (윈도우 개발자를 위한 일반적인 세션), 마이크로소프트의 새 표준 디자인 컨셉인 플루언트 UI의 핵심 개념을 정리하고, 윈도우10에서 실제로 어떻게 반영되었는지 살펴봅니다. 더 세련되어진 윈도우 10의 룩앤필과 UX를 적용하기 위해, 윈도우 애플리케이션 개발자에게 필요한 기술을 정리합니다. 2편에서는 (델파이 개발자를 위한 델파이 코드 중심 세션), 델파이 개발자들이 플루언트 UI를 구현하는 방법을 데모와 함께 설명합니다. (서드파티를 사용할 수도 있고, 순수 델파이 코드만으로도 가능합니다.) 소스 코드는 깃허브에서 무료로 볼 수 있습니다. 비디오에서 소스 코드 작성을 볼 수 있는데, 일반 UI 코드 작성 시에도 도움이 될 것입니다. 목차 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) (1편 비디오 보기) 플루언트 UI란? 마이크로소프트 디자인 요소를 정의한 디자인 언어의 최신판 이미 윈도우 10, 오피스 365 등 마이크로소프트 최신 제품들에 적용되어 있다. 마이크로소프트가 수많은 UX연구를 통해 실현한 미적인 새 디자인 (윈도우 96, 98, Me, 비스타를 거치면서 실패했거나 성공한 경험이 반영되었다.) 이미 멋지다고 알려졌던 바로 그 네온 프로젝트이다. 마이크로소프트 디자인 공식 웹페이지에서 무엇을 염두에 두었는지, 왜 그랬는지를 포함한 정확한 정보를 볼 수 있다. 한글 Wiki (플루언트 디자인 시스템) (다소 부정확한 내용도 있으므로 공식 웹사이트를 권장한다.) 플루언트 UI가 중요한 이유? 윈도우 애플리케이션 개발자라면 윈도우다운 룩앤필에 익숙해져야 한다. 사용자 입장에서, 윈도우 사용 경험과 여러분이 만든 윈도우 앱 경험이 일치해야 혼란을 느끼지 않는다. 이 디자인 표준을 벗어난 윈도우 애플리케이션은 구식으로 보이거나 윈도우와 충돌이 나서 사용자에게 불편을 줄 수 있다. 마이크로소프트가 잡는 디자인 방향이 주류가 되므로, 윈도우에서 작동되는 애플리케이션이라면 따를 수 밖에 없다. 윈도우 뿐만 아니라 마이크로소프트가 만드는 많은 개발 도구, API, SDK 등에서도 이 방향이 적용된다. 플루언트 디자인의 실제 모습: “윈도우10 설정 화면”에 잘 반영되어 있음 라이트모드, 다크모드가 제공된다. 마우스가 올라갔을 때 상자 테두리가 나타나는 곳은 기능이 있음을 의미한다. (마우스가 위치를 벗어나면 상자 테두리가 사라진다.) 포커스를 받은 윈도우는 테두리가 강조 표시된다. (기본 강조 색상: 빨강) 플루언트 UI의 기본 사상 마이크로소프트 디자인 언어 2 (MDL2)를 향상 메트로 UI로 알려진 마이크로소프트 디자인 언어 1 (MDL1)에서 시작되어 진화됨 오래전, 윈도우폰에 적용되었던 당시 통일된 UI를 시도했었다. 마이크로소프트는 메트로에서 폰과 윈도우 8 전체에 통일된 UI를 적용하고자 했으나 결국은 하드웨어 지원 문제 등의 이유로 실패했다. (자세한 내용은 관련글 참조) 예전에 이상하게 컸던 윈도우 버튼이 기억나는가? 플루언트 UI는 윈도우폰과 윈도우8에서 벗어난 후 새롭게 구축 한글 Wiki (메트로 디자인 언어) 마이크로소프트 플루언트 디자인 시스템 마이크로소프트 디자인 언어를 구현 2017년 10월, Window 10 업데이트에서 공식 데뷔 수많은 다양한 장비에서 윈도우가 이용되고 있으므로 단계적으로 안전하게 변화해오면서 이제는 상당히 정착됨 윈도우 7 디자인에서 윈도우 10 디자인으로 거의 옮겨감 (윈도우 8은 잠시 거쳐가는 정도였음) 윈도우10은 실제로 많은 서브 버전들이 있지만 모두 플루언트 UI가 일관적으로 적용됨 플루언트 UI의 핵심 개념 핵심 요소: Light, Depth, Motion, Fonts and Icons, Material 대부분 이미 MDL1 즉, 메트로 구현 시에 이미 있었지만, MDL2 즉, 플루언트 디자인에서 더 구체화되고 통일성이 갖추어졌다. 오피스 365 현재 버전에 그 특징이 잘 나타났다. (역자주: 아래 내용은 비디오를 보면 보다 명확히 이해할 수 있습니다.) 핵심 요소 주요 사항 Light (빛) 다크 모드 / 라이트 모드 Reveal Focus: (버튼, 윈도우 등) 클릭할 수 있는 요소가 포커스를 받으면 (마우스가 위치하거나 탭키로 포커스를 받으면) 그 테두리가 드러난다. Reveal Highlight: 마우스가 가리키고 있는 곳이 가장 밝고, 옆으로 가면서 점차 미세하게 옅어진다. (테두리 색상도 마찬가지로 미세하게 옅어지는 효과가 적용된다.) Depth (깊이) Z축을 이용하여 튀어나오게 만들어 내용을 차별화한다. 그림자가 다시 도입 - 여전히 기본적으로 평평한 디자인을 유지하지만, 깊이를 이용해 원하는 곳을 강조한다. Motion (움직임) 애니메이션 효과를 통해 사용자가 전환 내용을 이해할 수 있도록 한다. Fonts / Icons (폰트와 아이콘) Segoe* UI 폰트로 통일됨 Segoe 아이콘이 윈도우 10에 내장됨 아이콘은 윈도우에 맞게 통일감있게 사용하는 것이 좋다. 사람들은 이미 학습된 아이콘 모습을 보면 자동으로 기존 학습대로 인식한다. 따라서 윈도우의 아이콘을 다른 용도로 사용하면 사용자에게 혼란을 준다. (Font-Awesome 프로젝트에도 유사한 것들이 많이 있다.) Material (재질) 반투명한 시스루 룩을 윈도우 10에서 많이 경험했을 것이다. 이것이 대표적 재질인 아크릴 재질이다. 아크릴 재질은 뿌연 효과를 주기 위해 알파 투명도를 사용한다. 데모: 윈도우10 개인설정을 통해 플루언트 UI를 경험해보자. (20분 05초부터 데모 보기) 윈도우 바탕화면에서 오른쪽 마우스 후 가장 아래 항목인 “개인설정”을 선택해보자. Material (아크릴): 설정 창이 표시되고, 이 창 뒤에 가려진 화면은 반투명으로 비친다. Light (Reveal Highlight): 설정 창 왼쪽 메뉴 부분에서 마우스를 좌우로 움직이면 살짝 더 밝은 부분이 마우스를 따라다닌다. 즉, 미세한 그라데이션 효과가 생긴다. Light (다크 모드 / 화이트 모드): 설정 창 왼쪽 메뉴에서 “색”을 선택하면 다크 모드와 화이트 모드를 선택할 수 있다. Light (Reveal Focus): 설정 창 바깥을 클릭하면 설정 창의 테두리의 강조색이 사라지지만, 다시 설정 창 안쪽을 클릭하면 설정 창의 테두리에 강조색이 표시된다. Fonts와 Icons: 설정 창의 모든 글자와 아이콘은 Segoe UI 폰트와 Segoe 아이콘이다. 데모: 하나는 윈도우10의 설정 창과 모양과 방식이 똑같은 창을 델파이로 만들기 데모 (20분 54초부터 데모 보기) 델파이로 Material (아크릴), Light (하이라이트, 포커스) 등 플루언트 UI를 모두 구현할 수 있다. 이 데모는 델파이 10.4에서 AlMediaDev 라는 써드파티 컨트롤 세트를 사용했으므로 손쉽게 만들었다. (써드파티를 사용하지 않은 구현은 2편에 소개한다) AlMediaDev 컨트롤은 많은 프로퍼티를 통해 플루언트 UI를 반영 수 있도록 한다. 가격도 상당히 저렴하다. 예를 들어, FluentUIBackground 프로퍼티에서 Acrylic을 선택하면 Material에서 아크릴 효과를 줄 수 있다. FluentUIBorder, FluentUIInactiveAcrylicColorOpaq 등 플루언트 UI 구현 관련 속성이 많이 있다. 이 세션은 델파이 세션이기에 앞서 플루언트 UI에 대한 일반 세션이므로 델파이 부분은 생략한다 하지만, 내 블로그에는 다크 모드 / 화이트 모드를 탐지하는 법, 화면 해상도에 맞게 크기 변경 등 여러 코드와 안내가 있다. 델파이 코드 구현 보기: (24분 33초부터 데모 보기) 1편의 관련 자료와 링크 1편 발표 자료 및 원본 아티클 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) (2편 비디오 보기) 목차 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 데모: 델파이로 구현한 플루언트 UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 12분 50초부터 재생하기) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 데모: Almedia 컴포넌트로 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 그림1. 플루언트 UI가 적용된 윈도우 10 개인 설정 창 빛 (Light) 포커스 표현(Reveal Focus): 포커스를 받은 요소의 테두리를 눈에 띄도록 표시 강조 표현(Reveal Highlight): 마우스가 위치한 곳을 더 밝게 표시 깊이 (Depth) 오피스 2019 앱을 실행하면 나타나는 첫 화면에 잘 나타남 클릭할 수 있는 요소 역시 평소에는 평면이지만, 포커스를 받으면 그림자와 함께 3차원으로 튀어나와 보임 모션 (Motion) 윈도우 10 메일 앱을 열면 나타나는 화면에서 잘 나타남 앱의 배경인 구름이 흘러가는 것이 표현되어 생동감을 줌 폰트와 아이콘 (Font & Icon) Segoe UI 폰트 (평소에는 Segue UI의 light 폰트) 와 아이콘으로 통일됨 재질 (Material) 아크릴 바탕(Acrylic), 뒤에 있는 화면을 완전히 가리지 않고 반투명으로 표현, 투명도 적용 데모: 델파이로 구현한 플루언트UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 19분 51초부터 재생하기) 그림2. 플루언트UI가 적용된 Almedia에서 제공하는 데모 앱 그림3. 이 세션에서 사용한 플루언트 UI의 핵심 요소들을 구현한 앱 (델파이만으로 만든 앱과 Almedia를 사용한 앱 모두 깃허브에 소스 코드가 공개되어 있음) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 플루언트 UI의 빛(Light) - 포커스를 버튼에 표현하기: 우측 상단의 최소화 버튼 (비디오 20분 43초부터 재생하기) TRectangle [최소화 버튼] 이미지를 넣고, 그 안에 TFillRGBEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. 플루언트 UI의 깊이(Depth)를 버튼에 표현하기: 섹션 카드 (비디오 21분 28초부터 재생하기) TRoundRectangle 안에 TLabel과 TShadowEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. (TShadowEffect의 Enabled 속성이 True 이면 그림자가 표시된다.) 플루언트 UI의 재질(Material)을 버튼에 표현하기: 화면의 왼쪽 영역 (비디오 22분 42초부터 재생하기) 투명도 구현은 생각보다 쉽다 (의외로 많은 사람들이 어렵거나 불편한 방법을 사용하고 있다.) VCL에서는 TForm의 (AlphaBlend속성이 True이고) AlphaBlendValue가 255이면 불투명이다. 값이 0으로 가까이 갈 수록 더 투명해진다. FMX는 화면 그리기 방식이 VCL과 다르다. TForm의 Transparency 속성을 True로 주면 투명해진다. 그리고 나서 각 섹션에서 Opacity 속성을 사용해 투명도를 정한다. 이 데모의 FXM 폼에서는 BorderStyle 속성을 None으로 주어 테두리가 평소에 보이지 않도록 했다. 그리고 나서 화면 왼쪽의 TPanel의 Opacity 속성을 0~1 사이 값으로 설정하여 조절한다. (1 이면 완전히 불투명하다.) 이 데모의 TPanel의 투명도를 설정하는 부분은 우측 본 화면의 아래 쪽에 있다. TSpinBox를 통해 값을 받는다. // TSpinBox의 OnChange 이벤트를 처리하는 코드 // 0˜10까지 값을 받으면, 해당하는 Opacity(0~1)가 반영되도록 한다. procedure TForm1.SpinBox1Change(Sender: TObject); begin if SameText(Spinbox1.Text, '10') then Panel1.Opacity := 1 else Panel1.Opacity := StrToFloat('0.' + Spinbox1.Text); end; '플루언트 UI의 빛(Light) - 포커스를 폼 자체에 표현하기 (비디오 25분 19초부터 재생하기) 멀티플랫폼용인 FMX에서는 TForm의 OnActivate와 OnDeactivate 이벤트에서 포커스를 받았는지를 알 수 있다. 참고로, 윈도우 전용인 VCL에서는 TApplication의 이벤트을 사용해야 포커스를 받았는지를 알 수 있다. // ‘플루언트UI의 빛(Light)-포커스’를 OnActivate에서 강조, OnDeactivate에서 해제하는 코드 // [참고]윈도우 전용인 VCL에서는 TApplication을 사용해야 포커스를 받았는지를 알 수 있지만, // 멀티플랫폼용인 FMX에서는 TForm에서 가능하다 procedure TForm1.FormActivate(Sender: TObject); begin UpdateFocus(True); end; procedure TForm1.FormDeactivate(Sender: TObject); begin UpdateFocus(False); end; procedure TForm1.UpdateFocus(const IsFocussed: Boolean); begin // 창이 선택된 상태이고 AND 창이 최대화되지 않은 상태라면 // 창의 테두리 선을 표시하여 강조한다. if IsFocussed and (WindowState <> TWindowState.wsMaximized) then begin Line1.Stroke.Color := GetAccentColor(claRed); FillRGBEffect2.Color := Line1.Stroke.Color; FillRGBEffect3.Color := Line1.Stroke.Color; UpdateTransparency; end else begin Line1.Stroke.Color := claWhite; UpdateTransparency; // 창이 최대화된 경우, 투명도가 적용되지 않아야 한다. end; Line2.Stroke.Color := Line1.Stroke.Color; Line3.Stroke.Color := Line1.Stroke.Color; Line4.Stroke.Color := Line1.Stroke.Color; end; 가장 위쪽 툴바에서 마우스를 누른 상태로 창의 위치를 옮기도록 구현 하기 (비디오 26분 57초부터 재생하기) Mousedown 이벤트를 사용한다. // 창에 Title Bar가 없는 경우, 가장 윗쪽 툴바를 마우스로 누른 상태로 창의 위치를 옮길 수 있도록 하는 코드 // Mousedown 이벤트를 사용한다. procedure TForm1.Panel7MouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); begin if (Button = TMouseButton.mbLeft) then if WindowState <> TWindowState.wsMaximized then StartWindowDrag; end; 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내기 (비디오 27분 59초부터 재생하기) // 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내는 코드 function GetAccentColor(const TheDefault: TColor): TColor; const TheKey = 'SOFTWARE\Microsoft\Windows\DWM\'; TheValue = 'AccentColor'; var Reg: TRegistry; AccentCol: DWord; sStr: string; begin // 데스크톱 윈도우 관리자에 없는 값을 아래 레지스트리에서 가져올 수 있다: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\ // // 이 레지스트리에서 "AccentColor"의 DWORD 값을 찾는다. 이값은 창 테두리, 엣지 브라우저의 텝 등등에 적용된다. // // 해당 키의 전체 경로: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\AccentColor // Result := TheDefault; Reg := TRegistry.Create(KEY_READ); try Reg.RootKey := HKEY_CURRENT_USER; if Reg.KeyExists(TheKey) then if Reg.OpenKey(TheKey, False) then try if Reg.ValueExists(TheValue) then begin AccentCol := Reg.ReadInteger(TheValue); // AccentColor를 읽어서 8자리 헥사(Hex) 숫자로 변환 sStr := IntToHex(AccentCol, 8); // (Hex 값임을 표시하는) 첫 2자리 0x를 제거 sStr := Copy(sStr, 3, Length(sStr) - 2); // 이제, "$FF"를 앞에 놓고 RGB값을 뒤에서부터 떼어내어 델파이의 TColor에 맞추기 // // [참고] 델파이의 TColor에 맞추는 방법으로 GetRValue(), GetGValue() 등 훨씬 좋은 것들이 있다. // 이 방법을 쓰는 이유는, 편한 함수를 제공하는 유닛을 포함하지 않아도 되기 때문일 뿐이다. Result := TColor(StrToIntDef('$ff' + Copy(sStr, 5, 2) + Copy(sStr, 3, 2) + Copy(sStr, 1, 2), TheDefault)); end; finally Reg.CloseKey; end; finally Reg.Free; end; end; 그림4. 윈도우 레지스트리에 있는 강조색 (Accent Color) 값 데모: Almedia 컴포넌트를 사용하여 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) Almedia 컴포넌트는 플루언트 UI를 미리 반영해 두었으므로, 바로 사용하면 된다. 예를 들어, TscStyledForm에는 FluentUIAcrylicColor, FluentUIBackground, FluentUIBorder…의 속성이 이미있다. 라이선스 가격은 US$99 이며, 업데이트가 평생 무료로 제공된다. (다른 소프트웨어와 매우 다른 경우이다.) 참고로, 발표자(Ian Barker)는 Almedia 컴포넌트와 아무 관련이 없고, 단지 좋아해서 소개하는 것일 뿐이다. 윈도우 10 테마에 사용할 수 있는 델파이 테마 델파이의 'Windows 10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 Almedia 컴포넌트는 속성과 메소드가 매우 많아서 처음에 혼란스러울 수 있다. 하지만, 일단 한번 하고 나면 훨씬 쉬울 것이고, 매우 유용한 컴포넌트임을 알 수 있을 것이다. 이와 별개로, FMX 역시 UI구현이 매우 유연하고 강력하므로 FMX만 가지고 (소스 코드를 쓰지 않고) 플루언트UI를 구현하는 것도 매우 쉬웠다. 플루언트 UI는 훨씬 더 많은 것들이 있다. 이 세션의 간단한 데모는 플루언트 UI의 핵심을 중심으로 다루었으므로 좋은 시작점이 될 것이다. 이 세션에는 없지만 모션(Motion)을 구현하려면 Animation을 사용하면 된다. // AlmediaDev 컴포넌트로 개발하는 경우에도, 윈도우 테마를 맞춰주는 코드가 필요하다 procedure TVCLCalculatorForm.FormCreate(Sender: TObject); begin MatchWindowsTheme; ... end; // 윈도우 테마를 맞춰주는 코드 // [참고] Font.Color는 clWindows로, Font.Name은 Segoe로 되어 있어야 한다. procedure TVCLCalculatorForm.MatchWindowsTheme; var GoDark: Boolean; iInt: Integer; AButton: TComponent; begin // 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 // 델파이의 'Windows10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 SetAppropriateThemeMode('Tablet Dark', 'Windows10'); GoDark := DarkModeIsEnabled; // 이 코드는 Carbon 테마가, 윈도우 다크 테마와 잘 맞지 않기 때문임 for iInt in cNumberButtons do begin AButton := FindComponent('scGPButton' + IntToStr(iInt)); if (AButton <> Nil) then if (AButton is TscGPButton) then if GoDark then TscGPButton(AButton).Options.NormalColor := clBackground else TscGPButton(AButton).Options.NormalColor := clWindow; end; end; procedure SetAppropriateThemeMode(const DarkModeThemeName, LightModeThemeName: string); begin SetSpecificThemeMode(DarkModeIsEnabled, DarkModeThemeName, LightModeThemeName); end; procedure SetSpecificThemeMode(const AsDarkMode: Boolean; const DarkModeThemeName, LightModeThemeName: string); var ChosenTheme: string; begin if AsDarkMode then ChosenTheme := DarkModeThemeName else ChosenTheme := LightModeThemeName; TStyleManager.TrySetStyle(ChosenTheme, False); end; 2편의 관련 자료와 링크 2편 발표 자료 및 원본 아티클 사용된 Fluent UI 구현 소스 코드 다운로드 (깃허브) 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) << UX Summit 2020 목록으로 이동
  18. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Giving your Apps the Fluent UI Look and Feel with Delphi - Ian Barker 의 한글 요약본입니다. 발표자 (Ian Barker)는 델파이 개발자에게 잘 알려진 엠바카데로 MVP입니다. “Git과 Github를 사용해야하는 이유와 델파이 개발자가 꼭 필요한만큼만 사용하기”도 많은 관심을 받았습니다. 발표자 이안 바커(Ian Barker) 웹사이트 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 보기 (1편: 52분, 2편: 47분) 이 문서는 핵심 정리에 초점을 맞추었습니다. 비디오와 함께 보기를 권합니다. 1편에서는 (윈도우 개발자를 위한 일반적인 세션), 마이크로소프트의 새 표준 디자인 컨셉인 플루언트 UI의 핵심 개념을 정리하고, 윈도우10에서 실제로 어떻게 반영되었는지 살펴봅니다. 더 세련되어진 윈도우 10의 룩앤필과 UX를 적용하기 위해, 윈도우 애플리케이션 개발자에게 필요한 기술을 정리합니다. 2편에서는 (델파이 개발자를 위한 델파이 코드 중심 세션), 델파이 개발자들이 플루언트 UI를 구현하는 방법을 데모와 함께 설명합니다. (서드파티를 사용할 수도 있고, 순수 델파이 코드만으로도 가능합니다.) 소스 코드는 깃허브에서 무료로 볼 수 있습니다. 비디오에서 소스 코드 작성을 볼 수 있는데, 일반 UI 코드 작성 시에도 도움이 될 것입니다. 목차 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) (1편 비디오 보기) 플루언트 UI란? 마이크로소프트 디자인 요소를 정의한 디자인 언어의 최신판 이미 윈도우 10, 오피스 365 등 마이크로소프트 최신 제품들에 적용되어 있다. 마이크로소프트가 수많은 UX연구를 통해 실현한 미적인 새 디자인 (윈도우 96, 98, Me, 비스타를 거치면서 실패했거나 성공한 경험이 반영되었다.) 이미 멋지다고 알려졌던 바로 그 네온 프로젝트이다. 마이크로소프트 디자인 공식 웹페이지에서 무엇을 염두에 두었는지, 왜 그랬는지를 포함한 정확한 정보를 볼 수 있다. 한글 Wiki (플루언트 디자인 시스템) (다소 부정확한 내용도 있으므로 공식 웹사이트를 권장한다.) 플루언트 UI가 중요한 이유? 윈도우 애플리케이션 개발자라면 윈도우다운 룩앤필에 익숙해져야 한다. 사용자 입장에서, 윈도우 사용 경험과 여러분이 만든 윈도우 앱 경험이 일치해야 혼란을 느끼지 않는다. 이 디자인 표준을 벗어난 윈도우 애플리케이션은 구식으로 보이거나 윈도우와 충돌이 나서 사용자에게 불편을 줄 수 있다. 마이크로소프트가 잡는 디자인 방향이 주류가 되므로, 윈도우에서 작동되는 애플리케이션이라면 따를 수 밖에 없다. 윈도우 뿐만 아니라 마이크로소프트가 만드는 많은 개발 도구, API, SDK 등에서도 이 방향이 적용된다. 플루언트 디자인의 실제 모습: “윈도우10 설정 화면”에 잘 반영되어 있음 라이트모드, 다크모드가 제공된다. 마우스가 올라갔을 때 상자 테두리가 나타나는 곳은 기능이 있음을 의미한다. (마우스가 위치를 벗어나면 상자 테두리가 사라진다.) 포커스를 받은 윈도우는 테두리가 강조 표시된다. (기본 강조 색상: 빨강) 플루언트 UI의 기본 사상 마이크로소프트 디자인 언어 2 (MDL2)를 향상 메트로 UI로 알려진 마이크로소프트 디자인 언어 1 (MDL1)에서 시작되어 진화됨 오래전, 윈도우폰에 적용되었던 당시 통일된 UI를 시도했었다. 마이크로소프트는 메트로에서 폰과 윈도우 8 전체에 통일된 UI를 적용하고자 했으나 결국은 하드웨어 지원 문제 등의 이유로 실패했다. (자세한 내용은 관련글 참조) 예전에 이상하게 컸던 윈도우 버튼이 기억나는가? 플루언트 UI는 윈도우폰과 윈도우8에서 벗어난 후 새롭게 구축 한글 Wiki (메트로 디자인 언어) 마이크로소프트 플루언트 디자인 시스템 마이크로소프트 디자인 언어를 구현 2017년 10월, Window 10 업데이트에서 공식 데뷔 수많은 다양한 장비에서 윈도우가 이용되고 있으므로 단계적으로 안전하게 변화해오면서 이제는 상당히 정착됨 윈도우 7 디자인에서 윈도우 10 디자인으로 거의 옮겨감 (윈도우 8은 잠시 거쳐가는 정도였음) 윈도우10은 실제로 많은 서브 버전들이 있지만 모두 플루언트 UI가 일관적으로 적용됨 플루언트 UI의 핵심 개념 핵심 요소: Light, Depth, Motion, Fonts and Icons, Material 대부분 이미 MDL1 즉, 메트로 구현 시에 이미 있었지만, MDL2 즉, 플루언트 디자인에서 더 구체화되고 통일성이 갖추어졌다. 오피스 365 현재 버전에 그 특징이 잘 나타났다. (역자주: 아래 내용은 비디오를 보면 보다 명확히 이해할 수 있습니다.) 핵심 요소 주요 사항 Light (빛) 다크 모드 / 라이트 모드 Reveal Focus: (버튼, 윈도우 등) 클릭할 수 있는 요소가 포커스를 받으면 (마우스가 위치하거나 탭키로 포커스를 받으면) 그 테두리가 드러난다. Reveal Highlight: 마우스가 가리키고 있는 곳이 가장 밝고, 옆으로 가면서 점차 미세하게 옅어진다. (테두리 색상도 마찬가지로 미세하게 옅어지는 효과가 적용된다.) Depth (깊이) Z축을 이용하여 튀어나오게 만들어 내용을 차별화한다. 그림자가 다시 도입 - 여전히 기본적으로 평평한 디자인을 유지하지만, 깊이를 이용해 원하는 곳을 강조한다. Motion (움직임) 애니메이션 효과를 통해 사용자가 전환 내용을 이해할 수 있도록 한다. Fonts / Icons (폰트와 아이콘) Segoe* UI 폰트로 통일됨 Segoe 아이콘이 윈도우 10에 내장됨 아이콘은 윈도우에 맞게 통일감있게 사용하는 것이 좋다. 사람들은 이미 학습된 아이콘 모습을 보면 자동으로 기존 학습대로 인식한다. 따라서 윈도우의 아이콘을 다른 용도로 사용하면 사용자에게 혼란을 준다. (Font-Awesome 프로젝트에도 유사한 것들이 많이 있다.) Material (재질) 반투명한 시스루 룩을 윈도우 10에서 많이 경험했을 것이다. 이것이 대표적 재질인 아크릴 재질이다. 아크릴 재질은 뿌연 효과를 주기 위해 알파 투명도를 사용한다. 데모: 윈도우10 개인설정을 통해 플루언트 UI를 경험해보자. (20분 05초부터 데모 보기) 윈도우 바탕화면에서 오른쪽 마우스 후 가장 아래 항목인 “개인설정”을 선택해보자. Material (아크릴): 설정 창이 표시되고, 이 창 뒤에 가려진 화면은 반투명으로 비친다. Light (Reveal Highlight): 설정 창 왼쪽 메뉴 부분에서 마우스를 좌우로 움직이면 살짝 더 밝은 부분이 마우스를 따라다닌다. 즉, 미세한 그라데이션 효과가 생긴다. Light (다크 모드 / 화이트 모드): 설정 창 왼쪽 메뉴에서 “색”을 선택하면 다크 모드와 화이트 모드를 선택할 수 있다. Light (Reveal Focus): 설정 창 바깥을 클릭하면 설정 창의 테두리의 강조색이 사라지지만, 다시 설정 창 안쪽을 클릭하면 설정 창의 테두리에 강조색이 표시된다. Fonts와 Icons: 설정 창의 모든 글자와 아이콘은 Segoe UI 폰트와 Segoe 아이콘이다. 데모: 하나는 윈도우10의 설정 창과 모양과 방식이 똑같은 창을 델파이로 만들기 데모 (20분 54초부터 데모 보기) 델파이로 Material (아크릴), Light (하이라이트, 포커스) 등 플루언트 UI를 모두 구현할 수 있다. 이 데모는 델파이 10.4에서 AlMediaDev 라는 써드파티 컨트롤 세트를 사용했으므로 손쉽게 만들었다. (써드파티를 사용하지 않은 구현은 2편에 소개한다) AlMediaDev 컨트롤은 많은 프로퍼티를 통해 플루언트 UI를 반영 수 있도록 한다. 가격도 상당히 저렴하다. 예를 들어, FluentUIBackground 프로퍼티에서 Acrylic을 선택하면 Material에서 아크릴 효과를 줄 수 있다. FluentUIBorder, FluentUIInactiveAcrylicColorOpaq 등 플루언트 UI 구현 관련 속성이 많이 있다. 이 세션은 델파이 세션이기에 앞서 플루언트 UI에 대한 일반 세션이므로 델파이 부분은 생략한다 하지만, 내 블로그에는 다크 모드 / 화이트 모드를 탐지하는 법, 화면 해상도에 맞게 크기 변경 등 여러 코드와 안내가 있다. 델파이 코드 구현 보기: (24분 33초부터 데모 보기) 1편의 관련 자료와 링크 1편 발표 자료 및 원본 아티클 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) (2편 비디오 보기) 목차 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 데모: 델파이로 구현한 플루언트 UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 12분 50초부터 재생하기) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 데모: Almedia 컴포넌트로 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 그림1. 플루언트 UI가 적용된 윈도우 10 개인 설정 창 빛 (Light) 포커스 표현(Reveal Focus): 포커스를 받은 요소의 테두리를 눈에 띄도록 표시 강조 표현(Reveal Highlight): 마우스가 위치한 곳을 더 밝게 표시 깊이 (Depth) 오피스 2019 앱을 실행하면 나타나는 첫 화면에 잘 나타남 클릭할 수 있는 요소 역시 평소에는 평면이지만, 포커스를 받으면 그림자와 함께 3차원으로 튀어나와 보임 모션 (Motion) 윈도우 10 메일 앱을 열면 나타나는 화면에서 잘 나타남 앱의 배경인 구름이 흘러가는 것이 표현되어 생동감을 줌 폰트와 아이콘 (Font & Icon) Segoe UI 폰트 (평소에는 Segue UI의 light 폰트) 와 아이콘으로 통일됨 재질 (Material) 아크릴 바탕(Acrylic), 뒤에 있는 화면을 완전히 가리지 않고 반투명으로 표현, 투명도 적용 데모: 델파이로 구현한 플루언트UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 19분 51초부터 재생하기) 그림2. 플루언트UI가 적용된 Almedia에서 제공하는 데모 앱 그림3. 이 세션에서 사용한 플루언트 UI의 핵심 요소들을 구현한 앱 (델파이만으로 만든 앱과 Almedia를 사용한 앱 모두 깃허브에 소스 코드가 공개되어 있음) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 플루언트 UI의 빛(Light) - 포커스를 버튼에 표현하기: 우측 상단의 최소화 버튼 (비디오 20분 43초부터 재생하기) TRectangle [최소화 버튼] 이미지를 넣고, 그 안에 TFillRGBEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. 플루언트 UI의 깊이(Depth)를 버튼에 표현하기: 섹션 카드 (비디오 21분 28초부터 재생하기) TRoundRectangle 안에 TLabel과 TShadowEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. (TShadowEffect의 Enabled 속성이 True 이면 그림자가 표시된다.) 플루언트 UI의 재질(Material)을 버튼에 표현하기: 화면의 왼쪽 영역 (비디오 22분 42초부터 재생하기) 투명도 구현은 생각보다 쉽다 (의외로 많은 사람들이 어렵거나 불편한 방법을 사용하고 있다.) VCL에서는 TForm의 (AlphaBlend속성이 True이고) AlphaBlendValue가 255이면 불투명이다. 값이 0으로 가까이 갈 수록 더 투명해진다. FMX는 화면 그리기 방식이 VCL과 다르다. TForm의 Transparency 속성을 True로 주면 투명해진다. 그리고 나서 각 섹션에서 Opacity 속성을 사용해 투명도를 정한다. 이 데모의 FXM 폼에서는 BorderStyle 속성을 None으로 주어 테두리가 평소에 보이지 않도록 했다. 그리고 나서 화면 왼쪽의 TPanel의 Opacity 속성을 0~1 사이 값으로 설정하여 조절한다. (1 이면 완전히 불투명하다.) 이 데모의 TPanel의 투명도를 설정하는 부분은 우측 본 화면의 아래 쪽에 있다. TSpinBox를 통해 값을 받는다. // TSpinBox의 OnChange 이벤트를 처리하는 코드 // 0˜10까지 값을 받으면, 해당하는 Opacity(0~1)가 반영되도록 한다. procedure TForm1.SpinBox1Change(Sender: TObject); begin if SameText(Spinbox1.Text, '10') then Panel1.Opacity := 1 else Panel1.Opacity := StrToFloat('0.' + Spinbox1.Text); end; '플루언트 UI의 빛(Light) - 포커스를 폼 자체에 표현하기 (비디오 25분 19초부터 재생하기) 멀티플랫폼용인 FMX에서는 TForm의 OnActivate와 OnDeactivate 이벤트에서 포커스를 받았는지를 알 수 있다. 참고로, 윈도우 전용인 VCL에서는 TApplication의 이벤트을 사용해야 포커스를 받았는지를 알 수 있다. // ‘플루언트UI의 빛(Light)-포커스’를 OnActivate에서 강조, OnDeactivate에서 해제하는 코드 // [참고]윈도우 전용인 VCL에서는 TApplication을 사용해야 포커스를 받았는지를 알 수 있지만, // 멀티플랫폼용인 FMX에서는 TForm에서 가능하다 procedure TForm1.FormActivate(Sender: TObject); begin UpdateFocus(True); end; procedure TForm1.FormDeactivate(Sender: TObject); begin UpdateFocus(False); end; procedure TForm1.UpdateFocus(const IsFocussed: Boolean); begin // 창이 선택된 상태이고 AND 창이 최대화되지 않은 상태라면 // 창의 테두리 선을 표시하여 강조한다. if IsFocussed and (WindowState <> TWindowState.wsMaximized) then begin Line1.Stroke.Color := GetAccentColor(claRed); FillRGBEffect2.Color := Line1.Stroke.Color; FillRGBEffect3.Color := Line1.Stroke.Color; UpdateTransparency; end else begin Line1.Stroke.Color := claWhite; UpdateTransparency; // 창이 최대화된 경우, 투명도가 적용되지 않아야 한다. end; Line2.Stroke.Color := Line1.Stroke.Color; Line3.Stroke.Color := Line1.Stroke.Color; Line4.Stroke.Color := Line1.Stroke.Color; end; 가장 위쪽 툴바에서 마우스를 누른 상태로 창의 위치를 옮기도록 구현 하기 (비디오 26분 57초부터 재생하기) Mousedown 이벤트를 사용한다. // 창에 Title Bar가 없는 경우, 가장 윗쪽 툴바를 마우스로 누른 상태로 창의 위치를 옮길 수 있도록 하는 코드 // Mousedown 이벤트를 사용한다. procedure TForm1.Panel7MouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); begin if (Button = TMouseButton.mbLeft) then if WindowState <> TWindowState.wsMaximized then StartWindowDrag; end; 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내기 (비디오 27분 59초부터 재생하기) // 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내는 코드 function GetAccentColor(const TheDefault: TColor): TColor; const TheKey = 'SOFTWARE\Microsoft\Windows\DWM\'; TheValue = 'AccentColor'; var Reg: TRegistry; AccentCol: DWord; sStr: string; begin // 데스크톱 윈도우 관리자에 없는 값을 아래 레지스트리에서 가져올 수 있다: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\ // // 이 레지스트리에서 "AccentColor"의 DWORD 값을 찾는다. 이값은 창 테두리, 엣지 브라우저의 텝 등등에 적용된다. // // 해당 키의 전체 경로: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\AccentColor // Result := TheDefault; Reg := TRegistry.Create(KEY_READ); try Reg.RootKey := HKEY_CURRENT_USER; if Reg.KeyExists(TheKey) then if Reg.OpenKey(TheKey, False) then try if Reg.ValueExists(TheValue) then begin AccentCol := Reg.ReadInteger(TheValue); // AccentColor를 읽어서 8자리 헥사(Hex) 숫자로 변환 sStr := IntToHex(AccentCol, 8); // (Hex 값임을 표시하는) 첫 2자리 0x를 제거 sStr := Copy(sStr, 3, Length(sStr) - 2); // 이제, "$FF"를 앞에 놓고 RGB값을 뒤에서부터 떼어내어 델파이의 TColor에 맞추기 // // [참고] 델파이의 TColor에 맞추는 방법으로 GetRValue(), GetGValue() 등 훨씬 좋은 것들이 있다. // 이 방법을 쓰는 이유는, 편한 함수를 제공하는 유닛을 포함하지 않아도 되기 때문일 뿐이다. Result := TColor(StrToIntDef('$ff' + Copy(sStr, 5, 2) + Copy(sStr, 3, 2) + Copy(sStr, 1, 2), TheDefault)); end; finally Reg.CloseKey; end; finally Reg.Free; end; end; 그림4. 윈도우 레지스트리에 있는 강조색 (Accent Color) 값 데모: Almedia 컴포넌트를 사용하여 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) Almedia 컴포넌트는 플루언트 UI를 미리 반영해 두었으므로, 바로 사용하면 된다. 예를 들어, TscStyledForm에는 FluentUIAcrylicColor, FluentUIBackground, FluentUIBorder…의 속성이 이미있다. 라이선스 가격은 US$99 이며, 업데이트가 평생 무료로 제공된다. (다른 소프트웨어와 매우 다른 경우이다.) 참고로, 발표자(Ian Barker)는 Almedia 컴포넌트와 아무 관련이 없고, 단지 좋아해서 소개하는 것일 뿐이다. 윈도우 10 테마에 사용할 수 있는 델파이 테마 델파이의 'Windows 10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 Almedia 컴포넌트는 속성과 메소드가 매우 많아서 처음에 혼란스러울 수 있다. 하지만, 일단 한번 하고 나면 훨씬 쉬울 것이고, 매우 유용한 컴포넌트임을 알 수 있을 것이다. 이와 별개로, FMX 역시 UI구현이 매우 유연하고 강력하므로 FMX만 가지고 (소스 코드를 쓰지 않고) 플루언트UI를 구현하는 것도 매우 쉬웠다. 플루언트 UI는 훨씬 더 많은 것들이 있다. 이 세션의 간단한 데모는 플루언트 UI의 핵심을 중심으로 다루었으므로 좋은 시작점이 될 것이다. 이 세션에는 없지만 모션(Motion)을 구현하려면 Animation을 사용하면 된다. // AlmediaDev 컴포넌트로 개발하는 경우에도, 윈도우 테마를 맞춰주는 코드가 필요하다 procedure TVCLCalculatorForm.FormCreate(Sender: TObject); begin MatchWindowsTheme; ... end; // 윈도우 테마를 맞춰주는 코드 // [참고] Font.Color는 clWindows로, Font.Name은 Segoe로 되어 있어야 한다. procedure TVCLCalculatorForm.MatchWindowsTheme; var GoDark: Boolean; iInt: Integer; AButton: TComponent; begin // 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 // 델파이의 'Windows10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 SetAppropriateThemeMode('Tablet Dark', 'Windows10'); GoDark := DarkModeIsEnabled; // 이 코드는 Carbon 테마가, 윈도우 다크 테마와 잘 맞지 않기 때문임 for iInt in cNumberButtons do begin AButton := FindComponent('scGPButton' + IntToStr(iInt)); if (AButton <> Nil) then if (AButton is TscGPButton) then if GoDark then TscGPButton(AButton).Options.NormalColor := clBackground else TscGPButton(AButton).Options.NormalColor := clWindow; end; end; procedure SetAppropriateThemeMode(const DarkModeThemeName, LightModeThemeName: string); begin SetSpecificThemeMode(DarkModeIsEnabled, DarkModeThemeName, LightModeThemeName); end; procedure SetSpecificThemeMode(const AsDarkMode: Boolean; const DarkModeThemeName, LightModeThemeName: string); var ChosenTheme: string; begin if AsDarkMode then ChosenTheme := DarkModeThemeName else ChosenTheme := LightModeThemeName; TStyleManager.TrySetStyle(ChosenTheme, False); end; 2편의 관련 자료와 링크 2편 발표 자료 및 원본 아티클 사용된 Fluent UI 구현 소스 코드 다운로드 (깃허브) 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) << UX Summit 2020 목록으로 이동 View full 엠바카데로 기술자료
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.