10 Big Choices

1. Specialty / Title choices (that is, if/when you have choices ;-)


Desktop
Network/Server
DBA
Special System Support/Developer
Support
Developer (“previously” a.k.a. Programmer)
Architect
Business Analyst
Tech lead
“People” Manager
Change-Configuration Manager
Project Manager
Product Manager
Tech writer
QA Tester
Power User

Titles have different meanings in different places and contexts. However, in almost all places, a good developer is also a level-3 support, level-3 analyst, level-3 tester, and a level-2 DBA. Note that a developer should not deal with production specific DBA issues, hence “level-2”.

The only “exception” is that some software is for “peer” developers, for example, a compiler development team; especially, if such a compiler, for some reason, is only for internal users. In such a situation, a programmers can be closer to a “pure” programmer. However, even in that situation, your statement is still valid – it is just not that obvious or meaningful anymore.

In other words, sometimes, a few “genius” developers can give the impression that they never do support. I guess that is because they have “earned” it by supporting their fellow/peer developers.


Here are two very interesting blogs:
http://www.ericsink.com/No_Programmers.html

http://joelonsoftware.com/items/2006/04/11.html


Interestingly, I agree with both whole-heartedly. They are from different sides. the boss/management and the developer. In an ideal world, of course, we can have both sides.

More practically, since I am not a boss, I would like to be a developer, not a “pure” programmer.

2. IT or not IT, esp. for Some Industries

Some industries are, by their very nature, special kinds of information technology. For example, Education is a kind of information technology. Accounting is a kind of information technology. Banking is a kind of information technology. To an extent, Healthcare is very much also a kind of information technology.

As a result, in those industries, IT is not just IT, they are at the very core of their businesses.

This is especially important for developers. Developers must realize that they must learn the classic (or “traditional”) concepts in those industries, in a critical way, knowing that those concepts are likely to be replaced by computerized new concepts within next decade. Note that I am talking about core (you may say “academic”) concepts. For example, relational database concepts can and should be applied to the very core of accounting.


3. Windows vs. Linux: I always miss the feel of freedom when I use Linux and its siblings. However, most of the time, in my work place, Windows is the king. So, setting up a Linux server in my garage is always at the top of my new-year resolution list. I do try to prevent it from getting cold by keep using vim and cygwin.

4. C/C++ vs. "pointless" "other" languages: I do not really miss C/C++; however, I really miss the feel of freedom and omnipotence when you can change and recompile a compiler, the OS, a driver, a database, a web server, a browser, or the runtime of Java or .Net. You leave C and you leave all those excitements behind.

5. "Other" languages that is not VB-Java-C#--Lisp: C#'s anonymous method enable us to appreciate some power of Lisp in C#.

6. "Other" languages that is not VB-Java-C# -- TCL: It is so elegant, a good reference for a “small language”.

7. "Other" languages that is not VB-Java-C# -- Perl: I miss the spirit of perel – at the heart of it, it is the feel of freedom (just like C), and the feel of being empowered to provide immediate business solutions (you do not have that in C). Also, I must mention regular expression, which will always be the legacy of perl -- we certainly had regular expression before perl; but for all practical purposes, perl has “defined” regular expression as it is today. I always keep regular expression at my finger tip, by using vim, which has a similar syntax like perl’s regex. Yes, I always follow news of perl, Python, PHP, and Ruby. Their real weakness? I believe it is that they pretty much depend on web to have a “face”.

8. Classic VB: I have to been using its various versions for more than 10 years. It improves productivity; but encourages not-easy-to-maintain coding. However, believe it or not, we can do a lot of right programming with classic VB, from VB3 to VB6. For example, we can do database accessing wrapping, separation of UI and business logic, and even unit testing, http://www.vbunit.org/ and http://www.devx.com/vb/Article/21529/1954?pf=true



9. Java: Finally, this is my first love – admittedly that I fell in love very late in my career ;-). In all other things, I felt the excitements; I felt the awe and powerfulness; I even felt freedom; but no love. I felt in love with Java. The reason, I guess, is that the language matches my thinking almost perfectly; as a result, I can think and code, nothing else. You are not distracted – that is how you fall in love.


10. C# vs. VB.net: Currently I use both. I prefer C# more, simply because most open source packages are in C#. We need VB.net, because when we use classic VB, we need VB.net for side by side copy/paste; when we do not use classic VB anymore, we need VB.net so that we do not forget VB.

My first post on the new CSLA forum

This is my first post on the new CSLA forum:
http://forums.lhotka.net/forums/thread/12.aspx

I write this post is to use my own personal experience to mark this historical moment for CSLA: a new forum, happens a few weeks after its C# new version -- version 2 for .net 2, and almost the same time of its VB.net’s new version – its C# version is a few weeks earlier than its VB.net version.

Here is my own personal experience: in the past, I had participated CSLA forum kind of sporadically. As a result, I forgot my login and had to re-join, a few times ;-)

This time, since I was lucky to be the first a few persons that joined the forum, I did not need to worry about the “availability” issue. I can choose a name that I can remember, survic. I will not forget my login again.

Also, it is time to do some clearing-house work. So, I copied two still relevant posts to this blog (see my previous two blog posts).

Diagnostics.StackTrace and NoInlining attribute

This is copied from my post in CSLA forum
http://groups.msn.com/CSLANET/general.msnw?action=get_message&mview=0&ID_Message=26513

In addition to the issue itself, it also gives an example of the benefits of participating key open source projects.


--------------------------------------------------------------------------------
-------------there are others posts before my post below;
-------------please use the above the link to see them
--------------------------------------------------------------------------------

I did some research, and read the following from here: (http://www.springframework.net/doc/reference/html/aop.html )

------------
Generally speaking, a method will be a candidate for inlining when its code is 'small', just a few lines of code (less than 32 bytes of IL). For some interesting reading on this process read David Notario's blog entries (JIT Optimizations I http://blogs.msdn.com/davidnotario/archive/2004/10/28/248953.aspx and JIT Optimizations II http://blogs.msdn.com/davidnotario/archive/2004/11/01/250398.aspx ).

Additionally, when an assembly is compiled with a Release configuration the assembly metadata instructs the CLR to enable JIT optimizations. When compiled with a Debug configuration the CLR will disable (some?) these optimizations. Emperically, method inlining is turned off in a Debug configuration.

The way to ensure that your control flow pointcut will not be overlooked because of method inlining is to apply the System.Runtime.CompilerServices.MethodImplAttribute attribute with the value MethodImplOptions.NoInlining. In this (somewhat artifical) simple example, if the code is compiled in release mode it will not match a control flow pointcut for the method "GetAge".

public int GetAge(IPerson person)
{
return person.GetAge();
}

However, applying the attributes as shown below will prevent the method from being inlined even in a release build.

[MethodImpl(MethodImplOptions.NoInlining)]
public int GetAge(IPerson person)
{
return person.GetAge();
}

----------


Basically, this means all methods that use the following 3 methods’ overload that without property name must use the
[MethodImpl(MethodImplOptions.NoInlining)] attribute.

CanReadProperty() or (boolean);
CanWriteProperty() or (boolean);
PropertyHasChanged();

It seems those overloads do not buy too much. However, considering the attribute can be added mechanically, those overloads can still be useful.

--------------------------------------------------------------------------------
-------------there are others posts before my post below;
-------------please use the above the link to see them
--------------------------------------------------------------------------------
I agree. Because the nature of the unpredictability of inlining optimization, whenever we use the convenient overloads without “property name”, we need to use the NoInlining attribute.

So:

(a) Comment for the convenient methods should indicate that;
(b) The example in PTracker should be changed to use the NoInlining attribute.


--------------------additional note:
Note that this also affect

System.Reflection.MethodBase.GetCurrentMethod().Name

It seems that other than hard coding/code generation, the only way is to use emit-aop. For now, virtual methods are not inlined. Even in the future, when virtual methods are inlined, the aop process will be done before inlining -- I will need more research on this though. I will report the result later.

Also note that the techique used for log4net seems still ok, because that is at class level.

Changes in my use of CSLA

This post is copied from my post on CSLA forum.
http://groups.msn.com/CSLANET/general.msnw?action=get_message&mview=1&ID_Message=26149

It gives the other side of the same coin of my recent blog : http://survic.blogspot.com/2006/04/core-ottec-techniques.html

------------------------
Sent: 4/9/2006 1:30 AM
Subject: emit--no need of code gen; not limiting to 4 (CRUD) methods etc.
------------------------
Hi there:

After studying CSLA 1.X and 2 for a while, I am going to use emit on CSLA. I want to know interest and comment.

It will be at two levels: dataportal level and property/get/set methods level.

The direct effect is that it will reduce the need of code gen. Together with 2005’s Code Snippets, this will dramatically reduce the threshold of CSLA adoption.

Another significant benefit is that we are not limiting to 4 (CRUD) methods anymore; so, the object model will be closer to the domain logic, instead of the artifacts of 4 methods limits. Consequently, the need of special workflow objects will go away, and no need for special “criteria” and “exists” classes.

At property level, we will have cleaner property/get/set, because we do not need litter those CanRead/WriteProperty, PropertyHasChanged calls.
Also, it will be easier to add custom features without touching the framework -- effectively, it is inheritance on steroid.

The only downside is that the mechanism is too powerful and is easy to be misused. However, I feel that the above benefits are too good to be ignored.

CSLA can be the open-source (or "source-available") “game-engine”

This is copied from my post on http://www.lhotka.net/WeBlog/CommentView,guid,e76ff2d8-d8cf-436b-8bf7-bdec2ff06b2a.aspx


Imagine CSLA can be the open-source (or "source-available")“game-engine”

1. >>“We probably should have just used Enterprise Services and bought a bigger computer - that would have been cheaper.”

---- Perhaps not even need “a bigger computer” – How about make CSLA to abstract tx further -- combine all those things into the COM+ style?

2. >>“Honestly I think this can be done with tools - like Visual Studio - and still allowing us to use C# or VB.”

---- How about finding ways to “integrate” CSLA “into” Visual Studio? 3.

>>“But failing that, it may be the case that we need a different tool/language that is more directly focused on business development.”

---- How about introducing a “small language” into CSLA. Here is an example -- those validation rules -- we need a tool to translate them into javascript. I am thinking, if we can define a subset of C#/VB.net and javascript, and we write the validation rules only using such a subset. Because it is a common denominator, the translation can be accurate and totally automatic.

"OTTEC" and "Mort" without "smells"

This is copied from my post on:

http://www.lhotka.net/WeBlog/CommentView,guid,e76ff2d8-d8cf-436b-8bf7-bdec2ff06b2a.aspx


Vikas: I agree with you saying that a 2-3 months project is the sweet spot for XP, which was getting popular within lightweight java niche (which is not "entity bean J2EE" though; "entity bean J2EE" typically corresponds to UP). I guess we could say it is "Elvis".

However, I would say that a typical classic VB project is less than 2-3 months. So, we need a concept for project even lighter than XP. I guess we could say it is "Mort".

For "Einstein", that is C/C++, of course.

I’ve just realized that my career is from "Einstein" to "Elvis" and to "Mort". My goodness! Is the next step using VBA-equiv. with a "game engine" which is written offshore?

I do not believe in that future, though. I agree with you, and not agree with Frans, enterprise computing requires flexibility, it cannot be done via “game engine” approach. Another way to look at it, comparing with classic C/C++, the modern Java and .net platforms are themselves a flexible “game engine”.

The key of “Mort” is that it can compete with off-shoring and “game-engine configuring/scripting” (or a combination of both) head-on: to off-shoring, you need detailed spec; however, “Mort” can get the whole thing done during the “spec” timeframe. The same thing happens to “game engine” – you need to “configure” or “scripting” an “engine”; however, “Mort” can finish it earlier than the “configuring” or “scripting”.

However, to do that, while keeping the key spirit of extreme agility, “Mort” must give up those classic VB habits, in TDD terms, “smells”. For example, no logging, mix UI with business logic, no “transaction” concept, or, handle transactions in ad hoc ways, no authorization concept, or, handle authorization in ad hoc ways, and no automated (“pretty-high-level”) unit testing. Without giving up those “smells”, the career of “Mort” will end with VB6. This is indeed the implication of .net, off-shoring simply makes it faster and more sudden and possibly disruptive (let's hope it will not, if we "Morts" do it right). survic http://survic.blogspot.com

P.S. I went to Vikas's site, http://www.vikasnetdev.blogspot.com/ it is amazing that we used the same blog tempalte, and did similar modifications, and share similar ideas! Note that Vikas's blog started more than one year before mine; but I swear :-) I did not see Vikas's blog before I created mine. Great minds work alike :-)

By the way, I will put more code, but, well, a blog is a blog -- in blog, code takes secondary place ;-)