npm 호출시 다음과 같은 에러가 발생했다. 

Error: Cannot find module 'npmlog'
    at Function.Module._resolveFilename (module.js:455:15)
    at Function.Module._load (module.js:403:25)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at /usr/local/lib/node_modules/npm/bin/npm-cli.js:19:13
    at Object.<anonymous> (/usr/local/lib/node_modules/npm/bin/npm-cli.js:75:3)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)

npm 의 문제가 있으니 이를 수정한 업그레이드가 있을까하고 업그레이드를 시도했으니 npm 6.6.0 가 이미 설치되어 있다고 한다. 

✗ brew upgrade npm
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
bacula-fd         erlang            galen             irssi             leiningen         liquibase         macosvpn          open-babel        openssl ✔         openssl@1.1       privoxy           repo              zpaq
 
Error: npm 6.6.0 already installed

그래도 동일한 문제가 발생했다. 이와 관련해서 인터넷 검색을 문제를 찾아보니 Cannot find module 'npmlog' following homebrew update & upgrade가 나왔다.

위에 나온 절차에 따라 node 삭제작업을 진행한다.

brew uninstall node
Uninstalling /usr/local/Cellar/node/6.6.0... (3,669 files, 40.9M)
node 6.1.0, 6.3.1 are still installed.
Remove all versions with `brew uninstall --force node`.
➜  honeymon git:(master) ✗ brew uninstall --force node
Uninstalling node... (7,484 files, 78.5M)
➜  honeymon git:(master) ✗ sudo rm -rf /usr/local/lib/node_modules
Password:
➜  honeymon git:(master) ✗ brew install node
==> Downloading https://homebrew.bintray.com/bottles/node-6.6.0.el_capitan.bottle.tar.gz
Already downloaded: /Users/honeymon/Library/Caches/Homebrew/node-6.6.0.el_capitan.bottle.tar.gz
==> Pouring node-6.6.0.el_capitan.bottle.tar.gz
==> Using the sandbox
==> Caveats
Please note by default only English locale support is provided. If you need
full locale support you should either rebuild with full icu:
  `brew reinstall node --with-full-icu`
or add full icu data at runtime following:
  https://github.com/nodejs/node/wiki/Intl#using-and-customizing-the-small-icu-build
 
Bash completion has been installed to:
  /usr/local/etc/bash_completion.d
==> Summary
🍺  /usr/local/Cellar/node/6.6.0: 3,669 files, 40.9M


  1. 2016.10.06 17:39

    비밀댓글입니다

  2. 2016.10.07 16:09

    비밀댓글입니다

Bower, A package manager for the web
Web sites are made of lots of things — frameworks, libraries, assets, utilities, and rainbows. Bower manages all these things for you.
> 최근의 웹사이트는 다양한 것들(프레임워크, 라이브러리, 자원, 유틸리티 그리고 레인보우(!?))로 만들어진다. Bower는 이 모든 것을 관리한다.

Bower는 찾고자 하는 것들을 각지에서 탐색하고, 다운로드하고, 설치하고 붙인다. Bower는 bower.json 매니페스트 파일을 기준으로 패키지들을 추적관리한다.
어떤 패키지를 사용할지는 사용자에게 달려있다.

Bower는 프론트엔드에 최적화되어 있다. Bower는 간단한 의존성구조, 각 패키지별 대표버전만을 요구하며, 페이지로드를 최소한으로 감소시킨다.

1. Bower 설치

Bower는 커맨드라인 유틸리티다. npm*(https://www.npmjs.com/) 이 설치되어 있어야 한다.

$ npm install -g bower

Bower는 Node 그리고 npm  Git을 필요로 한다.

2. 시작

2.1. 패키지 설치

패키지 설치는 bower install 이용한다. Bower가 설치한 패키지는 bower_components/에 설치된다.

$ bower install <package>

패키지는 github, git 엔드포인트, URL 그리고 기타등등이 가능하다. 보다 자세한 내용은 bower install 을 살펴보기 바란다.

# registered package
$ bower install jquery
# GitHub shorthand
$ bower install desandro/masonry
# Git endpoint
$ bower install git://github.com/user/package.git
# URL
$ bower install http://example.com/script.js

2.2. 패키지 검색

Search Bower pacakge와 선호하는 프로젝트의 등록된 패키지명을 검색한다.

2.3. 패키지 저장

패키지 저장은 bower init 을 통해서 bower.json 에 등록한다.

2.4. 패키지 사용

패키지를 사용하는 것은 사용자가 결정한다. Bower와 함께 Grunt, RequireJS, Yeoman, 그리고 다양한 도구들을 함께 사용하거나,
빌드할때 API를 활용하는 것을 권장한다. 또한 설치된 패키지를, 다음의 jquery사용의 경우처럼, 바로 사용할 수도 있다.

<script src="bower_components/jquery/dist/jquery.min.js"></script>

다음은 RequireJS를 이용하여 각 페이지별 자바스크립트 파일/모듈을 적재해보자.

참고


  1. ... Java 백엔드 개발도 잘 못하는데... 프론트엔드도 깨작거리게 되었다.

각 안드로이드 프로젝트는 AndroidManifest.xml 이라는 매니페스트 파일을 가지는데, 이는 해당하는 프로젝트 계측구조의 루트에 저장된다.

매니페스트는 애플리케이션을 구성하는 각각의 컴포넌트(액티비티, 서비스, 콘텐츠 공급자, 브로드캐스트 수신자)에 대한 노드를 포함하고 있으며, 인텐트 필터(Intent Filter)와 권한(Permission)을 사용해 이들이 다른 컴포넌트 및 애플리케이션과 어떻게 상호작용하는지를 결정한다. 또한, 애플리케이션 메타데이터(아이콘이나 테마 같은)를 지정하기 위한 속성을 비롯해, 보안 설정과 단위 테스트에 사용될 수 있는 추가적인 최상위 노드 역시 제공

매니태그는 프로젝트의 패키지 설정을 위한 package 속성을 갖는 manifest 루트 태그로 구성된다.

  1. <manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.android.helloworld"
          android:versionCode="1"
          android:versionName="1.0">
      [...매니페스트...]
    </manifest>

 

manifest 태그는 애플리케이션을 구성하는 애플리케이션 컴포넌트, 보안 설정, 테스트 클래스를 정의하는 노드를 가진다.

  • application   매니페스트는 오직 하나의 애플리케이션 노드만을 가질 수 있다. 애플리케이션 노드는 속성을 사용해 개발자의 애플리케이션을 위한 메타데이터(타이틀, 아이콘, 테마 등)을 지정한다. 또한 애플리케이션 노드는 애플리케이션 컴포넌트를 지정하는 데 사용되는 액티비티, 서비스, 콘텐츠 공급자, 브로드 캐스트 수신자 태그를 담는 컨테이너 역할을 한다.

    1. <application android:icon="@drawable/icon" android:label="@string/app_name">
      [...애플리케이션 노드...]
      </application>

 

  • activity   activity 태그는 애플리케이션에 의해 보여지는 모든 액티비티에 필요하며, android:name 속성으로 클래스 이름을 지정한다. 매니페스트에 정의되지 않은 액티비티를 시작하려 하면 런타임 예외가 던져질 것이다. 각 액티비티 노드는 그 액티비티를 띄울 인텐트를 지정하는 intent-filter 자식 태그를 지원한다.
  1. <activity android:name=".Helloworld"
                      android:label="@string/app_name">
                <intent-filter>
                    <action android:name="android.intent.action.MAIN" />
                    <category android:name="android.intent.category.LAUNCHER" />
                </intent-filter>
    </activity>

 

  • service   activity와 마찬가지로, 애플리케이션에서 사용되는 각 서비스 클래스에 대해 새로운 service 태그를 하나씩 생성한다. 서비스 태그 역시 늦은 런타임 바인딩(Late runtime binding)을 지원하기 위한 intent-filter 자식 태그를 지원한다.
  1. <service android:enabled="true" android:name=".MyService"></service>

 

  • provider   provider 태그는 애플리케이션이 가진 각각의 콘텐츠 공급자에 대해 사용된다. 콘텐츠 공급자는 애플리케이션 간의 데이터베이스 접근과 공유를 관리하기 위해 사용된다.
  1. <provider android:permission="com.android.MY_PERMISSION"
            android:name=".MyContentProvider"
            android:enabled="true"
            android:authorities="com.android.myapp.MyContentProvider">
    </provider>

 

  • receiver   receiver 태그를 추가하면 애플리케이션을 띄우지 않고서도 브로드캐스트 수신자를 등록할 수 있다. 브로드캐스트 수신자는 한번 등록되고 나면 애플리케이션에 의해 일치하는 인텐트가 방송될 때마다 실행되는 전역 이벤트 리스너(event listener)와 같다. 브로드캐스트 수신자를 매니페스트에 등록함으로써, 이 처리를 완전히 자립적으로 만들 수 있다.
  1. <receiver android:enabled="true"
            android:label="My Broadcast Receiver"
            android:name=".MyBroadcastReceiver">
    </receiver>

 

  • user-permission   보안 모델의 일부로서, uses-permission 태그는 애플리케이션이 올바르게 동작하는 데 필요하다고 생각되는 권한을 선언한다. 애플리케이션 설치 과정 중 사용자에게 제시되어 권한 부여 혹은 거절이 결정될 것이다. 권한은 많은 네이티브 안드로이드 서비스에 요구되며, 특히 비용이 수반되거나 보안에 관계된 것들(전화 걸기나 SMS 수신 또는 위치기반 서비스(LBS) 사용 같은)에는 필수적이다.
  1. <uses-permission android:name="android.permission.ACCESS_LOCATION">
    </uses-permission>

 

  • permission   어떤 애플리케이션 컴포넌트에 대한 접근을 제한할 수 있으면, 권한을 매니페스트에 정의할 필요가 있다. 이러한 권한 정의를 생성하는 데에는 permission 태그가 사용된다. 이렇게 권한을 정의하고 나면, 애플리케이션 컴포넌트는 adnroid:permission 속성을 추가해 그 권한을 요청할 수 있다. 다른 애플리케이션이 보호된 이들 컴포넌트를 사용할 수 있으려면, 먼저 자신의 매니페스트에 uses-permission 태그를 포함해야 할 것이다(그리고 그 권한을 부여 받아야 할 것이다).
    permission 태그 안에 허용할 권한의 접근수준(normal, dangerous, signature, signatureOrSystem)과 레이블 그리고 그 권한이 주어짐으로써 오는 위험성에 대한 설명을 담은 외부 리소스를 지정할 수 있다.
  1. <permission android:name="com.android.DETONATE_DEVICE"
            android:protectionLevel="dangerous"
            android:label="Self Destruct"
            android:description="@string/detonate_desciption">
    </permission>

 

  • instrumentation   계측(instrumentation) 클래스는 실행 시에 액티비티와 서비스를 테스트하기 위한 프레임워크를 제공한다. 이들 클래스는 애플리케이션과 그가 갖는 시스템 리소스와의 상호작용을 모니터하기 위한 고리를 제공한다. 애플리케이션을 위해 생성한 테스트 클래스 각각에 대해 새로운 노드 하나씩을 생성한다.
  1. <instrumentation android:label="My Test"
            android:name="MyTestClass"
            android:targetPackage="com.android.aPackage">
    </instrumentation>

 

manifest.png ADT(Android Develope Tools)의 새 프로젝트 마법사는 새로운 프로젝트를 만들 때 자동으로 새 매니페스트 파일을 생성한다. 애플리케이션의 각 컴포넌트를 배워나감에 따라 다시 이 매니페스트로 되돌아 올 것이다.

이 글은 스프링노트에서 작성되었습니다.

+ Recent posts