이상한 미신;;

sh.의 이미지

html 코딩할 때 소문자로 쓰면 트래픽이 절약될 것 같은 느낌이 자꾸 들어서 남이 대문자로 해놓은걸 보면 화가 납니다 :oops:

...
....

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

File attachments: 
첨부파일 크기
Image icon 0221_yun1.jpg9.64 KB
죠커의 이미지

bs0048 wrote:
html 코딩할 때 소문자로 쓰면 트래픽이 절약될 것 같은 느낌이 자꾸 들어서 남이 대문자로 해놓은걸 보면 화가 납니다 :oops:

...
....

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

잘하셨습니다. 태그는 소문자로만 쓰는게 표준입니다.

rx78gd의 이미지

bs0048 wrote:
html 코딩할 때 소문자로 쓰면 트래픽이 절약될 것 같은 느낌이 자꾸 들어서 남이 대문자로 해놓은걸 보면 화가 납니다 :oops:

...
....

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

우하하하... 사실은 저도 그렇답니다..-_-;;

멀쩡한 소스에 대문자로 되어있는거 보면 다 뜯어고치고 싶다는...에구..이것도 병인가봐요...

-------------------------------------------------------------------------------------------
나에겐 할 수 있다는 의지와
하면 된다는 신념과
해야 한다는 의무가 있다.

http://rx78gd.tistory.com

sh.의 이미지

CN wrote:
bs0048 wrote:
html 코딩할 때 소문자로 쓰면 트래픽이 절약될 것 같은 느낌이 자꾸 들어서 남이 대문자로 해놓은걸 보면 화가 납니다 :oops:

...
....

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

잘하셨습니다. 태그는 소문자로만 쓰는게 표준입니다.

xhtml에서는 그렇지만 html에서는 대/소문자가 관계없습니다. :D

bus710의 이미지

실질적으로...

대문자의 아스키와 소문자의 아스키를 살펴 보면.

대문자의 경우 0x41이 A 입니다.

소문자는 0x61 이 a 입니다.

그런데 대문자는 0x41 ~ 0x5A 사이에 있고 소문자는 0x61 ~ 0x7A 사이로군요...

전력의 소비가 주로 전압의 상승 및 하강 시에 있다고 보면....

대문자의 경우 0x5* 대의 코드가 많습니다. 그에 비해 소문자는 0x7* 대가 많군요.

비교해 보면...

대문자: 0b0101****
소문자: 0b0111****

그렇습니다. 소문자 쪽이 신호 변화가 두차례나 적군요!!!

따라서 소문자 쪽이 전력 소비가 훨씬 적습니다!!

다만... sort 시에 아스키 값을 기준으로 검색해서 실행한다면 대문자 쪽이 앞에 위치해 있으므로 속도 면에서는 손해가 발생할 수 있겠군요...

물론 자주 쓰는 문자는 고려하지 않았습니다만....

여기까지 말도 안되고 쓸모도 없는 분석기 였습니다~

life is only one time

khris의 이미지

이 이런...
저는 얼마전까지만 해도 죄다 대문자로 뜯어고쳤는데... :oops:

───────────────────────
yaourt -S gothick elegant
khris'log

sh.의 이미지

khris wrote:
이 이런...
저는 얼마전까지만 해도 죄다 대문자로 뜯어고쳤는데... :oops:

IE에서 innerHTML 속성을 가져와보면 죄다 대문자로 나오죠;;

정태영의 이미지

akudoku wrote:
전력의 소비가 주로 전압의 상승 및 하강 시에 있다고 보면....

대문자의 경우 0x5* 대의 코드가 많습니다. 그에 비해 소문자는 0x7* 대가 많군요.

비교해 보면...

대문자: 0b0101****
소문자: 0b0111****

그렇습니다. 소문자 쪽이 신호 변화가 두차례나 적군요!!!

시리얼 통신 기준이군요 :twisted:

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

bus710의 이미지

정태영 wrote:
시리얼 통신 기준이군요 :twisted:

... 그래서 제가 말귀가 느려요 :oops:

life is only one time

sh.의 이미지

akudoku wrote:
정태영 wrote:
시리얼 통신 기준이군요 :twisted:

... 그래서 제가 말귀가 느려요 :oops:

EOT 받은 다음에 말씀하세요 8)

정태영의 이미지

bs0048 wrote:
akudoku wrote:
정태영 wrote:
시리얼 통신 기준이군요 :twisted:

... 그래서 제가 말귀가 느려요 :oops:

EOT 받은 다음에 말씀하세요 8)

패러티 가 안맞네요... 다시 보내주세요...

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

bus710의 이미지

그분이 오셨어요~

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트

life is only one time

sh.의 이미지

정태영 wrote:
bs0048 wrote:
akudoku wrote:
정태영 wrote:
시리얼 통신 기준이군요 :twisted:

... 그래서 제가 말귀가 느려요 :oops:

EOT 받은 다음에 말씀하세요 8)

패러티 가 안맞네요... 다시 보내주세요...

패리갯봐?모만Ⅴ摸뼈都求?에구..

정태영의 이미지

bs0048 wrote:
정태영 wrote:
bs0048 wrote:
akudoku wrote:
정태영 wrote:
시리얼 통신 기준이군요 :twisted:

... 그래서 제가 말귀가 느려요 :oops:

EOT 받은 다음에 말씀하세요 8)

패러티 가 안맞네요... 다시 보내주세요...

패리갯봐?모만Ⅴ摸뼈都求?에구..

baud rate 를 좀 낮춰보세요 =3=33

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

jongwooh의 이미지

bs0048 wrote:

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

흰 바탕화면에 검은 글씨로 픽셀이 나오므로 대문자가 전기를 덜 먹습니다. (CRT기준. LCD에서는 관련없음)

you must know the power of dark side.

sh.의 이미지

jwhan wrote:
bs0048 wrote:

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

흰 바탕화면에 검은 글씨로 픽셀이 나오므로 대문자가 전기를 덜 먹습니다. (CRT기준. LCD에서는 관련없음)


저는 검은 바탕 쓰거든요;;
s4bz의 이미지

저랑같은 병(?)을 가지신 분들이 좀있네요..

저도 이상하게 html 태그가 대문자이면..

직접 타이핑을 해서라도 다 소문자로 고쳐버리는데...

전에 뽀로샵이었던가??

거기서 이미지 잘라서 html 만들어주는거 있는걸로 아는데..

그걸 하니깐 태그가 다 대문자..

'젠장~'이라는 생각을 하면서 다뜯어고쳐 버린 기억이.;;

아~~

sh.의 이미지

s4bz 님;; 그건 옵션이 있어요~

Body
BODY
body

이렇게 고를 수 있도록.....

s4bz의 이미지

bs0048 wrote:
s4bz 님;; 그건 옵션이 있어요~

Body
BODY
body

이렇게 고를 수 있도록.....

충격! 지금 머리 쥐어뜯고있음.ㅜㅜ

이제껏 삽질을 해왔다는..으아아아아아~

아~~

espereto의 이미지

jwhan wrote:
bs0048 wrote:

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

흰 바탕화면에 검은 글씨로 픽셀이 나오므로 대문자가 전기를 덜 먹습니다. (CRT기준. LCD에서는 관련없음)

LCD도 관련있는 걸로 아는데요? :-)

LCD 구조에서, === 로 표시된 건 패널 경계이고, - 나 | 는 액정의 상태로 치면...

======
- - - - -
======

이렇게 되면 검은색,

======
| | | | |
======

이렇게되면, 흰색..

(물론, RGB로 나뉘어서 보아야 하겠지만, 귀찮아서 패스...)

저 두 가지 상태 중 어느 게 전기를 더 먹는 건지는 모르겠네요. :-)

잘 아시는 분?

단풍의 이미지

저 같은 경우는 소문자 태그를 보면 대문자로 고치고 싶은 충동이 생기는데 :oops:
오타 같은것도 찾기 쉬워서요... (Caps Lock) or (Shift) 누를 필요없이 소문자로 쓰도록
해야 겠네요 :)

warpdory의 이미지

espereto wrote:
jwhan wrote:
bs0048 wrote:

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

흰 바탕화면에 검은 글씨로 픽셀이 나오므로 대문자가 전기를 덜 먹습니다. (CRT기준. LCD에서는 관련없음)

LCD도 관련있는 걸로 아는데요? :-)

LCD 구조에서, === 로 표시된 건 패널 경계이고, - 나 | 는 액정의 상태로 치면...

======
- - - - -
======

이렇게 되면 검은색,

======
| | | | |
======

이렇게되면, 흰색..

(물론, RGB로 나뉘어서 보아야 하겠지만, 귀찮아서 패스...)

저 두 가지 상태 중 어느 게 전기를 더 먹는 건지는 모르겠네요. :-)

잘 아시는 분?

LCD 는 별 상관없습니다.
액정의 상태 변화에 쓰이는 전류량은 매우 미미하거든요.
LCD 는 대개 위쪽에 형광등(이라고 하기는 좀 뭐합니다만...)이 하나씩 달려 있는데, 이것 구동시키는 전류량이 LCD 전체를 구동시키는 필요 전기의 반정도에서 2/3 정도가 됩니다.
그리고 액정의 종류에 따라서 전류를 가할 때 on 이 되는 놈이 있고 off 가 되는 놈이 있기 때문에... 패널의 종류에 따라서도 차이가 납니다.
그래서 실제로 같은 크기일 때 LCD 나 PDP 나 소비전력량은 생각보다는 큰 차이가 없습니다. LCD 는 계속 켜 있는 상태이고 PDP 는 픽셀별로 on/off 를 하기 때문입니다. (물론, 아직까지는 PDP 가 LCD 에 비해서는 조금 더 많이 먹습니다.)


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

espereto의 이미지

warpdory wrote:

LCD 는 별 상관없습니다.
액정의 상태 변화에 쓰이는 전류량은 매우 미미하거든요.

흐흐... 그냥 농담으로 리플 단 것에 진지한 설명을 달아주시다니... ;;
아빠곰의 이미지

모니터가 반짝반짝 깨끗해야, 컴파일이 잘될 것 같습니다.

----
아발발다빠따반반나다발딸발발다빠따따맣밤밤따받따발발다따밝다발발다빠따따밤반다빠따다맣밥발
발다따밥다발발다따박다발발다빠따따밞밭밭다따다맣아희

coyday의 이미지

아빠곰 wrote:
모니터가 반짝반짝 깨끗해야, 컴파일이 잘될 것 같습니다.

:lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:
원츄입니다.

북한산(X) 삼각산(O) 백운대(X) 백운봉(O)

chronon의 이미지

리눅스 깔 때 아나콘다 화면에서 마우스를 흔들어주면 설치 속도가 빨라집니다.

진짜로요. 8)

warpdory의 이미지

espereto wrote:
warpdory wrote:

LCD 는 별 상관없습니다.
액정의 상태 변화에 쓰이는 전류량은 매우 미미하거든요.

흐흐... 그냥 농담으로 리플 단 것에 진지한 설명을 달아주시다니... ;;

저한테는 저게 농담이에요 ^^;


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

하니의 이미지

제가 알기로..

LCD는 검은색이 전기를 더 먹습니다. (물론. warpdory님 말씀처럼 차이는 미비합니다;;)

이유는.. 내부 물질(?)이 꼬이는 정도에 따라 빛이 많이 통과하기도 적게 통과하기도 하며, 이것이 Color-Filter(RGB)를 통과해서 우리가 말하는 pixel이 됩니다.

검은색을 만들려면. r/g/b 셋다 빛을 통과시키면 안되는데..

많이 꼬을수록(빛을 적게 통과시킬 수록..) 높은 전압이 필요합니다..

이론적인 내용일뿐 제가 직접 테스트 해보진 않았어요. ^^;

[니 칼은 니가 갈아라]

warpdory의 이미지

하니 wrote:
제가 알기로..

LCD는 검은색이 전기를 더 먹습니다. (물론. warpdory님 말씀처럼 차이는 미비합니다;;)

이유는.. 내부 물질(?)이 꼬이는 정도에 따라 빛이 많이 통과하기도 적게 통과하기도 하며, 이것이 Color-Filter(RGB)를 통과해서 우리가 말하는 pixel이 됩니다.

검은색을 만들려면. r/g/b 셋다 빛을 통과시키면 안되는데..

많이 꼬을수록(빛을 적게 통과시킬 수록..) 높은 전압이 필요합니다..

이론적인 내용일뿐 제가 직접 테스트 해보진 않았어요. ^^;

그 꼬는 게... 각 회사마다, 모델마다 다릅니다. 어떤 회사는 평소에는 정렬되어 있어서 빛을 투과시키다가 전압을 가하면 배열이 틀어지면서(위에서는 꼬았다고 표현하셨죠...) 빛을 막는 게 있는가 하면, 어떤 회사의 액정은 평소에는 지멋대로 배열되어서 빛의 투과를 막다가 전압을 가하면 정렬 되어서 빛을 투과시키기도 합니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

죠커의 이미지

bs0048 wrote:
CN wrote:
bs0048 wrote:
html 코딩할 때 소문자로 쓰면 트래픽이 절약될 것 같은 느낌이 자꾸 들어서 남이 대문자로 해놓은걸 보면 화가 납니다 :oops:

...
....

그래도 대문자가 픽셀이 더 많이 필요하니까 전기를 조금이라도 더 먹는건 사실이겠죠?

잘하셨습니다. 태그는 소문자로만 쓰는게 표준입니다.

xhtml에서는 그렇지만 html에서는 대/소문자가 관계없습니다. :D

요즘엔 다들 xhtml으로 하는 줄 알았습니다. 아직 xhtml이 html을 대체하지 못하는 이유를 설명해주실 분 있으신가요? :-)

정태영의 이미지

CN wrote:
요즘엔 다들 xhtml으로 하는 줄 알았습니다. 아직 xhtml이 html을 대체하지 못하는 이유를 설명해주실 분 있으신가요? :-)

아직 우리나라에선 css디자인이 널리 자리잡지도 못했는걸요 :shock:

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

codebank의 이미지

CN wrote:
요즘엔 다들 xhtml으로 하는 줄 알았습니다. 아직 xhtml이 html을 대체하지 못하는 이유를 설명해주실 분 있으신가요? :-)

저기요... 그런데... xhtml이 뭐죠??? :oops:

흐흐~ 무식한 질문이다... :lol:

------------------------------
좋은 하루 되세요.

sh.의 이미지

CN wrote:

요즘엔 다들 xhtml으로 하는 줄 알았습니다. 아직 xhtml이 html을 대체하지 못하는 이유를 설명해주실 분 있으신가요? :-)

굳이 필요성을 못 느끼는거죠. 왜 바꿔야하죠? :wink:

소리의 이미지

bs0048 wrote:
CN wrote:

요즘엔 다들 xhtml으로 하는 줄 알았습니다. 아직 xhtml이 html을 대체하지 못하는 이유를 설명해주실 분 있으신가요? :-)

굳이 필요성을 못 느끼는거죠. 왜 바꿔야하죠? :wink:

태그를 대문자로 쓸지 소문자로 쓸지 고민 안 해도 되니 좋잖아요~
(위 토론을 보세요. :oops:)

kane의 이미지

또 다른 미신.
직접 작성하면 라이브러리 함수보다 빠를 것 같다.

ed.netdiver의 이미지

또다른 미신.
warning도 없는데 program이 띨빡한짓하면 compiler를 의심하기 시작한다.

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

죠커의 이미지

kane wrote:
또 다른 미신.
직접 작성하면 라이브러리 함수보다 빠를 것 같다.

대체로 처음에는 빠른 경우도 많지요. 그런데 버전업이 될 수록 8)

kane의 이미지

qed wrote:
또다른 미신.
warning도 없는데 program이 띨빡한짓하면 compiler를 의심하기 시작한다.

덕분에 'gcc 버그'를 많이 찾았었지요.
두세시간 정도 지나면 생각이 바뀌기는 하지만.. ㅋ