라벨이 software_engineering인 게시물 표시

2021년 목표설정

이미지
기본적으로 작년에 달성하지 못한 것들을 하려고 생각중인데..코로나가 언제까지 이어질지, 한국이나 북해도는 갈 수 있을지..자격증은 응시 가능할지..여러가지가 불확실하다. 2021년은 무엇보다 정신적인 부분과 경제적인 부분에 중점을 두고 조금 더 치열하게 지내보고 싶다. 일본나이로도 30대 마지막 해, 이제 불혹에 접어드는 나이..복잡하지만 심플하게. 육체적목표 : 트라이에슬론 스탠다드 도전하기 정신적 : 자격증2개 도전 + 자체개발 서비스 론칭 가족적 : 가정의 평화를 유지하기 경제적 : 외식과 유흥비를 줄이고 부수입을 늘려서 결과적으로 저축하기 사회적 : 목표세미나를 포함해서 민단과 개인인맥의 활성화와 교류를 촉진하기

== 무료 제작툴 39개 모음 ==

기획 http://trello.com/ https://www.notion.so/ . 디자인 https://www.figma.com/ . 사진 https://unsplash.com . 코드 에디터 https://code.visualstudio.com/ . CSS 라이브러리 https://tailwindcss.com https://bulma.io . 깃 저장소 https://github.com/ https://about.gitlab.com/ https://bitbucket.org/product . 클라이언트 https://insomnia.rest  (REST) https://altair.sirmuel.design (GraphQL) . 검색엔진 https://www.algolia.com . 유저 비밀번호 관리 https://auth0.com/ https://aws.amazon.com/ko/cognito/ . 이메일 https://www.mailgun.com/ https://mailchimp.com . SSL Certificate https://letsencrypt.org/ . 백엔드 https://www.heroku.com/ https://aws.amazon.com/ . 프론트엔드 https://pages.github.com/ https://www.netlify.com/ . 서버리스 https://aws.amazon.com/lambda/ https://cloud.google.com/functions/ . 데이터베이스, https://aws.amazon.com/dynamodb/ https://cloud.google.com/firestore/ https://www.mongodb.com/cloud/atlas https://fauna.com/ . 파일 업로드 https://cloud.google.com/storage/ https://cloudinary.com/...

[메모] Git 초기화 순서 정리

맨날 까먹어 ㅠㅠ 1. 프로젝트용 폴더를 만들고 초기화 한다. 어떤 라이브러리 쓰느냐에 따라서 다르겠지만 ㅋ EXPO를 예를 들면 (Node.js 인스톨 했다고 가정)  > npm install expo-cli --global  > expo init [project name]  > cd [project name] 2. github에 가서 새로운 레포지토리를 만든다, 이름은 프로젝트명, 공개, 초기화문서 작성옵션 체크 3. 새로 만든 레포지토리의 URL을 복사해둔다 4. 커멘트창으로 돌아와 다음 순서로 입력  > git remote add origin [Github Repository URL]  > git pull origin master  > git add .  > git commit -m "Initial commit"  > git push origin master 에러 안 나면 성공, 에러가 나면 이전에 만든 정보랑 엉키거나 하는 경우니까 강제로 초기화 하는 커멘드 찾아서 넣기

「TIP」인스톨이나 다운로드 없이 개발환경을 제공하는 서비스 정리 by 노마드코더

Code sandbox( https://codesandbox.io/ ) 자바스크립트에 특화된 온라인용 개발 툴. VSC의 웹브라우저 버전같음. repl.it( https://repl.it/ ) 다양한 언어를 프로토타이핑 할 수 있음. git 하고 연동하면 ㅎㄷㄷ 할 듯?? snack.expo( https://snack.expo.io/ ) 모바일 애플리케이션을 프로토타이핑 할 수 있음. react & react.native 조합임. 참..세상 좋구나 ㅋㅋ 편하구나 ㅋㅋ 하지만 코딩을 열심히 안 하면 의미가 없지..ㅇㅇ [동영상] 아이패드로 코딩할 수 있나요? 꿀팁 대방출!

[메모] git 하고 github 설치

버전관리 및 소스코드 관리 학습을 위해서 설치를 해 봤다. 하도 귀아프게 들어서 언젠가는..이라고 생각만 했지 실제 개발쪽 일을 많이 안 했고 사용해도 SVN만 적당히 사용해 와서 필요성도 못느꼈다. 그래도 이왕 맘먹고 공부를 하는김에 개인적인 개발관련 프로젝트는 적용을 해보자 싶었음. 설치방법은 간단함. 나는 맥을 사용중이니 Mac OS X 환경을 전제로 설명함. 터미널을 열어서 git 이 설치되어 있는지 확인한다. >> git --version https://git-scm.com/  에 접속해서 화면 오른쪽에 있는 다운로드 버튼을 눌러서 dmg 파일을 다운로드 받아서 실행한다. (혹은 터미널에서 brew install git 이라고 입력해도 ㅇㅋ)  재부팅 후 터미널에서 1번 과정을 반복해서 설치가 완료되었는지 확인한다. 사용자 홈 디렉토리에 폴더를 하나 만든다. (터미널에서는 mkdir 커멘트 사용)  터미널에서 만든 폴더에 접근하여 다음과 같이 입력 후 ls -all 명령어로 .git 디렉토리가 생성되었는지 확인한다. >> git init https://github.com/  에 접속해서 계정을 생성한다. 생성된 계정을 메일인증 한 후에, 화면 왼쪽상단에 있는 new (+모양) 버튼을 클릭 후,  new repository 를 선택한다. Create a new repository 화면이 나오는데,  Repository name (필수, gitTest로 설정) 과 설명 및 옵션등을 입력한 후 Create Repository 버튼을 누른다.  Quick setup 이라는 설명이 나오는데, 여러가지 방법이 되나보다..그 중에서 나는 가장 원시적인 방법을 택했는데, [..or create a new repository on the command line] 이었다. 터미널로 가서 그대로 타이핑을 했다. >> echo "@ gitTiest" ...

[메모] 시스템 설계의 흐름 및 설계서 구성 관련

프로그래밍 개발 및 IT관련 프로젝트에서 워터폴(폭포수) 모델의 상류공정을 기준으로 설계의 흐름 및 산출물에 대한 정리임. (한국어와 일본어 용어의 번역이 부자연스러울수도??) 참고는  @chocode - システム設計の流れ・設計書の構成メモ 상류공정은 크게 <요구(요건)정의>👉<외부설계>👉<내부설계> 순으로 진행됨. [요구정의] 개발하는 시스템 및 서비스에 요구되는 기능 및 조건을 정리하는 단계. 예를 들면, 다음과 같은 것들이다. 패스워드 인증을 포함한 회원관리 기능 데이터베이스 내부의 자료를 검색 입력자료 및 출력자료의 사양 업무 플로우 처리속도 및 처리용량, 유지보수성, 조작성 등의 비기능적인 요구사항 RFP(제안의뢰서) 작성 및 사전조사를 통해서 실제로 필요한 요건을 정리해 나간다. 이 과정에서 정리된 내용에 기반해서 개발을 진행하게 되므로 제대로 요건을 정의해두면 누락 및 중복을 피할 수 있다. 요구정의를 할 때는 필수적으로 고려해야 하며 확실하게 보증을 해야하는 항목이 중심이 되어야 하며, 인터페이스 디자인 등 개발업체 쪽에서 결정해도 문제가 되지 않는 부분은 외부설계 단계에서 취급한다. 이 단계에서 만들게 되는 산출물은 요구정의서 혹은 요건정의서 라고 한다. 여러가지 양식이나 내용이 있지만 최소한 명시되어야 하는 항목은 다음과 같다. 시스템 개요 무엇을 하는 시스템인가?? 왜 이 시스템이 필요한가?? 이 시스템의 목표는 무엇인가?? 시스템 구성도 시스템 개념도 시스템의 업무 플로우 혹은 시나리오 유스케이스 다이어그램 기능요건(요구) 기능일람 각 기능의 상세설명 입력 및 출력요건 입력데이터 일람 각 입력데이터의 상세(데이터항목, 파일형식 등) 출력데이터 일람 각 출력데이터의 상세(데이터항목, 출력형식 등) 비기능요건 세큐리티 요구사항 품질 및 성능 요구사항 그 외 개발 스케쥴 관계자 일람 혹은 관...

당신이 2017년에 배워야 할 언어, 프레임워크, 툴에 대하여

이미지
많기도 하다...ㅠㅠ 우선 현재 해야하는 건 PHP 와 Javascript 관련 프레임워크인가.. http://han41858.tistory.com/27 당신이 2017년에 배워야 할 언어, 프레임워크, 툴에 대하여 안녕하세요. 한장현입니다. Martin Angelov의 [The Languages, Frameworks and Tools You Should Learn in 2017] 를 번역한 글입니다. I... han41858.tistory.com

UI - 사용성을 넘어 사용자의 경험을 디자인한다.

이미지
컬럼] UI - 사용성을 넘어 사용자의 경험을 디자인한다. UE (User Experience)란   디자인이 멋진 최신식 핸드폰이 나와서 냉큼 사버린 J씨. 그런데 키패드의 번호 배열 조차 기존의 방식과 너무나 다른 새로운 방식.늘 써오던 핸드폰의 키패드 번호 배열과 달라 익숙해지기까지 J씨는 많은 노력을 들였다. 그리고 다시 시간이 지나 그 회사에서 더욱 멋진 최신식 핸드폰이 출시됐는데, 키패드의 번호 배열이 또 다른 방식으로 바뀌었 다. 당신이 만약 J씨라면 그 폰을 다시 살까? 아마도 대부분은 그 폰을 사지 않겠다고 할 것이다. 한번 폰을 교체할 때마다 새로 키패드를 익혀야 한다면 과연 얼마나 그 폰을 사용하려고 하겠는가. 핸드폰의 기본 적인 기능은 전화를 걸고 받는 것이다. 아무리 뛰어난 부가적 기능과 멋진 디자인이라 할지라도 기본적인 기능을 수행함에 있어 불편함을 겪는다면 사용자는 다시 구매하려 하지 않을 것이다. 이렇게  사용자가 어떤 제품이나 시스템을 사용하면서 경험한 과정들을 통해 형성되는 제품에 대한 정서, 인지, 행동 등을 사용자 경험(User Experience)이라고 한다.  제품을 개발할 때, 사람들은 그 제품이 '무슨 일을 하는가'에 주로 신경을 쓴다. 제품이 어떻게 작동되는가 하는 사용자 경험에 대한 생각은 성공적인 제품과 실패작의 차이를 결정할 수도 있는 중요한 부분이지만 무시되는 경우가 종종 있어 왔다. 위의 폰과 같은 경우, 저 번호 버튼들은 번호를 누르거나 버튼으로 인식되는데 있어 전혀 문제가 없다. 그러나 사용자의 경험 속에 형성된 전화번호 버튼배열의 기본적인 모델과 상이하기 때문에 사용자는 전화를 거는데 어려움을 느끼게 된다. 그리고 그러한 반응은 당연히 판매 부진으로 이어질 것이고 기업의 입장에선 큰 손실이 될 수 있는 것이다. UI (User Interface)에서 UE (User Experience)로  과거의 산업화 시대...

프로그래머의 공부론 part 1

우리 프로그래머들은 항상 공부해야 합니다. 우리는 지식을 중요하게 여깁니다. 하지만 지식에 대한 지식, 즉 내가 그 지식을 얻은 과정이나 방법 같은 것은 소홀히 여기기 쉽습니다. 따라서 지식의 축적과 공유는 있어도 방법론의 축적과 공유는 매우 드문 편입니다. 저는 평소에 이런 생각에서 학교 후배들을 위해 제 자신의 공부 경험을 짬짬이 글로 옮겨놓았고, 이번 기회에 그 글들을 취합, 정리하게 되었습니다. 그 결실이 바로 이 글입니다.  김창준 (마이크로소프트웨어)  2002/06/02  이 글은 공부하는 방법과 과정에 관한 글입니다. 이 글은 제가 공부한 성공/실패 경험을 기본 토대로 했고, 지난 몇 년간 주변에서 저보다 먼저 공부한 사람들의 경험을 관찰, 분석한 것에 제가 다시 직접 실험한 것과 그밖에 오랫동안 꾸준히 모아온 자료들을 더했습니다. '만약 다시 공부한다면' 저는 이렇게 공부할 것입니다.  부디 독자 제현께서 이 글을 씨앗으로 삼아 자신만의 나무를 키우고 거기서 열매를 얻고, 또 그 열매의 씨앗이 다시 누군가에게 전해질 수 있다면 더 이상 바랄 것이 없겠습니다.  이 글은 특정 주제들의 학습/교수법에 대한 문제점과 제가 경험한 좋은 공부법을 소개하는 식으로 구성됐습니다. 여기에 선택된 과목은 리팩토링, 알고리즘·자료구조, 디자인패턴, 익스트림 프로그래밍(Extreme Programming 혹은 XP) 네 가지입니다.  이 네 가지가 선택된 이유는 필자가 관심있게 공부했던 것이기 때문만은 아니고, 모든 프로그래머에게 어떻게든 널리 도움이 될만한 교양과목이라 생각하여 선택한 것입니다. 그런데 이 네 가지의 순서가 겉보기와는 달리 어떤 단계적 발전을 함의하는 것은 아닙니다. 수신(修身)이 끝나면 더 이상 수신은 하지 않고 제가(齊家)를 한다는 것이 어불성설인 것과 같습니다.  원래는 글 후미에 일반론으로서의 공부 패턴들을 쓰려고 했습니다. 하지만 지면의 제약도 있고, 독자 스스로 이 글에서 그...

프로그래머의 공부론 part 2

디자인패턴 학습에서의 문제  잡지에 연재되거나 서적으로 출간된 혹은 세미나에서 진행되었던 디자인패턴 '강의'를 몇 가지 접했습니다. 훌륭한 강의도 많았지만 그렇지 못한 것도 있었습니다. 몇 가지 문제점을 지적하겠습니다.  ◆패턴을 지나치게 실체화, 정형화해 설명한다.  ◆컨텍스트와 문제 상황에 대한 설명이 없거나 부족하다. 결과적으로 문제를 해결하기 위해 패턴이 도입된 것이 아니라 패턴을 써먹기 위해 패턴이 도입된 느낌을 준다.  ◆문제의식을 먼저 형성하게 하지 않고 답을 먼저 보여준 뒤 그걸 어디에 써먹을지 가르친다. 왜 이걸 쓰는 게 좋은지는 일언반구 언급이 없다. 독자는 '어린아이가 망치를 들고 있는 오류'에 빠질 것이다.  ◆패턴이 어떻게 생성되었는지 그 과정을 보여주지 못한다. 즉, 스스로 패턴을 만들어내는 데 도움이 전혀 되지 않는다.  ◆해당 패턴이 현실적으로 가장 자주 쓰이는 맥락을 보여주지 못한다. 대부분 장난감 문제(Toy Problem)에서 끝난다.  그런 패턴 강의를 하는 분들이 알렉산더(Christopher Alexander, 패턴언어 창시자)의 저작을 충실히 읽어봤다면 이런 병폐는 없을 것이라 생각합니다. 알렉산더의 저작을 접해보지 못 하고서 패턴을 가르치는 사람은 성경을 읽어보지 않은 전도사와 같을 것입니다. 알렉산더가 『The Timeless Way of Building』의 마지막에서 무슨 말을 하는가요?  이 마지막 단계에는 더 이상 패턴은 중요하지 않다. … 패턴은 당신이 현실적인 것에 대해 수용적이 되는 것을 가르쳐줬다.  패턴 역시 도구요, 방편일 뿐입니다. 패턴은 현실적인 것에 대해 수용적이 되도록 가르친다는 말은 결국 우리가 궁극적으로 추구하는 것은 패턴이 아니라 현실이어야 한다는 이야기입니다. 물론 처음 단계에는 교육적인 목적에서, 어느 정도 패턴에 얽매여도 괜찮다고는 해도, 나중에 패턴을 잊고 패턴에서 자유로워지려면 처음부터 패턴에 대해 도...

프로그래머의 초식 - 디자인 패턴이란??

1980년대 중반 소프트웨어의 사용 범위와 규모가 폭발적으로 늘어나게 되면서 소프트웨어를 구성하는 프로그램의 논리는 점점 더 복잡한 실타래처럼 꼬여갔다. C 언어로 대표되는 기존의 ‘절차적’ 언어가 그런 변화를 감당하기에 역부족이라는 사실은 누구의 눈에도 분명했다. 이와 같은 상황에 등장하여 사태를 단숨에 제압한 존재가 바로 ‘객체’였다. 객체가 제공한 ‘코드의 재사용(reusability)’과 ‘다형성(polymorphism)’이라는 약은 중병을 앓던 소프트웨어의 세계에서 놀라운 효능을 지닌 처방이 되었다. 객체의 ‘약’맛을 본 프로그래머들은 세부적인 알고리즘의 구현에 점점 덜 구애받게 되었다. 세부적인 논리보다는 요구사항(requirements)을 분석한 결과에 따라서 객체를 정밀하게 설계하는 일이 더 중요하게 되었기 때문이었다. 하지만 모든 약이 그렇듯이 객체도 모든 병에 대한 만병통치약이 될 수는 없었다. 객체의 개념과 장단점을 정확하게 파악하고 있는 프로그래머에게 객체는 분명 약이 되었지만 그렇지 않은 프로그래머에게는 오히려 ‘독’이 되기도 했던 것이다. 객체지향의 창시자, 와드 커밍햄과 켄트 벡 1987년에 객체지향 언어인 ‘스몰토크(Smalltalk)’를 이용해서 소프트웨어 설계 작업을 하던 와드 커닝험(Ward Cunningham)과 켄트 벡(Kent Beck)은 막바지에 이른 작업의 완성을 위해서 소프트웨어를 이용하게 될 사용자들이 직접 설계를 끝내도록 맡겼다. 이 때 커닝험과 벡은 스몰토크에 익숙하지 않은 사용자들이 잘못된 설계를 하는 것을 방지하기 위해서 스몰토크 언어를 이용한 설계에서의 몇 가지 핵심적인 내용을 간추린 ‘패턴(pattern)’을 정리해서 교육시켰다. 교육의 결과는 만족스러웠다. 커닝험과 벡은 이 경험으로부터 객체지향 언어에 있어서 디자인 패턴의 중요성을 처음으로 깨닫게 되었다. 그리하여 그들은 1987년에 열린 OOPSLA(Object-Oriented Programming, Sy...