Ting 이네 Software 이야기

type 1 : Function may fail with quite high possibility. 
return value tells details about success or fail reason.
Ex.)

return_value == 0 : general success.
return_value > 0 : success with additional information [value represents additional information]
return_value < 0 : fails [value represents error code]

int open_service(...) {...}

type 2 : Function may fail with very low possibility.
return value tells the result or "success or fail".
Ex.)

return_value == NULL : fails.
otherwise : return_value is result.

Item* List::next() {...}
FILE* fopen(...) {...}

In this case, we may need additional function like "get_last_error()" - like MSVC's API.

type 3 : Function never fails.
return value is result, 'void' or instance itself to easy-next-use.
Ex.)

int get_id() {...}
void set_color(int color) {...}
Paint* Paint::set_color(int color) {...; return this;}

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
There two type of using 'new' operator.

new Type(param);
new Type[size];

'new' is operator. So, parameter is followed by. Therefore, we should take care of using '()'.
Here is test result on MSVC7.

(*1)

new (Typename(param)); // -- compile error
new (Typename)(param); // -- OK
new (Typename[size]);  // -- OK
new (Typename[size])(); // -- OK
new (Typename)[size];  // -- compile error
new (Typename[size])(param); // -- compile error

Interestingly, 'Type[size]' itself seems to be regarded as type. That is,

int a[10]; // 'sizeof(a)' works

similarly

Type[10]; // 'sizeof(Type[10])' works.

Considering 'Type[size]' as a kind of type may not be true. But, I think it's similar with the case of pointer - pointer is type of not. Only to understand things easily, personally, I will regard it as type.

Let's see (*1) from "C operator"'s point of view - 'new' also a kind of operator.

operator new ( Typename(param) ); //  (*a)
operator new (Typename) (param); // (*b)
operator new (Typename[size]); // (*c)
operator new (Typename[size])(); // (*d)
operator new (Typename)[size]; // (*e)
operator new (Typename[size])(param) // (*f)

(*a) : 'Type(param)' is syntax for create instance. Not type name.
(*b) : '(param)' is parameter of instance created by '(operator new(Typename))'
(*c) : 'Typename[size]' is just a type. So, no problem!
(*d) : same with above. It's like "calling default constructor of newly created instance".
(*e) : This is a form like "instance[size]" - (operator new (Typename))[size]. Array should be declard with type (Not instance).
(*f) : (operator new (Typename[size])) (param). This is like "calling constructor whose parameter is '(param)'". But, ISO C++ forbids initialization in array new.

Hmmm..... Interesting.....

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
This id 100% personal opinion...
Step of progress in terms of programming skill(excluding co-working skill).

1. Coding with giving attention to the language syntax.
2. Coding his/her own thought quickly. (number of code line per hour is a lot. But, very buggy & poor design)
3. Realizing difficulty of debugging. So, coding considering debugging. initial speed becomes slower than (2)
4. Realizing software design. Coding considering design too. (slower than (3))
5. Knowing design techniques and importance of interface design, but immature. So, software is tended to be over-engineered. Lots of time is spent on designing over-engineered-software, interface and so on. In this stage, programmer knows about "What should be considered for good software". But he/she doesn't have any idea/experience about solutions. That's why initial speed is very slow.
6. Being mature. Becoming faster step by step.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

There lots of books and guides about project management. But in my opinion, most important and efficient way is "Divide and Conquer". In general, small-size-project is easy to succeed regardless of methodology. So, most important thing to succeed is "Dividing large project into several small independent projects". We should focus and spend time on this!!!

( Yes.. I know..."Easier said than done!" :-( )

[Extracting from Wikipedia]

Software development

Part of this section is from the Perl Design Patterns Book.

In the software development process, the top-down and bottom-up approaches play a key role.

Top-down approaches emphasize planning and a complete understanding of the system. It is inherent that no coding can begin until a sufficient level of detail has been reached in the design of at least some part of the system. The Top-Down Approach is done by attaching the stubs in place of the module. This, however, delays testing of the ultimate functional units of a system until significant design is complete. Bottom-up emphasizes coding and early testing, which can begin as soon as the first module has been specified. This approach, however, runs the risk that modules may be coded without having a clear idea of how they link to other parts of the system, and that such linking may not be as easy as first thought. Re-usability of code is one of the main benefits of the bottom-up approach.[citation needed]

Top-down design was promoted in the 1970s by IBM researcher Harlan Mills and Niklaus Wirth. Mills developed structured programming concepts for practical use and tested them in a 1969 project to automate the New York Times morgue index. The engineering and management success of this project led to the spread of the top-down approach through IBM and the rest of the computer industry. Among other achievements, Niklaus Wirth, the developer of Pascal programming language, wrote the influential paper Program Development by Stepwise Refinement. Since Niklaus Wirth went on to develop languages such as Modula and Oberon (where one could define a module before knowing about the entire program specification), one can infer that top down programming was not strictly what he promoted. Top-down methods were favored in software engineering until the late 1980s, and object-oriented programming assisted in demonstrating the idea that both aspects of top-down and bottom-up programming could be utilized.

Modern software design approaches usually combine both top-down and bottom-up approaches. Although an understanding of the complete system is usually considered necessary for good design, leading theoretically to a top-down approach, most software projects attempt to make use of existing code to some degree. Pre-existing modules give designs a bottom-up flavour. Some design approaches also use an approach where a partially-functional system is designed and coded to completion, and this system is then expanded to fulfill all the requirements for the project

Programming

Top-down is a programming style, the mainstay of traditional procedural languages, in which design begins by specifying complex pieces and then dividing them into successively smaller pieces. Eventually, the components are specific enough to be coded and the program is written. This is the exact opposite of the bottom-up programming approach which is common in object-oriented languages such as C++ or Java.

The technique for writing a program using top-down methods is to write a main procedure that names all the major functions it will need. Later, the programming team looks at the requirements of each of those functions and the process is repeated. These compartmentalized sub-routines eventually will perform actions so simple they can be easily and concisely coded. When all the various sub-routines have been coded the program is done.

By defining how the application comes together at a high level, lower level work can be self-contained. By defining how the lower level abstractions are expected to integrate into higher level ones, interfaces become clearly defined.

Top-down approach

Practicing top-down programming has several advantages:

* Separating the low level work from the higher level abstractions leads to a modular design.
* Modular design means development can be self contained.
* Having "skeleton" code illustrates clearly how low level modules integrate.
* Fewer operations errors (to reduce errors, because each module has to be processed separately, so programmers get large amount of time for processing).
* Much less time consuming (each programmer is only involved in a part of the big project).
* Very optimized way of processing (each programmer has to apply their own knowledge and experience to their parts (modules), so the project will become an optimized one).
* Easy to maintain (if an error occurs in the output, it is easy to identify the errors generated from which module of the entire program).

Bottom-up approach

Pro/ENGINEER WF4.0 proetools.com - Lego Racer Pro/ENGINEER Parts is a good example of bottom-up design because the parts are first created and then assembled without regard to how the parts will work in the assembly.

In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a "seed" model, whereby the beginnings are small, but eventually grow in complexity and completeness.

Object-oriented programming (OOP) is a programming paradigm that uses "objects" to design applications and computer programs.

In Mechanical Engineering with software programs such as Pro/ENGINEER, Solidworks, and Autodesk Inventor users can design products as pieces not part of the whole and later add those pieces together to form assemblies like building LEGO. Engineers call this piece part design.

This bottom-up approach has one weakness. We need to use a lot of intuition to decide the functionality that is to be provided by the module. If a system is to be built from existing system, this approach is more suitable as it starts from some existing modules.

Pro/ENGINEER (as well as other commercial Computer Aided Design (CAD) programs) does however hold the possibility to do Top-Down design by the use of so-called skeletons. They are generic structures that hold information on the overall layout of the product. Parts can inherit interfaces and parameters from this generic structure. Like parts, skeletons can be put into a hierarchy. Thus, it is possible to build the over all layout of a product before the parts are designed.

Classifying non-regular bugs. (My opinion)

I usually classify non-regular bugs into 3 category.

(*1) : caused by timing. In multi-threaded software, sometimes unexpected execution order - ex. race condition - may raise error.
(*2) : caused by memory corruption. Memory is corrupted by some reasons - this is root cause, and because of this, error is occurred irregularly.
(*3) : caused by using uninitialized data.

Knowing that which category the bug belongs to, is very difficult and usually, only based on developer's experience.
Here one tip comes from my experience.

In case (*2) :
  reproducing way itself seems to be very irregular and the representation(result) of crash is also very un-determined.
In case (*3) :
  even if reproducing sequence is irregular too, the representation(result) tends to be simlar among cases. Usually, software is crashed from 'wrong memory reference'. And the overall outlook of crash is very regular.

(삼가 고인의 명복을 빕니다.)

[사람들은 "전부 노무현 탓이다."라고 이야기 하면서, 모든 것을 그의 탓으로 돌리며 그를 비판했다.]

[그렇지만, 그는 그냥 묵묵히 말없이 바위처럼 있었다. ]

난 그가 민주당 경선 후보로 나왔을 때부터, 그러니까 '노사모'가 결성되었을 때 즈음부터 노무현을 지지했었다. 그리고, 그가 보수 언론과 야당의 비판에 휘둘려, 국민들의 지지를 잃어갈 때에도 난 그를 지지했었다. 그리고 그가 퇴임하는 순간, 최악의 지지도에 괴로워했을 때에도 그를 지지했었다. 그냥 하는 이야기가 아니라, 정말이다. 난 그를 끝까지 지지했었다.

그런 그가, 떠났다. (모르겠다. 경찰은 자살이라고 발표했다. 언론도 그렇게 이야기한다. 그렇지만 항상, 진실은 경찰발표와 언론 저 너머에 있었다. 자살인지, 아니면 타살인지 모르겠다. 그렇지만, 노무현 그가 이 세상을 떠났다는 것은 부정할 수 없는 사실이다.)

2009년 5월 23일 그의 서거 소식을 들었다.(사실 23일 당시 언론은 '서거'가 아니라 '사망'이라는 표현을 먼저 썼다. 그래서 난 처음에는 누군가 장난치는 줄 알았다.)

멍~ 했다. 그리고 분노했다. 사실이든 사실이 아니든, 난 정치보복성 수사가 그를 죽음으로 몰고 갔다고 믿는다.(모르겠다. 이런 글을 쓰면, 또 검찰에서 딴지를 걸고 넘어질려나... 지금의 검찰은 그러고도 남을 듯 하다.) 그리고, 현 정권(17기 이명박 정권)에 분노를 표출했다. 그런 분노가 계속되고, 금일 29일(금요일) 영결식날 난 회사에 휴가를 내고 경복궁을 향했다. 그리고 다시 한 번 분노했다. 추모객 숫자보다 더 많아 보이는 전경들, 경복궁 근처에는 얼씬도 하지 못하게 하는 저지선, 그리고, 어디 광고에나 쓰일법한 전광판에서 방송되고 있는 영결식을 보고 있으라는 말... (특히 "조선일보"라는 큰 건물 명 아래에 위치한 전광판에서 '영결식'이 방송되는 모습은 정말 말로 표현하기 어려운 황당함과 분노를 일으켰다.)

그리고 난 이러한 분노가 이성을 막아설까봐 두려워, 집으로 발길을 돌렸다. 시청앞광장 노제를 뒤로한체... (나의 성격을 잘 아는 집사람이 시청에 가는 것을 극도로 반대했었던 것도 이유 중 하나였다. 지금은 두 가지 심정이 복잡하게 얽혀있다. 과연 그때 뒤돌아 온것이 잘한 것인지 아닌지... 마지막 가시는 길을 배웅하지 못한 안타까움과, 분노에 이성을 잃을 수도 있었으나 잘 참아낸 선택이였다는, 두 가지 상반된 생각의 혼재가....)

그리고 집에서 생방송을 지켜보았다. (이명박 정권부터는 뉴스 및 기타 시사 프로는 되도록이면 MBC를 본다.) 말없이 하염없이 방송을 지켜 보고 있던 가운데, 29일 저녁쯤, 처음으로 내 눈에서 눈물이 흘렀다.

사람들은 '지켜주지 못해서 미안하다.' 라고 말했다.

그랬다. 눈물을 흘리면서도, 왜 내가 이렇게까지 슬퍼하고 있는지 나 자신도 몰랐는데, 이유는 그거였다.

앞서 이야기 한 것처럼, 난 노무현을 지지해 왔었다. 그렇지만, 반 노무현의 목소리가 높았을때, 난 "나도 노무현을 좋아하지는 않지만..." 으로 시작하는 말로, 소극적으로 그를 지지했었다.

그랬다. 난 비겁했다. 난 당당하지 못했다. 그렇지만, 그는 언제나 당당했다.

오 바마 현 미 대통령이, 그의 당선의 변에서, "내가 하는 일이 모두 옳은 일은 아닐지언정, 난 내가 하는 모든 일을 정직하게 하겠다."(정확하게 이 말이 맞는지는 모르겠으나, 뜻은 거의 비슷할 것이다.)라는 말이 생각났다. 그랬다. "바보 노무현"은 그랬다.

그는 결코 그의 신념을 굽히지 않았다. 타협하지 않았다. 그런 그를 지지하면서도, 난 비겁했다. 그 미안함. 그게 아마도 눈물이 되어 흘렀으리라.

그 가 그렇게 힘들고 고독하게 싸우고 있음에도, 난 비겁했고, 소극적이였다. "난 힘이 없어." "난 아무것도 변화시킬 수 없어."라는 자기 변명으로, 비겁하게 난, 도망쳤다. 그리고, 지금의 내가 가지고 있는 것들을 잃는게 두려워 비겁하게 도망쳤다.

그리고, 이제 그가 갔다.

그런 그가 나에게 묻는다. 넌, 타협하지 않고, 신념과 소신을 굽히지 않고, 당당하게 나아갈 수 있느냐고...

(난 그가 했던 모든 것들이 '옳다'고 이야기 하고 있는게 아니다. 그는 정직했고, 당당했고, 원칙과 소신에 따랐다. 그걸 이야기 하고 있는 것이다.)

그런 그에게 부끄럽지 않고 싶다.

난, 아직 한번도 정치적인 사안에 대해 인터넷에 글을 올려 본 적이 없다. 두려웠기 때문이다. 그렇지만, 지금 이 순간 처음으로 글을 올린다.  나의 비겁함에 대한 작은 속죄로, 또 부끄럽지 않는 삶의 작은 첫걸음으로...(이 글을 공개하는 것은 아무래도 조금더 긴 생각이 필요할 듯 하다. 괜시리 그에게 의도하지 않은 피해를 줄 수도 있기에...)

다시 한번 삼가 고인의 명복을 빕니다.

사랑했었고, 사랑하고 또 앞으로도 사랑할 대한민국 16기 대통령 故 노무현 님.

나도 나보다 어려운 사람들을 위해 무언가를 해야겠다는 다짐을 다시 한 번 굳게 해 본다. 구체적인 실천계획을 세워야 겠다. 내가 무엇을 할 수 있는지 부터...

- 2010년 5월 23일 : 위 글은 故 노무현 前 대통령 서거 당일날 썼던 글이다. 그렇지만, 그 당시 난 이 글을 공개하지 않았다. 내가 쓴 이 글이 부끄러워서 인지, 아니면 어떠한 불이익이 두려워서인지는 기억나지 않는다. 하지만 오늘 서거 1주년을 맞이한 지금, 이 글을 공개한다. 지금의 나에겐 1년 전과는 달리, 공개하지 못할 어떠한 이유도 없다. "우리는 노무현을 맞이할 자격이 없었다." 라는 글을 어디에선가 읽었던 기억이 난다. 서거 1주년이 된 오늘, 난 나에게 다시금 물어본다. "과연 지금의 난 노무현 맞이할 자격이 있는가? 그리고, 언젠가 또다른 바보가 나타났을때, 그를 맞이할 자격이 있겠는가?" 를...
(2010년 6월 2일, 지방 선거가 있다. 과연 이번은 어떨지...)

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Notation:
[ ... ] : Issues that I face with. Record(History) for resolve the issue should be followed by - should be indented.
{ ... } : state and environment
( ... ) : reference stuff to resolve the issues.

{ Laptop : HP EliteBook 8530w }
{ OS : Ubuntu 9.04 Jaunty }
[ Nvidia graphic card is not identified by Jaunty ]
( http://www.linlap.com/wiki/HP+EliteBook+8530W )

download NVIDIA-Linux-x86-185.18.36-pkg1.run
stop 'gdm' service at "System > Administration > Services"
type "sh NVIDIA-Linux-x86-185.18.36-pkg1.run" to install NVIDIA driver

 
[ Sound doesn't work! ]
( http://www.linlap.com/wiki/HP+EliteBook+8530W )

Add the following lines at "/etc/modprobe.d/alsa-base"
=> options snd-hda-intel model=laptop

 
{ My laptop is behind proxy }
[ 'git' command doesn't work ]

git config should be modified. So, I added following lines at '~/.bashrc'
=> git config --global core.gitproxy "xxx for kernel.org"