Mr. WiseBell

Liferay에서 AutoLogin을 처리하는 방법은 2가지가 있다.

1. http://server/c/portal/login?login=계정&password=비밀번호

2. http://server/path?parameterAutoLoginLogin=계정&parameterAutoLoginPassword=비밀번호&기타 파라메터

2번을 사용하기 위해서는 auto.login.hooks 프로퍼티에 com.liferay.portal.security.auth.ParameterAutoLogin 값이 추가로 설정되어 있어야 한다.

Wise.IdealType.exe

방송중에 "이상형 월드컵" 이라는 게임이 있다.
Wise.IdealType은 이 게임을 흉내내 만들어 보았다.
이미지들은 일단 "초상권" 문제가 있을수 있으니 실행파일만 첨부하였다.

실행

이미지 로드

게임 시작

대전중

http://www.nunit.org/index.php

[NUnit]
NUnit 은 Microsoft .NET을 위한 오픈소스의 단위 테스팅 프레임워크이다.
이것은 JUnit이 Java에서 사용되는 목적과 동일한 역할을 하며, 수많은 xUnit 패밀리중에 하나이다.

[Unit Testing]
소프트웨어 확인 및 검증 방법으로 프로그래머가 소스코드의 개별 유닛들이 사용에 적합한지 테스트 하는 것이다.
하나의 유닛은 어플리케이션에서 테스트가 가능한 최소 단위이다.

[xUnit]
수많은 code-driven 테스트 프레임워크들을 집합적으로 일컬어 xUnit으로 알려졌다.

(표 출처 : http://www.nunit.org/index.php?p=platformSupport)

CLI는 ISO/IEC 9075-3:2003에 정의된 소프트웨어 표준이다. 이것은 프로그램이 SQL 질의들을 어떻게 DBMS 보내고, 반환된 레코드셋들을 어플리케이션이 어떻게 일관된 방법으로 다룰지에 대해서 정의하고 있다. 1990년대 초반에 개발된 이 API는 C와 COBOL 프로그래밍 언어만을 위해 정의되어 있다.

이 인터페이스는 Open Group이  Commin Application Environment로 참조하고 있는 것들중 일부이다. Commin Application Environment는 공개 어플리케이션들을 위한 광범위한 표준으로, 서로 다른 프로그래밍 팀과 서로 다른 공급자들의 어플리케이션간의 상호작용을 효과적인 방법으로 수행하기위한 표준이다. SQL/CLI 는 SQL 데이터베이스에 접근하는 국제표준의 구현 독립적인 CLI를 제공한다.  클라이언트-서버 형식의 툴들이 동적 링크 라이브러리를 통해 쉽게 데이터베이스에 접근할 수 있다. 이것은 풍부한 클라이언트-서버 툴들을 지원 장려하고 있다.

가장 널리 사용된 CLI 표준 사용법은 ODBC(Open Database Connectivity) 로, 서로 다른 공급자들의 데이터베이스 시스템에 어플리케이션들이 접근하도록 허용하는데 널리 사용되었다.

현재 버전의 API와 ODBC 3.52는 ISO와 X/Open 표준 모두의 특징들을 통합하고 있다.

참조
http://en.wikipedia.org/wiki/Call_Level_Interface
http://www.opengroup.org/products/publications/catalog/c451.htm

StringBuilder

Any "tips and tricks" presentation on the .NET Base Class Libraries will tell you that StringBuilder is better than String::Concat. Here's how that looks:

void StringBuild::build(int loops)
{
    String* block = "123456789012345678901234567890";
    StringBuilder* result = new StringBuilder();

    for (int i=0; i<loops;i++)
        result->Append(block);
    String* realresult = result->ToString();
    Console::WriteLine(realresult->Length.ToString());
    return;
}

The only hassle is remembering to call ToString() on the StringBuilder when you've finished building it. The code is simple to write and to read, and it's much much faster than the String::Concat() case. But it's not the fastest, at least not always.

Hand-allocating a buffer

StringBuilder works by allocating more memory than you need, and by tacking the new strings into that buffer. Every time you need the buffer to enlarge, it doubles in size. That approach was chosen as a trade-off between allocating too much memory and wasting a lot of time allocating little extra bits over and over again. The starting size is implementation-specific, but in most cases it's 16 characters. You can pass an integer to the StringBuilder constructor to bump up the initial allocation if you know what you'll need: That will save you the extra allocations but it won't save you all the testing to see whether you've exceeded your capacity or not.

So, because this is C++ after all, let's do something they can't do in VB and play with pointers a little. Look at this code:

void StringBuffer::build(int loops)
{
    char* block = "123456789012345678901234567890";
    int delta = strlen(block);
    char* buffer = new char[loops*strlen(block)+1];

    char* p = buffer;
    for (int i=0; i<loops;i++)
    {
        strcpy(p,block);
        p += delta; 
    }

    String* result = buffer;
    Console::WriteLine(result->Length.ToString());
    return;
}

Whenever you work with char* strings, you have to remember when to add an extra character for the \0 or when to move past it or before it or whatever. In this code, the delta, how much we move forward each time, is deliberately set to exactly the strlen of block—normally you would add 1 to allow room for the \0, but I want the first character of the next append to overwrite the \0 so we have one long, contiguous string at the end.

This code works, and it is faster than StringBuilder. That's not surprising, because I don't have to test to see whether I am exceeding my capacity, and I don't have to allocate more memory. Because I'm steering clear of the managed heap except for the final string, I'm probably not exercising the garbage collector either. So what is surprising is that's it's not very much faster than StringBuilder: about 10-20% less time for the same number of loops. And this is for a special case where I knew the exact length of the buffer in the end. For the general case where you're gluing together an unknown number of strings, each of an unknown length, you're not going to beat StringBuilder with something you write yourself. That's worth knowing, isn't it?

Program.cs에 다음과 같이 코드 추가

using System.Threading;

        static void Main()
        {            bool createdNew;
            Mutex dup = new Mutex(true,"Mu", out createdNew);             

            if (createdNew)
            {
                Application.Run(new From());
                dup.ReleaseMutex();
            }
            else
            {
                MessageBox.Show("이미 프로그램이 실행중입니다.");
            }           
        }