맑은 고딕 설정
저의 블로그에 '윈도우 비스타'와 '오피스 2007'의 기본 글꼴인 '맑은 고딕'을 적용해 보았습니다. 아직은 맑은 고딕이 대중화가 안되어서 가독성이 떨어질 것 같아 보이긴 하지만 글꼴이 개인적으로 예뻐보여서 한번 적용해 보았습니다.
참고로 저의 글꼴군입니다. [font-family: Malgun Gothic, Lucida Grande, Tahoma, Verdana, Arial, sans-serif;]
맑은 고딕 폰트의 가독성이 떨어지는 분들은 클리어타입 폰트가 현재 사용하고 있는 디스플레이 설정과 맞지않은 경우입니다. 다음 클리어타입 튜너 프로그램을 사용하면 간단하게 수정이 가능합니다. 보기 좋은 예제타입을 선택만 해주면 간단하게 설정됩니다.
그리고 설치 후에는 프로그램 폴더가 아닌 제어판에 등록됩니다.
[다운로드]
Social Network 분석
친구수가 많은 블로거 상위 1000명의 인적 네트웍 모형을 분석하기 위해서 먼저 타겟 정보를 수집하고 연령, 교육, 성별별로 Digital Mass, Digital Star, Traditional Upper Class의 분석 기준을 마련하고 분석을 진행하면서 다음과 같은 경우의 결과를 도출 할 수 있다.
- Digital Star에 속하는 이들에 비해, Upper Class는 연령적으로 많다던지..
- 상대적으로 교육이 높은 이들이 자신의 블로그를 많은 내용으로 채움과 동시에 타인의 블로그에도 많은 관심을 가지고 있다던지..
- 다양한 사람들과 관계 맺으면서도 관계의 강도 역시 강하게 엮여 있다던지..
- 새로운 계층 모형을 발견한다던지..
- 전통적 사회 관계에 속하는 upper class와 scale-free network에 속하는 digital population이 서로 다른 종류의 부가가치를 창출하고 있다거나..
- 즉각적인 부가가치를 창출하는 것은 digital population이 아니라 전통적 사회관계에 속하는 upper class이라거나..
- digital population은 트래픽을 늘리고 인터넷을 sustain하는 역할을 함을...
다양한 분석 모형을 만들 수 있을 것 같다.
그럼 우리는 어떤 사람들을 마케팅 대상으로 할지 알수가 있죠. 그리고 사람들의 사이버 공간에서 활발하게 네트워크를 분석함으로써 사회적 관계의 규칙들을 파악하고, 새로운 유형의 계층들을 이해하고 그러면서 많은 부가가치의 창출이 가능한 비지니스 모형의 도출에 기초적 데이터를 제공해 준다.
2007년 웹서버 사용 통계 발표
이번달 조사의 중요한 이슈는 고성능으로 설계된 오픈 소스 서버인 lighttp의 도약을 꼽았다. 제우스를 제치고 선에 가깝게 접근한 lighttpd는 전체의 1,2%인 138만 사이트에서 사용되고 있는 걸로 나타났다.
그리고 우리 눈에도 익히 알수 있는 오픈 소스 개발자 커뮤니티인 SourceForge, 소셜 미디어 허브사이트인 Redd, 인스턴스 메신저 서비스인 Meebo, YouTube, Wikipedia도 lighhttpd를 사용하고 있다.
다음은 발표된 통계 자료이다.

| Developer | March 2007 | Percent | April 2007 | Percent | Change |
|---|---|---|---|---|---|
| Apache | 64747516 | 58.62 | 66899485 | 58.86 | 0.24 |
| Microsoft | 34265321 | 31.02 | 35380121 | 31.13 | 0.11 |
| Sun | 1851269 | 1.68 | 1907610 | 1.68 | 0.00 |
| lighttpd | 1399786 | 1.27 | 1382843 | 1.22 | -0.05 |
| Zeus | 525405 | 0.48 | 488838 | 0.43 | -0.05 |
Rails를 사용하는 사람들은 아파치 웹 서버와 CGI. 성능에 문제가 많은데 그런 부분을 보완한 Lighttpd + FCGI 조합을 많이 쓰인다. 그리고 무엇보다 Lighttpd에 열광하는 이유는 기본으로 제공되는 안정적인 fastcgi 모듈이다. 이 모듈이 아파치의 mod_fastcgi보다 빠르고 안정적이라는 사실은 모두가 인정하고 있다.
Lighttpd + Pound + Mongrel 이 조합도 좋아 보인다. 그래서인지 앞으로는 Lighttpd의 사용률이 많이 올라가지 않을까 생각해본다.
Mindmeister 초대장 배포
그래서 샘플로 한번 초대 테스트를 해 봤는데 정상적으로 작동하는 걸 보았습니다.
15분께 초대장을 배포할 예정이니 댓글에 메일을 넣어주시면 제가 바로 쏴드리겠습니다. 물론 메일은 외부에 노출은 되지 않으니 메일 넣는 곳에 메일 주소를 넣어주시면 됩니다.
자 요이 땅 ~~~

Java Programming Style Guidelines
Java Programming Style GuidelinesVersion 6.0, April 2007Geotechnical Software Services Copyright © 1998 - 2007 This document is available at http://geosoft.no/development/javastyle.html |
Table of Content
- 1 Introduction
- 2 General Recommendations
- 3 Naming Conventions
- 4 Files
- 5 Statements
- 6 Layout and Comments
- 7 References
1. Introduction
This document lists Java coding recommendations common in the Java development community.
The recommendations are based on established standards collected from a number of sources, individual experience, local requirements/needs, as well as suggestions given in [1], [2], [3], [4] and [5].
There are several reasons for introducing a new guideline rather than just referring to the ones above. Main reason is that these guides are far too general in their scope and that more specific rules (especially naming rules) need to be established. Also, the present guide has an annotated form that makes it easier to use during project code reviews than most other existing guidelines. In addition, programming recommendations generally tend to mix style issues with language technical issues in a somewhat confusing manner. The present document does not contain any Java technical recommendations at all, but focuses mainly on programming style.
While a given development environment (IDE) can improve the readability of code by access visibility, color coding, automatic formatting and so on, the programmer should never rely on such features. Source code should always be considered larger than the IDE it is developed within and should be written in a way that maximize its readability independent of any IDE.
1.1 Layout of the Recommendations.
The recommendations are grouped by topic and each recommendation is numbered to make it easier to refer to during reviews.
Layout for the recommendations is as follows:
| n. Guideline short description |
| Example if applicable |
| Motivation, background and additional information. |
The motivation section is important. Coding standards and guidelines tend to start "religious wars", and it is important to state the background for the recommendation.
1.2 Recommendation Importance
In the guideline sections the terms must, should and can have special meaning. A must requirement must be followed, a should is a strong recommendation, and a can is a general guideline.
2. General Recommendations
| 1. Any violation to the guide is allowed if it enhances readability. |
| The main goal of the recommendation is to improve readability and thereby the understanding and the maintainability and general quality of the code. It is impossible to cover all the specific cases in a general guide and the programmer should be flexible. |
3. Naming Conventions
3.1 General Naming Conventions
| 2. Names representing packages should be in all lower case. |
| mypackage, com.company.application.ui |
| Package naming convention used by Sun for the Java core packages. The initial package name representing the domain name must be in lower case. |
| 3. Names representing types must be nouns and written in mixed case starting with upper case. |
| Line, AudioSystem |
| Common practice in the Java development community and also the type naming convention used by Sun for the Java core packages. |
| 4. Variable names must be in mixed case starting with lower case. |
| line, audioSystem |
| Common practice in the Java development community and also the naming convention for variables used by Sun for the Java core packages. Makes variables easy to distinguish from types, and effectively resolves potential naming collision as in the declaration Line line; |
| 5. Names representing constants (final variables) must be all uppercase using underscore to separate words. |
| MAX_ITERATIONS, COLOR_RED |
| Common practice in the Java development community and also the naming convention used by Sun for the Java core packages.
In general, the use of such constants should be minimized. In many cases implementing the value as a method is a better choice:
int getMaxIterations() // NOT: MAX_ITERATIONS = 25 This form is both easier to read, and it ensures a uniform interface towards class values. |
| 6. Names representing methods must be verbs and written in mixed case starting with lower case. |
| getName(), computeTotalWidth() |
| Common practice in the Java development community and also the naming convention used by Sun for the Java core packages. This is identical to variable names, but methods in Java are already distinguishable from variables by their specific form. |
| 7. Abbreviations and acronyms should not be uppercase when used as name. |
| exportHtmlSource(); // NOT: exportHTMLSource(); openDvdPlayer(); // NOT: openDVDPlayer(); |
| Using all uppercase for the base name will give conflicts with the naming conventions given above. A variable of this type whould have to be named dVD, hTML etc. which obviously is not very readable. Another problem is illustrated in the examples above; When the name is connected to another, the readability is seriously reduced; The word following the acronym does not stand out as it should. |
| 8. Private class variables should have underscore suffix. |
| class Person { private String name_; ... } |
| Apart from its name and its type, the scope of a variable is its most important feature. Indicating class scope by using underscore makes it easy to distinguish class variables from local scratch variables. This is important because class variables are considered to have higher significance than method variables, and should be treated with special care by the programmer.
A side effect of the underscore naming convention is that it nicely resolves the problem of finding reasonable variable names for setter methods: void setName(String name) An issue is whether the underscore should be added as a prefix or as a suffix. Both practices are commonly used, but the latter is recommended because it seem to best preserve the readability of the name. It should be noted that scope identification in variables have been a controversial issue for quite some time. It seems, though, that this practice now is gaining acceptance and that it is becoming more and more common as a convention in the professional development community. |
| 9. Generic variables should have the same name as their type. |
| void setTopic(Topic topic) // NOT: void setTopic(Topic value) // NOT: void setTopic(Topic aTopic) // NOT: void setTopic(Topic t) void connect(Database database) // NOT: void connect(Database db) // NOT: void connect(Database oracleDB) |
| Reduce complexity by reducing the number of terms and names used. Also makes it easy to deduce the type given a variable name only.
If for some reason this convention doesn't seem to fit it is a strong indication that the type name is badly chosen. Point startingPoint, centerPoint; |
| 10. All names should be written in English. |
| English is the preferred language for international development. |
| 11. Variables with a large scope should have long names, variables with a small scope can have short names [1]. |
| Scratch variables used for temporary storage or indices are best kept short. A programmer reading such variables should be able to assume that its value is not used outside a few lines of code. Common scratch variables for integers are i, j, k, m, n and for characters c and d. |
| 12. The name of the object is implicit, and should be avoided in a method name. |
| line.getLength(); // NOT: line.getLineLength(); |
| The latter might seem natural in the class declaration, but proves superfluous in use, as shown in the example. |
3.2 Specific Naming Conventions
| 13. The terms get/set must be used where an attribute is accessed directly. |
| employee.getName(); employee.setName(name); matrix.getElement(2, 4); matrix.setElement(2, 4, value); |
| Common practice in the Java community and the convention used by Sun for the Java core packages. |
| 14. is prefix should be used for boolean variables and methods. |
| isSet, isVisible, isFinished, isFound, isOpen |
| This is the naming convention for boolean methods and variables used by Sun for the Java core packages.
Using the is prefix solves a common problem of choosing bad boolean names like status or flag. isStatus or isFlag simply doesn't fit, and the programmer is forced to chose more meaningful names. Setter methods for boolean variables must have set prefix as in: void setFound(boolean isFound); There are a few alternatives to the is prefix that fits better in some situations. These are has, can and should prefixes: boolean hasLicense(); |
| 15. The term compute can be used in methods where something is computed. |
| valueSet.computeAverage(); matrix.computeInverse() |
| Give the reader the immediate clue that this is a potential time consuming operation, and if used repeatedly, he might consider caching the result. Consistent use of the term enhances readability. |
| 16. The term find can be used in methods where something is looked up. |
| vertex.findNearestVertex(); matrix.findSmallestElement(); node.findShortestPath(Node destinationNode); |
| Give the reader the immediate clue that this is a simple look up method with a minimum of computations involved. Consistent use of the term enhances readability. |
| 17. The term initialize can be used where an object or a concept is established. |
| printer.initializeFontSet(); |
| The American initializeshould be preferred over the English initialise. Abbreviation init must be avoided. |
| 18. JFC (Java Swing) variables should be suffixed by the element type. |
| widthScale, nameTextField, leftScrollbar, mainPanel, fileToggle, minLabel, printerDialog |
| Enhances readability since the name gives the user an immediate clue of the type of the variable and thereby the available resources of the object. |
| 19. Plural form should be used on names representing a collection of objects. |
| Collection<Point> points; int[] values; |
| Enhances readability since the name gives the user an immediate clue of the type of the variable and the operations that can be performed on its elements. |
| 20. n prefix should be used for variables representing a number of objects. |
| nPoints, nLines |
| The notation is taken from mathematics where it is an established convention for indicating a number of objects.
Note that Sun use num prefix in the core Java packages for such variables. This is probably meant as an abbreviation of number of, but as it looks more like number it makes the variable name strange and misleading. If "number of" is the preferred phrase, numberOf prefix can be used instead of just n. num prefix must not be used. |
| 21. No suffix should be used for variables representing an entity number. |
| tableNo, employeeNo |
| The notation is taken from mathematics where it is an established convention for indicating an entity number.
An elegant alternative is to prefix such variables with an i: iTable, iEmployee. This effectively makes them named iterators. |
| 22. Iterator variables should be called i, j, k etc. |
| for (Iterator i = points.iterator(); i.hasNext(); ) { : } for (int i = 0; i < nTables; i++) { : } |
| The notation is taken from mathematics where it is an established convention for indicating iterators.
Variables named j, k etc. should be used for nested loops only. |
| 23. Complement names must be used for complement entities [1]. |
| get/set, add/remove, create/destroy, start/stop, insert/delete, increment/decrement, old/new, begin/end, first/last, up/down, min/max, next/previous, old/new, open/close, show/hide, suspend/resume, etc. |
| Reduce complexity by symmetry. |
| 24. Abbreviations in names should be avoided. |
| computeAverage(); // NOT: compAvg(); ActionEvent event; // NOT: ActionEvent e; catch (Exception exception) { // NOT: catch (Exception e) { |
| There are two types of words to consider. First are the common words listed in a language dictionary. These must never be abbreviated. Never write:
cmd instead of command Then there are domain specific phrases that are more naturally known through their acronym or abbreviations. These phrases should be kept abbreviated. Never write: HypertextMarkupLanguage instead of html |
| 25. Negated boolean variable names must be avoided. |
| bool isError; // NOT: isNoError bool isFound; // NOT: isNotFound |
| The problem arise when the logical not operator is used and double negative arises. It is not immediately apparent what !isNotError means. |
| 26. Associated constants (final variables) should be prefixed by a common type name. |
| final int COLOR_RED = 1; final int COLOR_GREEN = 2; final int COLOR_BLUE = 3; |
| This indicates that the constants belong together, and what concept the constants represents.
An alternative to this approach is to put the constants inside an interface effectively prefixing their names with the name of the interface: interface Color |
| 27. Exception classes should be suffixed with Exception. |
| class AccessException extends Exception { : } |
| Exception classes are really not part of the main design of the program, and naming them like this makes them stand out relative to the other classes. This standard is followed by Sun in the basic Java library. |
| 28. Default interface implementations can be prefixed by Default. |
| class DefaultTableCellRenderer implements TableCellRenderer { : } |
| It is not uncommon to create a simplistic class implementation of an interface providing default behaviour to the interface methods. The convention of prefixing these classes by Default has been adopted by Sun for the Java library. |
| 29. Singleton classes should return their sole instance through method getInstance. |
| class UnitManager { private final static UnitManager instance_ = new UnitManager(); private UnitManager() { ... } public static UnitManager getInstance() // NOT: get() or instance() or unitManager() etc. { return instance_; } } |
| Common practice in the Java community though not consistently followed by Sun in the JDK. The above layout is the preferred pattern. |
| 30. Classes that creates instances on behalf of others (factories) can do so through method new[ClassName] |
| class PointFactory { public Point newPoint(...) { ... } } |
| Indicates that the instance is created by new inside the factory method and that the construct is a controlled replacement of new Point(). |
| 31. Functions (methods returning an object) should be named after what they return and procedures (void methods) after what they do. |
| Increase readability. Makes it clear what the unit should do and especially all the things it is not supposed to do. This again makes it easier to keep the code clean of side effects. |
4. Files
| 32. Java source files should have the extension .java. |
| Point.java |
| Enforced by the Java tools. |
| 33. Classes should be declared in individual files with the file name matching the class name. Secondary private classes can be declared as inner classes and reside in the file of the class they belong to. |
| Enforced by the Java tools. |
| 34. File content must be kept within 80 columns. |
| 80 columns is the common dimension for editors, terminal emulators, printers and debuggers, and files that are shared between several developers should keep within these constraints. It improves readability when unintentional line breaks are avoided when passing a file between programmers. |
| 35. Special characters like TAB and page break must be avoided. |
| These characters are bound to cause problem for editors, printers, terminal emulators or debuggers when used in a multi-programmer, multi-platform environment. |
| 36. The incompleteness of split lines must be made obvious [1]. |
| totalSum = a + b + c + d + e; method(param1, param2, param3); setText ("Long line split" + "into two parts."); for (int tableNo = 0; tableNo < nTables; tableNo += tableStep) { ... } |
| Split lines occurs when a statement exceed the 80 column limit given above. It is difficult to give rigid rules for how lines should be split, but the examples above should give a general hint.
In general:
|
5. Statements
5.1 Package and Import Statements
| 37. The package statement must be the first statement of the file. All files should belong to a specific package. |
| The package statement location is enforced by the Java language. Letting all files belong to an actual (rather than the Java default) package enforces Java language object oriented programming techniques. |
| 38. The import statements must follow the package statement. import statements should be sorted with the most fundamental packages first, and grouped with associated packages together and one blank line between groups. |
| import java.io.IOException; import java.net.URL; import java.rmi.RmiServer; import java.rmi.server.Server; import javax.swing.JPanel; import javax.swing.event.ActionEvent; import org.linux.apache.server.SoapServer; |
| The import statement location is enforced by the Java language. The sorting makes it simple to browse the list when there are many imports, and it makes it easy to determine the dependiencies of the present package The grouping reduce complexity by collapsing related information into a common unit. |
| 39. Imported classes should always be listed explicitly. |
| import java.util.List; // NOT: import java.util.*; import java.util.ArrayList; import java.util.HashSet; |
| Importing classes explicitly gives an excellent documentation value for the class at hand and makes the class easier to comprehend and maintain.
Appropriate tools should be used in order to always keep the import list minimal and up to date. |
5.2 Classes and Interfaces
40. Class and Interface declarations should be organized in the following manner:
|
| Reduce complexity by making the location of each class element predictable. |
5.3 Methods
| 41. Method modifiers should be given in the following order: <access> static abstract synchronized <unusual> final native The <access> modifier (if present) must be the first modifier. |
| public static double square(double a); // NOT: static public double square(double a); |
| <access> is one of public, protected or private while <unusual> includes volatile and transient. The most important lesson here is to keep the access modifier as the first modifier. Of the possible modifiers, this is by far the most important, and it must stand out in the method declaration. For the other modifiers, the order is less important, but it make sense to have a fixed convention. |
5.4 Types
| 42. Type conversions must always be done explicitly. Never rely on implicit type conversion. |
| floatValue = (int) intValue; // NOT: floatValue = intValue; |
| By this, the programmer indicates that he is aware of the different types involved and that the mix is intentional. |
| 43. Array specifiers must be attached to the type not the variable. |
| int[] a = new int[20]; // NOT: int a[] = new int[20] |
| The arrayness is a feature of the base type, not the variable. It is not known why Sun allows both forms. |
5.5 Variables
| 44. Variables should be initialized where they are declared and they should be declared in the smallest scope possible. |
| This ensures that variables are valid at any time. Sometimes it is impossible to initialize a variable to a valid value where it is declared. In these cases it should be left uninitialized rather than initialized to some phony value. |
| 45. Variables must never have dual meaning. |
| Enhances readability by ensuring all concepts are represented uniquely. Reduce chance of error by side effects. |
| 46. Class variables should never be declared public. |
| The concept of Java information hiding and encapsulation is violated by public variables. Use private variables and access functions instead. One exception to this rule is when the class is essentially a data structure, with no behavior (equivalent to a C++ struct). In this case it is appropriate to make the class' instance variables public [2]. |
| 47. Arrays should be declared with their brackets next to the type. |
| double[] vertex; // NOT: double vertex[]; int[] count; // NOT: int count[]; public static void main(String[] arguments) public double[] computeVertex() |
| The reason for is twofold. First, the array-ness is a feature of the class, not the variable. Second, when returning an array from a method, it is not possible to have the brackets with other than the type (as shown in the last example). |
| 48. Variables should be kept alive for as short a time as possible. |
| Keeping the operations on a variable within a small scope, it is easier to control the effects and side effects of the variable. |
5.6 Loops
| 49. Only loop control statements must be included in the for() construction. |
| sum = 0; // NOT: for (i = 0, sum = 0; i < 100; i++) for (i = 0; i < 100; i++) sum += value[i]; sum += value[i]; |
| Increase maintainability and readability. Make a clear distinction of what controls and what is contained in the loop. |
| 50. Loop variables should be initialized immediately before the loop. |
| isDone = false; // NOT: bool isDone = false; while (!isDone) { // : : // while (!isDone) { } // : // } |
| 51. The use of do-while loops can be avoided. |
| do-while loops are less readable than ordinary while loops and for loops since the conditional is at the bottom of the loop. The reader must scan the entire loop in order to understand the scope of the loop.
In addition, do-while loops are not needed. Any do-while loop can easily be rewritten into a while loop or a for loop. Reducing the number of constructs used enhance readbility. |
| 52. The use of break and continue in loops should be avoided. |
| These statements should only be used if they prove to give higher readability than their structured counterparts. |
5.7 Conditionals
| 53. Complex conditional expressions must be avoided. Introduce temporary boolean variables instead [1]. |
| bool isFinished = (elementNo < 0) || (elementNo > maxElement); bool isRepeatedEntry = elementNo == lastElement; if (isFinished || isRepeatedEntry) { : } // NOT: if ((elementNo < 0) || (elementNo > maxElement)|| elementNo == lastElement) { : } |
| By assigning boolean variables to expressions, the program gets automatic documentation. The construction will be easier to read, debug and maintain. |
| 54. The nominal case should be put in the if-part and the exception in the else-part of an if statement [1]. |
| boolean isOk = readFile(fileName); if (isOk) { : } else { : } |
| Makes sure that the exceptions does not obscure the normal path of execution. This is important for both the readability and performance. |
| 55. The conditional should be put on a separate line. |
| if (isDone) // NOT: if (isDone) doCleanup(); doCleanup(); |
| This is for debugging purposes. When writing on a single line, it is not apparent whether the test is really true or not. |
| 56. Executable statements in conditionals must be avoided. |
| InputStream stream = File.open(fileName, "w"); if (stream != null) { : } // NOT: if (File.open(fileName, "w") != null)) { : } |
| Conditionals with executable statements are simply very difficult to read. This is especially true for programmers new to Java. |
5.8 Miscellaneous
| 57. The use of magic numbers in the code should be avoided. Numbers other than 0 and 1can be considered declared as named constants instead. |
| private static final int TEAM_SIZE = 11; : Player[] players = new Player[TEAM_SIZE]; // NOT: Player[] players = new Player[11]; |
| If the number does not have an obvious meaning by itself, the readability is enhanced by introducing a named constant instead. |
| 58. Floating point constants should always be written with decimal point and at least one decimal. |
| double total = 0.0; // NOT: double total = 0; double speed = 3.0e8; // NOT: double speed = 3e8; double sum; : sum = (a + b) * 10.0; |
| This emphasize the different nature of integer and floating point numbers. Mathematically the two model completely different and non-compatible concepts.
Also, as in the last example above, it emphasize the type of the assigned variable (sum) at a point in the code where this might not be evident. |
| 59. Floating point constants should always be written with a digit before the decimal point. |
| double total = 0.5; // NOT: double total = .5; |
| The number and expression system in Java is borrowed from mathematics and one should adhere to mathematical conventions for syntax wherever possible. Also, 0.5 is a lot more readable than .5; There is no way it can be mixed with the integer 5. |
| 60. Static variables or methods must always be refered to through the class name and never through an instance variable. |
| Thread.sleep(1000); // NOT: thread.sleep(1000); |
| This emphasize that the element references is static and independent of any particular instance. For the same reason the class name should also be included when a variable or method is accessed from within the same class. |
6. Layout and Comments
6.1 Layout
| 61. Basic indentation should be 2. |
| for (i = 0; i < nElements; i++) a[i] = 0; |
| Indentation is used to emphasize the logical structure of the code. Indentation of 1 is to small to acheive this. Indentation larger than 4 makes deeply nested code difficult to read and increase the chance that the lines must be split. Choosing between indentation of 2, 3 and 4; 2 and 4 are the more common, and 2 chosen to reduce the chance of splitting code lines. Note that the Sun recommendation on this point is 4. |
| 62. Block layout should be as illustrated in example 1 below (recommended) or example 2, and must not be as shown in example 3. Class, Interface and method blocks should use the block layout of example 2. | ||
| while (!done) { doSomething(); done = moreToDo(); } |
while (!done) { doSomething(); done = moreToDo(); } | while (!done) { doSomething(); done = moreToDo(); } |
| Example 3 introduce an extra indentation level which doesn't emphasize the logical structure of the code as clearly as example 1 and 2. | ||
| 63. The class and interface declarations should have the following form: |
| class Rectangle extends Shape implements Cloneable, Serializable { ... } |
| This follows from the general block rule above. Note that it is common in the Java developer community to have the opening bracket at the end of the line of the class keyword. This is not recommended. |
| 64. Method definitions should have the following form: |
| public void someMethod() throws SomeException { ... } |
| See comment on class statements above. |
| 65. The if-else class of statements should have the following form: |
| if (condition) { statements; } if (condition) { statements; } else { statements; } if (condition) { statements; } else if (condition) { statements; } else { statements; } |
This follows partly from the general block rule above. However, it might be discussed if an else clause should be on the same line as the closing bracket of the previous if or else clause:
if (condition) {
This is equivalent to the Sun recommendation. The chosen approach is considered better in the way that each part of the if-else statement is written on separate lines of the file. This should make it easier to manipulate the statement, for instance when moving else clauses around. |
| 66. The for statement should have the following form: |
| for (initialization; condition; update) { statements; } |
| This follows from the general block rule above. |
| 67. An empty for statement should have the following form: |
| for (initialization; condition; update) ; |
| This emphasize the fact that the for statement is empty and it makes it obvious for the reader that this is intentional. |
| 68. The while statement should have the following form: |
| while (condition) { statements; } |
| This follows from the general block rule above. |
| 69. The do-while statement should have the following form: |
| do { statements; } while (condition); |
| This follows from the general block rule above. |
| 70. The switch statement should have the following form: |
| switch (condition) { case ABC : statements; // Fallthrough case DEF : statements; break; case XYZ : statements; break; default : statements; break; } |
| This differs slightly from the Sun recommendation both in indentation and spacing. In particular, each case keyword is indented relative to the switch statement as a whole. This makes the entire switch statement stand out. Note also the extra space before the : character. The explicit Fallthrough comment should be included whenever there is a case statement without a break statement. Leaving the break out is a common error, and it must be made clear that it is intentional when it is not there. |
| 71. A try-catch statement should have the following form: |
| try { statements; } catch (Exception exception) { statements; } try { statements; } catch (Exception exception) { statements; } finally { statements; } |
| This follows partly from the general block rule above. This form differs from the Sun recommendation in the same way as the if-else statement described above. |
| 72. Single statement if-else, for or while statements can be written without brackets. |
| if (condition) statement; while (condition) statement; for (initialization; condition; update) statement; |
| It is a common recommendation (Sun Java recommendation included) that brackets should always be used in all these cases. However, brackets are in general a language construct that groups several statements. Brackets are per definition superfluous on a single statement. A common argument against this syntax is that the code will break if an additional statement is added without also adding the brackets. In general however, code should never be written to accommodate for changes that might arise. |
6.2 White Space
| 73. - Operators should be surrounded by a space character. - Java reserved words should be followed by a white space. - Commas should be followed by a white space. - Colons should be surrounded by white space. - Semicolons in for statements should be followed by a space character. |
| a = (b + c) * d; // NOT: a=(b+c)*d while (true) { // NOT: while(true){ ... doSomething(a, b, c, d); // NOT: doSomething(a,b,c,d); case 100 : // NOT: case 100: for (i = 0; i < 10; i++) { // NOT: for(i=0;i<10;i++){ ... |
| Makes the individual components of the statements stand out and enhances readability. It is difficult to give a complete list of the suggested use of whitespace in Java code. The examples above however should give a general idea of the intentions. |
| 74. Method names can be followed by a white space when it is followed by another name. |
| doSomething (currentFile); |
| Makes the individual names stand out. Enhances readability. When no name follows, the space can be omitted (doSomething()) since there is no doubt about the name in this case.
An alternative to this approach is to require a space after the opening parenthesis. Those that adhere to this standard usually also leave a space before the closing parentheses: doSomething( currentFile );. This do make the individual names stand out as is the intention, but the space before the closing parenthesis is rather artificial, and without this space the statement looks rather asymmetrical (doSomething( currentFile);). |
| 75. Logical units within a block should be separated by one blank line. |
| // Create a new identity matrix Matrix4x4 matrix = new Matrix4x4(); // Precompute angles for efficiency double cosAngle = Math.cos(angle); double sinAngle = Math.sin(angle); // Specify matrix as a rotation transformation matrix.setElement(1, 1, cosAngle); matrix.setElement(1, 2, sinAngle); matrix.setElement(2, 1, -sinAngle); matrix.setElement(2, 2, cosAngle); // Apply rotation transformation.multiply(matrix); |
| Enhances readability by introducing white space between logical units. Each block is often introduced by a comment as indicated in the example above. |
| 76. Methods should be separated by three blank lines. |
| By making the space larger than space within a method, the methods will stand out within the class. |
| 77. Variables in declarations can be left aligned. |
| TextFile file; int nPoints; double x, y; |
| Enhances readability. The variables are easier to spot from the types by alignment. |
| 78. Statements should be aligned wherever this enhances readability. |
| if (a == lowValue) compueSomething(); else if (a == mediumValue) computeSomethingElse(); else if (a == highValue) computeSomethingElseYet(); value = (potential * oilDensity) / constant1 + (depth * waterDensity) / constant2 + (zCoordinateValue * gasDensity) / constant3; minPosition = computeDistance(min, x, y, z); averagePosition = computeDistance(average, x, y, z); switch (phase) { case PHASE_OIL : text = "Oil"; break; case PHASE_WATER : text = "Water"; break; case PHASE_GAS : text = "Gas"; break; } |
| There are a number of places in the code where white space can be included to enhance readability even if this violates common guidelines. Many of these cases have to do with code alignment. General guidelines on code alignment are difficult to give, but the examples above should give some general hints. In short, any construction that enhances readability should be allowed. |
6.3 Comments
| 79. Tricky code should not be commented but rewritten [1]. |
| In general, the use of comments should be minimized by making the code self-documenting by appropriate name choices and an explicit logical structure. |
| 80. All comments should be written in English. |
| In an international environment English is the preferred language. |
| 81. Javadoc comments should have the following form: |
| /** * Return lateral location of the specified position. * If the position is unset, NaN is returned. * * @param x X coordinate of position. * @param y Y coordinate of position. * @param zone Zone of position. * @return Lateral location. * @throws IllegalArgumentException If zone is <= 0. */ public double computeLocation(double x, double y, int zone) throws IllegalArgumentException { ... } |
| A readable form is important because this type of documentation is typically read more often inside the code than it is as processed text.
Note in particular:
Javadoc of class members can be specified on a single line as follows: /** Number of connections to this database */ |
| 82. There should be a space after the comment identifier. |
| // This is a comment NOT: //This is a comment /** NOT: /** * This is a javadoc *This is a javadoc * comment *comment */ */ |
| Improves readability by making the text stand out. |
| 83. Use // for all non-JavaDoc comments, including multi-line comments. |
| // Comment spanning // more than one line. |
| Since multilevel Java commenting is not supported, using // comments ensure that it is always possible to comment out entire sections of a file using /* */ for debugging purposes etc. |
| 84. Comments should be indented relative to their position in the code [1]. |
| while (true) { // NOT: while (true) { // Do something // Do something something(); something(); } } |
| This is to avoid that the comments break the logical structure of the program. |
| 85. The declaration of anonymous collection variables should be followed by a comment stating the common type of the elements of the collection. |
| private Vector points_; // of Point private Set shapes_; // of Shape |
| Without the extra comment it can be hard to figure out what the collection consist of, and thereby how to treat the elements of the collection. In methods taking collection variables as input, the common type of the elements should be given in the associated JavaDoc comment.
Whenever possible one should of course qualify the collection with the type to make the comment superflous: private Vector<Point> points_; |
| 86. All public classes and public and protected functions within public classes should be documented using the Java documentation (javadoc) conventions. |
| This makes it easy to keep up-to-date online code documentation. |
7. References
[1] Code Complete, Steve McConnel - Microsoft Press
[2] Java Code Conventions
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
[3] Netscape's Software Coding Standards for Java
http://developer.netscape.com/docs/technote/java/codestyle.html
[4] C / C++ / Java Coding Standards from NASA
http://v2ma09.gsfc.nasa.gov/coding_standards.html
http://www.ambysoft.com/javaCodingStandards.html
High Availability on Linux Server
비용을 고려한 고 가용성 서버를 구성할려면 리눅스 버추얼 서버를 구성하는 방법을 소개합니다.
원칙은 비싼 하드웨어 보다는 값싼 리눅스 서버를 활용하는 것입니다.

작동 방식은 아래와 같습니다.
Load Balancer는 보통 L4나 L7으로 구성하는데 이는 비용이 많아서 싼 리눅스 서버를 두고 Load Balancer를 둔다. 이 Load Balancer는 모니터링 데몬이 HeartBeat 메세지를 통해 Primary와 Backup간이 서버의 상태를 확인하여 SFP(Single Failure Point)를 제거하게 됩니다.
물론 이 때의 요청 Connection의 정보는 소실되어 고객은 재 요청을 해야만 원만한 서비스를 받게 됩니다. 만약 백업과 Primary가 전이되었을 경우 커넥션 정보를 같이 전이 시키기 위해서는 IPVS load balancer를 사용하여 주기적으로 Primary와 백업간에 Multiple UDP를 통해 커넥션 정보를 동기화하게 됩니다.
만약에 이용자가 기하 급수적으로 늘어난다면 캐싱 시스템을 도입을 검토해야 합니다. Cache strategy을 도입하여 웹서버나 데이터 베이스 서버의 무리가 없도록 부하 분산 전략이 필요합니다.
Epril 제 1회 스프링 공개 세미나 참석 후기
이프릴에서 Spring 관련 세미나를 한다고 하여 몇주전에 신청을 한게 이번주 토요일에 한다고 메일로 왔습니다. 오픈 소스의 관심이 있어서 세미나가 있는 곳이면, 시간이 허락한다면 마다하지 않고 다니는 편이라서 좋은 기회라고 생각하고 오늘 참석을 했습니다.
오픈 소스란게 완벽하게 자기 자신의 것으로 소화하지 않으면 문제가 발생하였을 때 복구 능력이 현저하게 떨어지게 마련이죠. 스스로 복구할 능력이 요구되는 면이 많죠.
물론 전문가를 알고 있다면 문제는 다르죠. 하지만 대부분의 개발자가 처한 현실은 그렇지 못하죠.
1. 시간 : 13:00 ~ 17:00
2. 위치 : 소프트웨어 진흥원 지하1층에 위치한 강의장(식당 개조 ^^)
3. 내용
3.1 다중 레이어 환경에서 Spring을 활용한 통합 테스트 및 단위 테스트 방안(발표자:안영회)
- 테스트의 중요성은 아무리 강조해도 지나침이 없죠. 대부분 테스트는 프로젝트의 시간을 잡아먹는 벌레라고 치부하여 간단한 단위 테스트만들 하고 프로젝트를 오픈하게 되는 경우가 많죠. 저만 그런가요?
그 때마다 느끼는 데 시간에 쫓기다보니 테스트 단계를 소홀히하는 부분이 많게 됩니다. 테스트가 시간을 내서 한다는 생각을 일단 버려야할 것입니다. 방법론이 그렇듯이 자기 스타일에 맞게 표준화된 방식을 갖고 자기(현실)화하는 것이 가장 중요하다고 생각합니다. 자기화하여 굳이 시간을 일부로 내어 테스트 하기 보다는 자기가 설계에서부터 테스트에 대한 개념을 가지고 개발에 이르기까지 코드 속에 녹아들게 하는 것이 중요합니다.
그렇게 함으로써 개발과 동시에 추가의 시간이 없이 기본적인 단위, 통합 테스트가 가능하죠. 물론 QA를 하지 않는다는 건 아니죠. 그만큼 사전에 위험 요소를 발견하여 개발자 단계에서 많은 숨은 버그를 도출해 내게 되는 거죠. 제가 지금까지 말한 건 개발자가 할 테스트에 대한 부분이라고 생각하시면 됩니다.
서문이 길었네요. 안영회님은 블로그를 통해 알아오다가 처음 보게되었습니다. 말씀도 준비를 잘 하셔서 그런지 흐름의 맥을 잘 이어서 발표를 하신거 같네요. 몰랐던 부을 생각나게 해주시고 좀 더 개발자가 효율적으로 테스트를 할 수 있는 방안에 대해서 나름의 시현까지 보이시고 하는 모습들이 참 보기 좋았습니다. 내용도 물론 알차구요.
DependencyInjection, Autowiring(Type -> Name) 등등..
3.2 XML 스키마 기반 빈 선언을 이용한 자유로운 XML Configuration Customization(발표자:이일민)
- Configuration을 좀더 가독성있고 효율적으로 관리할 수 있는 방안들을 아직은 많은 이들이 시도를 하지 않고 있지만 스키마 방식으로 표현할 수 있는 방법들을 알려주셨구요.
그리고 커스텀 스키마 부분(NameHandling, Properties...중간에 회사에서 전화와서 기억이 없음). 이 세션은 PHP의 Extension을 보는듯한 느낌입니다. 자기가 필요한 스키마를 만들어서 사용할 수 있는 방법을 설명하셨습니다. 물론 이부분은 신중함이 필요할 듯 합니다. 자기 자신만의 스키마를 다른 사람이 이해하기 힘들테니깐요. 이관 프로세스가 확실한 회사에서는 공통 표준을 사용하는 편이 나아보입니다.
물론 누구나 잘 알수 있도록 Description이 있다면 크게 문제가 되진 않겠죠. ^^
3.3 Q&A
- NHN의 박재성님께서 Webwork + Spring + iBATIS 웹 서비스의 표준 프레임워크와 되었다고 합니다.
- Spring 진영(Non EJB 진영)과 Hibernate(JBoss에 인수됨-EJB 진영)진영의 불협화음에 관한 내용..호사가들의 입방아에 오르기 좋은 꺼리가 여기에서도 나왔네요.
- 이동국님도 Q&A의 패널로 참석해 주셨네요.
PS : 영회님과 토비님을 개인적으로 만나서 인맥도 쌓을 겸 커피 타임을 가질려구 했으나 주위에서 워낙 많은 분들에게 둘러싸여 있어서 진입장벽(?-핑계?)이 있어서 만나질 못한게 제일 후회스럽다. 이 부분에 대해서는 내 자신에게도 불만족했다.
성능 시험 방법론 과 실무 저자 특강 참석 후기
한빛 미디어에서 저자 직강 세미나가 있어서 참여했다. Web2.0 기획론 특강에 이은 두번째다.
1. 장소 : 한빛 교육 센터 2007/4/14 14:00 ~ 18:00
2. 강의 내용
2.1 성능 시험 관련 용어 정의
Named User, Concurrent User, Response Time, Think Time, Request Interval, Throughput, TPS 등등 용어 정의.
2.2 성능 시험 기초 이론
Queuing Network Model, Operational Law에 대한 이해가 있어야 함.
2.3 성능 시험 방법론 소개
분석, 설계, 이행, 평가에 이르는 절차와 방법 소개.
2.4 용량 계획
용량 계획의 정의, 효과, 유형, 절차에 대한 내용을 쉽게 설명해 주었다.
전체적인 내용은 쉽게 이해하기에는 어려움이 있었지만 전체의 성능 방법론에 대한 흐름을 이해하고 어떻게 관리하는 지 등의 관리 방법에 대한 이해를 하기에 좋은 기회였던 것 같습니다. 그리고 강사님의 실 사례에 대한 예시는 피부로 느끼기엔 충분했습니다.
책의 예시에서 나오는 WorkLoad를 분석하는 툴을 사용하여 성능을 주별로 관리하여 오픈 초기의 임계치와 비교하여 서버의 가용성을 계속 관리하여야겠다는 생각이 드네요. 예전에 성능 테스트를 위해서 개발한 프로그램이 있는데 일단 그걸 만들길 잘했다는 생각이 든다. 일단 운영 중인 로그를 설정하여 주기적으로 관리를 해 봐야겠습니다.
브레인 라이팅(Brainwriting)과 브레인 스토밍(Brainstorming)과의 관계
브레인 스토밍은 매디슨 애버뉴(Madison Avenue)의 홍보팀 중역이던 알렉스 오스본(Alex Osborn)이 처음 개발한 것으로, 1946년 출간된 그의 저서 ‘응용 상상력(applied Imagination)’에 자세히 설명되어 있다. 브레인 스토밍 개념은 그 이후로 급격히 발전되었고, 세계 모든 조직들이 특정한 상황에서 다양한 아이디어를 짜내는데 사용되게 되었습니다.
브레인 라이팅은 독일에서 나온 것으로써 그룹이 아이디어를 고안할 때 아이디어를 조용히 글로 써서 내놓는 작업을 말합니다.
모든 여건이 똑같을 경우, 브레인 라이팅 그룹이 브레인 스토밍 그룹에 비해 더 많은 아이디어를 창출한다고 합니다. 왜 그럴까요?
우린 브레인 스토밍 과정에서 하지 말아야 할 것들을 하게 되죠. 내가 말하는 것이 논리적인지 한번 더 생각하게 되고, 내 뱉은 말조차 호사가들의 입에서 반박과 설전에 의해 다양한 이슈와 의견이 사장되는 경우가 많아서 그렇지 않을까 생각해 봅니다.
그럼 이런건 어떨까요? 브레인 라이팅과 브레인 스토밍의 결합으로 좀더 효율적으로 효과적아이디어를 얻는 방법은 없을까요?
개인적으로 특정 주제에 대한 자신의 생각을 주변 상황을 고려하지 않고 써내려단 다음, 브레인 스토밍으로 한가지 의견이 아닌 다양한 의견을 자신이 적은 내용을 발표하는 식으로 하는 것이 좋을듯 합니다.
브레인 라이팅으로만 할 경우 의사 전달 및 의미 오용 등의 부작용도 있을 수 있고 인간은 사회적 동물이기에 수다떨기에 좋아하는 동물 아닙니까? ^^ 수다를 떨면서 자신의 의견을 표출하면서 자신감을 찾을 수 있고 열정을 갖게 되는 거죠. 그러면 좀 더 나은 아이디어가 나오게 되는 선순환 구조의 좋은 본보기일 것 같네요.
두가지를 잘 활용한다면 좋은 의견, 지식을 확보할 수 있게 될 것 같네요.
오라클 trace 생성 및 분석 방법
- sqlplus 접속
- trace 이벤트를 session에 건다
alter session set events '10046 trace name context forever, level 12'; - sql을 수행한다
- oracle 계정으로 접속하여, 생성된 오라클 trace 로그를 생성시간으로 확인하고 tkprof로 분석한다
/oracle/ORA920/admin/SID/udump> ls -alt | more
/oracle/ORA920/admin/SID/udump> tkprof [trace화일명] [결과화일명] explain=username/password sys=no
- 4의 결과화일을 분석한다(plan결과와 Parse, Execute, Fetch 타임을 확인하여 쿼리를 튜닝한다.
아래는 튜닝한 쿼리입니다.
<< 변경전 쿼리 >>
SELECT /*+ ordered first_rows(1) */
u.userno, u.userid, u.domain, u.iddomain, u.usernm, u.nickname, u.persono,
u.rentry, u.realnmgb, u.myemail, u.infosvc, m.goodsgrp, m.goodscd, m.indt,
m.status, g.goodsnm
FROM aaa u ,
bbb m ,
ccc g
WHERE m.userno = u.userno
AND u.dupid = 'aaa'
AND m.goodsgrp = g.goodsgrp
AND m.goodscd = g.goodscd
AND ( m.goodscd BETWEEN '1'
AND '3'
OR m.goodscd BETWEEN '4'
AND '5' )
<< 변경전 stat >>
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 3.29 3.21 6 36326 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 3.29 3.21 6 36326 0 1
<< 변경전 plan >>
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: HINT: FIRST_ROWS
1 CONCATENATION
1 HASH JOIN
1 HASH JOIN
3 TABLE ACCESS (BY INDEX ROWID) OF 'AAA'
3 INDEX (RANGE SCAN) OF 'AAA_DUPID_IDX' (NON-UNIQUE)
50027 TABLE ACCESS (BY INDEX ROWID) OF 'BBB'
50027 INDEX (RANGE SCAN) OF 'BBB_GOODSCD_IDX' (NON-UNIQUE)
584 TABLE ACCESS (FULL) OF 'CCC'
0 HASH JOIN
0 HASH JOIN
3 TABLE ACCESS (BY INDEX ROWID) OF 'AAA'
3 INDEX (RANGE SCAN) OF 'USERMAST_DUPID_IDX' (NON-UNIQUE)
321514 TABLE ACCESS (BY INDEX ROWID) OF 'BBB'
321514 INDEX (RANGE SCAN) OF 'BBB_GOODSCD_IDX' (NON-UNIQUE)
0 TABLE ACCESS (FULL) OF 'CCC'
<< 변경후 쿼리 >>
SELECT /*+ ordered use_nl(m,g) */
u.userno, u.userid , u.domain, u.iddomain, u.usernm, u.nickname, u.persono,
u.rentry, u.realnmgb, u.myemail, u.infosvc, m.goodsgrp, m.goodscd, m.indt,
m.status, g.goodsnm
FROM aaa u ,
bbb m ,
ccc g
WHERE m.userno = u.userno
AND u.dupid = 'aaa'
AND m.goodsgrp = g.goodsgrp
AND m.goodscd = g.goodscd
AND ( m.goodscd BETWEEN '1'
AND '3'
OR m.goodscd BETWEEN '4'
AND '5' )
and rownum = 1
<< 변경후 stat >>
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.02 3 17 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.02 0.03 3 17 0 1
<< 변경후 plan >>
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: CHOOSE
1 COUNT (STOPKEY)
1 TABLE ACCESS (BY INDEX ROWID) OF 'CCC'
2 NESTED LOOPS
1 NESTED LOOPS
2 TABLE ACCESS (BY INDEX ROWID) OF 'AAA'
2 INDEX (RANGE SCAN) OF 'AAA_DUPID_IDX' (NON-UNIQUE)
1 TABLE ACCESS (BY INDEX ROWID) OF 'BBB'
3 INDEX (RANGE SCAN) OF 'BBB_USERNO_IDX' (UNIQUE)
1 INDEX (RANGE SCAN) OF 'CCC_IDX01' (NON-UNIQUE)
Digital Identity의 전망
Digital Identity의 전체 흐름으로도 무방한 좋은 그림이 있어서 올립니다.

- OpenID 2.0은 URL-based 기술(LID, i-names, Yadis, Sxip, XRI) OpenID라는 용어하에 진행되어 옴을 나타내고 있으며
- CardSpace/Higgins는 MS가 주도하는 영역입니다. MS의 Vista에 적용되어 기업 환경에서 많이 이용되고 있고.
- SAML Federation은 OpenID and SAML/Liberty(기업형)의 두 커뮤니티가 협업하여 나중엔 OpenID와 함께 융합된 형태가 되지 않을까 생각됩니다.
OpenID와 WS-*는 사용자가 주체가 되어 제어가 가능한 User-Centric 영역이라고 정의를 또한 했네여. 전체의 흐름을 잘 녹인 좋은 요약 그림입니다.
2007-04-15 일상
오늘은 오랫만에 깁밥을 먹었답니다. 준비를 반나절(^^) 이나 했구요 ^^. 식당에서 먹는 맛과는 차원이 틀렸죠. 정말 맛있었습니다. 질리지도 않고....
메인 요리사는 저의 와이프였고 전 부서진 재료를 먹는게 일이었죠. 참기름에 밥 비비는 거도 제가 했답니다. ^^ 마음껏 김밥을 먹은 하루였답니다.

웹 기반의 이슈 트래킹 시스템 비교
|
웹 기반의 협업이 가능한 이슈 트래킹 시스템을 찾으시는 분들에게 좋은 비교자료 하나 올립니다. 뭐든 업무의 효율성이든, 생산성이 올라가든, 시스템으로 도입한다는 건 많은 장벽이 있기 마련입니다. 학습에서부터 필요에 의해서 자동화 되기까지 많은 업무 로드가 있게 되죠. 없는 것이 나을 수 있습니다. 하지만 장점을 발견하여 몸에 베어 자동화시킨다면 더할나위 없이 업무에 효과를 몸소 느낀다면 도입을 하게 되는거죠. 암튼 빠른 시일내에 좋은 효과를 발휘 했으면 좋겠습니다.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Task Management Product - Smartsheet
Smartsheet는 온라인 상에서 태스크를 관리할 수 있는 Office 2.0의 대표적인 사이트이다. 이 사이트의 라이센스 정책이 유료 기준으로 다양하고 특화된 기능이 많이 있어서 무료 라이센스의 사용에 제약이 많아 보인다. 물론 Collaboration 기능도 있는 등 장점은 많다.
그러나 한글 지원은 아직 미흡한 점이 많네요.

HTTP Debugging Proxy - Fiddler
웹 어플리케이션을 개발자에게 도움이 될 만한 HTTP Debugging Proxy 툴을 하나 소개합니다. 보통 서버 사이드의 로직들은 Header정보를 많이 사용해서 처리하게 되는데, 디버깅 환경이 제공이 많이 되지 않아 웹 어플리케이션 개발에 생산성이 많이 떨어질 것입니다. 또한 실제 문제 발생시에도 빠르게 에러에 대한 대응 능력을 발휘하기에는 개발 환경이 이 안좋은게 현실이죠.
제가 소개하고자 하는 Fiddler는 이 HTTP 요청과 응답 정보를 볼 수 있게 해주는 아주 유용한 툴입니다. 이 Fiddler는 인터넷 프로토콜만을 모니터링해주기 때문에 웹 개발자들에게 아주 유용하죠. 또한 Request Builder가 있어서 실제 응답 요청을 가상으로 만들 수 있어서 더욱 편하게 되죠. 물론 해킹으로 악용될 소지도 많죠. 하지만 오용은 불법이므로 생산적인 업무에 쓰였으면 하는 바램입니다.
아래는 실제 화면을 캡쳐해봤습니다.


참고로 다운 받을 사이트를 알려드리겠습니다.
OpenOffice.org의 Impress 소개
웹에서 공유하거나 모니터에서 재생하는 것이 목적이라면 플래시 파일(SWF)로 변환하는 것이 효과적일 것입니다. PowerPoint 자체에는 이런 기능이 없어서 이런 역할을 하는 별도의 소프트웨어가 설치를 해서 하는 경우가 많을 것입니다.
그러던 중에 OpenOffice.org의 구성 애플리케이션 중 Microsoft PowerPoint와 같은 기능을 하는 Impress가 있다는 것을 알았습니다.
PPT가 미리 작성되어 있거나 OpenOffice에서 작업을 하여 SWF로 변환이 가능하다. 하지만 PPT가 2007버전용(확장자 pptx)이라면 2003버전으로 전환해 두어야 한다. 아직 지원이 안된다.
작동 방법은 [파일] > [내보내기]를 선택하고, 파일 형식을 "Macromedia Flash (SWF) (.swf)"를 선택하여 [저장] 버튼만 눌러주면 된다. 파일 크기가 크다면 변환 과정에 시간이 좀 필요하지만 만족스럽다. 또한 PDF로도 변환할 수 있다.
아래는 제가 작성한 ppt파일을 SWF로 변환한 예입니다. 보여지는 가로 폭에 제한이 있어 가로길이가 조금 잘려있습니다.
Confluence - the Enterprise Wiki 설치
특징
- 로그인 베이스로 운영되어 보안이 강화된 Enterprise적인 특징 반영.
- 간단한 설치와 관리가 가능.
- 위키 문법을 몰라도 되는 user-friendly WYSIWYG interface를 가지고 있음.
- 우수한 검색 기능 제공.
- PDF Export기능 제공.
- Open API(RSS포함)를 통해 확장 및 통합이 가능.
설치 가이드(Confluence Installation Guide EAR-WAR edition참조)
1. 소프트웨어 다운로드.
- Confulence 사이트에서 평가판을 다운 받음.
- Standalone, EAR/WAR 두가지 버젼이 있는데 Standalone은 tomcat서버가 내장되어 있는 것이고 EAR/WAR는 Application Server가 없는 버젼이다. 그래서 기존 운영중인 서버가 있는 경우는 EAR/WAR를 다운로드를 하면 됨.
2. DocumentRoot디렉토리에서 압축을 해제
- gzip -d confluence-2.4.4.tar.gz |tar -xvf
3. 패치 확인
- 최신 버전에 패치가 추가되었을 경우 패치 설치 필요.
4. confluence-init.properties 편집
- confluence.home 디렉토리를 설치된 디렉토리를 주석을 풀고 입력함.(보통은 설치된 디렉토리+confluence가 됨)
5. confluence.xml 등록
- server.xml에서 defaultHosts가 localhost일 경우에 conf/Catalina/localhost 디렉토리 안에 confluence.xml을 등록(tomcat 5.*기준).
<Resource name="jdbc/confluence" auth="Container"
type="javax.sql.DataSource"
username="username"
password="password"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/confluence?autoReconnect=true&
useUnicode=true&characterEncoding=utf-8&
mysqlEncoding=utf8"
validationQuery="Select 1"
maxActicve="20"
maxIdle="3"
removeAbandoned="true"
maxWait="3000" />
</Context>
6. Confluence Setup Guide 안내에 따라 설치
- Install License 화면에서 라이센스를 넣고 NEXT.
- Configure DataBase에서 External Database에서 원하는 데이터베이스 엔진을 선택(전 mysql)
Setup Standard Database에서 Driver, Url, 로긴 아이디, 패스워드를 넣고 NEXT. - Datasource Connection에서 jdbc/confluence 넣고 NEXT.
- 테이블 설치 과정에서 에러가 날 경우에는 직업 mysql에 로그인 하여 create database confluence character set utf8; 커맨드를 실행함.
- Load Content에서 Example Site를 클릭하여 예제를 보는 것이 초보자에게는 도움이 되어 클릭을 함.
- 자기가 원하는 Space를 만들어서 사용함.
- 자세한 건 Confluence 이용 가이드를 참조.
KoreanClick 데이터 산출 방법론
1. 조사 대상 및 적용 범위
- 전국 만 7세에서 65세 국내 거주자 중 성, 연령, 지역, 접속 장소에 따른 무작위 추출 방식으로 표본을 대상으로 조사.
2. 자료 종류 및 수집 방법
- 패털의 컴퓨터에 설치한 iTrack을 통하여 패널이 방문한 사이트 정보를 실시간으로 받은 데이터를 가지고 통계 기법을 적용하여 추정.
- iTrack 수집 데이터는 패널의 PC상태, 브라우져 활성화 여부, URL정보와 페이지 및 Embedded 파일 정보, 이용자의 자발성과 액션 감지, PC에 설치된 인스턴트 메신저 및 어플리케이션 설치 및 이용 정보.
3. 데이터 처리 기준 - Redirection 페이지 처리 : 최종 랜딩 페이지만을 유효한 페이지로 간주하고 중간에 이용 페이지는 제외함.
- 프레임 페이지 처리 기준 : 가장 상위구조의 Navigation Frame만을 유효한 페이지로 측정하고 Embedded 페이지는 제외함.
- Complete 기준, 마우스 드래그 : Complete가 된 페이지에 한해서만 유효로 측정하고 드래그한 더미 페이지는 비유효 페이지로 간주함.
- Cache Page 처리 기준 : PC 내 Browser Cache 상에 저장되어 있었던 웹 페이지의 열람도 페이지 뷰로 카운트함.
- 자발성과 비자발성 팝업/Auto Refresh : 이용자의 자발적인 Action (Mouse Click Event, Keyboard action, Mouse Over는 제외)이 없는 상태에서의 팝업 또는 팝언더는 유효한 페이지로 처리하지 않고 있으나, 브라우저 Request가 아닌 애플리케이션을 Request를 통해 뜨는 페이지는 자발성과 관계없이 최종 1개 컴플릿 페이지만 카운트 함.
4. 측정 방법론 비교
- 사용자 중심 측정 방법 : 표본에 의한 패널 구성하여 행동을 추적/기록하는 장치 및 소프트웨어 설치하여 측정함. 측정 회사는 ComScoreMetrix, Nielsen/NetRatings, 코리안클릭 등이 있음.
- 사이트 중심 측정 방법 : 각 사이트 서버의 로그 파일을 기록 분석하여 방문량 산출하고 Cookie 기술의 활용함. 측정 회사로는 I/Pro, NetCravity, MatchLogic 등이 있음.
WEB2.0시대 기업이 직면하는 지식 활용법
Web 2.0이라는 말에 집약되어 있듯이 인터넷이 이전부터 설명 되어온 그 본래의 모습을 나타내기 시작하여 지식을 양성하기 위한 플랫폼으로서의 기능을 담당할 수 있게 변화 되고 있다.
이것은 기업에 「필요한 지식이 어디에 있는가?」라고 하는 본질적인 의문을 던지고 있다.
가속되는 엔터프라이즈 2.0
4월의 MITSloan Management Review에 하버드 비즈니스 스쿨의 앤드류 맥아피(Andrew McAfee)에 의한 「Enterprise 2.0:The Dawn of Emergent Collaboration」이라는 논문이 게재되었다.
맥아피의 문제 의식은 IT의 활용에 의해 사내에 존재하기 쉬운 형식적인 것이 아니고, 조직에 별로 구속되지 않고 보다 자연스럽고 평상시의 정형화되지 않은 것에 가까운 협력을 실현할 수 없을까라는 것이다. 블로그나 Wiki 등의 커뮤니케이션 툴을 사원에게 제공한 유럽의 투자 은행의 사례 연구법을 기반으로 쓰여진 이 논문은, 새로운 테크놀로지에 의한 지적 노동자의 활발한 협력의 진전을 지적한다.
여기서 논해지고 있는 「엔터프라이즈 2.0」은, 종래의 지식(knowledge ) 관리론에 가까워, 「인트라넷 2.0」이라고 생각하는 편이 이해 하기 쉬울지도 모른다. 그 의미에서는 지금까지의 지식(knowledge ) 관리와의 차이가 불명료하다는 비판도 일어나고 있다.
그러나, 최근 엔터프라이즈 SNS(소셜l 네트워킹 서비스)와 같은 툴의 도입을 검토하는 기업은 증가하고 있어 비정형화에 가까운 형태로의 지적 노동자에 의한 협력은, 새로운 기술의 활용에 의해 추진될 것이다.
맥아피의 논문과 같은 시기인 2006년 4월 3일호의 니케이컴퓨터에는 「엔터프라이즈 2.0:웹이 열리는 신기간 시스템」이라고 하는 특집이 게재되었다. 니케이컴퓨터는, 엔터프라이즈 2.0을 「비즈니스로 성과를 올리기 위한 정보를, 사내외 구분하지 않고 활용할 수 있는 기업이며, 그것을 실현할 수 있는 정보 시스템이다」라고 정의하여, 주로 「외부의 정보 콘텐츠」를 사내의 정보 시스템에 끼워넣으려고 하는 흐름의 총칭으로서 「엔터프라이즈 2.0」을 논했다.
사내의 지적 노동자에 주목하는 것이 아니라, 외부의 정보를 사내의 수중에 넣는다고 하는 점에 주목하고, 여기에서 논의 되는 엔터프라이즈 2.0은 종래의 지식(knowledge ) 관리론과는 다소 차이가 있다. 확실히 웹을 통해 공개되어 기업 정보 시스템에 활용할 수 있는 정보 콘텐츠는 많고 증가 추세에 있다. 그리고 API를 공개하는 기업수도 증가할 것이므로 이 흐름도 가속화 될 것이다.
InnoCentive를 사용한 P&G의 성공
이것들은 다소 다르지만 모두 사내의 정보를 유효 활용해 사내의 지식 축적을 높이는 방법에 관해서 논한 것이다. 이것에 대해, 2006년 6월에 Wired에 게재된, 같은 잡지 편집자인 Jeff Howe의 「The Rise of Crowdsourcing」라고 하는 기사는, 사내의 정보, 혹은 지적 노동자와 같은 사내의 자원에 관해서 논하는 일 없이, 기업이 지식을 유효 활용하는 방법론을 제시하고 있다. “Crowdsourcing”은 그 이름에서도 알 수 있듯이, “wisdom of crowds”(군중 지혜)와 “outsourcing”(외부 위탁)을 결합한 조어로, 그 의미도 이 결합되어진 뜻 그대로 이해하여도 무관할 것이다.
이 기사에서는 처음에 특정의 사진을 필요로 하는 사람들이 프로는 아니고 불특정 다수의 아마추어 카메라맨의 사진을 보다 염가로 이용할 수 있게 된 것을 ShutterStock과 같은 온라인 사진 판매 사이트를 예로 들어 설명하고 있다. 그리고 이 예로부터 경우에 따라서는 염가의 노동력을 요구해 인도나 중국에 외부위탁 할 필요성이 저하되고 있다는 것을 지적했다.
이 정도라면 예를 들어 eBay를 활용해 물품의 구입비용을 절약할 수 있는 방법으로 그다지 변화하지 않고, 반드시 「집합지」를 활용하고 있다고도 말할 수 없을 것이다. 그러나, Howe는 그 밖에도 몇개의 예를 들어 「 Crowdsourcing 」의 임펙트를 설명한다. 특히 흥미로운 것은 R&D(연구 개발)의 Crowdsourcing 의 예로 들고 있는 InnoCentive에 관한 사례이다. 이미 일본에서도 서비스를 개시한 InnoCentive의 사이트에 의하면 여기에서는 연구 개발 과제를 안은 세계의 일류 기업과 그 연구를 전문으로 하는 톱 클래스의 과학자들의 조화를 제시한다.
기업은 InnoCentive와 계약을 맺어 자사의 연구 개발 과제를 상세히 해설하고 마감하여, 과제의 해결책에 수여되는 보장금을 사이트에 게시한다. 이러한 과제에 대해 InnoCentive와 기밀 보관 유지나 지적 재산권의 양도 계약을 맺은 과학자들이 그 솔루션을 제공한다. 과학자들에게 주어지는 보장금은 1만 달러에서 10만 달러 사이이므로 대규모 연구 개발을 이 시스템으로 완성한다고는 생각되지 않는다. 그러나 InnoCentive를 통해서 「 Crowdsource」해도 충분하리라는 경우는 많지 않을까.
이 점에 관해, Howe는 P&G의 예를 들고 있다. 2000년 당시 상승일로에 있는 연구 개발비와 주춤하는 매출에 고민하고 있던 P&G는, 사외로의 이노베이션(innovation)을 적극적으로 받아 들일 방침을 굳혀 2006년에는 연구 개발 부문의 생산성이 60%나 상승했다고 한다. P&G는 InnoCentive를 초기부터 활용하고 있었던 것 같지만, 이와 같은 서비스를 그 이외에도 활용하고 있어, 9,000명의 사내 R&D스탭 외에 무려 150만명의 외부 연구자와의 네트워크를 구축하고 있다고 한다.
잘 생각해 보면, 이 예도 최초라고 할 수 있는 아마추어 카메라맨의 경우로 본질적으로는 변하지 않는다. 단지 주목 해야 할 것은 R&D라고 하는 어느 의미에서는 기업 경쟁력의 원천이라고도 해야 할 일까지 일반 대중에게 맡기는 것이 가능하게 되었다는 점이다. 또 Howe는 5월부터 「Crowdsoucing: tracking the rise of amatuer」라고 하는 블로그를 운영하고 있지만, 이 예로의 “crowds”는 아마추어가 아니고 프로의 과학자들을 가리키고 있다.
Crowdsource라고 하는 개념에서는, 인터넷을 통해 연결되어진 사람들의 잠재적 지식을 잘 활용하는 것에 의한, 비용 삭감이나, 효과적 이노베이션(innovation)을 위한 새로운 방법론을 엿볼 수 있다.
Web 2.0이 던지는 본질적인 질문
지식을 유효하게 활용하기 위한 방법론은 오늘날까지 여러가지가 제시되어 왔다. 예를 들면 유저의 질문에 유저가 대답하는 형식의 「지식 검색」은 이전부터 존재하고 있었고, 기업 내의 시스템에도 활용되고 있다.
그러나, 엔터프라이즈 2.0이나 Crowdsourcing 이라고 하는 컨셉이 재차 주목받고 있는 것은 Web 2.0이라는 말로 대표되는, 본래의 모습을 나타내기 시작한 인터넷의 영향에 의한 것이다. 그러므로 이 두 개의 컨셉은 모두 인터넷이 본래 가지는 지식 창조 플랫폼의 관점으로부터 보다 본질적인 의문을 기업에 던진다.
이 질문이란 「원래 기업에 있어서 필요한 지식은 도대체 어디에 있는 가」라는 것이다.「사내 밖에 없다」, 혹은 「사내에도 있다」라고 대답할 수 있는 기업은, 엔터프라이즈 2.0적인 진화한 지식 관리 시스템의 구축이나 활용에 의해서 그것을 필요한 때에 필요한 사원이 활용할 수 있다.
그러나 한편으로 이러한 지식은 반드시 사내에 있다고는 할 수 없다. 그렇다기 보다, 오히려 사내에 없는 케이스가 압도적으로 많은 것이 아닐까. 새로운 프로젝트를 개시하거나,새로운 연구 개발을 실시할 때 등의 경우는 특히 그 가능성이 높다. 이 경우 지식 관리 시스템이 기능하면 할수록 필요한 지식은 사내에 없다는 것을 깨닫게 된다. 게다가 진화한 인터넷은, 필요한 지식을 가지는 사람이 어디에 있고, 그 지식을 가지는 사람들과 협력하는 것이 가능하다는 것도 분명히 하고 있다.
경영학의 권위자인 피터 드러커는 이전부터 지식만이 기업의 발전에 기여하는 자원이 되는 것을 지적하고 있지만, 풍부하고 다양한 지식 기반을 보유하는 대기업은 위에 던진 본질적인 의문과 마주보지 않을 수 없을 것이다. 그러나 전문 지식을 가지는 개인에게 있어서는 찬스가 많은 “Power To The People”의 시대가 도래하고 있다.
Maeda Takasi ( ZDNet Korea )
Modus Operandi: Business Today Vs. Enterprise 2.0
현재 우리가 하고 있는 비지니스 환경과 Enterprise 2.0 기업의 환경에 대해서 잘 비교한 표입니다. Enterprise 2.0의 방향에 대해서 감이 오실것입니다.

참고로 Modus Operandi의 의미는 라틴어로 대략 "modes of operation"(작동 방식, 처리 방식)입니다.
AdClix 달았어요
긴꼬리 사업 모델의 하나인 다음의 AdClix를 달았습니다. 긴꼬리 영역(분산된 트래픽)에서도 수익을 창출할 수 있는 사업들이 모락 모락 피어오르고 있는 것 같습니다. 하루 충전 금액은 얼마 안되지만 나름대로의 블로그 활성화의 동인으로 저의 마음을 잡아놓았습니다.
하나의 블로거의 수익 모델과도 직결되고 롱테일의 법칙도 반영되는 것이 특징인 것 같습니다.
지금까지는 ‘파레토의 법칙(80 대 20 법칙)’이 비즈니스 세계를 지배했고, 이를 근거로 ‘선택과 집중’의 이라는 전략이 생겼습니다만은 이제는 Web 2.0의 사상이 업계 전반에 걸쳐 확신이 되면서 주목받지 못하는, 다수 속의 소수가 중요시 된다는 ‘롱테일의 법칙’이 세상을 지배할 것이고 또한 이를 근거로 관심(Attention)의 전략을 펼 때가 온것 같습니다.
즉 긴꼬리 사업에도 관심을 가지는 사업 모델이 나오고 있으니깐요.
관심과 롱테일의 결합 상품도 좋은 비지니스 모델이 될 거 같군요.
인기 블로그의 비결 15가지
1. Blog cause you want to - 당신이 원하는 것, 사랑하는 것, 좋아하는 것에서부터 블로깅은 시작된다.
2. Read other blogs - 다른 블로그를 방문하여 읽어라. 다른 이들의 블로그를 방문하는 순간 당신은 이미 블로거다. 당신이 관심가지고 좋아하는 주제에 대한 블로그를 꾸준히 방문하고 또 격려/성원하라. '관계'가 만들어지는 계기가 된다.
3. Pick a niche you can own (be different) - 모든 사람은 검색으로, 구글을 통해 세상과 대화한다. 일반인들이 애용하는, 시의적절한 키워드(또는 분야)에 대해 자주 언급하였다면 때에따라 당신은 검색결과의 상위에 노출될 것이고 많은 독자를 얻게 될것이다.(예를 들어 blog about the London Underground 라는 블로그는 매우 지루한 주제의 블로그라 생각되지만 런던 지하철 폭발사건이 있은 후 이 블로그는 검색에 의해 순식간에 인기블로그로 변모하였다. 이후 이 블로그에 기재된 독특한 포스트들이 인기를 끌기 시작했다.)
4. Link to other blogs - 다른 블로그 포스트의 링크를 걸어라. 그리고 링크한 포스트에 덧글을 남겨라. 블로거들은 일반적으로 리퍼러를 통해 방문자들의 동향을 확인한다(포털 블로거들은 제외). 따라서 그들에 대한, 그들의 주목을 끌만한 주제에 대해 블로깅을 하고 링크를 걸어라.
5. Admit mistakes - 실수를 인정하라. 실수나 실언으로 인해 부정적인 덧글이나 욕설이 남겨지더라도 떳떳하게 인정할 경우 방문자들의 태도는 다시 긍정적으로 변화한다. 실생활에서 처럼 실수를 인정하는 길만이 독자들로부터 신뢰를 얻는 최선의 방법이다.
6. Write good headlines - 낚시(?)를 잘 하라. 방문자는 주로 검색엔진(제목)과 Feed(메타블로그 or 리더기-제목)를 통해 정보를 습득한다. 멋진 제목은 검색결과페이지에서 Feed 목록에서 당신의 포스트를 눈에 띄게 해줄 것이다.(물론 좋은 내용이 수반되어야 함은 필수)
7. Use other media - 일반적으로 오프라인보다 온라인에서 읽기속도가 30%가량 떨어진다고 한다. 따라서 podcast, vedio, image 등을 적극적으로 활용(트래픽에 영향을 주지않도록 관련 서비스를 활용한다. Youtube, Flickr 등)할 경우 방문자의 가독성과 빠른 이해에 도움을 주므로 동일한 내용이라도 다양한 방법으로 차별화를 꾀하도록 하라. (Techcruch의 경우 모든 포스트에 이미지를 이용하고 있다.)
8. Have a voice - 기교적으로만 글을 쓰려 노력하지 말고 인간적인 면을 보여라. 친한 누군가(친구나 와이프)와 이야기하듯이 글을 쓰라.
9. Get outside the blogosphere - 다양한 모임과 이벤트 등 활발한 오프라인 활동을 통해서 블로거들과 Face to face 관계를 맺어라. 그러면 더 많은 링크와 독자를 얻게될 것이다. 오프라인 활동 또한 다양한 미디어(Flickr, Youtube 등)를 통해 포스팅하라. 이를 확인하기 위해서라도 그들은 당신의 블로그를 방문할 것이다.
10. Market yourself - 적극적으로 마케팅하라. 아직까지 명함에 블로그 주소를 포함한 사람은 별로 없다. 명함 등과 같이 자신의 블로그를 홍보할 수 있는 모든 방법을 이용하라.
11. Write well - 항상 오타를 확인하고 배포 전에 다시 한번 문장을 확인하라. 글의 상단에 주제를 배치하고 글의 길이가 길 수록 완독률이 떨어지므로 글의 제목과 첫번째 단락이 독자가 포스트를 읽을지 말지를 결정하는 중요한 요인이라는 것을 명심하라. 또한 글쓰기 등에 관한 책을 꾸준히 읽고 글쓰기 능력을 배가하라.
12. Expose yourself - 당신만의 스타일(개성)을 드러내라. 마치 신문기사와 같은 문구로 포스팅하지 말라. 100개중 한두개 정도는 당신의 개인적 관심을 드러내어 주제의 지루함을 방지하라.
13. Help other people blog - 당신이 블로깅을 하며 배운 것을 공유하고 새로운 블로거들의 목소리를 전해 그들이 블로고스피어에 적응하도록 도와라.
14. Engage with commenters - 다른 이들의 블로그에 덧글이나 트랙백을 남겨 대화에 참여하라. 독자들은 종종 덧글/트랙백을 통해 당신의 블로그를 방문하곤 한다.
15. Keep your integrity - 항상 정직함을 유지하고 자신에 대해 숨기거나 독자들을 속이려 하지 말아라. 어떠한 광고형 포스팅을 하거나 상업적 목적을 위한 어떤 댓가를 받았을땐 숨기지 말고 이를 밝혀라. (Edelman의 Wal-Mart 가짜블로그 사건이 한 예이다.)
- 참조 사이트 : http://wooweb.org/rc3/554
2007-04-07 일상
오늘은 날씨가 무지 화창해서인지 꽃들이 춤을 추는 것 같네요. 그저 지나치기만 하다가 오늘은 카메라를 들고 나간 기념으로 사진 몇 장을 찍어봤습니다. 이제 날씨는 어느덧 봄의 언저리를 지나가는 느낌입니다. 목련, 자목련, 진달래, 벚꽃들을 종류별로 올립니다.





'나이키의 상대는 닌텐도다' 을 읽고
나의 경쟁상대, 우리의 경쟁상대는 누구일까?
"나이키의 상대가 닌텐도라고, 소니의 미래는 아톰을 목표로 한다니.." 고개가 갸우뚱해진다. 비유와 상징인가? 언뜻 이해가 잘되지 않았다. 이런 타이틀은 어디에 근거한 것이며, 도대체 어떤 내용을 담고 있는지 궁금하게 만들었다. 어리둥절하게 만들면서도 호기심을 유발시키고, 게다가 머리에 쏙 들어온다. 이것도 절묘한 마케팅의 일환이었겠지. 다 읽고 나니 공감이 간다. 책의 내용과 주제를 하나의 문장으로 적절히 압축해 놓았고, 이상한 이론 같지만 실상 너무도 이상하지 않게 오히려 당연하게 풀어내고 있었다.
저자는 최근 마케팅 트렌드와 관련된 8가지 핵심 개념을 이야기 하기 위해, 이러한 개념들이 우리 실생활에서 어떤 모습으로, 어떻게 접근하고 있는지를 수많은 사례를 통해 보여주고 있다. 해외 유명 기업은 물론 국내 기업, 각종 영화 및 상품들의 사례를 철저히 분석해 시장변화와 마케팅 트렌드를 실감할 수 있도록 도와주고 공감을 불러 일으킨다. 이 책에서 소개하는 8가지 트렌드들이 아주 새로운 것은 아닐지라도 고객을 끌어 모으고 유지하기 위해 놓쳐서는 안될 중요한 이슈이며, 이를 이해하기 쉽게 정리하고 있다는 측면에서 강점을 가지고 있다.
그렇다면 그가 이야기하는 8가지 개념에 비추어 현재 마케팅의 추세가 이렇다면 앞으로는 어떻게 변화할지 고민해봐야 하지 않을까. 나의 경쟁상대는 누구이며, 우리의 경쟁상대는 과연 누구인지도. 그리고 마케팅을 서비스화하여 우리 실정에 맞는 전략도 각 항목마다 생각할 필요가 있어 같이 정리해본다.
1. Time Share(시간 점유율) - 주어진 동일한 시간을 고객으로부터 지켜라.
'나이키와 닌텐도는 고객의 시간을 놓고 서로 다툰다.' 책의 첫 장은 시간점유율에 대해 다루고 있다. 누구나 시간을 무엇보다도 가치 있게 여기고, 똑같은 시간을 더 알차고 만족스럽게 보내길 원한다. 나이키의 논리는 나이키 주 고객들의 시간을 닌텐도 게임기가 빼앗아 가고 있다는 점을 두고 이야기 한 것이다. 이렇게 표현하고 보니 제목이 단번에 이해가 된다. 이제는 스포츠업체와 게임업체, 즉 기존에 누구도 경쟁사라 생각 조차하지 않았던 대상까지도 경쟁자로 등장한 것이다. 누가 고객의 시간을 더 많이 차지할 것인가를 놓고 경쟁하는 세상이 되어버린 것이다. 결국 기업의 수익은 고객의 시간에서 나온다는 것이다.
기세 좋게 성장하던 싸이월드의 성장을 정체시킨 주범으로 카트라이더 게임을 꼽고 있는 저자는 고객의 시간과 신뢰를 더 차지하기 위해 이종업체들간에 치열한 경쟁이 이뤄지고 있음을 주목하며 '경쟁사보다 고객이 더 중요하다'는 이야기를 하고 있다. 고객의 시간점유율을 제고하는 방법으로 시간 연장, 시간 단축, 적시 대응, 시간 창출이라는 네 가지 방안을 제시하는데, 그것은 즉, 고객과 함께 하는 시간을 늘리고, 고객의 불필요한 시간을 줄여 주며, 고객이 필요할 때 적시적소에 대응하고, 고객에게 의미 있는 시간을 기념하게 하라는 것이다.
여기서 우리만의 생각을 유추할 수 있을 것이다. 가지고 있는 컨텐츠는 많지만 진정 고객이 즐기고 유익하게 느낄 수 있는 의미가 있는 컨텐츠는 과연 몇이나 될까? 이 부분을 고민한다면 우리가 과연 무엇을 해야 할 것인가? 를 알게 된다. 실적에 대한 데이타를 분석하며 어떤 서비스를 기획할 것인지를 고민하기 보다는 고객이 무엇을 원하는지 창의적인 사고를 바탕으로 서비스를 발굴할 필요가 있다. 현재의 트랜드를 분석하고 미래 트랜드를 예상하기 위해서는 우리는 지금 시류에 편승하는 습관은 버려야 할 대상이다. 언제까지 me-too(복제)서비스를 만들어 뒤쳐진다는 소리만 들을 것인가? 그렇게 하기 위해서는 고객이 바라는 것을 연구할 필요가 있고 또, 창의적인, 의미가 있는 서비스를 만들어 내기 위해서는 부단한 연구가 선행되어야 한다. 그래서 요즘 제가 관심이 가는 분야가 웹 사이언스 분야입니다. 아직 많은 사람들이 연구되진 않지만 흥미로은 학문 분야입니다. 웹 사이언스에 대해서 간략하게 설명하자면 팀 버너스 리는 ‘웹은 컴퓨터로 무엇을 할 것인지에 대한 것이 아니라 컴퓨터로 연결된 사람들에 관한 것’이라고 강조하면서 웹 사이언스는 지금까지의 컴퓨터 과학으로 풀어갈 문제가 아님을 지적했다. 이것은 웹에 기반을 둔 이른바 소셜 컴퓨팅에 관한 연구이고 사회과학·인문과학이 자연과학과 공학을 만나는 접점이다
웹에서 활동하는 우리의 불특정 고객들의 의사소통, 신뢰, 아이덴티티, 집단 지능, 사회적, 정치적 관계 등의 사회적, 문화적 심리들에 대한 연구가 먼저 진행이 되어야 하고 이를 반영한 웹 서비스 즉, 컴퓨팅 모델이 만들어져야 한다는 이야기다.
2. E-factor(즐거움) - 재미가 없다면 사라지는게 이치다!
요즘 인터넷의 소비자이자 생산자인 고객들의 행태는 아주 단순하다. 웃기는 포스트나 동영상은 너도 나도 재빨리 포스팅을 한다. 재미가 없다면 읽히지 않고, 인터넷이라는 곳에서 사장되기 일수이다. 하지만 일부는 롱테일이라는 개념으로 다시 부활하기도 하지만 드문 현상이다. 그만큼 ‘재미있다’ - '엔터테인먼트 요소(E-factor)'가 중요하다는 점을 강조하는 것이다. 앞으로는 단순한 서비스가 아니라 다양한 엔터테인먼트 체험과 관련한 사업이 각광을 받게 될 것이다. 이러한 트렌드는 정보와 엔터테인먼트가 결합된 인포테인먼트, 교육과 결합된 에듀테인먼트, 그 밖에 컬처테인먼트(문화), 스포테인먼트(스포츠), 이터테인먼트(음식), 애드버테인먼트(광고) 등 다양한 모습으로 진화한다. 이러한 추세에 부응하지 못하면 성공하기 어렵다는 것이다.
우리가 만드는 서비스에 비즈니스 전략 외에 불어넣을 수 있는 것은 무엇일까? 엔터테인먼트다. 고객이 즐거워하지 않는다면 그 서비스는 얼마 가지 못한다. 그만큼 서비스를 유지하는 비용이 올라간다는 이야기이다. 당연 수익이 발생하기 어렵기 때문이다. 즐거움을 주는 전략도 비즈니스의 전략보다 오히려 더 중요할 수 있다고 생각한다.
3. Story Telling(이야기) – 서비스에 Story를 주입시켜라
드라마 「대장금」에서 장금이 임금에게 올린 음식이 인정을 받을 수 있었던 것은 음식의 모양새나 맛 때문만은 아니었다. 그 음식이 담고 있는 스토리가 공감과 감동을 불러 일으켰기 때문이었다. 그 드라마에 등장하는 음식들이 소위 '스토리 푸드' 였기 때문에 한국인 뿐만 아니라 중국인, 일본인들에게까지 공감을 얻을 수 있었다는 것이 저자의 분석이다. 스토리를 통해 고객의 마음을 움직이는 게 만드는 것이다.
이제 IT분야에서는 무게 중심이 점차 솔루션에서 서비스로, 그리고 스토리로 이동 중이라고 주장한다.
서비스라는 놀이터를 만들고 즐거움을 줄 수 있는 도구를 준비만 했다면 그 서비스는 지속성이 결여된 서비스로 전락하고 만다. 즉 즐기고 머물 수 있는 이야기 꺼리를 소통할 수 있는 채널이 필요하다는 이야기다. 그래야 머물 수 있는 기회를 제공하게 되는 것이다. 그 다음으로 바로 관심(Attention)의 경제(서비스)로 넘어간다고 생각한다. 그리고 고객들의 기억 속에 서비스가 자리를 잡고 한발 더 나아가 중독으로 빠지게 되면 그 서비스는 그야말로 대박이 나게 될 것이다. 그렇다면, 스토리는 어떻게 만들어지는가? 새롭게 창작된 스토리보다는 기존의 사실을 발견하고 윤색하는 것이 고객에게 더 큰 공감을 유발할 수 있다. 재 창조의 발상으로 더 관심이 가는, 고객이 즐거워하는 서비스를 만들도록 끝없이 연구 과정이 또, 한번 강조되는 셈이다..
4. Word of Mouth(입소문) - 입소문 마케팅을 활용하라
수많은 제품, 또 이에 관한 광고들이 넘쳐 나고 있는 오늘날, 이미 입소문은 소비의 강력한 나침반 역할을 담당하고 있다. 소비자들이 제품을 구입할 때 인터넷으로 가격비교 사이트, 브랜드 커뮤니티, 관련 정보제공 사이트 등에 접속해 각종 정보와 구매 후기 등을 참고하는 것은 일상적인 절차로 자리 잡아 가고 있다. 이와 같은 온라인의 영향력 강화는 입소문 마케팅의 효과를 더욱 배가시고 있다. 그러나 입소문 마케팅이 성공하기 위한 전제 조건으로 상품의 우수한 품질, 핵심고객의 파악, 그리고 중장기적인 접근 등이 필요하다고 말하고 있다. 핵심은 우수한 품질을 적시에 값싸게 제공하는 것이다. 그 다음 우리는 입소문(버즈) 등의 마케팅이 필요하다. 입소문 전략은 가격 경쟁력이 있다고 한다. 그래서 전문 블로거나 얼리 어댑터 둘에게 좋은 소문을 낼 수 있도록 홍보 전략도 많이 필요하다. 초기 시장 진입을 빨리 하기 위한 이런 신뢰성 전략인 것이다. 하지만 우린 주객이 전도되어서는 안 된다. 그렇기에 앞에서도 지속적으로 이야기해 왔듯이 핵심인 품질 좋은 서비스를 만드는데 지속적인 투자를 아끼지 않아야겠다.
5. UCC:User Created Contents(사용자 제작 컨텐츠) – 고객을 참여를 조장하라
최근 2 ~ 3년 동안 Web2.0 트랜드가 뜨면서 참여, 공유, 개방의 모토 하에 UCC같이 이용자의 컨텐츠 생산 플랫폼이 각광을 받고 있다. 이제 개인들은 콘텐츠의 소비뿐만 아니라 생산에도 큰 기여를 하고 있다는 것이다. 국내 UCC 시장은 동영상 쪽에서는 판도라TV, 엠엔캐스트, 아프리카, 다모임 등 동영상 UCC 전문 업체와 다음, 네이버, 프리챌 등 기존 포털, SBS, MBC, KBS 등 방송사에서 그 외에 지식인, 블로그, 카페, 미니 홈피 등 포털에서 커뮤니티 사이트들이 활발하게 운영되고 있고 해외에서는 동영상 분야에서는 Yahoo, MSN같은 기존 포탈 사업자와 YouTube, Revver, eefoof 같은 동영상 UCC 공유 사이트들의 운영 되고 있고, Myspace, Blogger, Technorati 등의 커뮤니티 사이트들이 인기리에 운영되고 있다. UCC를 생산하고 활용할 수 있는 공간이야말로 고객들을 유인하게 만드는, 고객들을 놀 수 있는 놀이터로 만들기에는 가장 안성맞춤이다. 그래서 인터넷에서 가장 이슈화 되어 있다.
이젠 이런 트랜드를 쫗아가지 않으면 안되는 상황이 되었다. 문제는 누가 핵심적인 컨텐츠를 많이 확보하느냐가 중요한 키인 것 같다. 제휴를 통해서, M&A를 통해서 아니면 UCC를 생산할 수 있는 플랫폼을 만들어서 고객들의 컨텐츠를 확보하는 등 다양한 방법들을 분석할 필요가 있다.
6. Egonomu(자기중심경제) - 모든 길은 나로부터 출발한다.
미래시장 핵심 키워드는 '자기중심경제(Egonomy)'이다. 이제는 인터넷 문화는 개인화 되고 있다. 모두들 '내 것'을 사용하기 시작하면서 라이프 스타일도 점차 개인주의화 되어가고 있다. 생활과 소비의 중심이 바로 나 자신이 된 것이다. 그러나 재미있는 것은 이렇게 개인화, 차별화를 추구하는 가운데에도 소비자들이 '동질화'를 추구하는 현상이 뚜렷해지고 있다는 점이다. 블로그나 미니 홈피를 통해 한편으로 자신의 개성을 마음껏 발산하면서도, 다른 한편으로 타인과의 공유, 공감을 추구하고 있는 것이 좋은 예다. 그래서 이젠 개인의 총체적 경험을 발전시키면서도, 이들 개인간의 네트워크에 기반한 관계의 진화를 모색해야 한다. 즉, 유행과 개성을 동시에 요구하는 소비자들의 기대에 부응하라는 것이다. 차별화를 원하면서 동질화를 추구한다. 맞춤식이 각광을 받게 되는 것이다.
여기서 중요한 키워드 개인화와 관계이다. 구글 알리미, 블로그 라인, 한Rss, 이메일 수신 레터 뉴스 알리미 등에서 보듯이 개인의 관심을 이젠 찾아오게 하는 것이 아니라 찾아 가는 서비스로 바뀌고 있다. 그야말로 You(당신), I(나)가 중요해졌다는 것이다. 당신이 없으면 우린 사라진다는 생각 속에 당신을 위해서 우린 무엇을 해야하는 지를 다시 한번 생각이 필요하다.
7. Evangelist (브랜드 전도사) – 서비스 브랜드를 매니징하자.
할리 데이비슨, 나이키와 같이 브랜드들은 자신의 비즈니스에 자유, 평등, 박애, 환경 등의 혼을 불어 넣는데 성공했다. 이들을 최근에는 많은 사람들에게 삶의 중요한 일부로 정착된 라이프 스타일 브랜드를 지칭하기도 한다.
여기서 우린 느껴야 한다. 하나의 상품이나 서비스를 생활이나 문화로 인식하게 만들었음을. 생활 속에 스며들고 문화 속에 기억으로 남겨진 서비스라면 고객들은 열정 고객으로 봐야 할 것이다. 이러한 이유로 우린 매출을 발생시킨 충성고객이 보다는 서비스를 신뢰하고 알리는, 사용하는 열정고객에게 더 관심을 가져야 하는 이유가 여기서 나온다. 열정고객은 경쟁사의 온갖 유혹에도 절대 배반하지 않을 애정을 가진 사람들이다. 이들은 자기를 표현하기도 하고 타인들과 사용경험을 공유하는 데 적극적이다. 이들은 누가 시키지 않아도 자발적으로 포교에 참여한다. 이런 열정 고객으로 전환하기 쉬운 고객군은 어떤게 있을까? 얼리어답터, 모니터요원, 미스테리 샤퍼, 멤버쉽 등 다양한 형태의 브랜드 전도사들을 만들어서 운영 할 전략도 필요하다. 이런 고객군들이 자기들의 서비스를 이용하고 서비스를 홍보하는 등 우군을 많이 확보하게 될 것이다.
8. Context (정황) - 타이밍과 Needs의 파악하자
고객의 필요를 미리 읽고 준비하는 컨텍스트적 측면을 서비스에 불어 넣을 필요는 있다. 대부분 고객의 현재 처한 정황을 인식하여 그에 맞는 제품이나 서비스를 노출 시키는 것이다.
비오는 날에는 파전 전문점의 광고를, 고객이 친 검색어를 연관된 광고로 실시간으로 표시하는 센스. 고객의 현 위치 정보를 알아서 그 주변의 필요한 정보(맛집, 할인점, 쿠폰)를 보여주는 등의 고객의 정황에 맞는 서비스를 제공해 줄 필요가 있다.
즉, TPO(Time:시간, Place:장소, Occasion:상황)에 따른 서비스를 제공해 주어야 한다는 이야기다. 이와 같은 시간, 장소, 상황에 입각한 서비스 제공 전략은 기존의 무작위 노출 에 비해 훨씬 효과가 크다. 앞으로의 이런 서비스는 디지털 기술을 활용해 소비자가 누구인지, 그들이 어디에서 무엇을 하고 싶은 지를 적시에 파악, 대응하는 방향으로 진화해 나갈 것이다. 앞으로는 유비쿼터스 환경에서 인터넷이 제공되는 경우가 많아질 것이다. 그러기에 우리는 시대적 흐름에도 깨어있어야 할 것이다.
마케팅 기법이 아무리 발전해도 소비자의 변화를 추월할 수 없다고 강조한다. 그렇기 때문에 위의 마케팅 기법을 학습하는 것이 중요한 것이 아니라 고객의 변화를 먼저 읽어야 한다는 것을 강조하고 싶다.
정작 자신이 출시하는 서비스가 비지니스 전략에는 부합하지 않더라고 고객이 원하는 서비스는 출시 할 수 있는 능력을 갖추어야 하는 게 가장 급선무인 것이다. 기획자는 고객의 입맛을 찾고 개발자는 고객의 입맛에 맞는 기술을 개발하여 타사보다 한발 앞서서 내놓을 준비를 하는 것이 가장 중요한 시기인 것 같다. 또한 고객 스스로가 컨텐츠를 생산할 수 있는 플랫폼 또한 갖추는 게 중요하다. 서비스 소비자과 생산자의 구분이 없어진 지 오래되었다고 할 수 있다. 이제는 그 플랫폼 위에 집단의 지성을 발현할 수 있는 구현물의 준비가 필요하다. 그야말로 Peer Production을 할 수 있는 플랫폼을 구축하고 어떻게 하면 구축된 컨텐츠의 의미 관계를 분석하여 고객의 의도를 웹에서 보여주는 것이 필요할 것이다. 그것이 바로 시맨틱 웹의 미래인 것이다. 우리도 모든 서비스가 이젠 키워드 기반의 Information Finding보다는 의미 분석 기반의 Information Understanding으로 변화를 시도해야 할 것이다. 즉, 고객에게 쉽게 다가가기 위한 방법이 필요한 것이다. 그럼 개기인들은 이제 할 일이 생겼다. 각자의 위치에서 기존의 고정관념을 깨고 창의적인 틀 아래서 소비자의 변화를 예측할 수 있는 안목과 그 안목을 서비스로 출시 할 수 있는 기획 및 기술력을 키우는 것이다. 이런 활동들이 지속적으로 이루어지는 과정에서 개선까지 이루어진다면 자신들에게는 좋은 결실이 있을 것이다.
How To Build a Website with Office 2.0
Ismael Ghalimi가 Office 2.0 Tool을 가지고 웹사이트 만들기에 대해서 재밌게 썼습니다.
Requirements
- 클라이언트 사이드 어플리케이션은 No!
- 협업으로 컨텐츠를 개발하고 퍼블리싱해야할 것
- 두 개 이상의 독립적인 소스들을 이용할 것
- 코딩의 양이 많지 않을 것
- 인력은 5Md일 것
- 호스트 비용은 월 25달러 이내일 것
Platform: WordPress
WordPress은 fantastic blogging tool! 더할 말이 없다.
Database: Dabble DB
Dabble DB는 Office 2.0 database 이다. JSON으로 컨텐츠를 효과적으로 Syndication할 수 있고 최상의 유저 인터페이스를 지원한다.
Documents: Zoho Writer, Zoho Sheet
Zoho Writer는 Office 2.0 word processor이면서 협업적으로 문서작성에 용이하다. Zoho Sheet는 웹용 스프레드 쉬트다. 그리고 공유도 가능하다.
Images: Flickr
모든 이미지 저장고는 Flickr를 이용하고 부가적으로 banners, logos, screenshots and large icons를 활용하라.
Feeds: FeedBurner
WordPress, Dabble DB and Zoho Writer도 Syndication feeds를 자동으로 생성해 주지만 트래픽을 덜어주는 FeedBurner에 등록해서 사용하라.
Profiles: LinkedIn
개인 프로파일 관리는 LinkedIn에서 하라.
Miscellaneous
Google Analytics등을 사용하여 트래픽을 모니터링하라...
위글은 블로깅을 하기위한 플랫폼을 설명한 것으로 이해하셔도 좋을 듯 합니다. 아직은 외국 사이트들이 내용을 채우고 있지만 머지않아 한국 사이트들을 구성하여 위와 버금가는 사이트를 구축할 수 있는 날이 왔으면 좋겠네요. 분발합시다. 여러분~~
구글 Co-op 서비스 소개
구글에서 Co-op 베타 사이트에서 내가 맞는 검색 엔진 즉, 개인화 검색 서비스를 구성해 보았습니다.
검색어를 검색하고자 할때 그 키워드와 관련성이 높은 사이트들만을 검색하게 끔 만들었습니다. 고객의 입맛에 맞는 검색을 하겠다는 구글의 전략도 엿보이네요.
자리 블로그나 홈피에 붙일 수 있도록 스크립트도 제공해 주네요.
한번 해보세요.아래는 제가 만든 Enterprise 2.0관련 사이트들을 모아서 검색의 집적도를 높여 주도록 만들어 보았습니다.

제가 만든 Enterprise 2.0을 위한 사이트입니다. 한번 들러보세요.
How to use OpenID (a screencast)
OpenID 사용 방법 소개
Links
- http://openid.net/ is the official site for OpenID.
- OpenID Site Directory is a list of sites that you can log in to using your OpenID.
OpenID providers
Enterprise 2.0 슬라이드 소개
thomas.purves가 2006년 11월 7일 토론트의 Enterprise 2.0 Camp에서 발표한 자료입니다. Enterprise 2.0의 개념을 파악에 좋을 듯 합니다. 자세히는 파악이 힘들겠지만 대략 어떤 내용인지는 쉽게 이해하실 수 있을겁니다.
웹 기반의 마인드맵 소프트웨어 비교
| Topics | ||||
| Topic text styles |
|
|
|
|
| Topic fonts |
|
|
|
|
| Topic shapes |
|
|
|
|
| Topic colors |
|
|
|
|
| Topic icons/symbols |
|
|
|
|
| Hyperlinks |
|
|
|
|
| Topic notes |
|
|
|
|
| Topic images |
|
|
|
|
| Free positioning of topics |
|
|
|
|
| Topic boundaries |
|
|
|
|
| Relationship lines |
|
|
|
|
| Task info on topics |
|
|
|
|
| Map features | ||||
| Support for keyboard shortcuts |
|
|
|
|
| Undo command |
|
|
|
|
| Map zoom |
|
|
|
|
| Filter topics by level |
|
|
|
|
| Types of map layouts supported |
7
|
1
|
1
|
1
|
| Collaboration/map sharing | ||||
| Collaboration - real time |
|
|
|
|
| Collaboration - non-real time |
|
|
|
|
| Map output | ||||
| Print maps |
|
|
|
|
| Export to MindManager |
|
|
|
|
| Export to FreeMind |
|
|
|
|
| Export to Word/RTF |
|
|
|
|
| Export to image file |
|
|
|
|
| Publish map to web/blog |
|
|
|
|
| Other capabilities | ||||
| Import maps from MindManager |
|
|
|
|
| Import maps from FreeMind |
|
|
|
|
- Mindomo는 이용자 인터페이스 측면에서는 잘 개발되었으나 실시간 협업이나 다른 포멧으로 Export지원이 빈약한 편이다.
- MindMeister는 실시간 협업이 가능하고 MindManager and FreeMind과 같은 데스크탑 기반의 마인드맵 프로그램과 호환이 가능하나 유저 인터페이스 측면이 약하다.
2007-04-01 일상
어제부터 아내가 큐브에 푹 빠졌습니다. ^^ 치매 예방에 도움이 된다고 방에 앉아서 꼼짝 달싹 않고 몇시간째 노하우 터득에 여념이 없습니다.
이 일을 어떻게 봐야 될까요? 아래의 사지은 아내가 가지고 있는 큐브입니다. 귀엽죠.
재밌긴 재밌는 모양입니다. 참고로 3X3X3은 세계 기록은 프랑스의 Edouard Chambon이 10초 36이라네요. 우리나라 랭킹은 유정민씨가 11초 9라고 나오네요. 완전 귀신들이죠.
참고로 큐브 연합회 사이트가면 재밌는 기록들을 볼 수가 있네요.
아참에 큐브의 역사를 한번 볼까요?
큐브 퍼즐은 1974년 헝가리의 수도 부다페스트에서 당시 부다페스트 대학교 응용미술대학 디자인학과 교수이던 에르노 루빅 (Erno Rubik) 교수에 의해 발명되었다고 합니다.
다음은 TV 방송에서 3살짜리 어린이 셰언시가 1분 54초만에 큐브 퍼즐을 모두 맞추는 비디오가 소개되었습니다.
아래를 보시죠.
그런데 이 화면을 보더니 와이프가 짜증을 내더군요. 더이상 못해 먹겠다고..세살 어린이가 저정도인데.. ^^
의지를 무지막지하게 꺽은셈이죠 제가..
잠시 주섬 주섬 하더니 다시 큐브롤 들고 꼼지락 꼼지락하네요. 어린애처럼..
아직은 다 맞추지 못했는데 다음번엔 맞춤 사진을 올려드리겠습니다.
To be continue....









