동탁의 개발자취

세일즈포스는고객 데이터를 저장하고잠재 고객을 육성할 수 있는 프로세스를 제공하며함께 일하는 사람들과 협업할 수 있는 방법을 제공잠재 고객 및 고객에게 판매 - 판매를 관리하기 위한 리드 및 기회판매 후 고객 도움 - 고객 참여를 위한 사례 및 커뮤니티이동 중 작업 - 사용자 정의 가능한 Salesforce 모바일 앱동료, 파트너 및 고객과 협업 - Slack, Chatter 및 커뮤니티를 사용하여 회사와 연결대상 고객 마케팅 - 고객 여정을 관리하는 마케팅 클라우드기본 이용 약관Slaesforce 앱은 비즈니스 프로세스를 지원하는 객체, 필드 및 기타 기능의 집합 App Launcher로 사용 중인 앱을 확인하고 앱 간에 전환 가능객체는 특정 정보를 저장하는 Salesforce 데이터베이스의 테이블 계정..

취업 이후 이런저런 업무를 하다 보니 개인적인 자기개발이 잠깐 끊겼다가, 전 직장에서 직원 스케줄을 만드는게 상당히 번거로웠던 경험을 살려 workdayscheduler - 스케줄 생성기를 한번 만들어 보았다. 현재도 계속 기능 추가 및 오류 수정 중이며 그 기록들은 주기적으로 블로그에 업로드 할 예정이다. 해당 프로젝트는 기본적으로 React로 만들어져 있으며 사용한 라이브러리는 대표적으로 "react-dom", "react-modal", "xlsx", "gh-pages"가 있으며 각각 react-dom : 기능별 페이지 라우팅을 위해 사용 react-modal : 모달창을 만들기 위해 사용 xlsx : 만들어진 페이지의 엑셀 다운로드를 위해 사용 gh-pages : github의 pages를 활용하여..

이번 프로젝트에서는 처음으로 Recoil , TS를 사용하여 프로젝트를 진행하고 있다. 현재 전체적인 Layout을 TS를 통하여 만들었고 Recoil을 이용하여 일기 쓰기 페이지를 작성해 보았다. 해당 페이지의 코드는 다음과 같다. import React from "react"; import axios from "axios"; import { useRecoilState } from "recoil"; import { journalState } from "../../Atom"; import { JournalPostMain, JournalPostSC, ButtonDiv } from "./JournalPostSC"; const JournalPost : React.FC = () => { const [journa..

* 엘리스 수강 중 2차 스터디에서 조사한 객체 지향 프로그래밍에 대한 발표 자료 정리 블로깅 입니다. 객체 지향 프로그래밍이란? 우선 객체 / 지향 두 가지 단어의 뜻을 한번 확인해 보면 지향 : 객체(컴퓨터 과학에서) : 따라서 객체 지향 프로그래밍이란 간단하게 라고 볼 수 있다. 객체 지향 프로그래밍이란 컴퓨터 프로그래밍의 패러다임 중 하나로 그동안의 사람들이 컴퓨터 프로그래밍에 대해서 정해 놓은 견해나 사고들을 다르게 바꾼 패러다임 중의 하나이다. 기존의 컴퓨터 프로그래밍에서는 프로그래밍을 각각의 다른 명령어들의 나열로 보는 것과 다르게 각각의 객체가 메세지를 주고 받고 데이터를 처리 할 수 있으며, 이 독립적인 객체들의 모임으로 프로그래밍을 파악하는 것이 객체 지향 프로그래밍으로의 패러다임 변화..

Git Conflict (깃 충돌) 해결 방법 프로젝트를 진행하면서 팀장을 맡아 다양한 Git Conflict를 마주하게 된다. 그때마다 항상 당황하고 짜증을 내면서 해결을 하였지만, 여러 경험이 쌓인 후 깨달은 점은 git conflict는 오히려 좋다. 물론 충돌없이 각자가 맡은 파트에서 최선을 다하여 작업하고 합쳐져서 하나의 작업물이 완성이 된다면? 사실 그거야 말로 더할 나위 없이 좋을 수 있다. 하지만 오히려 git conflict를 활용한다면 서로 같은 파트를 작업하여도 더욱 효율적이고 좋은 코드를 선택하여 작업물의 퀄리티를 높일 수도 있다고 생각한다. 해결 방법 1. 우선 테스트를 위하여 현재 리팩토링 중인 작업물에서 dev브랜치를 생성한 후 checkout 하였고 src 디렉토리에 test..

이번 프로젝트에서는 1차 프로젝트와 다르게 Route들을 컴포넌트화 하여 따로 관리하여 불필요하게 길어진 태그와 코드들을 효율적으로 정리해 보았다. 1. 기존의 방식 기존의 Route방식에서는 위의 사진과 같이 path와 element값을 넣은(React-Router-Dom V6) Route태그를 길게 나열하여 Route를 관리하였다. 하지만 해당 방식의 문제점은 1. import를 해야 하는 component가 너무 많아 가독성이 떨어진다. 2. 한 component내에서 한번에 너무 많은 route를 비효율적으로 render한다. 위와 같은 문제점을 가지고 있었다. 2. 바꾼 방식 따라서 위와 같은 문제점을 해결하기 위하여 React의 장점인 component를 활용하여 ROUTE를 따로 관리하기로 ..