2일
리디북스에서 무료로 60일 대여를 해서 대여한 책이다.
일단 한국 소설이고, 표지에서 보듯이 2015 대한미국 전자 출판대상 대상 수상작이다.
소재 자체가 신선한 소재라서, 기대를 많이 하고 봤다. 주인공 자체는 교통 사고로 부모님을 모두 잃고, 다른 사람의 생명의 남은 날짜를 볼 수 있는 능력을 얻었다. 이 빽넘버에 대한 얘기이다.
자기 자신의 생명은 볼 수 없다. (등 뒤에 눈이 달리지 않았으므로)
사신과의 만남도 있고.. 여러가지 위험도 감지할 수 있다. 갑자기 빽넘버가 1로 변하는 사람들을 보고, 위험을 판단한다..
마지막에 약간의 반전도 있었다.
조금은 책 자체의 분량이 짧지 않나라는 생각이 들긴 했다.
어쨋든 가볍게 읽을만했다.
킬림 타임용으로 볼만 했다.
4/5
3주
예전에 한번 읽었던 적이 있었는데, 개정판이 새로 나왔다고 하여 이북으로 구매 후 출퇴근 길에 가볍게 읽을 목적으로 구매 하였다.
책 자체에 대한 평가가 상당히 좋고, 책의 저자분도 상당히 유명한 분이라 기대하면서 읽었다.
총 4장의 목차로 이루어져 있으며, 다양한 알고리즘에 대해 설명해 준다.
책 자체에 대해서 얻을 수 있는 부분은 얼마 없는 것 같다.
끝에서 다루는 알고리즘의 난이도는 누워서 읽기에는 상당히 어렵지 않나?라는 생각을 했다.
분명히 몇가지 유용한 부분도 있고, 흥미 있는 부분도 존재하긴 한다.
하지만 그렇게 추천은 하지 못하겠다.
나에게는 별로 였다.
3/5
1달 (상당히 오래 걸렸다.)
책 제목 그대로..
예전에 읽었을 때, 좋은 기억이 있어서 구입해서 읽게 된 책.
Ebook으로 구매하여, 출 퇴근 길에 읽었다.
436페이지 분량의 책인데 상당히 읽는데 고생을 했다.
중간 중간 삽화들이 있는데, 이게 개그인지 정말로 얘기하는 건지 헷갈리는 것들도 있었다. 사실 그렇게 좋은 평을 줄 수는 없을 것 같다.
나중에 정말 시간날때 곰곰히 생각하면서 읽어야 될 책인것 같다.
생각보다 무거운 책이다.
개인적으로는 부록으로 들어간 국내 개발자들의 이야기가 더 흥미 있었다.
나중에는 한번에 읽어봐야겠다..
다시 읽어보니, 생각보다 별로..
3/5
유니티 IDE 선택에 대한 잡소리 입니다.
윈도우 환경에서는 두말 할 것 없이 visual stduio 쓰시면 됩니다. 모두가 인정하는 최고의 ide 입니다.
맥에서의 유니티 IDE 선택에 대한 이야기 입니다.
사실 초창기에는 어쩔 수 없이 mono IDE를 쓸 수 밖에 없었습니다.
일단 기본적으로 mono의 경우 맥에서는 한글 입력이 되지 않는 현상이 존재하며, 초창기 mono의 경우 화면 분할 또한 가능하지 않았습니다. 이러한 문제들 때문에 서브라임 텍스트를 사용한다던가 윈도우 환경을 가상 머신으로 돌려 비쥬얼 스튜디오를 사용하시는 분들도 계셨습니다.
사실은 제가 가장 추천해주고 싶은 ide는 visual stduio code 입니다. (ide라기 보다는 텍스트 에디터이지만..)
일단 가볍고, 자동 완성 기능 또한 준수하고, 디버깅 기능또한 제공되기 때문에 사실 제가 볼때는 가장 괜찮은 선택일 것 같습니다.
사실 맥에서 나온 visual stduio의 경우 자마린 기반이라. 제가 처음에 생각했던 멋진 모습의 ide가 아니라 실망을 많이 했던 기억이 있습니다.
그이외에 추천하는 툴은 젯브레인사의 Rider입니다.
일단 기본적으로 젯브레인사의 모든 ide는 유료 입니다.
트라이얼 버전이나 학생의 경우는 무료로 사용할 수 있으니 그 기간동안 관련 ide를 사용해 보시고 괜찮으시면 사용해 보는 것도 좋은 선택 인 것 같습니다.
가장 큰 장점은 제가 보기엔 크로스 플랫폼 지원인 것 같습니다.
윈도우와 맥에서 같은 환경에서 같은 ide로 작업하는 것 자체가 큰 메리트로 다가 왔습니다.
그리고 젯브레인사의 제품답게 리팩토링 관련 기능들이 강력한 것 같습니다.
또한 유저의 편의성을 생각하는 ide의 기능들이 눈에 띄었습니다.
예를들어 유니티 자체 함수의 경우 옆에 유니티 아이콘으로 표시해 주는 점.
또한 제일 신기했던 부분은 인보크나 스타트 코루틴에 스트링으로 함수를 호출해주는 부분이 있는데 그 부분 조차 리팩토링을 지원해 줘서 이름을 바꿀 수 있다는 점입니다.
어쨌든 저도 무료 기간동안은 계속해서 사용할 예정이고, 만족하면서 사용 중입니다.
한번 쯤 맥 환경에서 ide를 고민하시는 분들은 사용해 보시는 것을 추천 드립니다.
참조
포프님이 올리신 C# 코딩 스탠다드의 번역 글입니다.
번역 자체는 구글 번역에서 이상한 부분은 제가 수정 하였습니다. 번역 자체의 문제가 있을 수 있습니다.
코딩 스탠다드는 코드 몽키 레벨에서는 왜 이렇게 작성했는지에 대한 설명을 할 필요도 없고 그냥 코딩 스탠다드에 주어진 내용 대로 코드를 짜면 된다고 합니다.
하지만 아래 45가지의 코딩 스탠다드에는 분명히 그렇게 해야 되는 이유가 존재 합니다.
꼭 아래의 코딩 스탠다드를 사용하여 코드를 작성하실 필요는 없습니다.
이 코딩 스탠다드는 이러한 코딩 표준에 의해 영감을 받는다.
class SomeClass;
struct SomeStruct;
void SomeMethod(int someParameter)
{
int someNumber;
}
public uint GetAge()
{
// function implementation...
}
public uint GetAge()
{
// function implementation...
}
Private uint GetAgeInternal()
{
// function implementation...
}
const int SOME_CONSTANT = 1;
namespace System.Graphics
bool bFired; // for local variable
Private bool mbFired; // for private class member variable
Public bool IsFired { get; private set; }
interface ISomeInterface
{
}
public enum EDirection
{
North,
South
}
Public class Employee
{
public int DepartmentID { get; set; }
private int mAge;
}
public uint GetAge();
public int ID { get; private set; }
public string HttpAddress { get; private set; }
이거 대신에:
public class Employee
{
private string mName;
public string GetName();
public string SetName(string name);
}
이렇게 사용해라:
public class Employee
{
public string Name {get; set;}
}
if (bSomething)
{
return;
}
float f = 0.5F;
switch (number)
{
case 0:
...
break;
default:
break;
}
switch (number)
{
case 0:
DoSomething();
//fallthrough
case 1:
DoFallthrough();
break;
case 2:
case 3:
DoNotFallthrough();
break;
default:
break;
}
switch (type)
{
case 1:
...
break;
Default:
Debug.Fail("unknown type");
break;
}
void FibonacciRecursive();
이거 대신에:
Anim GetAnim(int index);
Anim GetAnim(string name);
이렇게 사용해라:
Anim GetAnimByIndex(int index);
Anim GetAnimByName(string name);
class Anim {}
Anim.cs
public enum EVisibilityFlags
{
}
public class SomeClass
{
public int Count {get;set;}
public void Func(int Count)
{
for (int count = 0; count != 10; ++count)
{
// Use Count
}
}
}
public string GetNameOrNull();
a. 오브젝트가 한 곳에서만 작성된 경우. (예를 들어, 1 회의 DTO)
b. 객체가 소유 클래스의 정적 메서드 내에서 만들어 질 때 (예 : 팩토리 패턴)
5일
게임 프로그래밍 패턴
책 이름 그대로 패턴에 대한 공부를 하기 위해 구입
먼저 게임 관련된 패턴책이라 무조건 구입을 했다.
이 책에서도 여러가지 패턴에 대한 설명을 한다.
그리고 게임 관련되서 많이 쓰일 법한 패턴들에 대한 설명을 해준다.
출퇴근 중에 읽은 서적이라 자세히 정리하지 못한 점은 아쉽다.
일단 몇가지 접해보지 못한 패턴들에 대해 알게 되었다.
몇가지 패턴들은 이미 알고 있는 패턴들이라 이해하기 쉬웠고, 몇 개의 패턴들에 대해서는 이해하기 좀 어려운 부분도 있었다.
추후에 이 책에 대해 정리 해봐야 될 것 같다.
GOF 디자인 패턴이나 헤드 퍼스트 디자인 패턴을 읽고 다시 한번 읽어봐야 될 책.
4 / 5
패턴과 객체지향적으로 코딩하는 방법에 대한 책
5일
대학교 때 구매했던 서적.
패턴과 객체지향에 대해 관심이 있어 구매 함.
책 자체는 쉽게 읽을 수 있는 책이다.
처음에는 객체 지향적 사고 방식으로 생각하는 방법에 대해 설명 해준다.
저자는 2가지 방식을 중요시 한다.
이 2가지만 알면 객체지향적 사고와 패턴의 원리를 모두 알 수 있다고 말한다.
아래에 대한 패턴에 대해 설명 해준다.
실무에서 사용할 만한 간단한 코드와 설명으로 수필 읽듯이 읽을 수 있는 장점이 있는 책이다.
하지만 자세한 소스 코드 까지는 나오지 않아, 가볍게 읽을 만한 책으로 느껴진다.
이 책을 읽고 이후 디자인 패턴에 대해 자세히 공부하려면, GOF의 디자인 패턴이나 Head First 디자인 패턴 책을 펴서 공부를 하면 좋을 듯 싶다.
설계 관련 간단히 읽을 수 있어 추천해 주고 싶은 책.
4 / 5
안나와 브라이언이 식당에서 주문한 물건들 n 그러나 안나는 알레르기로 인해 먹는 것을 거부합니다. k개의 아이템을
수표가 오면, 그들은 그들이 공유하는 모든 항목의 비용을 나누기로 결정합니다.
그러나 브라이언은 항목을 분리하지 않고 실수로 안나에게 청구했음을 잊어 버렸을 수 있습니다.
당신은 각 아이템의 비용과 브라이언이 계산서의 일부분에 대한 안나에게 청구 한 총 금액을 받습니다.
청구서가 상당히 분할되면 Bon Appetit을 인쇄하십시오. 그렇지 않으면 브라이언이 안나에게 환불해야하는 금액을 인쇄하십시오.
첫번째 인자는 아이템의 개수이고 두번째 인자는 안나가 먹지 못하는 음식의 인덱스 값 이다.
두번째 라인의 첫번째 줄에서 첫번째 인자로 받은 인덱스는 각 음식의 값들이고.
세번째 라인은 브라이언이 안나에게 청구한 금액이다.
Sample Input 0
4 1
3 10 2 9
12
Sample Output 0
5
안나는 c[1] = 10을 먹지 못한다.
총 비용은 3+2+9=14이다. 그녀의 비용을 사람 수로 나누면 7이다.
브라이언은 그녀에게 12달러를 청구하였고, 그녀는 7달러면 내면 된다.
그러므로 우리는 안나에게 과다 청구된 금액을 출력하면 된다 12-7=5이다.
Sample Input 1
4 1
3 10 2 9
7
Sample Output 1
Bon Appetit
정확하게 안나가 청구될 금액과 일치 하므로 Bon Appetit을 출력한다.
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
class Solution {
static int bonAppetit(int n, int k, int b, int[] ar) {
// Complete this function
int sum = 0;
for (int i = 0; i < n; i++)
{
if (k == i)
{
continue;
}
sum += ar[i];
}
int charge = sum / 2;
return b - charge;
}
static void Main(String[] args) {
string[] tokens_n = Console.ReadLine().Split(' ');
int n = Convert.ToInt32(tokens_n[0]);
int k = Convert.ToInt32(tokens_n[1]);
string[] ar_temp = Console.ReadLine().Split(' ');
int[] ar = Array.ConvertAll(ar_temp,Int32.Parse);
int b = Convert.ToInt32(Console.ReadLine());
int result = bonAppetit(n, k, b, ar);
if (result == 0)
{
Console.WriteLine("Bon Appetit");
}
else
{
Console.WriteLine(result);
}
}
}
linq를 사용하여 풀었다.
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
class Solution {
static void Main(String[] args) {
int K = Console.ReadLine().Split(' ').Select(Int32.Parse).ToArray()[1];
List<int> ItemList = Console.ReadLine().Split(' ').Select(Int32.Parse).ToList();
long CorrectTotal = (ItemList.Sum(m => m) - ItemList[K]) / 2;
long AmountCharged = Convert.ToUInt32(Console.ReadLine());
if (CorrectTotal == AmountCharged)
Console.WriteLine("Bon Appetit");
else {
Console.WriteLine(AmountCharged - CorrectTotal);
}
}
}
알고리즘 문제들을 풀다보면 c#의 경우 linq를 사용하면 쉽게 풀 수 있는 것들이 많다.
사실 linq의 사용을 의도적으로 피한 경향이 있었다.1
하지만 linq관련 문제는 여러가지 방법으로 우회 방법이 존재하며, 이제는 슬슬 적용을 할 단계인것 같습니다.
마린은 타임머신을 발명했으며 시간 여행을 통해 1700~2700년 사이의 프로그래머의날1 (일년중 256th)에 방문하려고 한다.
1700년에서 1917년에는 러시아에서의 공식 달력은 줄리안 달력이고, 1919년에는 그레고릭 달력 시스템이었다.
1918년에 줄리안 달력에서 그레고릭 달력으로 변경이 일어났고, 1월 31일 이후 다음날 2월 14일 변경이 됐다.
이 말은 러시아에서 1918년에는 2월 14일은 1월 32일 이었다. (중간에 14일은 간의 기간은 달력 변경으로 삭제)
두 가지 달력 시스템에서 2 월은 가변 일수가있는 유일한 달입니다.
윤년 기간에는 29 일, 그 외 모든 연도에는 28 일이 있습니다
줄리아 달력에서 윤년은 4로 나눌 수 있습니다. 그레고리력에서 윤년은 다음 중 하나입니다.
1년을 감안할 때 그 해의 공식 러시아 달력에 따라 해당 연도의 날짜를 찾으십시오.
그런 다음 dd.mm.yyyy 형식으로 인쇄하십시오. 여기서 dd는 두 자리 날이고 mm은 두 자리 월이며 yyyy는 y입니다.
Sample Input 0
2017
Sample Output 0
13.09.2017
2017년은 1월은 31일, 2월은 28일, 3월은 31일, 4월은 30일 ,5월은 31일, 6월은 30일, 7월은 31일, 8월은 31일이다. 31+28+31+30+31+30+31+30+31+31 = 243이다. 프로그래머의 날은 256번째 날이므로. 256-243=13이다. 그러므로 9월 13일이 프로그래머의 날이다.
Sample Input 0
2016
Sample Output 0
12.09.2017
위와 같은 방식이지만 2016년은 2월이 29일인 윤년이다. 그러므로 31+29+31+30+31+30+31+30+31+31 = 244이고 256-244=12이다. 그러므로 9월 12일이 프로그래머의 날이다.
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
class Solution {
static int[] GetDays(int year) {
int[] days = new int[12] {
31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
};
bool isJulianCalendar = year <= 1917;
bool isGregorianCalendar = year >= 1919;
if (isJulianCalendar)
{
if (year % 4 == 0)
{
days[1] = 29;
}
}
else if (isGregorianCalendar)
{
if ((year % 4 == 0 && year % 100 != 0) ||
(year % 400 == 0))
{
days[1] = 29;
}
}
else
{
// julianCalendar & isGregorianCalendar
// January 31 after -> February 14
days[1] = 28 - 14 + 1;
}
return days;
}
static string solve(int year){
// Complete this function
int[] days = GetDays(year);
int programmerDay = 256;
int y = year;
int m = 0;
int d = 0;
for (int i = 0; i < days.Length; i++)
{
programmerDay -= days[i];
if (programmerDay < 0)
{
m = i + 1;
d = programmerDay + days[i];
break;
}
}
return String.Format("{0:00}.{1:00}.{2:0000}", d, m, y);
}
static void Main(String[] args) {
int year = Convert.ToInt32(Console.ReadLine());
string result = solve(year);
Console.WriteLine(result);
}
}
#pragma GCC diagnostic ignored "-Wunused-result"
#include <cstdio>
#include <cassert>
int main() {
int y;
scanf("%d", &y);
int daysInFebruary;
if (y == 1918) {
daysInFebruary = 28 - 13;
} else if (y < 1918) {
if (y % 4 == 0) {
daysInFebruary = 29;
} else {
daysInFebruary = 28;
}
} else {
if ((y % 4 == 0 && y % 100 != 0) || y % 400 == 0) {
daysInFebruary = 29;
} else {
daysInFebruary = 28;
}
}
int day = 256 - 31 - daysInFebruary - 31 - 30 - 31 - 30 - 31 - 31;
assert(1 <= day && day <= 30);
printf("%02d.%02d.%04d", day, 9, y);
return 0;
}
문제 자체가 더 어려운 느낌.
문제를 풀려면 그레고릭 달력 줄리안 달력 개념과 윤년 계산 법 등을 알고 있어야 한다.
문제를 풀면서 프로그래머의 날이 있다는 사실 도 알았다..
문제 자체는 출제자와 거의 똑같은 방식으로 푼 것 같다.