A little bit more...

Wednesday, July 26, 2006

Always prototyping your new features that are to be added

Wow, this new feature is awesome. It’s super cool!. I woner if we could add it our product. Ok, I’m gonna do it right now.

But wait…

First develop a prototype with this new feature added. Then see how this feature functions within your product, how it collaborate with other features. If these all are just fine then change your artifacts to add it to your product extensively and “aggressively”. This would be safer.

Never do so-called feasibility analysis just in your mind or just on a paper with your pen. You’re cheating yourself. In this way you would be very excited with your analysis results at most time and say to your colleagues those words written in the first paragraph of this post.

We experienced this cheating-ourself process. And it turns out to be that this new feature actually doesn’t function as we expected but meantime we have to keep those codes modified during adding this new feature for not wasting more time removing them and bringing new risks even though we know they’re useless. This may be a lesson you can learn from.

It is noteworthy that the beta policy of most web2.0 applications goes to extremes in prototyping new features and that developping iteratively is the essence of contemporary software development.

One post of my development diary series…to be continued.


Technorati : , , , ,
Del.icio.us : , , , ,

Help me with automating KDE environment settings

I have pasted this on some tech forums, but no one seems to be willing to help me. So I would like to also paste it here. Any help or even any response making no sence would be very appreciated.

我刚接触Linux不久,现在碰到要做这个,请各位高手支支招。

主要分为几个部分:
1. Desktop shortcut, background, etc;
2. Kicker (Panel), start menu, custom menu, etc; and
3. Konqueror, Konsole, etc.

由于KDE采用 Cascading Configuration Files的结构 (至少KDE3.1+是这样),有针对所有用户的设置和用户自定义设置,主要的配置文件分别在/usr/share/config, ~/.kde/share/config。我现在采取的策略主要是写了一个脚本用定制的标准桌面环境的配置文件去覆盖 ~/.kde/share/config下面的配置文件(其实我把整个share文件夹都覆盖了)。

现在问题是其他的都似乎没有什么大问题,但是覆盖的kickerrc(配置上文提到的第二个部分中的kicker)文件没有作用,无论是在 /usr/share/config还是在~/.kde/share/config下面,kickerrc里面的设置没法被应用,而且通过手动去修改 Panel(比如增减Applet)后relog in kde session会用修改的配置覆盖掉~/.kde/share/config/kickerrc。似乎kickerrc只是反映当前的panel的设置而 不是系统根据kickerrc去配置当前的panel。

我在网上查了很多资料没找到原因,不知道这里有没有人知道。

更新:我用的是Redhat 3企业版(update几忘了,等查到再来更新:)。

How to capture key combination press in java

Though it may appear extremely easy to someone who has mastered it, I wanna paste some useful code here both for myself to keep a note and for those who haven’t ever addressed this problem to use as a guideline.

Code snippet (catch “ctrl+shift+`”):

public final static int CTRL_SHIFT_MASK =
KeyEvent.SHIFT_MASK | KeyEvent.CTRL_MASK;

if ((evt.getModifiers() & CTRL_SHIFT_MASK) != 0) {
if (inputEnabled) holdInput(true);

// Press “Ctrl+Shift+`” to toggle view only option.
if ((evt.getModifiers() & CTRL_SHIFT_MASK) == CTRL_SHIFT_MASK &&
keyCode == KeyEvent.VK_BACK_QUOTE) {
boolean viewOnly = !_vc.getConfigManager().isViewOnly();
_vc.getConfigManager().setViewOnly(viewOnly);
if (!viewOnly) {
inputRecorder.setPaused(false);
inputRecorder.setLastLogTime(System.currentTimeMillis());
} else {
inputRecorder.setPaused(true);
}
clearInput();
return;
}

Here key combination restricts to the pattern of modifier key(s) (ctrl, shift, alt) plus ordinary character key or only combination of modifier keys themselves.

The end.

Wednesday, October 26, 2005

Thoughts after Ivar Jacobson's speech. Is Agile Process really Agile?

25th Oct. Shanghai China, I heard Ivar Jacobson's speech about his understanding about the next generation of software process. IMHO, his key point is to make UP(Unified process) more agile than agile process, which he called "smart". Then I wasn't much convined, because I thought his understanding dpend too much on a intellegent product called "WayPointer" developed by one of his own company. But later when I went home and used WayPointer trial edition accompanied with the provided CD to work with Rational's product, I understand everything. It really can make RUP more agile. It's a intellegent agent acts as pair programmer, telling you when and what parts of RUP document to read.
And, another of his point supporting the key point is UP use explicit knowledge rather than tacit knowledge, which make ailge seem to be agile, used by agile process. With explicit knowledge you can learn and you can search for what to do next in the knowledge library. However, tacit knowlege is never documented and hard to be learned and harder to be searched. So the most experienced programmer have the most tacit knowledge, which make success of project primarily rely on key individuals. So, is Agile process really agile?(Anyone wants a PPT of his speech, email me at i.am.blogger at gmail dot com).
What a pity, Dr. Ivar didn't talk much about doing use case with aop, which he proposed in his latest papers and later turned out a book about AOSD(I got the book for free at the speech : ). So the following part of my blog will cover this aspect.
The report was received with complacency:" This is the nature of software--use case cross component--and there's nothing to be done about it."In RUP, use case play a very important role, elicitating requirements, coordinating stakeholder requests, measuring the grain of iteration. According to RUP, use cases are finded out, refined and then usually implemented in several components, that is, simply speaking, a use case is often devided into parts assigning to components(Classes, to simplify the matter) according to each component's reponsibility. However, that's not the end. In RUP test cases are derived from use cases, which means testing is usually conducted in terms of use case to verify every use case is correctly implemented. All we see is that it's really a use case driven way, but traditional components stands in the way, breaking down use cases. It seems if we are royal enough to use case technology, traditional component-centric development contribute negatively to the whole development process.And interestingly enough, in an AOP view, it's typically crosscutting, with every use case almost always cross cutting components. Dr. Ivar has his own way of solving this problem, which he proposed in this paper.
But I wonder if a use case driven method is widely adopted, otherwise it isn't worth much effort on this issue.
So here I wanna conduct a survey, how many companies use USE CASE technology and to what degree use case technology is adopted (only used to handle requirement issue or as a use case driven development way)?
Any comment about either my ideas or this survey would be very appreciated.

Saturday, October 22, 2005

Is AOP a Programming paradigm

Edited by: I.Am.Blogger at gmail dot com

Prerequisite:
“A programming paradigm is a paradigmatic style of programming (compare with a methodology which is a paradigmatic style of doing software engineering). A programming paradigm provides (and determines) the view that the programmer has of the execution of the program.”
(http://en.wikipedia.org/wiki/Programming_paradigm)

Yes:
“I would argue that by any reasonable definition of paradigm, AOP is one. You can "think aspects" starting from fairly early in the design process (probably requirements too); you can design and develop those aspects; you can make the code look like the design; the aspects can be treated as independent units, with independently assessable properties and value. All the things that I at least thought made OO a paradigm seem to apply...”
By Gregor Kiczalse(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001001.html)

Note that the original meaning of "paradigm" entails the notion that two different paradigms are incompatible, which means that the qualification as paradigms does not depend on whether you can use them independently but rather that you _cannot_ use them together. From this perspective, none of the programming paradigms in computer science are really paradigms, because it's certainly possible to mix them altogether…The analogy that I'd propose is that AOP relates to OOP as OOP relates to imperative programming, and if you describe the move from imperative programming to OOP as a paradigm shift, you also have to describe the move from OOP to AOP as a paradigm shift to the same degree.”
By Pascal Costanza (http://aosd.net/pipermail/discuss_aosd.net/2004-July/001004.html)

No:
“Mathematically, aspects form a second-order extension of any programming paradigm: while usual programming paradigms allow reasoning about single functions, messages and so forth by a function/message signature, AOP enables reasoning about entire sets of those entities by using pointcuts with wildcards in their signature. Thus one could view AOP as a powerful, logical extension, rather than as an independent paradigm. Friedrich Steimann, for example, has proposed such a view.”
Wikipedia(http://en.wikipedia.org/wiki/Aspect-oriented_programming)

“..In OOP you have communicating objects with encapsulated state. In FP you have the notion of encapsulated functionality and side-effect-freeness, however no explicit notion of state…that all the paradigms noted above can exists "on its own". You can use FP without OOP…AOP, however as I see it, always (correct me, if I am wrong here) makes use of a kind of "host paradigm", that provides basic expressiveness and then kind of provides a way for second-order reasoning on that "host paradigm"…”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001003.html)
“…when moving from IP to OOP,one gains the new concept of encapsulated state together with the notion of messages. This changes the whole universe of reasoning: Instead of reasoning about loops or sequences of commands executed on a machine (IP) one now certainly talks about objects that are communicating via messages.…I see the difference in the fact that when moving from IP to OOP, we change the entities we are reasoning about (objects rather than commands) while with AOP we don't really. Of course AOP claims an aspect as the additional entity of reasoning. But can one really see an aspect as a single entity ,that is without any coupling of the outer world? Objects in OOP do so, also do functions in FP (due to side-effect-freeness), aspects however don't, since in all AOP languages you will always at some point have to conrecretize when and where your aspect synchronizes with the rest of the world…An object in OOP is fully compositional without exposing any of its subunits to the outer world. For functions in FP, the same holds. However, does that also hold for aspects?....”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001005.html)

Two citations above By Eric Bodden

Note: FP=Functional Programming, IP=Imperative Programming.

About Me

My photo
I'm finishing my master degree in Software Engineering, Computer Science. I believe and have been following what Forrest Gump's Mam said: you have to do the best with what god gave you.