[아이디어] 복잡한 로직은 GraalVM JavaScript엔진을..
전기요금을 계산하는 프로그램을 개발해야 했다. 전기요금 계산이 이거 이래도 되나 할정도로 복잡하고, 지역, 계절, 년도등의 변수가 많고, 계산 또한 변수가 너무 많았다.이런경우 이런 계산 로직을 코드로 작성을 하는것보다, 변수에 빠르게 적응을 하기 위해서,다이나믹한 기법을 사용하는게 더 좋을것 같다는 생각을 했다.rule엔진을 사용하는게 좋아보이지만 (drools등), 단순 계산을 위해 rule엔진을 사용하는건 오버엔지니어링이라고 판단을 했다.그리고, rule엔진이 사실, 사용하는게 상당히 번잡하고 복잡하다...먼가 간단하면서, 다이나믹하게 계산식을 적용하고, 반영되게 하는 방법을 원했다. 고민중에 예전에 mocksal이라고 개인 mocking 서비스를 만들때 (https://tech.super100.a..
[아이디어] 대기열 기능 만들기에 대해서
사용자가 갑자기 몰리는 기능, 특히 해당 기능이 무거운 경우 (외부 API연결, 스크래핑, 무거운 쿼리) 사용자의 기능 접근을 의도적으로 일정수준으로 제한을 해야하는 경우가 발생한다. 이런경우, 대기열 기능으로 해당 문제는 해결할수있다. 대기열이란, RateLimiter를 구현하는것이라고 보면 될듯하다.세마포어를 이용해서, 내가 기능에 접근할 최대 횟수를 정하고, 항상 그 횟수안에서 기능의 접근을 허용하고 거부하도록 만드는 구현이다.(가게에 화장실이 x개있고, 사람들이 줄을 서서 화장실에 접근하는 개념 ㅋ) 가장 일반적인 방법은 Redis의 Zset을 활용하는 방법이 있다.이 부분은 AI에이전트들에 물어보면 상세하게 알려줄것이라, 구현의 어려움은 없겠지만, 우리는 어떻게 운용을 해야하는가를 고민해야한다...
[아이디어] 코틀린의 Delegate를 이용한 ReadableMap 구현에 대해서
가끔 Api의 RequestBody로 Map객체를 받아야할 필요가 있다. Api의 RequestBody의 필드값들이 가변적이거나, 요청에 따라 바뀌는경우등의 케이스에 유연하게 대응하기위해서,Map객체를 받게 구현을 할때가 있다. 이경우는 사실 코드상에서의 유려한 흐름으로 읽히는 코드는 포기해야한다.Map req 이런 객체에서 req.get("name"), req.get("age")등으로 꺼내써야 하고,값이 Any 타입으로 선언되어있기 때문에, 캐스팅도 해야하는 코드가 덕지덕지 붙게 됨에 따라,깔끔하지 못하고,개발자가 class로 구성된 DTO와 달리 필드를 바로 확인할수가 없고,문서나 주석등에 의존하거나 코드 전체를 훝어야 한다.... 이런 문제를 문득,코틀린의 Delegate를 사용하여, Map을 개발..
