Archive for the ‘Software Engineering’ Category

Dialogue’s Guiding Principles, or a Healthy Hatred of OOP two chain links

Dialogue’s Guiding Principles, or a Healthy Hatred of OOP two chain links

Well, it will be interesting to read the post.
However, I found out that problems among US programmers in terms of C++ is that they follow C++ techniques or new syntax etc, which are just supplemental rather than keeping philosophy of OOP and meta-programming.
Syntax-sugar is good. But problems of C++ is that ( don’t misunderstand that. As you can see I’m a long-time C++ programmer and I liked its initial paradigm a lot. ) a lot of features have been added to C++ for the sake of convenience ( with difficulty of using it ) or more power. People, who just judge others’ knowledge on C++ just by asking terminology and features, thus missing core values, love to use any new features.
Knowing such things are good and beneficial, but not always.
I’ve worked on pSosystem at Samsung and other systems where the greatest and the latest C++ features were omitted intentionally for the purpose of the system or unintentionally (just old C++ compiler). If people just stick to the greatest and latest feature and when exposed to such system, they are embarrassed often.
So, I’m always in the attitude of choosing common ground, which maximizes compatibility of source code and your knowledge compatibility.

Anyway, folks. Knowing more terminology and new features will make look more knowledgeable person especially here in the US due to its culture, but actually it’s not. What is more important is to know why you need to use this or that, philosophy behind of a language you choose, etc.

Here I see Objective-C code which is not written by people who understand Objective-C philosophy. They argue that they know, but if you see such code, ou will be able to see that they don’t understand the philosophy.
They oppose Objective-C or any other language without understanding their philosophy. Criticism can be good only and only if people criticize after understanding philosophy or background history on why this language/system is designed as such.

So far, my experience here in the US is that when interviewers were too picky and just judges people by asking if the interviewee knows(memorizes) one thing, I usually found out that their source code were dirty and messy in every angle.
If an interviewee is not a liar or a salesperson who wants to sell himself rather than an engineer, they tend to memorize terminology etc. But if they are engineers, they know but at the moment of being asked, they may not answer the interviewers question. It’s not because they don’t know about the answer, but they can guess something else.

For example, I’ve been asked like “implement this thing using STL.”
Well, I use Win32 collection APIs, Cocoa/Core Foundation collection APIs and also STL. Also I use boost. They are similar. If you happen to use Win32 collection API for the week when you are interviewed, you can temporarily forget STL. But if you look up document, you can quickly write in STL. Then doesn’t he know the STL?

Here in the US, although they say they are Objective-C programmer, they write in C++ and STL mostly. So, they can remember STL syntax.

I’m different. When I implement Win32 code, I stick to Win32 stuffs mostly. When I implement Cocoa/Core foundation code, I stick to them.
If I need to implement something common code, which I may need to use on Window / Mac / iOS/ Unix, I write with pure C/C++/STL. Then, I can temporarily forget one syntax. But does it mean that I don’t know about it?

I’m versatile person. However, the way US people interview others are not like that and they stick to one thing and say they are “the other” programmer.

Another example is … I’m asked how to implement XOR in C++ while being asked about bit-wise operations. So, I told him it’s ^ operator.
He said “No.”
Actually in the conversation, he jumped from logical operation and bit-wise operation. So, I wonder why he said “No.”
Well, what he wanted “DeMorgan’s law” to express logical XOR.
Damn.. then he must be clear on that.
In Korea, DeMorgan’s law is taught in middle school. Everybody knows DeMorgan’s law. Well, actually what is taught here in the US are mostly taught in middle school or high school like calculus, probability etc. Well. some are taught in here too in high school. But compared to the level of things taught in Korea, well here.. I understand why Obama mentioned education in Korea, although I oppose to his intention.
Anyway, then he treated me like a person who doesn’t know C++.

What the..

Agile technique/methodology


That’s what I’m saying as a person who saw the birth of agile technique/methodology. Don’t stick to terminology and their requirements/ or ‘do-this-do-that’.

I remember it was around 1992 when I first saw it. It was in its very early stage. As far as I remember it became more formal. However, I remember that people in S/W engineering called it ‘technique’ rather than ‘methodology’. There was good reason for that. However, after that time ( around 1996~7 ), professors or people in academia have built ivory tower around it. At that time, that was tendency in S/W industry/school. Wow factors were reduced, because most of things we could imagine this ‘comparably-new’ field of academia/industry  were already made or pusuit largely. Anothe example was ‘pattern’. In Korea, we used to say that ‘reason to read books on patterns’ was not because we didn’t know them but because we didn’t know how people called them.

That is typical way to provide ‘authority’ in their major field and protect themselves to present them as ‘experts’. Knowing terminology is important, but it’s not core of knowledge. Knowing is to know something and making it yourself.

I can’t forget a story about a very famous author’s father. (Milan Kundera’s father? I’m not sure ).

His father was a great fan of classical music. In a social meeting with people who care classical music (Surely most are from high society ). People there kind of looked down his father when they let W.A Mozart’s early music played and his father mumbled “Hmmm.. this is differnt from when Mozart grew up but still has his feeling and style though not mature.” It was famous one. Those people mumbled how his father couldn’t know the title of the Mozart’s.
The difference is that they memorized that it’s Mozart’s, while his father knew the style. What’s actual knowledge? Which one we can call ‘knowing’?

I believe who really knows Mozart’s is his father not other people. “Can say terminology or definition by just memorizing’ is not ‘knowing’ itself. After it is boiled and cooked into oneself, even after he forget what it is called, if he can ‘know’ what it is, what it is for, etc, it’s actual ‘knowing’.

After getting interviewed here in the USA for years, now what I can say for sure is that, people here pick  a S/W engineer they want to hire like the way those ‘other’ people do not the father.
In Korea, (i’m sorry that say this but) it’s how small companies hire ‘coders’, who just learned how to write S/W program in ‘programming’ institutes ( like language institutes for English, Korean )
Good S/W engineers from University pursuit their knowledge by understanding not by just memorizing. (memorizing is one of the step to know, as phase 1 along with understanding though. )

commenting or documenting…

When I got interviewed, people tended to ask me, “Can you use Doxygen?”, “Can you use ‘some other document generator’?”.
Usually, when I am asked like that, it turned out that their documentation or whatever stuff they asked was not good in the company.

Commenting, or documenting in source files should be part of architecture, design or planning.
It’s not something you are to write after you implement something. It should be written before you start implementing something and while implementing.

What I mean is this. Commenting/Documenting is for maintainability or help for easier understanding of code.
If people make fun of you when you say “How bad it is! There is no comment!!”, then it’s Ok to treat them as non-professional people.
They will say “Real S/W engineers should be able to figure out without comment.”

Well.. they are only half-right. Sure. If you are a person who can think. Sure.. you can figure it out. However, just to use something and maintain, if you need to spend too much time, it’s not good. Commenting is to help that case. If it gives you an idea what the code part is for, you can get a pre-image to the code block. Then you can figure out things even quicker. Also, you can understand the original authors’ intention, suffering or odd situation they were in.

However, another very important reason for commenting is this.
It helps you to plan things better.
For example, even before writing, you can use your IDE/source code editor as a scratch paper like this.

void MyClass::doSomethingGreat( void )
// 1. Retrieve data from twitter

// 2. Check if there is user object in the response data

// 3. ...

Then, those commenting can plays very important role to aid you to organize your idea and split big task into small chunks.
You can get more rigid idea on what you are going to do. Sometimes by writing as such, something ambiguous can be clearer.
Also, after you write code, it can help you to locate interested portion of code quickly.
Then, it becomes great comment and documentation for itself. You don’t waste your time in writing comment/document. Your design time becomes your documenting time naturally.

Another very important point i would like to address is… Please use and pick terms others can use. Don’t use your own abbreviation and explain things really.

Here is a good example from twitcurl project.

* @method: twitCurl::mentionsGet
* @description: method to get mentions
* @input: sinceId - String specifying since id parameter

Especially take a lookat @input: sinceId line.
What is ‘sinceId’? that will be the question when you first confront the line.
Does “String specifying since id parameter”  really explain what sinceId is?
How about this?

* @method: twitCurl::timelineHomeGet
* @description: method to get home timeline
* @input: sinceId - the post ID for the last retrieved post.
*                                  Post with IDs after sinceID will to be retrieed

Isn’t that better? Anyway you should refer Twitter’s API documentation, but even without it, you can figure out what the sinceId means in that context.

I don’t count comment like the one in the mentionGet method.
You should not say you write comment if you write as shown in the mentionGet method.

창조는 어떻게 교육되나? ( how creativity is taught )

The title can sound weird, because creativity is not to be taught. Creative people look to be born with it.
However, creativity can be found, cultivated and strengthen by training or education.
By saying “education”, it doesn’t mean education at schools here. It means some chances to learn things through them in your life.

This fabulous article on it talks about it in easily readable way. I’m sorry that it’s written in Korean. ( google translation across different family of languages is not good at all. )
Sometimes I wish people write in English as well as their mother tongue for wider audience. )

If you can read and understand Korean, it will be fun to read this article.

write memo to forget things

Although this post is nothing about code, it’s about S/W engineers’ mindset.
When young, CS people focus largely on writing code, thinking about algorithm, researching about how to solve specific problems or domain problems.

SE, i.e. Software Engineering, to CS majors is a field which is humanities to general scholars. While growing up we started to have more interest in SE stuff.
I think most wrong things about recruiting in here in US is to check whether an applicant can answer to some specific questions with the most “up-to-date” set of technical words, or the interviewer tend to have an attitude to consider an applicant not-knowledgeable with a given topic when the applicant didn’t know the “terminology” the interviewer just spit out.
When you have more experience and understand stuff more profoundly, we care is not about the terminology but what it is. Also, in this computer industry, which is easily a topic by even journalist and non technical people, a lot of new terminology which is not different from old terminology are created and perished very quickly.
Then, like me, people who have long experience in this field tend not to care about specific wording. Only people who have business as background but happened to lead developers tend to care about those wording. Especially here in the U.S., people strangely believes “how many terminology you know equals how good engineers you are” thing.

I personally write memo to dump out things from my brain. If some stuffs fill up my brain, I can’t work on new things.
One of my not-short time friend in S.Korea blogged about it recently. So, I’d like to post a link to his post here.

“A new point of view on writing memo”

It’s written in Korean. Do not rely on Google or any other’s machine translation. They are useless. If you want to read and understand it, socialize yourself with nearby Korean friends and ask help from them. :)

Open Source project management tools

Here is a list of 12 really nice project management tools which are free!

How about BugZilla? Is it too confined as “Bug Tracking” system for being a project management tool?

대규모 프로젝트를 조직적으로 관리하는 예

개인 프로젝트가 아닌, 여럿이서 하는 대규모 프로젝트를 하다보면 branch니 trunk니 하는 개념을 써야 할때가 있다.

제품 출시일에 맞추어서 안정된 버젼을 내놓으면서, 새로운 기능을 넣어야 할때, 그 기능을 테스트하지 않거나 테스트를 충분히 하지 않고, 고객의 요구때문에 그냥 최종 버젼으로 넣고, 간단한 테스트를 하고 제품을 출시하기도 한다. 그러다보면 제품 안정성에 문제가 생길 수밖에 없고, 시간이 가면서 고객들이 점점 제품의 안정성을 문제 삼아 꼬투리를 잡고 부당한 것을 요구할 수가 있다. 즉 제품 품질 관리는 기술적인 범위만의 문제가 아니라 사업적인 범위의 문제가 되는 것이다.

그렇다면 뭔가 조직적인 프로젝트의 버젼 관리가 필요하게 된다. 현재 새로운 기능을 넣고 통합하는 큰 줄기의 repository (trunk)에서 때때로 분리 되어 나오는, 그래서 실제 출시 제품으로 가는 알파/베타/release 버젼로 가는 별도의 가지가 필요한데, 이를 branch라 한다.

더군다나 여기에 SQA 팀이 확정적으로 “이쯤되면 이제 release하자”라고 하면, 그것을 또 하나의 branch로 만들어 release code branch를 만들 수있다.

즉 하나의 trunk에 여러 branch를 둘 수가 있다.

Mozilla는 그런 식으로 프로젝트 관리를 해왔다.

즉 이렇게 되어 있다.

Nightly (매일마다 빌드되는, 개발중인 코드들)

  • Mozilla Central
  • TraceMonkey
  • Latest Mozilla-<version number>
Release ( 배포가 확정된 것들)

내가 기억하기론 Mozilla Central은 원래 Netscape의 all-in-one (Web browser, email, HTML editor ) 소스코드의 repository였었는데( Sea Monkey라고 불린다. 이 프로젝트는. 근데 요새도 이 all-in-one을 쓰는 사람들이 꽤 있나? 아직도 Sea Monkey를 유지하는 것을 보면), 최근에 좀 다시 재정리가 된 것 같다. 그래서 Firefox의 nightly에는 Mozilla Central과 TraceMonkey가 거의 서로 alias인 것처럼 동일하다.
근데 최근에 여기에 하나 더 추가했다.
바로 Aurora라는 것인데, 그런 이유로는 개발자가 아닌, 소위 Power User들이 Nightly를 다운 받아가면서, “불안정하다”라고 불평을 토로하는 경우가 많아져서이지 않을까 한다.
즉  이 Aurora는 다음에 위치하고 있다.

  • Mozilla Central
  • TraceMonkey
  • Auroa
  • Latest Mozilla-<version number>
  • <version number>-candidate

Aurora는 Mozilla Central의 최신 기능들을 좀 안정화 시킨 코드를 포함하고 있다. 그러므로 발표가 될 버젼의 베타 버젼들(Latest Mozilla-<version number>)들 보다는 새 기능을 가지고 있고, 안정화는 main trunk인 Mozilla Central보다는 더 되어 있다.

*-candiate는 발표 직전의 것들인데, 이것도 사실 다 베타 버젼이다.
참 여기서, Mozilla Central이나 TraceMonkey는 Trunk로 볼 수가 있고 (정말 그 두개가 같은 거라면), 나머지는 branch들이다.
예전엔 Trunk/Branch라는 용어를 많이 사용했는데, 최근에는 별로 사용하지 않는 것으로 보인다. 아무튼…
근데 여기에 좀더 복잡한 면이 있다. 베타 버젼인 Latest Mozilla branch는 1.9.1, 1.9.2 , 2.0 등이 있다. 항상 동시대에 두세개의 버젼에 대한 branch가 있는데, 하나는 이미 발표되고 공식 릴리즈로 봐도 이전 버젼이지만, patch등이 이루어지는 경우, 그리고 현재 릴리즈된 것의 버그 픽스등이 들어 있는 경우, 그리고, 그 다음 버젼의 것등이다.

그러므로, 이 자체가 어떤 면에서는 저 aurora가 가질 특성을 이미 가지고 있다고 보면 된다. ( 최종 사용자 입장에서는 이미 다음 버젼에 대한 latest-mozilla-*가 배포된 버젼의 것에 없는 기능을 포함하고 있기 때문에, 이미 충분히 일반 사용자가 사용 못하는 새 기능을 가졌다고 할 수있다. )
가만히 보면, 이것은 베타에 베타 기능들이 겹겹히 되어 있는 것이다.

처음에는 분명히 개발의 목적에 의해서 분류가 되었었다.
이를테면 all-in-one suite가 있고, Firefox나 Thunderbird가 나올 때, main branch(trunk)에서는 새 기능이나 프로그램 구조 자체를 확 뜯어 고치는 작업이 이루어졌듯이, Firefox로 넘어와서 그 자체의 trunk에서도 그런 일이 있었다. 이를테면 기존의 UI 모델에서 XML에 기반한 XUL의 모델로 바꿨다던가, Firefox 3에서 4로 넘어갈때, 그리고 예전에 cache 문제가 memory leak 문제랑 결부되어서 아주 해결하기 힘들었었을때, 아예 기본 구조를 뜯어 고쳤을때, trunk에서 그런 작업이 이루어지면서, 그 파생 branch에서는 기존 구조 유지하면서 새 기능을 넣었었다. 그러다가 trunk에서 작업이 완료내지는 많이 안정화 되면 branch로 그것을 전이 시켰었다.
이런 측면은 분명 개발의 목적을 충족시키는 것이었는데, aurora같은 경우는 별로 개발하고 관련없어 보인다. 이미 새 기능의 안정화는 latest-mozilla-<version> branch에서 해 오던 기능이다.

아무튼… 이렇게 겹겹이 해 놓은 것을, 서로 같에 소스코드 싱크 시키고, 새 구조로 바뀌었을때는 그것을 반영하면서 기존 기능 깨지지 않게 유지시키고 하는 일이 정말 큰 일이다.
내가 봤을때, Open Source로 진행되는 큼지막한 프로젝트들, 예를 들어 OpenCV, OpenSSL, GCC, IBM의 ICU, Mozilla 같은 것들이 다 관리가 잘 되는 훌륭하게 성공한 프로젝트들인데, 특히나 Mozilla는 일반인들에게도 관심이 있고, 엄청난 다운로드 수를 자랑하고 있어서 (그만큼 노출이 되었다는 소리) 특히나 이런 버젼 관리가 굉장히 중요하다. 그런 상황에서 이렇게 소스 코드 싱크를 하고 있다는 것은 정말이지 놀라운 일이다.
( 이것을 최근의 WebKit과 비교해 보자. 요새 WebKit2의 소스코드가 슬슬 WebKit에 묻어나오는지, 어떤 날의 빌드는 아예 수행자체가 안되는 경우가 왕왕있다. WebKit은 Mozilla처럼 복잡한 source branch를 가지고 있지 않다. 그렇다고 해서, WebKit의 그것이 나쁘다는 소리는 아니다. WebKit은 Mozilla에 비해선 철저히 개발의 목적에 맞추어서 관리되고 있는 모양새다. 아무튼 이렇게 가끔은 수행이 안될 정도로 깨지는 것도 있는게, 개발자인 내가 보기엔 더 자연스럽다. 그런데 Mozilla의 것은 아주 아주 가끔 그런적도 있었지만, 대개 그런게 없다. 이렇게 다양한 층으로 관리를 하니까 그런거다. 하지만 대신 복잡한 소스 싱크의 문제가 도사리고 있다. )
도대체 누가 이런 소스 싱크 관리를 할까?
Mozilla Foundation을 보면, 개발자들도 있다. 그 사람들은 상주하는 사람들 같은데, 그들이 할 것 같다는 생각이 든다.

아무튼, Mozilla가 최근 채택한 소스 repository관리에 대해서 더 알아보고 싶으면 여기를 참조하시라.
Mozilla Release Process
두 문서가 링크되어 있다.

%d bloggers like this: