Python

헬로우 큐트 포 파이썬 (Hello Qt for Python)

헬로우 큐트 포 파이썬 (Hello Qt for Python) * 원문: http://blog.qt.io/blog/2018/05/04/hello-qt-for-python/ * 번역: https://j2doll.github.io/Qt-for-Python-Docs-Kor/ 첫 번째 Qt for Python의 기술 프리뷰 릴리스가 여기 있습니다! 그래서 파이썬 세계에 문을 여는 방법에 대한 간단한 예제를

[HBR 독후감] 애자일 이야기

HBR 한국판이 있습니다. Harvard Business Review라는 꽤 유명한 경영월간지인데, 필자는 지난 15년간 개발자 출신 IT 컨설턴트였던지라 띄엄띄엄 여력이 있을 때마다 한글판을 사서 보곤 했습니다. 그런데 어느 때부터인지 한국판은 격월간으로 나오고, 또 대형 서점에 가보면 눈에 안 띄는 매대로 점차 밀려나고 있음을 확인할 수 있었습니다. 직원을 부르지 않고 찾으려면 상당한 탐색

RadonDB: 대륙의 뉴타입 슈주쿠(Shùjùkù, 数据库, database) !?

최근에 알게 QingCloud (칸클라우뜨, 칭클라우드, 청나라 구름?! ) 에서 오픈소스로 공개한 RadonDB (0) ( 레이돈디비,  라둥디비?! 동(氡)디비?! ) 에 대해서 알아 보겠습니다. RadonDB 는 MySQL 데이터베이스를 이용하여 대용량 데이터 처리를 쉽게 하기 위해 클러스터 구성이 가능하도록 지원하는 솔루션으로 보입니다. RadonDB 솔루션명이 DB 라고 되어 있는데 사실은 DB 라고 부르기에는 애매한 점이

[개요] 아파치 하둡 3.1.0

여는 글 최근 아파치 하둡 3.1.0의 출시로 HDFS 의 Erasuere Coding 외에 분산 자원 관리자인 YARN에 특히 실용적인 기능들이 적용되었는데, 어떠한 기능들인지 차근차근 소개하겠습니다. 먼저, 공식 사이트에 게시 된 개요로부터 시작 하겠습니다. 개요 이 글에서는 주요 변경 사항에 대한 간략한 개요를 제공합니다. * YARN 기반에서 장기 실행 서비스들을 native와

[번역글] Spark Streaming의 내부

여는 글 최근 재미나게 본 영화인 Ready Player One 의 한 컷으로 글을 시작합니다. 이 영화에서 처럼 저와 독자분들께서도 자신의 인생에서 보지 못한 것을 볼 수있는 통찰력을 갖게 되기를 희망합니다. 독서 시간 : 3분 | 발췌... 글의 제목에서 알 수 있듯이, 이 글은 Spark Streaming 입문서가 아닙니다. 솔직히 이 글은 Spark 및

나의 영어 기사 읽기 노하우 공개 - Kent Beck 글을 예시로

모처럼 즉흥 글이다. 아시는 분은 아시겠으나 필자는 팝잇의 다작 기고자이다. 사실 그건 별로 중요하지 않은데, 일상 업무를 올리고 있기에 주변분들에게 피해나 상처를 주지 않아야 하니 조심스럽다. 게다가 팝잇 운영자가 옆자리에 앉아 있기도 해서 (그가 아무런 압력을 행사하지는 않지만) 괜시리 글 품질에 신경을 쓰지 않을 수 없다. 과거에 Younghoe.info 운영할

소프트웨어 엔지니어링에 작별을 고하는 친구(?)의 글을 읽으며

공감 120%의 글이다. 제목은 Say Goodbye to Software Engineering (And Why Software Projects Never End) 직역하면 소프트웨어 엔지니어링에 작별을 고한다, 그리고 왜 소프트웨어 프로젝트가 끝이 없어야 하는지에 대하여 저자의 이름은 Simon Lee. DZone 기사로 접했을 뿐 모르는 사람이다. 하지만, DZone 게시판에 나눈 필담[1]을 근거로 친구로 칭하기로 했다.

마이크로 서비스 아키텍처: 디지털 시대의 리테일 유연성

* 이 글은 소트웍스의 독일 리테일 책임자 Frank Potozki와 리테일 수석 Marcus Klein이 쓴 Microservices architecture: flexibility for omni-channel retailers라는 제목의 기사를 번역한 것입니다.  쇼핑하는 방식이 빠르게 바뀌고 있다. 변화 속도가 리테일 종사자들의 정확한 예측을 점차 어렵게 한다. 리테일 종사자가 미래 고객 기대를 모르고 있다. 확실한 점은 매력적인 상품구색만으로는 더

소프트웨어 개발에서 우리의 핵심가치와 실천사항은 무엇인가?

* 이 글은 여전히 직접 개발하는 수석 기술자[1] Evan Bottcher가 ThoughtWorks 블로그에 올린  What are our core values and practices for building software?을 번역한 글입니다. 올해 들어, 소트웍스에서 개발자로 근무하면서 내 경력과 인생에서 어떤 의미가 있는지 많이 생각하게 되었다. 그 중에는 훌륭한 사람들과 함께 일하는 점이 돋보인다. 그들은 신뢰와

복잡한 기술 스택이 경영진에게 주는 시사점

당신이 경영진의 일원이나 관리자 심지어 대표이사로서 기술스택 문제를 다뤄야 하는 이유는 무엇인가? 기술스택 문제는 기술자들이 다루면 될 일 아닌가? 그렇지 않다! 소프트웨어와 소프트웨어 개발은 디지털 미래를 여는 열쇠이다. 따라서, 구체적인 사항까지는 아니더라도 전반적 추이가 여러분 조직에 의미하는 바를 반드시 이해해야 한다. 기술은 다양한 형태로 차별화와 혁신을 주도한다. 경영진과 관리자는 다양한 기술이 시사하는 바를 반드시 이해해야 한다. 그래야만 올바른 의사결정을 할 수 있다.

개발을 여러 층의 케익으로 나누기

* 이 글은 제품 설계와 관리 전문가 Luis Mizutani가 ThoughtWorks 블로그에 올린  Slicing your development work as a multi-layer cake을 번역한 글입니다. 애자일 프로젝트에서는, 흔히 목적을 쪼개어 개별 작업 단위로 나누어서 최종 사용자 관점에서 동작을 수행하는 기능feature 으로 만든다. 이러한 작업 단위를 보통 '사용자 스토리user story’라고 부른다. 이때,

왜 IT부서는 스스로 혁신해야 하는가, 3부

* 이 글은 WORKSPACES & INNOVATION 책임자인 Swapnil Deshpande가 ThoughtWorks 블로그에 올린  Why IT departments must reinvent themselves 시리즈 3부를 번역한 글입니다.   지난 1부와 2부에 이어서, 이번 3부에서는 작업현장Workspaces을 구축할 때 어떤 방식이 좋은지 기술하겠다. 여기서는, 무수한 논쟁을 일으켰던 일상업무BAU와 혁신의 관계에 대한 내 의견을 제시하겠다. 최근 수 차례 대화에 참여해