반응형

 Response.AddHeader("Content-Disposition", "attachment;filename=\"test.zip\"");
 Response.ContentType = "application/octet-stream";

 Response.WriteFile("../test.zip");

저작자표시 비영리
반응형
asp.net에서 Request로 파일을 전송받아서 서버에 저장한다.
플랙스에서는 직접파일 처리는 불가능 한듯 하다. 
플랙스와 php,jsp등을 연동하여 많은 예제가 있는데 asp.net(c#)은 별로 없는 듯 하다.
(이것도 퍼온건데 출처가 어딘지 까먹었네...=_=)

플랫폼에 상관없는 업로드기능을 구현해보려고 만든 거였는데...
웹폼에 데이터를 전송하는 방식을 사용하기 때문에 asp.net의 파일용량제한은 별도로 해결해 줘야한다... =_=;
저작자표시 비영리
반응형
보안 샌드박스는 아마도 서버-클라이언트 기술 제약인 것 같다.
서버로 접근하여 파일을 다운로드하는 기능을 구현하였는데 localhost에서 테스트할때는 문제가 없었으나
외부에서 접근하니 보안샌드박스 위반이라고 한다.
보안샌드박스 위반 문제를 해결하기 위해서는 웹페이지 서비스 루트에 crossdomail.xml을 만들어 줘야한다.
-crossdomail.xml-------------------------------------------------------------------------------
<?xml version="1.0"?> 
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy> 
<site-control permitted-cross-domain-policies="master-only"/> <!--파일업로드시권한관련-->
<allow-access-from domain="*"/><!-- 모든 도메인 허용 -->
<allow-http-request-headers-from domain="*" headers="SOAPAction"/> 
</cross-domain-policy>
------------------------------------------------------------------------------------------------
allow-access-from domain="*" 이부분에 *문자를 기록하여 모든 도메인에 접근하도록 한 것인데
세부적인 설정이 가능하다. (자세히 알아보는건 다음기회로...)
<site-control permitted-cross-domain-policies="master-only"/> <!--파일업로드시권한관련-->
이부분을 빼놓으니 디버그시 policies="master-only"가 어쩌고 저쩌고 하는 메세지가 콘솔에 나온다...
모르겠다... 귀찮아서 추가했다.

저작자표시 비영리
반응형
우연히 어떤게임을 알게됐다.
1. 나는 그게임을 다운 받았다.
2. 게임을 실행하려고 하니 컴사양이 달려서 뽑아놨던 비됴카드를 다시 달았다.
3. 윈도우가 부팅이 안된다.
4. 포맷했다.
5. C:드라이브와 D:드라이브가 바뀐체로 포맷이 돼있었다.
 기존에 사용하던 파티션은 c:50G d:100G였는데 포맷하고 보니
 c:100G d:50G... ㅠ_ㅠ 젠장...
6. 로또프로젝트 자료는 전부 D:드라이브에 있었다.
7. 그냥 다시포맷했다. c:50G d:100G로...
8. 게임은 재밌었다... ㅠ_ㅠ
저작자표시 비영리
반응형
직선의 기울기 구하기.
좌표 [x,y], [x',y' ]
기울기 slop 
Y절편 Itce

slop = (y'-y)/(x'-x)
Itce = y-(slop*x)

이게 중학생 수준의 문제였지 아마????(ㅠ_ㅠ)


저작자표시 비영리
반응형
자, 경우의 수는 모두 입력했다.

이제부터 할일은 814만건 중에서 당첨확률이 낮아 보이는 숫자를 선별하는 일이다.

기존에 로또 분석사례를 보니 당첨숫자 빈도수를 점검하는 방식으로 진행되는 것 같더라.

내가 사용할 방법은 기존에 당첨된 번호와 기당첨번호와 매우 유사한 숫자등을 선별하여

814만건의 데이터에서 추려내는 것 이다.

사실... 이 발상에도 한계는 있다. 말이 선별이지 선별의 기준도 좀 모호하고...

아무리 선별한다고 하여도 로또의 확률은 매회 1/814만 이기때문이다.

단지 편의상 기존에 당첨됐던 번호와 그 유사한 번호를 제외하는 방법을 사용했을 뿐이지...

아무튼 기당첨 번호 355건을 입력했고 그와 유사한 5자리의 번호를 체크했더니

(예를 들어 당첨번호가 1,2,3,4,5,6 이라면 1,2,3,4,5가 들어가는 모든 수 1,3,4,5,6이 들어가는 모든 수들)

대략 4만건정도가 쌓인다. 4자리 유사한 숫자와 기타 몇가지 특징이있는 숫자들을 제외할 생각인데...

처음에 구상할땐 백만건 이상 선별할 것으로 기대했으나 실제로 해보려니 그정도는 힘들 것 같다.^^

저작자표시 비영리
반응형
경우의 숫자 815만여건을 모두 만들었다.

아무래도 1부터 45까지 6자릿수의 경우의수를 반복해서 만드는 건 너무 오래걸리는 것 같아서

그냥 숫자생성로직을 초기화했다.

중복되는 숫자체크 확인 함수도 없애고 그냥

a,b,c,d,e,f에 대한 초기값1 대신

앞자리 + 1을 초기값으로 설정하고 한잠자고 일어나니 815만건정도의 데이터가 모두 입력돼있었다.

물론... 어찌된 영문인지 일주일넘게 켜놨던 데탑이 뻣어버리는 사태가 발생해서

회사출근도 째고 부시럭부시럭 거리며 서버를 살려놓고 DB에 접속해보니 내가 만들려고 했던 데이터가

완성되 있는 것이 아닌가...

바로 로또사이트 들어가서 로또 당첨기록 엑셀파일로 다운받아서 경우의 수에 당첨 회차 업데이트 했다. 

후후후 기본 소스는 만들어졌으니 슬슬 분석단계로 넘어가야 하는데...

사실 지금까지 만들어 놓은 것들은 기본 소스에 불과하고 지금부터가 진짜 라는거...

젠장 경우의 수 만들기는 정답이라도 있지만 이제부터는 답도 없는 아이디어의 세계다... ㅠ_ㅠ
저작자표시 비영리
반응형
너무 느린 것 같아서 로직을 살짝 바꿨다.
조금 빨라진 것 같긴한데 그래도 속도가 마음에 안들어서 
(대충 보니까 1초에 200에서 300건정도 입력되는 듯...)

그냥 기존 로직을 샥뜯어 고쳐서 돌리니 30분도 안돼서 백만건이 훌쩍넘어 버렸다...

어떻게 했느냐 하면...

그냥 기존에 중복확인 함수를 빼버렸다.
그리고 숫자생성부분 로직을 고쳐서 그냥 중복수가 발생하지 않게 바꿔버려서 속도가 엄청 빨라졌다.

근데 나중에 전부 입력하고 중복되는 수가 있는지 확인해봐야함...
(아마도 중복수가 안생기리라 기대하고 있지만... 개발이란게 원래 맘먹은데로 쉽게 되는게 없는 거다.
저작자표시 비영리
반응형

프로그램을 만들어서 무한반복(까지는 아니고) 반복문으로 
로또 경우의 수 생성하고있다.
좀 많이 무식한 방법인데...

6자리의 숫자를 생성해서
① 생성된 숫자가 DB에 존재하는지 존재여부를 검색
② 존재하면 건너뛰고 존재하지 않으면 6자리 숫자를 DB에 입력
하는 아주 단순한 로직이다.

문제는 너무 단순하다 보니까 무조건 돌리기만 한다는 거...

중복되는 숫자를 제거하고 돌리다 보니 DB에 쌓인 데이터의 양이  4,5일정도 
돌렸음에도 불구하고 30만건을 겨우 넘는 정도였다.

숫자를 생성하는 속도자체는 큰 차이가 없지만 그것을 일일이 DB에 접근해서
유효한 것인지 아닌지를 판단하다 보니 속도가 엄청 느려졌다고나 할까?

그래서...
유효성판단하는 함수에 한가지를 더 추가했다.

(a)01,(b)02,(c)03,(d)04,(e)05,(f)06 번째 자릿수의 특징 중 하나가
뒷자릿수가 앞의 자릿수보다 작은수가 올 수 없다는 것이니...

무한생성시키고 있는 숫자중에 뒷자리가 앞자리 보다 작은 숫자들은
이미 기존에 입력된 값이 있는 중복된 값이기 때문에 무조건 무시하고
생성하기로 했더니...

4,5일간 30만건 생성했던 속도가 하룻밤만에 30만건을 생성하는게 아닌가... -_-;
앞으로 추가할 로직이 몇가지 더있긴 한데... 쩝...
저작자표시 비영리
반응형
로또예측프로그램 1차단계로 로또 경우의 수 생성 프로그램을 작성했다.

애당초에 825만건 정도의 경우의 수를 예상했으나 실제로 프로그램을 돌려보니

실제 생성될 데이터의 1/10도 생성되지 않았는데 3천만건이 넘게 생성되는 것이 아닌가???

아, 물론 큐브리드는 바보같아서 MSSQL로 바꿨더니 3천만건정도 되니까 큐브리드랑 비슷한 바보증세가 MSSQL

에서도 보이더라... (큐브리드는 200만건에서 바보가 됐었고 그래서 큐브리드가 가야할 길이 멀었다는 의미다...)

그래서 천만건은 커녕 억단위의 경우의 수를 예상하고 있었는데 아뿔사!!!!!!!!!!!!

테이블 설계를 [순서],[1],[2],[3],[4],[5],[6],[당첨회차] 이런 식으로 하고 루프를 돌렸는데

전혀 예상하지 못했던 실수가 있었다... 그것은 다름이 아니라...

1,2,3,4,5,6 이라는 경우의 수를 예로 든다면 1,2,3,4,5,6 과 2,3,4,5,6,1이나 3,4,5,6,1,2나 동일한 숫자는 순서에 상관없이

결국 같은 하나의 값이라는 결론이 예상된다... 이런... 난감한 실수를 할 줄이야...

중복데이터를 회피할 쿼리까지 만들기는 했지만... 시간관계상 마무리를 못했다...

오늘 컴백홈해서... 마무리를 지어야지.... (ㅠ_ㅠ)
저작자표시 비영리

+ Recent posts

티스토리툴바