lostfind

Go 언어의 인터페이스

Sun, 14 Jul 2019 18:28:00 +0000

Go에서의 인터페이스는 메서드의 집합체로, 인터페이스를 만족하기 위해서는 위해서는 인터페이스가 갖고있는 모든 메소드를 구현 하기만 하면 된다.

단, Java의 implements와 같은 표기는 하지 않기 때문에 어떤 인터페이스를 구현 한건지 코드만 봤을땐 파악하기 힘들다는 단점이 있다.

예제

Pet이라는 구조체가 Animal과 Cat 두개의 인터페이스를 구현하는 예제이다.

인터페이스 정의

package zoo

type Animal interface {
	Walk()
}

type Cat interface {
	Cry()
}

인터페이스 구현

두 인터페이스가 정의 되어있는 zoo패키지를 import한 후, 각 메소드를 구현 한다.

package main

import (
	"fmt"
	"lostfind/playground/zoo"
)

type Pet struct {
	name string
	age  int
}

// Cat의 인터페이스 구현
func (p *Pet) Cry() {
	fmt.Println("Nya")
}

// Animal 인터페이스의 구현
func (p *Pet) Walk() {
	fmt.Println("I walk with four feet.")
}

func main() {
	// 인터페이스 변수
	var animal zoo.Animal
	var cat zoo.Cat

	myPet := &Pet{
		name: "Nyanko",
		age:  10,
	}

	// myPet은 Cat, Animal의 인터페이스를 구현 하였으므로 각 인터페이스 변수에 대입 가능
	cat = myPet
	animal = myPet

	cat.Cry() // Nya
	animal.Walk() // I walk with four feet.
}

Java에서의 표현

단순히 이해를 돕기위한 코드로 Java를 코딩 안한지 꽤 오랜 시간이 지나서 문법이 정확하지 않을 수 있다.

public interface Animal {
  public void Walk();
}

public interface Cat {
  public void Cry();
}

class Pet implements Animal, Cat {
  public void Walk() {
    System.out.println("I walk with four feet.");
  }

  public void Cry() {
    System.out.println("Nya");
  }
}

Go 언어의 메소드와 함수

Sun, 30 Jun 2019 11:28:00 +0000

함수

함수는 단순히 파라미터 리턴값을 갖는다.

func Meow(name string) {
	fmt.Printf("function: my name is %s. MEOW~\n", name)
}

메소드

메소드는 함수와 거의 동일하지만, 구조체에 붙여서 사용하며 구조체 이외에도 기본타입 이외의 어떠한 타입에든 붙여서 사용할 수 있다. 특정 구조체에 붙여 사용하기 위해서 메소드명 앞의 리시버에 구조체(혹은 타입명)를 명시한다.

type Cat struct {
	name string
	age  int
}

// Cat 구조체의 메소드 Meow
func (c Cat) Meow() {
	fmt.Printf("my name is %s. MEOW~\n", c.name)
}

func main() {
	// neco *Cat
	neco := new(Cat)
	neco.name = "neco"
	neco.age = 0

	// nabi Cat
	nabi := Cat{name: "nabi", age: 1}

	neco.Meow() // my name is neco. MEOW~
	nabi.Meow() // my name is nabi. MEOW~
}

포인터 리시버

Go 언어는 일반적으로는 값을 전달하기 때문에 메모리상에서 변수가 복제되어 전달되지만 리시버를 포인터 리시버로 정의하면 불필요한 복제를 방지하며, Call by reference와 같이 동작한다.

아래의 코드와 같이 포인터 리시버를 사용한 메소드는 Cat구조체의 필드 age의 값을 직접 수정한다.

// Cat 구조체의 메소드 AddAge (포인터 리시버)
func (c *Cat) AddAge() {
	c.age++ // 구조체의 필드를 직접 수정
}

func main() {
	// neco *Cat
	neco := new(Cat)
	neco.name = "neco"
	neco.age = 0

	// nabi Cat
	nabi := Cat{name: "nabi", age: 1}

	fmt.Println(neco.age) // 0
	fmt.Println(nabi.age) // 1

	neco.AddAge()
	nabi.AddAge()

	fmt.Println(neco.age) // 1
	fmt.Println(nabi.age) // 2
}

그렇다면, 포인터 리시버 메소드의 경우에는 구조체를 포인터형으로 생성해야 하는가? 위 코드의 경우 neco는 Go의 내장함수new()을 통해 생성했기 때문에 포인터형(*Cat)으로 생성되어 있고 nabi는 직접 생성했기 때문에 포인터가 아닌 객체(Cat)로 생성되었다.

하지만, 동일한 AddAge()메소드를 호출하면 neco, nabi 둘 다 직접 값이 수정되어 있다. 이는, 컴파일러가 암묵적으로 변환해 주기 때문에 가능한 것이다. Go매뉴얼 Calls

명시적으로 포인터형의 메소드를 호출하는 것도 가능하며, 결과는 동일하다.

	fmt.Println(neco.age) // 0
	fmt.Println(nabi.age) // 1

	neco.AddAge()
	(&nabi).AddAge() // nabi.AddAge()와 동일

	fmt.Println(neco.age) // 1
	fmt.Println(nabi.age) // 2

함수 vs 메소드

함수의 경우에는 프로그램 전체적으로 파라미터에 대해 일정한 처리를 하는 경우에 사용하고, 메소드는 객체별 기능을 구현할 때 사용하는 것이 좋다고 생각한다.

비슷한 기능이라도 구조체별로 다른 동작을 하는 경우에 메소드로 한다면 hogeSave(), fugeSave()이 아니라 객체명.Save()와 같이 이름을 짓기도 편하며 수정이 발생하는 경우에 어디까지 영향이 미치는지 범위를 파악하기도 쉬워진다.

특별한 경우가 아니라면 기본적으로 메소드로 구현하는 것이 나을 듯하다.

가계부 자산관리 모델

Fri, 03 May 2019 15:20:00 +0000

‘자산관리’의 모델 부분 개발의 현재까지 진행상황 정리

개발 과정

일단 스파게티 코드

class Account
{
  // 데이터 항목
  public $id = '';
  public $accountName = '';
  public $balance = 0;
  public $sort = 0;
  public $accountType = '';
  public $accountTypeName = '';

  function getAll()
  {
    $mysqli = new mysqli('localhost', 'dwkim', 'dwkim', 'accountbook');
    if (mysqli_connect_errno()) {
      printf("Connect failed: %s\n", mysqli_connect_error());
      exit;
    }

    $query = "쿼리생략";
    $result = mysqli_query($mysqli, $query);
    $mysqli->close();

    return $result;
  }

  function getAccount($id)
  {
    // ...생략
    if ($result) {
      $this->id = $result->id;
      // ...생략
    }
  }
}

현재 코드의 문제점

DB커넥션이 각 메소드에서 반복되며 되고 관리가 불편함
mysqli를 사용함으로 특정 DB에 의존

해결방안

DB커넥션을 Model클래스에 구현하고 각 모델에서 상속
PDO로 DB의존해소

DB연결 부분 분리

class Model
{
  public $db;

  function __construct() {
    $dbServer = 'localhost';
    $dbUser = 'dwkim';
    $dbPass = 'dwkim';
    $dbName = 'accountbook';

    $dsn = "mysql:host={$dbServer};dbname={$dbName};charset=utf8";

    try {
      $this->db = new PDO($dsn, $dbUser, $dbPass);
    } catch (PDOException $e) {
      echo '접속실패' . h($e->getMessage());
    }
  }
}

class Account extends Model
{
  // ...생략
  function getAll()
  {
    $sql = "쿼리생략";
    $prepare = $this->db->prepare($sql);
    $prepare->execute();
    $result = $prepare->fetchAll(PDO::FETCH_ASSOC);

    return $result;
  }
}

현재 코드의 문제점

전체 레코드를 조회하는 getAll()메소드는 데이터 항목 변수를 사용하지 못함
한 레코드 조회용 getAccount()와 getALL()이 반환하는 형식이 달라 컨트롤러에서 각각 대응이 필요

해결방안

데이터 객체를 별로도 작성하여 컨트롤러와는 데이터 객체를 통해 데이터를 주고 받는다

데이터 객체 생성

테이블 구조와 거의 동일한 데이터 클래스 AccountData 작성

class AccountData
{
  public $id = '';
  public $accountName = '';
  public $balance = 0;
  public $sort = 0;
  public $accountType = '';
  public $accountTypeName = '';

  function __construct($data = array())
  {
    foreach ($data as $key => $value) {
      switch ($key) {
        case 'id':
          $this->id = $data[$key];
          break;
        case 'account_name':
        case 'accountName':
          $this->accountName = $data[$key];
          break;
        case 'balance':
          $this->balance = $data[$key];
          break;
        case 'sort':
          $this->sort = $data[$key];
          break;
        case 'account_type':
        case 'accountType':
          $this->accountType = $data[$key];
          break;
        case 'account_type_nm':
        case 'accountTypeName':
          $this->accountTypeName = $data[$key];
          break;
      }
    }
  }
}

class Account extends Model
{
  // ...생략
  function getAll()
  {
    $sql = "쿼리생략";
    $prepare = $this->db->prepare($sql);
    $prepare->execute();
    $result = $prepare->fetchAll(PDO::FETCH_ASSOC);

    $accounts = array();

    foreach ($result as $row) {
      $account = new AccountData($row);
      $accounts[] = $account;
    }

    return $accounts;
  }

  function getAccount($id)
  {
    $sql = "쿼리생략";
    $prepare = $this->db->prepare($sql);
    $prepare->bindValue(':id', $id, PDO::PARAM_INT);
    $prepare->execute();
    $result = $prepare->fetch(PDO::FETCH_ASSOC|PDO::FETCH_UNIQUE);

    $account = new AccountData($result);

    return $account;
  }
  // ...생략
}

남은 과제

DB커넥션에 대한 정보가 Model에서 Config로 옮기기
- (Model에 있는 것보다 Config에서 관리하는게 타당할 경우)
데이터객체의 get, set기능
- DB의 스네이크 표기법과 컨트롤러, 뷰의 카멜 표기법 자동 매칭 account_name ↔ accountName

개인용 가계부 시스템 개발

Wed, 01 May 2019 18:17:00 +0000

아이폰으로 넘어온 후로 지금껏 안드로이드에서 사용중이던 가계부 어플을 계속해서 사용할 수 없게 되었다.

웹, 어플과도 연동 되는 Moneytree등 좋은 서비스들이 많이 있지만, 몇년간 사용하며 쌓아온 데이터를 버리기도 아깝고, 카테고리 관리등 내가 원하는 방식과는 좀 달랐기 때문에 지속적인 사용으로 연결되지 않는 문제가 있었다.

그런 이유로 내가 사용 할 가계부 시스템을 만들기로 했으며, 진행과정과 시행착오, 변경점 등을 기록해 나가고자 한다.

구현할 기능

카테고리
- 상위, 하위 카테고리 기능
자산관리
- 현금 / 통장 / 전자머니
- 은행, 전자머니 회사에서 제공하는 API로 내역 동기화
예산관리
- 카테고리별 고정지출
- 카테고리별 고정수입
신용카드 관리
- 사용기간 / 결제일
데빗카드 관리
- 연결 계좌 설정
이력, 통계
주식매매 기록
부가기능 (혹은 필수적인)
- 보안을 위한 최소한의 기능
- 로그인 기능 (유저별)

개발환경

PHP 7.3.4
mysql 8.0.15
Apache/2.4.34
MVC라우터 https://github.com/pokeb/php-mvc-router

MVC라우터에 대해

프레임워크 없이 모든 기능을 구현 하려 했으나, 라우터 기능을 레일즈처럼 간단하게 사용하기 위해 직접 구현하려고 하니 가계부 시스템 개발과는 다른 방향으로 공부가 필요 한 것 같아서 github에서 가벼운 MVC 라우터를 찾아서 사용하게 되었다.

설계

데이터 설계

m_code- 각종 타입, 구분등을 공통으로 관리
m_account - 자산 구분과 잔액 관리
m_category - 수입, 지출에 대한 카테고리
수정 / 추가가 필요한 부분
- 신용카드 사용기간, 결제일
- 예산관리
- 주식매매 관련

라우트

$GLOBALS['routes'] = array(
  '/' => '/DepositHistory',
  '/deposits' => 'DepositHistory',
  '/deposits/detail/(deposit)' => 'DepositHistory:action',
  '/deposits/income' => 'DepositHistory:income',
  '/deposits/outgo' => 'DepositHistory:income',
  '/categories' => 'Category',
  '/categories/:kind' => 'Category:index',
  '/categories/detail/(category)' => 'Category:action',
  '/accounts' => 'Account',
  '/accounts/new' => 'Account:new',
  '/accounts/:id' => 'Account:detail',
);

디렉토리 구조

MVC라우터 php-mvc-router가 제공하는 기본적인 디렉토리 구조를 따른다.

accountbbok/
├ common/autoload.php
├ config/
│　├ config.php
│　└ routes.php
├ helpers/
│　├ Router.php
│　└ utility.php
├ htdocs/
│　├ .htaccess
│　├ 404.php
│　└ index.php
├ controllers/
│　└ 컨트롤러 클래스
├ models/
│　└ 모델 관련 클래스
├ views/
│　├ accounts/
│　└ categories/
│　└ deposits/
└ bootstrap.php

화면 설계

간단한 HTML을 이용하여 형편없는 디자인으로 일단 구현 할 예정이다.

MVC모델로 잘 구현이 되었다면 뷰에 관련된 변경은 최종적으로 진행 하여도 설계, 내부 코드 수정은 없어야 한다고 믿고 있으며, 그렇게 진행 하고자 한다.

정리

개발에 착수 한지는 3개월가량 지났지만 프레임워크를 사용할지 말지에 대한 고민과 php-MVC라우터에 대한 이해 없이 내역(deposits), 카테고리(categories)의 컨트롤러와 모델을 개발 하며 같은 곳을 여러번 수정하는 바람에 아무런 진척이 없는 상태에서, 클린아키텍처 설계까지 도입 하고 싶은 욕심이 강해 더더욱 진행이 되지 않는 상태였다.

소스가 지저분하게 되더라도 일단 구현을 하며 문제점을 파악 한 후 리팩토링으로 클린 아키택쳐가 되도록 진행하고자는 결론에 도달했다.

전체적인 계획

PHP로 기능 구현 → Vue.js로 프론트 구현 → 백엔드 Go언어로 마이그레이션

소프트웨어 설계 원칙 : SOLID

Sun, 07 Apr 2019 14:53:00 +0000

Clean Architecture를 읽고 있는 중, SOLID 원칙에 대해 일단 간단하게 정리 해 두려고 한다.

SOLID 원칙이란, 로버트 마틴(엉클밥)이 객체지향 설계에서 지켜야 할 5가지 기본 원칙이다.

변경에 강하고
이해하기 쉬우며
컴포넌트 기반으로서, 많은 소프웨어 시스템에서 사용 되는 것

위 세가지의 성질을 가진 중간레벨 소프트웨어를 만드는 것이 목적이다.

예제를 포함해 상세한 부분은 각 원칙별 별도 포스트로 정리할 예정이다.

단일 책임 원칙 (Single Responsibility Principle)의 정의

모듈을 변경하는 이유는 단 하나여야만 한다.

처음에 이걸 봤을 땐 “어차피 변경하는 이유는 한가지 아닌가?” 라고 생각했기 때문에 애매모호하며 무엇이 중요한지 이해하기가 쉽지 않았다.

변경하려는 이유에 관점을 두는 것이 아니라, 변경하는 이유를 만드는 주체(액터) 에 관점을 두는 것이 중요했다. 액터는 같은 목적을 가지고 그 기능을 사용하는 대상을 뜻한다.

한 액터만이 유일한 변경의 원천이어야만 하며, 액터가 서로 다른 코드는 분리해야만 한다.

개방 폐쇄 원칙 (OCP : Open-Closed Principle)

소프트웨어의 구성요소는 확장에 대해 열려있고, 수정에 대해선 닫혀 있어야 한다.

확장에 대한 Open : 요구사항의 변경에 맞게 모듈을 확장 가능해야 한다.
수정에 대한 Closed : 기능의 확장을 할 때 기존 코드의 수정은 없어야 한다.

바꿔 말하면, 기존의 동작은 수정없이 유지하며 추가 기능을 확장할 수 있어야 한다. 예를 들어, 화면 출력 방식 변경/추가를 할 떄, 비즈니스 로직이나 데이터 저장 등의 기존 기능의 수정이 없이 이루어져야 한다.

리스코브 치환원칙 (LSP : Liskov Substitution Principle)

자식 클래스를 부모 클래스의 자리에 넣어도 문제 없이 작동 해야 한다.

프로그램의 실행에는 영향을 주지 않으면서 기본 클래스의 참조를 파생클래스의 참조로 변경할 수 있어야 한다.

class Car {
  // ...
}

class Porsche extends Car {
  // ...
}

Porsche p = new Porsche();
Car car = (Car)p;

위와 같이 부모 클래스로 업캐스팅 해도 동작에는 문제가 발생하지 않아야 한다.

인터페이스 분리 원칙 (ISP：Interface Segregation Principle)

직접 필요로 하지 않는 모듈을 의존하지 않는 것으로, 예상치 못한 문제의 발생을 억제 한다.

자신이 필요로 하지 않는 메소드에는 의존하지 않아야 한다. 그렇지 않은경우, 참조하고 있는 클래스에 필요로 하지 않는 메소드의 수정으로 인해 재컴파일, 재배포가 발생한다.

이는 정적 언어에만 해당 하는 경우이지만, 아키텍처 레벨에도 ISP의 근본적인 사상을 적용 하는 것이 문제 발생을 억제 할 수 있다.

의존관계 역전 원칙 (DIP：Dependency Inversion Principle)

추상화 된 것을 참조, 상속 (의존) 해야 한다.
구체 클래스가 추상 클래스를 의존해야 한다.

가장 유연한 시스템은 소스의 의존관계가 인터페이스만을 참조하고 있는 경우이다.

SOLID는 객체지향에만 적용 되는가?

SOLID 원칙에 대해서 찾아보면 ‘객체지향’이라는 단어가 항상 붙어 나와서, 객체지향에서만 적용되는 원칙같아 보이지만 꼭 그렇지만은 않다.

Clean Architecture에서 엉클밥은 어떠한 소프트웨어 시스템이라도 OOP의 클래스처럼 몇가지의 기능과 데이터를 모아 두는 구조가 있을 것이며, SOLID는 그런 구조에 적용하는 원칙이라고 말한다.

마무리

개념의 타이틀 수준으로만 정리 했지만, 예를 들어가며 설명하기에는 아직 이해가 많이 부족하며, 역시 간단하게 정리가 될 만큼 쉬운내용은 아니란걸 깨달았다.

각 원칙에 대해 예를 들어가며 설명이 될 정도로 공부해서 재 포스팅을 할 예정이다.

[엔지니어의 지적생산기술]을 읽고 난 정리

Sun, 24 Mar 2019 15:48:00 +0000

엔지니어의 지적생산기술이라는 책을 읽고 감상을 정리해둡니다.

エンジニアの知的生産術

읽어보면 당연한 말을 하는 것 같지만, 의외로 평소에 크게 생각하지 않으며 지냈다는 것을 깨달았다.

저자도 여러 가지 방법론을 익혀서 실천해 본 후 자신에 맞는 방법을 만들어 낸 것 같다. 나도 일단 실천해 보고 판단하여 개선해 나갈 계획이다.

1장 새로운 것을 배우려면

정보수집
- 우선은 대략 전체 구조를 파악한다. 그게 안 된다면 닥치는 대로 수집.
추상화, 모델화
- 수집한 정보에서 패턴을 발견해 추상화, 모델화를 진행한다.
배운 것을 실천, 검증함으로 직접적인 경험이 된다.
- 프로그램이라면 직접 작성해봄으로 검증 가능.
- 블로그나 타인에게 대한 설명으로 자신의 이해도가 부족하지 않은지 무엇을 더 보충해야 하는지 알게 된다.
위의 3가지를 반복한다.

2장 의욕을 내려면

지금 하려는 작업 한 개만 선택한다. 여러 개를 처리하려고 하면 의욕이 나기 어렵다.
Getting Things Done 일단 할 일을 모두 한곳에 모아 전체를 파악한 후, 하나씩 처리해 나간다.
긴급함이 아니라 중요함을 우선으로 작업을 선택한다.
- 단, 우선순위를 반드시 지정할 필요는 없다. 그 자체도 공수가 많이 들기 때문
- “성공하는 사람들의 7가지 습관”의 습관3
작업을 하나만 선택해도 그 자체가 너무 크면 의욕이 사라진다.
- 작업 하나가 너무 큰 경우(2시간 이상) 업무를 더 작은 단위로 나누기
- 작업 처리 견적을 제대로 잡기 위해 자신의 처리 능력을 파악해둔다.

3장 기억을 단련시키려면

반복 학습과 아웃풋을 통해 기억을 단련한다.
SuperMemo등 여러 공부 방법을(암기법?) 소개했지만 중요한 건 역시 반복과 아웃풋을 통해 이해도를 높여 가는 것.

4장 효율적으로 읽으려면

1페이지 2초 이하의 속도로 전체 내용을 대략 읽어 정보를 발견한다.
1페이지 3분 이상의 속도로 머릿속에서 정보를 조립하여 이해한다.
습득한 정보나 지식을 다른 사람을 가르치기 위한 자료를 작성한다.
- 실제로 가르치지 않더라도 자료 작성으로 복습, 기억 강화 효과가 발생

5장 생각을 정리하려면

생각이 정리 안 되는 이유는 정보량이 너무 많거나 혹은 너무 적거나.
정보량이 적은지 많은지 확인하는 방법
- 수단어 ~ 한문장 정도로 관련 정보 100개 정도 작성 가능한지를 기준으로 잡는다. 내용의 질이나 중복은 생각하지 않는다.
정보가 많을 경우 관계성을 파악해나가며 그룹화한다.
- 그룹을 미리 정해 두지 않는다. 미리 정해 두면 새로운 발견이나 관계성 파악에 방해가 될 뿐이다.

6장 아이디어를 생각해내려면

경작, 발아, 성장시키기 단계로 진행한다.
- 경작 : 정보수집
- 발아 : 관계발견, 추상화, 모델화, 정보의 결합
- 성장 : 아이디어의 언어화, 구체화
아이디어는 주관적으로 기존의 틀을 깨, 보수적인 판단에서 벗어난다.
생각해 낸 아이디어를 예를 들 수 있는 언어화, 구체화해나간다.
아이디어를 실체화해 나갈 때는 타인의 시점이 매우 중요하다.
아이디어가 발아될 때까지 정보 수집을 계속해 나간다.

7장 무엇을 배울지 정하려면

무엇을 배울지 고민만 하면 아무런 결과가 발생하지 않는다. 일단 배워보고 방향성이 맞았는지 틀렸는지 판단한다.
지식의 양이 조금 줄어들더라도 분야를 넓게 하여 여러 사람과 커뮤니케이션이 가능하도록 한다. 커뮤니케이션, 연결고리 역할을 통해 지식의 양이 늘어간다.

PHP 세션관리

Sun, 03 Mar 2019 16:37:00 +0000

웹 개발자로서 기본적으로 알고 있어야 할 지식이지만, 남에게 확신을 가지고 설명 할 수 없는 상태였기 때문에 공부 한 후 정리 해둔다.

PHP에서 세션

프레임 워크를 없이 순수 PHP에서의 세션 관리를 위한 방법.

세션의 시작, 재개

# 각 페이지의 스크립트 최상단에서 호출 해야 한다.
session_start();

세션의 종료

session_destroy();만으로는 슈퍼전역변수 $_SESSION과 세션쿠키를 해제하지 않기 때문에 세션 파괴 전에 처리 해야 할 필요가 있다.

# session_destroy를 호출하기 전에 세션을 재개
session_start();

# 세션 글로벌 변수를 초기화
$_SESSION = array();

# 세션ID를 보관 하고 있는 쿠키 삭제
if (isset($_COOKIE[session_name()])) {
  setcookie(session_name(), '', time() - 3600, '/');
}

# 현재 세션에 관련된 모든 데이터를 파괴.
session_destroy();

샘플코드

<?php
  session_start();

  if (!isset($_SESSION['count'])) {
    $_SESSION['count'] = 0;
  }
  if (!isset($_SESSION['createTime'])) {
    $_SESSION['createTime'] = date("Y/m/d H:i:s");
  }
?>

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8"/>
    <title>PLAYGROUND</title>
  </head>
  <body>
    <div>
      세션ID : <?= session_id() ?>
    </div>
    <div>
      액세스 수 : <?= $_SESSION['count']++ ?>
    </div>
    <div>
      세션생성일시 : <?= $_SESSION['createTime'] ?>
    </div>
    <hr>
    <div>
      <a href="session_check.php">세션유지확인</a>
      <a href="session_destroy.php">세션파괴</a>
    </div>
  </body>
</html>

<?php
session_start();
?>

<div>
  세션 ID : <?= session_id() ?>
</div>
<div>
  세션생성일시 : <?= $_SESSION['createTime'] ?>
</div>
<hr>
<div>
  <a href="session_start.php">세션생성</a>
  <a href="session_destroy.php">세션파괴</a>
</div>

<?php
session_start();

echo "파괴 전의 세션 내용<br>";
print_r($_SESSION);
$_SESSION = array();

if (isset($_COOKIE[session_name()])) {
  setcookie(session_name(), '', time() - 3600, '/');
}
session_destroy();

echo "<hr>세션 파괴 후<br>";
print_r($_SESSION);
?>
<hr>
<div>
  <a href="session_start.php">세션생성</a>
</div>

세션이란

동적 웹 프로그래밍에서 필수적인 요소이다. HTTP 프로토콜은 상태를 저장 할 수 없는 일회성인 요청과 응답만이 있는 프로토콜이기 때문에, 웹 서버와 클라이언트 간의 상태를 유지시켜 지속적인 통신을 하기 위해 쿠키나 세션을 사용한다.

그 중 세션은 사용자의 요청에 대한 정보를 세션 아이디를 부여한 후 웹 서버에 저장하고, 세션 아이디를 사용자의 쿠키에 저장하여 HTTP 요청 시 쿠키에 저장된 ID로 사용자의 세션을 판단한다.

동일한 도메인을 가진 경우 웹 브라우저에서는 세션이 공유 되지만, 타 브라우저 혹은 시크릿 모드와는 기본적으로 세션 공유가 되지 않는다.

참고

PHP 매뉴얼

Docker로 Rails, MySQL개발 환경 설정

Sun, 03 Feb 2019 20:35:00 +0000

Docker에서 Rails로 웹개발을 하기 위해 세팅했던 내용들

FROM mysql:5.7.25
RUN apt-get update && apt-get install -y apt-utils locales && \
    rm -rf /var/lib/apt/lists/* && echo "ja_JP.UTF8 UTF-8" > /etc/locale.gen && \
    locale-gen ja_JP.UTF-8
ENV LC_ALL ja_JP.UTF-8
ADD ./docker/mysql/my.cnf /etc/my.cnf

FROM ruby:2.6.1
ENV LANG C.UTF-8

#for MySQL
RUN apt-get update -qq && apt-get install -y apt-utils \
      build-essential libpq-dev nodejs mysql-client

RUN gem install bundler

WORKDIR /tmp
ADD Gemfile Gemfile
ADD Gemfile.lock Gemfile.lock
RUN bundle install

ENV APP_HOME /accountbook
RUN mkdir -p $APP_HOME
WORKDIR $APP_HOME
ADD . $APP_HOME

version: '2'
services:
  datastore:
    image: busybox
    volumes:
      - /share
      - ./docker/mysql/volumes:/var/lib/mysql
  server:
    build:
      context: .
      dockerfile: ./docker/nginx/Dockerfile
    ports:
      - '8090:80'
    volumes_from:
      - datastore
    depends_on:
      - datastore
  web:
    build:
      context: .
      dockerfile: ./docker/ruby/Dockerfile
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    ports:
      - '3600:3000'
    volumes:
      - .:/accountbook
    environment:
      RAILS_ENV: development
    volumes_from:
      - datastore
    depends_on:
      - db
    links:
      - db
      - db:database
      - db:mysql
    extends:
      file: ./docker/mysql/password.yml
      service: password
  db:
    build:
      context: .
      dockerfile: ./docker/mysql/Dockerfile
    ports:
      - '3606:3306'
    volumes_from:
      - datastore
    depends_on:
      - datastore
    extends:
      file: ./docker/mysql/password.yml
      service: password

레일즈 초기 설정

$ docker-compose run --rm web rails new . --force --database=mysql --skip-bundle

DB 초기설정 (레일즈 이용)

$ docker-compose run --rm web bundle exec rake db:create

트러블

레일즈가 제대로 시작되지 않을 때

$ rm tmp/pids/server.pid

docker-compose 관련 명령어

# 중지
$ docker-compose down

# 실행
$ docker-compose up

# 실행 (데몬, 백그라운드)
$ docker-compose up

# 현재 상태 확인
$ docker-compose ps