티스토리 뷰

문득 필요한 걸 찾기 위해 구글보다 Foundation에서 구현되어 있는 것을 먼저 보는게 가끔은 더 빠르다는 것을 깨닫고 쓰는 것.

 

보통 디스크 캐싱할 때 URL의 lastcomponent를 부르면

http://www.abc.com/imimage.png 이런식으로 URL이 있다면 imimage.png로 깔끔하게 불린다.

 

난 이런 경우만 경험해봤는데 안돌아 가는 것 아니겠니? 멘붕이 왔잖니 키키

 

생각해보니

http://www.abc.com/imimage.png/resize/512x512/optimize 이렇게 되어 있어서 모든 아이들의 파일명이 optimize로 같아지는것 아니겠니. (말투 왜이러니?...티아라의 왜이러니 듣고 있어서 그럼ㅋㅋ)

 

보통 같으면 extension URL 해서 string parsing 하려고 할텐데 요즘은 그냥 바로 정의/구현 된 부분 찾으러 간다.

페어프로그래밍을 하면서 문제 해결 방식에는 여러가지가 있다는 것을 깨달았는데

그 중 무작위의 추측성 디버깅이 아닌 근거를 가진 추측성 디버깅이 꽤 도움이 되더라.

무작정 print나 breakpoint 걸어서 분기문에 들어왔는지, call stack을 확인하는 것 보다

원인이 될 법한 곳에서 논리적으로 생각하려는 노력이 오히려 디버깅하는 시간을 더 단축시켜주는 듯 하다.

 

지금 해결하고 있는 건 이렇게까지 대단한 문제는 아니지만

생각을 더 많이 할 수록 stackoverflow 보다 apple에서 제공해주는 자료들이 더 빠른 해결책을 줄 수도 있다는 깨달음을 적용해보려고 한다.

lastPathComponent라는 게 있으면 firstPathComponent, pathComponents 뭐 이런게 있지 않을까.

아니면 비슷한 것이라도.

바로 위에 있는거 시롸? 이름도 똑같이 생각해낸거 롸아아?

네, return 받은 배열로 .png 갖고 있는 애로 뽑아내려고 합니다.

깔깔. (별거 아닌데 괜히 기분 죠하 키키)

 

오늘도 무사 해결!

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함