blog만들기 진행상황

git도 도움이 될 것이라는 판단하에, 새로 만들어 관리를 시작해 봤습니다.

이제 나름대로 익숙해 지고 나니, 관리의 편의를 느끼기 시작합니다.

방문자 카운터와 코드 게시글 작업이 완료되어 테스트에 돌입중 입니다.
다음, 메인화면의 추천이나 신규 글 추천메뉴를 건들여 볼 예정입니다..

ubuntu / web / image now showing some case

스테틱 자료를 웹에서 불러올때 두가지 문제가 있었는데,
1. 간혈적으로 이미지가 불러와 지지 않는케이스
2. 특정 이미지가 완전히 먹통인 케이스(로딩이 안되는)

1번의 경우는 간혈적으로 발생해서, 원인 파악중..nginx의 타임아웃시간이 짧은가 해서 검색 해 보았지만, default는 1분이나 되기때문에 아닌것 같습니다..

다시한번 오류가 나타난다면 분석 해 봐야겠습니다..

2번의 경우에는, 테스트용 pc에서는 windows 환경이었지만 ubuntu로 넘어오며 발생됬던 매우 기초적인 문제였습니다.

windows에서는 파일 확장자를 지정할때 대소문자 구분이 비교적 자유로운것 같으나,
우분투에서는 엄격한 편이었다는걸 지난주에 배워놓고 간과하고있었습니다.

파일 이름이
Img.PNG 였는데, 코드에서는 img.png 라고 작성했었습니다.
windows에서는 전혀 문제가 없었으나,ubuntu는 다른것 으로 인식했습니다.

해결법은 실제 디렉토리의 파일과 코드의 파일 이름을 일치시키면 됩니다.

blog만들기 - 3월 19일

지난번 업데이트 이후 손을 대지 않았다가, aws사용법도 익힐겸, 외부에서도 작업이 되게 할겸
작업중이던 blog를 aws에 띄웠습니다.
git과 aws를 할줄 알면 취업에 조금이나마 도움이 된다는 언급이 있길래 시도 해 봤습니다..

lightsail / ubuntu / postgres / remote-connection issue

AWS의 lightsail 에서 ubuntu 환경에 postgres를 테스트서버에서 쓰엔 db정보를 마이그레이션 하기 위한 작업을 계획했습니다.

ubuntu에 pstgres를 설치하는것은 다른것과 전혀 다를바 없이 package 메니져를 통해서 설치하면 되었고, 테스트서버의 pgAdmin을 통해, 만들어둔 시퀸스와 db를 create하는 명령어를 긁어와 만드는데 까지는 무난하게 진행되었으나, 데이터 안의 내용을 계속 추가해야하는 상황에서, 어떻게 하면 편하게 작업을 할까? 라는 고민을 하게 되었습니다.

이미 있는 정보를 마이그레이션 할 때 까지만, 위험하지만 원격접속을 이용해 pgAdmin으로 AWS 의 postgres를 건들이기로 결정했습니다만, 여기서 문제가 발생했습니다.

---

우선 원격제어를 하기위해서는, pg의 설정을 localhost만 허용에서 외부 주소 허용단계까지 수정해야하며, 이 작업이 끝나면, 172.0.0.1 에서만 접속이 허용되던것이, 풀립니다.
/etc/postgresql/버전/main/postgresql.conf 과 pg_hba.conf 를 수정하면 됩니다.


다음으로는 네트워크 인/아웃바운드 규칙에 pg의 포트를 허용시켜야 합니다.
간단하게 ufw에서 규칙을 추가하면 된다고 생각했는데, 오랜 삽질끝에, ufw로는 상세한 규칙을 정의하는데에 제한이 있다고 한답니다.

ufw보다 더 자세한 설정은 iptables 로 하며, 기본적으로 설치가 되어있는 package같으나, 어떤 이유에서인지 저는 제설치를 했습니다..

이후 shell에서 
iptables -I INPUT 1 -p tcp --dport 포트번호 -j ACCEPT
iptables -I OUTPUT 1 -p tcp --dport 포트번호 -j ACCEPT
를 입력하여 인/아웃바운드 규칙을 허용시켜줍니다.

이 작업은 외부에서 aws서버의 pgsql 에 접속을 하기위해 필요한 작업입니다.

이후 반드시 postgres 서비스를 제실행 해야합니다.

---

여기까지가 검색하면 나오는 일반적인 적용방법입니다만. 어째선지 저의 경우에는 외부에서 접속을 인식하지 못하는 문제가 계속 발생했습니다.

솔직히 아직도 이게 진짜 이유인지 확신을 못하고 있지만, 제 해결방법은 이러했습니다.

Aws의 lightsail 관리메뉴를 들어가면

 방화벽 설정을 하는 메뉴가 있습니다..
바로 이전 글에서는, 이 기능이 ufw를 실행하면, 작동하지 않는다고 했었기 때문에, 'ufw의 우선순위가 더 높다'  라고 판단하고 있었습니다.

하지만 도저히 외부접속이 안되서, 위 이미지처럼 postgressql 을 예외목록에 추가를 해주니 곧바로 접속이 되었습니다.(????내 3시간?)
그런고로 ufw와 aws의 firewall정책은 두개다 지켜야 하는것으로 보입니다.

반드시
ubuntu의 firewall과
aws의 firewall
두가지를 모두 허용해야 합니다..

some tips for using ubuntu on Amazon lighthouse, open web server with node.js.

계속 햇깔려서 메모겸 작성합니다.

Amazon lightsail 을 통해 생성한 Ubuntu운영체제에서
nodejs를 외부에서 정상적으로 접속 가능한 서버로 띄우는중 해맸던 자료입니다.

우선 lightsail은 ufw와 독립적으로 포트포워딩을 제공하고 있기 때문에,
ufw를 활성화시 lightsail 각각 설정이 필요합니다.
(ec2또한 마찬가지라는코멘트를 봤습니다)

ufw만 활성화 후, ssh접속을 요청했는데 문제가 생기는 일이 발생..
(Amazon web ssh 는 22포트이니깐, ufw활성화전 22를 allow해줘야 제접속시 접속가능!! 안그럼 서버 짜이요!)

반대로 규칙을 추가할때도 ufw/aws dashboard 각각 허용을 해 주어야 합니다.

이후 node / nginx 설치,
node는 내부 포트로 swf 허용후 서버 개방,
nginx는 기본 80포트로 외부에서 접속을 관리하는데, 들어온 요청을 방금 연 node와 연결을 설정해야합니다.

에디터로 /etc/nginx/sites-avaliable/default 를 열어
중간의

location/{} 을 찾아가, 안에 값을 하나 써준다
proxy_pass http://localhost:내부포트/ ;
를 써줍니다.

내부포트는 node로 열때 포트번호를 말합니다.

뿅 완성입니다.


some tips for using ubuntu on Amazon lighthouse, open web server with node.js.


install ubuntu on lighthouse is no need to write, cause its super easy right?


first of all, lightsail's firewall(in aws dashboard) and ufw are operation diffirently,


if you enable ufw in ubuntu without allow port for ssh, you will never reach to ssh again.

(case of lighthouse, guess like you never reach to server again, unless you format)

therefore, you have to open port for ssh before enable ufw!


also, if you want to enable other port, you have to enable aws dashboard and ufw too.

otherwise, it might be work local network, but you cannot reach from other network.



node server will operate local. you need to mount WAS before, unless you dont want to connect other network.

nginx or tomcot will help this, i'll try nginx.
install nginx and nodejs.


after installing nginx, you can access from other network with http://yourlightsailIP/ .

now, you need to hook-up your own nodeserver.


open /etc/nginx/site-available/default with editor.

you will see 'proxy_pass'parameter inside of 'location/{}'

either or not, write down lines like this ' proxy_pass http://localhost:[your node server port]/; '

(in my case : proxy_pass http://localhost:8080/; )


after than, turn on node server, and try to connect from other network.

voilà! you'll see your website now.

웹/안드로이드에서 위치추적을 사용하기 위해 정리했던 글..

GPS system 도입을 위해 분석했던 자료이며, 정확한 내용이라고 하기에는 많이 부족합니다. 처음 앱/웹에서 gps를 도입하기 위해 간단하게 읽어나가, 검색을 어디부터 시작해야할지 정도의 도움이 되기를 바라며 남기는 글 입니다..

Web/App 위치기반 시스템을 사용하기 위해 우선적으로 현제 GPS시스템을 어떻게 쓸지 분석하기위해 17년 12월부터 한달간 기록된 자료들을 정리하여 제 작성한 글 입니다.

앱 파트에서 GPS 위치정보 기반 시스템은 이미 많은 수준의 기술적 상향들이 있었기 때문에, 그저 끌어 쓸 줄만 알면 됩니다.

하지만 플렛폼과 버전별로 각기 다른 필요 방식이 있기 때문에, 짚고 넘어야 할 사항이 많이 있었습니다.

아이폰의 경우엔 ObjectC 와 Swift로 나뉘어져 있으며, 특히 Swift의 케이스엔 버전별로 코드가 매우 다르다는 이야기를 접했기 때문에, 기존에 내렸던 결론인 아이폰은 적용이 비교적 쉽다는 말은 실제로 알아보기 전 까지는 장담 할 수 없게되었습니다(…)

안드로이드

안드로이드의 경우에도 역시 버전별로 많은 위치기반 수집 방식이 있지만, 크게 2013년 전 후로 기능이 나뉘어져 있습니다.

이전 년도의 기능은, 순수하게 안드로이드 기기를 이용하여, 개발자가 스스로 구현해야 할 파트가 많으며, 덕분에 퍼포먼스 하락 같은 요인이 발생 할 수 있습니다. 하지만 굳이 무거운 라이브러리를 쓰기 싫다면, 이는 좋은 방법 중 하나라고 판단됩니다. (스스로 짜는만큼 확실히 알 수 는 없을태니깐요.)

하지만 이러한 불편함 덕분에, 구글에서 자체적으로 쉽게 사용할 수 있게 되었습니다.

그리고 이를 fusedLocationProvider 를 만들어 API레벨 23 이상의 안드로이드 OS에서 이용이 가능케 되었습니다.

하지만 그 당시 23래벨은 상당히 높았으며, 지금까지도 안드로이드OS 점유율의 대부분은 19버전임을 감안하면, 개발자 입장에서는 고려의 가치가 상당히 낮아집니다.

이러한 이유로 구글은 추가적인 업데이트 배포와 함께, API 10부터 가능하게끔 바꾸었습니다.

 이전버전의 호환을 처리하는 방식은, 제조사에게 펌웨어 업데이트를 요구하는 것이 아닌, Playstore업데이트로 가능하게 만들었습니다.

Api10 유저도 playstore 업데이트만 한다면(앱을 정상적인 루트로 받는행위를 한다면..) 사용할 수 있게 됩니다.

Playstore 의 업데이트로 많은 라이브러리들이 작동이 가능케 되었다고 하니, 이 방면으로 조금 알고있으면 원하는 기능 검색에 조금 더 도움이 될 것 같습니다.

최신버전의 fusedLocation은 권한이 필요로 합니다.

1.    1 .  ACCESS_FINE_LOCATION과

2.    2.   ACCESS_COARSE_LOCATION 인데,

1번의 경우는 통신사/GPS/WIFI를 이용하여 위치정보를 수집할 수 있는 권한이며,

2번의 경우는 WIFI만을 이용한 권한입니다.

fusedLocation의 위치정보 수집방식은 위의 열거된 방식을 통해 빠르고/낮은 오차로 위치를 제공하게 됩니다.

(API 23이상의 버전에서는, Manifest에서권한을 grant하여도 추가적으로, 앱에서 기능을 실행할 때마다 권한을 재승인 해야 합니다. 이를 위해 API버전이 23이상인 경우 추가 permission grant코드가 필요로 합니다. 공식 fusedLocation문서에 존재합니다.)

Manifest단에서 권한을 주었다면, LocationCallback과 LocationRequest를 생성/선언합니다

LocationRequest를 생성하며, 옵션들도 설정이 되며,

FusedLocationClient에서 requestLocationUpdate를 호출합니다.

콜백으로 location업데이트의 성공 실패여부를 리턴하게되고,

이후 필요에 따라 FusedLocationClient의 GetLastLocation메서드롱 좌표를 리턴합니다.

requestLocationUpdate와 getLastLocation의 기능은 비슷해 보였고,

이전버전에서는 getLastLocation만 있었기 때문에, 이부분에서 혼돈이 있었는데,

getLastLocation은 마지막으로 기록된 정보만을 반환하는 반면,

requestLocationUpdate는 fusedLocationClient에서 위치정보를 업데이트 하라고 시키는 역할 입니다.

즉, reuqestLocationUpdate를 호출하지 않으면, getLastLocation을 몇 번이고 호출해도 값은 바꾸여지지 않습니다.

이전버전까지는 requestLocationUpdate를 실행하면 즉각적으로 안드로이드에게 현제 위치를 업데이트 요청을 시켰으나, 이는 개발자의 관리 부주의로 불필요하게 많이 호출하여, 배터리 소모를 유발하는 문제가 있었습니다. 

이를 방지하고자 새로운 fusedLocationClient는 업데이트 주기를 설정하여, 주기가 돼야만 실제로 requestLocationUpdate를 실행하며, 주기가 되지 않았을 때 위치업데이트를 요청하면, 그냥 getLastLocation을 호출하여, 개발자의 실수로 battery drain현상을 방지하게 되었습니다.

해당 설정 값들은 LocationRequest를 생성할 때 사용되는,

setInterval과 setFastestInterval, setPriory로 설정됩니다. 

(이 값은 앱 실행 도중 변경이 가능합니다.)

이 값들을 이용해서 Interval시간을 주기로 업데이트를 자동적으로 하게 되는데,

수동적으로 현제위치를 업데이트 시킬 필요가 있을 때,

(역시 상기와 같은 이유로 battery 낭비를 위해 안전장치로) 

fastestInterval의 값을 설정하게 되는데, 이 fastestInterval에 명시된 시간이 지난 뒤, 수동으로 gps업데이트 요청을 할 때에는, 그 요청을 응해준다는 의미입니다.

이 값으로 자동 업데이트 간격을 정의해 놓고, 수동 요청 시 과도한 요청을 막으면서 유연하게 대처 할 수 있습니다.

Priority는 GPS위치 추적 기능을 얼마만큼 정밀하게 사용하는가에 대한 세팅입니다.

값은 no  / Balance / high 가 있으며,

No의 경우에는 직접적으로 위치정보를 업데이트 하지 않고, 타 앱이나 서비스에서 가지고 있던, 최종 값을 가져온다는 의미입니다. 앱을 구동하다 보면, 여러 앱 혹은 서비스에서 GPS정보를 얻어오게 되는데, 굳이 이미 가져온 정보가 있음에도 불구하고, 다시한번 fusedLocation을 쓰지 않게 하기 위한 기능입니다.  

당연하게도 정확도는 위치정보를 얻어오는 앱/서비스에 따라 다를것 이며, 배터리 소모량도 없습니다.

Balance 의 경우에는 GPS를 사용하지 않으며, 오차는 20~미터 정도입니다. 결과를 리턴하는대에까지 시간이 30초 정도까지도 소요되었으며, 단일 앱 구동시 테스트 장비에서는 배터리가 9시간을 버텼습니다.

Power의 경우에는 15미터~ 정도까지도 나왔습니다. 요청의 리턴은 거의 항상 20초 내에 작동했습니다. 구동시 테스트장비는 balance의 배터리 소모량의 반도 못 미쳤습니다.

장비의 성능과 배터리에 따라 다르기 때문에, 이 수치는 절대적이지 않으며, 다른 블로그나 android에서 소개하는 페이지에 정확한 수치가 공개 되어있습니다.

여기서 Priority를 설정한다 한들, gps혹은 3/4G, wifi를 끄게 되면 기능을 이용하지 않습니다.

필드테스트를 거치지 않았으나, 실험실 주변에서의 위치측위 결과, balance는 준수한 성능과 지리를 불러왔기 때문에, 정밀한 수준의 위치 추적이 필요치 않는 상황에서는 balance 로 세팅이 옳은 것으로 보입니다.

테스트 당시에 앱은 소멸을 지시한 코드가 없었으며, 백그라운드로 자동적으로 넘어가 작업을 수행함을 확인했기 때문에, 불필요시 메모리 할당 해제를 반드시 해야 할 것 같습니다.

웹

웹의 경우는 앱과는 달리 위치측위 방식은 인터넷 밖에 없습니다.

js단에서 이미 깔끔하기 그지없는 라이브러리까지 다 준비 되어있어, 적용에 무리가 전혀 없었습니다.

오차는 이동중에는 역시 오차가 넓으나(km수준까지도), 동일한 위치에서 동일한 이더넷일 경우에는 정밀하게 측위 되었습니다.

다만, http환경에서는 위치추적기술을 사용하지 못하게 되어있습니다.

Localhost일 경우에는 개발용으로 문제가 없으나, 정식 서비스를 위해서는 서버를 https로 만들어야만 합니다.

또, 웹 특성상 미지원 브라우저가 존재합니다.(그리고 이게 아마 모든 브라우저가 하나의 표준을 따르기 전까진 제가 죽을때까지 웹을 공부하면서 느낄 고통이겠지요)

blog만들기 - 3월 12일

계획은 2월 중 이었고, 기본 틀 및 db생성 2월 말에 되었지만, 본격적인 작업은 개강한 뒤 부터 시작..

사용환경 :
Node.Js / Express
PostgresSQL

진행도
blog 게시판 생성 -100%
code 게시판 생성 - 20%
에디터 추가 - 0%
독립적인 이미지 서버 -0%
회원관리 -post 1.0
뉴스피드? - post 1.0
모바일 적용 - 10%
css적용 - 5%
blogger 내용 marge - post 1.0

문제점
블로그 글의 \n 이나 <br />태그의 경우 server ->js 로 옮기면서 문제가 발생중.
\n 과 <br /> 대신 <br/> 으로 바꾸면 정상 작동..
regex 공부 절실..
에디터 추가시blog 게시판에서 많은 애로사항이 발생 할 것으로 예상중..

postgres prev/next 컬럼 select 하기

게시판 공부중에, 이전/다음 게시글을 불러오는 방법에 대해 생각해 보았는데,
지금 수준으로는 db에서 무식하게 불러오는 수준밖에 떠오르지 않았기 때문에, 좀 더 원할한 솔루션이 있을거라 막연하게 판단하여 검색을 했었고, 좋은 예시를 하나 찾아서 기록을 위해 남겨둡니다.






우선 datebase는
create table blog(
 num int primary key,
 title text
)
insert into blog values(1,'hello world1');
insert into blog values(3,'hello world2');
insert into blog values(4,'hello world3');
insert into blog values(6,'hello world4');


이며 게시글 3번을 눌렀을때, 이전글인 1번과 4번을 출력하고 싶습니다.



sql문에서 select문을 두번 사용하는데, 처음은 각 row의 이전/다음 num값을 출력합니다.
select
  num,
  lag(num) over (order by num desc rows between current row and unbounded following) as prev,
  lead(num) over(order by num desc rows between current row and unbounded following) as nextt
from blog;

Postgres Function 에 따르면,
lag 는 offset 된 값중에서, 현제 선택된 행의 값의 이전 row를 불러오며
lead 는 반대로 이후 값의 row를 불러온다 정도로 해석됩니다.
over는 window function을 사용할 때에 반드시 따라오게 되는 문법적 용어이며,
그 뜻은, 정렬의 방법을 정의한다.
해당 컬럼의 정렬방식은 num의 desc(오름차순) 정렬이며,
between은 풀어쓰자면 where a > 1 or a < 3 처럼 1과 3사이 로 쓸 수 있다고 한다.
between 조건1 and 조건2 를 작성하여 조건1과 조건2 사이의 값을 저의 할 수 있다고 한다.
current row 는 영어 그대로 이해했고,
and절 뒤의 unbounded following 은 모든 파티션을 위해서 쓴다고 합니다.
보통은 order by 절을 사용하면 모든 파티션을 검색하는것 이지만, 이번 케이스는 order by 문이 쓰였기 때문에, 모두 라는것을 저의하기 위해 쓰였다 합니다.

이제 prev 와 next컬럼을 얻었으니, 3번 게시물의 prev 와 next가 무엇인지 알기 위해 sql을 한번 더 날립니다.
select * fron blog where 3 in (prev, nextt);
where 절의 in은 = 과 동일한 역활을 합니다.
prev = 3 or nextt = 3 이라고도 굳이 풀어 쓸 수 있습니다.

이제 이것들을 하나의 sql문으로 작성하면 아래와 같이 됩니다.
select *
from (
 select
  num,
  lag(num) over(order by num desc rows between current row and unbounded following) as prev,
  lead(num) over(order by num desc rows between current row and unbounded following) as nextt
 from blog
) as x
where 3 in (prev,next);


실제 구동 예시