|
:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
14/10/25 14:57
사실 이름 정하는 게 가장 어려웠습니다.
이름 후보들은 다음과 같았습니다: 쪽보드: 아시는 분은 아실... 공돌공돌해 카드보드: 구글만 쓰냐, 나도 쓰겠다 피지보드: 피지알 + 보드... 근데 피'쥐'보드라고 쓰는 사람들이 나타날까봐 걱정돼서 그만뒀습니다. 바로드: board의 애너그램, barod 원보드: '제로'보드를 대체하니까 호무보드: 마법 소녀 마도카 마기카의 등장 인물 pyBB: phpBB의 패러디. 파이선이니까 py 호무보드의 장점이 하나 더 있는데, 'homuboard'로 구글 검색했을 때 결과가 없다는 것입니다.
14/10/25 15:00
오오 파이썬으로 만들고 있군요! 고생많으십니다^_ㅜ
iOS 개발자로서 시간이 나면 pgr21의 iOS 유니버셜 앱 버전을 오픈소스로 한번 만들어보고 싶긴 하네요. 하지만 맨날 생각만 하고 있다는게ㅠㅠㅠ
14/10/25 15:05
와 고생 많으십니다. 사실 PGR21 은 어떻게 생긴 (기술적으로 뭘로 만들어졌고 운영되는지) 사이트일까... 궁금했었는데 그런 부분이 해결이 되어서 좋네요.
DB 도 다른 걸로 옮기게 되는 건가요? MariaDB 라던가요..
14/10/25 15:35
아직 학교 다니던 시절에 알바로 이런 저런 게시판이니 커뮤니티니 하면서 CMS 아류들 만들때마다 할 일은 많고 시간은 너무 많이 걸려서 참 후달림을 많이 느꼈었는데.. 고생이 많으실 것 같습니다.
도움을 드리면 좋겠는데 파이썬이면 도움 드릴 수 있는 부분이 별로 없네요 크크 화이팅입니다
14/10/25 15:41
짧은 시간에 게시판 골격을 잘 잡으셨군요.
깃헙을 통해서 오픈소스화 하는 것도 저 같은 사람이 운영진 밖에서도 기여 할 수 있어서 좋은 것 같습니다. 다만 게시판 교체는 사용자 경험을 완전히 바꿔버릴 수 있기 때문에 피지알 멸망시나리오가 나올 수 있습니다. 그래서 준비를 충분히 한 뒤에 교체하면 좋을 것 같네요. 스무스하게 넘어가려면 2가지 방법이 있다고 생각되는데요. 첫번째 방법은 기존 게시판과 완전히 동일한 UI의 새 게시판을 작성하는 것입니다. 새 게시판 준비가 완료되면 일시에 마이그레이션 하여 이전하고, 그 이후에 원하는대로 기능수정을 하는 것이지요. 두번째 방법은 기존의 제로보드 DB를 그대로 사용하여 새 게시판을 개발하는 것입니다. 새 게시판을 베타로 오픈하여 계속 작업을 이어나간뒤 적당한 시점에 메인게시판으로 바꿔버리는 것이지요. 그 후에 DB도 손보구요. 피지알 클래식 스킨을 현재의 기본스킨인 새벽안개 스킨으로 바꾸는 작업이 이런식이었습니다. 하지만 DB구조에 게시판 개발도 영향을 많이 받을 수 밖에 없기 때문에 두번째 방안은 현실적으로는 어렵지 않을까 싶네요. 호무보드가 잘 진행되면 좋겠네요. 코드 기여는 게시판이 거의 완성되었다는 느낌이 들 때 쯤에 해볼 마음이 들 것 같습니다.
14/10/25 16:45
저도 첫 번째 방법이 괜찮다고 생각합니다. 제로보드 데이터베이스를 그대로 쓰는 건 너무 괴로울 것 같아서요...
사실, 마이그레이터 만들면서 충격도 좀 먹었습니다. 제로보드가 트랜잭션, 외래 키, constraints 같은 걸 전혀 고려하지 않고 만들어졌다 보니, 데이터베이스 내용 자체에도 버그가 있더군요. (사실 그 시절 MySQL은 그런 거 지원 안 했으니 어쩔 수 없지만...) 대표적인 예가, 아이디가 같은 회원이 몇 명 존재합니다. (!) 아마 데이터베이스를 복원하면서 중복으로 들어간 것 같아요. 이런 문제도 UNIQUE 제약 조건을 걸었다면 발생하지 않았겠죠. 마이그레이션 진행하면서 오류가 나길래 보니까 아이디가 중복이더군요... 아무튼, 기여를 받을 수 있게 되면 좋겠군요. 열심히 만들겠습니다!
14/10/25 15:46
운영진이던 시절에 장고로 옮기려고 db스키마 만들고 마이그레이션하고 잠시 쉬던 도중에 운영진 짤려서 그냥 버렸는데 괜히 지웠네요
제로보드 구조가 그렇게 어려운건 아니라 마이그레이션은 금방 만드실거고 아마 프론트엔드에서 힘들지 않을지.. 참여할수도 있지만 flask라서 굳이 새로운걸 배워가면서 하기는 여유가 부족해서.. 다른분들께 기회를 넘깁니다. 수고하세요!
14/10/25 16:48
장고 난이도가 TOP라면 플라스크는 커피입니다! (?)
어차피 파이선이고 같은 웹 프레임워크고 하니 개념은 비슷한 것 같아요. 기회 되면 도와주세요!
14/10/25 15:53
고생하십니다~! 그래도 다이아몬드는..크흠
그럼 이거 있으면 피지알 짝퉁 홈페이지를 만들어 요리조리 고쳐보고 할 수 있는건가요? 흐흐
14/10/25 16:49
네. Reddit도 사이트를 만드는 데 쓰인 소프트웨어를 오픈 소스로 공개해서 누구나 Reddit 클론을 만들 수 있게 해 놨는데, 비슷한 느낌이라고 생각하시면 될 것 같습니다.
14/10/25 17:53
뭔말인지 모르겠지만 운영진 갈아서 만드는 거라는거는 알겠습니다. ㅠㅠ
앞으로 트래픽 잡아먹는 엄한 뻘글은 자제하겠습니다.
14/10/25 19:18
오, 좋은 질문입니다! 그렇지 않아도 답하고 싶던 질문이었어요.
제가 한동안은 SQLAlchemy를 잘 쓰다가, 요즘 좀 흔들리고 있습니다. 아시다시피, SQLAlchemy는 평범한 ORM이 아닙니다. ORM을 쓸 때 발생할 수 있는 온갖 문제들에 대응을 해 놨으며, 필드를 미리 로드할지 안 할지 여부도 정할 수 있는 등 시시콜콜한 부분까지 섬세하게 만질 수 있죠. 그런데 요즘 들어 느낀 것입니다만, SQLAlchemy가 제공하는 추상화 수준에 비해 수고가 너무 많이 드는 게 아닌가 하는 생각이 들기 시작했습니다. 예를 들어, SQLAlchemy는 N+1 문제를 해결한 좋은 ORM입니다만, 그냥 되는 건 아닙니다. joinedload() 라는 걸 쓰죠. session.query(User).options(joinedload('post')).all() 그런데 이게 맞긴 하지만 어딘가 좀 쓸데없는 군더더기가 많은 것처럼 느끼기 시작했습니다. SQLAlchemy의 저자도 밝히고 있지만, SQLAlchemy는 여타 ORM처럼 SQL을 대체하려고 나온 게 아닙니다. 오히려 SQL을 잘 알아야 SQLAlchemy도 잘 쓸 수 있게 되는 것입니다. 위의 문장이 SQL로는 아래의 문장으로 바뀐다는 것을 확고하게 이해하고 있어야 쓸만하다는 거죠. SELECT user.id, post.id, post.name FROM user JOIN post 그런데 이런 변환 과정이 머리 속에 바로 그려질 정도라면, 그냥 SQL 문을 써도 가독성에 별 차이가 없지 않을까요? 실제로 저는 같은 일을 하는 위의 두 가지 표현 중 어느 게 더 읽기 좋고 쓰기 좋은지 잘 모르겠습니다. 어찌 보면 SQL이 더 좋아 보이기도 하거든요. 한편, SQLAlchemy의 장점을 파이선과의 긴밀한 결합에서 찾아 볼 수도 있습니다. 예를 들어, SQLAlchemy에 JSON 어댑터를 붙여서 필드에 JSON을 바로 저장할 수 있게 하거나, 여러 필드를 묶어서 calculated field를 만드는 것이 가능합니다. 분명 편한 기능입니다. 하지만, PostgreSQL 9.2에서 JSON 타입이 추가되었고, 가상 필드 또한 SQL에서 뷰를 쓰면 어느 정도 따라하는 게 가능합니다. 이런 것들은 SQLAlchemy를 써야 하는 결정적인 이유가 되지는 못하는 것 같습니다. 그래서 저는 추상화 레벨을 한 단계 포기하고 SQL을 생으로 쓰기로 한 것입니다만... 솔직히 이게 외부 기여를 받는데는 별로 좋지 못한 생각인 것 같기도 합니다. 코드 가독성도 좀 떨어질 것 같고요. 일단 시작은 SQL로 했지만, 아직 여러 가지로 고민이 많습니다...
14/10/25 23:22
오 좋은 답변입니다. GAE로 게임서버를 짤까하는데 sqlalchemy를 쓸지 고민 중이었거든요. datastore에 어울릴지도 모르겠고.. 조금 더 생각을 해봐야겠네요.
근데 랜덤여신님이 barosl님 맞는거죠?
14/10/25 23:28
잘 모르긴하지만... 앱엔진 쓸 땐 JDO 나... 나중에 RDBMS 로 전환할 가능성까지 고려하면 JPA 가 좋지 않나요?
아.. 아니구나... 파이썬 개발은 다를 수도 있겠네요. 자바 위주로 생각하다보니...
14/10/25 23:39
SQLAlchemy는 뭐랄까.. ORM 중에서는 가장 진보한 형태라고 해야할까요.. 철학 자체가 꽤 다른 녀석입니다.
그래서 다른 ORM 다루시던 분 들에겐 좀 생소한 녀석이예요 흐흐
14/10/26 00:28
파이썬은 좀 아는데 오픈소스 프로젝트는 아직 참여해본 적이 없어서 선뜻 돕겠다고 나서기가 무섭네요. 흐흐...
오랜시절의 오픈소스 지지자로써 기회되면 한번 힘써 보겠습니다!
|
||||||||||