여러가지 form 태그들

폼 Form

action

• 제출 시 양식 데이터를 보낼 위치를 지정합니다. 일반적으로 URL입니다.

method

• 데이터 전송 방법을 정의합니다. 가장 일반적인 두 가지 방법은 'GET'과 'POST'입니다.

GET:

• 이름/값 쌍으로 URL에 데이터를 추가합니다. 민감하지 않은 데이터에 적합합니다.

POST

• 데이터를 HTTP 포스트 트랜잭션으로 보냅니다. 민감한 데이터에 사용됩니다.

입력 태그 input

text

• 일반 텍스트 입력용입니다.

email

• 이메일 전용.

number

• 숫자 입력을 받는 최적화된 키보드 뜨게.

password

• 비밀번호 입력용. 입력값 *** 이렇게 마스킹되게

date

• 날짜

submit

• 양식을 제출합니다.

라벨 태그 label

label

• 예상 입력을 설명하므로 사용자가 양식을 작성하는데 도움이 된다.

• 텍스트 레이블을 양식 입력 요소와 연결하는 데 사용 => 레이블 클릭해도 입력요소에 커서 올라감!

• 라벨의 'for' 속성은 해당 입력 요소의 'id'와 일치해야 합니다.

• for는 보조 기술이 어떤 레이블이 어떤 입력 필드에 속하는지 알 수 있도록 한다.

<form>
    <label for="username">Username:</label>
    <input type="text" id="username" name="username">
    
    <label for="password">Password:</label>
    <input type="password" id="password" name="password">
    
    <input type="submit" value="Login">
</form>

• Username: "사용자 이름:" 내용이 포함된 label은 사용자 이름에 대한 텍스트 입력 필드와 연결됩니다.

• 이는 label의 for 속성을 input 요소의 id와 일치시켜 수행됩니다. 따라서 레이블의 for="username"은 입력의 id="username"과 일치합니다.

• 비밀번호 라벨: 마찬가지로 "비밀번호:" 라벨은 비밀번호 입력 필드와 연결되어 있습니다.

label 을 왜 사용할까..?

접근성

• 관련 입력 필드에 '초점'이 맞춰지면 화면 판독기가 레이블을 읽어주므로 시각 장애가 있는 사용자가 입력 필드의 용도를 이해할 수 있습니다.

사용성 개선

• 라벨 텍스트를 클릭하면 관련 '입력 위젯에 초점'이 맞춰지거나 활성화됩니다. 이는 작은 체크박스와 라디오 버튼에 특히 유용하며 '클릭하기가 더 쉽'습니다.

---

value

• 디폴트 값을 입력하거나
• 사용자에게는 보이지 않지만, 컴퓨터가 읽을 수 있게 value 를 서버에 전송

---

radio

      <input type="radio" name="verify" id="verify-text-message">
      <label for="verify-text-message">Via text message (SMS)</label>
      <input type="radio" name="verify" id="verify-phone">
      <label for="verify-phone">Via a phone call</label>
      <input type="radio" name="verify" id="verify-email" >
      <label for="verify-email">Via an email</label>

• id 는 다르지만, name은 동일하게 해야 3중 1개 선택.

• 여러 옵션 중에서 하나를 선택합니다.

---

checkbox

• 체크하면 value 값으로 전송
• value 없다면 on 으로

radio vs checkbox

• 라디오는 한개의 옵션만 선택
• 체크박스는 여러개의 옵션 선택 가능.

file

• 파일 셀렉터를 생성

드롭다운

select 태그, option 태그

• 드롭다운 목록을 만듭니다.

  <select id="favorite-color" name="favorite-color">

• 라디오버튼 처럼 한개만 선택하는 것이니 name 하나로 통일해야해.

<label for="favorite-color">Your favorite color?</label>
      <select id="favorite-color" name="favorite-color">
        <option value="blue">My favorite color is blue</option>
        <option value="black">Black</option>
        <option value="red">Red</option>
      </select>

• select 태그는 목록을 정의하고, 그 안에 있는 'option' 태그는 사용 가능한 옵션을 정의합니다.

 <option value="blue">My favorite color is blue</option>

• value 를 설정하면 value 가 서버로 전송되고, 사용자에게는 My favorite color is blue 가 보여진다.

장문이 가능한 텍스트 태그 'textarea'

<textarea id="message" name="message"></textarea>

• 닫는 태그를 꼭 설정해야해
• 댓글이나 메시지 등 여러 줄의 텍스트 입력이 가능합니다.
• 행 및 열 속성을 사용하여 크기를 조정할 수 있습니다.

button 태그

button

• 클릭 가능한 버튼에 사용되며 종종 양식을 제출하는 데 사용됩니다.

submit

• 양식을 제출합니다.

reset

• 양식의 입력을 초기화 합니다.

button

• 기본 동작이 없는 일반 클릭 가능한 버튼입니다.

Validate

novalidate

<form action="/" method="GET" novalidate>

• 브라우저 검증을 해제
• ex) 무효한 이메일도 통과시킨다

required

<input type="text" name="user-name" id="username" required />

• 필드가 공란이 되면 경고.

minlength

<input
                type="password"
                name="user-password"
                id="userpassword"
                required
                minlength="7"
              />

• 최소 N 문자.

min, max

• 최소 최대 설정

    <input
                type="number"
                step="1"
                name="user-age"
                id="userage"
                required
                min="18"
                max="100"
              />

       <input
                type="date"
                id="birthdate"
                name="user-birthdate"
                required
                min="1921-01-01"
                max="2003-01-01"
              />

placeholder

placeholder vs value

<input type="text" name="user-name" id="username" required placeholder="Max Schwarz" />

• value 값은 사용자가 입력한 데이터로 취급.
• placeholder 는 입력된 값으로 취급되지 않음. => 가이드 기능!

row

• N열이 디폴트. 텍스트 에이리어의 높이가 N열을 수용할 수 있다는 뜻.

• 추가) css r

---

멘토링 QnA

백엔드 개발자가 만드는 어드민 페이지와 관련해서 질문 드립니다 :)‘백엔드 개발자 포지션을 맡고 있더라도, 어드민 페이지 정도는 스스로 만들 수 있는 수준의 프론트 엔드 개발 능력을 갖춰야 한다’ 라고 알고 있는데요.여기서1) 어드민 페이지란 주로 무엇을 위해 만드는 것인지? 2) 그것을 만들기 위해 프론트 엔드 개발 지식은 어느 정도 수준이 요구되는지? 3) 어드민 페이지를 편리하게 만들기 위해 실무에서 주로 사용되는 도구나 템플릿이 있을지?

위 세가지를 질문드리고 싶습니다!

• 회사입장에서의 니드가 조금 있긴해. 하지만 프론트와 백은 달라서 프론트 개발을 어려워하는사람도 많아. 그 간극을 좁히기 위해 스트레스 받는 사람이 많아서 백을 하지만 프론트도 살짝 하면 좋긴하지.

• 지마켓에서 카테고리 같은것을 사용자가 만들게 할 수는 없어. 지마켓 자체의 퀄리티가 떨어져. 커뮤니티라고 할때, 악성 댓글을 단 유저가 있어. 이 유저를 검색하고 차단하는 기능을 만들때, 개발자가 insert 할 수는 있지만 이는 너무 번거로워.

• 이를 그래서 admin 페이지에서 만들기로 했어. 강의 재생이 안된다는 cs 를 받았을때, 고객센터에서 받아서 admin페이지를 구축하는 경우도 있어. 사용자에게 노출되면 안되지만 필요로하는. 사용자의 데이터에 변화를 주거나 삭제를 하거나 하는 수작업을 db 대신 하기 위해.

• 어드민 페이지는 Vue.js 2-3일 동영상 강의 보고 작업시키는 경우가 많음. 어드민 페이지는 네트워크만 중요하기 때문에 퀄리티가 낮아도돼. 기능만 작동하면 되거든.

• 3. 프론트 배우면 부트스트랩으로 최소한의 ui 를 만드는 경우가 일반적이야. 어드민 페이지도 그러하고. 프론트와의 간극이 여기서 생기는데 프론트는 보통 리액트 사용하지. 백엔드한테 어드민을 맡기면 vue 를 사용해. 기술 스택 차이를 싫어하고. 백엔드 사람들은 이게 메인이 아니기 때문에 그러하지.

---

안녕하세요, 멘토님 실무에서의 깃과 깃허브 활용에 대해 궁금하여 질문드립니다. 회사마다 다르겠지만 현재 멘토님이 계신 곳에서는 협업을 어떻게 진행하고 계시는지 궁금합니다. Ex) 지라나 깃랩과 같은 협업툴을 활용한다던가…? 회사마다 브랜치의 작명 방법, merge 방법 가이드라인 같은 것이 있다고 들었는데 실제로 이런 가이드라인이 운영되고 있는지 궁금합니다. 가이드라인이 존재한다면 깃의 충돌이 발생할 가능성이 낮을 것 같은데, 그럼에도 문제가 발생하는 경우가 있는지 궁금합니다.

멘토님이 깃을 활용한 협업 문제를 겪어보신 적이 있으시다면 그 중 가장 기억에 남는 에피스드를 듣고 싶습니다!
항상 많이 배우고 있습니다. 감사합니다!

• 깃허브 엔터프라이즈 사용중. 메인 브랜치는 프로텍션을 걸어놔. 풀리퀘스트 없이 커밋이 들어올 수 없어. 지라 연동을 해두었어. 연관된 커밋을 연동하는 정도야. 그 이상으로는 별 규칙이 없어. 너무 규칙이 많으면 불편하거든.

• 회사가 커지면 팀바이 팀 이 더 커지기 때문에 크게 공유하거나 그러지는 않아.

• 2. 이슈를 무엇으로 관리하냐에 따라 달라. 이슈가 번호로 나오면 ex) 이슈번호 feature 이슈번호 이렇게 짜는 경우가 많아. feature 의 내용을 한글로 쓰는 경우도 있고. 짧게 단어 수준으로 요약하기는 쉽지 않으니 난 숫자를 더 사용해.
• 3. 머지는 방지해. 풀리퀘스트만 가능하게. 그 기준에서 가이드라인은 , 팀 8명 중 리뷰어 지정이 최소 4명, 그 중 절반의 동의를 얻어야해. 그 승인이 나지 않으면 merge 가 들어 올 수 없어. 책임은 승인한 사람과, 코드 작성자에게 있는데, 이 책임은 해고하고 그런게 아니라 회고하면서 코드를 고치는 정도야. 리뷰를 줄때 의견이 아직 모아지지않은 경우에는 approve 를 하면 안돼. 리뷰 상태로 두고 논의를 이어가야해.

• 한주간에 풀 리퀘스트 합의가 됐는지를 합니다.

• 충돌 해결하고 다시 체크해야해.

• 4. 깃이 오히려 메인에다 커밋을 안하면 문제가 안생겨. 그래서 풀리퀘스트를 걸어놓는거야. 깃은 커밋을 한번 하면 날라가지 않는데, 충돌이 나면 내것이 날라간거처럼 인식되는 상황이 있어. 근데 툴에서는 안보이는거지. 커맨드 라인에서 보면 나와있는데. 그걸 모르는 사람들이 패닉에 빠지는 경우가 있었어. 다 복구할 수 있어. 하지만 그 충돌을 해결하는 과정에서 계속 또 충돌이 나고 이를 해소하려면 공부를 열심히 해야하긴해. => 고생 좀 하긴하지..
     => 프로텍션 그래서 꼭 썼으면 좋겠어.

---

멘토님은 개발을 하다가 막히거나 스트레스 받으실 때 주로 어떤 방법으로 해소하실지 궁금합니다ㅎㅎ

• 무조건 50분을 리미트로 걸고, 화장실을 갔다오거나 음료를 가져오거나. 방법이 떠오르면 자리에 앉고 생각이 정리 될때까지 산책을 하거나 지금까지 했던 생각들을 정리하긴해.

• 시니어도 문제는 항상 생겨. 안풀리는게 당연하다는 마음가짐을 가지는게 좋아. 내가 새롭게 배우는 분야는 초보니까.

• 집중도가 진짜 떨어지면 놀다오기도해.

---

지라 관련 질문이 나와서, 팀 프로젝트에서 지라 활용 중 궁금증이 들었던 부분 저도 한번 질문 드립니다!현재 애자일 스크럼 방식으로 지라를 활용중에있으며, 스크럼 마스터의 경우엔 팀원들이 스프린트마다 돌아가면서 맡기러 했는데, 스크럼 마스터의 역할이 어디부터 어디까지일지 궁금해 문의 드립니다..!

그리고 스크럼 마스터를 팀원들이 돌아가면서 맡는것이 관련 맞는 선택일지, 현업에서는 보통 어떤 사람이 스크럼 마스터를 맡는지 궁금합니다!
또한 github 협업 관련해서
멘토님께서 coding convention이나 PR convention이라면 몰라도, commit convention에 대해서는 “ㅇㅇ” “진짜마지막” 이런식으로만 작성하지 않는다면 크게 신경쓰지 않아도 될것같다고 하신것으로 기억합니다..!
하지만 기존에 다른 커피챗에서 commit 메세지의 양식만큼은 통일했으면 한다는 피드백을 받았었고, 이를 위해 현재 진행중인 사이드 프로젝트에서 팀원들이 convention에 대해서 신경쓰지 않고 message를 작성하더라도 작업한 내용과 키워드만 적으면 자동으로 convention에 맞춰서 commit message가 수정될 수 있도록 설정하고 싶었으나 github에는 gitlab과 달리 해당 기능을 제공하지 않는다고 해서 githook에서 직접 prepare-commit-msg를 이용해 commit 메시지를 양식에 맞게 바꿔주도록 설정을 해두었습니다..
그런데 현재 상황에서는 commit message에 body를 입력하는 경우엔 body에 입력된 내용이 commit message에 합쳐져서 수정입력이 되어버리는 바람에 스크립트를 수정하고자 하는 와중에 생긴 궁금증인데요..!
관련해서 궁금한 부분이
현업에서 commit message의 body에 상세한 내용을 적는 경우가 많은지 궁금하며
연관지어,
현업에서는 PR merge 시에는 보통 어떤 merge 전략을 주로 가져가시는지 궁금합니다..!
dev 와 main 브랜치의 commit history를 깔끔하게 하기위해 스쿼시 머지를 실행한다는 의견과, 모든 commit 은 유의미하기에 일반 merge 를 해야한다는 의견이 충돌되어 의견 조율중에 있습니다! feat, fix브랜치의 경우 dev브랜치에 merge시 삭제되도록 설정해두었습니다!

• 보통 스크럼 마스터가 모든 기록을 책임지고, 풀리퀘스트 밀린거, 리뷰어들 밀린거들 독촉을 받아. 블러킹 포인트를 찾는것. 시작 상태에 너무 오래 머무른것들 체크하고 푸씨해. 또 마스터 역할의 로테이션이 돌면, 모든사람들이 공감할 확률이 높아지고 팀워크에 좋아.

• 2. 돌아가면서 하는게 맞는거같아.

• 한커밋에 여러개 작업을 하는건 좋은게 아냐. ex) 부연설명이 많이 들어가는 커밋들. 현업에서는 머지가 이루어졌다는게 명시적이어야해.

---

알고리즘 문제를 풀때 테스트 케이스 작성 요령이 있으시면 알려주시면 감사하겠습니다!

• 임계값 버그들을 먼저 검사하는게 좋아. 부호실수가 별게 아닌데 되게 많이해서.
• 입력에 중복값이 있을때 ex) array 로 입력값이 있을때
• 값이 많을때

지형님 질문에 이어지는 질문입니다. 어드민 페이지가 내부에서 이용되는 것이고, 단순 구현이 목적이라면 타임리프 써도 되나요? 주변 사례들을 보면 몽고DB를 주로 노드JS 기반 프레임워크와 엮어서 쓰던데, 스프링+몽고db 조합과 비교해서 node.js +몽고db 조합이 더 나은 점이 있을까요? (주로 스타트업이라 몽고db 사용률이 높다고 추측은 하고 있지만, 멘토님 의견을 들어보고 싶습니다~!)

• 그래도 됩니다. 뭐를 써도 상관은 없는데, 백엔드와 프론트를 분리하는게 좋을거같아.

• MVC 가 단점이 없는건 아닌데 현재는 프론트, 백엔드를 분리하는게 선호되는 이유가 있긴해. 따로 분리하면 API 재활용도 가능하고, 어드민 기능까지도 서버를 같이 써도되고 규칙도 같이 가져가도 되서.

• 2. 스프링 + 몽고 db 가 더 나은점이 있는건 아냐. 스프링 개발자들이 리액티브 프로그램을 잘 못하는 사람들이 많아. 비동기 처리를 스프링이 잘 못하기도했고. async 과 await 의 직관성을 아직 못가져왔어. 그래서 그렇고.

• 스타트업이라고 몽고db 사용률이 높지는 않은거같아. 스키마리스 분산 db 로 분류되고 그 해당 포지션에서는 대세가 맞긴한데. 스타트업 아니더라도 많이 쓸거야.

• 노드 js 는 스타트업이 많긴해. 한국의 빅테크는 java 스프링이 너무 주세다 보니까. 또 바꿀만큼의 메리트가 없어. 이미 너무 많은 구성원이 익숙하기때문에.

• 노드를 사용하면 async await를 사용해 비동기를 사용하는 장점을 잘 썼으면 좋겠어. 몽고 db 와 시너지가 너무 좋은 조합이야. 코드 가독성까지 고려하면 훨 좋아.