현재 가지고 있는 것: - 모든 바는 분 히스토리를 기반으로 구축되었습니다. 그게 플러스인 것 같습니다. -하지만 역사 저장 모델의 동일한 플러스가 지방 빼기를 드러냈습니다. - 분이없는 고대 역사를 어디에 둘 것입니까? - 며칠 동안 생각한 후, 당신은 이 모든 이야기를 가져오기로 1분 만에 결정을 내렸습니다. 당신에게는 다른 선택이 없었습니다! "모든 것을 몇 분 안에" 모델이 더 맛있습니다 :)
즉, 타협은 받은 것 같지만 목발을 하나 놓고 가다가 우연히 또 다른 목발을 마주하게 되는데...
분 없는 고대의 역사가 당신의 서버에 있다는 것은 분명합니다. 다른 브로커의 서버에는 이러한 기록이 없을 수 있습니다(이 줄은 FiftyStars 용입니다).
전체적으로 다음을 기반으로 합니다. - 아무도 "분" 모델을 변경하지 않습니다. 그것은 사실이다. - 아무도 MQL에 기능을 추가하여 1분과 1일을 분석하지 않습니다. 일반적으로 어떻게 하는지 명확하지 않기 때문입니다.
그래서 주제가 무의미하다. 나는 모든 것이 브로커에 달려 있다고 생각합니다. 그가 자신의 서버에서 "1분도 안 된" 기록을 허용할지 여부... 그리고 이 질문은 더 이상 MK에 대한 것이 아닙니다.
"단 1분"이라는 모델은 한편으로 많은 양의 정보를 저장하고 전송할 때 편리함을 보여주었습니다. 반면에 우리는 MK로부터 기능을 받았습니다. 즉, 1분 역사에 일일 바가 있다는 것은 사실 놀라운 일입니다.
따라서 분에서 일일 막대를 제거하려는 모든 사람은 중개인에게 문의하십시오. 이를 전달하고 문제 상황을 설명하는 것이 가능합니다. 그리고 MK의 경우 이렇게 하는 것은 의미가 없습니다. 여기 프로거가 있습니다.
우리는 불꽃을 부풀려 두뇌를 끄나요?
아니요, 우리는 새로 발견된 잔인한 목발을 피할 수 있는 최소한 몇 가지 옵션을 찾으려고 노력하고 있습니다.
이것이 기능이며 우리는 괜찮을 것이라고 확신할 필요가 없습니다.
Komposter, 지난 10-12년 이내의 시간으로 작업하고 1999년보다 오래된 시간이 중요한 척하지 마십시오.
문제가 없고 1999년보다 오래된 날짜가 존재하기 때문에 더 깊은 역사를 볼 수 있습니다.
특히 각 브로커가 사용할 기록을 스스로 결정하기 때문에 문제가 없습니다. 원한다면 조금 더 짧지만 깨끗한 M1을 방송하게 해주세요. 1999년 이전의 역사를 사용할 필요는 없습니다.
구멍을 제어하기가 어렵지 않은 것처럼 보이지만 분 막대 대신 다른 시간 프레임이 사용 되도록 프로그래밍 방식으로 결정하는 방법은 무엇입니까?
내가 이해하는 한, 누군가는 의도적으로 "분 대신에 뭔가 다른 것이 있을 수 있다"는 생각으로 히스테리를 일으키게 됩니다.
사실은 다음과 같습니다.
시장에 출시되는 제품은 타협의 집합이라는 점을 명심하십시오.
한 이론의 순수성을 옹호하는 극단주의는 필연적으로 다른 수십 가지 입장과 충돌하게 된다. 그리고 결국, 대부분의 경우 누적 타협 옵션이 승리합니다. 여기서 양측은 조금씩 무언가를 희생해야 합니다.
사실은 다음과 같습니다.
당신은 그것을 가지고 있습니다. 여기 는 어떻습니까 ? 아니면 중개인이 더 이상 귀하의 비즈니스가 아님을 부인하시겠습니까?
마감일이 언제인가요? 1999년 1월 1일, 1999년 1월 4일, 아니면...?
아니면 다른 캐릭터에 대해 다를 수 있습니까?
당신은 그것을 가지고 있습니다. 여기 는 어떻습니까 ? 아니면 중개인이 더 이상 귀하의 비즈니스가 아님을 부인하시겠습니까?
"있다"는 구체적인 사항이 없습니다.
따라서 당신은 현실과 상관없이 순전히 이론상으로 반응했습니다. 본질을 이해하지 못하고 이해하지 못한다.
마감일이 언제인가요? 1999년 1월 1일, 1999년 1월 4일, 아니면...?
아니면 다른 캐릭터에 대해 다를 수 있습니까?
물론 다릅니다.
개발자가 분 배열에서 원하는 시작 인덱스를 찾기 위해 5행 함수를 작성하는 것이 어렵다는 것을 알고 있습니까? 그리고 예외적인 경우에도 1000명당 1명입니다.
물론 어렵지 않습니다. 하지만 시스템의 전체적인 그림에 신경을 쓰지 않고 공개 구축함을 플레이하는 것은 매우 흥미롭습니다.
"있다"는 구체적인 사항이 없습니다.
따라서 당신은 현실과 상관없이 순전히 이론상으로 반응했습니다. 본질을 이해하지 못하고 이해하지 못한다.
글쎄, 물론, 나는 모든 것을 기억합니다. 나는 아무것도 이해하지 못하는 무능한 멍청이이며 실수로이 주제에 방황했습니다.
구체적인 내용이 나오면 어떻게 하시겠습니까?
글쎄, 물론, 나는 모든 것을 기억합니다. 나는 아무것도 이해하지 못하는 무능한 멍청이이며 실수로이 주제에 방황했습니다.
구체적인 내용이 나오면 어떻게 하시겠습니까?
내가 쓴 것을 읽도록 당신을 보내겠습니다.
귀하의 지시가 구체적이지 않다는 점을 인정해 주셔서 감사합니다.
레나트, 기술-실천의 관점에서 접근하자.
현재 가지고 있는 것:
- 모든 바는 분 히스토리를 기반으로 구축되었습니다. 그게 플러스인 것 같습니다.
-하지만 역사 저장 모델의 동일한 플러스가 지방 빼기를 드러냈습니다. - 분이없는 고대 역사를 어디에 둘 것입니까?
- 며칠 동안 생각한 후, 당신은 이 모든 이야기를 가져오기로 1분 만에 결정을 내렸습니다. 당신에게는 다른 선택이 없었습니다! "모든 것을 몇 분 안에" 모델이 더 맛있습니다 :)
즉, 타협은 받은 것 같지만 목발을 하나 놓고 가다가 우연히 또 다른 목발을 마주하게 되는데...
분 없는 고대의 역사가 당신의 서버에 있다는 것은 분명합니다. 다른 브로커의 서버에는 이러한 기록이 없을 수 있습니다(이 줄은 FiftyStars 용입니다).
전체적으로 다음을 기반으로 합니다.
- 아무도 "분" 모델을 변경하지 않습니다. 그것은 사실이다.
- 아무도 MQL에 기능을 추가하여 1분과 1일을 분석하지 않습니다. 일반적으로 어떻게 하는지 명확하지 않기 때문입니다.
그래서 주제가 무의미하다. 나는 모든 것이 브로커에 달려 있다고 생각합니다. 그가 자신의 서버에서 "1분도 안 된" 기록을 허용할지 여부... 그리고 이 질문은 더 이상 MK에 대한 것이 아닙니다.
"단 1분"이라는 모델은 한편으로 많은 양의 정보를 저장하고 전송할 때 편리함을 보여주었습니다.
반면에 우리는 MK로부터 기능을 받았습니다. 즉, 1분 역사에 일일 바가 있다는 것은 사실 놀라운 일입니다.
따라서 분에서 일일 막대를 제거하려는 모든 사람은 중개인에게 문의하십시오.
이를 전달하고 문제 상황을 설명하는 것이 가능합니다. 그리고 MK의 경우 이렇게 하는 것은 의미가 없습니다. 여기 프로거가 있습니다.