개발 피드 목록

클라우드 컴퓨팅은 인터넷으로 가상화 된 IT 리소스를 서비스로 제공하는 것을 의미합니다. 그리고 클라우드 컴퓨팅에서 가상화 하여 서비스로 제공하는 대상은 인프라스트럭쳐, 플랫폼, 소프트웨어입니다. AWS와 Azure가 대중화되면서 클라우드를 인프라스트럭쳐의 가상화 개념으로만 이해하기도 하지만 클라우드는 인프라스트럭쳐 뿐만이 아니라 플랫폼과 소프트까지 포함하는 온라인의 모든 영역을 다루는 꽤 광범위한 개념입니다. 그렇기 때문에 클라우드는 분야별 특성별로 나누어서 이해하는 것이 좋습니다. 클라우드 서비스의 종류는 아래와 같이 크게 3가지로 나눌 수 있습니다. Infrastructure as a Service (IaaS, 아이아스, 이에스)서비스로 제공되는 인프라스트럭처입니다. 개발사에 제공되는 물리적 자원을 가상화합니다. Platform as a Service (PaaS, 파스)서비스로 제공되는 플랫폼입니다. 개발사에 제공되는 플랫폼을 가상화합니다.Software as a Service (SaaS, 사스)서비스로 제공되는 소프트웨어입니다. 고객에게 제공되는 소프트웨어를 가상화합니다.클라우드 구분하여 알아보자IaaS: 서비스로 제공하는 인프라스트럭쳐클라우드 인프라스트럭처 서비스는 확장성이 높고 자동화된 컴퓨팅 리소스를 가상화하여 제공하는 것입니다. IaaS는 컴퓨팅, 네트워킹, 스토리지 및 기타 인프라스트럭쳐를 사용하기 위한 서비스이며 사용자는 필요할 때 마다 서비스를 통해 리소스를 구입할 수 있습니다.(IaaS는 한국에서 이아스 또는 아이아스로 부르며 영미권에서는 이에:스 또는 아이아스로 발음합니다.)PaaS: 서비스로 제공하는 플랫폼클라우드 플랫폼 서비스는 주로 응용 프로그램을 개발 할 때 필요한 플렛폼을 제공하는 것입니다. PaaS는 사용자 정의 응용 프로그램을 개발하고 사용할 수있는 개발자를위한 프레임워크를 제공합니다. 개발사는 미들웨어를 설치하지 않고도 미들웨어에서 제공하는 API를 사용하여 소프트웨어를 개발할 수 있습니다. SaaS : 서비스로 제공하는 소프트웨어클라우드 애플리케이션(소프트웨어) 서비스는 사용자에게 제공되는 소프트웨어를 가상화하여 제공하는 것입니다. SaaS는 타사 공급 업체가 관리하는 사용자에게 응용 프로그램을 제공하기 위해 인터넷을 사용합니다. 대부분의 SaaS 애플리케이션은 웹 브라우저를 통해 직접 실행되므로 클라이언트 측에서 다운로드 나 설치가 필요하지 않습니다.무엇을 제공하는가클라우드는 온라인의 광범위한 영역을 모두 다루는 광범위한 영역입니다. 클라우드 서비스들은 제공하는 범위에 따라 IaaS, PaaS, SaaS로 나뉘고 있으므로 각각의 클라우드 서비스가 제공하는 내역을 살펴보는 것은 클라우드를 이해하는 데 많은 도움이 됩니다. IaaS: 물리적 자원 제공IaaS는 고객에게 서버, 네트웍, OS, 스토리지를 가상화하여 제공하고 관리합니다. IaaS는 가상화 된 물리적인 자산을 UI형태의 대시보드 또는 API로 제공합니다. IaaS의 고객들은 서버와 스토리지를 접근할 수 있지만 사실상 클라우드에 있는 가상 데이터 센터를 통해 리소스를 전달받는 형태입니다. IaaS는 기존의 데이터센터에서 제공받던 물리적인 자산을 완벽하게 가상화하여 제공하기 때문에 서버 사양의 변경 등 물리적 자산의 수정이 필요한 경우 기존의 방식에 비해 훨씬 빠른 대응이 가능합니다.IaaS의 제공업체는 서버, 하드 드라이브, 네트워킹, 가상화 및 스토리지를 관리하며 고객은 OS, 미들웨어, 애플리케이션 및 데이터와 같은 자원들을 관리해야 합니다. PaaS: 소프트웨어 개발을 돕는 플랫폼 제공PaaS는 고객에게 OS, 미들웨어, 런타임과 같은 소프트웨어 작성을위한 플랫폼을 가상화하여 제공하고 관리합니다. 이 가상화 된 플랫폼은 웹을 통해 제공되며 개발자는 운영 체제, 소프트웨어 업데이트, 저장소 또는 인프라에 대한 관리 없이 소프트웨어 개발에 집중할 수 있습니다.PaaS를 사용하면 기업에서는 특수 소프트웨어 구성 요소를 사용하여 PaaS에 내장 된 응용 프로그램을 설계하고 만들 수 있습니다. 이러한 응용 프로그램 또는 미들웨어는 특정 클라우드 특성을 채택 할 때 확장 가능하고 가용성이 높습니다.SaaS: 고객이 사용하는 소프트웨어 제공SaaS는 고객을 대신하여 소프트웨어와 데이터를 제공하고 관리합니다. 패키지 또는 On-Prems 방식이라고 하는 기존의 소프트웨어 전달 방식과 다르게 SaaS는 개별 컴퓨터에 응용 프로그램을 다운로드하고 설치할 필요가 없습니다. SaaS를 통해 서비스를 공급하는 업체는 데이터, 미들웨어, 서버 및 스토리지와 같은 모든 잠재적 인 기술적 문제를 관리하기 때문에 고객은 유지 보수 및 지원을 간소화 하면서 비지니스에 집중 할 수 있습니다.클라우드의 장점과 단점클라우드 인프라 서비스를 사용할 때의 장점과 클라우드 소프트웨어 서비스를 사용할 때의 장점은 다를 수 밖에 없습니다. 이에 3가지 클라우드 서비스의 장점과 단점을 각각 설명합니다. IaaS: 장점비용물리적 자원을 소비 형태로 사용하기 때문에 고정비가 들지 않습니다.속도물리적 자원을 즉시 소비할 수 있습니다.관리물리적 자원에 대한 관리를 논리적인 영역으로 대체할 수 있습니다.물리적 자원에 대한 자동화 된 배포가 가능합니다.물리적 자원에 대한 안정적인 운영을 벤더에 맞길 수 있습니다.물리적 자원에 대한 규모의 확장 또는 축소가 자유롭습니다. PaaS: 장점비용필요한 플랫폼만 소비 형태로 사용하기 때문에 비용 부담을 덜 수 있습니다. 속도개발 및 배포 프로세스를 빠르게 확보할 수 있습니다.관리소프트웨어 유지 관리가 쉬워집니다.가상화 기술을 기반으로 구축되어 비즈니스가 변함에 따라 리소스를 쉽게 확장 또는 축소 할 수 있습니다.응용 프로그램의 개발, 테스트 및 배포를 지원하는 다양한 서비스를 제공합니다.수많은 사용자가 동일한 개발 응용 프로그램에 액세스 할 수 있습니다.PaaS: 단점특정 플랫폼 서비스에 종속될 수 있습니다.SaaS: 장점SaaS는 소프트웨어 설치, 관리 및 업그레이드와 같은 지루한 작업에 소요되는 시간과 비용을 크게 줄임으로써 직원과 회사에 많은 이점을 제공합니다. 따라서 기술 직원이 조직 내에서 보다 긴급하고 중요한 문제에 집중할 수 있습니다. 비용소프트웨어를 소비 형태로 사용하기 때문에 비용 부담을 덜 수 있습니다.속도즉시 사용이 가능합니다. 관리소프트웨어를 설치할 물리적 자원이 필요하지 않습니다.언제 어디서든 접근가능합니다.SaaS: 단점커스터마이징이 어렵습니다. 클라우드 언제 적용해야 하는가IaaS: 빠른 변화를 원한다면스타트업이나 중소기업에게 IaaS는 훌륭한 옵션이므로 하드웨어나 소프트웨어를 설치하는데 시간과 돈을 낭비 할 필요가 없습니다. IaaS는 응용 프로그램과 인프라를 완벽하게 제어하고자하는 대규모 조직에 유용하지만 실제로 소비되거나 필요로하는 것을 구매하려는 경우에만 유용합니다. 빠르게 성장하는 기업의 경우, IaaS는 요구 사항이 변화하고 발전함에 따라 특정 하드웨어 나 소프트웨어에 전념 할 필요가 없으므로 좋은 선택이 될 수 있습니다. 또한 필요에 따라 확장 또는 축소 할 수있는 많은 유연성이 있으므로 새로운 응용 프로그램에 어떤 요구가 필요한지 확실하지 않은 경우 도움이됩니다.PaaS: 신속한 개발을 원한다면PaaS를 이용하는 것이 유익하거나 필요한 경우가 많이 있습니다. 동일한 개발 프로젝트를 수행하는 여러 개발자가 있거나 다른 공급 업체도 포함해야하는 경우 PaaS는 전체 프로세스에 뛰어난 속도와 유연성을 제공 할 수 있습니다. PaaS는 사용자 정의 된 응용 프로그램을 만들려는 경우에도 유용합니다. 또한이 클라우드 서비스는 비용을 크게 절감 할 수 있으며 앱을 신속하게 개발하거나 배포하는 경우 발생하는 몇 가지 문제를 단순화 할 수 있습니다.SaaS: 비지니스에 집중하고 싶다면보안상 민감한 사항이 아니라면 모든 기업에게 SaaS는 훌륭한 옵션입니다. 또한 협업이 필요한 단기 프로젝트라면 SaaS 를 도입하는 것이 훨씬 유리합니다. 일반적으로 On-Prems 솔루션은 모바일 액세스를 지원하지 않기 때문에 모바일 액세스가 필요한 경우에도 SaaS를 사용하면 비용가 시간을 절약할 수 있습니다.클라우드 서비스 예클라우드는 적용된 분야별로 이해해야 합니다. 아래는 분야별 서비스 예입니다. IaaSAmazon Web Services (AWS), Microsoft Azure, DigitalOcean, Google Compute Engine (GCE)PaaSAWS Elastic Beanstalk, Windows Azure, Heroku, Google App EngineSaaSGoogle Apps, Dropbox, Salesforce, WhaTap마무리지금도 많은 기업의 임원분들이 클라우드의 적용 여부에 대해 고민을 하고 있으며 많은 스타트업들이 클라우드 기반의 서비스를 만들어 가고 있습니다. 회사에 클라우드를 도입해야 한다면 IaaS를 도입할 지, PaaS를 도입할 지 아니면 SaaS를 도입해야 하는지 알고 있어야 합니다. 그리고 자사의 서비스가 클라우드 기반의 서비스라면 고객에게 왜 도입해야 하는지 쉽게 설명할 수 있어야 합니다. 제가 다니는 와탭랩스(whatap.io)는 국내에서 드물게 SaaS 모니터링 서비스를 제공하고 있습니다. 2015년 1월에 시작한 서비스는 이제 만 4년을 달려가고 있습니다. 앞으로 한국에서 더 많은 클라우드 서비스들이 나왔으면 합니다. #와탭랩스 #개발자 #개발팀 #클라우드서비스 #서비스소개

대략 1년 반 전, 5.0 롤리팝과 함께 나타난 RecyclerView. ListView 를 이용할 때 아주 기초적이고 정석적인 개념으로 사용되던 ViewHolder pattern 을 반 강제화? 하면서 동시에 성능까지 개선한 ListView 의 개량버전.앱 시장이 활성화되면서 한 가지 타입의 뷰만 반복적으로 보여주는 단순한 구성보다는 다양한 타입의 뷰를 보여주는 앱들이 많아지고 보편화 된 시점에 이것을 구현하기 위한 Adapter.getView 메소드는 혼돈.chaos 가 되었지요. 가독성을 높일만한 나름대로의 시도를 해보고 있을 때, RecyclerView 가 갑툭튀 했고 이걸 이용하면 원하는 만큼의 많은 타입의 뷰를 “가독성 좋게 만들어 볼 수 있겠다” 라는 생각이 들었습니다.그래서 RecyclerView.Adapter 를 상속 받아 다양한 타입의 뷰를 바인딩 할 수 있게 도와주는 헬퍼 클래스, MultiItemAdapter 라는 것을 만들어 보게 됐습니다. 구 회사 프로덕트에 적용해보기도 하고, 개인 프로젝트에 넣어보기도 하고, 토스랩에서 서비스하고 있는 “잔디”에 녹여내보기도 했는데 나쁘지 않은 느낌이들어 그 과정을 공유하고 많은 분들께 피드백도 받고 싶습니다. 또, 어떻게 더 잘 활용하고 계신지 여쭙고 싶습니다.RecyclerView.Adapter 의 이해를 위해 단순단순하게 만들어보자public class BasicAdapter extends RecyclerView.Adapter { private List mItems = new ArrayList<>(); @Override public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } @Override public void onBindViewHolder(MyViewHolder holder, int position) { holder.mTextView.setText(mItems.get(position)); } class MyViewHolder extends RecyclerView.ViewHolder { private TextView mTextView; public MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } } ... 이런 식으로 구현하면 되는군, 하지만 내가 최종적으로 원하는 건 다양한 ViewHolder 를 다뤄야 되는 건데 ViewHolder 가 많아지는 경우 inner class 는 쓰면 안되겠다! ViewHolder 들은 따로 패키지 만들어서 관리하자. 음 근데 ViewHolder 를 구성하고 난 다음 어떻게 그려지는 지에 대해 궁금하면 다시 어댑터를 찾아가야 되고, 반대로 어댑터에서 ViewHolder 내 구성요소가 어떻게 생겼는지 궁금하면 다시 ViewHolder 찾아가서 뒤져봐야되는 군. 이건 비효율 적인 것 같다. ViewHolder에 뷰를 그리는 메소드를 하나 만들자. 아 기왕이면 추상화된 클래스를 만들어 돌려돌려 쓰자. 하나 더 Generic 을 사용하자.public abstract class BaseViewHolder extends RecyclerView.ViewHolder { public BaseViewHolder(View itemView) { super(itemView); } public abstract void onBindView(ITEM item); } 뷰를 그리는데 쓰이는 객체는 Generic 을 이용하면 ViewHolder 안에서 그리는 작업 또한 해결이 가능하겠군! 이걸 이용해서 다시 만들어보자.public class MyViewHolder extends BaseViewHolder { private TextView mTextView; public MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } @Override public void onBindView(String item) { mTextView.setText(item); } } ... public class BaseAdapter extends RecyclerView.Adapter { private List mItems = new ArrayList<>(); @Override public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } @Override public void onBindViewHolder(MyViewHolder holder, int position) { holder.onBindView(mItems.get(position)); } public void setItems(List items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemCount() { return mItems.size(); } } 음 원하는 모양새다. 근데 이제 Adapter 에선 ViewHolder 에 들어갈 layout 이 어떤 건지 관심꺼도 되겠네. 게다가 ViewHolder 에서 layout 궁금하면 다시 또 찾아와야 되는게 문제다. 좀 더 명시적인 방법으로 Factory method 로 생성자를 제한해보자. RecyclerView.ViewHolder 는 View 를 가지는 생성자가 강제되니 이렇게 바꾸자.public static MyViewHolder newInstance(ViewGroup parent) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } private MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } 이렇게 하면 어떤 layout 을 다루고 있는지도 금방 알 수 있겠다. 이 정도만 되도 구색을 다 갖춘듯하니 이 느낌으로 다양한 타입의 뷰들을 다뤄보자.public class BasicMultiTypeAdapter extends RecyclerView.Adapter { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; private List mItems = new ArrayList<>(); @Override public BaseViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { return AViewHolder.newInstance(parent); } else { return BViewHolder.newInstance(parent); } } @Override public void onBindViewHolder(BaseViewHolder holder, int position) { holder.onBindView(mItems.get(position)); } public void setItems(List items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemCount() { return mItems.size(); } @Override public int getItemViewType(int position) { if (position % 2 == 0) { return VIEW_TYPE_A; } else { return VIEW_TYPE_B; } } } 음 깔끔하긴 하다. 근데 getItemViewType 이 스크롤 할 때마다 불릴 텐데, 분기도 많고 연산이 생겼을 때 스크롤 속도에 괜한 영향을 줄 듯? view type 을 차라리 미리 가지고 있게 만들자. 또! 가만보니 한 타입의 객체를 이용해서 다른 스타일로 뷰를 보여줄 뿐이었네. 이것도 여러가지 객체를 담을 수 있게 만들어야지.뷰를 그릴 대상이 될 객체랑 타입을 가지는 Wrapper class 를 만들어서 해결하자. 이러면 Adapter.onBindViewHolder 랑 Adapter.getItemViewType 도 해결이 되겠군.public abstract class MultiItemAdapter extends RecyclerView.Adapter { private List mRows = new ArrayList<>(); @SuppressWarnings("unchecked") @Override public void onBindViewHolder(BaseViewHolder holder, int position) { holder.onBindView(getItem(position)); } @SuppressWarnings("unchecked") public ITEM getItem(int position) { return (ITEM) mRows.get(position).getItem(); } public void setRows(List mRows) { mRows.clear(); mRows.addAll(mRows); } @Override public int getItemCount() { return mRows.size(); } @Override public int getItemViewType(int position) { return mRows.get(position).getItemViewType(); } public static class Row { private ITEM item; private int itemViewType; private Row(ITEM item, int itemViewType) { this.item = item; this.itemViewType = itemViewType; } public static Row create(T item, int itemViewType) { return new Row<>(item, itemViewType); } public ITEM getItem() { return item; } public int getItemViewType() { return itemViewType; } } } MultiItemAdapter 완성.네, 저는 이렇게 만들어서 1년 반 정도 필요한 부분(복잡해 질만한 부분)에 이 클래스를 상속받아 구현했습니다. 사용방법을 예로들어 데이터베이스나 서버로부터 긁어온 아이템들을 타입에 따라 A, B로 나눠서 보워줘야 한다면,// MutiItemAdapter 구현 public class AdvancedItemAdapter extends MultiItemAdapter { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; @Override public BaseViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { return AViewHolder.newInstance(parent); } else { return BViewHolder.newInstance(parent); } } } // Activity 나 Fragment 등 view 요소에서 ListAdapter item setting. public void setItems(List items) { List rows = new ArrayList<>(); for (int i = 0; i < items xss=removed>이렇게 해주면 됩니다. 그런데 위 사용방법을 보면 추가적인 새로운 타입(Row)의 List 와 반복문을 돌려야 된다는 것이 단점으로 보이는데요. 그럼 이 클래스를 사용하지 않고 직접 구현한 결과를 좀 볼까요?public class NormalItemAdapter extends RecyclerView.Adapter { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; private List mItems = new ArrayList<>(); @Override public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new AViewHolder(itemView); } else { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new BViewHolder(itemView); } } @Override public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) { if (holder instanceof AViewHolder) { Item item = getItem(position); ((AViewHolder) holder).getTextView().setText(item.getName()); } else { ((BViewHolder) holder).getTextView().setText("I am B."); } } private Item getItem(int position) { return mItems.get(position); } public void setItems(List items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemViewType(int position) { if (getItem(position).getType().equals(Item.ITEM_TYPE_A)) { return VIEW_TYPE_A; } else { return VIEW_TYPE_B; } } @Override public int getItemCount() { return mItems.size(); } } 뭐, 나쁘진 않습니다. 이 정도 수준으로 개발이 끝나도 되고 추가적인 확장이 필요하지 않아보인다면 굳이 MultiItemAdapter 를 쓸 필요가 없습니다.중요성을 가지는 리스트 위주의 화면에서 위와 같이 개발된다면 당장 보이는 제 불만은 onCreateViewHolder, onBindViewHolder 계속해서 분기가 들어가게 되고 getItemViewType 에서는 계속 해서 List 데이터에 접근해야 한다는 것입니다. 접근 자체가 큰 문제, 큰 영향을 끼치지 않을 정도 규모의 자료구조라면 논외로 치더라도, 뷰 타입이 조금만 늘어나도 onCreateViewHolder, onBindViewHolder 의 덩치는 엄청 커질 겁니다.예를들면 맨 마지막 아이템 타입이 B 이고 현재 추가 될 아이템 타입이 A인 경우에는 다른 형태의 디바이더를 넣어야 한다던지 하는 추가적인 확장이 이루어져야 한다면 골치가 꽤 아플겁니다. 특히 저는 위 예와 비슷하게 뷰 타입에 따라 각기 다른 아래 위 마진값을 요구받을 때, ViewHolder 마다 이전 데이터를 참고하게 만들고 동적으로 Visibility 처리를 하거나 MarginLayoutParams 를 고치는 것이 비효율적으로 느껴져서 height를 주입받는 DividerViewHolder 를 하나 만들어 사용하곤 했습니다. 이렇게 하니 각각의 ViewHolder 들이 데이터들에 의존적이지 않게 코딩이 가능했었습니다. 한 가지 더 예를들어 리스트 중간 중간 광고가 보여지게 되고 이 광고 클래스는 완전히 다른 객체로부터 보여줘야 한다 라고 했을 때 MultiItemAdapter 를 이용하면 쉽게 해결이 가능합니다.정작 근 1년간 “잔디”를 만들면서는 자주 쓰진 않았는데, 작년부터 각광받기 시작한 MVP 패턴을 사용할 때 View 에서의 로직을 최소화 하려고 한다면 써먹을 수 있는 모델로 적합하지 않나 생각이 들면서 다시 사용하기 시작했습니다. Presenter 에서 Row 를 만들어 던져주면 View 는 그것을 그대로 사용하게 만들 수 있다는 생각이 들었거든요.(아직까지는 비교적 크지 않은 부분에서만 사용하게 되서 View(MainThread)에서 Row 를 만들게 코딩해 놓은 컴퍼넌트가 더 많네요 흑흑) 더 복잡한 구조를 갖는 컴퍼넌트를 만들어야 할 때는 비동기 스레드에서 Row 까지 만들어 내보내는 것도 해볼까 하는 생각도 듭니다.제 눈에만 괜찮은 구조인지, 생각지도 못한 치명적인 단점이 있진 않은지, 구조나 설계 측면에서 안 좋은 점은 있지 않은지, 논리없이 Generic 으로 “퉁” 치고 있는 코드는 아닌지, 여러가지가 많이 궁금합니다 ^^ MultiItemAdapter 를 쓴 것과 안 쓴것의 정말 심플한 비교 소스를 열어놓았습니다 MultiItemAdapter 또, 여러분들은 어떻게 구현하고 계신지요? 여러분의 관심이 필요합니다 ! :)#토스랩 #잔디 #JANDI #개발 #개발자 #인사이트 #경험공유

스토리 홈

인터뷰

피드

뉴스

REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁

MySQL의 Transaction Isolation Level (Lock에 관하여)

안드로이드 앱의 Persistent data를 제대로 암호화해 보자! (2/2)

개발자에게 필요한 좋은 개발도구들

제니퍼에서 새로운 가능성을 실험하라

ASIHTTPRequest를 대체하는 iOS 네트워킹 라이브러리 2가지

Team Profile: Meet Jungkap

Nodejs 기반의 개발 환경 클린하게 재 구성하기

클라우드 서비스 이해하기 IaaS, PaaS, SaaS

HBase상 트랜잭션 라이브러리 Haeinsa를 소개합니다

하나부터 열까지 모두 알려주겠다! Scatter 계정 만들기 (feat. HexBP 연동하기)

[사람이 서비스다] #4 JD, 안드로이드앱 개발 담당

다양한 형태를 지원하는 리스트 UI, 잘 그리고 계신가요?

Gradle Dependency 분리하기

코인원 개발자는 어떻게 일할까?

로봇 택시가 산업 지형을 바꾼다