광장
SW 기술자들의 현실 자주 가는 사이트인 안드로이드펍에서 퍼왔습니다. 출처는 아마도 ITonAir.왠간한 SW기술로 먹고 살기에는 10년 전부터도 늘 좋지만은 않은 상황이지만 희망도 역시 늘 함께인 것 같아요.
광장
SW 기술자들의 현실 자주 가는 사이트인 안드로이드펍에서 퍼왔습니다. 출처는 아마도 ITonAir.왠간한 SW기술로 먹고 살기에는 10년 전부터도 늘 좋지만은 않은 상황이지만 희망도 역시 늘 함께인 것 같아요.
광장
검색엔진 최적화에 대해 네이버나 다음과는 다르게 웹사이트를 크롤링해서 검색순위가 조정 되는 구글이나 야후 등의 검색엔진에 사이트를 최적화 시키기 위해 title, keywords, subject, description 등의 메타 태그를 조정해 보았으나 한계가 있더군요.한글과 영어를 모두 지원하는 사이트인데 기본 언어가 한글이라 그런지, 한글 키워드 검색으로는 그나마 괜찮지만, 영..more
ToFinder님 http://kimstone.tistory.com/291 에 보시면 메타테그를 활용하여서 검색능력을 향상?
고무고무님
아하! subject와 description을 영어로 적어도 yahoo.com에서 검색결과가 한글로 나오는 이유가 content-language 때문이었나보군요! 링크까지 챙겨주시는 자상함... 감사합니다^^
구글은 하도 자세히 긁어가서 이미지봇 블락시켰네요...ㅎㅎ
05.16 13:17
ToFinder님 저도 자세히는 잘 모르지만 느낌상 그렇습니다. kr로 하니 한글로 인식하겠죠. 또한 구글은 로봇이 안오더라도 긁어가도록 유도하는것중에 가장 효과적인것이 애널릭틱스를 활용하는것입니다. 구글정책상 구글 api를 사용하는 홈페이지의 정보를 가져간다는 것이 있는지 로봇이 오지 않더라도 api의 실행만으로 구글에 등록되어지더군요 ㅎㅎ 05.16 15:12
댓글 테마 관련한 이번 이슈에 대해...오늘 알게 되서 링크도 가보고 쭈욱 보았습니다.서로 배려가 없었군요... 사용자는 개발자를, 개발자는 사용자를 조금 더 위해주었다면일어나지 않았을 (그래서 여지껏 일어나지 않았던) 상황이네요.킴스큐 쪽에서는 개발자가 마켓에 모듈이나 테마를 올릴 때,사용자 대상을 선택할 수 있는 단계를 추가해 주시는 것도 방법일 듯 합..more
베르메르님
그런식으로 나눠도 어차피 설치 질문글은 올라올것 같은데요...ㅎㅎ
친절할수밖에 없는 유료기술지원 같은건 어떨까 싶네요.
중급자들은 기술지원이 필요없는데 높은 가격을 주고 살 필요없으니...
상품가격은 더 낮춰질수도 있고....
고무고무님 그런 방법도 있겠군요. 근데 누가 그 기술지원을 하느냐에 대해 현실적으로 생각해 볼 필요가 있지 않나 합니다. 저는 킴스큐에서 즉시 시행이 가능한 간단한 방법을 생각해 보았던 거에요. 02.27 22:08
인포님 hulkzone님의견에 한표 더합니다.~~
2012.02.27 21:00
ㆍ덧글(2)
아가싱즈님 한표받고 두표 더 ~~ 02.27 21:08
고무고무님 두 표 받고, 두 표 더~~!ㅎㅎ 02.27 22:06
새로운 모듈 개발의 진입 장벽... 기본 모듈(코어)과 새로운 모듈 개발의 진입 장벽... 기본 모듈(코어)과는 다른 새로운 기능을 가진 모듈을 개발할 때, 자체적으로 개발 진입장벽이 있지 않나 합니다. 바로 사용상 호환성, 배포상 호환성 문제인데요. 가령 카테고리를 문자열이 아닌 id로 DB에서 관리하는 게시판 모듈(A)을 만들면, 기본 게시판 모듈과는 호환이 되지 않으므로 많은 기존 게시판 테마를 포기해야 ..more
hulkzone님 좋은의견 ^^
고무고무님 아니, 훈남 헐크존님께서 댓글을... 감사합니다^^ 02.22 17:08
사용자 이슈
게시판 카테고리의 유연성 현재는 1.카테고리가 게시판에 속해 있고,또한 2.문자열 자체를 값으로 갖고 있기에 (gid, bid 처럼 고유 id가 아니라)카테고리 및 게시판 관련 모듈 개발, 다국어 사이트 구현에 있어서또 그와 연계해 URL에서 cat= 등으로 사용함에 있어 문자열이 직접 사용되므로게시판 모듈 관련 유연성을 떨어뜨리며 개발에도 불편한 부분이 있습니다.시장의 다른 모듈..more
세븐고님
카테고리의 경우 kimsq oss 에서는 말씀하신 형태로 별도의 table 을 두어 처리하였으나 rb에서 다시 텍스트 형식으로 변경되었습니다.
이는 각각의 방식이 갖는 일장일단중 후자가 갖는 장점에 더 큰 비중을 두었기 때문인데요.
모듈의 추가/제외 방식인 rb에서는 기본게시판 모듈외에 앞으로 추가적인 게시판모듈들이 등록되리라 기대하고 있습니다.
그때라면 다른 방식으로 카테고리를 처리하는 게시판모듈이 추가될 수도 있을 것이라 생각합니다.
하나의 모듈로 다양한 니즈를 모두 충족시키기 보다는 다양한 모듈로 접근하는 것이 낫다고 생각하고 있습니다.
고맙습니다.
고무고무님 oss에서는 그랬었군요... 그런데 제 얘기는 하나의 모듈로 다양한 니즈를 중촉시키자는 것이 아니라, 기본 모듈의 기능과 범위가 더 확대 되어야 하지 않나 하는 겁니다. 목적은 마켓의 활성화이고요. 답변 고맙습니다. 02.21 18:03
킴스큐Rb 쓰면서 좋은 점은,속도가 정말 빠르다는 것과든든한 개발진이 항상 업그레이드를 위해 노력하고 있다는 것.그리고 시간이 잘 안 나긴 하지만, 알면 알수록 모듈 개발 등으로 파고 들고 싶어진다는 것...제일 먼저 느껴지는 안 좋은 점은,알림 다이얼로그가 매번 떠서 클릭을 너무 많이 해야 한다는 것.차후 소셜팩에서는 그런 부분에서도 트위터나 페북처럼 클..more
아가싱즈님 제목만 보고 킴스큐가 '든든한 개' 라고 한줄 알았뜸.
2012.01.20 11:28
ㆍ덧글(1)
태지포레버님 ㅋㅋㅋ.. 저도 든든한 개... 까지만 보고 갸우뚱 했습니다. 01.20 19:59
홈바이블님 ㅋㅋㅋ 아무 생각 없이 제목을 넘기고 차분하게 '고무고무'님의 글을 읽고 '아~! 그렇구나' 하고 댓글을 달려고 하다가 '아가싱즈'님 댓글 보고 그만 웃다가 무너짐. ^^;
redred님 완전 동감입니다.
다국어 처리에 있어서 언어와 다른 부분을 완전히 분리하여 어색하 다국어 처리에 있어서 언어와 로직을 완전히 분리하여 번역문이 어색하게 되는 문제보다는 해당 문장을 가진 액션이나 테마들을 복수로 관리하는 게 더 어려운 문제라고 생각하기에, 1.1.0 버전에서 lang 부분이 action, theme 등의 부분과 분리 되길 바랬는데... 그대로 가네요.개인적으로는 안드로이드처럼 언어와 동작이 완전히 분리 되었으면 좋겠는데,..more
dobiz님 본격적으로 글로벌 진출을 노리고 있는 것으로 알고 있는데,
dobiz님 예를들어 현재의 언어팩 시스템 구조를 비슷하게 취하되, 각 파일에서 사용된 모든 문자열을 단 하나의 랭귀지파일로 추출해서 저장해놓으면 추후 비슷한 어순을 가진 언어팩들을 만들 때 랭귀지파일만 수정하면되니 효율성이 좋아지겠죠. RBX의 경우도 기본이될 영어팩에서 랭귀지파일만 뽑아놓으면 같은 어순의 언어팩을 만들 때 파일 하나만 번역하면 되니 글로벌화 하기에도 효율적이고요 :) 01.04 17:15
고무고무님 문법적 문제를 언급하시는 이유를 잘 모르겠는데요... 혹시 인터넷 번역기의 경우를 말씀하시는 건가요...?? / 일단 현재 구조의 가장 큰 문제는 번역을 수정해야 할 때가 아니라 소스코드를 수정해야 할 때입니다. 01.05 13:40
dobiz님 예전 경험을 떠올리면 단어나 문장으로만 구성된 경우에는 큰 문제가 없지만, 변수를 포함하고있는 문장들의 경우에는 간혹 문제가 되기도 합니다. 대부분 변수가 목적어로 쓰일 때인데, 이 경우는 문자열만 모아둔 파일의 수정만으로는 어색함을 피하기 어렵더라고요. 01.05 15:00
고무고무님 아, 변수가 문장 안에 쓰일 때를 말씀하신 거군요. 제가 내공이 부족하여 못 알아봤습니다;;; 글로벌한 관점으로 보면 우리나라와 일본 등의 경우가 예외적인 어순을 갖는 언어이니, 말씀대로 영어 언어팩을 중심으로 라틴 계열 언어들을 처리하고, 우니나라 등은 따로 언어팩을 만들면 괜찮을 것 같아요~ 01.05 17:55
고무고무님 킴스큐에서 문장을 모아놓은 파일을 따로 안 만들고 코드에 넣은 큰 이유 중 하나는 해당 문장을 누군가 번역할 때 어떤 뉘앙스로 해야하는지 구분할 수 없기 때문인 것으로 알고 있습니다. 어떤 상황에서 문장이 사용 되는지 모르니 코드에서 문맥을 파악하여 자연스럽게 번역하라는 것인데, 문제가 좀 있습니다.ㅠㅠ
고무고무님 번역이 필요할 때마다 번역자와 개발자 두 명이 함께 작업을 하던지, 아니면 한 사람이 코드를 읽는 능력과 번역하는 능력을 모두 갖춰야하며, 더 큰 문제는 유지보수에서 굉장히 해결하기 힘든 이슈들을 만들어 냅니다. 그 중 가장 큰 문제는 역시 코드의 한 줄을 수정하려면 모든 lang.* 폴더의 파일을 고쳐야 한다는 것이겠습니다. 그래서 저는 언어는 코드와 반드시 분리하되, 문맥에 맞는 번역을 위해서는 번역 기간 동안 번역자와 개발자 사이의 활발한 의견교환 채널의 유지,와 같은 방법으로 해결해야 하지 않나 생각합니다.
redred님 제가 소스단에서 영어 번역을 하면서
고무고무님 그런 좋은 방법이 있다면 시급히 도입을 해야겠네요... 01.06 17:16
ㆍ실명/생일 : 이혁수 - 03/06
ㆍ나이/성별 : 32세 (남성)
ㆍ분야/지역 : 기획자 (해외)
ㆍ가입일자 : 2011.05.25 (360일전)
ㆍ최근접속 : 2012.05.17 (2일전)
ㆍ회원등급 : 2,390P (비기너 4)
ㆍ홈페이지 : 미등록