mobile native app 을 제작한다면...
2017-12-07 │ http://onionmixer.net/print_news_once_9th.php?news_id=372
1. mobile 프로그래밍은 web 보다 어렵다. 단순이 java 와 php 의 level 이 아니다. 문제는 reverse enginnering 이다. 소스코드의 로직이 다 드러날 수 있다는게 문제
2. 그런면에서 mobile-web 은 고민을 덜하게 된다. 바깥의 틀만 native 고 기본적으로는 web 이니까. 하지만 user expirence 가 틀리지. 그러니 native app 을 고집하게 되는데.......
3. 자.. 각설하고 이 native app 을 만든다면 여러가지 고민을 해야한다. 특히 데이터베이스 코드가 잘못 사용되면 web 의 sql injection 보다 훠얼씬 위험한 상황이 될 수 있다. 우리팀처럼 많은 삽이 아니라고 하더라도 서버와 json 으로 통신하는 과정은 필요하다. 그리고 login session 관리도 필요하다. session 의 요청을 통해 불필요한 사용자 정보가 흘러나가는 경우도 막아야 한다. 이외에도 신경쓸게 매우 많다
4. 그럼 이정도냐? 아니다. 사실 해킹등을 대비하려면 좀 더 신경써야 하는게 많다. 대부분 귀찮아서 그냥 넘어가지만... 사실은 넘어가서는 안되는것중에 하나가 clock skew. mobile 과 서버의 시간이 틀어지는 부분도 원래는 대비해야 맞다

UI/UX 를 빼고도 사실은 고민해야할 부분이 많은데... 제대로 신경쓰는곳은 몇곳이나 되려나 싶다. 사실 나라면 크래킹을 할때 mobile app 이 제공된다면 그것부터 뚫겠다. 적어도 mobile app 은 소스를 다 볼 수 있기때문에 상대적으로 web 보다 수월하다는 개인적인 생각.
이름 :    패스워드 :
Legacy Development Environment 에 대한 생각
2017-11-29 │ http://onionmixer.net/print_news_once_9th.php?news_id=371
요즘와서 드는 생각인데.. C 를 위시한 legacy 개발환경이 은근 외면받고 있는듯한 느낌이다(아니 현실이 이미 그렇지만)
 
내가 소속된 개발팀은 그럼에도 불구하고 꽤나 고전적인 방법들을 선호하는(이라고 쓰고 강요당하는) 편인데, 사실 이건 기본 또는 기초에 대한 문제기도 하다.
 
1. 대다수의 php 를 필두로한 스크립트 개발자들은 socket 프로그래밍에 대해 이해하지 못한다. 때문에 조금만 고민해도 훨씬 효율적인 시스템을 구성할 수 있음에도 불구하고 그걸 자기가 알고있는 일반적인 지식에서만 구현하려하는 습성을 가져가기 때문에 결과적으로는... 직관적이지 못한 시스템으로 갈 가능성이 많은편이다
 
2. 아는가? 우리들이 쓰는 그 스크립트 언어들의 인터프리터등은 지금도 C 또는 C++ 등으로 개발되고 있다는걸? 아 물론 자바스크립트로 웹브라우저에서 동작하는 에뮬레이터를 만드시는 분들도 있다는것 인정. 하지만 그분들은 이미 legacy development 를 꿰고 있는 사람들이라는것도 염두에 두어야 하지 않을까?
 
3. 요 근래 mysql 에 대해서 외부 및 내부에서 미묘한 사례가 나왔다. database 및 구조와 효율에 대해서 전~혀 고민하지 않고 기준없이 설계하는 경우. 물론 요즘와서야 DB 를 oracle 등으로 접하기 "시작한" 사례가 그리 많지 않으리라는 현실은 이해가 간다만... 적어도 개발자라면 그런 사례를 일일히 설명해 주기 전에 고민에 대한 컨셉으로 나머지를 예상해 낼 수 있어야 한다. 개인적으로는 이게 legacy development 가 주는 이점이라고 생각.
 
4. 물론 web 서비스 외에 뭐가 더 필요하냐고 할 수 있다. 그리고 대부분의 경우는 그게 맞을 수도 있다. 물론 facebook 도 php 를 쓰고, 나 역시 web project 의 경우는 php 를 최우선 순위로 삼는 편이다. 하지만 그 facebook 조차도 php "만으로" 모든 시스템이 이루어져 있지는 않다. 하다못해 IDC 며 서버 하드웨어를 설계하는 기술이 php 만으로 다 된다고 착각하는 사람은 없곘지. 물론 이건 C 언어를 안다는 수준을 한참전에 벗어난 경우겠지만, 적어도 우리가 사용하는 OS 의 근간은 컴파일러 언어라는 사실은 잊지 말아야 겠다.
 
5. 이런저런 잡설을 집어 치우고라도 간단한 예를 들어보자. 적어도 C 또는 컴파일러 언어에서 thread 프로그래밍을 "직접" 해본 사람은 효율에 대한 이해의 레벨이 다르다. 또한 C 에서 포인터를 직접 짜본 사람 역시 메모리 소모에 대한 고민의 정도가 다르다. 절대적 이라는건 아니지만 상당히 높은 확률로.
 
6. 사실 개인적으로는 개발자들이 이러한 old legacy development 에 관심을 가지지 않는게 이익이다. 왜냐하면 그럼으로서 나, 또는 내가 속한 개발팀의 가치는 올라갈 테니까. 그럼에도 불구하고 발끝을 아직 담그고 있는 사람으로서는 안타깝기도 하다.
 
7. 이 내용은 지극히 어그로로 발전할 수 있는 가능성을 지니고 있다. 하지만 오해는 하지 많아주셨으면! 지금의 기술이 나쁘거나 저렴하다는 의미가 아니다. 속칭 "원천기술" 을 가지고 지금의 것을 구현하는 것과, 신기술을 follow 하기에 바쁜건 분명 틀리다. 그 점은 엔지니어고 불리고 싶다면 한번정도는 고민해 봐야할 부분이 아닐까 싶다. - 라는 그냥 개인적인 생각
이름 :    패스워드 :
gnome 에서 KDE 로의 이주를 완료.
2017-11-24 │ http://onionmixer.net/print_news_once_9th.php?news_id=370
대략 3일전부터 급하게 KDE 로 선회하고 나서의 간단한 소회를 적어보자면...
 
1. 아마도 gnome 은 Wayland 를 위해 뭔가를 내부에서 바꿔버린게 아닌가 싶다. KDE 도 엔진을 opengl2.0 과 opengl 3.1(?) 그리고 xcomposite 를 쓸 수 있는데 이게 뭔 차이라고 2.0 이 가장 쾌적하다. 일단 KDE 로 이전한 이후에 gnome 에서 느껴지던 버벅임은 없다고 봐도 무방할듯.
2. 서버 접속을 시도할때 ssh 의 key login 방식인 경우라면 kwallet 이 뭔가 나를 좀 귀찮게 한다. 그냥 ssh-agent 를 띄우는 결로.. 조금 귀찮지만 해결..(재시작 할일이 없어야 할탄데)
3. 여튼 모든 화면 효과가 좋아졌기 때문에 griffin powermate 의 설정은 xkeybind 로 rollback. 참 좋다
4. kate 는 나름 쓸만한 느낌.
5. dolphin 은 아직 좀 미묘... 바탕화면의 icon 을 다루는 데에 있어 파일을 move 했는데 사라지지 않는다. 그래서 delete 를 하려고 하면 없는 파일이라고 나옴. 문제없이 쓰기 위해서는 파일을 복사후 지우면 확실하게 사라진다. 물론 Xsession 자체를 relogin 한다면 알아서 사라지는듯.
6. dolphin 바탕화면에서 특정 파일/폴더의 icon 을 재지정하는 기능은 여전히 쓸만하다
7. konsole 자체는 설정을 좀 손보니 쓰는데 별 이상은 없지만(특히 복사 key 는 xterm 을 위해서라도 재지정하는게..) dolphin 에서 konsole 로 파일 또는 폴더를 drag 할때 action 을 선택하게 하는건 역시.. 조금은 불필요하지 않나 싶다. konsole 에서 현재 위치해 있는 location 으로 실제 파일 복사등의 이벤트를 진행할 수 있는데.... 좋게보면 통합이고.. 굳이 나쁘게 보자면 터미널 이상의 무언가를 쑤셔넣는 느낌. 참고로 xterm 으로는 drag 조차 되지 않는다!!! (이건 좀..-.-)
8. 아직도 KDE 어플을 ctrl+q 로 종료하는건 조금 어색하다. ctrl+w 가 좀 더 편하기는 하지만.. 뭐 이건 철학의 차이니....
9. windows 를 좌측세로로 붙인다던가.. 상단으로 붙인다던가의 action 은 발군이라 생각한다. 다만.... 이게 좀 한글 번역이 미묘한듯 한데.... "창을 오른쪽위로 보내기" 라는 단축키가 kwin 에서 항목이 2개인데 실제로 action 은 틀리다. 아마도 번역이 update 가덜된쪽이 아닐까.. 생각해 보는데... 둘중에 하나는 오른쪽 반쪽 영역으로 상하 fit 하게 채우는것, 다른 하나는 화면을 4분면으로 나눠서 오른쪽 상단에 위치 시키는것. 이게 되어서 꽤 편하다. Windows 10 에서도 유용하게 사용했기 때문.
10. 이미지를 보고 있는데 del 키 하나로 삭제할 수 있다는 점에서 gwenview 보다는 eog 에 한표.
 
결과적으로는 gnome 에서 KDE 이로의 이주에 만족하는 편인데, 일단 속도때문이다. 사실 glxgears 의 수치는 같지만.. 전반적으로 시스템의 동작 자체가 매우 빨라졌다. 사람들이 nvidia 독점 driver 를 좀 폄하하는 편인데.... 그건 linux 에서 문명6등의 게임을 안해봐서 하는얘기. nouveau 에서는 좀 3D 를 과도하게 사용하는 게임에서는 아무것도 못하고 뻗는 수준이라 보면 되는데, 적어도 nvidia driver 에서는 그런일은 없다. 고로 NVIDIA DRIVER 에서 보다 상쾌한 경험을 할 수 있게 해주는 KDE-plasma 에 한표.
 
ps. 사실 이 모든 삽질은 telegram 과 virtualbox 덕에 시작됐다고 해도 과언이 아니다. 새삼 킬러앱의 소중함을 느낀달까....-.-;
ps2. 웬지는 모르겠지만 nvidia driver with gnome 에서 느려지는 현상은 ubuntu 만이 아니라 opensuse 에서도 동일하다. nvidia 를 떠나기 전에는 이 환경을 유지하지 않을까 싶다.
이름 :    패스워드 :
[1][2][3][4][5][6][7][8][9][10][Next]

ONIONMiXER.net
ONIONMiXER.net RSS feed 맨위로 이동