현재 공연 검색 머신의 개량을 계속하고 있습니다

현재 공연 검색 머신의 개량을 계속하고 있습니다

처음에는 이런 생각으로 움직이고있었습니다

"GAE / J는 불안정 무서워서, PHP 버전을 만들고 그쪽으로 갈아 탄다. 그래서 공부를"

 PHP 대해서는 우선 GAE / J 판과 같은 것을 만들만한 지식은 흡수 할 수 있고,

오히려 PHP 연습을하는 가운데, Wikipedia 자체의 지식든지 MediawikiAPI든지 XML든지

Wikipedia를 이용한 서비스를 만든다면 알고있어 당연 지식

(그렇지만 몰랐던 지식)을 얻을 수있었습니다

그것을 바탕으로 PHP 버전을 만들려고하면

"할 수가 너무 많아서 오히려 산만!"라는 것이 지금의 고민입니다

 가장 큰 것은 역시 "기사 이름 (≒ 고유 명사)가 속한 카테고리를 얻을 수있다"라는 것이군요

그것은 사람 이름이거나, 작품 명이거나,

인물이라면 어떤 직업의 사람 또는

작품이라면 애니메이션인지 게임인지 ...

구조 적으로는 지금까지 쓴 것처럼

기사의 카테고리를 읽거나 템플릿을 읽거나 할뿐입니다 만,

그 정보를 결합하여

또한 새로운 문을 연다 (새로운 서비스로 연결) 것이 아닐까 생각합니다.

그러던 중 문득 GAE / J 버전의 코드보고 있으면 "지금이라면 이렇게 쓰는데 '라는 아이디어가 떠올라

PHP 버전이 언제 끝날지라는 것인지 완성시킬지도 보이지 않는 현상이므로

실제로 서비스 인하고있다 GAE / J 판에 손을 넣어 가려는 생각에 이르렀습니다

GAE / J의 안정성에 대해서는 솔직히 아직 회의적인데

상당히 오랫동안 가만히 바람에 (로그를별로 보지 않은 탓에)

불신이 약간 누그러 있다는 것은 개발을 재개 한 이유일지도 모릅니다

어째서 요 며칠 사이에 손을 넣은 부분

· Wikitext의 취득을 HTML 아니고 MediawikiAPI에 요청하여 XML에서 얻을 수 있도록했다.

지금까지는

푸른 꽃 _ (만화) & action = edit

에서 얻을 수 있던 것을,

푸른 꽃 _ (만화)

에서 얻을 수 있도록했습니다.

상식적으로 생각하면 후자. 응답 개선. Wikipedia 서버 친화.

상식이 없어서 미안 해요.

· 입력에 오탈자가 있어도, 가능한 범위에서 인물을 특정하도록했다.

지금까지 사용하시는 분의 입력에 대해 Wikipedia 기사가 존재하지 않으면 그 시점에서 아웃이었습니다.

기사 이름은 조 _ (배우)이나 이토 켄타로 _ (성우) 라든지 타나카 리에 _ (체조 선수)처럼

괄호 안의 물건이 있기 때문에 이들을 보충으로 수정 한 정도입니다.

정확한 입력을 요구 때문에 그 부담을 경감하려고하면 풀다운 목록 = 성우 이름의 목록을 추가했지만,

현재 올바른 입력이되지 않고 그 자리에서 튕겨 않도록되어 있습니다.

일부러 드롭 다운 목록에서 선택보다 히라가나로 카챠 카챠 계속 치면 공격하기 때문에,

몇 배 노력이되었다고 생각합니다 (^^ ;;

지금의 흐름을 소개합니다.

이용자의 입력을 받아

→ 과거에 그 단어 등록이 없기 때문에

→ 검색 엔진에 문의

→ 검색 엔진에 Wikipedia 기사 중에서 맨 위의 것을 제시하고

→ 얻은 Wikipedia 기사 이름에 대한 공연 검색 머신이 처리를 재개

평평하게 말하면

성우의 이름을 히라가나로 꾸물도 한자 표기의 검색 결과가 표시되는 지요? 라는 이야기와

그 뒤에 Wikipedia라고 붙여 검색하면 맨 위에 Wikipedia 기사가 오는군요? 라는 이야기로,

요점은 이것을 사용하여 올바른 검색어 유도하고 있습니다. 원리는 매우 원시적이지만 유효합니다.

히라가나 이외에도 「오징어 딸 성우 "라든지,"에미린 "등으로도 검색 할 수 있습니다.

하나 문제있는 것은 "프로그램에 액세스하고도 상하지 검색 서비스를 찾을 수"인 것입니다 만

당 블로그로 여기를 추천 해 둡니다.

풀다운 목록은 다른 사용 방법을 생각할시기 이지요 ...

· 검색어와 검색 결과의 대응을 캐시와 데이터 저장소에 저장하도록했다.

같은 검색어인데 일일이 외부 서비스에 문의 있으면 걸리는데 저장합니다.

좀 더 정확히 말하면

"캐시는 Map 필드가있는 직렬 가능한 클래스 객체를 생성하고 저장"

"데이터 저장소에는 Map를 XML로 변환하고 Text 객체로 저장"

"캐시가 나는 경우 데이터 저장소에서 복원"

"일반적으로 캐시에 새로운 검색어를 추가하고 있고, 정기적으로 데이터 저장소에 저장"

입니다.

부끄러운 이야기 캐시해서 데이터 저장소로도

지금까지 단순한 쉼표로 구분에서만 데이터를 취급 오지 않으며 때문에

처리가 매우 끝났 습니다만,이 점에 대해서도

"괜찮은 데이터 구조로 바꾸어 나가는 것 '앞으로 개선해 나갈 것입니다.

(제대로하지 않은 데이터 구조는 아직 많이 남아 있습니다.)

이용자 여러분은 응답의 개선과 오류 감소,

다음은 좀 더 빠른 확장을 약속 할 수 있다고 생각합니다.

그래서,

지난 몇 개월 동안 계속 PHP를 쓰고 있었는데,

몇 달 전 자신이 GAE / J에 실리지 않았던 기능을 왜 지금 실리 게되었는지,라고하는 것은,

정말 이상한 생각이 있습니다.

PHP를 쓰면 쓸수록, Java의 지식은 잊어가는 불필요한 쓸 수 없게되어 간다고 생각하고 있었는데,

(GAE / J 버전은 이미 ほとこ, 정도의 느낌이었습니다 만) 정반대의 것으로되어 있습니다.

하나는 PHP 오류 메시지가 너무 조각 조각 않았다는 것이 있을지도 모릅니다.

오류 메시지가 안되다 때문에 디버깅시 오류 이유를 고려하는 범위가 넓어졌다 가라고.

휘날리며 코드를 작성할 때이 버그의 원인이 될 것 같은 것은 사전에 방지 버릇이 벌어진 것일까라고.

다른 하나는 "PHP로 할 수 있었 으니까 Java에있는 데쇼"라는 생각 이네요

XML 처리 그렇다 외부 라이브러리의 도입 그렇다 연관 배열의 취급 그렇다 ...

특히 PHP를 연관 배열의 취급은 궁극적 편한 만 (이상 자신 안에 PHP = 연관 배열라고 할 정도입니다)

그 노하우를 Java로 살리려고하니 제대로 컬렉션과 마주하게되는 거죠

PHP를 연관 배열을 실컷하고 나서 컬렉션과 제네릭에 종사하는 경우에, 아주 순조롭게 삼켜 라했습니다.

그리고 PHP를 시작하기 전에 자신은 Java 정규식에서 "여러 줄에 걸쳐 일치"도 못했다.

움직이고있는 코드 중 일부는 아직 전혀 남아 있지만. 정말, 엉뚱 지요.

프로그램의 공부라는 의미 "RPG의 레벨 업 '에 가까운 것이있는 것일까라고 생각합니다.

얼마 전까지 쓰러 않은 적이 쓰러 뜨릴 수있게되었다,라고.

수험 공부 라든지, 자격의 공부 등으로도 그 느낌은 맛볼 수있는 것이지만,

자신은 프로그램의 공부가 향하고있다라고 생각합니다.

자신은 지금 레벨 12 정도 일까. 아직 쭉쭉 오르는시기라고 생각하기 때문에 힘내 자.