(말씀)
이 기사는 당사의 Organization 을 이용하여 사내 서비스 개발에 Scala+PlayFramework를 도입하는 데 있어서의 작업 내용이나 시행착오를 기록한 연속 투고가 됩니다.
기본적으로 내용이 정확하고 독자에게 유익한 정보가 되도록 배려하고 있습니다만, 어느 쪽이라도 사내에서의 정보 공유를 주목적으로 하고 있기 때문에,

정합없는 정보의 배열

정확하게 검증되지 않은 정보

등을 기재할 수도 있습니다. 미리 양해 바랍니다.

왜 Scala (사내 정책)

당사 하지만 엔지니어 팀은 평소에는 PHP, Ruby 등을 사용하여 개발하고 있습니다.
보치보치 엔지니어의 채용도 본격화해, 수탁도 자사 서비스도 확대하는 가운데, PHP, Ruby에 이은 「제3의 개발 언어」를 늘리려고 하는 것이 되었습니다. 주된 이유를 정리하면 이런 느낌입니다.

외부를 위해 회사의 기술적 노력에 대한 호소

프리랜서 엔지니어 쪽과의 관계가 많기 때문에, Scala로 개발하고 있습니다 라고 하는 것이 커뮤니케이션의 좋은 계기가 되는 것도 기대.

위탁 개발을 위해 클라이언트에 대한 언어 선택을 늘립니다.

특히 웹 서비스의 스타트업에 관련되는 경우, 개발 언어의 선택은 장래의 채용에 크게 관련될 것으로 생각하고 있습니다.

사내 기술 의식의 향상, 최신 기술에의 캐치 업

Scala에서의 개발 경험/흥미가 있는 향상된 마음의 엔지니어가 입사하고 싶다! 라고 생각해 줄 수 있는 엔지니어 팀 만들기.

Scala+PlayFramework에 기대하고 싶은 것(기술면)

편하게 말하면, 「정적 언어와 Rails계 프레임워크의 Web 개발 효율의 좋은 토코취」를 할 수 있으면 좋다고 생각하고 있습니다.

유형 + 함수 언어로 안전하고 견고하며 가독성이 높고 유지 관리하기 쉬운 코딩

그래서 Ruby on Rails에 가까운 신속하고 효율적인 웹 개발

테스트 코드를 작성할 수 있다면 가능한 한 많이 작성하고 싶습니다

개발 내용

실제로 가동하고 있는 자사 서비스(PHP5.4+CakePHP2)의 리플레이스.
라고는 해도 풀 리플레이스를 갑자기 시작하면 절대로 끝나지 않기 때문에, 관리자용의 새로운 기능 등, 현행 사이트와 병행 가동시킬 수 있는 곳으로부터 시작해, 차분히 이행해 가는 것 같은 이미지입니다.

사내 스칼라 경험

일절 없음.
농담 빼고 경험자 제로의 상태로부터, 무모하게도 스타트했습니다.
기술 선정에 있어서 Scala의 언어 사양이나 PlayFlamework의 특징이나 평판에 대해서는 어느 정도 조사하고 있습니다만,
이 기사를 쓰는 시점에서 메인 개발 담당 ( @zaramme )은 아직 한 줄도 Scala 코드를 작성한 적이 없습니다.

게다가 사내 자원이 별로 나눌 수 없는 경우가 있어 실질 스컹크워크 에서의 개발이 됩니다.

어떻게 될까.

(다음 번)
Scala + PlayFramework 환경 선택 (Scala, Play 버전 설정, 개발 환경 및 편집기 정비)