기본 콘텐츠로 건너뛰기

1월, 2019의 게시물 표시

이더리움(Ethereum) 송금 수수료 및 Gas, Gwei 관계

Gas는 수수료가 아니고 트랜잭션 처리에 사용된 연료 입니다. 그리고 수수료를 적게 잡기 위해 gwei라는 gas 단가가 있습니다. 1 ETH = 100,000,000,000,000,000 gwei 그리고 수수료(ETH) = 사용된 Gas gwei 가격 * 0.000,000,001 가 됩니다. gwei는 8~40까지 원하는 속도에 맞추어 입력하는데, 그 외를 입력해도 됩니다. 실패하거나 너무 수수료가 높을 수 있을 뿐이지요. 그리고 Gas를 처음에 최대 얼마나 쓸지를 지정하는데 10만 Gas를 지정했는데 50000Gas만 사용했다면 50,000Gas x 8gwei x 0.000,000,001 = 0.0004 ETH 가 됩니다. Gas가 수수료라고 생각하시는 분들이 많은데, 엄밀하게 말하자면 수수료는 gas x gas단가 가 되겠죠. 수수료는 공식대로 움직이고 처리에 들어간 사용량에 따라 좌우되며, 최대 한도를 송신자가 지정하기 때문에 지정한 금액 이상 빠져나가지 않습니다. 지금 송금할 때 최적의 gas나 gwei를 알고 싶다면 Ether gas station( https://ethgasstation.info/ ) 에서 확인 가능합니다. ---- 서버관련은 언제든 문의주세요! Do not login your server any more! Free server management tool! http://giipweb.littleworld.net Subscribe and publish your links as a book with friends  My Favorite Link Share http://link.littleworld.net

Java(JSP)와 PHP 의 주관적인 고찰 및 비교

얼마전 친구의 회사에서 사이트 개발 외주를 하는데 PHP와 Java에 대해 이야기를 했다고 한다.  그 웹 에이전시에서는 Java가 좋고 PHP는 DB연결 없는 간단한 홈페이지나 게시판 정도밖에 안된다는 이야기를 했다.  개인적으로 난 아직도 ASP를 쓰기 때문에 Java와 PHP에서는 중립이지만, 에이전시에서 그 얘길 했다는 얘기를 듣고 분개를 했다...  이유는  말도 안되는 내용으로 친구에게 잘못된 정보를 준 것도 그렇지만, 이렇게 당연하게 한국에서만 세계의 흐름에 역행하는 행동을 하기 때문이다.  글로벌을 꿈꾸는 사람들은 제발 기술정보를 구글에서 검색하길 바란다.  국내 블로거들이 자기의 생각을 어필하는 정도를 진실이라 생각하지 말기를 바란다.  그건 개인의 의견일 뿐 중론이라고 볼 수가 없고,  만약, 국내 웹 에이전시와 공공 SIer들에 특화된 범위를 정한다면 대부분 Java를 택할 테니 그런 제한된 영역에서만 이야기 한다면 괜찮다. 대신 상관없는 사람들에게 이게 세계 트렌드니 뭐니 하면서 잘못된 정보를 주지 말기를 바란다.  http://w3techs.com/technologies/overview/programming_language/all W3Tech라고 알 만한 사람들은 다 아는 서비스에서 낸 웹서비스 통계이다.  전 세계에서 개인이 아닌 사이트 1000만 이상의 사이트 데이터의 통계이다.  내용을 보면 PHP가 82%정도를 차지한다.  누가 대세를 JSP라고 했던가.. JSP를 찬양하는 분들의 반박은 언제든 환영한다. 대신 국내 개인 블로거의 개인의견 링크를 걸지 마시고 통계나 기술적인 근거자료를 보여주시기 바란다.  JSP찬양자는 JSP가 퍼포먼스가 좋다는 이야기를 한다..  그럼 이 내용도 참고하기 바란다.  http://cppcms.com/wikipp/en/page/benchmarks_all 이건 단지 자신의 CMS솔루션을 강조하기

우리나라의 기술이 발전할 수 없는 가장 큰 이유.

우리나라에서 갑으로 유명한 지인과 가볍게 이야기하다가 나온 이야기다.  우리나라 사람들은 어느정도 기술이 쌓이면 더 배우려 하지 않는다.  가장 큰 이유는 더 배워도 급여가 오르거나 하지 않기 때문이다.  왜 그럴까? 이유는  우리나라의 IT기술 시장은 연간 약 2.5조원 그 중에 94%가 대기업 및 공공 기관의 IT Out sourcing이다. 즉, 대부분 대기업이나 공공 기관의 예산으로 먹고사는 중소기업 뿐이라는 이야기다.  대기업은 중소기업에게 일을 줄 때 지불하는 금액의 기준은  당연히 인건비 이다.  해외에서는 IT Out sourcing을 할 때 턴키 계약도 많이 한다.  솔루션 계약이나 서비스 계약도 많이 한다.  나 : "우리 서비스는 사용량 과금인데요." 라고 말하자 바로 잘렸다.  지인 : "우리는 매달 변경되는 비용 지불 못해요. 1년치 예산을 먼저 올려야 하거든요. " 또, 이렇게도 얘기했다.  나 : "그럼 월정액으로 이렇게 하면 어떨까요?" 지인 : "그렇게 하면 그 금액에 맞는 인건비 산정 기준표가 필요해요." 나 : "금액에 맞출려면 사람을 소싱해야만 한다는 거네요." 지인 : "네, 그렇게 안하고 소프트웨어 라이선스는 국내에서는 유명 기업 외에는 안되요." 즉, 아무리 실력이 좋아도  과기처 공시 인건비 단가 기준에서 최고봉인 특급 월 650만원 이상은 청구할 수 없다. 게다가 그 금액을 넣고 싶어도 사람을 정확하게 소싱해야만 하고,  그 사람에게 급여가 지급이 되어야만 한다.  더 웃긴건 작은 회사에 그런 경력을 뽑으려면 과기처 기준을 넘어서는 연봉이 필요하다. 내가 전에 참여 했던 모 공공 프로젝트에서는 좋은 사람을 소싱하지 않으면 공공에서 뽑아주지 않기 때문에 좋은

개발언어 파이슨(Python) 의 장단점 및 2, 3의 큰 변화, 구조에 관련된 이야기

파이슨 관련 이야기가 나왔다. 난 지금도 asp를 쓰고 있고, wmi, shell만으로도 모든게 가능해서 다른 언어는 뭐라도 상관없다. 필요한 기능 호출만 가능하다면.. 그런데 왜이렇게 한국 사람들은 파이슨을 신격화 시키는지.. 게다가 물어보면 그냥 좋대더라.. 개발자가 논리력이 이렇게 없어서야.. 파이슨을 모르는 내가 파이슨에 대해서 논해보겠다. 기술적인 태클은 언제든 환영이지만 인신공격은 무조건 삭제함. 파이슨은 C를 이용해서 원래 언어를 만드는 사람이 아닌 개발자가 만든 언어이기 때문에 랭기지로서는 아직도 발전해야 할 것이 많다. 하지만 개발자 Guido van Rossum은 Google 및 FOSDEM, ACM, NLUUG 등 유명한 소프트웨어 관련 경험이 있었고, Python역시 ABC에서 따서 만들었기 때문에 구조는 크게 나쁘지 않았다. Python은 다음의 특징을 가진다.(DARPA에 제출한 투자제안서에 기입한 내용) - 쉽고 직관적인 언어. - 메이저 개발언어와 동급의 성능 - 오픈소스 - 쉬운 코드 - 일상적인 태스크에 적합하고 쉽게 개발되는 언어 위와 같은 특징에서인지 초보자들용 으로 많이 불리고 있다. 하지만 오픈소스이기 때문에 많은 사람들이 많은 라이브러리를 만들어 FORTRAN계열과 같은 수학에 특화된 언어처럼 바뀌어졌다는게 내 생각이다. 때문에 지금도 ML중심의 언어로 많이 쓰이고 있지만, 웹 언어로는 아직도 쉽게 접근하기 힘든 것이 바로 Django같은 MW의 어려움 때문에 바로 시작하기에는 PHP나 ASP가 더 쉬운 언어같다. (그럼 PHP나 ASP가 웹은 초심자용? ^^;;) 쉬운 언어 = 초심자용 언어 = 능력이 떨어짐 이라는 선입관이 너무 팽배한지, 쉽다는 표현, 초보자용이라는 표현에 거부감이 많은 것 같다. 하지만, 그건 자괴감이 아닐까? 난 아직도 VB script베이스인 ASP로 모든 것을 해결하는데 부족함이 없다. 그럼 난 20년 넘은 초보 개발자?

이더리움(Ethereum)이 PoW를 버리고 PoS로 가는 이유

Ethereum은 총 네 가지 비즈니스 단계를 가지고 있습니다.  Frontier > Homestead > Metropolis > Serenity 이 중에 두 번째 단계에 접어들었네요.. 세 번쨰 단계인 Metropolis 때는 PoS로 전환한다고 하여 의견이 많네요... 많은 분들이 PoW와 PoS의 차이를 정확히 모르시는데 쉽게 설명을 드릴꼐요~ PoW는 Proof of Work 라고 하여 작업 증명이라는 어려운 기계 번역 스러운 번역을 사용합니다.  이유는 비트코인 전문 서적을 최초로 번역한 사람이 비트코인 관련인이 아니었기 때문이겠죠... 그럼 난 뭐라고 하느냐구요? .... 작업증명... 이죠 =ㅅ=;;; 작설하고.. PoW(Proof of Work)는  코인 거래를 기장하는 장부인  블럭체인의 이력이 정확한지를  다수의 PC(마이너)가  체크하는 방법을  말합니다.  PoS(Proof of Stake) 는 코인의 보유(Stakes)량으로  블럭체인의 이력이 정확한지를 체크하는 방법 을 말합니다.  실제로 마이닝하는 방법은 같지만,  코인을 보유한 전체 지갑(Full wallet)에는 전체 블럭체인이 저장되어 있습니다.  (2017년 현재 약 4GB정도?) PoS에는 자신이 보유한 코인의 블럭들이 저장되어 있는데,  코인 거래시에 거래 이력의 확인을 요청하면  각각의 전체 지갑에서 마이닝을 담당하게 되는데,  이 때 자신이 보유한 코인이 많을 수록  가지고 있는 블럭이 많게 되어 자신이 가지지 않은 블럭만 해싱작업을 하면 됩니다.  때문에  많이 소유한 만큼  이미 검증된 블럭을 가지고 있어 해싱을 하지 않고 자신에게 없는 블럭만 해싱하면 되므로 필요한 컴퓨팅 자원이 줄어들고  빨리 해싱을 하기 때문에 보상을 받을 확률이 늘어나는 것이지요.. PoW는  비트코인, 이더리움등 이미 메이저 가상화폐에서 기본으로 사용하고 있는 방법입니다.  갑

블록체인 기술의 취약점 및 고려 사항

요즘 많은 백서의 기술 검증을 하고  여러 ICO에서의 설명을 듣고,  Github에서 소스를 내려받으면서  실제 소스를 보고 있습니다.  Genesis 블럭은 어떻게 만들고 있는지? 기본 구조는 몇 세대 체인 구조를 가지고 있는지? DAG이 최선? 고속 합의 및 용량 제약을 풀어낸  DAG이 IOTA덕분에 좀 활기를 치고 있지만,  최초의 DAG Whitepaper에서도 언급했던 것 처럼 이건 이론일 뿐이고 실제로는 어떻게 될지 모릅니다.  즉, 현재 국내 DAG구조를 발표한 백서에서  DAG원래 취약성의 보완 방법을 언급한 Whitepaper는 못봤습니다.  블록체인이 최고인양,  블록체인이 최첨단 기술인양 자기의 비즈니스를  억지로 구겨넣고 있는 모습을 많이 봅니다.  블록체인은 어떤 단점이 있는지조차 모른채.. 블록체인의 중요한 단점은 다음과 같습니다.  1. 블록체인은 Transaction이 느릴 수 밖에 없다! 요즘 들어 TPS(transaction per second, 초당 처리수) 우위로  광고하는 블록체인들이 늘고 있습니다.  5000TPS? 어떻게 그렇게 구현할 수 있죠?  github에 구조좀 공개해 주세요!  5000이라고 얘기한 것은 아마  Open source RDB의 TPS허용량을  기준으로 얘기한 것일 겁니다.   그렇다면 그냥 RDB라고 하지..  블록체인은 구조상  네트워크로 요청을 보내서  여러 네트워크에 오는 결과의  정합성을 검증하여 참을 가리는  합의 프로토콜을 가지고 있습니다.  즉, 아무리 가까운 곳에 있다 하더라도 수 천대의 머신에 연결을 하려면,  최소 수 백개의 L2장비가 필요하고,  그 L2장비를 연결하는   수 십 또는 수 대의 대형 패치 패널을 보유한  백본 사이즈 네트워크 기기가 필요합니다.  이건 가정

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만