2012/01/02 10:49 WEB & IT

SNS 다음은 LNS?

PC통신에 이어서 아이러브스쿨, 싸이월드 등등의 SNS에 이서 LNS는 facebook에 timeline이 대표적인 feature로 보인다.

http://news.naver.com/main/hotissue/read.nhn?mid=hot&sid1=105&cid=303942&iid=562266&oid=015&aid=0002609150&ptype=011

* SNS : social network service
* LNS : life network service

관계와 개인의 인생...그러면 그 다음은 무엇일까?
사람 중심일까? 활동 중심일까?
Posted by ologist
트랙백0 댓글0

2011/12/28 14:34 분류없음

고객을 두번 찾게 만드는 방법

아마존닷검 CEO "제프 베조스", 그가 말하는 고객을 두번 찾게 만드는 방법
http://blog.naver.com/2minrain/90130431818

1. 우리의 경쟁상대는 경쟁회사가 아니라 고객이다.
2. 단골고객을 만드는 최고의 방법은 첫 구매시 기대이상의 서비스를 하면 된다.

제프 베조스는 아마존CEO로서 이름을 알고 있었으나 최근에 아마존의 행보를 보면서 어떤 사람인지 궁금해지기 시작했다. 좀더 자세히 보려고 검색을 해보니 한글문서에서도 충분히 좋은 글들이 많이 보인다.

공격적인 리뷰, 마이크로 경영 및 디테일한 지식, 마케팅 전략, 플랫폼을 만들고 확장하는 모습들....
http://eggy.egloos.com/3764098
http://blog.naver.com/vooooooo/100139377732
http://sktstory.com/jeffrey-bezos-interview/
http://youngheajung.com/5




Posted by ologist
트랙백0 댓글0

2011/07/26 00:54 분류없음

부채의 습격

최근 공공기관과 금융권 서비스에서 장애가 발생하고 있다. 이전에 농협사태 이후에 크고 작은 장애가 지속적으로 발생하는 것이다.

시스템이란 것이 항상 똑같은 상황으로 멈추어 있으면 장애가 나지 않겠지만, 상황은 매분매초 변하게 되어 있다. 꾸준히 관리를 해주지 않으면 문제가 생길 수도 있는 것이다.

아마 시스템을 만들 때도 일정압박에 낮은 퀄리티의 산출물이 나왔을 것이고 이제서야 하나둘씩 문제가 드러나기 시작하는 것이 아닐까? 

그 동안에 개발자들을 못살게 굴면서 만들어 온 시스템의 부채들이 앞으로 습격을 계속 할 것 같다.

서스테이닝 전문가들이 필요한 시점이다. 

나이스 오류
http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=105&oid=008&aid=0002579629

인터넷 지로 시스템 한때 마비
http://news.naver.com/main/hotissue/read.nhn?mid=hot&sid1=101&cid=302840&iid=303228&oid=055&aid=0000209686&ptype=011

우리은행 뱅킹 문제 많네
http://news.naver.com/main/hotissue/read.nhn?mid=hot&sid1=101&cid=302840&iid=9758189&oid=008&aid=0002579595&ptype=011

 

Posted by ologist
트랙백0 댓글0

2011/06/30 00:20 분류없음

리더


조직의 성패는 리더의 역할과 능력에 달려 있다. 조직은 리더를 세우는데 신중해야 한다. 한 사람을 양성시키려다가 여러 사람을 잃을 수도 있다.

리더십은 지도자도 배 안에 타서 모두가 함께 움직이도록 하는 것인데 반해 헤드십은 지도자가 배 밖에 있으면서 배에 탄 사람들을 끌어당기고 있는 것이라 할 수 있다.

권위에 의존하고 꾸짖기만 하고 공포심만 심어 주는 상관이 회사를 망친다. 성공한 리더는 앞장서고 신바람 나게 하고 협동하고 잘못을 고쳐주며 부하직원들을 사랑하고 섬기고 감동시킨다.

사람의 능력이라는 것은 경험의 기회가 만들어 낸다. 윗사람이 아랫사람보다 그 일을 잘할 수 있다는 것은 윗사람에게 그 일을 해볼 기회가 많았기 때문이다. 그러므로 과감한 위임은 윗사람과 아랫사람 모두에게 도움이 되며, 궁극적으로는 조직 발전에 기여하게 된다.

상대에게 주의를 줄 때에는 일 대 일로 다른 사람이 없는 곳에서 하는 것이 원칙이다. 이것은 꼭 지켜야 한다.



Posted by ologist
트랙백0 댓글0

2011/04/20 13:46 분류없음

농협 전산장애

최근에 농협사건으로 인해서 리눅스(유닉스) 명령어인 rm인 유명해졌다. 현재 언론이나 정부는 누군가에 의한 악의적인 공격으로 보인다고 하고 있다.

공격치고는 너무 단순한 명령어라 당황스럽지만, 완전 소설 쓰는 느낌도....
특히 이 시점에 북한을 의심하는 정부는 또 뭔가요? 어떤 이슈만 생기면 나오는 북한, 이젠 좀 고만;;

이런 사건이 발생하고 복구하는데 시간도 오래 걸리고 여러가지 추측만 무성한 지금 이게 바로 우리 IT역량의 현주소다. 시스템관리자, 개발자를 탓할 것이 아니라 질좋고 안전한 시스템을 만들기 위해서 투자를 해야 하는 것이다. 투자를 하기 위한 의사결정자들이 전체적으로 시스템, S/W에 대한 이해도가 낮다고 밖에 생각이 안든다.

농협관련 rm기사
http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=023&aid=0002257045
http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=038&aid=0002144077
http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=081&aid=0002181520

 

Posted by ologist
트랙백0 댓글0

2011/02/01 23:50 분류없음

spring batch에서 job을 수행전에 unique키 발급 에러

"org.springframework.dao.DataAccessResourceFailureException: Could not increment identity; nested exception is java.sql.SQLException: 트랜잭션(프로세스 ID 816)이 잠금 리소스에서 다른 프로세스와의 교착 상태가 발생하여 실행이 중지되었습니다. 트랜잭션을 다시 실행하십시오."

spring batch를 적용해서 수행하다가 보면, 위와 같은 에러를 만날 수가 있다. 말그대로 쿼리를 수행 후에 unique한 키발급이 되지 않은 상황이다. 트랜잭션이 보장되지 않도록 쿼리를 작성해서 발생하는 문제인데 MSSQL DB인 경우 간혹 발생한다.

이 경우 처리하는 방법이 2가지가 있다.

1. retry를 하는 방법
http://floatingcube.blogspot.com/2009/09/retry-spring-batch-job-due-to-database.html

2. 쿼리 패치
org.springframework.jdbc.support.incrementer.SqlServerMaxValueIncrementer.java 에서 사용하고 있는 쿼리를 수정한다.

<BEFORE>
insert into BATCH_JOB_SEQ default values.
select @@identity
delete from BATCH_JOB_SEQ where ID < 'before ID'

<AFTER>
아래처럼 트랜잭션을 관리하는 코드를 명시적으로 넣어준다.
begin tran
insert into BATCH_JOB_SEQ default values
rollback tran
select scope_identity()
Posted by ologist
트랙백0 댓글0

2011/02/01 23:20 분류없음

페이스북과 애플의 조직문화

"프로그래머의 길, 멘토에게 묻다"라는 책을 보면 엔지니어의 사고방식에 대해서 나옵니다.  소프트웨어 개발업무를 하면서 업무에 대해 스펙을 정리하고 지속적으로 개선하는 좋은 습관들이 개발 이외의 업무를 하더라도 효과적으로 업무를 수행한다는 이야기입니다. 우리 모두 소프트웨어 엔지니어로서 자부심을 가졌으면 합니다...^^
참고 서적 : http://book.naver.com/bookdb/book_detail.nhn?bid=6332442

아래 글들을 보면 구글을 비롯해서 facebook과 apple도 엔지니어 중심의 문화라는 것을 볼 수 있습니다. 특히 페이스북은 회계담당자도 엔지니어출신을 채용을 한적이 있다고 합니다.

<Facebook>
how facebook ships code
http://framethink.wordpress.com/2011/01/17/how-facebook-ships-code/
번역본 : http://logonjava.blogspot.com/2011/01/facebook-sw.html

<Apple>
Apple is run like a huge startup. The key to great products is small teams
http://sachin.posterous.com/apple-is-run-like-a-huge-startup
http://www.multiwriter.co.kr/803

8 Management Lessons I Learned Working At Apple
http://www.businessinsider.com/management-lessons-i-learned-working-at-apple-2010-7#challenge-your-employees-to-grow-4
번역본 : http://logonjava.blogspot.com/2010/08/apple.html

Posted by ologist
트랙백0 댓글0

2011/01/30 21:18 분류없음

핵심과 유연성

얼마전에 트위터를 보다가 배우 박중훈이 트윗이 리트윗되면서 퍼지는 글을 보았다.

유능한 감독은 유연성이 있다.꼭 지켜야 할 핵심이 아니라면 현장 상황에 자기 생각을 잘 맞춰 간다.그렇지 않은 감독은 반드시 자기가 생각한대로 100% 영상에 옮겨져야 한다.전자는 결과적으로 100%자기 생각을 관객에게 전달하고 후자는 그러다 지친다. - 박중훈

핵심과 유연성에 대한 이야기인데 위에 트윗은 핵심보다는 유연성에 맞추어서 표현글로 보인다. 감독역할을 하는 리더가 핵심이 아닌 것에서 집착을 하고 비용을 낭비를 한다면 배우들은 지쳐서 쓰러지게된다. 반대로 핵심이라면 어려운 상황이라도 반드시 일관성이 있게 지켜야 하고 배우들이 지치면 다독이면서 끌고 나가야 한다. 핵심을 버리고 성공하는 영화는 없을 것이다.

리더는 어떤 상황/업무에서 핵심을 잘 파악해야 한다. 본질이 무엇인지? 핵심이 무엇인지? 핵심을 통해서 만드는 가치는 무엇인지를 정의하고 구현을 해야 한다. 실제로 구현을 하면서 유연성 있게 대응하는 것은 리더의 역할이다. 핵심 이외의 것에서 이기적으로 구현을 하다가보면 리더를 따르는 이는 지쳐서 사라질 것이다.

리더를 믿고 따르는 사람들이 지치지 않도록 핵심과 핵심이 아닌 것에 대한 정의를 잘 해야 한다. 핵심이 아닌 것에 대해서는 유연성을 보이도록 하자. 그리고 리더는 항상 진심으로 마음을 전달할 수 있어야 한다.
Posted by ologist
트랙백0 댓글0

2011/01/18 00:42 Developer

asynchronous servlet in servlet3.0

servlet3.0에서는 asyncronous servlet을 지원한다.
http://blogs.sun.com/enterprisetechtips/entry/asynchronous_support_in_servlet_3

Asynchronous Support Features
- Annotation Attributes
- Servlet Request Methods
- AsyncContext Class
- Asynchronous Listener Class

Apache Tomcat version 7.0 implements the Servlet 3.0 and JavaServer Pages 2.2 specifications
http://tomcat.apache.org/tomcat-7.0-doc/index.html

tomcat7.0부터는 servlet3.0을 지원하는데 7.0이 많이 사용하게 되면 비동기 서블릿이 많이 활용될 것으로 보인다.

Posted by ologist
트랙백0 댓글0

2011/01/16 15:04 Developer

컴포넌트의 R&R, 그리고 시스템R&R


내가 기능을 구현할 때도 컴포넌트(클래스) 간에 R&R도 애매할 때가 있다. R&R은 비즈니스 로직을 어디에 두는 가를 결정해야 하기때문에 객체지향설계 시에 매우 중요한 요소이다.

R&R은 boundary하고도 밀접하다. 이 기능에 대한 문제의 해결의 R&R은 My boundary안에 있다면 문제를 해결하는 곳에서 처리를 해야 한다. 어떤 구조적인 문제로 문제가 전파가 되는 경우라면 그 문제를 My boundry에 갇아두고 다른 곳에는 영향을 끼치기 않게 해야 한다.  

그렇게 R&R과 boundary를 만들어도 애매할 때 가장 중요한 원칙은 중복제거과 I/O throttling이다. 중복없이 역할을 가질 수 있는 방법을 찾거나 중복을 최소화해야 한다. 변경에 대해서 도메인 지식으로 가장 많이 알고 부분에서 주도권을 갖는 것으로 엑세스는 권한을 한군데로 집중해서 분산되지 않아야 한다. 둘다 애매한 경우에는 새로운 R&R을 가지는 컴포넌트를 만드는 경우가 있다. 새로운 R&R을 가지는 컴포넌트는 애매한 역할을 명확하게 만들고 그 역할의 문제를 해결해야 한다.

지난 주에는 2개의 인프라성 서비스와 회의를 할 시간이 있었다.

하나의 인프라는 새로운 기능 추가에 대한 업무를 최소화하기 위해서 중복을 허용하면서 R&R을 줄이려는 얘기를 계속한다. 원칙이나 룰도 없이 "어렵다/힘들다/공수가 많이 든다/자신이 없다"만 반복한다.

또 하나의 인프라는 이미 추가된 기능일지라도 인프라성으로 가져갈 수 있는 부분을 더 제공해서 서비스에서는 서비에 충실한 비즈니스 로직에만 집중을 할 수 있게 해준다. 오히려 너무 많은 부분에서 고려를 하는 것 같아서 메인Role에 집중을 할 수 있게 의견을 주었다. 

정확한 분석/설계으로 통해서 R&R을 정확하게 만들지 않고 업무량을 줄이기 위한 방법으로 방향성을 정하는 경우가 있다. 주로 꼼수라는 표현을 많이 쓰는데 꼼수는 또 다른 꼼수를 하게 되고 변경에 제약사항이 계속 늘어가게 된다. 이 부채의 비용은 시간이 흐를 수록 급속도로 높아져서 결국에는 전체 시스템에 부담을 주게 된다.

객체지향설계/개발을 통해서 얻는 배움은 올바른 객체지향시스템에 대해서 알수 있게 하고 더 나아가서는 조직업무에도 적용을 할 수 있는 사고이다. 다양한 사람과 큰 그림에 대해서 이야기를 하다가보면 코드를 작성할 때도 어떤 식으로 하는지 뻔히 보인다. 구분하고 나누는 것은 쉽지 않은 일은 맞지만 원칙에 맍게 끊임없이 좋은 방향에 대해서는 고민을 해야 한다. 이미 잘못되어있다면 개선하는 것 그게 우리가 해야할 일 아닌가?
 
Posted by ologist
트랙백0 댓글1
이전버튼 1 2 3 4 5 ... 67 이전버튼
블로그 이미지
ologist

공지사항

Yesterday124
Today68
Total31,725

달력

 « |  » 2012.01
일 월 화 수 목 금 토
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

최근에 받은 트랙백

글 보관함