스프링에서 404 에러가 나면
별도의 힌트 코드도 없이
404
The requested resource is not available.
이렇게 밖에 안나온다…
경로를 잘 설정해야한다. 특히 오타 -_- 멘붕이다…
특별히 이상한 코드가 아닌이상.. 대부분 경로 설정을 잘못했거나.
view를 보여질 페이지 에러 이거나..
담부턴 확실하게, 꼼꼼히 하자잉.~~ㅋ
스프링에서 404 에러가 나면
별도의 힌트 코드도 없이
404
The requested resource is not available.
이렇게 밖에 안나온다…
경로를 잘 설정해야한다. 특히 오타 -_- 멘붕이다…
특별히 이상한 코드가 아닌이상.. 대부분 경로 설정을 잘못했거나.
view를 보여질 페이지 에러 이거나..
담부턴 확실하게, 꼼꼼히 하자잉.~~ㅋ
저희 회사로 들어 오는 모든 지원서는 제가 가장 먼저 봅니다. 그리고, 일차적으로 검토를 해서 담당자에게 전달합니다. 이후 과정은 특별한 문제가 있지 않는 한 담당자의 판단을 전적으로 믿고 그에 따라 결정합니다. 함께 일할 동료에 대해서는 저보다 담당자가 더 좋은 결정을 하리라 믿기 때문입니다. 이번에 500여분의 지원서를 검토하면서도 같은 과정을 거치고 있습니다. 그러면서 많은 걸 느꼈는데요. 취업을 준비하는 그리고 이직을 준비하는 분들께 도움이 될까해서 간단히 정리해 봤습니다.
1. 지원서는 여러분과 회사가 1차로 만나는 통로입니다. 최대한 성의껏 작성해 주세요.
2. 어디서나 볼 수 있는 표준화된 포맷에 정형화된 내용으로 다른 지원자와 차별화하기 어렵습니다. 지원하는 회사에서 특별한 제한을 두고 있지 않다면, 지원서 부터 최대한 개성을 드러내 주세요.
3. 간혹 지원서를 보내면서 100MB가 넘는 파일을 첨부파일로 보내는 분들이 있습니다. 10MB가 넘으면 대용량 메일로 보내시는게 좋습니다.
4. 여러분이 이만큼 대단하다는 것을 나열식으로 풀지 말고, 여러분이 다른 사람과 어떻게 다른지를 강조해 주세요.
5. 지원서 안에 실수로 다른 회사의 이름을 적지 않도록 해 주세요 (copy & paste 주의)
6. ‘귀사’라는 말보다는 지원하는 회사의 이름을 적어주세요.
7. 메일을 받는 사람에 여러 회사를 넣지 말아주세요.
8. 신입의 경우 첫번째 회사를 정말 신중하게 고르세요. 그리고 최소 3년 이상은 근무하시길 권해 드립니다.
9. 경력의 경우 5년간 3번 이상의 이직을 했다면 경력 관리를 시작하시길 권해 드립니다.
10. 지원서를 보내면서 이메일 본문에 ‘첨부파일 참조’ 또는 ‘이력서 제출’ 심지어 아무 내용없이 보내는 분이 생각보다 많습니다. 짧게라도 본문에 내용을 적어주세요.
11. 포트폴리오를 구성할 땐 잘한 공동작업보다 개성있는 개인작업을 꼭 넣어주세요.
12. 회사의 사이트 뿐만 아니라 회사 혹은 대표자의 SNS도 미리 살펴 보세요. 마지막으로, 보내기 전에 ‘나라면, 이 지원서를 보고 어떤 생각을 하게 될까?’라는 질문을 던져보세요. 언젠가는 여러분과 인연이 이어지길 바라며…^^
우분투는 일반적인 리눅스 배포판들과 다른 구조를 하고 있다. 데비안 계열의 특징인듯…
/etc/apache2 : 설정파일 루트위치
설정파일들이 이 디렉토리 밑에 위치하고 있다.
/etc/apache2/apache2.conf : 기본설정 파일
다른 배포판에서 httpd.conf 를 기본 설정파일로 사용하고 있는데 우분투에서는 apache2.conf 를 사용한다.
/etc/apache2/conf.d : 고급설정 파일
다른 배포판에서 httpd.conf 파일 하나에 설정되어 있던 문자셋과 에러메시지, 보안과 관련된 설정등을 따로 따로 분리하여 conf.d 디렉토리밑에서 설정하고 있다. 또한 사용자가 설치하게 되는 Apache와 관련된 애플리케이션들의 설정파일들도 위치하게 된다.
/etc/apache2/envvars : apache2ctl 환경설정 파일
/etc/apache2/httpd.conf : 사용자의 특정 설정 파일
역사적으로 httpd.conf 가 기본설정 파일이였는데 지금은 빈파일이다.
사용자가 특정 설정을 부여해서 사용할 수 잇다.
/etc/apache2/magic
파일의 시작값(magic number) 데이터베이스. 이 값에 기반해 전송하는 파일의 MIME Type을 결정한다.
가급적 수정하지 말 것.
/etc/apache2/mods-available
사용가능한 Apache 모듈을 불러오는 곳
/etc/apache2/mods-enabled
위의 /etc/apache2/mods-available 의 모듈중에 사용할 모듈을 심볼릭 링크로 추가하여 실제 동작하게 만든다.
/etc/apache2/ports.conf
Apache 서버의 서비스 포트 설정으로 http 의 기본값 80 과 https 의 기본값 443, 가상호스트의 포트들을 설정할 수 있다.
/etc/apache2/sites-available
서버에서 운영할 사이트의 설정파일
/etc/apache2/sites-enabled
위의 /etc/apache2/sites-available 에서 설정한 파일을 심볼릭 링크로 추가하여 실제 운영에 사용할 설정파일들이다.
1. 기본 사이트 설정 사항 ( /etc/apache2/sites-available/default )
apache2 의 기본설정은 가상호스트 친화적이다.
기본적으로 VirtualHost 지시자에 의해 하나의 가상호스트가 설정되어 있고 하나의 사이트만을 운영할 계획이라면 이 가상호스트 설정이 기본적인 웹사이트가 된다.
/etc/apache2/sites-available/default 파일을 수정하여 사용하면 된다.
ServerAdmin 의 메일주소를 원하는 것으로 수정하고 다른 여러 다른 가상호스트에서 설정하지 않을 경우 대표메일 주소로 이용된다.
ServerName 이 지정되어 있지 않다.
이는 다른 가상호스트의 ServerName 과 매치되지 않는 모든 요청에 대하여 응답하게 된다.
이를 원하지 않는다면 ServerName 에 구입한 도메인을 추가한다.
ServerAlias 도 기본적으로 지정되어 있지 않지만 www 를 호스트명으로 이용하는 경우가 많으니 이를 추가해도 된다.
DocumentRoot 값은 /var/www 로 지정되어 잇는데 원한다면 이를 수정하여 사용할 수 있다.
<Directory> 지사자에 Option 항목에 Indexes 가 설정되어 있는데 이를 제거해서 파일리스트들이 출력되지 않게 할 수 있다.
<Directory /home/MyID/www/uzuro.com>
Option -Indexes FollowSymLinks MultiViews
2. 새로운 가상호스트 추가법
우선 default 파일을 복사해 원하는 파일명(사이트명)으로 변경한다.
새로운 사이트의 디렉토리를 생성하고 복사한 파일의 DocumentRoot의 경로를 설정한다.
a2ensite 유틸리티를 사용하여 추가한다.
$ sudo a2ensite mynewsite
$ sudo service apache2 restart
3. DirectoryIndex 설정
/etc/apache2/mods-available/dir.conf 에서 설정할 수 있으면 기본적으로 index.html, index.cgi, index.pl, index.php, index.xhtml, index.htm 이 설정되어 있다. 필요하다면 더 추가하면 된다.
위 파일들이 요청한 디렉토리에 없다면 <Directory> 지시자의 Option 값으로 Indexes가 설정되어 있을 경우 파일이 리스팅된다.
4. ErrorDocument 설정
/etc/apache2/conf.d/localized-error-pages 에서 설정할 수 있다.
5. Log 설정
Apache의 기본 로그 파일은 /var/log/apache2/ 디렉토리에 access.log, error.log, other_vhosts_access.log 로 존재한다. 가상호스트 설정에서 ErrorLog 지시자나 CustomLog를 따로 설정하지 않는다면 위에 언급한 파일들에 로그가 저장되고 만약 가상호스트에서 설정사항을 주석처리하거나 삭제한다면 other_vhosts_access.log 파일에 생성된다.
여러개의 사이트를 운영할 계획이라면 각각의 홈디렉토리에 logs 디렉토리를 생성하여 그곳에 위치하는 방법을 많이 사용한다.
6. Apache 서비스를 재시작할때마다 에러메시지가 함께 나올텐데 기본으로 설정된 사이트의 ServerName이 존재하지 않아서이다. 이는 /etc/apache2/apach2.conf 에 ServerName localhost 와 같이 추가하면 된다.
7. 새로운 모듈 추가
우분투는 기본적으로 동적으로 모듈을 불러오도록 컴파일되어 있다.
<IfModule> 블럭으로 둘러쌓아 특정한 모듈에 대한 지시를 할 수 있고 /etc/apache2/mods-enabled 에 등록하여 이를 사용할 수 있다.
/etc/apache2/mods-available 디렉토리에 존재하지 않는 모듈들은 apt-get등으로 설치한다.
$ sudo a2enmod ssl
$ sudo service apache2 restart
사용하지 않을 모듈은
$ sudo a2dismod ssl 과 같이 사용하고 apache 서비스 재시작
8. 리눅스 계정의 사용자들이 각각 홈디렉토리에서 웹사이트를 운영할때 설정
– /home/UserID/public_html 의 구조를 생성한다.
$ mkdir public_html (이때 폴더 소유자는 그계정의 사용자ID임에 유의)
– 유저디렉토리 모듈 활성화
$ sudo a2enmod userdir.conf
$ sudo a2enmod userdir.load
$ sudo service apache2 restart
( 사용자들이 http://서버도메인(IP)/~UserID 로 접근이 가능하게 된다 )
– $ sudo vi /etc/apache2/mods-available/userdir.conf 의 설정내용을 알맞게 변경
– php의 모듈 사용자 디렉토리에 활성화
php 모듈의 기본 설정이 기본적으로 /home/*/public_html 상에서는 사용불가로 되어 있다.
$ sudo vi /etc/apache2/mod-available/php5.conf
<IfModule mod_userdir.c> 부분부터 끝나는 블록까지 주석처리한다.
8. HTTPS 설정
The mod_ssl module adds an important feature to the Apache2 server – the ability to encrypt communications. Thus, when your browser is communicating using SSL, the https:// prefix is used at the beginning of the Uniform Resource Locator (URL) in the browser navigation bar.
The mod_ssl module is available in apache2-common package. Execute the following command from a terminal prompt to enable the mod_sslmodule:
sudo a2enmod ssl
There is a default HTTPS configuration file in /etc/apache2/sites-available/default-ssl. In order for Apache2 to provide HTTPS, a certificateand key file are also needed. The default HTTPS configuration will use a certificate and key generated by the ssl-cert package. They are good for testing, but the auto-generated certificate and key should be replaced by a certificate specific to the site or server. For information on generating a key and obtaining a certificate see Certificates
To configure Apache2 for HTTPS, enter the following:
sudo a2ensite default-ssl
The directories /etc/ssl/certs and /etc/ssl/private are the default locations. If you install the certificate and key in another directory make sure to change SSLCertificateFile and SSLCertificateKeyFile appropriately.
With Apache2 now configured for HTTPS, restart the service to enable the new settings:
sudo service apache2 restart
Depending on how you obtained your certificate you may need to enter a passphrase when Apache2 starts.
You can access the secure server pages by typing https://your_hostname/url/ in your browser address bar.
For more than one user to be able to write to the same directory it will be necessary to grant write permission to a group they share in common. The following example grants shared write permission to /var/www to the group “webmasters”.
sudo chgrp -R webmasters /var/www sudo find /var/www -type d -exec chmod g=rwxs "{}" \; sudo find /var/www -type f -exec chmod g=rws "{}" \;
If access must be granted to more than one group per directory, enable Access Control Lists (ACLs).
참고 : https://help.ubuntu.com/12.04/serverguide/httpd.html
자바에서 객체 안에 내용을 비교하고 싶을때 equals 문을 사용한다.
equals(“비교내용”) 혹은 객체 내용을 확인하고 싶을때 다음과 같이 써준다.
if ( valuse.equals(“result”))
… 실행문…
다음과 같이 해줄때 객체 안에 내용이 맞다면 실행이 된다.
자바 SMS 문자 보내기.
애플 APNS 활용하기
리눅스 권한 일괄 적용 -R 옵션
자바 난수 발생기
hudson.war 파일은 내부에 Winstone이라는 웹서버를 포함하고 있습니다.
기본포트는 8080과 ajp13 연결포트인 8009를 사용하고 있지요.
톰캣 등과 같은 서버에서 포트가 겹칠 경우 이 포트를 바꾸려면 다음과 같이 옵션을 주면 됩니다.
톰켓 같이 이용시에는 둘중에 하나는 변경을 해주는것이 좋겠네요,
java -jar jenkins.war –httpPort=7070 –ajp13Port=-1
옵션을 줄때는 – – 입니다.
-1은 사용하지 않는다는 뜻입니다. 위의 경우 7070포트로 접근이 가능합니다.
Jenkins는 반복되는 job들에 대한 실행을 모니터 하는 award-winning application 입니다. 예를 들어 소프트웨어 프로젝트를 빌드한다던가 cron에 의해 실행되는 job들 같은 경우 이지요. 그런 일들 중에 현재 Jenkins는 아래 두가지 job들에 포커스를 맞추고 있습니다.
Building/testing software projects continuously, just like CruiseControl or DamageControl. Jenkins는 지속적으로 integration이 진행되는 시스템 에서 이러한 일들을 쉽게 사용할 수 있도록 해 줍니다. 개발자들이 프로젝트를 진행하면서 이루어 지는 integrate change들을 쉽게 진행할 수 있도록 해 주는 것이죠. 그리고 빌드 하는 작업도 쉽게 진행하도록 도와 줍니다. 자동화되고 지속적인 빌드는 생산성을 높여줍니다.
cron job들과 procmail job들 같은 외부에서 실행되는 job들에 대한 모니터링을 합니다. 원격에서 실행되는 job들에 대한 모니터도 가능합니다. 예를 들어 cron의 경우 output을 capture 한 정기적인 이메일을 받는 일등이 있을 수 있습니다. 여러분은 정기적으로 이 이메일을 점검함으로서 뭔가 이상이 있을 때 이것을 알아챌 수 있는 것입니다. Jenkins는 이런 output들을 보관하고 뭔가 이상이 있을 때 여러분이 알아채기 쉽도록 도와줍니다.
하지만 지금 공부하고 있는 Jenkins의 로고는 아래 이미지 입니다.
Who is using it?
많은 회사들과 기관들이 이 Jenkins를 사용하고 있습니다. 대부분의 instance들은 firewall 안에서 실행되죠. 구글 같은 경우에는 public하게 visible한 instance들을 사용하기도 합니다. 여기를 보시면 anonymouse usage를 수집한 통계 자료를 보실 수도 있습니다.
Features
Jenkins 에는 아래와 같은 기능들이 있습니다.:
Easy installation: Just java -jar jenkins.war, 혹은 a servlet container 내에 deploy. 다른 추가적인 인스톨 필요 없음. 데이타베이스 필요 없음.
Easy configuration: web GUI를 통해서 쉽게 configuration을 할 수 있음. 실시간으로 에러 확인이 가능하고 inline help를 받을 수 있음. XML를 수정하고 하는 작업이 필요 없음. XML을 통해서 configuration을 하고 싶으면 그렇게 할 수도 있음
Change set support: Jenkins는 Subversion/CVS로부터 빌드하면서 만들어진 변화들의 리스트를 generate 할 수 있음. 이것은 repository 의 load를 줄이기 위한 아주 효율적인 방법입니다.
Permanent links: Jenkins는 대부분의 페이지에 대해 깔끔하고 가독성 있는 URL을 제공합니다. “latest build”/”latest successful build” 같은 permalinks등을 포함해서요. 그래서 다른 곳에서도 쉽게 링크 작업을 할 수 있습니다.
RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures. failure에 대한 실시간 notification들을 얻기 위한 RSS나 이메일에 의한 빌드 결과 모니터 함.
After-the-fact tagging: 오래전에 빌드가 완료된 것에 대해서도 tag가 가능합니다.
JUnit/TestNG test reporting: JUnit test report를 보여 줍니다. history 정보도 보여주고요. history trend도 그래프로 보여줍니다.
Distributed builds: Jenkins can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers’ desks.
File fingerprinting: Jenkins can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Jenkins, and is ideal for projects to track dependency.
Plugin Support: Jenkins can be extended via 3rd party plugins. You can write plugins to make Jenkins support tools/processes that your team uses.
Jenkins Best Practices
최근 automated test를 진행하는 Continuous Integration에서 Jenkins를 많이 채택하고 있습니다. CI(Continuous Integration)의 개념이 이제는 Build Management, Release Management, Deployment Automation, and Test Orchestration 쪽으로 바뀌고 있습니다. 이 섹션에서는 Jenkins를 사용하기 위한 best practic 들의 세트를 제공합니다. – A Continuous Integration Solution to provide executives, business managers, software developers and architects a better sense of the development progress and code quality of projects throughout the development lifecycle. (View Jenkins Best Practices)
Introductory Articles
아래 링크들 중 많은 부분이 Hudson을 참조하고 있습니다. Jenkins의 원래 이름이 Hudson 이었습니다.
Test Drive
test drive를 위해 Java Web Start를 통해서 Jenkins를 시작합니다. jenkins가 시작되면 dashboard를 얻기 위해 http://localhost:8080/로 갑니다. 이 Jenkins에 여러분이 세팅한 configuration은 ~/.jenkins에 저장됩니다. Jenkins가 restart 하게 되면 이 저장된 configuration을 참조해서 계속 적용되게 됩니다.
Installation
Jenkins를 실행하려면 JRE 1.5 버전 이상이 깔려 있어야 합니다. 그 다음 jenkins.war를 다운 받은 후 java -jar jenkins.war 라는 명령어를 통해서 이것을 실행 시킬 수 있습니다. 이것은 기본적으로 test drive와 같은 set up 인데요 다만 oupput 이 윈도우가 아니라 콘솔로 가는 것이 다릅니다.
그리고 여러분이 Glassfish, Tomcat 5, JBoss, Jetty 6 같은 Servlet 2.4/JSP 2.0 이후 버전을 지원하는 서블릿 콘테이너를 가지고 있다면 jenkins.war를 다른 WAR 파일처럼 deploy 할 수 있습니다. container-specific installation instruction 에 대해 좀 더 자세히 할고 싶으시면 이 문서를 보세요.
일단 war 파일이 explod 되면 jenkins/WEB-INF directory 안에서 chmod 755 jenkins를 해 주세요. 이렇게 해야 이 shell script를 실행할 수 있습니다.
만약 Window에서 실행한다면 Jenkins를 service로서 실행해야 할 겁니다. 그래야 자동적으로 start up 시킬 수 있을테니까요. 이렇게 하기 위한 가장 쉬운 방법은 Jenkins를 native Windows installer를 다운받아 인스톨 하면 됩니다. 이 파일은 Jenkins main page에서 다운 받으실 수 있습니다. .zip 파일을 다운 받으신 후 압축을 풀고 인스톨 파일을 클릭하시기만 하면 설치 마법사를 통해 설치하실 수 있습니다. 이 설치 마법사가 Jenkins를 인스톨 하고 Jenkins Windows service도 셋업해 줄 겁니다.
Jenkins를 서비스로 등록할 수 있는 다른 방법은 톰캣을 서비스로서 인스톨하고 Jenkins를 이곳에 deploy 하는 방법도 있습니다. 그리고 Java Service Wrapper를 사용할 수도 있구요. 그런데 service wrapper를 사용하면 약간의 문제가 있을 수도 있습니다. 왜냐하면 디폴트 namespace에 있는 Jenkins의 Main 클래스가 이 service wrapper main class와 충돌할 수 있기 때문이죠. service container (Tomcat, Jetty, etc.) 안에 deploy 하는 것이 아마 좀 더 직관적일 겁니다. 이와 관련해 별로 경험이 없는 개발자들도 쉽게 하실 수 있습니다.
다양한 환경에서 다른 사람들은 Jenkins/Hudson을 어떻게 deploy 했는지 보시려면 아래 링크들을 참조하세요.
License
The license for the core might be found athttps://github.com/jenkinsci/jenkins/blob/master/LICENSE.txt
제목에 심심해서 <noscript>를 써봤는데
싸이트에 모든 글들이 날라가네요, 메뉴도 날라가고…
처음 알았습니다. ㅋㅋ 꺄 ㅋㅋ 재밌네요.
문제는 타이틀 밑으로 스크립트들을 읽지 않게 되서 그런건가요?ㅎ
한번 알아봐야겠습니다.
자바스크립트를 지원하지 않는 브라우저 혹은
자바스크립트 기능을 꺼둔 브라우저에서 실행되는 태그 입니다.
<noscript>
자바스크립트를 지원하지 않는 브라우저입니다.
</noscript>
CentOS로 웹 서버 구축하는 방법을 정리해 놓겠습니다.
먼저 해야할일
1. 자바 설치
2. apache 설치
3. tomcat 설치
4. apache & tomcat 연동
5. mysql 설치
6.ssh 설치
7. ftp 설치
8. 방화벽 설정
일단 이정도 까지만