答:
In the .NET world, it is common to use a markup-based language for GUI design (e.g. XAML in WPF), with "code-behind" to handle functionality.

If you use unobtrusive techniques, even common HTML/Javascript can follow a very similar pattern. Querying frameworks like jQuery are optimized to help you attach javascript handlers to markup elements based on specific selectors. Since you mention GWT, you may be interested in GwtQuery, which aims to bring targeted, optimized jQuery functionality to projects written in GWT.

Title: What options are there for splitting UI layout from code logic using a markup language?

Body:
What tools similar to GWT's UIBinder exist in other languages? By this I mean a system where you can define your UI layout in a markup language (preferably html+css) and attach the functionality to the layout using the code. I'm most interested in anything for python, but answers in other languages would interest me as well.

I'm interested because the benefits of having a non-programmer work directly on the layout without needing to touch the code and adjust a bunch of UI toolkit method calls is very productive.

I'm aware of Flex for flash, but is there anything else out there?

What search terms might I use to find such frameworks? I've looked around but I haven't found anything concrete.

Edit: I'm not only interested in web frameworks, but desktop applications as well.

Edit2: My question appears to be close to a duplicate of https://stackoverflow.com/questions/2962874/what-are-the-open-source-alternatives-to-wpf-xaml


问:
Is it a good idea to appoint one of the scrum team member or scrum master as Product Owner?
Lately we had a project, in which client was busy touring. As usual scrum team was formed, management decided to appoint our analyst as Product owner since Client won’t be able to participate actively. Analyst was the one who worked closely with client for requirement analysis and specification drafting.

Client doesn’t have the time to review first two releases. Everything went smoothly until, client saw third release; he wasn’t satisfied with some functionalities, and those was introduced by make shift Product Owner (our analyst).

We were told to wait till design team finished mock-up of all pages and client checked each one and approved to continue working. Scrum team is there, but no sprints – we finished work almost like classic waterfall method.

Is it a good idea to appoint scrum team member or master as product owner? Do we need to follow scrum in the absence of client/product owner participation?

答:
Thanks for your post.  I realize it's old, but I think you've raised a great case and here are my $.02:

Problem 1: appointing the analyst as PO in your case seriously short-circuits the scrum framework.  Why?  Because only the PO can make value judgements, ROI assessments, prioritization and decisive choices that flow from the business, not from technology, not even from familiarity with the product.  I'm sure your sr. analyst did a fantastic job mimicking the PO, but ultimately had to guess the wants, values, choices that would come from your PO. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/.  Unless your analyst was granted POA from the client (unlikely), they would not be in a position to accept or reject anything at sprint review.

Could this approach possibly work? Yes but there would need to be a total transfer of responsibilities while your client was out.  Your client's boss would need to agree to the surrogate, and that no reasonable decisions made would be reversed.  Sound likely? More likely that you'd get a temporary PO from your client's organization (which is certainly not without its downside!)  But if your sr. analyst worked with the temporary PO, any incorrect decisions would come from the business, thus keeping your team roles clean.

Problem 2: "client doesn't have time to review".  Big problem (and one that I ran into recently too).  PO must be present to accept the product.  No one else can 'sign the check'.  PO absence means dissatisfaction happens later, potentially more rework, and loss of trust.  More fundamentally I'm sensing the client is not actively engaged in your project: no time for the daily standup, no time to answer questions, etc.

Problem 3: "we were told to wait till design team finished mock-up".  And now are off scrum completely.  The folks doing the mock-up should be part of your cross-functional team.  I can't tell if this is caused by lack of management understanding of scrum or a shock reaction to your third release.

Question: Where was your scrum master in all of this?  The SM would ordinarily recognize the danger of the role conflict and PO lack of participation, both obstacles / dangers to be addressed.

ContentLicense: CC BY-SA 3.0


问:
Are "backwards" terminators for if and case unique to shell scripting?
In bash at least, if and case blocks are closed like this:

```<code>if some-expr
then
    echo "hello world"
fi

case $some-var in
[1-5])
    do-a-thing
    ;;
*)
    do-another-thing
esac
</code>```

as opposed to the more typical close of end or endif/endcase. As far as I know, this rather funny convention is unique to shell scripting and I have never seen such an odd block terminator anywhere else. Sometimes things like this have an origin in another language (like Ruby's elsif coming from Perl), or a strange justification. Does this feature of shell scripting have a story behind it? Is it found in other languages?

答:
No. You find these "reversed" language constructs in many languages:

{ and },

/* and */

(* and *)

:)


答:
According to Wikipedia, the sh program reused the syntax from ALGOL 68.

Stephen Bourne carried into this shell some aspects of the ALGOL 68C compiler that he had been working on at Cambridge University. Notably he reused portions of ALGOL 68's "if ~ then ~ elif ~ else ~ fi", "case ~ in ~ esac" and "for ~ while ~ do ~ od" (using done instead of od) clauses in the common Unix Bourne shell syntax.

Since Bash was the GNU replacement of sh, it reused the same syntax for backwards compatibility.

Title: Are "backwards" terminators for if and case unique to shell scripting?

Body:
In bash at least, if and case blocks are closed like this:

```<code>if some-expr
then
    echo "hello world"
fi

case $some-var in
[1-5])
    do-a-thing
    ;;
*)
    do-another-thing
esac
</code>```

as opposed to the more typical close of end or endif/endcase. As far as I know, this rather funny convention is unique to shell scripting and I have never seen such an odd block terminator anywhere else. Sometimes things like this have an origin in another language (like Ruby's elsif coming from Perl), or a strange justification. Does this feature of shell scripting have a story behind it? Is it found in other languages?


问:
Is there a phrase or word to describe an algorithim or program is complete in that given any value for its arguments there is a defined outcome?
Is there a phrase or word to describe an algorithm or program is complete in that given any value for its arguments there is a defined outcome? i.e. all the ramifications have been considered whatever the context?

A simple example would be the below function:

```<code>function returns string get_item_type(int type_no)
{
  if(type_no < 10)
    return "hockey stick"
  else if (type_no < 20)
    return "bulldozer"
  else
    return "unknown"
}
</code>```

(excuse the dismal pseudo code)

No matter what number is supplied all possibilities are catered for. My question is: is there a word to fill the blank here:

```<code>"get_item_type() is ______ complete"
</code>```

?

(The answer is  not Turing Complete - that is something quite different - but I annoyingly always think of something as "Turing Complete" when I am thinking of the above).

答:
In Your Case...

In your particular example, what we have is a pure surjective (partial) function.

(Don't be mislead by the "partial". See below.)

To answer your question, we need to consider these:

Algorithms and Functions

Algorithms are implemented using either:

a pure fuction (side-effects free), resulting in a deterministic algorithm (results are predictable and transposed to a mathematical function),

or an impure function, resulting in a non-deterministic algorithm.

Functions

Functions can also considered as being either:

a partial function (there's an output for all possible input),

a total function (perfect input-output pairing).

Function Types

Furthermore, consider the following types of functions from a mathematical perspective:

An Injective Function

A partial function where results are unique.

A Surjective Function

A partial function where results can overlap.

A Bijective Function

A Total Function, both injective and surjective, where there's an output for all possible inputs, and where all possible outputs are distinct and obtained by a unique input, thus being perfectly paired.


问:
I'm doing 90% maintenance and 10% development, is this normal?
I have just recently started my career as a web developer for a medium sized company. As soon as I started I got the task of expanding an existing application (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure).

So after I had successfully extended this application with the requested functionality, they gave me the task to fully maintain the application. This was of course not a problem, or so I thought. But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported.

From then on I have had three more projects just like the above, that I now also have to maintain. And I got four projects where I was allowed to create the application from scratch, and I have to maintain those as well.

At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. They expect me to handle these mails directly while also working on two other new projects (and there are already five more projects lined up after those). The sad thing is I have yet to receive a bug report on anything that I have coded myself. For that I have only received the occasional let's-do-things-180-degrees-different change requests.

Anyway, is this normal? In my opinion I'm doing the work equivalent of a whole team of developers.

Was I an idiot when I initially expected things to be different?

I guess this post has turned into a big rant, but please tell me that this is not the same for every developer.

P.S. My salary is almost equal if not lower than that of a cashier at a supermarket.

答:
The situation you are facing is nearly (if not totally) the same for many freshers.

This happens in the initial phases of a career. Here is the catch: We have to overcome this issue and prove our value to the company (be it medium-sized or MNC). We should be able to make decisions about what the circumstances demand us to do. So there is nothing harm in putting efforts in the job, provided you get noticed for it and stand as an individual for your work. If you are worth, the company will notice! Adios and best of luck.


问:
Is making my own copyright licence safe?
I've seen various open source libraries (actually I've seen it for assets as well) having a home-baked license in the following manner :

SomeGuy's License:
1. You can use this code freely in commercial projects and modify it as you wish, but not sell it
2.
  If you want to sell a modified version, drop me an email first, or give credits to me

Edit:

The above example is ambiguous, so I am giving another one, I want to know if 3 lines of license will hold some ground:

SomeGuy's License:
1. You can use this code in a commercial project as a 3rd party library
2.
  You can't sell it as a derivative work

I know that such license is not polished at all, for example the Creative Commons set of licenses seem to be short, but actually have some large legal stuff underneath it, but I wonder if at least some level of protection can be gained with a hobby license like that ?

My question is, could this hold any ground in the court, or would the corporative lawyers of the company X tear it apart ?

答:
Custom licences are huge pain in the a*** for no gain. Those who want to violate it will do so anyway, but those who try to play by the rules will have problems. Such problems exist and Linux distributions and big open-source projects have to deal with them daily, so don't make it worse.

For example your above licenses are incompatible with GPL. So the result would be that the bad guys would be shamelessly copying from your code anyway, but anybody wanting to use your code in GPL software couldn't. Is that what you wanted? It also does not allow Red Hat or Suse to put your library on the CDs they sell? Is that what you wanted?

I'd suggest you just go with either LGPL or GPL with libgcc-like linking exception. The difference being that LGPL requires your code to be linked dynamically to any different-licensed code, the libgcc link exception does not. They don't prohibit selling (that would prohibit selling distribution CDs), but instead requires that the licensee must be given (upon asking) complete source code and that they are allowed to further share that code. Which effectively prevents somebody selling the library itself.

And GPL and it's variants already held a lot of ground in court.


答:
During one of my internships I found I spent a lot of time doing bug fixes. You have to realize that as an entry level employee you aren't going to get the sexiest work, you're going to get the grunt work no one else wants. It's unfortunate, but it's how it is at every job.

Additionally, you have to realize that to a company, having code that works is more important than having code that is clean. From your company's perspective, you changing the existing structure is money wasted on redoing something that is already done and potentally introducing even more errors. Usually these types of companies aren't computer/software companies so no sufficiently high manager has the technical background to know that sometimes you need to do these major overhauls. That said, if your company is run by technically competent people and they understand the value of good code, you may get more leeway, although sometimes you need to choose your battles (the main purpose of a business is still to make money, after all).

That said, you are not unreasonable in wanting to be able to leave your mark on the software and wanting more meaningful work. It is also unfortunate that you have to deal with so many projects at once while fielding requests from so many different managers.

As a programmer, it is a fact of life that you will spend more time maintaining and modifying other people's code than you will writing your own from scratch. If this is a problem for you then perhaps you should stick to developing as a hobby and pursue a different career. If you are OK with maintaining code, but you feel you are not being used effectively or are being overwhelmed, then that is a matter you need to discuss with your manager. If your problems are more serious than that or if you feel like your managers don't know how to effectively manage your skill set then it would be a good idea to consider finding a position at a different company. Given your stated low salary, this is probably your best course of action.

Title: I'm doing 90% maintenance and 10% development, is this normal?

Body:
I have just recently started my career as a web developer for a medium sized company. As soon as I started I got the task of expanding an existing application (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure).

So after I had successfully extended this application with the requested functionality, they gave me the task to fully maintain the application. This was of course not a problem, or so I thought. But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported.

From then on I have had three more projects just like the above, that I now also have to maintain. And I got four projects where I was allowed to create the application from scratch, and I have to maintain those as well.

At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. They expect me to handle these mails directly while also working on two other new projects (and there are already five more projects lined up after those). The sad thing is I have yet to receive a bug report on anything that I have coded myself. For that I have only received the occasional let's-do-things-180-degrees-different change requests.

Anyway, is this normal? In my opinion I'm doing the work equivalent of a whole team of developers.

Was I an idiot when I initially expected things to be different?

I guess this post has turned into a big rant, but please tell me that this is not the same for every developer.

P.S. My salary is almost equal if not lower than that of a cashier at a supermarket.


答:
I was also in a similar situation, and I can tell you that if you stay on that track it never ends. Management will keep shoveling it at you, because... they can.

There are a few additional thoughts that I have on this topic.

Do what you love. If you don't love it, prepare yourself for making the attempt to find what it is that you might love.

Communication. Communicate clearly your inabilities to deliver to unrealistic expectations. In my similar experience the architect (who did the most shoveling) said, "you have to manage others expectations of you."

Burnout. If you have not experienced burnout, do not tempt fate. It sucks your life and soul out of your mind. Despite your best effort, your working purpose becomes grey, dreary and meaningless. I impart this advice because you must, at all costs, avoid burnout.

Training. Here is the silver lining. Your training and experience, while frustrating, and perhaps underpaid, is in fact, very valuable to your career. This is your saving grace to realize this because you can soak up as much learning as possible and delay any inevitable glass ceiling.

Focus on what talents and skills you are growing... These will carry you through the next opportunities of your career.


问:
How can I speed up the process of typing up specification during a meeting with developers?
I'm studying source code with other developers, and my job is to type up the specifications as the lead programmer  describes what each function does. Are there any tips/tricks to doing this faster? a lot of times I have to ask him to repeat himself, as I didn't hear it well.

How can I be a better specification  writer?

答: I personally find that writing specifications down on a notepad is the fastest way to go. Keep it at the keywords and only write down full sentences when required. It's also easy to make quick sketches of ideas / requirements on a notepad. And sometimes it might even be a good thing to record the meeting, so afterwards you can check if you really caputered all the specifications. </p>


答:
It sounds like management has a problem managing your workload and prioritizing tasks. You should talk to your manager and make them understand that you are overloaded and you can't do effective work if everyone keeps bombarding you with requests which they want fulfilled immediately.

That makes you jump from one task and project to another, wasting a lot of time switching gears in your mind. For effective software development work, one should be able to immerse oneself into a task and focus fully on it. The more interruptions one gets, the more time is wasted by context switching. Research shows that it takes about 15 minutes to immerse and get to the state of flow where our mind works the most efficiently. If you get interruptions every 15 minutes, you never get to flow, which is a tremendous waste for both you and the company.

So you should try to negotiate a more sensible working mode with your manager. This should include prioritizing the incoming requests and planning ahead to some extent. All user requests should be maintained in a list, ordered by priorities. And the priorities should not be decided by the requester (as naturally everyone thinks his/her request is the most important on earth), neither by you, but by someone with enough business knowledge and overview of the whole range of products you are maintaining (the product owner).

Ideally, all incoming requests should be entered into an issue tracker like JIRA or Mantis. Or at least mailed to the product owner, not you. And he/she should deal with all the complaints from the users too over "why is my request not ready yet?!", allowing you to focus on the development work. If this is unattainable, you should at least negotiate some windows of time when you look at incoming requests and deal with them, reserving an uninterruptible portion of your time solely for development.

If this is possible, the next step could be to plan ahead to some extent. That is, estimate the time needed to implement the top priority requests, then schedule your time into sprints, which may be one or more weeks each, and allocate enough tasks to the next sprint to cover your time.

You probably want to keep a portion of your time for incoming emergency requests, but the rest can be planned ahead. And you may also prefer to organize work on different projects into separate "streaks", that is, to work on project A on Monday, project B on Tueday-Wednesday, project C on Thursday morning and D on afternoon, etc., to further reduce context switching.

This way you have a rough idea of what you are to do in the next one or few weeks. Moreover, this gives a roadmap to your clients too: they can see when they get which request implemented. You may or may not want to mention the word "agile" to your manager here - this is basically agile development, but some people oppose agile without actually knowing what it is :-)

Note that even if your current position seems low valued by your company, the more projects you are maintaining, the more negotiating power you have.

Finding and training a new hire to maintain all these projects takes considerable time ( = money) for the company. And you may rightly point out that your code is so much better than the legacy parts of these applications, so it is not a given that they can easily find a candidate of similar capabilities for the same amount of money. Not to mention that if they don't improve working conditions, they will make the next guy get fed up and quit just as fast as you... Try to make them understand that it is in their own best interest to keep you, and to keep you happy where you are :-) This may give you some power to negotiate the above conditions, and/or request a pay raise.

How much negotiating power you have - that is a big question. Your management may or may not be open to these ideas, and may or may not respect you enough to take your pleas seriously. But if you play your cards well, you have a chance. And if they refuse... you can always look for a better workplace. This situation isn't the same for every starter, although (sadly) your experiences are fairly typical. But there really are better workplaces out there. The quality of workplace is only loosely correlated with geographical location, but my feeling is that in Northern Europe you have higher than average chances. So if you can't get your current conditions noticeably improved, you should start looking immediately, before you get completely fed up, and burnt out.

It is immensely better to look for a job while you still have one, so you need not accept the first offer just because you need money immediately. Eventually you will find a better place :-)


问:
Generalise variable usage inside code
I would like to know if it is a good practice to generalize variables (use single variable to store all the values).

Consider simple example

```<code> Strings querycre,queryins,queryup,querydel;
    querycre = 'Create table XYZ ...';
    execute querycre ;
    queryins = 'Insert into XYZ ...';
    execute queryins ;
    queryup  = 'Update  XYZ set ...';
    execute queryup;
    querydel = 'Delete from XYZ ...';
    execute querydel ;
</code>```

and

```<code> Strings query;
    query= 'Create table XYZ ... ';
    execute query ;
    query= 'Insert into XYZ ...';
    execute query ;
    query= 'Update  XYZ set ...';
    execute query ;
    query= 'Delete from XYZ ...';
    execute query ;
</code>```

In first case I use 4 strings each storing data to perform the actions mentioned in their suffixes.

In second case just 1 variable to store all kinds the data.

Having different variables makes it easier for someone else to read and understand it better. But having  too many of them makes it difficult to manage.

Also does having too many variables hamper my performance?

P.S: please don't answer w.r.t the code in example it was just to convey what I really mean.

答:
In Terms of Code Design

In general, it's alright to reuse variables to store different values - after all, that's why they are called variables, because the value stored in them varies - as long as the value is not only of the same type but also means the same thing. For example of course it's okay to reuse the currentQuery variable here:

```<code>for currentQuery in queries:
    execute query;
</code>```

Naturally there's a loop so you have to reuse a variable, but even if there wasn't a loop it would have been okay. If the value does not mean the same thing, use a separate variable.

Specifically, though, the code you are describing does not look very good - it repeats itself. It's much better to use a loop or helper method calls (or both). Personally I've very rarely seen production code that looks like either your 1st or 2nd versions, but in the cases I have, I think the 2nd version (variable reuse) was more common.

In Terms of Performance

It depends on the language, compiler(s) and runtime system(s) used, but in general there should not be any difference - in particular compilers for stack-based register machines (like the popular x86/x86-64) will anyway just use whatever free stack memory or register they can as the assignment target, completely ignoring whether you wanted the same variable or not.

For instance, gcc -O2 generates the exact same binary, and the only performance difference I know of is the size of the symbol table during compilation - completely negligible unless you go back in time to the 60s.

A Java compiler will generate bytecode which needs more storage for the 1st version, but the JVM's jitter will remove it anyway, so again, I suspect there would be practically no noticeable performance impact even if you need highly-optimized code.

Title: Generalise variable usage inside code

Body:
In Terms of Code Design

In general, it's alright to reuse variables to store different values - after all, that's why they are called variables, because the value stored in them varies - as long as the value is not only of the same type but also means the same thing. For example of course it's okay to reuse the currentQuery variable here:

for currentQuery in queries:
    execute query;

Naturally there's a loop so you have to reuse a variable, but even if there wasn't a loop it would have been okay. If the value does not mean the same thing, use a separate variable.

Specifically, though, the code you are describing does not look very good - it repeats itself. It's much better to use a loop or helper method calls (or both). Personally I've very rarely seen production code that looks like either your 1st or 2nd versions, but in the cases I have, I think the 2nd version (variable reuse) was more common.

In Terms of Performance

It depends on the language, compiler(s) and runtime system(s) used, but in general there should not be any difference - in particular compilers for stack-based register machines (like the popular x86/x86-64) will anyway just use whatever free stack memory or register they can as the assignment target, completely ignoring whether you wanted the same variable or not.

For instance, gcc -O2 generates the exact same binary, and the only performance difference I know of is the size of the symbol table during compilation - completely negligible unless you go back in time to the 60s.

A Java compiler will generate bytecode which needs more storage for the 1st version, but the JVM's jitter will remove it anyway, so again, I suspect there would be practically no noticeable performance impact even if you need highly-optimized code.


答:
Self-Documented Code is Easier to Read and Maintain

Follow the Principle of Least Atonishment and of the precept of code-as-documentation: use one variable for one goal, to both make its use easy to understand and the code easy to read without explanations.

Correctly Structured Code is Easier (thus Cheaper) to (Re)Use

Also, here it would appear that query is always used to prepare a statement before executing it. That's probably a sign that you want to refactor part of this code into one (or more) helper methods to prepare and execute the query (to comply to the DRY principle).

This way, you'll effectively:

use only one variable in your helper method to identify the query of the current context,

need to type less code everytime you want to re-execute a query,

render your code more readable for others.

Examples:

Consider this, taken from your example, where the refactored version is obviously better. Of course your snippet was just an example for the purpose of this question, but the concept still holds true and scales.

Your Example 1:

```<code>Strings querycre,queryins,queryup,querydel;
    querycre = 'Create table XYZ ...';
    execute querycre ;
    queryins = 'Insert into XYZ ...';
    execute queryins ;
    queryup  = 'Update  XYZ set ...';
    execute queryup;
    querydel = 'Delete from XYZ ...';
    execute querydel ;
</code>```

Your Example 2:

```<code> Strings query;
    query= 'Create table XYZ ...';
    execute query ;
    query= 'Insert into XYZ ...';
    execute query ;
    query= 'Update  XYZ set ...';
    execute query ;
    query= 'Delete from XYZ ...';
    execute query ;
</code>```

Example 3 (Refactored pseudo-code):

```<code>def executeQuery(query, parameters...)
    statement = prepareStatement(query, parameters);
    execute statement;
end

// call point:
executeQuery('Create table XYZ ... ');
executeQuery('Insert into XYZ ...');
executeQuery('Update  XYZ set ...');
executeQuery('Delete from XYZ ...');
</code>```

The benefit shows with regular reuse.

Personal Anecdote

I originally started as a C programmer working with limited screen real-estate, so re-using variables made sense both for the compiled code (back then) and to allow more code to be readable at once.

However, having then moved on to higher-level languages and brushed up on functional programming, I took the habit of using immutable variables and immutable references whereever possible to limit side-effects.

What's In It For Me?

If you take the habit of having all your function's inputs be immutable and to return a new result (as a true mathematical function would), you get into the habit of not duplicating stores.

By extension, this leads to:

you writing short functions,

with well-defined objectives,

that are easier to understand,

to re-use,

to extend (whether by OO inheritance or by functional chaining),

and document (as already self-documenting).

I'm not saying there's no benefit to mutable state here, I'm just pointing out how the habit might grow on you and how it impacts code readability.

Title: Generalise variable usage inside code

Body:
I would like to know if it is a good practice to generalize variables (use single variable to store all the values).

Consider simple example

```<code> Strings querycre,queryins,queryup,querydel;
    querycre = 'Create table XYZ ...';
    execute querycre ;
    queryins = 'Insert into XYZ ...';
    execute queryins ;
    queryup  = 'Update  XYZ set ...';
    execute queryup;
    querydel = 'Delete from XYZ ...';
    execute querydel ;
</code>```

and

```<code> Strings query;
    query= 'Create table XYZ ... ';
    execute query ;
    query= 'Insert into XYZ ...';
    execute query ;
    query= 'Update  XYZ set ...';
    execute query ;
    query= 'Delete from XYZ ...';
    execute query ;
</code>```

In first case I use 4 strings each storing data to perform the actions mentioned in their suffixes.

In second case just 1 variable to store all kinds the data.

Having different variables makes it easier for someone else to read and understand it better. But having  too many of them makes it difficult to manage.

Also does having too many variables hamper my performance?

P.S: please don't answer w.r.t the code in example it was just to convey what I really mean.

Body:
Self-Documented Code is Easier to Read and Maintain

Follow the Principle of Least Atonishment and of the precept of code-as-documentation: use one variable for one goal, to both make its use easy to understand and the code easy to read without explanations.

Correctly Structured Code is Easier (thus Cheaper) to (Re)Use

Also, here it would appear that query is always used to prepare a statement before executing it. That's probably a sign that you want to refactor part of this code into one (or more) helper methods to prepare and execute the query (to comply to the DRY principle).

This way, you'll effectively:

use only one variable in your helper method to identify the query of the current context,

need to type less code everytime you want to re-execute a query,

render your code more readable for others.

Examples:

Consider this, taken from your example, where the refactored version is obviously better. Of course your snippet was just an example for the purpose of this question, but the concept still holds true and scales.

Your Example 1:

Strings querycre,queryins,queryup,querydel;
    querycre = 'Create table XYZ ...';
    execute querycre ;
    queryins = 'Insert into XYZ ...';
    execute queryins ;
    queryup  = 'Update  XYZ set ...';
    execute queryup;
    querydel = 'Delete from XYZ ...';
    execute querydel ;

Your Example 2:

 Strings query;
    query= 'Create table XYZ ...';
    execute query ;
    query= 'Insert into XYZ ...';
    execute query ;
    query= 'Update  XYZ set ...';
    execute query ;
    query= 'Delete from XYZ ...';
    execute query ;

Example 3 (Refactored pseudo-code):

def executeQuery(query, parameters...)
    statement = prepareStatement(query, parameters);
    execute statement;
end

// call point:
executeQuery('Create table XYZ ... ');
executeQuery('Insert into XYZ ...');
executeQuery('Update  XYZ set ...');
executeQuery('Delete from XYZ ...');

The benefit shows with regular reuse.

Personal Anecdote

I originally started as a C programmer working with limited screen real-estate, so re-using variables made sense both for the compiled code (back then) and to allow more code to be readable at once.

However, having then moved on to higher-level languages and brushed up on functional programming, I took the habit of using immutable variables and immutable references whereever possible to limit side-effects.

What's In It For Me?

If you take the habit of having all your function's inputs be immutable and to return a new result (as a true mathematical function would), you get into the habit of not duplicating stores.

By extension, this leads to:

you writing short functions,

with well-defined objectives,

that are easier to understand,

to re-use,

to extend (whether by OO inheritance or by functional chaining),

and document (as already self-documenting).

I'm not saying there's no benefit to mutable state here, I'm just pointing out how the habit might grow on you and how it impacts code readability.


问:
How to convince management that I can lead a team?
I am a developer working with small organization from last two years.
I have completed some successful projects and organization believe on my technical skill.

Now I get nominated for Team leader position, So how can convince them that I can lead a team ?

What skills I have to show besides technical stuff ?

Any help will be appreciated.

答:
You need people skills, including communication, empathy, time management, delegation etc. Technical skills are actually not necessary to lead developers, although of course it doesn't hurt if you have them. But your technical skills alone won't make you a good team lead. And most likely you won't have the time to keep them up to date, so expect them to slowly but surely get rusty, which means you will need to rely more and more on the expertise of your team members.

IMHO probably one of your greatest challenges (at least initially) will be delegation of tasks. So far you have managed to solve problems yourself, based on your tech skills. Now you will need to learn to delegate tasks to others, and trust that they will do a good job. Some of them may not be as capable as you (think you are :-), still often it is better to delegate to them, rather than trying to do everything yourself. You are now responsible for the work of the whole team, not just a specific tasks, so you must balance to have enough time for the whole team.

As a team lead, you probably need to plan ahead a lot more than you used to as a developer. And on various levels too, for a whole team, not just your own activities.

And last but not least: you most likely need to communicate a lot more than before, with a lot of other people (managers of various sorts, clients, ...) who are not developers. You need to learn to communicate with them effectively, i.e. using a language they can understand. That includes talking business speak to managers who don't understand technical jargon, i.e. focusing on the value a specific feature brings to users, and the costs, rather than the technical details of implementing it.

An absolutely recommended reading for this is Peopleware: Productive Projects and Teams (Second Edition).


答:
Team leader is first and foremost a role, not a position.

You shouldn't be worrying about convincing the management in the first place, you should be leading the team, which in turn demonstrates that you can do that. You can be the leader regardless of your formal title. If you do lead the team, then you may eventually get a new title to your business card :-)

Title: How to convince management that I can lead a team?

Body:
I am a developer working with small organization from last two years.
I have completed some successful projects and organization believe on my technical skill.

Now I get nominated for Team leader position, So how can convince them that I can lead a team ?

What skills I have to show besides technical stuff ?

Any help will be appreciated.


答:
Leading a team could have different meanings. You may want to start listing the responsibilities of such a role and demonstrate to yourself first, then to management why you think you can do a good job at it.

For example responsibilities may include:

Plan one or more projects.

Provide estimates for task and project durations.

Ability to identify risk and work with the team to mitigate risks.

Can do multiple things in the day (Time management).

Ability to get to the real cause of an issue (not necessarily technical stuff).

Knowledge of how to judge deliverable and general quality standards.

Knowledge of how to prioritize deliverable for yourself and for the team.

Add to the above the set of personal skills required to for "People Skills" that @Péter Török, mentioned above.

With all these things, you can put together a good discussion with management and you could give a strong statement about why you can do well.

Personally, I think that not all technical people are cut for management role. You need to believe in the role and you need to dedicate significant time of your day doing things that does not add value to your programming skills. Make sure you want to do this!


问:
What is the meaning of the sentence "we wanted it to be compiled so it’s not burning CPU doing the wrong stuff."
I was reading this article. It has the following paragraph.

And did Scala turn out to be fast? Well, what’s your definition of fast? About as fast as Java. It doesn’t have to be as fast as C or Assembly. Python is not significantly faster than Ruby. We wanted to do more with fewer machines, taking better advantage of concurrency; we wanted it to be compiled so it’s not burning CPU doing the wrong stuff.

I am looking for the meaning of the last sentence. How will interpreted language make the CPU do "wrong" stuff ?

答:
"Wrong stuff" here means the overhead it takes for the interpreter to parse and process the code. It's connected with the notion of interpreted vs compiled languages. There are several models of code translation in use, which roughly fall into one of following categories:

Native compilation - source code is directly compiled into machine code. Best performance at the expense of portability. Commonly associated with C and C++,

Intermediate compilation - source code is compiled into a simplified intermediary language (bytecode), which is later interpreted or compiled (just-in-time compilation) into machine code during execution. Better portability than native code, better performance than pure interpretation while retaining some of the upsides of interpretation (like late binding). Examples include C#, Java and other languages targeting JVM and .NET CLR,

Interpretation - source code isn't directly translated into machine code, instead it's interpreted and executed by a dedicated interpreter program. Interpreters vary in sophistication, in the naive implementation however it boils down to parsing, analyzing and executing source code line by line. Interpretation allows greater flexibility than compilation, hence interpreted languages make wider use of dynamic typing or reflection, for instance. Interpreted languages are often seen as offering increased developer productivity, as they require less boilerplate code and lent themselves nicely to rapid prototyping. Downside is reduced performance. Commonly associated with JavaScript, Ruby or Python.

Hence the choice between interpreted and compiled language boils down to the question, what do we value more, developer productivity or performance? The migration described in the article seems to follow the same line of thought, with strong prototyping language Ruby being replaced by JVM-based Scala due to performance considerations.


问:
Killer semi-unique programming language features
When learning a new programming language you sometimes come across a language feature which
makes you wish you had it in your other programming languages that you know.

What are some language feature which were at the time of learning very new to you and that you wish your other programming languages had.

An example of this is generators in Python or C#.
Other examples may include list comprehensions in Python, template in C++ or LINQ in .NET or lazy evaluation in Haskell.

What other semi-unique language features have you come across which were completely new and enlightening to you?  Are there other features of older programming languages which were unique and have fallen out of fashion?

答: String mixins plus compile time function evaluation in D is a pretty unique killer feature.  Yes, technically it's two features, but the real power comes from combining them.  With this combination, you can write regular D functions that generate code as a string at compile time, and then mix this code into any scope and have it be evaluated as regular D code.  The code is fully statically compiled and executes exactly as if it had been handwritten.  This feature is even used to work around a couple sticky situations in the standard library.</p>

ContentLicense: CC BY-SA 2.5


答:
we wanted it to be compiled so it’s not burning CPU doing the wrong stuff.

Sounds like they are referring to compiled vs interpreted. Most likely down to the whole story of Twitter moving background processing tasks to Scala (compiled) after initially developing in Ruby On Rails (interpreted).

An explanation of compiled vs interpreted code here.

With a compiled language, code you enter is reduced to a set of machine-specific instructions before being saved as an executable file. With interpreted languages, the code is saved in the same format that you entered. Compiled programs generally run faster than interpreted ones because interpreted programs must be reduced to machine instructions at runtime.

Title: What is the meaning of the sentence "we wanted it to be compiled so it’s not burning CPU doing the wrong stuff."

Body:
I was reading this article. It has the following paragraph.

And did Scala turn out to be fast? Well, what’s your definition of fast? About as fast as Java. It doesn’t have to be as fast as C or Assembly. Python is not significantly faster than Ruby. We wanted to do more with fewer machines, taking better advantage of concurrency; we wanted it to be compiled so it’s not burning CPU doing the wrong stuff.

I am looking for the meaning of the last sentence. How will interpreted language make the CPU do "wrong" stuff ?


答:
In addition to other people's comments:

Yes, it is normal for an entry level employee to be given the jobs nobody else wants to do.

You should see this as a building block for your future career.

So what should you do? In order to prove youself as a professional developer you need to ensure your work is structured and planned, otherwise you may find it hard to build on the good things you're currently doing - so you should try to do things like the following (if you're not already).

Log your work accurately, for each project. So if you spend one hour fixing a bug on project A, log this time. This will be useful to show to your manager if you want to discuss workloads.

Write unit tests. You mention some of the projects you maintain are full of bugs, so my guess is that there are few (if any) unit tests. For each bug report, write a unit test which replicates the bug, then fix the bug. This will help ensure no regressions occur, improve the quality of the code, and serve as a platform on which to refactor the code if you're given the chance (for example, it could help you convince the stakeholders that rewriting some parts could improve quality without introducing new bugs, due to the unit test suite).

Look for a new job - you work on many projects at once, you have written code from scratch, and you have probably experienced the entire project lifecycle - these are all good experiences for applying elsewhere.


问:
Is it ok to replace optimized code with readable code?
Sometimes you run into a situation where you have to extend/improve some existing code. You see that the old code is very lean, but it's also difficult to extend, and takes time to read.

Is it a good idea to replace it with modern code?

Some time ago I liked the lean approach, but now, it seems to me that it's better to sacrifice a lot of optimizations in favor of higher abstractions, better interfaces and more readable, extendable code.

The compilers seem to be getting better as well, so things like struct abc = {} are silently turned into memsets, shared_ptrs are pretty much producing the same code as raw pointer twiddling, templates are working super good because they produce super lean code, and so on.

But still, sometimes you see stack based arrays and old C functions with some obscure logic, and usually they are not on the critical path.

Is it a good idea to change such code if you have to touch a small piece of it either way?

答:
The main question here is: is the optimisation required?

If it is then you cannot replace it with slower, more readable code.  You will need to add comments etc to it to make it more readable.

If the code does not have to be optimised then it should not be (to the point of affecting readability) and you can re-factor it to make it more readable.

HOWEVER - make sure you know exactly what the code does and how to throughly test it before you start changing things.  This includes peak usage etc.  If do not not have to compose a set of test cases and run them before and after then you do not have time to do the refactoring.


答:
If the code says

```<code>A = A + 1
</code>```

compiled code does this

```<code>add A, 1
</code>```

interpreted code does this (or some variation)

```<code>look up the location of A in the symbol table
find the value of A
see that 1 is a constant
get its value
add the value of A and the value of 1
look up the location of A in the symbol table
store the new value of A
</code>```

get the idea?

Body:
If the code says

A = A + 1

compiled code does this

add A, 1

interpreted code does this (or some variation)

look up the location of A in the symbol table
find the value of A
see that 1 is a constant
get its value
add the value of A and the value of 1
look up the location of A in the symbol table
store the new value of A

get the idea?


答:
I will never replace Optimized code with Readable code because I can't compromise with performance and I will opt to use proper commenting at each and every section so that anyone can understand logic implemented in that Optimized section which will resolve both the problems.

Hence, Code will be Optimized + Proper Commenting will make it Readable too.

NOTE: You can make an Optimized Code readable with the help of proper commenting but you can not make Readable Code an Optimized one.

Title: Is it ok to replace optimized code with readable code?

Body:
Sometimes you run into a situation where you have to extend/improve some existing code. You see that the old code is very lean, but it's also difficult to extend, and takes time to read.

Is it a good idea to replace it with modern code?

Some time ago I liked the lean approach, but now, it seems to me that it's better to sacrifice a lot of optimizations in favor of higher abstractions, better interfaces and more readable, extendable code.

The compilers seem to be getting better as well, so things like struct abc = {} are silently turned into memsets, shared_ptrs are pretty much producing the same code as raw pointer twiddling, templates are working super good because they produce super lean code, and so on.

But still, sometimes you see stack based arrays and old C functions with some obscure logic, and usually they are not on the critical path.

Is it a good idea to change such code if you have to touch a small piece of it either way?


答:
This is the way I do things: First I make it work in readable code, then I optimize it. I keep the original source and document my optimization steps.

Then when I need to add a feature I go back to my readable code, add the feature and follow the optimization steps I documented. Because you documented it's really fast and easy to reoptimize your code with the new feature.


问:
Useful versioning scheme for a git project?
I have a small github project, which I need to add an option to to output some version number on the commandline.

The problem is I have no idea how to "compute" the version number. Is this some random process? Should I just start at 1.0 (probably creating a tag or something), and put a number after . for fixes?

I know this question is a bit vague... I just had never to deal with this, and want to use some sane versioning scheme.

EDIT

Im also interested into how to update this version number automatically, maybe using something like a git hook.

答: Have a look at Semantic Versioning. What constitutes a major, minor and patch version increment depends on your project, but the site is a good starting point. You might also want to include the first few digits of the git commit ID in the version, so you can find it later.</p>


答:
In this case I have taken the wrong stuff to mean lack of type safety in non-compiled code.

Thus, not only is interpreted code slower, but it's also more buggy...


问:
I can't program because the code I am using uses old coding styles. Is this normal to programmers?
I have my first real job as programmer, but I can't solve any problems because of the coding style used. The code here:

Does not have comments

Does not have functions (50, 100, 200, 300 or more lines executed in sequence)

Uses a lot of if statements with a lot of paths

Has variables that make no sense (eg.: cf_cfop, CF_Natop, lnom, r_procod)

Uses an old language (Visual FoxPro 8 from 2002), but there are new releases from 2007.

I feel like I have gone back to 1970. Is it normal for a programmer familiar with OOP, clean-code, design patterns, etc. to have trouble with coding in this old-fashion way?

EDIT: All the answers are very good. For my (un)hope, appears that there are a lot of this kind of code base around the world. A point mentioned to all answers is refactor the code. Yeah, I really like to do it. In my personal project, I always do this, but... I can't refactor the code. Programmers are only allowed to change the files in the task that they are designed for.

Every change in old code must be keep commented in the code (even with Subversion as version control), plus meta information (date, programmer, task) related to that change (this became a mess, there is code with 3 used lines and 50 old lines commented). I'm thinking that is not only a code problem, but a management of software development problem.

答:
Ok, I'll be blunt. That is a bad place to work... I've been in such situations, and usually it ends with you being swallowed by this code. After a year or so, you'll get used to it, and you'll loose the grip on how modern alternatives can be used to achieve the same task easier, in a more maintainable way, and also, faster at run-time in most cases.

I left a workplace like that, because, after just a month, I felt I'm being dragged into an old skool code. I tried to give it a go, but decided not to. I couldn't use clean code and started to loose skills because of missing everyday practice. Any modern approach had to be approved by 3 layers of developers, which never happened, because the idea was that things might break when modern approaches are used. And fragile nature of the code that comes out when you don't use modern approaches is quite scary.

Don't get me wrong, there are cases where people over-engineer solutions, and I'm all against it. But being dragged into '80 coding conventions and style for extensive amount of time will stop your progress, and also, I think, career opportunities.

Then again, you have to earn money, so sometimes you have to do what you don't exactly like. Keep an eye on burnout symptoms and turning coding into a mundane task in those cases though.


答:
Try talking with your employers and see if you can solve this out. It sounds like you're way over your head on this, and it has nothing to do with being a bad programmer.

Smaller web companies tend to have a lot of projects going on at the same time, which in many ways leaves you in a though spot. Either try to make the best of your situation, or try to find a new job if you think you can. I promise there are better coding jobs out there, so don't let this first one scare you off.

Good luck, and I hope both you and your co-workers understand the gravity or your efforts!

Personal experience

Like many here I also recognize your situation. I basically got my first coding job with a low salary and had to maintain a lot of built code with a poor structure. At first I found it funny to learn new stuff, but when I in the end had lots of projects to maintain, new projects to make and a white board which grew bigger and bigger every day with points I wasn't done with I realized that it wasn't working.

After putting up with it for two years, I quit and found another coding job a couple of months later which fits me perfectly.

Anyway, many times it's not only your projects that might be the issue. I find myself more comfortable on a workplace when I get acknowledged and respected for my work. The problem with the situation that you're in is that your employers might only notice the bugs which arise from created projects, and not the time you take to remove all the other bugs.

Salary

If you want more money, you can often get it. I managed to negotiate my salary in under two years to a raise of 33%.

Basically, think about the value of your work and how much the company needs you. If they can't afford to give you the salary you've earned, then the company either needs to looks at their expenses or realize that their business isn't working.

And as mentioned by many here, and I agree, you're a very valueable piece of the company puzzle. Hell, you're probably the only one that can solve that puzzle. :)


问:
Why isn't Java used for modern web application development?
As a professional Java programmer, I've been trying to understand - why the hate toward Java for modern web applications?

I've noticed a trend that out of modern day web startups, a relatively small percentage of them appears to be using Java (compared to Java's overall popularity).  When I've asked a few about this, I've typically received a response like, "I hate Java with a passion."  But no one really seems to be able to give a definitive answer.

I've also heard this same web startup community refer negatively to Java developers - more or less implying that they are slow, not creative, old.

As a result, I've spent time working to pick up Ruby/Rails, basically to find out what I'm missing.  But I can't help thinking to myself, "I could do this much faster if I were using Java," primarily due to my relative experience levels.

But also because I haven't seen anything critical "missing" from Java, preventing me from building the same application.

Which brings me to my question(s):

Why is Java not being used in modern web applications?

Is it a weakness of the language?

Is it an unfair stereotype of Java because it's been around so long (it's been unfairly associated with its older technologies, and doesn't receive recognition for its "modern" capabilities)?

Is the negative stereotype of Java developers too strong? (Java is just no longer "cool")

Are applications written in other languages really faster to build, easier to maintain, and do they perform better?

Is Java only used by big companies who are too slow to adapt to a new language?

答:
I'm using a lot of Java, for creating web applications. So, when it comes to the *language itsel*f, I find only one (but big) issue - lack of multiline support. This makes printing/templating in pure Java code very unreadable.

But the real problem is the lack of good web frameworks. I've worked with a lot of solutions, and none of them I could name good or even satisfying.

Most of them are in fact XML programming. In JSF you produce tons of XML, and if you want to change some general feature, like rearange labels to the top of the text fields, you'll end up in doing the same change in multiple places. Yes, you have includes, but compare them with the includes from PHP...

Additionally, new JSF includes "extra" features which were known to the JavaScript frameworks years before...

ZK is a bit better because it allows creating the web elements in the Java code, which makes the modifications easier (if you use OOP properly - inheritation etc.). However, this Java code is executed on the server side, which is a great performance issue - every click will cause a package to be sent to the server.

Well, GWT is the best web framework I've worked with. It allows object programming in the web design. Every element on the screen is represented by the Java object, which gives you full flexibility but... The compilation time is very long, and the generated Javascript is far from optimal, simply because GWT isn't utilizing fully the JavaScript possibilities (no support for the reflection, at least in the version I was using, and fatal implementation of HashMap).

You can use templates, such as Velocity, but as above, they are a poor-man's version of the templating possibilities given by such languages as PHP.

So, it's not a hate towards Java, but the lack of support for writing web apps that one will get when using PHP, Python etc...


问:
Good practice or service for monitoring unhandled application errors for a small organization
I'm working with multiple software with varying ways of monitoring for errors. When I make software, I usually send email with the stack trace to admins(usually me). Some customer software is monitored by a team who check that a particular batch run was successfull. Other software might not have any monitoring at all(someone will call when things go wrong horribly).

Sending emails is good, except when things start going wrong, my mail gets filled fast. Also I don't want to solve the same problem in code for every software. Is there some relatively cheap and low maintenance software or practice to handle this. I want it to be cheap/low maintenance because usually I work alone or in teams of 5 or smaller. For example it would be great if errors would be aggregated so I don't get 10 000 emails when something unexpected happens...

For clarification: By unhandled errors I mean Exceptions that were unhandled by application code that were propagated to Tomcat or Jboss. I don't need help with how to catch those errors. I need help with what to do with them.

Is there any cloud application that I could send my errors to? Or some simple server to install? Or some library that can handle errors using configuration files. I use Java if that is any help.

答: I've only built my own aggregating service for this type of problem in the past.  Basically only passing on a notification every x occurrences in y timeframe.  Perhaps you can implement a similar simple solution for the apps that you deliver.</p>


答:
For knowledge-intensive, fast paced conversations, use whatever recording / capturing devices you can.

In one of my past projects, our professional tech writer used audio recording to capture explanations from our lead developer. Guides he produced were great.

Few months ago I brainstormed design of a particularly tricky module with my tech lead. After we finished, I just scanned all the papers we wrote our thoughts and schemes on and attached it to the respective ticket in issue tracker. That worked like a charm.

Another tip - submit your draft specifications for review as early as possible.

That tech writer I mentioned above, had a pretty bad habit to hesitate sending for review stuff until it looked good enough to him. Because of that, guides reviews somehow tend to happen pretty close to release when it was too late to fix some bugs discovered in review. If memory serves, we even had to do "doc-only" releases to handle this. Release 2.1.12 - same as 2.1.11, but with updated guides. :)

Title: How can I speed up the process of typing up specification during a meeting with developers?

Body:
I'm studying source code with other developers, and my job is to type up the specifications as the lead programmer  describes what each function does. Are there any tips/tricks to doing this faster? a lot of times I have to ask him to repeat himself, as I didn't hear it well.

How can I be a better specification  writer?


问:
Getting non-programmers to understand the development process
When starting a project for a company that's not primarily a programming company, one of the expectations is that there's a finished product at the end free of all bugs and does everything needed right away. However, that's rarely the case.

What are some ways to manage expectations and explain to non-programmers how software development differs from other types of product development?

答:
Explanation by metaphor is a leaky abstraction, but here are some ideas that often work for me:

Note that none of these explanations excuse sloppy work.

Think of a computer program as machine, where every variable is a moving part. That makes even a trivial program a machine composed of hundreds of moving parts.

When that fails, I fall back on the fact that while it is mathematically possible to prove that a program has no errors, it takes huge amounts of time and won't be worth the effort.

Finally, I ask if Intel and Microsoft are unable to avoid bugs, how do they expect us to?


答:
Have you tried slf4j + logback logging to a central syslog server with Logback's SyslogAppender?

From there you can use the syslog tools to analyze the messages and send an email to you if necessary.

Title: Good practice or service for monitoring unhandled application errors for a small organization

Body:
I'm working with multiple software with varying ways of monitoring for errors. When I make software, I usually send email with the stack trace to admins(usually me). Some customer software is monitored by a team who check that a particular batch run was successfull. Other software might not have any monitoring at all(someone will call when things go wrong horribly).

Sending emails is good, except when things start going wrong, my mail gets filled fast. Also I don't want to solve the same problem in code for every software. Is there some relatively cheap and low maintenance software or practice to handle this. I want it to be cheap/low maintenance because usually I work alone or in teams of 5 or smaller. For example it would be great if errors would be aggregated so I don't get 10 000 emails when something unexpected happens...

For clarification: By unhandled errors I mean Exceptions that were unhandled by application code that were propagated to Tomcat or Jboss. I don't need help with how to catch those errors. I need help with what to do with them.

Is there any cloud application that I could send my errors to? Or some simple server to install? Or some library that can handle errors using configuration files. I use Java if that is any help.


答:
This one is all about money. My guess is that as a starter, you are probably too kind for customers who've already gotten more than they paid for.

Learn to quote a price for new requests.  This is far from easy and customers will often try you out.  If you can, enlist the help of an experienced project/product manager.

Once you think in terms of money, communicating with management becomes a lot easier.  If your current customers provide full time money, you should not pick up new projects.  But you'll understand that management will still try to bully you into doing them.

If you are indeed valuable to the company, you'll gain bargaining power.  You can ask them to hire more people, get fewer new projects, help you reduce maintenance load, or increase your salary.


答:
Your problem sounds like sommething you hear more often about. It appears to be a job that could easily fit on The Daily WTF.

A lot of organisations focus more on sales or feature pushing than on quality. What those companies fail to see is that there is more than external qualities of a piece of software. Ward Cunningham coined the term technical debt.

You might also want to read Steve McConnell on technical debt. He has some interesting points. In a Google Tech Talk, Ken Swaber talks about agile software development. A good part is about a story similar to yours. He talks about a software project that has become "braindead" after 10 years of programming by various programmers without ever doing any refactoring. I think that if you see this video you'll see a lot of similarities to what you describe.

Any software system will degrade in quality when it is being expanded on. In fact in order to survice it will have to. The Lehman Laws explain this principle quite well. Ultimately it will boil down to the following question: "How do I convince your boss to do refactoring?".

How I approached a similar problem:

I confronted my boss and explained that code quality degrades when we keep developing (Lehman Laws).

I tried to explain my boss the concept of technical debt. And that the way he lets you to work is a way that will cost him money in the long run.

In order to actually show him how severe the problem was, I have (in my own time) done a static code analysis. Bosses don't understand software, but they understand numbers. Although code metrics have their flaws it is good to have something measurable you can talk about. Try to find out what normal readings are for these metrics, and you will be surprised when you compare this to your own codebase.

If nothing helps and nothing changes, the only thing you can do is explain that a certain new feature will require some rework of other parts of your codebase. Explain that if you have duplicate code and they want to change something that the costs of a change duplicate as well.

A common answer to the previous point will be that no-one has asked and thus not paid for this rework. That "perhaps" this rework is superfluous. You will have to explain that software will always have to change. Like the Lehman Laws say; it will have to change in order to remain in use. If not, other programs who did change will always outlive. It is those who expect change and can adapt to change that will survive. This is what agile software development is all about. (Wikipedia)

My boss nowadays uses the concept of technical debt to explain to our customers that we sometimes need to rework parts of the software we build. Just to prove that - if you have a reasonable boss, it is possible to change things for the better.


答: You could use your iPhone or iPad to record the session. A pencil and paper will not require batteries. Try to remove technology from the equation if possible unless you can use it unobtrusively.</p>


问:
How to manage a developer who has poor communication skills
I manage a small team of developers on an application which is in the mid-point of its lifecycle, within a big firm. This unfortunately means there is commonly a 30/70 split of Programming tasks to "other technical work". This work includes:

Working with DBA / Unix / Network / Loadbalancer teams on various tasks

Placing and managing orders for hardware or infrastructure in different regions

Running tests that have not yet been migrated to CI

Analysis

Support / Investigation

Its fair to say that the Developers would all prefer to be coding, rather than doing these more mundane tasks, so I try to hand out the fun programming jobs evenly amongst the team.

Most of the team was hired because, though they may not have the elite programming skills to write their own compiler / game engine / high-frequency trading system etc., they are good communicators who "can get stuff done", work with other teams, and somewhat navigate the complex bureaucracy here. They are good developers, but they are also good all-round technical staff.

However, one member of the team probably has above-average coding skills, but below-average communication skills. Traditionally, the previous Development Manager tended to give him the Programming tasks and not the more mundane tasks listed above. However, I don't feel that this is fair to the rest of the team, who have shown an aptitude for developing a well-rounded skillset that is commonly required in a big-business IT department.

What should I do in this situation? If I continue to give him more programming work, I know that it will be done faster (and conversely, I would expect him to complete the other work slower). But it goes against my principles, and promotes the idea that you can carve out a "comfortable niche" for yourself simply by being bad at the tasks you don't like.

I want to clarify that I'm not trying to address this issue due to a grudge, or that I have a "chip on my shoulder" as was mentioned. I'm looking for advice on how to keep a well-rounded team, which is happy and motivated. By observing the variety of answers to this question, it seems like there are a lot of different opinions on how to achieve this.

答:
Best answer has already been accepted, but I'm surprised nobody pointed out that "task assignment" isn't the only thing the manager can work with.  Having an "above avg programmer" who also has "above avg communication skills" should (all other things being equal) be a higher paid/more senior developer than someone with similar programming skills and weak communication skills.  This may help offset any perceived "favoritism" from the team.  (In some orgs, having above avg skills in "Requirements Analysis" and below avg skills in other areas may be worth much more to the company due to the type of work being done.  As a manager, you need to decide how to handle this.)

One other thing to watch out for: giving the person in question nothing but programming tasks will lead to isolation long term.  Be sure to keep giving them some of the other tasks (but ones they can do well, don't set them up for negative feedback!!) so they are both visible to and have visibility with the other departments/teams.

Finally... check in with the other team members if they see any inequality in the team assignments periodically.  This may be a big concern to you, but #15 on everyone else's list.


答:
This is true, but not because of Java and its ecosystem. It's because of people that, when using Java tend to create big messes and heavy abominations.

There are enough frameworks (spring-mvc, grails, play, etc.) that allow you to build things fast. The fact that people overengineer their systems is a problem that comes with the increased knowledge people get when they work with the Java ecosystem - you know many more thing, and you have them available (there are tools for everything), and "everything looks like a nail".

If you are "hacky", you can do pretty much the same with Java as with other languages, and here's a study indicating that:

Study of 49 programmers: static type system had no effect on development time... http://www.cs.washington.edu/education/courses/cse590n/10au/hanenberg-oopsla2010.pdf

Title: Why isn't Java used for modern web application development?

Body:
As a professional Java programmer, I've been trying to understand - why the hate toward Java for modern web applications?

I've noticed a trend that out of modern day web startups, a relatively small percentage of them appears to be using Java (compared to Java's overall popularity).  When I've asked a few about this, I've typically received a response like, "I hate Java with a passion."  But no one really seems to be able to give a definitive answer.

I've also heard this same web startup community refer negatively to Java developers - more or less implying that they are slow, not creative, old.

As a result, I've spent time working to pick up Ruby/Rails, basically to find out what I'm missing.  But I can't help thinking to myself, "I could do this much faster if I were using Java," primarily due to my relative experience levels.

But also because I haven't seen anything critical "missing" from Java, preventing me from building the same application.

Which brings me to my question(s):

Why is Java not being used in modern web applications?

Is it a weakness of the language?

Is it an unfair stereotype of Java because it's been around so long (it's been unfairly associated with its older technologies, and doesn't receive recognition for its "modern" capabilities)?

Is the negative stereotype of Java developers too strong? (Java is just no longer "cool")

Are applications written in other languages really faster to build, easier to maintain, and do they perform better?

Is Java only used by big companies who are too slow to adapt to a new language?


问:
the decisive difference between LGPL and AGPL
What is the decisive difference between LGPL(v3) and AGPL(v3) ?

Both can be used in commercial production, both can also be packed within a payed product. As long as I do not change the source code of these, I am not forced to enclose the source code with my product.

So where lies the eminent difference?

(Asked this also at https://stackoverflow.com/questions/10996160/the-decisive-difference-between-lgpl-and-agpl, but a user suggested to ask it here.)

答:
roughly, as long as you application isn't just a wrapper around the library:

LGPL: you can link against and don't have to release source code as long as you don't modify the library itself

GPL: you have to release source code if you link against and distribute the binary, but don't if you just provide a service

AGPL: you have to allow the source to be downloaded even if you never distribute the binary but do provide a service

i.e. your understanding of the LGPL is probably correct but your understanding of the AGPL is very wrong

as always if you want proper advice for your use-case you need to hire a lawyer


答:
P.S. My salary is almost equal if not lower then that of a cashier at a supermarket.

Heh I wanted to write something about how to negotiate until I read that. Now all I can say is leave! Assuming that's half of what a developer with a degree usually earns. And assuming that things improve and they give you immediately a 10% increase you can figure out yourself how long it takes to get there. It also looks like you do not learn anything on the job and you don't seem to be surrounded by brilliant engineers there, so it's a waste of time.


答:
Seven years ago I was doing pretty much 100% maintenance work for a while and wrote an article about it: The Art of Maintenance Programming. One part you may find useful:

Get to Like It

How can anyone like maintenance programming? Developers dream of being chief architects in their teams, and when they end up maintaining existing software, it feels almost like punishment. It doesn’t have to be: maintenance programming has its own set of challenges, and requires a lot of creativity, adaptability, patience, discipline, and good communication. It can be good for your career as well: having bombastic entries like “Architected n-tier 24/7 enterprise application” in your resume looks nice, but employers actually value people who solve problems; and maintenance programming can be a good chance to demonstrate your problem-solving skills.


问:
Should a server "be lenient" in what it accepts and "discard faulty input silently"?
I was under the impression that by now everyone agrees this maxim was a mistake. But I recently saw this answer which has a "be lenient" comment upvoted 137 times (as of today).

In my opinion, the leniency in what browsers accept was the direct cause of the utter mess that HTML and some other web standards were a few years ago, and have only recently begun to properly crystallize out of that mess. The way I see it, being lenient in what you accept will lead to this.

The second part of the maxim is "discard faulty input silently, without returning an error message unless this is required by the specification", and this feels borderline offensive. Any programmer who has banged their head on the wall when something fails silently will know what I mean.

So, am I completely wrong about this? Should my program be lenient in what it accepts and swallow errors silently? Or am I mis-interpreting what this is supposed to mean?

The original question said "program", and I take everyone's point about that. It can make sense for programs to be lenient. What I really meant, however, is APIs: interfaces exposed to other programs, rather than people. HTTP is an example. The protocol is an interface that only other programs use. People never directly provide the dates that go into headers like "If-Modified-Since".

So, the question is: should the server implementing a standard be lenient and allow dates in several other formats, in addition to the one that's actually required by the standard? I believe the "be lenient" is supposed to apply to this situation, rather than human interfaces.

If the server is lenient, it might seem like an overall improvement, but I think in practice it only leads to client implementations that end up relying on the leniency and thus failing to work with another server that's lenient in slightly different ways.

So, should a server exposing some API be lenient or is that a very bad idea?

Now onto lenient handling of user input. Consider YouTrack (a bug tracking software). It uses a language for text entry that is reminiscent of Markdown. Except that it's "lenient". For example, writing

```<code>- foo
- bar
- baz
</code>```

is not a documented way of creating a bulleted list, and yet it worked. Consequently, it ended up being used a lot throughout our internal bugtracker. Next version comes out, and this lenient feature starts working slightly differently, breaking a bunch of lists that (mis)used this (non)feature. The documented way to create bulleted lists still works, of course.

So, should my software be lenient in what user inputs it accepts?

答:
Of course you are completely right. Programs should never be “lenient” as doing so only serves to mask problems. Problems should be highlighted, not swept under the rug. An informative error message is an absolute must for a program to be helpful to the user.

Most of the time when incorrect/invalid data is provided, the provider of that data (whether it’s a user or the output of some other program) probably didn’t know it was invalid. Swallowing the error will keep them in the belief that it is (or might be) valid, which proliferates invalid data.

The only way for systems to interoperate is for that interoperation to be fully and unambiguously defined. A program that accepts data outside the specification makes that data de facto accepted even if it is invalid by the spec, which not only makes compatibility a huge load harder, but also means it is no longer formally defined. The program itself is now the de facto standard. Thus, lenient programs are impossible to develop further or to replace because you can’t make the minutest change to how it operates.

OwnerDisplayName: romkyns


答:
I think that it all depends on who your target demographic is. If it's programmers, then absolutely not. Your program should fail hard and scream bloody murder. However, if your target audience isn't programmers, then your program should be lenient where it can handle exceptions gracefully, otherwise, whisper sweet bloody murder.

As a case study, take the NPAPI Flash player. There is a "release" version for those who don't really care about 99% of errors that can occur, but there's also a "debug" version that can be used that screams bloody murder when anything goes wrong. Each support playing Flash content obviously, but are targetted to two completely different demographics.

In the end, I think that the important thing is: What do your users care about?

Title: Should a server "be lenient" in what it accepts and "discard faulty input silently"?

Body:
I was under the impression that by now everyone agrees this maxim was a mistake. But I recently saw this answer which has a "be lenient" comment upvoted 137 times (as of today).

In my opinion, the leniency in what browsers accept was the direct cause of the utter mess that HTML and some other web standards were a few years ago, and have only recently begun to properly crystallize out of that mess. The way I see it, being lenient in what you accept will lead to this.

The second part of the maxim is "discard faulty input silently, without returning an error message unless this is required by the specification", and this feels borderline offensive. Any programmer who has banged their head on the wall when something fails silently will know what I mean.

So, am I completely wrong about this? Should my program be lenient in what it accepts and swallow errors silently? Or am I mis-interpreting what this is supposed to mean?

The original question said "program", and I take everyone's point about that. It can make sense for programs to be lenient. What I really meant, however, is APIs: interfaces exposed to other programs, rather than people. HTTP is an example. The protocol is an interface that only other programs use. People never directly provide the dates that go into headers like "If-Modified-Since".

So, the question is: should the server implementing a standard be lenient and allow dates in several other formats, in addition to the one that's actually required by the standard? I believe the "be lenient" is supposed to apply to this situation, rather than human interfaces.

If the server is lenient, it might seem like an overall improvement, but I think in practice it only leads to client implementations that end up relying on the leniency and thus failing to work with another server that's lenient in slightly different ways.

So, should a server exposing some API be lenient or is that a very bad idea?

Now onto lenient handling of user input. Consider YouTrack (a bug tracking software). It uses a language for text entry that is reminiscent of Markdown. Except that it's "lenient". For example, writing

```<code>- foo
- bar
- baz
</code>```

is not a documented way of creating a bulleted list, and yet it worked. Consequently, it ended up being used a lot throughout our internal bugtracker. Next version comes out, and this lenient feature starts working slightly differently, breaking a bunch of lists that (mis)used this (non)feature. The documented way to create bulleted lists still works, of course.

So, should my software be lenient in what user inputs it accepts?


问:
Pattern for Accessing MySQL connection
We have an application which is C++ trying to access MySQL database.

There are several (about 5 or so) threads in the application (with Boost library for threading) and in each thread has a few objects, each of which is trying to access Database for its' own purpose. It has a simple ORM kind of model but that really is not an important factor here.

There are three potential access patterns i can think of:

There could be single connection object per application or thread and is shared between all (or group). The object needs to be thread safe and there will be contentions but MySQL will not be fired with too many connections.

Every object could initiate connection on its own. The database needs to take care of concurrency (which i think MySQL can) and the design could be much simpler. There could be two possibilities here.
a. either object keeps a persistent connection for its life OR
b. object initiate connection as and when needed.

To simplify the contention as in case of 1 and not to create too many sockets as in case of 2, we can have group/set based connections. So there could be there could be more than one connection (say N), each of this connection could be shared connection across M objects.

Naturally, each of the pattern has different resource cost and would work under different constraints and objectives.

What criteria should i use to choose the pattern of this for my own application?

What are some of the advantages and disadvantages of each of these pattern over the other?

Are there any other pattern which is better?

PS: I have been through these questions:

mysql, one connection vs multiple
and

MySQL with mutiple threads and processes

But they don't quite answer exactly what i am trying to ask.

答: I would never try and share database connections across threads. Split it up and just have 1 connection per thread.</p>

Title: Pattern for Accessing MySQL connection


问:
Advantages of Scrum for the developers themselves?
Scrum being a project management methodology, how would you 'sell' it to the developers in a team that is reasonably happy with its current situation?

It seems easy to me to explain to our Product Manager how Scrum will allow him to get regular releases, to amend requirements, and get the team to focus on the high-priority stories first.  I found it easy to explain what TDD or Continuous Integration bring in a developer's day-to-day life.

But how can developers be convinced to embrace Scrum?  How would Scrum make their life easier?

答:
There are several things that I as a developer like about scrum.

The developers tend to be given more information upfront. The product owner needs to explain all the work that is going to be done during the next sprint in sufficient detail to allow for good estimates.

Just in time estimating means that that estimates are reasonably accurate. Everyone usually has a reasonably good idea of what will be finished in a sprint. This gives programmers and project managers the tools to push back against unreasonable demands.

It is nice to step back every three to four weeks and take a breath and at least have a change of pace.

Self organizing teams, seem to give a bit more variety in the work.

In theory at least, during the sprint there are fewer interruptions and 'emergencies'.

The daily stand up meeting forces programmers to say several words every day.

It is easier to see the progress being made as stories are explicitly finished and reviewed at the end of each sprint.

The burn down charts are a pretty effective light weight means of tracking progress.


问:
I'm doing 90% maintenance and 10% development, is this normal?
I have just recently started my career as a web developer for a medium sized company. As soon as I started I got the task of expanding an existing application (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure).

So after I had successfully extended this application with the requested functionality, they gave me the task to fully maintain the application. This was of course not a problem, or so I thought. But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported.

From then on I have had three more projects just like the above, that I now also have to maintain. And I got four projects where I was allowed to create the application from scratch, and I have to maintain those as well.

At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. They expect me to handle these mails directly while also working on two other new projects (and there are already five more projects lined up after those). The sad thing is I have yet to receive a bug report on anything that I have coded myself. For that I have only received the occasional let's-do-things-180-degrees-different change requests.

Anyway, is this normal? In my opinion I'm doing the work equivalent of a whole team of developers.

Was I an idiot when I initially expected things to be different?

I guess this post has turned into a big rant, but please tell me that this is not the same for every developer.

P.S. My salary is almost equal if not lower than that of a cashier at a supermarket.

答:
Your situation is a bit edgy, yet still normal. But the way you handle it is very bad. Here is what you need to do:

Try to confront your boss. You should have some proof (numbers) of how much time the bad code base actually costs. If he does not understand stuff like technical debt, stop mentioning it. It would wreck your head, and you could be marked as a 'bad attitude' guy. It is not your job to teach your boss to do his work.

Maintain your own backlog (kanban). When new tasks comes put it at end, and tell estimated time of completion.

Increase your response time, check your email only twice day. Typically before lunch and just before you leave. (Checking email should not be followed by coding, as it may wreck your head).

Make small code improvement as part of each task. It is simply your job to improve code, skills and tools you are using. It will also boost your moral in the long term.

No project switching during the day. Today you are simply working on project X, and you will start other task for Y tomorrow.

Allocate one hour per day for gate keeping. It means small tasks which are trivial to do. If this task takes longer than 10 minutes (no mater what the reason is), it goes into the backlog and you notify the manager it will be delayed.

Now comes the hard part. Currently managers do not communicate with each other, and just assume you will finish their own project with maximal priority. This brings a lot of stress on your head, because you are in middle of arguments. You need to force managers to start coordinating your work. At the end you should have a nice & simple backlog and managers should bully each other without you.

So let's do some simple role playing. There are three managers and projects (Xavier with project X, Yvonne with project Y and Zed with project Z). You have a backlog for two weeks, 5 days for X and 5 days for Y.

Z asks you to do some task (1 day)

You respond that it will be done in 11 days.

Z responds that it is simple task and should not take more then one day (notice that Z applies small pressure).

You respond that you are currently working for X and latter for Z. You can do her work after that.

Z responds you should do his task immediately anyway (increased pressure, direct violation of X and Y territory).

You respond that doing her task would delay work for X and Y. He should ask them first. You also CC X and Y.

Now there are two ends:

Managers will start barking at each other, many emails, probably some meetings... You should stay away and let the winner assign you a task.

Nothing will happen, Z will ask you two days latter where his task is. You answer that you are working for X currently, and he did not mention anything about project Z. Again CC X.

Now this type of behaviour can get you fired. But your situation is unsustainable, and you will probably quit soon anyway. This solution only works if managers are competing against each other (very usual). You should also keep records of your work (backlog), in case somebody would complain, that you are slacking off.


答:
In my opinion, a company that prohibits refactoring is not worth working for.  Refactoring is an essential software development skill, and version control tools make it very easy to develop changes in isolation without corrupting the 'trunk' (in case a refactor actually does break something). As Uncle Bob says (paraphrased): "You should haven't to ask to be a professional and do your job right."

Maintenance programming should never mean perpetuating bad code.


答:
It seems to me that Postel's Law -- "Be conservative in what you do, be liberal in what you accept from others" is what is being discussed for a JSON service. This is usually applied to web services and not UI.

For UI constructive user feedback and contraining user input is the rule of thumb we use.


答:
Since I can't comment yet because I'm a lurker on this Stack Exchange site, I will just add to the information on here.

Since you are just starting out, your salary isn't going to be stellar unless you went to work for a big company like Microsoft, Amazon or something akin. But it shouldn't be that of a grocery employee! Don't put up with that for long, gain experience doing what you are doing and move on when a better opportunity arises.

For an entry level gig this is kind of normal. Your workload is too high, but the type of work is expected. To become a better developer you must learn from others' mistakes. The more you see, the better you become. But that implies you are looking for things to learn from, not learning bad habits...

The ratio of maintenance to project work should shift over time. If it isn't, that means the company you work for doesn't realize how to keep a good developer; they intend to have you do the same thing day in and day out. Make a yearly goal for yourself as to where you would like to be, salary and job expectations wise, and move accordingly.

4) If you aren't happy, leave! Life is too short to deal with stupid people.

All the best.


答:
The statement is about sending information over the internet.
One of the things with sending information over the internet is that not always will it get to the target at all or fragmented.</p>


问:
Should I tell a departed coworker about their "sev 1" defect?
I had a co-worker leave our company recently. Before leaving, he coded a component that had a severe memory leak that caused a production outage (OutOfMemoryError in Java).  The problem was essentially a HashMap that grew and never removed entries, and the solution was to replace the HashMap with a cache implementation.

From a professional standpoint, I feel that I should let him know about the defect so he can learn from the error.  On the other hand, once people leave a company,  they often don't want to hear about legacy projects that they have left behind for bigger and better things.

What is the general protocol for this sort of situation?

答:
If you're under an NDA, then it's a big no-no to talk to someone outside of your company about any IP-related issues, whether they're former employees or not.

If you're not under an NDA, I'd venture to say that he/she won't care.

That aside, was that person disgruntled? Was it something that could actually have been intentional?


答:
You start using an issue tracker to keep track of your todo list.

This will not only help you with keeping track of what is critical, but it will help the users and your boss with seeing what your current workload is.

Also, should they ever hire a second developer (or you quit and your replacement now takes up your workload) this will help in managing the workload, and you'll be able to avoid stepping on each others toes.


答:
You don't hunt down a former collegue to tell him he made a mistake.  You may tell your friend that he made a mistake.

Whether he is a friend or a former collegue is up to you.

Title: Should I tell a departed coworker about their "sev 1" defect?

Body:
I had a co-worker leave our company recently. Before leaving, he coded a component that had a severe memory leak that caused a production outage (OutOfMemoryError in Java).  The problem was essentially a HashMap that grew and never removed entries, and the solution was to replace the HashMap with a cache implementation.

From a professional standpoint, I feel that I should let him know about the defect so he can learn from the error.  On the other hand, once people leave a company,  they often don't want to hear about legacy projects that they have left behind for bigger and better things.

What is the general protocol for this sort of situation?


答:
It depends upon how this person left and your relationship to him/her.

Also, what do you care? I see that you want to help him "learn from the error," but are you really? Are you going to show him the logs* and the stack trace*? Are you going to show him the steps you took to diagnose the issue? Are you going to show him the source* so he can see where the problem was?

If not, then you are probably wasting his time and yours.

*Are you going to get in trouble for disclosing company assets/data to a non-employee?


答:
Failing silently is the worst thing you could possibly do, ever. Have you tried to debug an API with silent failure? It's impossible.

There's "Do your best to recover but send detailed error" and there's "Silent failure".