나는 별일없이 산다 뭐 별다른 걱정 없다

반달 -  작자 미상 차갑게 잘려있었다. 완벽하게 나뉜 달은 잔인했다. 지나가는 젊음이 멈춰섰다. 이제는 가야할 길보다 오왔던 길이 길다. 동그란 시계 위 날카로운 바늘에 찔려있다. 하지만 달은 차오른다. 잠깐의 두려움과 실망을 부끄럽게 하며 밝아온다. 그렇게 달빛이 위로한다.

명령형 프로그래밍 순차적 어떻게 문제를 해결 할지가 주요 관심 튜링 완전 C, 파스칼 선언형 프로그래밍 어떻게 나타내야 할지에 초점 순차적일 필요가 없음 어떤 인터페이스를 만들지 HTML 함수형, 등등이 있다. (명령형이 아닌 것을 선언형이라 부르다?!) 튜링 완전하지 못함?! 프로그래밍에서 꽤나 중요한 개념일 것 같아서 조사하고 따옴 vue.js를 공후바다 컴공의 지식이 필요함을 느낀다. 언어를 공부하려니 구조를 파악하게 되고 그러려니 왜 그 구조가 나왔는지에 대한 목적을 알아야 하고 그러다 보니 그 목적이 무엇을 의미하는지를 알기 위해 컴공 지식이 필요해진다. 아 공부는 끝이 없다.

<div id="app-4">   <ol>     <li v-for="todo in todos">       {{ todo.text }}     </li>   </ol> </div> var app4 = new Vue({   el: '#app-4',   data: {     todos: [       { text: 'JavaScript 배우기' },       { text: 'Vue 배우기' },       { text: '무언가 멋진 것을 만들기' }     ]   } }) 콘솔에서, app4.todos.push({ text: 'New item' })을 입력하십시오. 목록에 새 항목이 추가되어야 합니다. 이상이 vue 가이드에서 이야기하는 반복문이다. 리액트에서는 <div> <ol> { this.props.list.forEach( e => { return ( <li>{e.name}</li> )})} </ol> </div> this.props.list = [ {name: kate}, {name: jason}, {name: tate} ] 이란 식으로 작성한다. 리액트로 공부를 시작한 나에게는 vue의 문법은 꽤 당황스럽다. 분명 리스트로부터 생성되는 dom element는 <li>일텐데 <li>를 감싸는 표식이 아무 것도 없고 오히려 <li> 안에서 데이터를 불러오기?! 때문이다. 물론 <li> 안에 v-for로 바인드가 되어 있어서 '이 <li>는 데이터에 맞추어 반복될 것이다'라...

개요 render props은 값이 함수인 prop을 사용하여 리액트 컴포넌트 간에 코드를 공유하는 간단한 테크닉이다. 렌더 프롭을 갖는 컴포넌트는 함수를 갖는다. 함수는 함수의 렌더 로직을 구현하는 대신 리액트 element를 반환하고 불러온다. <DataProvider render={data => (   <h1>Hello {data.target}</h1> )}/> 렌더 프롭을 사용하는 라이브러리로는 리액트 라우터와 다운 시프트가 있다. 우리는 왜 렌더 프롭이 유용한지 그리고 어떻게 사용하는지 알아본다. Use render props for cross-cutting concerns 컴포넌트는 리액트에서 코드 재사용의 primary unit이다. 그러나 한 컴포넌트가 encapsulated한 state와 행동을 같은 상태를 필요로 하는 다른 컴포넌트와 공유하는지가 언제나 분명하지는 않다. 예를 들어 따라오는 컴포넌트는 웹앱에서 마우스 포지선을 트래킹 한다: class MouseTracker extends React.Component {   constructor(props) {     super(props);     this.handleMouseMove = this.handleMouseMove.bind(this);     this.state = { x: 0, y: 0 };   }   handleMouseMove(event) {     this.setState({       x: event.clientX,       y: event.clientY     });   }   render() {     return (       ...

아래의 내용은 기사를 번역 한 것 입니다. 생략하거나 간추린 내용이 있습니다. 블로그의 주인이자 번역을 하는 필자는 멍청이입니다. -----------(이하 내용)-------------- "setState를 사용해서는 안됩니다."라는 기사를 보았으면서 동시에 어떤 문서는 "refs are bad"라고 주장하고 있다 ... 이 새끼들이?!  무엇이 잘 하는 것인지 무엇을 선택하는 지에 대한 기준을 이해하기 매우 어렵다. 도대체 어떻게 form을 만들어야 하는가? 결국 form은 많은 웹 앱의 핵심 요소이다. 그럼에도 불구하고 React에서의 form 핸들링은 약간의 ... corner stone? (역자 주: 뭔 소리를 하길래 corner stone이라는 단어를 썼는지 1도 모르겠다. asshole이나 moron이 더 적절해 보이는데...) 그러나 더 이상 두려워하지 마라. 접근법의 차이점과 각 접근법을 사용해야 할 때를 살펴보자. The Uncontrolled Uncontrolled inputs는 전통적인 HTML form inputs과 비슷하다. class Form extends Component {   render() {     return (       <div>         <input type="text" />       </div>     );   } }  그 것들은 당신이 무엇을 기입했는지를 기억한다. 당신은 ref를 통해서 value를 얻을 수 있다. 예를 들어 버튼의 onClick 핸들러 안에서 class Form extends Component {   handleSubmitClick = () => {     const name = this._name.value; ...

개요  대부분의 경우, 우리는 controlled components를 추천한다. controlled component에서는, form data는 리액트 컴포넌트로 다루어진다. 대체재로 uncontrolled components가 있는데 DOM 자체에서 form data를 다룬다.  uncontrolled components를 작성하려면 모든 state 업데이트에 대한 event handler를 작성하는 대신 ref를 사용하여 DOM에서 form values을 가져올 수 있다. 예를 들어,이 코드는 uncontrolled components에서 단일 이름을 허용한다: class NameForm extends React.Component {   constructor(props) {     super(props);     this.handleSubmit = this.handleSubmit.bind(this);     this.input = React.createRef();   }   handleSubmit(event) {     alert('A name was submitted: ' + this.input.current.value);     event.preventDefault();   }   render() {     return (       <form onSubmit={this.handleSubmit}>         <label>           Name:           <input type="text" ref={this.input} />   ...

개요 React의 일반적인 패턴은 컴포넌트가 여러 element를 반환하는 것 이다. fragment을 사용하면 DOM에 노드를 추가하지 않고 하위 목록을 그룹화 할 수 있다. render() {   return (     <React.Fragment>       <ChildA />       <ChildB />       <ChildC />     </React.Fragment>   ); } 동기 보통 패턴은 자식의 목록을 반환하는 컴포넌트를 위해 존재한다.  class Table extends React.Component {   render() {     return (       <table>         <tr>           <Columns />         </tr>       </table>     );   } } <Columns />는 렌더링 된 HTML이 유효하도록 여러 <td> element를 반환해야 한다. 부모 div가 <Columns />의 render() 내에서 사용 된 경우 결과의 HTML은 유효하지 않다. class Columns extends React.Component {   render() {     return (       ...

개요 고차 컴포넌트는 리액트의 재사용 컴포넌트 로직의 고급 기술이다. 고차 컴포넌트는 리액트 API는 아니다. 고차 컴포넌트는 구성상의 자연으로부터 탄생한 패턴이다. Concretely, 고차 컴포넌트는 컴포넌트를 받아 새 컴포넌트를 반환하는 함수이다. const EnhancedComponent = higherOrderComponent(WrappedComponent);  component가 UI로 props을 변환하는 반면, 고차 component는 component를 다른 component로 변환한다. HOC는 Redux의 connect 및 Relay의 createFragmentContainer와 같은 써드 파티 React 라이브러리에서 일반적으로 사용된다. 이 문서에서는 고차 component가 유용한 이유와 직접 component를 작성하는 방법에 대해 설명한다. Use HOCs For Cross-Cutting Concerns 컴포넌트는 React에서 코드 재사용의 기본 단위이다. 그러나 일부 패턴은 기존 구성 요소에 적합하지 않다. 예를 들어, 주석 목록을 렌더링하기 위해 외부 데이터 소스를 구독하는 CommentList 컴포넌트가 있다고 가정 해보자: class CommentList extends React.Component {   constructor(props) {     super(props);     this.handleChange = this.handleChange.bind(this);     this.state = {       // "DataSource" 는 어떤 global data 소스       comments: DataSource.getComments()     };   }   componentDidMount() { ...

개요  리액트는 명명하는?! api를 제공한다. 그래서 모든 업데이트에 대한 변화에 걱정할 필요가 없다 걱정을. 이것은 어플리케이션을 쓰기 엄청 쉽게 만든다 , 그러나 그것이 어떻게 리액트에서 구현되는지 분명하지 않다. 이 문서는 리액트의 'diffing' 알고리즘으로 우리가 만든 선택지를 설명하고 그래서 컴포넌트 업데이트는 충분히 빠른 하이-퍼포먼스 앱으로써 존재하며 업데이트에 대해 예상가능하다 동기  render () 함수를 한 시점에서 React 컴포넌트의 트리를 만드는 것으로 생각할 수 있다. 다음으로,  state 또는 props 업데이트 되면 render () 함수는 다른 React  컴포넌트 트리를 반환한다. React는 가장 최근의 트리와 일치하도록 UI를 효율적으로 업데이트하는 방법을 찾아야한다.  하나의 트리를 다른 트리로 변환하기위한 최소 수의 연산을 생성하는 알고리즘 적 문제에 대한 일반적인 해결책이 있다. 그러나 최첨단 알고리즘은 O(n^3)의 복잡성을 가지며, 여기서 n은 트리의 요소 수 이다.  React에서 이것을 사용하면 1000 개의 요소를 표시하는 데 10 억 번의 조회가 필요하다. 이것은 너무 비싸다. 대신, React는 두 가지 가정에 따라 경험적 O(n) 알고리즘을 구현한다. 다른 유형의 두 element는 서로 다른 트리를 생성 개발자는 키 prop를 통해 다음 렌더에서 어떤 자식 element가 안정적인지 알 수 있 실제로 이러한 가정은 거의 모든 실제 사용 사례에 유효하다. Diffing 알고리즘  두 개의 트리를 비교할 때 React는 먼저 두 개의 루트 element를 비교한다. 동작은 루트 element의 유형에 따라 다르다. elements of different types 루트 element가 다른 유형을 가질 때마다 React는 오래된 트리를 찢어 버리고 새로운 트리를...

개요  Ref forwarding은  ref를 컴포넌트를 통과해서 자식에게로 자동으로 넘기는 기술이다. 이것은 보통 필요하지 않지만 이것은 몇몇 컴포넌트에게 유용하며 특히 재사용되는 컴포넌트 라이브러리들에게 유용하다. DOM 컴포넌트에게 Forwarding refs function FancyButton(props) {   return (     <button className="FancyButton">       {props.children}     </button>   ); }  React 컴포넌트는 렌더링 된 결과를 포함하여 구현 세부 정보를 숨긴다. FancyButton을 사용하는 다른 컴포넌트는 일반적으로 내부 button DOM element에 대한 ref를 가져올 필요가 없다. 컴포넌트가 서로의 DOM 구조에 너무 많이 의존하지 않기 때문에 좋다.  그러한 encapsulation은 FeedStory나 Comment 같은 application-level components에 바람직함에도 불구하고, FancyButton 이나 MyTextInput과 같은 매우 많이 재사용될 수 있는 'leaf' 컴포넌트에 그것은 불편할 수 있다. 이러한 컴포넌트는 일반 DOM button 및 input과 비슷한 방식으로 응용 프로그램 전체에서 사용되는 경향이 있으며 DOM 노드에 액세스하면 포커스, 선택 또는 애니메이션을 관리해야한다. ref forwarding은 일부 컴포넌트가 수신 한 ref를 받아 하위 단계로 전달 (즉 전달) 할 수있는 선택 기능이다.  아래 예제에서 FancyButton은 React.forwardRef를 사용하여 전달 된 ref를 가져온 다음 렌더링 한 DOM 버튼으로 전달한다. const FancyButton = React.forwardRef((props,...

개요  Refs는 DOM 노드나 렌더 메소드로 생성된 리액트 요소에 접근할 수 있는 방법을 제공한다.  전형적인 리액트 데이터 흐름에서는, props가 부모와 자식요소간의 interact를 하기 위한 유일한 방법이다. 자식을 modify하기 위해서는 새로운 props로 re-render해야 한다. 그러나 일반적인 데이터 흐름 외부의 자식을 수정해야하는 경우가 있다. modify 되야하는 자식은 리액트 컴포넌트의 instance일 수 있으며, 혹은 DOM element일 수 있다. 이러한 2 케이스를 위해서, 리액트는 escape hatch를 제공한다. 언제 refs를 사용하는가  몇몇 좋은 refs의 사용 케이스가 있다. focus 관리, text 선택, media playback 회피 불가능한 애니메이션의 triggering 3th 파티 DOM librareis와 통합함?!  예를 들어, Dialog 컴포넌트의 open()과 close()라는 메소드를 노출하는 것 보다, isOpen prop을 넘기는 것이 있다. Refs를 남용하지 말 것  첫 번 째 경향은 ''make things happen"으로 앱 안에서 refs를 사용하는 것이다. 이 경우 잠시 시간을내어 구성 요소 계층에서 상태를 소유해야하는 위치에 대해 더 비판적으로 생각하라. 종종, 상태를 소유하기에는 더 높은 레벨의 hierarchy가 더 좋은 위치라는 것이 분명해 진다.   lifting state up 가이드를 확인해 보아라. 아니면 우리에겐 리덕스가 있다. Refs 생성  Refs는 React.createRef()로 생성되며 ref attribute를 통해 리액트 요소에 붙게 된다. refs는 보통 일시적인 property로 컴포넌트가 생성될 때 배정된다. 그래서 그들은 컴포넌트를 넘어서 reference가 될 수 있다. ...

개괄 Portals은 DOM 안으로 부모 컴포넌트의 DOM 하이어라키 밖에 존재하는 자식들을 렌더하는데 first-class 방식을 제공한다. -> 무슨 소리냐 ReactDOM.createPortal(chlid, container) 첫 번째 argument child는 렌더 가능한 리액트 자식 요소 중 아무 거나 이다. 두 번째 argument container는 DOM 요소이다. 사용 보통, 컴포넌트의 렌더 메소드를 통해 요소를 반환할 때, 요소는 제일 가까운 부모 요소의 자식과 같은 DOM의 안으로 마운트 된다. render() {   // React mounts a new div and renders the children into it   return (     <div>       {this.props.children}     </div>   ); } 그러나, 때때로 자식을 다른 위치의 DOM 안으로 넣는 것은 유용하다 render() {   // 리액트는 새로운 div를 생성하지 않는다. 이것은 'domNode'안으로 자식을 렌더한다.   // 'domNode'는 어떤 유효한 DOM node이며 DOM 안의 위치와 관계가 없다.   return ReactDOM.createPortal(     this.props.children,     domNode   ); } 포탈은 부모 컴포넌트가 overflow: hidden 이나 z-index의 스타일을 가지고 있으나 자식요소를 시각적으로 부모로 부터 'break out'하기 위할 때 전형적으로 사용한다. 예를 들어 dialogs, hovercards, tooltips가 있다. Portals의 Event Bubbling  Portal이 DOM...

 후지필름의 저가?! 렌즈 라인은 XC이다. x-mount comtemporary정도 일 거 같은데 뭐 중요한거 아니고... XC 라인의 망원을 책임지는 렌즈는 후지필름 XC 50-230mm f4.5-6.7 OIS II (이하 '50230')이다.  망원 줌은 묘한 렌즈이다. 쓸일은 별로 없는데 쓸일이 꼭 생긴다. 그리고 대부분의 망원 줌은 어느 정도 인물용 준망원 화각도 커버하기 때문에 없으면 허전하다. 그런 의미로 50230은 후지 카메라를 사용하는 사람에게는 화각을 채우는데 효과적인 솔루션이 아닌가 한다.  50230은 저가?! 라인으로 보기에는 화질이 좋은 렌즈이다. 내가 전문 리뷰어는 아니기에 정말 좋다! 준수하다! 형편없다 등의 평가는 할 수 없지만, 개인적인 경험으로는 (적어도 중앙부는) 일반 아마츄어의 입장에서 충분한 화질을 내주고 있지 않나 한다. 보통 아마츄어 사진가들은 주로 웹으로 그리고 폰이나 모니터로 사진을 즐기기 때문이기에. 물론 화질이란 너무 다양한 개념을 내포하기 때문에 굉장히 확실하지 못한 표현이다. 보다 구체적으로는 선예도 정도면 될까나?  50230은 조리개가 매우 느린 렌즈이다. 때문에 실내에서 사용하면 광량을 확보하기 힘들고, 아웃포커싱을 활용하기 힘들다. 때문에 iso/감도를 높히는 것이 두렵거나 아웃포커싱이 중요한 상황이면 사용하기 '나쁘다'. 다만 iso/감도에 의한 노이즈는 확실히 웹이나 폰같은 매체에서는 리사이즈와 보정을 통하면 꽤나 커버가 되기는 한다. 그리고 50230의 비밀?! 무기인 OIS가 있기에 iso/감도 증가에 의한 노이즈를 더 피할 수 있다. 사용해 보니 50230의 OIS가 생각보다 매우 강력하다고 느껴졌다. 작은 렌즈 사이즈라서 OIS의 성능이 충분히 보장이 되서 그런 것일까? 아무튼 이래 저래 둘러봤을 때 특별히 나무랄 것이 없는 렌즈라는 생각이 든다. 다만 아웃포커싱은... 답이 없...거기다 aps-c 판형... 으음.... 그런건 돈 많이 모...

 짜이스는 독일의 명문 렌즈/광학 기업이다. 짜이스는 미러리스 카메라 중 aps-c 센서 포맷을 위한 라인인 '뚜잇'을 가지고 있다. 뚜잇은 앵무새를 의미하는데 개인적으로는 참 좋은 작명이라고 생각한다.  짜이스 32mm f1.8 뚜잇(이하 뚜잇)을 x-pro2에 사용했었다. 35mm 포맷 환산 약 50mm 정도의 초점거리를 가지고 있다. 개인적으로 50mm 화각을 매우 좋아하기 때문에 첫 인상이 매우 마음에 들었다. 거기에다 짜이스의 파란 방패라니.  뚜잇은 분명 매력적인 렌즈이다. 손에 들어오는 작은 사이즈에 수려한 라인의 디자인. f1.8의 밝은 조리개와 준수한 보케를 가지고 있다. 즉, 화질로는 특별히 깔 것이 (분명 있겠지만 나의 기준으로는) 없다. 다만 x-mount라서 그런지는 모르겠지만 af가 조금 느린 정도? e-mount의 뚜잇은 어떠할지 모르겠다.  x-pro2 및 후지의 특장점 중 하나를 뽑으라면 필름 시뮬레이션이 있을 것이다. 필름 시대에는 필름 마다 특성이 있었는데 그러한 특성을 디지털로 시뮬레이션 하는 것이다. 나는 이러한 후지의 기능을 매우 높이 평가하고 좋아한다. 아마추어니까 ㅋ. 난 실력이 없는데 후지가 주는 필름 시뮬레이션을 사용하면 사진이 꽤 준수해 지니까 ㅋㅋㅋ. 아무튼 좋고 말고를 떠나서 뚜잇은 후지의 필름 시뮬레이션 중 흑백과 궁합이 좋다고 생각한다. 뚜잇의 표현 특징이 섬세함과 선명함이라고 본다 (비록 뚜잇이 플라나 설계라지만...). 덕분에 흑백 시뮬레이션인 아크로스, 모노크롬을 사용하면 흑백 특유의 선명함과 계조 그리고 입자감이 뚜잇의 특성과 결합해 훌륭한 결과를 낸다. 뭔가 정말 짜이스답다고 해야 할까나.  그런데... 그런데 말이다. 그닥 뭐 그렇게 마음에 들지는 않게 되더라. 분명 좋은 렌즈이다. 선예도도 보케도 발색도 분명 좋은 렌즈인데 뭔가 마음에는 들지 않았다. 뭔가 '내 렌즈'라는 생각이 들지 않더라.  '내 것'이라는 생각은 내가...