答:
Case sensitivity makes code more readable and programming easier.

People find proper use of mixed case easier to read.

It allows/encourages CamelCase such that the same word with different case can refer to related things: Car car;  Thus the variable named car is created of type Car.

ALL_CAPS_WITH_UNDERSCORES indicates constants by convention in many languages

all_lower_with_underscores can be used for member variables or something else.

All modern programming tools (source control, editors, diff, grep, etc) are designed for case sensitivity.  You'll forever be having problems with tools programmers take for granted if you make a case insensitive language.

If the language will be interpreted, there may be a performance penalty to case insensitive parsing of the code.

What about non-English characters?  Are you deciding now to never support Coptic, Chinese, and Hindi?  I'd strongly suggest you make your language default everything to UTF-8 and that supports some languages that have characters with no upper or lower-case equivalent.  You won't use these characters in your keywords, but when you start turning off case sensitivity in various tools (to find things in files for instance), you will run into some surreal and probably unpleasant experiences.

What's the benefit?  The 3 languages you mention are from the 1970's or earlier.  No modern language does this.

On the other hand, anything that actually makes the end-user happy brings a little light into the world.  If it will really effect user happiness, then you have to do it.

If you want to make it really simple for end-users, you can do better than case sensitivity/insensitivity - have a look at Scratch!  A few less cartoon cats and more business-friendly colors and you have about the friendliest language I've ever seen - and you don't have to write anything!  Just a thought.

Title: Case insensitive keywords in a language

Body:
We're trying to write a custom scripting language. There has been a suggestion to make the language forgiving by providing case insensitive keywords.

I personally do not like the idea, but there are few people in my team leaning towards it, saying it will make the end user happy! Examples of languages like FORTRAN, BASIC, SQL are given saying that these are case insensitive.

Is this a good idea?


问:
In Scrum, should you split up the backlog in a functional backlog and a technical backlog or not?
In our Scrum teams we use a backlog, which mostly contains functional topics, but also sometimes contains technical topics.  The advantage of having 1 backlog is that it becomes easy to choose the topics for the next sprint, but I have some questions:

First, to me it seems more logical to have a separate technical backlog, where developers themselves can add pure technical items, like: we could improve performance in this method, this class lacks some technical documentation, ...  By having one backlog, all developers always have to pass via the product owner to have their topics added to the backlog, which seems additional, unnecessary work for the product owner.

Second, if you have a product owner that only focuses on the pure-functional items, the pure-technical items (like missing technical documentation, code that erodes and should be refactored, classes that always give problems during debugging because they don't have a stable foundation and should be refactored, ...) always end up at the end of the list because "they don't serve the customer directly".  By having a separate technical backlog, and time reserved in every sprint for these pure technical items, we can improve the applications functionally, but also keep them healthy inside.

What is the best approach?  One backlog or two?

答: I'm no expert but I'd say you can only have one backlog per team. The team needs to decide which issues are urgent and which ones can be postponed. If you separate the issues into separate types of stacks you go against the core idea that is at the heart of scrum, which is that there is a pool of issues and each sprint the team works on the most urgent of them. If you (sub)divide the teams you might be able to divide the types of tasks which are relevant to them, but you'd basically be setting up teams which work in parallel. Urgency/necessity is the number one decider when it comes to planning the next sprint. You may categorize the tasks, but this shouldn't get in the way of your decision process.</p>

ContentLicense: CC BY-SA 3.0


问:
Is taking frequent breaks really that beneficial when programming?
I keep reading that it is recommended for a programmer to take frequent breaks while programming, and the usual recommendation I see is 5 minutes every half hour or 10 minutes every hour.

I gave it a try, but quite often I find something interesting during those 5 minutes, and it takes me away from what I was working on for longer than I planned. Either that, or my mind gets focused on something else and I find it hard to get back into my work and don't focus very well.

Is it really that beneficial to take frequent breaks while programming? Am I doing something wrong for it to be decreasing my productivity instead of increasing it?

答:
Absolutely. I'm an advocate of the Pomodoro technique, the most general implementation of which is 25 minutes on, 5 minutes off. A pomodoro is atomic, so you can't do half of one. This forces you to sit and think through a problem without wandering off to gmail or SO. Conversely, you're also forced to get up every twenty five minutes and walk around or do something non-job related (I occasionally violate this if I'm deep in a problem). </p>

<p>I've been doing this for about half a year and find that the "head down coding for hours" myth is largely that, a myth. I'm more productive, and generally spend less time dealing with stupid problems (E.g. today I typed [] instead of () when trying to invoke a javascript function) when I force myself to stop every 25 minutes. </p>

Body:
Absolutely. I'm an advocate of the Pomodoro technique, the most general implementation of which is 25 minutes on, 5 minutes off. A pomodoro is atomic, so you can't do half of one. This forces you to sit and think through a problem without wandering off to gmail or SO. Conversely, you're also forced to get up every twenty five minutes and walk around or do something non-job related (I occasionally violate this if I'm deep in a problem).

I've been doing this for about half a year and find that the "head down coding for hours" myth is largely that, a myth. I'm more productive, and generally spend less time dealing with stupid problems (E.g. today I typed [] instead of () when trying to invoke a javascript function) when I force myself to stop every 25 minutes.

ContentLicense: CC BY-SA 2.5


问:
Community Programming
Background

I just began working for a religious non-profit organization. As with most non-profits, the organization is resource-poor and has no IT department to speak of. In my two months here I've received 20 requests for websites, apps, and internal automation. Many of these 20 requests have merit and would benefit the organization.

I'm a .net web developer and as such the open source community is relatively foreign to me...

Question

For the sake of this question, lets say I'm talking about building a single, large, website.

Does software (web based, hopefully) exist that would allow me to post requirements and assets (graphics and CSS) for a site, and then invite programmers to participate in the sites development?

As a simple example, I could post the requirements and data for the about us page and an individual would indicate that they could/would fulfill the requirement. Upon completion, they could upload the new source code to the shared repository (github).

答:
In addition to Turnkey's answer:

Consider having style guidelines and a preferred site structure in place prior to soliciting help.  This will make it easier for developers to come and go but still be able to understand how a given change blends in with the rest of the site.

Prioritize the requests, as difficult as that may be.  A large list of tasks to work on can be overwhelming.  Providing guidance to the contributors helps them understand where the organization's needs are really at.

Title: Community Programming


问:
Best way of accessing data on different pages
I'm looking for a way to load data into properties/variables etc and have this information accessible to all the pages of my app.
I want the information to be loaded via a background thread to keep UI thread free. Some of the pages will have various properties of their controls binding to these global properties.

Here is what I tried.

Created a static class. All pages could access the data but can't bind.

Changed the static class to a Singleton and used DependencyProperty's. All pages could access data and binding worked fine but cross-threading issues when accessing via background threads.

I have read in various places on this subject but haven't really come up with the best method yet for my situation.

答:
I would probably have each page bind to different ViewModel objects, and let your ViewModels worry about accessing/updating the data in your "static" class.

If that's not an option, remember that DependencyObject is not the only way to go if you want to bind a page to an object. I personally prefer using INotifyPropertyChanged. This way you can have the UI update data on the UI thread and still be able read data on a different thread. Of course you're going to need to write your code in such a way that it is thread safe, but at least you won't get an exception when accessing properties that your UI is bound to.

Also note that singletons have their downsides. If I were you, I'd probably use dependency injection as an alternative if possible.


答:
James, you are doing a great job !

In addition to the provided answers to host this project using GitHub, you may also get local developer support to help you with your initiative.

Depending on where are you located there is a GiveCamp event - a weekend long marathon where IT professionals donate their time and skills for charities. You may also get inspired developers from that communities to help you.

Last year, I have attended the one in Baltimore, MD. It was a great feeling to help the non-profits that were doing wonderful job to the communities in need. This year, i am also planning to attend and give back to the non-profits that support needy communities.

Title: Community Programming

Body:
Background

I just began working for a religious non-profit organization. As with most non-profits, the organization is resource-poor and has no IT department to speak of. In my two months here I've received 20 requests for websites, apps, and internal automation. Many of these 20 requests have merit and would benefit the organization.

I'm a .net web developer and as such the open source community is relatively foreign to me...

Question

For the sake of this question, lets say I'm talking about building a single, large, website.

Does software (web based, hopefully) exist that would allow me to post requirements and assets (graphics and CSS) for a site, and then invite programmers to participate in the sites development?

As a simple example, I could post the requirements and data for the about us page and an individual would indicate that they could/would fulfill the requirement. Upon completion, they could upload the new source code to the shared repository (github).


答:
What you're referring to is commonly called 'technical debt'. It can sometimes be difficult to see how technical debt work fits into the scrum process, in the same way that defects can.

What you are proposing is similar to suggesting that there be a separate 'defect backlog' as well, splitting the backlog into 3.

Personally, I would not advocate splitting the product backlog at all. The idea of the product backlog is to represent outstanding items of work. From that perspective, the only difference between a feature and a technical debt item is that the requirement came from the development team, not from the customer. It is still an item of work and it still needs to be managed, including prioritizing it against other items of work. This is especially true if the technical debt item requires testing, in which case it should go through exactly the same QA process as a regular feature.

Title: In Scrum, should you split up the backlog in a functional backlog and a technical backlog or not?

Body:
In our Scrum teams we use a backlog, which mostly contains functional topics, but also sometimes contains technical topics.  The advantage of having 1 backlog is that it becomes easy to choose the topics for the next sprint, but I have some questions:

First, to me it seems more logical to have a separate technical backlog, where developers themselves can add pure technical items, like: we could improve performance in this method, this class lacks some technical documentation, ...  By having one backlog, all developers always have to pass via the product owner to have their topics added to the backlog, which seems additional, unnecessary work for the product owner.

Second, if you have a product owner that only focuses on the pure-functional items, the pure-technical items (like missing technical documentation, code that erodes and should be refactored, classes that always give problems during debugging because they don't have a stable foundation and should be refactored, ...) always end up at the end of the list because "they don't serve the customer directly".  By having a separate technical backlog, and time reserved in every sprint for these pure technical items, we can improve the applications functionally, but also keep them healthy inside.

What is the best approach?  One backlog or two?


答:
I agree with Onno in that there should be only one single backlog per project. Otherwise, the team is basically taking in their own hands some decisions which rightfully belong to the product owner.

Even "purely technical" items must have some practical value for users (and therefore for the product owner) to be eligible for the sprint backlog. It is your task to explain the benefit of these to the product owner, and to convince him/her of the added value which justifies the cost. And this process forces you yourself to think through these issues and select the technical changes which bring the most value to the project with the least effort.


问:
Bug Tracking Etiquette - Necromancy or Duplicate?
I came across a really old (2+ years) feature request issue in a bug tracker for an open source project that was marked as "resolved (won't fix)" due to the lack of tools required to make the requested enhancement. In the time elapsed since that determination was made, new tools have been developed that would allow it to be resolved, and I'd like to bring that to the attention of the community for that application.

However, I'm not sure as to what the generally accepted etiquette is for bug tracking in cases like this. Obviously, if the system explicitly states to not duplicate and will actively mark new items as duplicates (much in the way the SE sites do), then the answer would be to follow what the system says. But what about when the system doesn't explicitly say that, or a new user can't easily find a place that says with the system's preference is? Is it generally considered better to err on the side of duplication or necromancy? Does this differ depending on whether it's a bug or a feature request?

答:
I'd say this differs between bug and feature request.

When you create a bug report in bugtracker, you're usually describing symptoms. It does not however mean, that underlying cause is same or even similar. Especially if internals are well hidden from end user, and all you get is generic error when something went wrong. In such a cases necromancy is not the way to go, as event though external symptoms might seem similar, it's most likely completely different bug. If you'd reopen old bug, the developer would probably start to investigate the old cause, which may lead him in complete wrong direction and loose time.

For feature request which was rejected and the rejection reasons are no longer valid, I'd say necromancy is the way to go. In this case you know that creating new ticket you would be creating exact duplicate.


答:
I'd like to add my voice to those who recommend one backlog per product.  Creating another backlog is a rational response, but is really just avoiding the core issue: Why won't the Product Owner prioritise technical items over feature items?  You should focus on solving this rather than working around it.  You could use the 5 Whys technique, for example, to try to get to the bottom of things.

There could be many reasons why the PO doesn't prioritise technical issues.  For example, maybe the tech team isn't explaining the long-term cost (in $$$) of not addressing the technical debt.  Maybe it's something else completely.  There's a good chance it's down to a communication issue, and the long-term solution is to work on it and resolve it -- remove the impediment.

Additionally, I have an another question for you to think about: Why has the technical debt arisen in the first place?  Ideally work such as refactoring etc. should happen within the functional stories and be completed within the sprint.  They shouldn't be extra stories in their own right otherwise you don't have potentially shippable code.


问:
Issues with time slicing
I was trying to see the effect of  time slicing, and how it can consume significant amount of time. Actually, I was trying to divide a certain task into a number of threads and see the effect.

I have a two core processor. So two threads can run in parallel. I was trying to see if I have a task w that is done by 2 threads, and if I have the same task executed by t threads with each thread doing w/t of the task. How much does time slicing play a role in it.

As time slicing is time consuming process, I was expecting that when I do the same task using a two thread process or by a t thread process, the amount of time taken by the t thread process will be more.

Any suggestions?

答:
http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

The article above tries several ways to measure context switch time for a number of recent processors.

It comes up with a rough 30 microseconds (good worst case) per context switch though the numbers vary a lot depending on what you are measuring.

Title: Issues with time slicing


问:
Should UML be used before or after a basic Program Design
UML Diagrams take time and even though they provide knowledge about program design, the design changes and so do requirements, and hence it becomes a chore to keep UML Diagrams in Sync  with code. I am trying to figure out how should we use UML in an optimum way.  </p>

答:
It depends on how you are using UML and what information you need to capture and share with other people.

I've seen two primary use cases for UML. The first is as a language to capture design ideas at a high level. These diagrams wouldn't include every detail of the system, just the important ones. Often, these are also the more abstract diagrams - use case diagrams, state machine diagrams, activity diagrams, deployment diagrams, and to a lesser extent component diagrams and package diagrams. Some work might be done toward sketching class diagrams with an emphasis on public interfaces (ignoring, at this time, any private members or functions) and sequence diagrams. The other use case for UML is to capture the current state of a system, using reverse engineering tools. These are often more detailed class diagrams, sequence diagrams, communication diagrams, object diagrams, composite structure diagrams, and so on. This serves as documentation into how the system actually is for discussions about changes to the system.

As far as when to apply UML, it depends. At the right granularity, some of the diagram types can be used as soon as you start discussing system architecture. Others are more suited to discussions of detailed design and the specifics of the system. It all comes down to choosing the right diagrams to display relevant information to the people who need it in a timely fashion.

With regards to the problems with keeping UML in sync with code, there are two things to consider. First, review the types of documentation that you are keeping. If none of it is actively consumed or value-adding, this might be a good idea to eliminate it. If it's difficult to update, the act of updating it might be something that's pushed aside. Out-of-date documentation is worse than non-existent documentation, since no one can make a decision based on incorrect information. Second, if you have a codebase already, there are tools for facilitating the generation of UML diagrams from code, often called CASE tools or reverse-engineering tools - considering automating the process.


答:
UML is a great tool to use during and after program design but only if you use it right.

First you need to ask yourself, why are you producing UML diagrams?  Then you need to be honest with yourself and ask, is anyone actually going to read these, ever?

During design, having a UML diagram provides something for the development team that they can focus on and discuss.  But this diagram doesn't need to be formal or even in any kind of document. Just take a whiteboard or a napkin and start drawing boxes.  In this case, UML is just a loose set of rules that provides "common language" to everyone looking at your whiteboard.

After the design, and I mean, WAY after the design, when your code has settled down and you are not moving classes around, this is when you might decide that you want to capture some of the knowledge in a formal design document to preserve organizational memory.  In this case, I would suggest to keep the design document at a high level (if people need details, that's what code is for). But UML could certainly be useful to highlight some of the major classes in your application and how they relate to each other.  The key is that you want to produce these documents only after all (or at least most) changes are done, otherwise you will discover that maintaining UML can be a pain.

Title: Should UML be used before or after a basic Program Design

Body: UML Diagrams take time and even though they provide knowledge about program design, the design changes and so do requirements, and hence it becomes a chore to keep UML Diagrams in Sync  with code. I am trying to figure out how should we use UML in an optimum way.  </p>


答:
UML can be used in a whole spectrum of ways - from the back-of-the-envelope drawings all the way through the round-trip engineering, and everything in between these two ends. Deciding how to use UML depends a lot on the preparedness of your organization, and your management's stomach for the risk.

Deciding on round-trip engineering would address the synchronization problem, but will cost your team in terms of learning curve, and will almost certainly tie you to a single expensive vendor of software tools. This becomes especially important when the vendor has higher priorities than fixing a bug that annoys most of the developers in your organization; you don't have to worry about it if your organization is among the IBMs of the world, but in most other cases the concern is very real.

Deciding on UML as a drawing convention (i.e. no ties to code) brings along the code synchronization problem, but gives you flexibility to choose vendors for your UML tools, or even using free tools if you wish. In this case UML diagrams become just another piece of documentation that you maintain along with the code of your project. You should decide when this documentation gets updated.

One example that I've seen working reasonably fine required the UML documentation to be in sync at the time the coding starts, and at the time the coding is complete. During the coding phase we updated UML on paper if necessary, but we did not bother updating the electronic copy each time we added a method or refactored a class.


问:
Style bits vs. Separate bool's
My main platform (WinAPI) still heavily uses bits for control styles etc. (example).

When introducing custom controls, I'm permanently wondering whether to follow that style or rather use individual bool's. Let's pit them against each other:

```<code>enum EMyCtrlStyles
{
   mcsUseFileIcon = 1,
   mcsTruncateFileName = 2,
   mcsUseShellContextMenu = 4,
};

void SetStyle(DWORD mcsStyle);
void ModifyStyle(DWORD mcsRemove, DWORD mcsAdd);
DWORD GetStyle() const;

...
ctrl.SetStyle(mcsUseFileIcon | mcsUseShellContextMenu);
</code>```

vs.

```<code>CMyCtrl & SetUseFileIcon(bool enable = true);
bool GetUseFileIcon() const;

CMyCtrl & SetTruncteFileName(bool enable = true);
bool GetTruncteFileName() const;

CMyCtrl & SetUseShellContextMenu(bool enable = true);
bool GetUseShellContextMenu() const;

ctrl.SetUseFileIcon().SetUseShellContextMenu();
</code>```

As I see it,

Pro Style Bits

Consistent with platform

less library code (without gaining complexity), less places to modify for adding a new style

less caller code (without losing notable readability)

easier to use in some scenarios (e.g. remembering / transferring settings)

Binary API remains stable if new style bits are introduced

Now, the first and the last are minor in most cases.

Pro Individual booleans

Intellisense and refactoring tools reduce the "less typing" effort

Single Purpose Entities

more literate code (as in "flows more like a sentence")

No change of paradim for non-bool properties

These sound more modern, but also "soft" advantages. I must admit the "platform consistency" is much more enticing than I could justify, the less code without losing much quality is a nice bonus.

1. What do you prefer? Subjectively, for writing the library, or for writing client code?

2. Any (semi-) objective statements, studies, etc.?

答:
The booleans have almost all the advantages.  All the bit advantages you mentioned except "Consistent with platform" can be completely overcome by carefully packaging booleans into classes.  Booleans make for dramatically cleaner code and better design.

However, bits do have one very big advantage.  They are faster and use less memory.  If you have 10 million objects, each with a set of 60 boolean values, your program will run faster and use a lot less memory if you use the bits.  (This is why the platform still uses bits.)  You have to decide at the start of a project how much performance matters, because it will be very hard to switch your booleans to bits later.

If I have a couple of booleans in a class that may end up with a couple hundred instances, I'll stick with booleans.  If it's the 10 million and 60, and performance matters, I go with the bits.  If it's in the middle, I end up thinking for a while.

Title: Style bits vs. Separate bool's


问:
Should curly braces appear on their own line?
Should curly braces be on their own line or not? What do you think about it?

```<code>if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}
</code>```

or should it be

```<code>if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}
</code>```

or even

```<code>if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();
</code>```

Please be constructive! Explain why, share experiences, back it up with facts and references.

答:
It depends on the platform/language/conventions

In Java:

```<code>void someMethod() {
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}
</code>```

In C#

```<code>void someMethod()
{
     if (you.hasAnswer())
     {
         you.postAnswer();
     }
     else
     {
       you.doSomething();
     }
}
</code>```

In C:

```<code>void someMethod()
{
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}
</code>```

I hate when Java guys use their style in C# code and vice versa.

Body:
It depends on the platform/language/conventions

In Java:

void someMethod() {
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

In C#

void someMethod()
{
     if (you.hasAnswer())
     {
         you.postAnswer();
     }
     else
     {
       you.doSomething();
     }
}

In C:

void someMethod()
{
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

I hate when Java guys use their style in C# code and vice versa.


答:
UML is great for conveying ideas and getting your mind wrapped around a given problem domain.  However, like ANY documentation, it is only good for a moment in time.  Go back to the agile manifesto regarding documentation.  It is more important to provide working software than it is to provide comprehensive documentation that needs to be updated continuously.

When given a problem, use UML to understand the problem and then design a solution.  You can use it in peer discussions to convince your co-workers to your solution, or as a catalyst for collaboration.

Build your solution and then check in your diagram along with your story or attach it to your work item in your project management software.  Then, move on to the next story.  You have it for later reference, but you should not be expected to keep going back and updating it.

Take note however - All of this is true unless this is some sort of flight controls software for a fighter jet where the government requires comprehensive documentation - but most of our work is in a business environment where MIL-STD-2167A is not required, thank goodness.


问:
What is use of universal character names in identifiers in C++
The C++ standard (I noticed it in the new one, but it did already exist in C++03) specifies universal character names, written as \uNNNN and \UNNNNNNNN and representing the characters with unicode codepoints NNNN/NNNNNNNN. This is useful with string literals, especially since explicitly UTF-8, UTF-16 and UCS-4 string literals are also defined. However, the universal character literals are also allowed in identifiers. What is the motivation behind that?

The syntax is obviously totally unreadable, the identifiers may be mangled for the linker and it's not like there was any standard function to retrieve symbols by name anyway. So why would anybody actually use an identifier with universal character literals in it?

Edit: Since it actually existed in C++03 already, additional question would be whether you actually saw a code that used it?

答: Someone may want to create an identifier using a foreign language character that is not enterable on the keyboard or input device. Alternatively, the identifier may contain a character that is not printable using the font or output capabilities of the device but the IDE wants to show an accurate representation.</p>


问:
Switching licenses, or cross licensing existing GNU GPL v3 software
I'm in the process of making a fork of GNU coreutils with a range of modifications. I'd like to release the result as an open-source project, but I'm not so much of a fan of GNU GPL as a license.

Is it possible to change the license, or provide the software under both GNU GPL v3 and CC BY-NC-SA?

答: No. The GPL gives no right to re-licence the copyrighted work under a different licence.</p>


问:
Is it possible to keep only one Database for both web and desktop applications?
I'm experiencing a trouble with my business model, let me explain better.

I'm developing a software for 1 year and few months, it's for the food industry, more exactly a software to: Delivery, Take Way, Table Reservation, POS, Accounts Payable and Receivable, Prints(receipt), Kitchen Monitors Orders, Customers Orders Control and Fiscal Area.

Well, I had separated the software mainly in two areas, one is web area and the other is desktop area (Used by Admins only) and local installed.

1 - Web Area (Basically do the follow:)

Show Catalog with the products

Customers Make Orders

Customers Pay for the Orders

etc ... as mentioned above

2 - Desktop Area

Manage Orders

Manage Customers

Manage Suppliers

Manage Accounts Payable and Receivable

etc ... as mentioned above

The web area is hosted in an online web server (scripts and database are online). The Desktop area is hosted locally in a Linux machine with a local database and local scripts files.

My question is:
Is it possible to keep only one Database for both applications? If YES, please what is the best approach?

Follow my technical specification environment

Database: Actually I have two databases working and I would love to keep only one.

Operating System: Linux (Kernel 2.6.X and above) or Windows (XP and above)

For the Web Area

Apache, PHP, Python, Java Script, Shell Script and MySQL.

For the Desktop Area:

PHP-GTK2, Apache, PHP, MySQL and Shell Script.

Addtional Information about the system [EDITED]

The main purposes to have a Desktop environment is:

I need to print and give out Tax Coupon on each new order.

I have the drawer.

I have a serial reader (Bar code).

I have a terminal to query for information.

and few other stuffs that is so hard if not impossible to do in the web environment.

Desktop relational schema: 104 tables.
Web relational schema: 42 tables.

Permissions is assigned based on: Deny all by default, and assigns as needed.

(Validation / Sanitization) has already been done in the web application.

Until now performance is not a problem, since every fiscal year part of my database will be archived.
(Also customer, suppliers and all related data about them will be archived after 3 years of inactivity).

My real problem is I have 2 environments today and I would love to have only 1.
Then "merge" the both worlds into one is an option, but not sure about.
I would love to read here a lot of ideas about this matter.

Observation about the process: Today it is in operation and it works fine, but I feel like waste time in some process.

Take a look in the scenario:

The order is made in the internet, then stored in my Web database.

The "order" is sent to the kitchen and prepared.

Print a receipt (Tax Coupon), put it with the order and delivery to the customer.

A Tax Coupon is generated by my Desktop Environment and it need a call to the orders table, but it is not the Web Order Table but a Desktop Order Table.

In few words I need to generate again the order to fill up the Tax Coupon. The same happen to Customer Register, Supplier Register and few other stuffs.

I hope this information turn my question more readable. Thanks Again!

答:
Sure it is possible, mySQL is a database server, and is designed to support connections from multiple sources, whether these are local or remote.

However, when installed on a webhost, by default mySQL is typically configured to only allow local connections for security reasons. There is a setting in the configuration file to enable/disable remote connections, you will need to set this accordingly.

See: How Do I Enable Remote Access To MySQL Database Server? for details.


答:
I think it really depends on the task you are working on.  Sometimes I find a 5-10 minute break to clear my thoughts and stretch/walk about can really be beneficial.  Other times I will leave my desk and come back and my code will look almost alien to me as my train of thought has jumped.

Generally speaking I say good thing, but I would disagree with using an app like @Pierre suggested, I tried something similar before and found it frustrating.

Title: Is taking frequent breaks really that beneficial when programming?

Body:
I keep reading that it is recommended for a programmer to take frequent breaks while programming, and the usual recommendation I see is 5 minutes every half hour or 10 minutes every hour.

I gave it a try, but quite often I find something interesting during those 5 minutes, and it takes me away from what I was working on for longer than I planned. Either that, or my mind gets focused on something else and I find it hard to get back into my work and don't focus very well.

Is it really that beneficial to take frequent breaks while programming? Am I doing something wrong for it to be decreasing my productivity instead of increasing it?


问:
What Design Pattern is separating transform converters
For converting a Java object model into XML I am using the following design:

For different types of objects (e.g. primitive types, collections, null, etc.) I define each its own converter, which acts appropriate with respect to the given type. This way it can easily extended without adding code to a huge if-else-then construct.

The converters are chosen by a method which tests whether the object is convertable at all and by using a priority ordering. The priority ordering is important so let's say a List is not converted by the POJO converter, even though it is convertable as such it would be more appropriate to use the collection converter.

What design pattern is that?

I can only think of a similarity to the command pattern.

答:
It sounds like the strategy design pattern.

a software design pattern, whereby an algorithm's behaviour can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it...

For instance, a class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed. The validation strategies, encapsulated separately from the validating object, may be used by other validating objects in different areas of the system (or even different systems) without code duplication...

You have different algorithms for similar things.


答:
As the other answers already indicate there are many ways to use UML. Especially you are using it with different detail levels and different times in a project.

But you are asking about synchronizing code with UML. Our primary focus for one of our tools (UML Lab) was the cycle between Design and Implementation phases. To adapt the UML design while changing the source code becomes necessary. Being able to switch back and forth between fine design and code is called round-trip-engineering. Using such techniques failed for quite some time as there still is some abstraction necessary to really make use of such techniques. But it is possible now: One can reverse engineer Java code with custom templates and generate the very same source code from it afterwards. This enables developers (or architects) to modify the class design while the implementation is already running. We are doing this with Class Diagrams only. Regarding analysis of behavior, there are other tools, of course. But there is no round-trip-engineering for those parts of UML, as far as I can tell.

Tools for mapping back code to earlier phases than Design or even Requirements do not exists (yet:). Usually this problem is addressed by "traceability": The tools keep track of the results for artifacts so they can tell which requirements are affected by a source code (or whatever) change.


问:
Is agile about development or management?
On a debate over what Scrum is all about, I found that perhaps I totally misunderstood the agile thing. It appears to me that Scrum (which is certainly considered an Agile process) is all about managing features and sprints and roles and stuff with nothing to do with TDD, pair programming, CI, refactoring and other developer centric techniques and practices that I though (until now) are the heart of agile. Now I am facing a difficulty !

1) Is Scrum agnostic to whether developers do agile practices?

2) Can you implement Scrum in a team that does not utilize automated tests? does not perform refactoring or does not adhere to the agile programming practices?

答:
Is agile about development or management?

Agile is a set of software development practices to meet flexibility and fast phase changing market requirements- or so called accelerated delivery. So in a big picture, it is about a flexible approach to meet the changing complex requirements of the client by splitting work in small peaces and delivering functionality in quick iterations of 2-4 weeks.

However to meet this flexibility, the development team needs to practice Agile programming practices.

Description from Wiki in regards to Agile software development:

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.


答:
It's a common mistake to think that Scrum is equal to Agile.

Being Agile is following the four principles of the Agile Manifesto. Scrum is a project management process consistent with those principles but it's not, in and of itself, being Agile. XP (TDD, pair programming) is a development process, also consistent with those principles, and consistent with Scrum, but it is not being Agile. Continuous Integration, Continuous Delivery, DevOps, all consistent with the Agile principles.

Follow the principles, first and foremost. All of these buzz-phrases are just methodologies that people have found successfully help them to follow the principles. But the main part of "being Agile" is being able to adjust your processes at will where they don't follow the principles of Agile.

Title: Is agile about development or management?

Body:
On a debate over what Scrum is all about, I found that perhaps I totally misunderstood the agile thing. It appears to me that Scrum (which is certainly considered an Agile process) is all about managing features and sprints and roles and stuff with nothing to do with TDD, pair programming, CI, refactoring and other developer centric techniques and practices that I though (until now) are the heart of agile. Now I am facing a difficulty !

1) Is Scrum agnostic to whether developers do agile practices?

2) Can you implement Scrum in a team that does not utilize automated tests? does not perform refactoring or does not adhere to the agile programming practices?


问:
What would you think of a job based on mostly doing the proof of concept?
I'm working as a developer in a small software company whose main job is interfacing between separate applications, like between a telephony system and an environment control system, between IP TVs and hospitality systems, etc...And it seems like I am the candidate for a new job title in the company, as the person who does the proof of concept of a new interfacing project and does some R&D for prototyping.

What do you think the pros and cons of such a job would be, considering mainly the individual progress/regress of a person as a software engineer? And what aspects would you consider essential in a person to put him/her in such a job position?

答: First I would ask myself this question: Does this company put out enough new products that there will be a steady stream of projects that require a proof of concept? If the answer is no then I would be worried about the stability of the position. If the answer is yes the I would suppose that the number one quality required for the job would be a person who is extremely fast at picking up new languages/technologies.</p>


问:
Why are exceptions considered better than explicit error testing?

Possible Duplicate:

  Defensive Programming vs Exception Handling?

  if/else statements or exceptions

I often come across heated blog posts where the author uses the argument: "exceptions vs explicit error checking" to advocate his/her preferred language over some other language. The general consensus seems to be that languages that make use of exceptions are inherently better / cleaner than languages which rely heavily on error checking through explicit function calls.

Is the use of exceptions considered better programming practice than explicit error checking, and if so, why?

答:
Advantages of exception throwing over error code returning:

The return value of a function can be used for what it was designed to do: return the result of the function call, not a code that represents success or one of many failures within the function. This creates cleaner, more elegant code; fewer output/reference parameters, assignments are made to things you actually care about and not to throwaway status codes, etc.

Exceptions are object-oriented, so exception types have reusable conceptual meaning. What does a return code of -2 mean? You have to look it up in the documentation (which had better be good or you're forced to trace code, and if you don't have source code you're really screwed). What does a NullPointerException mean? That you tried to call a method on a variable that doesn't reference an instance. In addition, exceptions encapsulate data, so they can tell you exactly how and where your program screwed up in easily human-readable means. A return code can only tell you the method screwed up.

By default, return codes are ignored; exceptions aren't. If you don't store and check the return code, your program merrily continues along, corrupting data, screwing up pointers and generally crumpling itself into garbage. If you don't catch an exception, it's thrown out to the OS which terminates your program. "Fail fast".

Exceptions are more easily standardized. Because exceptions create more self-documenting code, and because most of us don't write all our programs 100% from scratch, exception types covering a wide variety of general cases are already available. The cheapest solution is the one you already have, so these built-in exception types get used in situations similar to the ones they were originally created for. Now, an InvalidOperationException means you tried to do something inconsistent with the current state of an object (exactly what that was will be detailed in the error message), regardless of which function from which third-party library you were trying to call.

Contrast that with return codes; for one method, -1 might be a "null pointer error", while -2 might be an "invalid operation error". In the next method, the "invalid operation" condition was checked first and so that error got return code -1, while "null pointer" got -2. A number's a number, and you are free to create any standard for assigning numbers to errors, and so is everyone else, leading to a LOT of competing standards.

Exceptions allow you to be more optimistic. Instead of pessimistically checking everything that could go wrong with a statement before actually executing the statement, you can simply try executing the statement, and catch any exceptions that were generated by it. If you can resolve the cause of the error and try again, great, if not, fine; you probably couldn't have done anything about it had you known beforehand.

Exception-based error-handling thus creates more efficient code by assuming it will work until it doesn't. Guard statements that return early cost processor time; they should thus be used primarily when the benefits of checking up front outweigh the costs; if you can determine in a few clocks that the input will never produce a valid output, but it'll take several seconds for the main body of the function to come to the same conclusion, then by all means put in a guard clause. However, if there are a dozen things that could go wrong, none of which are particularly likely and most of which require expensive execution, the "happy path" of normal program execution will be several times faster if you simply try/catch.


答:
Scrum is a flavor of agile that follows a specific pattern to meet the goals of the agile development methodology. You can't follow Scrum and not be agile, but you can be agile and not follow Scrum.

Scrum has no bearing on the use of automated tests, agile tends to favor them but the are by no means required. Refactoring should be a goal in agile and Scrum, but its often ignored. having no intention to ever refactor isn't really agile.


答:
I second Awemo's answer; this sounds like the Strategy Pattern, where algorithms that do similar things given different inputs or expected outputs are encapsulated, and then the proper algorithm can be chosen at runtime given knowledge of the data being input.

One comment mentioned "Chain of Responsibility"; this is related but slightly different and may incorporate a Strategy pattern. Basically, one at a time, in a pre-determined or dynamic "most likely first" order, the set of inputs is given to one of the encapsulated "strategies". That strategy has the knowledge to "decide" for itself whether it can do anything with the inputs. If it can, it may partially or completely process the inputs, and signals to the parent "supervisor" whether it thinks any further processing is needed. If it can't, it simply flags that fact. The supervisor then finds the next most likely algorithm to handle processing or further processing, until something signals to the supervisor that the inputs have been completely processed.

Title: What Design Pattern is separating transform converters

Body:
For converting a Java object model into XML I am using the following design:

For different types of objects (e.g. primitive types, collections, null, etc.) I define each its own converter, which acts appropriate with respect to the given type. This way it can easily extended without adding code to a huge if-else-then construct.

The converters are chosen by a method which tests whether the object is convertable at all and by using a priority ordering. The priority ordering is important so let's say a List is not converted by the POJO converter, even though it is convertable as such it would be more appropriate to use the collection converter.

What design pattern is that?

I can only think of a similarity to the command pattern.


答:
1) NO!!!! Scrum is Agile, meaning agile dev practices (TDD, pair programming, CI, refactoring, etc.) are very important to all aspects of a Scrum project. It is going to be much harder to figure out your teams run rate, estimate work, set appropriate sprint size, etc. if you are not using these practices.

2) Yeah you can implement Scrum in a team that does not adhere to agile practices, but I feel it really limits the potential of the team. A big part of why Scrum/Agile are so successful are the performance and quality gains you get from Agile dev practices which are core to delivering front to back complete features every sprint.

If someone else in your group is trying to convince you that Agile dev practices are a waste of time I think you should spend some time to emphasize why these practices are always stressed with Scrum as well as Agile as a whole. They really do make a difference.


答:
Is Scrum agnostic to whether developers do agile practices?

Scrum is a set of guidelines that encourage a team to be agile.

Can you implement Scrum in a team that does not utilize automated
  tests? does not perform refactoring or does not adhere to the agile
  programming practices?

Very difficult, because by the end of every sprint you must have a working product. If you have to do a complete manual regression test to prove that it is working, this is likely to be unachievable.


问:
Spending a good fortune on a certificate holding Scrum Master or a Veteran XP coach?
There is a very prestigious company that delivers a well-sold software about financial systems.  It has more that 20 years of history, and is staffed with about 20 programmers and much larger number of managerial staff.
Dissatisfied customers have reported strange bugs and no one has a clue what is wrong, hard to read code, and customization is prohibitively expensive. In a word, the software is rotten.

The company decided to spend a fortune and found the Agile thing as the remedy but they are stuck about what it is they need most urgently. Is it about the process or the developers or both? The challenge breaks down to the following options:

They can hire a certificate holding Scrum Master to teach them
Scrum. When asked about the value of doing it, the SM responded: "I
will prepare them to embrace Agile and only then they can go Agile
and save the product".

They can as well hire a veteran XP coach. When posed with the
same question he responded : "The most urgent problem is with the
programmers and not the management, XP will save the product from
rot and only then Scrum will make sense"

Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) ... you get the idea.

Some say they would be far better trying to improve their programming first (hire option 2) and then go with the process. Many say quite the opposite. Any insights ?

答:
This is a biased answer as I believe in quality above all else.

I would say go with the XP coach hands down. It sounds like the team doesn't know how to refactor or really implement well organized code, the XP coach will help them start holding themselves to a higher standard on these points.

I'm inclined to think that scrum is great at organizing the productivity machine to have them start churning things out at a consistent velocity. However if they haven't learned to refactor and follow good coding practices and write readable maintainable code, then most of the sprints will be spent consistently churning out either buggy software or bug fixes for what they did last sprint. And that velocity will be very low due to the time it takes to work in such software as you described.

Some may say Scrum can solve these problems, and it's true, but here's how: Scrum will magnify the inefficiences in the process, that is, make them visible problems, not larger problems. When scrum makes these visible long enough management may be inclined to start pushing engineers out the door and looking for replacements that do not show the same issues.

This is not (always) the best solution. A bit of coaching on better implementation practices may resolve these issues where Scrum processes will just make them apparent.

That said, if they can spring for it, have them go for both, but I would definitely start down the XP hole first.


答:
Alistair Cockburn (one of the originators of the Agile movement) says this about Crystal Clear (one facet of his Agile methodology):

Crystal Clear can be described to a Level 3 listener in the following
  words:

“Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the
  users every one or two months, and otherwise leave them alone.”

That is a definition of agile, admittedly for experienced development staff who know what they're doing and can be trusted to get on and do it. So does that mean you have to use CI and TDD and Pair Programming and all the other fashionable things? Put simply... No.

Agile is not about following a set of processes, its about being effective. What that means to you depends on your team and how it works, what you find useful to you. If TDD doesn't help you produce working code, then stop listening to the lesser lights who shout about it on the web and do not use it! If Pair Programming really helps your team to focus and get stuff done, then ignore anyone who says its a waste of time and organise your team like a 3-legged race at school sports day.

I did agile many years ago, so many we didn't even realize we were doing agile - we delivered iterations of the product every month, and cycled round fixing bugs and adding new features regularly. We did absolutely zero unit tests as such things had not been invented, and the refactoring book had not been written. So yes, you absolutely can do agile without any of the so-called agile practices.

Alistair also says this of Kent Beck:

Asked about XP and the five levels of the Software Engineering
  Institute’s “Capability Maturity Model,” he replied with XP’s three
  levels of maturity:

Do everything as written.

After having done that, experiment with variations in the rules.

Eventually, don’t care if you are doing XP or not.

Eventually, don't care if you're doing XP or not... wise words that should remind you not to fall into this trap.


答:
Personally I would worry about hiring someone who spent their time doing proof of concept stuff because it sounds like they are trained to get stuff working in a very beta/high level way but maybe couldn't deal with the real fiddly bits of actual implementation.

That being said if the work was there it would be a wicked awesome job.

Title: What would you think of a job based on mostly doing the proof of concept?

Body:
I'm working as a developer in a small software company whose main job is interfacing between separate applications, like between a telephony system and an environment control system, between IP TVs and hospitality systems, etc...And it seems like I am the candidate for a new job title in the company, as the person who does the proof of concept of a new interfacing project and does some R&D for prototyping.

What do you think the pros and cons of such a job would be, considering mainly the individual progress/regress of a person as a software engineer? And what aspects would you consider essential in a person to put him/her in such a job position?


答:
I'm a firm believer in the idea of No Silver Bullet. The two people that you are describing - the Scrum master and the XP coach - appear (based on your description) to be pushing their favored methodology as the solution to your organization's problem.

No one idea is going to improve your time to delivery, quality, predictability, or any other aspect of your development environment significantly over night. Process improvement and quality programs take a long time (not weeks, probably not months, but years) to design, implement, and institutionalize.

There are a lot of tools out there to help improve an organization's ability to deliver software, each with their own advantages and disadvantages. The correct solution would be to bring in someone who is familiar with a number of methodologies, techniques, and tools to assess your current status and culture and develop a process that addresses key problems facing the business.

Right now, you're only considering someone advocating Scrum and someone else advocating XP. What about CMMI? Lean Software Development? Six Sigma? PSP/TSP? Crystal? RUP? Some other tailored process that takes advantage of a collection of traditional product/process quality techniques and modern software engineering methods?

Don't look toward these snake oil salesmen. I believe that both XP and Scrum offer good ideas, but they aren't right for everyone. I'd look elsewhere to people who understand that and can help you build what's right for you.

Title: Spending a good fortune on a certificate holding Scrum Master or a Veteran XP coach?

Body:
There is a very prestigious company that delivers a well-sold software about financial systems.  It has more that 20 years of history, and is staffed with about 20 programmers and much larger number of managerial staff.
Dissatisfied customers have reported strange bugs and no one has a clue what is wrong, hard to read code, and customization is prohibitively expensive. In a word, the software is rotten.

The company decided to spend a fortune and found the Agile thing as the remedy but they are stuck about what it is they need most urgently. Is it about the process or the developers or both? The challenge breaks down to the following options:

They can hire a certificate holding Scrum Master to teach them
Scrum. When asked about the value of doing it, the SM responded: "I
will prepare them to embrace Agile and only then they can go Agile
and save the product".

They can as well hire a veteran XP coach. When posed with the
same question he responded : "The most urgent problem is with the
programmers and not the management, XP will save the product from
rot and only then Scrum will make sense"

Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) ... you get the idea.

Some say they would be far better trying to improve their programming first (hire option 2) and then go with the process. Many say quite the opposite. Any insights ?


问:
How do I parse a header with two different version [ID3] avoiding code duplication?
I really hope you can give me some interesting viewpoints for my situation, because I am not satisfied with my current approach.

I am writing an MP3 parser, starting with an ID3v2 parser.

Right now I`m working on the extended header parsing, my issue is that the optional header is defined differently in version 2.3 and 2.4 of the tag.

The 2.3 version optional header is defined as follows:

```<code>struct ID3_3_EXTENDED_HEADER{
    DWORD dwExtHeaderSize;          //Extended header size (either 6 or 8 bytes , excluded)
    WORD  wExtFlags;                //Extended header flags
    DWORD dwSizeOfPadding;          //Size of padding (size of the tag excluding the frames and headers)
};
</code>```

While the 2.4 version is defined :

```<code>struct ID3_4_EXTENDED_HEADER{
    DWORD dwExtHeaderSize;          //Extended header size (synchsafe int)
    BYTE  bNumberOfFlagBytes;       //Number of flag bytes
    BYTE  bFlags;                   //Flags
};
</code>```

How could I parse the header while minimizing code duplication?

Using two different functions to parse each version sounds less great, using a single function with a different flow for each occasion is similar, any good practices for this kind of issues ? Any tips for avoiding code duplication?

Any help would be appreciated.

答:
You're worrying about code duplication for 2 headers of 3 fields?  In the time it took you to write this question, you could have coded both parsers.  Honestly, just get it done.

If I'm way off base here, please update your question to indicate why duplication at such a small scale is a concern for you.

If you really don't want two separate functions, then code a single one with an if check in there.

I could see writing a common routine to break out the flags within the Word | Byte.

It doesn't appear that the logic surrounding the header size field is significant enough to justify worrying about duplication, but if it were non-trivial then another common routine for validation could make sense.

I don't mean to be harsh but the "good practice" in this case is to get it done and to move on to the bigger design issues of your problem space.  I would call this concern a case of premature optimization.  Part of the reason why you're struggling to find the "right answer" is because the difference between "right" and "good enough" is pretty small.


问:
In Scrum, should you split up the backlog in a functional backlog and a technical backlog or not?
In our Scrum teams we use a backlog, which mostly contains functional topics, but also sometimes contains technical topics.  The advantage of having 1 backlog is that it becomes easy to choose the topics for the next sprint, but I have some questions:

First, to me it seems more logical to have a separate technical backlog, where developers themselves can add pure technical items, like: we could improve performance in this method, this class lacks some technical documentation, ...  By having one backlog, all developers always have to pass via the product owner to have their topics added to the backlog, which seems additional, unnecessary work for the product owner.

Second, if you have a product owner that only focuses on the pure-functional items, the pure-technical items (like missing technical documentation, code that erodes and should be refactored, classes that always give problems during debugging because they don't have a stable foundation and should be refactored, ...) always end up at the end of the list because "they don't serve the customer directly".  By having a separate technical backlog, and time reserved in every sprint for these pure technical items, we can improve the applications functionally, but also keep them healthy inside.

What is the best approach?  One backlog or two?

答:
I concur with all answers above.  In the heat of commercial reality, the PO will keep on prioritizing functional stories over technical ones. Often to the frustration of the team.
The team should refrain from technical stories without any user value (who cares about an optimisation, if speed is not an issue?) and learn to see certain other technical tasks as implied by the functional stories. The "definition of done" also plays a big role. The remaining functional stories go on the backlog for the PO to prioritize.

E.g. Technical documentation: Availability of technical documentation (where applicable) is a typical item that belongs in the D.O.D. And therefor, updating it is IMPLIED with every functional story.

E.g. Refactoring code: should be done when it benefits the product development. Not earlier (the team should not assume in what direction the product will evolve) and not later when it has already turned into technical debt. Having the design reviewed could also be part of the DoD.


答:
Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) ... you get the idea.

The problem isn't your developers. With a twenty year old product, your don't have developers. You have maintenance programmers. As much as I loathe maintenance programmers (the havoc they wreak on what was a beautifully architected system is a crime), they do have a place in this world. Most development programmers don't like that place. They would love to be cast into the development world. Give them the chance!

Your problem is almost certainly management, not your developers. Prima facie evidence: about 20 programmers and much larger number of managerial staff behind the company. What has happened to your product is that customer X asked for feature A, customer Y asked for feature B, customer Z asked for feature C. All ASAP, all at minimal cost, and all with zero concern for how feature A conflicts with feature C. Your maintenance programmers have become quite agile at wedging that garbage into the product. The result, after twenty years of such maintenance wedging, is a product that is 99.44% pure garbage.

You will not turn this around overnight. Someone who says you can is just peddling a different kind of garbage.

The first thing that needs to happen is that your management has to see that they are the ultimate problem. If this doesn't happen, let us know the name of the company so we can sell them short before you go bankrupt. If this does happen and you do have management buy-in, turn your maintenance programmers free. This will take a mindset change, and some will not be able to make it. Whether it's agile programming, extreme programming, or something else, most of them will jump at that chance. It's a once in a lifetime opportunity that will last at least a few years.

The important thing is not the approach you take but how you assure yourself that you have a perpetually high quality product. You need to maintain (improve!) that quality rather than let it degrade. Otherwise you will face exactly the same problems a few years down the line after the beautiful rewrite once again becomes 99.44% pure garbage.


问:
Does a mature agile team requires any management?
After a recent heated debate over Scrum, I realized my problem is that I think of management as a quite unnecessary and redundant activity in a fully agile team. I believe a mature Agile team does not require management or any non-technical decision making process whatsoever. To my (apparently erring) eyes it is more than obvious that the only one suitable and capable of managing a mature development team is their coach (who is the most technically competent colleague with proper communication skills). I can't imagine how a Scrum master can contribute to such a team.

I am having great difficulty realizing and understanding the value of such things in Scrum and the manager as someone who is not a veteran developer but is well skilled in planning the production cycles when a coach exists in the team. What does that even mean? How on earth can someone with no edge-skills of development manage a highly technical team? Perhaps management here means something else?

I see management as a total waste of time and a by-product of immaturity. In my understanding a mature team is fully self-managing. Apparently I'm mistaken since many great people say the contrary but I can't convince myself.

答:
You're making a number of mistakes here.

The first one is assuming that a Scrum Master is a manager. They're not. They're basically an administrator-cum-facilitator. They make sure things happen on the Scrum schedule, but they don't have to tell you how to, if you're a fully-mature Agile team. It mostly just happens.

But they don't monitor the quality of your work or sign your holidays off or anything like that. Nor do they manage the product or project; that's done by other people.

The bigger mistake you're making is assuming that you can go from the situation you've described in other questions ("Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) ... you get the idea.") to "fully-mature Agile team" overnight. That's simply not possible. Forget it. Don't even try.

If overnight results is what you want, look to more structured project-management approaches. And hire some managers.

If the business wants you to be Agile, it takes time, it takes culture change. And yes, at first, when you're in the Chaotic Stage of improvement, it's going to require management. Whether that be an individual or a group, someone's going to have to make some decisions.

You need a person or group to be responsible for taking a look at the bigger picture, explaining the current situation to both the developers and the business, and explaining the options you have for improvement, figuring out what the business needs and then guiding people through it.

It's going to be a long time before you can call yourselves a fully-mature Agile team and self-manage. Most teams never get there.


问:
What are the advantages of programming to under an OS as opposed to bare metal executive?
Assume you are presented with an embedded system application to program, in C, on a multi-core environment (think a Cavium or Tilera) and need to choose between two environments:

Code the application under Linux in SMP mode or code the application under a thin bare metal executive (something like a very minimal RTOS), perhaps with a single core running UP Linux that can serve control tasks.

For the purpose of this question, assume that both environment provide the same level of performance guarantees in any measurable aspects of run time performance, including number of meaningful action per second, jitter, latency, real time considerations - the works. (and yes, I realize this is by far not a trivial assumption at all, bare with me).

How would you justify going with a Linux SMP based solution rather then a bare metal thin executive solution?

The question may seems silly. It certainly seems obvious to me - but I have to convince someone that does not think the same. Could you help make a list of arguments in favor of choosing a real SMP aware OS (Linux) vs. a bare metal executive assuming performance guarantees are NOT an issue?

Many thanks

答:
Portability

Threading support

There will be fewer bugs if you reuse mature OS code than if you replace parts (e.g. device drivers) of the OS with your own code.

Much, much easier to get/make the C libraries.

Much easier to find answers to problems if you use a popular OS like Linux.

Having said that, if I was the guy that you were trying to convince I would not be impressed if you told me that you could get the exact same performance that you can get with bare-metal code.  That's nonsense.

You could, on the other hand, convince me that the differences would be small enough that it would not matter for the particular application, or even that the differences would matter but the advantages of the OS are significant enough that it would still be worth it.  Acknowledge that there will be differences, though.  If you don't, why should he trust your analysis?


问:
Unit testing and Test Driven Development questions
I'm working on an ASP.NET MVC website which performs relatively complex calculations as one of its functions.

This functionality was developed some time ago (before I started working on the  website) and defects have occurred whereby the calculations are not being calculated properly (basically these calculations are applied to each user which has certain flags on their record etc).

Note; these defects have only been observed by users thus far, and not yet investigated in code while debugging.

My questions are:

Because the existing unit tests all pass and therefore do not indicate that the defects that have been reported exist; does this suggest the original code that was implemented is incorrect? i.e either the requirements were incorrect and were coded accordingly or just not coded as they were supposed to be coded?

If I use the TDD approach, would I disgregard the existing unit tests as they don't show there are any problems with the calculations functionality - and I start by making some failing unit tests which test/prove there are these problems occuring, and then add code to make them pass?

Note; if it's simply a bug that is occurring that can be found while debugging the code, do the unit tests need to be updated since they are already passing?

答:
I do not believe that unit tests necessarily test requirements: 1) unit tests operate against very low level components (methods/classes/interfaces/et cetera) tested as stand-alone units; 2) requirements are supposed to be tested while the test engineer designs integration/system tests during the requirements design phase; 3) functionality, requirements and specifications are tested (again) once the system is in an operational state; and 4) using an iterative software development approach, many phases of the development lifecycle are revisited for tightening up requirements, design, and development -- processes that re-occur.

Why unit testing is not appropriate for testing requirements.  Unit testing will not necessarily uncover a requirement issue for a number of reasons. One, if a requirement was poorly communicated, chances are the requirement was incorporated into the software design, and subsequent development; as a result, if the unit testing follows suit, correctly following an incorrect requirement, the unit testing will come up with nothing.  Two, if the requirement was properly documented, and the development team misinterpreted the requirement, similar to item 1, the misintepretation will carry through to the unit testing.  Three, as far my experience goes, unit testing is done by the developer, and is part of the development lifecycle -- unit testing is low-level and will not likely represent a requirement, unless each complete requirement is represented by its own method, which is very, very unlikely.

Example.  Consider unit testing in terms of methods.  Unit testing largely verifies that given the pre-condtions, post-conditions hold after execution of the method under test.  The object of unit testing is to test/verify the methods, et cetera, of a software system, starting from the most atomic or primitive methods, progressing towards the most complex ones.  By testing each low-level method, you verify whether it works, a no brainer. At this stage, the developer does not need to re-test the low-level method again as a stand-alone unit.  While moving upward in complexity to higher-level methods, unit testing verifies these methods, demonstrating that the primitive methods, from which the higher-level ones are composed, work together.  As far as I know, this is pretty much where unit testing stops.

How requirements are tested. In a well planned project, the test engineer (an integrated / system tester), starts designing tests while the requirements are written.  Through this activity, requirements get verified, before system design, and long before a stitch of code is written.  Once the system becomes available in some useable form, requirements are verified via functional/integration/system testing.


答:
I see management as a total waste of time and a by-product of immaturity.

Wow.  You haven't worked with any good managers lately, have you?  (We've all worked with bad ones).

I have seen people occasionally make the mistake of assuming anything they don't fully understand is easy.

(Business folk are especially guilty of this - have you ever received poor quality specifications AND a deadline set in stone?)

In most businesses the development team exists as a part of a larger whole.  Managers exist as an interface between the team and the rest of the company.  A good manager will work that relationship in both directions, ensuring the team gets what they need (requirements, office space, new computers, recognition, bonuses, etc) as well as communicating the (ever changing) priorities that come out of the corner office.

The corner office exists for a lot of reasons, most of which aren't relevant to this post.

Remember that most managers are making the best decisions they can with the information available to them which may not be the same as the information available to you.

If you had a fully mature development team that was part of a fully mature company that had fully mature customers and nothing ever changed, you might possibly eliminate the need for most management.  The term for that is Utopia.

Good luck with that.

ps - read Don't call yourself a programmer - excellent advice, and explains better than I how the rest of the business world views us.

Title: Does a mature agile team requires any management?

Body:
After a recent heated debate over Scrum, I realized my problem is that I think of management as a quite unnecessary and redundant activity in a fully agile team. I believe a mature Agile team does not require management or any non-technical decision making process whatsoever. To my (apparently erring) eyes it is more than obvious that the only one suitable and capable of managing a mature development team is their coach (who is the most technically competent colleague with proper communication skills). I can't imagine how a Scrum master can contribute to such a team.

I am having great difficulty realizing and understanding the value of such things in Scrum and the manager as someone who is not a veteran developer but is well skilled in planning the production cycles when a coach exists in the team. What does that even mean? How on earth can someone with no edge-skills of development manage a highly technical team? Perhaps management here means something else?

I see management as a total waste of time and a by-product of immaturity. In my understanding a mature team is fully self-managing. Apparently I'm mistaken since many great people say the contrary but I can't convince myself.


答:
All of this should be read with a very large "I AM NOT A LAWYER" hat on.  The very fact that you've asked this question shows that you have sufficient doubt - you should either consult a legal professional or just take the easier (and cheaper) route and live with the GPL.

That aside...

You, as the author of code, own copyright to the code you author and can license it as you wish - this is the entire legal basis that allows the GPL to exist in the first place.

How does that apply to your example?  It depends on the modifications you make.  If you've made some modifications here and there to existing code then the current license should stand; this should apply no matter how extensive the modifications are.

If you have added entirely new code of your own, if that code lives in it's own modules, and if it can be reasonably shown to be standalone (or at worst capable of standalone functionality), then I believe (IANAL) that you actually do have choice of license for that code, and that code alone.

Existing work to support this would include incorporation of e.g. zlib code into GPL projects.  That's the level of "standalone" I'm talking about here; if you're utterly satisfied that you're watertight on this (and if you find yourself having to try prove it then you're probably not) then this should apply.

Even then, the GPL does require that the license you choose be GPL-compatible, so you can't just pick and choose and you definitely can't keep your own source closed.  The FSF site maintains a list of GPL-compatible licenses, so it's wise to restrict any choice to licenses from that list.

The wording of the question "Am I required to claim a copyright on my modifications to a GPL-covered program?" in the GPL FAQ supports this reading of the situation: this is an explicit acceptance from source that changes you make can be placed in the public domain.  See also "Can the US Government release improvements to a GPL-covered program?", and - quite explicitly - "If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module?".

Note that in all of these cases the entire program itself must be under the GPL, there is just allowance for individual parts of it to be under different licenses.  Note also that these are just FAQ answers explaining the intention of the GPL; if this were to be tested in court it would be the actual license text that was tested.

Finally, and it should be quite obvious, under no circumstances can you re-license existing GPL code; once again: it would have to be entirely new and entirely standalone.

That's a hell of a lot of "if"s for an answer, so the path of least resistance is most likely to just swallow your dislike of the GPL and use it.

Title: Switching licenses, or cross licensing existing GNU GPL v3 software

Body:
I'm in the process of making a fork of GNU coreutils with a range of modifications. I'd like to release the result as an open-source project, but I'm not so much of a fan of GNU GPL as a license.

Is it possible to change the license, or provide the software under both GNU GPL v3 and CC BY-NC-SA?


答:
In my understanding a mature team is fully self-managing.

Let's assume for a moment you're correct. I don't know one way or another, so let's not discuss it.

The issue comes that even a self-managing team ends up with someone with good social and political skills that can represent the team to other departments. Someone who keeps track of what everyone is doing, when they're taking vacation, etc. Someone who handles HR bullshit and budgeting. Someone who argues with the QA and PM groups so that the rest of the team doesn't have to. Someone who mediates the inevitable interpersonal squabbles between developers. Someone to schedule meetings and keep morale up.

This person is a manager.


问:
How can calculus and linear algebra be useful to a system programmer?
I found a website saying that calculus and linear algebra are necessary for System Programming.

System Programming, as far as I know, is about osdev, drivers, utilities and so on. I just can't figure out how calculus and linear algebra can be helpful on that. I know that calculus has several applications in science, but in this particular field of programming I just can't imagine how calculus can be so important.

The information was on this site:
http://www.wikihow.com/Become-a-Programmer

Edit: Some answers here are explaining about algorithm complexity and optimization. When I made this question I was trying to be more specific about the area of System's Programming. Algorithm complexity and optimization can be applied to any area of programming not just System's Programming. That may be why I wasn't able to came up with such thinking at the time of the question.

答:
As others have mentioned, any mathematics courses in university can sharpen your problem solving and deductive reasoning skills. These are important to almost anyone.

But sometimes knowing some linear algebra can be helpful, particularly for some pretty good business ideas.


问:
Accessing Repositories from Domain
Say we have a task logging system, when a task is logged, the user specifies a category and the task defaults to a status of 'Outstanding'. Assume in this instance that Category and Status have to be implemented as entities. Normally I would do this:

Application Layer:

```<code>public class TaskService
{
    //...

    public void Add(Guid categoryId, string description)
    {
        var category = _categoryRepository.GetById(categoryId);
        var status = _statusRepository.GetById(Constants.Status.OutstandingId);
        var task = Task.Create(category, status, description);
        _taskRepository.Save(task);
    }
}
</code>```

Entity:

```<code>public class Task
{
    //...

    public static void Create(Category category, Status status, string description)
    {
        return new Task
        {
            Category = category,
            Status = status,
            Description = descrtiption
        };
    }
}
</code>```

I do it like this because I am consistently told that entities should not access the repositories, but it would make much more sense to me if I did this:

Entity:

```<code>public class Task
{
    //...

    public static void Create(Category category, string description)
    {
        return new Task
        {
            Category = category,
            Status = _statusRepository.GetById(Constants.Status.OutstandingId),
            Description = descrtiption
        };
    }
}
</code>```

The status repository is dependecy injected anyway, so there is no real dependency, and this feels more to me thike it is the domain that is making thedecision that a task defaults to outstanding. The previous version feels like it is the application layeer making that decision. Any why are repository contracts often in the domain if this should not be a posibility?

Here is a more extreme example, here the domain decides urgency:

Entity:

```<code>public class Task
{
    //...

    public static void Create(Category category, string description)
    {
        var task = new Task
        {
            Category = category,
            Status = _statusRepository.GetById(Constants.Status.OutstandingId),
            Description = descrtiption
        };

        if(someCondition)
        {
            if(someValue > anotherValue)
            {
                task.Urgency = _urgencyRepository.GetById
                    (Constants.Urgency.UrgentId);
            }
            else
            {
                task.Urgency = _urgencyRepository.GetById
                    (Constants.Urgency.SemiUrgentId);
            }
        }
        else
        {
            task.Urgency = _urgencyRepository.GetById
                (Constants.Urgency.NotId);
        }

        return task;
    }
}
</code>```

There is no way you would want to pass in all possible versions of Urgency, and no way you would want to calculate this business logic in the application layer, so surely this would be the most appropriate way?

So is this a valid reason to access repositories from the domain?

EDIT: This could also be the case on non static methods:

```<code>public class Task
{
    //...

    public void Update(Category category, string description)
    {
        Category = category,
        Status = _statusRepository.GetById(Constants.Status.OutstandingId),
        Description = descrtiption

        if(someCondition)
        {
            if(someValue > anotherValue)
            {
                Urgency = _urgencyRepository.GetById
                    (Constants.Urgency.UrgentId);
            }
            else
            {
                Urgency = _urgencyRepository.GetById
                    (Constants.Urgency.SemiUrgentId);
            }
        }
        else
        {
            Urgency = _urgencyRepository.GetById
                (Constants.Urgency.NotId);
        }

        return task;
    }
}
</code>```

答:
This is one reason I don't use Enums or pure lookup tables within my domain. Urgency and Status are both States and there is logic associated with a state that belongs with the state directly (e.g. what states can I transition to given my current state). Also, by recording a state as a pure value you lose information like how long the task was in a given state. I represent statuses as a class hierarchy like so. (In C#)

```<code>public class Interval
{
  public Interval(DateTime start, DateTime? end)
  {
    Start=start;
    End=end;
  }

  //To be called by internal framework
  protected Interval()
  {
  }

  public void End(DateTime? when=null)
  {
    if(when==null)
      when=DateTime.Now;
    End=when;
  }

  public DateTime Start{get;protected set;}

  public DateTime? End{get; protected set;}
}

public class TaskStatus
{
  protected TaskStatus()
  {
  }
  public Long Id {get;protected set;}

  public string Name {get; protected set;}

  public string Description {get; protected set;}

  public Interval Duration {get; protected set;}

  public virtual TNewStatus TransitionTo<TNewStatus>()
    where TNewStatus:TaskStatus
  {
    throw new NotImplementedException();
  }
}

public class OutStandingTaskStatus:TaskStatus
{
  protected OutStandingTaskStatus()
  {
  }

  public OutStandingTaskStatus(bool initialize)
  {
    Name="Oustanding";
    Description="For tasks that need to be addressed";
    Duration=new Interval(DateTime.Now,null);
  }

  public override TNewStatus TransitionTo<TNewStatus>()
  {
    if(typeof(TNewStatus)==typeof(CompletedTaskStatus))
    {
      var transitionDate=DateTime.Now();
      Duration.End(transitionDate);
      return new CompletedTaskStatus(true);
    }
    return base.TransitionTo<TNewStatus>();
  }
}
</code>```

The implementation of CompletedTaskStatus would be pretty much the same.

There are several things to note here:

I make the default constructors protected. This is so the framework can call it when pulling an object from persistence (both EntityFramework Code-first and NHibernate use proxies that are derived from your domain objects to do their magic).

Many of the property setters are protected for the same reason. If I want to change the end date of an Interval, I have to call the Interval.End() function (this is part of Domain Driven Design, providing meaningful operations rather than Anemic Domain Objects.

I don't show it here but the Task would likewise hide the details of how it stores its current status. I usually have a protected list of HistoricalStates that I allow the public to query if they're interested. Otherwise I expose the current state as a getter that queries HistoricalStates.Single(state.Duration.End==null).

The TransitionTo function is significant because it can contain logic about which states are valid for transition. If you just have an enum, that logic has to lie elsewhere.

Hopefully, this helps you understand the DDD approach a little better.

Title: Accessing Repositories from Domain

Body:
This is one reason I don't use Enums or pure lookup tables within my domain. Urgency and Status are both States and there is logic associated with a state that belongs with the state directly (e.g. what states can I transition to given my current state). Also, by recording a state as a pure value you lose information like how long the task was in a given state. I represent statuses as a class hierarchy like so. (In C#)

public class Interval
{
  public Interval(DateTime start, DateTime? end)
  {
    Start=start;
    End=end;
  }

  //To be called by internal framework
  protected Interval()
  {
  }

  public void End(DateTime? when=null)
  {
    if(when==null)
      when=DateTime.Now;
    End=when;
  }

  public DateTime Start{get;protected set;}

  public DateTime? End{get; protected set;}
}

public class TaskStatus
{
  protected TaskStatus()
  {
  }
  public Long Id {get;protected set;}

  public string Name {get; protected set;}

  public string Description {get; protected set;}

  public Interval Duration {get; protected set;}

  public virtual TNewStatus TransitionTo<TNewStatus>()
    where TNewStatus:TaskStatus
  {
    throw new NotImplementedException();
  }
}

public class OutStandingTaskStatus:TaskStatus
{
  protected OutStandingTaskStatus()
  {
  }

  public OutStandingTaskStatus(bool initialize)
  {
    Name="Oustanding";
    Description="For tasks that need to be addressed";
    Duration=new Interval(DateTime.Now,null);
  }

  public override TNewStatus TransitionTo<TNewStatus>()
  {
    if(typeof(TNewStatus)==typeof(CompletedTaskStatus))
    {
      var transitionDate=DateTime.Now();
      Duration.End(transitionDate);
      return new CompletedTaskStatus(true);
    }
    return base.TransitionTo<TNewStatus>();
  }
}

The implementation of CompletedTaskStatus would be pretty much the same.

There are several things to note here:

I make the default constructors protected. This is so the framework can call it when pulling an object from persistence (both EntityFramework Code-first and NHibernate use proxies that are derived from your domain objects to do their magic).

Many of the property setters are protected for the same reason. If I want to change the end date of an Interval, I have to call the Interval.End() function (this is part of Domain Driven Design, providing meaningful operations rather than Anemic Domain Objects.

I don't show it here but the Task would likewise hide the details of how it stores its current status. I usually have a protected list of HistoricalStates that I allow the public to query if they're interested. Otherwise I expose the current state as a getter that queries HistoricalStates.Single(state.Duration.End==null).

The TransitionTo function is significant because it can contain logic about which states are valid for transition. If you just have an enum, that logic has to lie elsewhere.

Hopefully, this helps you understand the DDD approach a little better.


答: The job of a scrum master or a manager in general isn't to act as a dictatorial overlord. A manager's job is to make sure that his team is set up for success within the business. That includes hiring the right people, getting the right equipment, and keeping a strategic view of the product. A manager should be like a linesman, keeping the details and minutiae that aren't important to a teams success from interfering with their progress.</p>


答:
Part of the problem is that "Scrum Master" is quite possibly the least-accurately titled role in all of history. "Scrum Facilitator" would be slightly more accurate, but as someone else pointed out earlier, the SM job isn't to manage the team but to make problems go away so the (self-managing) team can get on with their jobs. Yes, the scrum master is also responsible for making sure that scrum happens: tasks get updated with remaining hours, stand-ups are held and add value, burn-downs are updated and velocity is tracked and so on, but that's still a coaching and facilitating role, not a managing role.

Another part of the problem is that the folks in the corner offices want to know the answers to questions like "when can I ship the software?" and "what features will it contain?" and they're used to being able to ask a "Project Manager" those questions and get answers supported with lots of impressive-looking Gantt charts and little or no mention of uncomfortable things like the cone of uncertainty.

Under Scrum, it's feasible to start with a rough-and-ready list of the "will", "might" and "won't" features for any given ship date, but there's definitely a role for someone - probably the scrum master - in keeping the corner office up to date with the inevitable changes in those lists over time. I'm tempted to think of that activity, along with processing the resulting feedback and managing new feature requests as "management", albeit management that's different from what many, many Project Managers might have done in the past.


问:
Tips on persuading boss that code review is a good thing
Let's say one works in a hypothetical company that has several developers that rarely worked together on projects and the Boss didn't believe that code reviews are worth the time and cost.

What are various arguments that could be presented in this scenario that will portray the benefit of code review?  Furthermore, what are the potential arguments against code review here and how can these be countered?

答:
How about running a demo (a one week "mickey mouse" type project) executed in parallel by two teams, one using code review, the other one not .

At the end of the week, assess the each team's quality of work, I am quite sure that the code reviewers will come off as better.


答:
This is opinionated, but based on personal experience.

I think the XP coach is more likely to provide value than the scrum master.  He is far more likely to create good programming than the scrum master is likely to create good management.

If that doesn't persuade you, use your common sense.  He says he will turn around your management and he calls himself a "scrum master".  Does that sound like B.S. to you?

If the "XP coach" called himself a "home run czar" then that wouldn't be confidence-inspiring either.

O.K., that was a joke, partly, (plus XP coach isn't a B.S.-free term itself) but there is a better chance for programmers to implement changes without management really being behind it than there is if management is behind it but the programmers don't know how to do it.

Also, once management has shelled out for the XP coach you can probably justify, you know, doing some of the stuff you were coached about.  So you get some of the benefit of the scrum master.  The converse would not be true  - the scrum master won't teach you how to do this agile programming stuff, even if your stand-up meetings make onlookers weep at their beauty.

Neither option will come close to being enough to solve the problem, but the XP coach is better if you must stick within the choices presented in the question.