본문 바로가기

Category

 (417)
[공간리뷰] 국내에 공간 잘 쓰는 애들 http://piknic.kr/exhibition-category/current/ 피크닉 piknic piknic.kr https://blog.naver.com/localstitchmaster/223179821504 [로컬스티치 회현] A,B,C,D,E,F 구석구석 골라보는 재미가 있다! 과거와 현재를 이어주는 가게 로컬 로컬 스티치 회현 - 4호선 회현역 4번 출구, '서울로'가 끝나는 신호등 옆 '로컬 스티치 회... blog.naver.com 둘이 거~의 붙어있다. 피크닉 전시 한번 커피한잔 마시고 , 로컬 스티치 한번 보면 딱 이다.
라우터 + 새로운 페이지 만들기 커피 많이 마셔서 상태 메롱 https://velog.io/@jjunyjjuny/nextjs-13.4.0%EB%B6%80%ED%84%B0-%EC%95%88%EC%A0%95%ED%99%94%EB%90%9C-App-Router.-Pages-Router%EC%99%80-%EB%B9%84%EA%B5%90 [nextjs] 13.4.0부터 안정화된 App Router. Pages Router와 비교 13.4.0버전부터 stable로 승격된 app router에 대해서 기존의 pages router와 비교하며 알아봅니다. velog.io 이거 보고 디렉토리 만들고 index.js 만드니깐 작동한다. https://velog.io/@sssm/Next.js-App-Router%EC%99%80-Pages-Router [N..
읽기 좋은 코드가 좋은 코드다 오랜만에 CTO인 업계선배와 이야기를 했다. 개발 잘 하는 개발자는 누구일까? 1. 커뮤니케이션 되고 센스있는 개발자 2. 읽기 좋은 코드를 작성하는 개발자 3. 성장하려는 개발자 4. 코드스멜을 잘 맡는 개발자 5. 의지가 있는 개발자 6. 책임감 있는 개발자 .. 끝도 없다 개발자라면 읽기 좋은 코드를 작성할 수 있어야한다. 주석을 아무리 달아놔도 코드 자체가 보편적이고 읽기 좋은 코드를 짜지 않으면 유지보수, 고도화가 불가능하다. 잘하는 개발자들은 코드를 굳이 꼬아놓지 않는다. 프로덕트 런칭하는것도 정말 힘든일이지만, 유지보수 역시 정말 힘들다. 해석불가능한 코드를 짜놓으면 책임감없는 코드를 짜는 경우가 많은데 이건 정말 답이 없다. 읽기 좋은 코드가 좋은 코드다 ㅈㄱㄴ
만약 내가 주니어IT 분야의 디자이너라면 어떻게 공부할까 - 키워드는 서핏 디자인탭에서 주을 거다 - 디자인 나침반을 회사 계정으로 월욜 마다 뉴스레터 받아서 환기를 시킬거다 - 프로덕트헌트에서 매일 놀거다. (이건 지금도 해야할듯) 외국 내 또래들이 최근 만드는 프로덕트를 구경하고 감을 유지하기 좋다. 근데 굳이 사이트 들어가지는 않으니깐 -> 회사그룹웨어 뉴스레터로~ 뉴스레터를 구독하면 일일/주간 선택할 수 있고 따로 The Art of Product 정보도 받아볼 수 이ㅏㅆ다. - 그리고 이걸 진행할것 같다 https://weeklyuxuichallenge.oopy.io/ 위클리 UX/UI 분석 챌린지 - UX 스터디, 기획 스터디 UX/UI 에 관심있고 인사이트를 얻고 실력을 키우고 싶은 멤버들이 모여 UX/UI 리뷰, 아티클 공유, 북리뷰 등 다양한 ..
css.module 조건부 스타일 근본 classnames 안쓰면 그냥 이렇게 해야해야함. 근데 난 종속성 싫어서 그냥 이런식으로 씀. 유딩도 알아볼 수 있는 코드가 좋다 // MyComponent.js import React from 'react'; import styles from './MyComponent.module.css'; const MyComponent = ({ isSpecial }) => { // 조건에 따라 클래스를 동적으로 할당 const containerClassName = isSpecial ? styles.specialContainer : styles.normalContainer; return ( Hello, World! ); }; export default MyComponent; 링크 조건부 스타일은 이런식으로 http..
위쪽으로 올라오는 border-bottom 가끔씩 border-bottom 라인이 밑으로 되어있어서 짜증날때가 있다. 그럴땐 shadow로 처리를 하면 된다. box-shadow: inset 0px -1px 0px 0px #ffe142; 이해 하고 싶으면 https://www.cssmatic.com/box-shadow Box Shadow CSS Generator | CSSmatic CSSmatic is a non-profit project, made by developers for developers Are you a web developer? Would you like to collaborate on CSSMatic? www.cssmatic.com 쉐도우 자동생성기를 만지작 거리면 이해할 수 있다.
next styles 방식에 대한 고찰 https://nextjs.org/docs/app/building-your-application/styling Building Your Application: Styling | Next.js Learn the different ways you can style your Next.js application. nextjs.org tailwind -> scss -> css module -> css 걍 글로벌로 css 쓰기로 결론 땅땅땅. 우리 조직 큐모 크지로 않는데 억지로 복잡도를 만들 필요는 없음 스타일 만지는 개발자 3명이상 이면 새로운 방식으로 변경해도 된다고 생각함. 아직은 아님. 그리고 module 로 한것도 진짜 많이 내려둔것데.. 라이브러리 써서 뚝딱뚝딱 만들려니깐 잘 안되네
개발자는 어디까지QA 를 해야할까? https://medium.com/@kth5604/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%8A%94-qa%EB%A5%BC-%EC%96%B4%EB%8A%90%EC%A0%95%EB%8F%84-%EA%B9%8C%EC%A7%80-%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98-ae10e94ed296 개발자는 QA를 어느정도 까지 해야하나? 요약 medium.com 내 생각: - 초기 프로덕트 런칭 과정 개발자랑 , 걍 개발자랑 구분해야함 - 개발팀 꽤 있고 qa 팀있고 이런 개발자는 걍 논할 대상도 아님 초기팀에서 초기 프로덕트 런칭 과정에 있는 개발자라면, 도대체 QA를 어느정도 까지 해야하나? 바로결론: 개발자 실력에 따라 케이스 바이 케이스 개발실력 별로 없으면 기능개발만..

티스토리툴바