问:
How is"cloud computing"different from "client-server"?
Watching a CEO for a new "cloud computing" company describe his company on a finance TV program today, he said something like "Cloud computing is superior to old-fashioned client-server computing".

Now I'm confused.  Can someone please explain what "cloud computing" means in contrast to client-server?

As far as I understand it, cloud computing is more of a network services model, such that I do  not own or maintain the physical hardware.  The "cloud" is all the back-end stuff.  But I still might have an application that communicates with that "cloud" environment. And if I run a web site presents a form that a user fills out, pushes a button on the page, and returns some report that was generated by the web server, isn't that the same as "cloud" computing? And would you not consider my web browser as the "client"?

Please note my question is specific to the concept of "cloud computing" with respect to "client-server".

Sorry if this is an inappropriate question for this site; it's the one closest in the Stack universe and this is my first time here.  I'm an old timer, programming since mainframe days in the late 70's.

答:
I think it is fair to say that "cloud computing" and "client-server" are very similar. From my perspective, cloud computing seems to rely more on the server than the "client-server" model. In theory, some forms of cloud computing can happen regardless of a client connection. The benefit of an application only running on the cloud with no client communication doesn't seem very helpful, so it makes sense to create some form of client communication to that server.

Essentially I think it mostly relies on where the majority of your computing power is being done. A server generally has better specs, in terms of hardware and computing power, than a standard user computer in order to simply manage many client connections and concurrent operations to serve those connections. Cloud computing uses this as an advantage by moving what would normally be client run code to the server and allowing the client to be as "dumb" as possible. Thus requiring less user resources, to handle the same type of operations.

Might not be the best answer, but that is how I see it.


答:
Can someone please explain what "cloud computing" means in contrast to client-server?

It depends on your perspective. For businesses, cloud computing is good because it (usually) allows you to be more flexible with the number of machines supporting your services. That flexibility allows you to be more responsive, which should save you money. Businesses can also take advantage of letting the cloud provider do backups, disaster recovery, physical security, and all of the other infrastructure stuff that they don't want to deal with. This usually leads to savings and improved quality.

From the consumer's perspective, the increased connection quality and reliability are good. Some cloud providers also help distribute their servers to help consumer's latency.

For programmers... it's pretty much client-server programming where the server is a pain to get to and you occasionally need to use some specialized APIs.

ContentLicense: CC BY-SA 3.0

Title: How is"cloud computing"different from "client-server"?

Body:
Watching a CEO for a new "cloud computing" company describe his company on a finance TV program today, he said something like "Cloud computing is superior to old-fashioned client-server computing".

Now I'm confused.  Can someone please explain what "cloud computing" means in contrast to client-server?

As far as I understand it, cloud computing is more of a network services model, such that I do  not own or maintain the physical hardware.  The "cloud" is all the back-end stuff.  But I still might have an application that communicates with that "cloud" environment. And if I run a web site presents a form that a user fills out, pushes a button on the page, and returns some report that was generated by the web server, isn't that the same as "cloud" computing? And would you not consider my web browser as the "client"?

Please note my question is specific to the concept of "cloud computing" with respect to "client-server".

Sorry if this is an inappropriate question for this site; it's the one closest in the Stack universe and this is my first time here.  I'm an old timer, programming since mainframe days in the late 70's.


问:
Why do we write the action to be performed by a function in jQuery inside the parentheses?
Generally whenever we're programming in any Programming language, say C, we would pass the parameters we need to pass to a function using the parentheses next to the name of the function. Whereas in jQuery, other than the user defined function() we write the action we need the function to perform inside the parentheses, for example,

```<code>$('div').mouseenter(function(){
   /* blah blah blah*/
});
</code>```

Why?

答:
This is because the jQuery method mouseenter is expecting a single parameter, which is a function. It can then call that function later.

We could just as easily write

```<code>function blah(){
    /* blah blah blah */
}
$("div").mouseenter(blah);
</code>```

Body:
This is because the jQuery method mouseenter is expecting a single parameter, which is a function. It can then call that function later.

We could just as easily write

function blah(){
    /* blah blah blah */
}
$("div").mouseenter(blah);


答:
Strictly speaking, there is no 'Cloud'. Not in the sense of what that CEO was spouting.  There's an Internet, of course.  There's hosted services.  There's VPS's.  There's content delivery systems.  We've (technical folks) have adapted to the term to reference certain hosted service models.  But 'Cloud' in consumer media is largely a marketing term loosely translated as 'internet'.  More often than not, it also means 'I get to charge you by the month'.

You are correct in your thoughts that the two terms, 'cloud' and 'client-server' aren't related.  Having a service hosted 'in the cloud' (I always want to add a dramatic 'dun-dun-daaaaaaa' after using that phrase) does not make a client-server app any less client-server-y.  For example, the 'web' primarily uses a client-server model.  The web browser is the client.  The web server is the server.  That a web server is hosted 'in the cloud' does not change the fact that the web browser / web server relationship is client-server.

So the term client-server defines the relationship between two entities in a system.  Where the entities are physically hosted is irrelevant.

Basically, you are correct.  The two are not comparable.


问:
Should selenium tests be written in imperative style?
Is an automation tester supposed to know concepts of OOPS and design patterns to write Tests in a way where changes & code re-use are possible?

For example, I pick up Java to write cucumber step definitions that instruct a selenium webdriver.

Should I be using a lot of inheritance, interfaces, delegation etc. to make life easier or would that be overly complicated for something that should just line by line instructions?

答:
There is no "should". Testing is a tool. It's like asking "Should an artist always use oil-based paint". The answer is (of course!) "it depends".

The goal of tests are to a) test the product, and b) be well engineered. You can write well-engineered tests in many styles. Your team should do what is most compatible with their skills.


问:
Writing the minimum code to pass a unit test - without cheating!
When doing TDD and writing a unit test, how does one resist the urge to "cheat" when writing the first iteration of "implementation" code that you're testing?

For example:

Let's I need to calculate the Factorial of a number.  I start with a unit test (using MSTest) something like:

```<code>[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}
</code>```

I run this code, and it fails since the CalculateFactorial method doesn't even exist.  So, I now write the first iteration of the code to implement the method under test, writing the minimum code required to pass the test.

The thing is, I'm continually tempted to write the following:

```<code>public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}
</code>```

This is, technically, correct in that it really is the minimum code required to make that specific test pass (go green), although it's clearly a "cheat" since it really doesn't even attempt to perform the function of calculating a factorial.  Of course, now the refactoring part becomes an exercise in "writing the correct functionality" rather than a true refactoring of the implementation.  Obviously, adding additional tests with different parameters will fail and force a refactoring, but you have to start with that one test.

So, my question is, how do you get that balance between "writing the minimum code to pass the test" whilst still keeping it functional and in the spirit of what you're actually trying to achieve?

答:
If you still able to cheat then the tests are not enough. Write more tests! For your example, I will try to add tests with input 1, -1, -1000, 0, 10, 200.

Nevertheless, if you're really commit to cheat you can write an endless if-then. In this case, nothing could help except code review. You would be soon caught on acceptance test (written by other person!)

The problem with unit tests is sometimes programmers look at them as unnecessary work. The correct way to see them is as tool for you to make the result of your work correct. So if you create an if-then, you know unconsciously that there are other cases to consider. This means you have to write another tests. And so on and so on until you realize the cheating is not working and it is better to just code the correct way. If you still feel that you are not finish, you are not finish.

ContentLicense: CC BY-SA 2.5


答:
A key part of "cloud computing"  is the deployment management tooling.

In "classic" deployments one ordered a specific machine for a specific application and did quite fixed configuration.

In a cloud environment there is more or less standardized hardware in a pool and an API which creates and configures virtual machines on it from some form of templates. By that faulty systems can easily be replaced, scaled up or scaled down depending on needs and the hardware be allocated as needed, een in an automated way.

Of course proper admins did most of that before, too, but besides pure marketing, there is a foundation of standardized APIs (Aamzons AWS API which is also offered by tools like Eucalyptus for "private clouds") and tools (i.e. puppet) emerging.


问:
How much freedom should a programmer have in choosing a language and framework?
I started working at a company that is primarily C# oriented. We have a few people who like Java and JRuby, but a majority of programmers here like C#. I was hired because I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs.

I have recently started on a project building a web application with a focus on getting a lot of stuff done in a short amount of time. The software lead has dictated that I use mvc4 instead of rails. That might be OK, except I don't know mvc4, I don't know C# and I am the only one responsible for creating the web application server and front-end UI.

Wouldn't it make sense to use a framework that I already know extremely well (Rails) instead of using mvc4? The reasoning behind the decision was that the tech lead doesn't know Jruby/rails and there would be no way to reuse the code.

Counter arguments:

He won't be contributing to the code and is, frankly, not needed on

this project. So, it doesn't really matter if he knows JRuby/rails or not.

We actually can reuse the code since we have a lot of java apps that
JRuby can pull code from and vice-versa. In fact, he has dedicated
some resources to convert a Java library to C#, instead of just
running the Java library on the JRuby on Rails app. All because he
doesn't like Java or JRuby

I have built many web applications, but using something unfamiliar is causing some spin-up and I am unable to build an awesome application in as short of a time as I'm used to. This would be fine; learning new technologies is important in this field. The problem is, for this project we need to get a lot done fast.

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

答:
I'd say you have to talk to the team lead and say something like:

I know you guys are a .NET shop, but I was actually hired for my Java/JRubyRails skills. I can build this new application in X amount of time using those tools that I already know. I could learn C#/mvc4 like you want, but it will take >> X amount of time. What do you want?

This raises the issue of "skills-you-were-(assumedly)-hired-for" vs. "skills-you-need-now" and also shows that you're willing to learn the new skills, but that it will take longer to develop the new application as you are new to this tool-set. And you do want to show that you're willing to learn new skills. Not being open to learning new skills is a good way to ensure your employment ends when your skills are no longer needed.

As to your question at the end:

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

It usually depends on the company. If a company buys MS tools and standardizes everything on the VisualStudio platform and .NET framework, it could get very awkward if one developer insists on using Linux and C. That is normal. Exceptions might exist where the company is less fussy about the editors, such as letting developers choose Vi vs. Emacs, as long as the output is the same. I know some companies even let developers choose Windows vs. Linux, but the language they work in has very good support and runtimes for both OSs.

Why do companies do this? Consistency is one reason. It can be very difficult to debug things when the application is a patchwork of binaries built in the favourite languages/frameworks of various developers, built in different tools, and tested on very different systems. If all developers work on mostly similar set ups, those sorts of problems are resolved.

In your case, it sounds like you were hired to work in technology that is non-standard in this company. This seems strange to me, and you might want to talk to the person who hired you about why they wanted that.


问:
Empty interface to combine multiple interfaces
Suppose you have two interfaces:

```<code>interface Readable {
    public void read();
}

interface Writable {
    public void write();
}
</code>```

In some cases the implementing objects can only support one of these but in a lot of cases the implementations will support both interfaces. The people who use the interfaces will have to do something like:

```<code>// can't write to it without explicit casting
Readable myObject = new MyObject();

// can't read from it without explicit casting
Writable myObject = new MyObject();

// tight coupling to actual implementation
MyObject myObject = new MyObject();
</code>```

None of these options is terribly convenient, even more so when considering that you want this as a method parameter.

One solution would be to declare a wrapping interface:

```<code>interface TheWholeShabam extends Readable, Writable {}
</code>```

But this has one specific problem: all implementations that support both Readable and Writable have to implement TheWholeShabam if they want to be compatible with people using the interface. Even though it offers nothing apart from the guaranteed presence of both interfaces.

Is there a clean solution to this problem or should I go for the wrapper interface?

UPDATE

It is in fact often necessary to have an object that is both readable and writable so simply seperating the concerns in the arguments is not always a clean solution.

UPDATE2

(extracted as answer so it's easier to comment on)

UPDATE3

Please beware that the primary usecase for this is not streams (although they too must be supported). Streams make a very specific distinction between input and output and there is a clear separation of responsibilities. Rather, think of something like a bytebuffer where you need one object you can write to and read from, one object that has a very specific state attached to it. These objects exist because they are very useful for some things like asynchronous I/O, encodings,...

UPDATE4

One of the first things I tried was the same as the suggestion given below (check the accepted answer) but it proved to be too fragile.

Suppose you have a class that has to return the type:

```<code>public <RW extends Readable & Writable> RW getItAll();
</code>```

If you call this method, the generic RW is determined by the variable receiving the object, so you need a way to describe this var.

```<code>MyObject myObject = someInstance.getItAll();
</code>```

This would work but once again ties it to an implementation and may actually throw classcastexceptions at runtime (depending on what is returned).

Additionally if you want a class variable of the type RW, you need to define the generic at the class level.

答:
Given a generic MyObject instance, you're always going to need to know whether it supports reads or writes.  So you would have code like:

```<code>if (myObject instanceof Readable)  {
    Readable  r = (Readable) myObject;
    readThisReadable( r );
}
</code>```

In the simple case, I don't think you can improve on this.  But if readThisReadable wants to write the Readable to another file after reading it, it gets awkward.

So I'd probably go with this:

```<code>interface TheWholeShabam  {
    public boolean  isReadable();
    public boolean  isWriteable();
    public void     read();
    public void     write();
}
</code>```

Taking this as a parameter, readThisReadable, now readThisWholeShabam, can handle any class that implements TheWholeShabam, not just MyObject.  And it can write it if it is writable and not write it if it isn't.  (We've got real "Polymorphism".)

So the first set of code becomes:

```<code>TheWholeShabam  myObject = ...;
if (myObject.isReadable()
    readThisWholeShebam( myObject );
</code>```

And you could save a line here by having readThisWholeShebam() do the readability check.

This does mean that our former Readable-only has to implement isWriteable() (returning false) and write() (doing nothing), but now it can go all kinds of places it couldn't go before and all the code that handles TheWholeShabam objects will deal with it without any further effort on our part.

One other thing:  if you can handle a call to read() in a class that doesn't read and a call to write() in a class that doesn't write without trashing something, you can skip the isReadable() and isWriteable() methods.  This would be the most elegant way to handle it--if it works.

Body:
Given a generic MyObject instance, you're always going to need to know whether it supports reads or writes.  So you would have code like:

if (myObject instanceof Readable)  {
    Readable  r = (Readable) myObject;
    readThisReadable( r );
}

In the simple case, I don't think you can improve on this.  But if readThisReadable wants to write the Readable to another file after reading it, it gets awkward.

So I'd probably go with this:

interface TheWholeShabam  {
    public boolean  isReadable();
    public boolean  isWriteable();
    public void     read();
    public void     write();
}

Taking this as a parameter, readThisReadable, now readThisWholeShabam, can handle any class that implements TheWholeShabam, not just MyObject.  And it can write it if it is writable and not write it if it isn't.  (We've got real "Polymorphism".)

So the first set of code becomes:

TheWholeShabam  myObject = ...;
if (myObject.isReadable()
    readThisWholeShebam( myObject );

And you could save a line here by having readThisWholeShebam() do the readability check.

This does mean that our former Readable-only has to implement isWriteable() (returning false) and write() (doing nothing), but now it can go all kinds of places it couldn't go before and all the code that handles TheWholeShabam objects will deal with it without any further effort on our part.

One other thing:  if you can handle a call to read() in a class that doesn't read and a call to write() in a class that doesn't write without trashing something, you can skip the isReadable() and isWriteable() methods.  This would be the most elegant way to handle it--if it works.


问:
Why Use Scala over Java
I am totally into Scala as a language ... and still I struggle with why any company should switch from Java to Scala. Is Scala just syntatic sugar on top of the JVM or are there fundamental improvements in Scala over Java that would improve real world applications? </p>

答:
list comprehension, for comprehension.

for example in java you write:

```<code>int myVar;
if (condition) {
  myVar = //some value
}
else {
 myVar = //some other value
}
</code>```

In scala, the same code, is much more elegantly written (Like python) as:

```<code>int myVar = (//some value) if (condition) else // other value;
</code>```

and done.

There's so much that Scala offers that Java does not.  There's simply no comparison at all.  The only problem is people are more familiar with Java (b/c that's what they teach in CS classes) and not as skilled yet with the Scala paradigm.

Scala has tail recursion, it can return tuples (something that might be coming in Java 8 I think).

It's no comparison.  Scala was developed by Martin Ordersky, who worked on the core team for Java Generics.

Scala is just a far superior language.  That's all there is to it.  People who say otherwise simply haven't explored Scala enough to know better.

Above, I meant to say tail recursion optimization (which the JVM cannot do the way that Scala's compiler can).

Scala also compiles and runs faster than JVM apps (Yes, it's true).  Not to mention the frameworks.  We use Tomcat for example and deploy some servelets to handle REST.

One thing Tomcat can't do, is asynchronous operations that require non-blocking I/O.  For this, JAVA developers have typically invented a workaround using a message queue (send the message to the queue, and some other process or thread picks it up and does whatever you want in the background).

Unfortunately, this method is cr*p, and a hack over the limitations of deploying Java servlets on Tomcat.

Go check out akka+spray.  It uses scala's Actors (Actors are just like Threads, except the only way they can communicate is through messages).

And done, asynchronous REST calls made easy.  Long-running background task?  No problem.  Just fire and forget, and do some REST polling to check it's status from the front-end every once in a while.

If you're still using Java and think it's better than scala, you might as well stop using your computer for typing and go back to the days of quill pens and writing by candlelight.  Java is basically antediluvian compared with Scala.

Title: Why Use Scala over Java

Body:
list comprehension, for comprehension.

for example in java you write:

int myVar;
if (condition) {
  myVar = //some value
}
else {
 myVar = //some other value
}

In scala, the same code, is much more elegantly written (Like python) as:

int myVar = (//some value) if (condition) else // other value;

and done.

There's so much that Scala offers that Java does not.  There's simply no comparison at all.  The only problem is people are more familiar with Java (b/c that's what they teach in CS classes) and not as skilled yet with the Scala paradigm.

Scala has tail recursion, it can return tuples (something that might be coming in Java 8 I think).

It's no comparison.  Scala was developed by Martin Ordersky, who worked on the core team for Java Generics.

Scala is just a far superior language.  That's all there is to it.  People who say otherwise simply haven't explored Scala enough to know better.

Above, I meant to say tail recursion optimization (which the JVM cannot do the way that Scala's compiler can).

Scala also compiles and runs faster than JVM apps (Yes, it's true).  Not to mention the frameworks.  We use Tomcat for example and deploy some servelets to handle REST.

One thing Tomcat can't do, is asynchronous operations that require non-blocking I/O.  For this, JAVA developers have typically invented a workaround using a message queue (send the message to the queue, and some other process or thread picks it up and does whatever you want in the background).

Unfortunately, this method is cr*p, and a hack over the limitations of deploying Java servlets on Tomcat.

Go check out akka+spray.  It uses scala's Actors (Actors are just like Threads, except the only way they can communicate is through messages).

And done, asynchronous REST calls made easy.  Long-running background task?  No problem.  Just fire and forget, and do some REST polling to check it's status from the front-end every once in a while.

If you're still using Java and think it's better than scala, you might as well stop using your computer for typing and go back to the days of quill pens and writing by candlelight.  Java is basically antediluvian compared with Scala.


答:
There are a number of conflicting goals and the problem is to find the best compromise. We have the deadline, we have an team lead that requests a certain toolset, and we have a developer inexperienced with that toolset but doomed to produce something within a (obviously short) timeframe.

It's important to understand, that the team lead has probably some good reasons why he demands exactly this toolset (one of which could be indeed to get you used to this toolset for some reason that you might not know yet). The best thing you can do at the first run is to find out, what these reasons exactly are.

Put into your position, I would try to talk to the team lead and try to explain the situation, as it is in your view, and the options and which outcome (incl. short-term and long-term economic effects) will be generated following each of these options. For example, another more experienced developer could be assigned to coach you, maybe with some pair programmng sessions or the like.

Unless your team lead is a complete moron, you should be able to find a consensus that makes sense with regard to the project and to the overall goals of the company.

Title: How much freedom should a programmer have in choosing a language and framework?

Body:
I started working at a company that is primarily C# oriented. We have a few people who like Java and JRuby, but a majority of programmers here like C#. I was hired because I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs.

I have recently started on a project building a web application with a focus on getting a lot of stuff done in a short amount of time. The software lead has dictated that I use mvc4 instead of rails. That might be OK, except I don't know mvc4, I don't know C# and I am the only one responsible for creating the web application server and front-end UI.

Wouldn't it make sense to use a framework that I already know extremely well (Rails) instead of using mvc4? The reasoning behind the decision was that the tech lead doesn't know Jruby/rails and there would be no way to reuse the code.

Counter arguments:

He won't be contributing to the code and is, frankly, not needed on

this project. So, it doesn't really matter if he knows JRuby/rails or not.

We actually can reuse the code since we have a lot of java apps that
JRuby can pull code from and vice-versa. In fact, he has dedicated
some resources to convert a Java library to C#, instead of just
running the Java library on the JRuby on Rails app. All because he
doesn't like Java or JRuby

I have built many web applications, but using something unfamiliar is causing some spin-up and I am unable to build an awesome application in as short of a time as I'm used to. This would be fine; learning new technologies is important in this field. The problem is, for this project we need to get a lot done fast.

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?


答:
You were apparently hired because of your ability to adapt to "new" technologies.  C# is no different, in that regard.  Are you sure you don't want to take the opportunity to learn something new?

ASP.NET MVC is very similar to Ruby on Rails, in many ways.

You won't be at a snail's pace forever.  If you already know ROR, ASP.NET MVC will be a cinch for you.  The trick is learning C#.


问:
Emacs-as-OS: obsolete?
In an attempt to reach at least beginner status with such a legendary editor, I have been coding in Emacs for the last two months.  I try to keep an open heart, but I find myself continally disagreeing with one core design choice: that Emacs allow its users to never have to leave.  In a 2010 world, I just think that every side feature of Emacs is hopelessly behind dedicated software:

I would never use its built-in browser; Chrome is years ahead.

I would never use its dired feature; Path Finder (Mac OS X) suits my needs.

I would never use its built-in email; the Gmail web interface has more relevant features like Priority Inbox.

Etc.

Sure, I might occasionally dip into Emacs to use regexps, etc. for one of the above tasks, but other than regexps, I really see no reason to ever touch those side features.  I'm a completely newbie, yet I have a strong gut feeling that Emacs-as-an-OS is obsolete.

Emacs experts, do you think that Emacs' choice to be a comprehensive environment is the right choice for 2010 and the future?  Are there particular peripheral features that are still at or ahead of their time compared to alternatives?

答:
Emacs was never intended for the mass market. It is designed for efficient use by people who have taken the time to learn how it works. That said, one size does not fit all, so you may not like emacs even after you learn more about it. </p>

<p>EDIT: My two favorite features of emacs besides editing text are the shell mode, and gnus. After getting frustrated with Google Groups because of all the spam, I signed up with Eternal September and learned how to use gnus. It's much faster to navigate through messages, and only the occasional spam posting gets through, and getting rid of it is a matter of one key press. Shell mode is especially useful to me at work because copy/paste is more efficient than it is in a DOS prompt. </p>

Title: Emacs-as-OS: obsolete?

Body:
Emacs was never intended for the mass market. It is designed for efficient use by people who have taken the time to learn how it works. That said, one size does not fit all, so you may not like emacs even after you learn more about it.

EDIT: My two favorite features of emacs besides editing text are the shell mode, and gnus. After getting frustrated with Google Groups because of all the spam, I signed up with Eternal September and learned how to use gnus. It's much faster to navigate through messages, and only the occasional spam posting gets through, and getting rid of it is a matter of one key press. Shell mode is especially useful to me at work because copy/paste is more efficient than it is in a DOS prompt.


答:
At what point should a developer be allowed to choose his tools?

When they don't impact your team.

Am I looking at this the wrong way?

Absolutely.

Yes, you have a short deadline. Yes, you could get it done faster in Rails. But the company as a whole needs to deploy and maintain the application. If the company has a stable of good C# developers, then it will probably be cheaper (and yield better quality) to have a C# app to maintain.

Your DBAs and other admin staff are probably familiar with that stack and have processes in place to deploy and update that stack. Even if you can get the code done faster, it might take longer once you account for all of the overhead needed to get a professional web app up and running.

Remember, you're going to spend way more time maintaining your app than writing it. Optimize for that cost.


答:
Many companies simply prefer to stick with what they've always done or what's "safe". There's a reason Java and PHP are still very popular. At the moment, searching for "COBOL" on indeed.com returns 2144 listings...that should really speak for itself. The industry doesn't care about good code, it cares about code it can milk for as long as possible (this doesn't imply C# is bad, it really isn't).

Think it about this: the code is going to outlast you. There's a good chance that someone else is going to maintain your code and C# is a safer bet than Node.js and Rails. It wouldn't surprise me if in 5 or 6 years the number of Ruby programmers halved, after all the same happened to Perl and any other language that has been considered at some point the "it" web language. Javascript isn't likely to go away but we're already starting to see it being used as a sort of ASM (or even C) of the web - an intermediate language other languages can compile to so writing server-side code in it could very well become obsolete.


问:
Storing a value vs calling reference for repeated use in Java
I have an old habit of avoiding calling references multiple times, both for easier to read/maintain code, and for possible efficiency.  But I'm wondering which is more efficient (memory, performance, both?).

For example when working with XML using a VTD parser

```<code>if( vn.toString( vn.getCurrentIndex() ).equalsIgnoreCase( "broken-label" ) == false )
        {
            do
            {
                if( parentNode != null )
                {
                    currentNode = parentNode.addChildNode( vn.toString( vn.getCurrentIndex() ) );
                }
                else
                {
                    currentNode = new xmlNode( vn.toString(vn.getCurrentIndex()), null );
                    treeNodes.add( 0, currentNode );
                }
</code>```

Does not store the value, perhaps saving some overhead for creating space to save  a local variable and also lowering the burden on the garbage collector (assuming this section of code is repeated thousands of times in quick succession.

My habit of cleaner/efficient code would be to replace the above with the simple change of

```<code>String label = vn.toString( vn.getCurrentIndex();

if( label ).equalsIgnoreCase( "vsled-image" ) == false )
        {
            do
            {
                if( parentNode != null )
                {
                    currentNode = parentNode.addChildNode( label ) );
                }
                else
                {
                    currentNode = new xmlNode( label, null );
                    treeNodes.add( 0, currentNode );
                }
</code>```

While this is obviously easier to read and maintain.  Are there any non-human benefits?

答:
One point not mentioned here:  vn.getCurrentIndex() might get a different value with each call.  Your local variable will retain its value, which can be quite useful.

(Another thread might change it.  Or a trivial-looking method that obviously has nothing to do with the current index might call something that calls something that ... changes the index.)


答:
"Cloud computing" is a blanket term meant to do two things: first, to abstract all possible uses of a client-server model behind a single term, as opposed to more specific use cases like "file servers", "database servers", "web servers", "application servers" etc.; and second, to abstract the server architecture itself, in terms of hardware, topology, location, and even ownership.

In a traditional client-server model, which is definitely still in common use today, a client connects to a server that performs a particular job. This server may host a database, or a series of file shares, or a webpage. When the client connects to that server, there is an implicit understanding of the type of communication and data transmission that will ensue between the two computers. There may also be an understanding by the client, or the end user, of the capabilities of the server's hardware, and its limitations. This relatively "tight coupling" between the client machine and its server can pose problems for a sysadmin who needs to take down a server for maintenance; all the applications dependent upon resources provided by this server have to be pointed at another server, and not all applications and infrastructures are designed with this type of redundancy and failover-tolerance in mind.

In a cloud model, the hardware, topology, division of labor, and even number of actual machines involved is all abstracted behind a single endpoint. The analogy could be drawn to a modern "web application", as opposed to older generations of "website" which were more static. We might guess that there is an application server and a DB server behind the scenes, but we really don't have to care; the web server, as part of its job to serve the full application to users beyond the "edge", provides a unified endpoint allowing controlled access to all the data and services provided by other machines behind this front door.

The upshot is that, with a single endpoint exposed to provide the functionality of the application, that's all a client consumer of the application ever has to care about, instead of where to get its data, where to call such and such a remote application process, etc; that means that the administrators and architects of the service provider within this cloud are more or less free to change the machines, topology and other specific implementation details of this "cloud service" without the clients being any the wiser. Facebook could, if it thought it wise, rebuild its entire data storage system from scratch using a different DBMS and all new servers, and as long as the site remained available during the transition, nobody would ever be the wiser; in fact, Facebook did just that, many times, as it expanded from a site hosted from Mark Zuckerberg's personal machine in a dorm room to dedicated hosting off-campus, to server farms in several locations worldwide.


问:
What to call requirements that are "assumed"/"invisible"/"very obvious"
I'm looking for an umbrella term for all the nitty-gritty requirements that it's helpful to have specified up front but which the client never thinks about in his excitement about the product.

In the client's mind, they think of the headline requirements, the main user stories such as "I need to be able to view the status of all equipment" and "I need to receive automatically any notification equipment failure". But at times the mundane ones are there but the client never mentions them until the result differs from his unspoken expectations: "Well of course a user must be able to change his own password" and "Of course the user's session must time out after 30 mins"

Any development team can anticipate what's likely to be needed but is there a name for this category of requirements? Obvious/infrastructural/boring/details?

答:
I'd just go with assumptions (or, unwritten assumptions if it should be more precise).

Implicit, from another answer, doesn't quite work, because what was requested doesn't necessarily rely on them.  For example, user must be able to change their password isn't implicit unless another requirement makes reference to a user changing their password with the assumption that it already works.

Very obvious, from the question, doesn't really work either.  It could easily be something that's only obvious to someone with appropriate domain knowledge, or works very closely with the product.  Or, to use the password example, it may be that users shouldn't be able to change their passwords, and only admins can.

What you're describing are things that the client assumed would be done.


答:
Generally whenever we're programming in any Programming language, say C

C does not encompass "any programming language". For example it does not have Object Oriented capabilities. As a matter of fact, in C you'd do somethin similar to your JavaScript/JQuery example: pass a function as argument to your user input callback. Here's how it would work with GLUT:

```<code>void blah() {
   /* blah blah blah */
}

void ODLGameLoop_initOpenGL() {
    glutKeyboardFunc(blah);
}
</code>```

In C and JavaScript functions are first class objects, meaning that they can, amongst other things, be passed around as arguments to other functions.

In Object Oriented languages, such as Java for example, you'd need to pass an instance of a certain type of class to the callback function, something like this:

```<code>class MyMouseListener implements MouseListener {

    public void mouseClicked(MouseEvent e) {
        /* blah blah blah */
    }

    public static void main(String[] args) {
        JFrame myJframe = ....;
        myJFrame.addMouseListener(new MyMouseListener());

    }

}
</code>```

These are both examples of, as you put it: "we would pass the parameters we need to pass to a function using the parentheses next to the name of the function". It's just that in languages that support functions as first class objects, those parameters are (sometimes) functions, and in Object Oriented Languages they are (sometimes) objects.

Title: Why do we write the action to be performed by a function in jQuery inside the parentheses?

Body:
Generally whenever we're programming in any Programming language, say C, we would pass the parameters we need to pass to a function using the parentheses next to the name of the function. Whereas in jQuery, other than the user defined function() we write the action we need the function to perform inside the parentheses, for example,

```<code>$('div').mouseenter(function(){
   /* blah blah blah*/
});
</code>```

Why?

Body:
Generally whenever we're programming in any Programming language, say C

C does not encompass "any programming language". For example it does not have Object Oriented capabilities. As a matter of fact, in C you'd do somethin similar to your JavaScript/JQuery example: pass a function as argument to your user input callback. Here's how it would work with GLUT:

void blah() {
   /* blah blah blah */
}

void ODLGameLoop_initOpenGL() {
    glutKeyboardFunc(blah);
}

In C and JavaScript functions are first class objects, meaning that they can, amongst other things, be passed around as arguments to other functions.

In Object Oriented languages, such as Java for example, you'd need to pass an instance of a certain type of class to the callback function, something like this:

class MyMouseListener implements MouseListener {

    public void mouseClicked(MouseEvent e) {
        /* blah blah blah */
    }

    public static void main(String[] args) {
        JFrame myJframe = ....;
        myJFrame.addMouseListener(new MyMouseListener());

    }

}

These are both examples of, as you put it: "we would pass the parameters we need to pass to a function using the parentheses next to the name of the function". It's just that in languages that support functions as first class objects, those parameters are (sometimes) functions, and in Object Oriented Languages they are (sometimes) objects.


问:
How to read thousands lines of code without any documentation?
Previously I was searching for a good TimeLine control for a WPF project. I found an answer in Here which direct me to this CodePlex project.

Now I want to change code to feed my culture needs. But there are some mismatches!

My question is:

How you interact with such thousands lines of code?

EDIT:

Any shortcut will be great!

答:
Step through the code

Rename as needed

Refactor as needed

Repeat until you completely understand

... and the code will thank you for it. ;-)


答:
Arguments for staying with Java/JRuby

Chances are, your boss wants you to produce. They hired you so that you could add value to the company. Ensure that they understand that by forcing you to use a framework that you aren't familiar with they will cause you to:

Produce results at a slower rate

Create lower quality code

Even the best programmers require warm up time with new languages/frameworks.

Arguments for Learning MVC4 and C#

Learning new languages is good. Investing in your skills as a programmer is only a risk if the language/platform you're learning is going to disappear in the near future, and with Microsoft chugging along, I don't think that that's an issue. C# and MVC both have had recent updates improving them both, with even more updates in the pipeline.

Making you, personally, a more well rounded developer will keep you from being put in this situation ever again. The best part? Your boss will be paying you to learn these things, meaning that you get paid to make yourself worth more money.

The Bottom Line

You may end up winning this fight, but you'll be left working with disgruntled colleagues. Just explain the pros and cons of each to your manager and then you'll both come out the other end happier.


问:
Rails/Node.js interaction
I and my co-worker are developing a web application with rails and node.js and we can't reach a consensus regarding a particular architectural decision.

Our setup is basically a rails server working with node.js and redis, when a client makes a http request to our rails API in some cases our rails application posts the response to a redis database and then node.js transmits the response via websocket.

Our disagreement occurs in the following point: my co-worker thinks that using node.js to send data to clients is somewhat business logic and should be inside the model, so in the first code he wrote he used commands of broadcast in callbacks and other places of the model, he's convinced that the models are the best place for the interaction between rails and node.

I on the other hand think that using node.js belongs to the runtime realm, my take is that the broadcast commands and other node.js interactions should be in the controller and should only be used in a model if passed through a well defined interface, just like the situation when a model needs to access the current user of a session.

At this point we're tired of arguing over this same thing and our discussion consists in us repeating to ourselves our same opinions over and over. Could anyone, preferably with experience in the same setup, give us an unambiguous response saying which solution is more adequate and why it is?

答:
Actually (without knowing more of the details of your architecture or your domain), this situation would be a great fit for a service object---as an occasional mediator object between your controller and your models.

Call it WebSocketsService or BroadcastService, or whatever you like. Make it a singleton (either using the Ruby singleton stuff in std lib, or perhaps a Module extending itself with some methods tacked onto it), and access it from either the controller, or from a model.

Your controller could invoke it:

```<code>WebSocketsService.broadcast(my_model, "this message!")
</code>```

...and likewise for your models.  You mentioned above the possibility of going through a "well-defined interface": something like this might be it.

```<code>module WebSocketsService
  extend self

  def broadcast(model, message)
    ## interact with Node here...
  end

end
</code>```

If you decide to go to an Rails-only solution in the future, the only thing you'll have to change is the implementation inside these methods. Neither the controllers nor the models involved would need to know.

I just add a /services directory inside of /app to keep them all.

Just an idea I hadn't seen mentioned above.

Title: Rails/Node.js interaction

Body:
Actually (without knowing more of the details of your architecture or your domain), this situation would be a great fit for a service object---as an occasional mediator object between your controller and your models.

Call it WebSocketsService or BroadcastService, or whatever you like. Make it a singleton (either using the Ruby singleton stuff in std lib, or perhaps a Module extending itself with some methods tacked onto it), and access it from either the controller, or from a model.

Your controller could invoke it:

WebSocketsService.broadcast(my_model, "this message!")

...and likewise for your models.  You mentioned above the possibility of going through a "well-defined interface": something like this might be it.

module WebSocketsService
  extend self

  def broadcast(model, message)
    ## interact with Node here...
  end

end

If you decide to go to an Rails-only solution in the future, the only thing you'll have to change is the implementation inside these methods. Neither the controllers nor the models involved would need to know.

I just add a /services directory inside of /app to keep them all.

Just an idea I hadn't seen mentioned above.


答:
This is less about jquery, and more about how javascript works overall.  Passing functions as variables is extremely vital to programming in javascript because javascript is asychronous.
Consider this:

```<code> var a = getA();
 var b = getB(a);
</code>```

Now, we need 'a' first, then we use it to get 'b'.  But javascript doesn't guarantee that function getA will run to completion before function getB is called.  So we could do something like this instead:

```<code> var b = getA(getB);
</code>```

Now function getA can call getB when it's finished.

In your example (i didn't look it up but I'm assuming) you want the program to look at every div on the page, and when a mouse enters that div, execute a block of code.

We don't want that code to execute right away, on every div as soon as jquery finds it.  We want the div to call that block of code when the mouse enters it.  What do we call a block of code that can be called?  We call that a function, son.  So it wouldn't make sense to use anything other than a function.

Body:
This is less about jquery, and more about how javascript works overall.  Passing functions as variables is extremely vital to programming in javascript because javascript is asychronous.
Consider this:

 var a = getA();
 var b = getB(a);

Now, we need 'a' first, then we use it to get 'b'.  But javascript doesn't guarantee that function getA will run to completion before function getB is called.  So we could do something like this instead:

 var b = getA(getB);

Now function getA can call getB when it's finished.

In your example (i didn't look it up but I'm assuming) you want the program to look at every div on the page, and when a mouse enters that div, execute a block of code.

We don't want that code to execute right away, on every div as soon as jquery finds it.  We want the div to call that block of code when the mouse enters it.  What do we call a block of code that can be called?  We call that a function, son.  So it wouldn't make sense to use anything other than a function.


问:
Is it realistic to use designers for complex UI
When I created my first web application few years ago, I remember trying to use the designer in VS 2008. Before I can even remember I abandoned it to the favor of actual debug to understand how my UI will actually look like.

Since then, I gave it few more shoots but I was never convinced that it's even possible to build an complex UI with it.

How much progress designers have made in the recent few years? Are there any designers that can enable real-time view of highly complex UI? is it programming language/framework dependent?

Thanks.

答:
Having a UI Designer tool greatly streamlines the UI design process for most developers.  Designer tools help developers visualize what they are creating, and write some of the code for them.  But if you already feel productive hacking that code by hand, more power to you.

XAML is probably the closest thing to language-independent UI that Microsoft has.  Given the "many languages" paradigm that Microsoft adopted when they created .NET, XAML was a natural choice.  You can manipulate a XAML UI just as well in VB.NET as you can in C#, or any other .NET language, for that matter.

What you see as complexity in a designer is mostly necessary.  Each control on a form may have 40 to 50 properties, ranging from event bindings to size and location in a container.  Having this level of complexity insures that you have the necessary flexibility to mold the UI to your particular vision.

The real choice to be made is not the designer per se, but the underlying technology.  Do you choose a proprietary but mature interface like WPF, or an open standard like HTML5?  The designers, from what I've seen, are not all that different from each other.  They all have property pages, design surfaces, etc.

I personally would shoot myself if I didn't have a designer.  Even the simplest of Windows forms involves dozens to hundreds of lines of boilerplate code, code that I don't have to write by hand if I'm using a designer.  A simple example of something you don't want to have to code by hand: the position of a control on a form.  Why estimate the X and Y position numbers when you can just drag the control to the proper position on the form, and have it automatically line up with other controls or snap to a grid?

Actually, I'm a huge fan of code-generating a UI through templates.  Creating a detailed UI is very tedious for most software developers, whether you're using a designer or not, so if I can hand some code generator a table or series of tables, and have a template code-generate a sensible UI for me, why not?


问:
Is it OK to have a team with same abilities but different skill levels?
I believe that in an ideal team, members should have different but complementary abilities. But is that true about software development teams?

As an example we are a small team of 5. We almost have the same abilities and interests but with different levels of skills. Regarding such situation I think we don't cover our teammates' weaknesses.

Is there any pattern to follow to manage and improve such team?

Should I setup a team with different abilities and interests to maximize the performance and productivity?

-- EDIT --

Our current team has a specific lifetime. We work together in a per-project manner. In another word we may change the team arrangement for each project depending on the project and developers situation. Actually we've provided a sort of floating situation.

In short, we are a network of developers rather than a fixed-size development team.

答:
I asked myself two questions:

1) If a team member take a month long vacation, is the team exposed?

2) If a team member walks out today, is the team exposed?

If you are not comfortable with your own answers, then you will know what skills need to develop in the team and who to learn what.  It may take some time get the team to the level you feel comfortable with.

Updated

It answered the question precisely if you think about it.

Same abilities and different skills are fine if you are in the env that you have enough of same skill level to cover the needs like one of the key folks  take a longer break or walk out.  This approach is much more effective that any prescriptive approach or formula.


问:
How to refactor when all your development is on branches?
At my company, all of our development (bug fixes and new features) is done on separate branches. When it's complete, we send it off to QA who tests it on that branch, and when they give us the green light, we merge it into our main branch. This could take anywhere between a day and a year.

If we try to squeeze any refactoring in on a branch, we don't know how long it will be "out" for, so it can cause many conflicts when it's merged back in.

For example, let's say I want to rename a function because the feature I'm working on is making heavy use of this function, and I found that its name doesn't really fit its purpose (again, this is just an example). So I go around and find every usage of this function, and rename them all to its new name, and everything works perfectly, so I send it off to QA.

Meanwhile, new development is happening, and my renamed function doesn't exist on any of the branches that are being forked off main. When my issue gets merged back in, they're all going to break.

Is there any way of dealing with this?

It's not like management will ever approve a refactor-only issue so it has to be squeezed in with other work. It can't be developed directly on main because all changes have to go through QA and no one wants to be the jerk that broke main so that he could do a little bit of non-essential refactoring.

答:
It may look like a difficulty in the technical side when actually it's in the requirements side.

Where the development is oriented towards different requirements in different branches is the real difficulty. The managers and architects of the team should make decisions that may enable the different Business needs to co-exists.

ZBB process and Co-Dev "compromises"  when done after making right decisions with relevant inputs from all the developers should afterwords enable you the implement what you need without having to think - How will I merge my code.

ZBB stands for Zero-based budgeting. By saying Co-Dev I meant few people that are working in parallel programming.


答:
I think that even on the most complex of UIs, you're going to spend a tiny part of your time on designing it, either by hand or using a designer.

As far as new UI designers, I'm not familiar with Microsoft products but if you are interested in cross-platform ones, Qt Designer and Stetic are the only relevant ones (Glade too but you've probably heard of it).

Qt Designer is an excellent UI designer in my opinion - it's very versatile in letting you lay out widgets in a WYSWIG manner and I don't see why you wouldn't be able to write complex UIs in it. Since you can subclass any widget you want, virtually all designing could be done in Qt Designer. Plus it's integrated in Qt Creator, a pretty good C++ IDE (of course, if you use VS you probably wouldn't use it). Plus, Qt runs on pretty much everything. The only thing that could turn you off Qt is its Meta-Object compiler. I personally don't have any problems with it, though I usually dislike such abuses of preprocessing.

As for Stetic, it's not bad but you if you are a Windows developer and want to make WinForms stuff, Stetic is not an option. I have nothing against GTK# but, unlike WinForms, it was obviously not designed specifically for .NET, so I'm afraid you might not like it. Using Glade+Vala (a C#-like language designed specifically for GObject/Glib) is probably a better choice.

Title: Is it realistic to use designers for complex UI

Body:
When I created my first web application few years ago, I remember trying to use the designer in VS 2008. Before I can even remember I abandoned it to the favor of actual debug to understand how my UI will actually look like.

Since then, I gave it few more shoots but I was never convinced that it's even possible to build an complex UI with it.

How much progress designers have made in the recent few years? Are there any designers that can enable real-time view of highly complex UI? is it programming language/framework dependent?

Thanks.


答:
At what point should a developer be allowed to choose his tools?

When said developer is the software lead.

Certainly, you can (and should) make the case for using the different toolkit if you're concerned about productivity, but be prepared for an answer you won't like.  There may be a damned good reason why your lead wants you to use a specific toolkit, be it compatibility with the current architecture, concerns about maintenance, licensing issues, etc.

BTW, the phrase

with a focus on getting a lot of stuff done in a short amount of time

is responsible for more heartburn and mayhem in the software industry than just about anything else.


问:
Is the license of gifmerge compatible with GPLv3?
My doubt arises from this sentence in the gifmerge distribution conditions:

"This software may be freely copied, modified and redistributed without fee provided that this copyright notice is preserved intact on all copies and modified copies."

Especially the "without fee" part is the one thet puzzle me.

Can some expert dispel my doubt?

http://www.the-labs.com/GIFMerge/

答: No, it isn't. For reference, take a look at this link, which is the FSF's stance on a similar license. Prohibiting commercial redistribution makes it non-free software.</p>


答:
Because the function that gets passed to the receiving function is throw away function, i.e. not reusable. If it was reusable, it would be written as a function (not closure) or a class method and you'd pass the function name instead of "write the action we need the function to perform inside the parentheses".

To clarify, the function body (action) is not written "inside the parentheses", it's written inside the curly braces which is part of the function(). i.e. the action is
not part of mouseenter() but it belongs to function() that gets passed to mouseenter.

```<code>$('div').mouseenter(f);

f = function(){
   /* blah blah blah*/
};
</code>```

It's no different to typical callback functions in Observer, just different style.

Body:
Because the function that gets passed to the receiving function is throw away function, i.e. not reusable. If it was reusable, it would be written as a function (not closure) or a class method and you'd pass the function name instead of "write the action we need the function to perform inside the parentheses".

To clarify, the function body (action) is not written "inside the parentheses", it's written inside the curly braces which is part of the function(). i.e. the action is
not part of mouseenter() but it belongs to function() that gets passed to mouseenter.

$('div').mouseenter(f);

f = function(){
   /* blah blah blah*/
};

It's no different to typical callback functions in Observer, just different style.


答:
Let's rewrite your example a bit:

```<code>function mouseEnterAction() { doStuff(); }

$('div').mouseenter(mouseEnterAction);
</code>```

The only difference here is that we're using a named function here rather than an unnamed function as you provided in your example.

Ask yourself - what is the "value" of an action?  It isn't something simple like the number 5 or the string "Hello World".  It isn't even something more complex like an array or an object.   For an action to be performed, you need something capable of performing an action - in this case, a function.

The whole idea is you're setting up an event handler.  When the event "mouseenter" happens, you execute the given function and perform whatever actions are needed.  This isn't really fundamentally a Javascript/jQuery thing that's distinct from C - C can do things like this but the syntax is far more complicated.

Body:
Let's rewrite your example a bit:

function mouseEnterAction() { doStuff(); }

$('div').mouseenter(mouseEnterAction);

The only difference here is that we're using a named function here rather than an unnamed function as you provided in your example.

Ask yourself - what is the "value" of an action?  It isn't something simple like the number 5 or the string "Hello World".  It isn't even something more complex like an array or an object.   For an action to be performed, you need something capable of performing an action - in this case, a function.

The whole idea is you're setting up an event handler.  When the event "mouseenter" happens, you execute the given function and perform whatever actions are needed.  This isn't really fundamentally a Javascript/jQuery thing that's distinct from C - C can do things like this but the syntax is far more complicated.


问:
Branching Strategy for Test Environment
We will be starting a new project this month. The project will be 1 year and production deployment will only occur towards the end of the project.

We will be doing iterative development (1 month per iteration), so this means we will drop features to Test environment at the end of each iteration for QA testing.

Our branching strategy is:

Trunk - All development will happen on trunk.

Feature Branch -  Branches off trunk will be created on a per need basis for development of large features which could potentially be breaking if done on trunk

QA Release Branches - At the end of each iteration, a branch of trunk will be created. This branch (which includes a version number) will be released to Test environment. All critical and blocking bugs found in this version will be fixed on this branch and fixes will have to be merged to trunk. Non-critical/trivial bugs will not be addressed on the QA release branch and will only be fixed in trunk since the QA release branch will be thrown away after the end of the next iteration where a new release branch will be created off trunk.

Production Branch - this will be the latest QA release branch at the end of the project. This will be tagged and all production bug fixes will be on this branch and merged to trunk.

Is this a correct branching strategy? Is there anything else that we've missed to consider?

We're using SVN.

答:
You mention several things which are likely to increase awkwardness and reduce the chances of success for your project:

The project will be 1 year and production deployment will only occur
  towards the end of the project.

I really, really recommend that you deploy to a production-like environment as often as possible, ideally every day. Leaving so-called 'productionization' to the end of the project usually results in unforeseen problems. The anti-patterns here are 'late integration', and 'late production deployment'.

1 month per iteration

A month is a very long iteration heartbeat, and few developers will be able to remember clearly what they were working on at the start of the iteration. I'd recommend going for 2-week iterations, delivering in smaller batches. Anti-patterns: 'large batch sizes', 'long cycle time'.

Feature Branch

You should probably avoid feature branches, unless you also use integration branches. Ideally, use feature toggles and branch-by-abstraction instead. Feature branching tends to lead to unexpected late integration problems. Anti-pattern: 'late integration'.

We're using SVN.

Merging is pretty painful in Subversion, even if you use the merge-tracking features of v1.5 and later. I recommend you switch to Git - you'll never look back. Merging with Git is painless compared to with Svn. I used Subversion for many years, and was initially skeptical of Git, but I am now 'sold'. The only things I'd use Svn for over Git are for storing binary files (if really necessary!) and for things like RANCID which are in complete control of the repo. For source code control, Git beats Subversion every time.

I recently wrote about work I have done on releasing from trunk/mainline/master and avoiding feature branches, which might give you some further 'food for thought':
Leaving the Platform – Branching and Releasing for Independent Subsystems

Also, read some posts on Martin Fowler's site, such as ContinuousIntegration, FeatureBranch, and BranchByAbstraction.

Finally, buy a copy of Continuous Delivery by Jez Humble and David Farley and work through the recommendations - it's a hugely valuable book, and every developer should own a copy. I have found it useful to print out the Contents pages and put them on the wall to track progress :) Even if you don't intend to delivery continuously, so many of the practices in this book are really healthy and vital for successful software delivery today.

Hope this helps.

M

Title: Branching Strategy for Test Environment


问:
When deploying updates, do you deploy all or selected/changed assemblies?
I'm a developer and I have had several experiences in web application deployment which are the following:

Deploy all files then apply configuration values as appropriate to the environment. We've used this style of deployment for larger softwares with long development cycles and quick releases aren't needed or allowed unless for emergencies.

Deploy only what has changed; manually update configuration files with what new or updated configuration as appropriate to environment. We've used this style for web applications that tend to be more agile, i.e. fix and feature releases are almost done daily. I've had issues with this before where not all assemblies dependent on an assembly that has changed were identified (A constant value was change in assembly A and the same constant was used in assembly B and only assembly A identified as changed).

Which of the 2 is a better (or best) practice? I'm starting a new medium sized project where deployments would be on a monthly basis and would like to establish this process early on.

答:
Deploying everything is fine when the codebase is small, but does not scale as it becomes larger.

You can gain control above and beyond your two points by using a deployment pipeline to push changes to your different environments. The pipeline is triggered by changes, so you retain traceability over changes, whilst deploying only when needed.


问:
Single Page Web Application and Requiring JavaScript
I'm under the impression, and I agree with it, that it's bad to create a web application requiring JavaScript to function properly.

What if one were to create a single page application?  Is it possible to create one that doesn't rely on JavaScript, without being difficult, or full of "hacks"?

答:
I'd say no. It could've been bad 5-10 years ago to create a web application that requires JavaScript, but technology is advancing, and as such, web applications are becoming more dynamic, and require proper processing technology. This is where JavaScript comes in.

Single page web applications are likely to be even more heavily reliant on JavaScript, as they tend to make strong use of AJAX calls to show data.

At the end of the day, you could theoretically make a single page application in server-side code such as PHP, but the quality of the website will be severely lacking in comparison to one that takes full advantage of the technology available today.


答:
There are several problems that are mixing together to make refactoring challenging in this environment.  Mixed into this are some non-technical problems ("but that's a management issue and a battle I've yet to win").

The first problem to look at is the long running branch.  These branches have difficulty with tracking changes outside of the view of the developer. To address this:

When the code is complete - give it a once over (let customer support look at it if they want), but merge it quickly into develop so that other changes that depend  it will be able to be picked up and changes that conflict are identified early in the process.

If, for some reason a brach does become long running while refactoring is going on, it tends to be good practice to merge from stable into the branch to pick up changes and refactoring.  Often this minimizes conflicts and surprises on merge from the feature branch into the stable branch.

All out integration testing needs to be done on releases - not features.  In this environment features may or may not be fully integrated with the system. While it is possible to do a sanity check on the feature in isolation, it doesn't identify issues upon the release.

From time of code completion to merge to (lets call it develop - branching from master / stable / release has its own issues of not picking up the latest development changes) shouldn't be too long.  The longer you wait, the more knowledge that is lost and the harder it is for the code to become integrated with other code lines.

Another issue that is mixing into this is that I alluded to with the above points is the changing role of the branch over time.  It starts out as a development branch where developers commit, and then becomes a testing area (what testing is being done here that can be meaningful in the whole of the application?), which is then merged into stable (and presumably released - is it tested again?).

With a shorter feature start to end time it is easier for the refactoring to be able to be picked up by other branches.

Encourage developers to get the entire environment.  Just cherry-picking changes can lead to... lets say interesting developer environments.  While cherry-picking has its uses, for that to be the default mode of pulling changes into a branch can be worrisome.

Refactoring is something that ideally is done constantly, or if not constantly whenever there is a modicum of downtime.  Branch, do a simple refactoring, run the unit tests to verify everything is still working (its unit tested, right? right?) and then merge back into stable.  Pass around the information for other developers to pull those changes that you refactored into their own branches.

It is important for developers to own the quality of the code.  While the direction of the features comes from outside, and the time allocations are often not our own, code quality is something that it is necessary to take pride in and make time for.

You may find the following questions useful in the quest for allocating time for dealing with technical debt:

Should technical debt be scheduled as a feature or a chore (or a bug)?

How can I convince management to deal with technical debt?

Look also at the linked questions to this one - it is often cited in other questions that may be of value going and reading.

You may also wish to look at tools such as sonar which can help identify the areas of the code that need the most work for refactoring.  The technical debt plugin is something that can be used to help point out the accumulation of debt over time in the code base.

Often it is necessary to point out that the ROI for dealing with technical debt is a faster turnaround time for features and bug fixes from the development team.

Title: How to refactor when all your development is on branches?

Body:
At my company, all of our development (bug fixes and new features) is done on separate branches. When it's complete, we send it off to QA who tests it on that branch, and when they give us the green light, we merge it into our main branch. This could take anywhere between a day and a year.

If we try to squeeze any refactoring in on a branch, we don't know how long it will be "out" for, so it can cause many conflicts when it's merged back in.

For example, let's say I want to rename a function because the feature I'm working on is making heavy use of this function, and I found that its name doesn't really fit its purpose (again, this is just an example). So I go around and find every usage of this function, and rename them all to its new name, and everything works perfectly, so I send it off to QA.

Meanwhile, new development is happening, and my renamed function doesn't exist on any of the branches that are being forked off main. When my issue gets merged back in, they're all going to break.

Is there any way of dealing with this?

It's not like management will ever approve a refactor-only issue so it has to be squeezed in with other work. It can't be developed directly on main because all changes have to go through QA and no one wants to be the jerk that broke main so that he could do a little bit of non-essential refactoring.


答:
Yes it's possible. The way to do it is to create a multi-page application first, then progressively enhance it into a single-page application. In your client side code, you use the HTML5 History API to manipulate the URL so that if the app is bookmarked at any time, then the bookmark will show the same page or application state no matter which browser the bookmark is opened on. Is it a lot of work? Yes, but this is indeed the pattern that's usually followed to make single-page applications that work without JavaScript.

One famous example is the GitHub Tree Slider.

Title: Single Page Web Application and Requiring JavaScript

Body:
I'm under the impression, and I agree with it, that it's bad to create a web application requiring JavaScript to function properly.

What if one were to create a single page application?  Is it possible to create one that doesn't rely on JavaScript, without being difficult, or full of "hacks"?


答:
I remember people making this argument 10 years ago and even back then I thought it was ridiculous. Apart from the utter uber-geek who represents 0.01% of the population, no-one turns off javascript these days. No-one. I hate to be dogmatic about this but look at the biggest websites - gmail, facebook, twitter, youtube - they all need javascript to work.

The only thing to be careful of is security - you can't rely on javascript for validation because the user could turn it off - or even worse, alter it.


问:
How is"cloud computing"different from "client-server"?
Watching a CEO for a new "cloud computing" company describe his company on a finance TV program today, he said something like "Cloud computing is superior to old-fashioned client-server computing".

Now I'm confused.  Can someone please explain what "cloud computing" means in contrast to client-server?

As far as I understand it, cloud computing is more of a network services model, such that I do  not own or maintain the physical hardware.  The "cloud" is all the back-end stuff.  But I still might have an application that communicates with that "cloud" environment. And if I run a web site presents a form that a user fills out, pushes a button on the page, and returns some report that was generated by the web server, isn't that the same as "cloud" computing? And would you not consider my web browser as the "client"?

Please note my question is specific to the concept of "cloud computing" with respect to "client-server".

Sorry if this is an inappropriate question for this site; it's the one closest in the Stack universe and this is my first time here.  I'm an old timer, programming since mainframe days in the late 70's.

答:
In 'traditional' client-server architecture you had statically assigned resources (or at least it is presented as such - I don't have experience from pre-cloud period so please correct me if I'm wrong and depend on false marketing). The database server was called db.yourcompany.com and your webserver communicated with it. If you wanted to increase resources you might add another dedicated webserver and provide load-balancing etc.

On the other hand in cloud stress have been put on abstraction of lower levels and denote how the 'server' is constructed. On the For example you have:

HAAS (Hardware As A Service) - client (company) gets a hosted computer on which they can install any OS they want. The difference is that they don't 'really' get a computer but a virtual machine in a farm. Because it is virtualized they don't need to care about lower level details like amount of computational power, pay the bills regardless if machine is used, how it is connected etc.

PAAS (Platform As A Service) - a level highier - you write an aplication which somehow somewhere runs. As API is general enough the cloud providers may allocate resources on demand so if your application got slashdotted you will pay for more resources rather then suffer from non-malicious DDOS.

SAAS (Software As A Service) - yet another level highier - you don't write an application - you use one. You don't care how it is implemented or what resources it uses. It is available everywhere and at any time.

Please note that while in most cases it is implied that actual service is outsourced to large company (say Amazon or Google) it is not necessary the case - large companies or universities deploy their own internal clouds to allow easier management of resources. This allow to add the resources to the application their run to be added as needed. If the new internal startup got successful they don't need to worry that the servers got overloaded. However as economy of scale play role it is usually done only when there are special requirements (for example regarding security).

From user perspective it is transparent and it have look'n'feel of client-server architecture. Webserver might live 'in the cloud' while using plain old HTTP. The ideas problems and solutions indeed run back to 50s mainframes and currently they come back more as a contrast to thick client PCs.

Having said that it might also be a buzzword in given sentence and state that company is dynamic and focus on their core competence while enabling their employees.


答:
I deploy everything. It's a lot safer, doesn't cost you much and saves a lot of headaches. When you're debugging issues on a test server the last thing you want to be thinking about is "hang on is this code in DLL #3 up to date".

If you're in .NET land, I have had issues where deploying a .NET DLL (the only one that had changed) that had a dependency on a third-party control just stopped working. Deploying the whole lot fixed everything.

Title: When deploying updates, do you deploy all or selected/changed assemblies?

Body:
I'm a developer and I have had several experiences in web application deployment which are the following:

Deploy all files then apply configuration values as appropriate to the environment. We've used this style of deployment for larger softwares with long development cycles and quick releases aren't needed or allowed unless for emergencies.

Deploy only what has changed; manually update configuration files with what new or updated configuration as appropriate to environment. We've used this style for web applications that tend to be more agile, i.e. fix and feature releases are almost done daily. I've had issues with this before where not all assemblies dependent on an assembly that has changed were identified (A constant value was change in assembly A and the same constant was used in assembly B and only assembly A identified as changed).

Which of the 2 is a better (or best) practice? I'm starting a new medium sized project where deployments would be on a monthly basis and would like to establish this process early on.


问:
Writing the minimum code to pass a unit test - without cheating!
When doing TDD and writing a unit test, how does one resist the urge to "cheat" when writing the first iteration of "implementation" code that you're testing?

For example:

Let's I need to calculate the Factorial of a number.  I start with a unit test (using MSTest) something like:

```<code>[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}
</code>```

I run this code, and it fails since the CalculateFactorial method doesn't even exist.  So, I now write the first iteration of the code to implement the method under test, writing the minimum code required to pass the test.

The thing is, I'm continually tempted to write the following:

```<code>public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}
</code>```

This is, technically, correct in that it really is the minimum code required to make that specific test pass (go green), although it's clearly a "cheat" since it really doesn't even attempt to perform the function of calculating a factorial.  Of course, now the refactoring part becomes an exercise in "writing the correct functionality" rather than a true refactoring of the implementation.  Obviously, adding additional tests with different parameters will fail and force a refactoring, but you have to start with that one test.

So, my question is, how do you get that balance between "writing the minimum code to pass the test" whilst still keeping it functional and in the spirit of what you're actually trying to achieve?

答:
As long as you only have a single test, then the minimal code needed to pass the test is truly return 120;, and you can easily keep it for that as long as you don't have any more tests.

This allows you to postpone further design until you actually write the tests that exercise OTHER return values of this method.

Please remember that the test is the runnable version of your specification, and if all that specification says is that f(6)=120 then that fits the bill perfectly.


答:
The short answer to your main question is "no".  You cannot write a single-page app in the conventional sense without relying on JavaScript.  The common definition of an SPA is using a combination of rendering on the client-side using DOM manipulation and AJAX calls to provide a fluid, responsive client experience.  By definition, this includes the use of JavaScript.

You could make the argument that Java applets or plugin technologies like SilverLight and Flash provide a similar quality of experience and can involve only a single page load, but this is not generally what folks mean when they talk about SPAs.  Further, plugins are less likely to be installed and active on a user's browser than plain old, ubiquitous JavaScript.

In terms of the goodness or evil of JavaScript, others answers have addressed it well.  JavaScript is now widely accepted and there is little reason to hesitate in using it for web applications, even if they are not SPAs.


问:
Web programming, standard way to deal with a response that takes time to complete
With normal form submission I use the pattern Post / Redirect / Get, when processing the forms.

I have a database application built with Django. I want to allow the users to select a number of items from the database, then launch a computationally intensive task based on those items.

I expect the task to take between 10 minutes and 2 hours to complete.

Is there a standard approach to dealing with requests like this (i.e. that don't return immediately)? Ideally there would be some way to display the progress.

答:
HTTP 202 Accepted

The 202 response is intentionally non-committal. Its purpose is to
  allow a server to accept a request [...] without requiring that the
  user agent's connection to the server persist until the process is
  completed. The entity returned with this response SHOULD include an
  indication of the request's current status and either a pointer to a
  status monitor or some estimate of when the user can expect the
  request to be fulfilled.

The Web is resource-oriented, and so the "pointer to a status monitor" would be a URI to a resource that you've made available. In some specific sense, you might have a database table of jobs with associated status information that the client can GET. The other answers contain useful information about how you might implement the jobs, but I feel your question is about the web - and the answer is yes, HTTP has reasonably well thought out status codes for conveying this kind of information.


问:
How much freedom should a programmer have in choosing a language and framework?
I started working at a company that is primarily C# oriented. We have a few people who like Java and JRuby, but a majority of programmers here like C#. I was hired because I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs.

I have recently started on a project building a web application with a focus on getting a lot of stuff done in a short amount of time. The software lead has dictated that I use mvc4 instead of rails. That might be OK, except I don't know mvc4, I don't know C# and I am the only one responsible for creating the web application server and front-end UI.

Wouldn't it make sense to use a framework that I already know extremely well (Rails) instead of using mvc4? The reasoning behind the decision was that the tech lead doesn't know Jruby/rails and there would be no way to reuse the code.

Counter arguments:

He won't be contributing to the code and is, frankly, not needed on

this project. So, it doesn't really matter if he knows JRuby/rails or not.

We actually can reuse the code since we have a lot of java apps that
JRuby can pull code from and vice-versa. In fact, he has dedicated
some resources to convert a Java library to C#, instead of just
running the Java library on the JRuby on Rails app. All because he
doesn't like Java or JRuby

I have built many web applications, but using something unfamiliar is causing some spin-up and I am unable to build an awesome application in as short of a time as I'm used to. This would be fine; learning new technologies is important in this field. The problem is, for this project we need to get a lot done fast.

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

答:
Turn it around, please. Imagine you were the one hiring a Ruby developer, and they insist on implementing their work in Asp.net/MVC.

What would you say to them? This is our stack, man. Learn to live with it.

The golden rule, here is, she who has the gold makes the rules.


答: You can use methods like post-backs, server-side validation, etc. as fallbacks for non-javascript visitors. It won't be seamless as it requires, at the least, multiple page loads, but it can be done.</p>


答:
Bah. Everybody is wrong.

Be a better dev than those one-platform people are and you'll have a lot more interesting options than they ever will. So, for now, DO learn MVC. And on your own time, learn more about the platforms that really interest you. Build your Node skills. Learn some Django. Pay attention to whatever Java or pre MVC .NET shenanigans you're exposed to and then run away but at least learn enough to be able to criticize and explain how much thought you've put into your barely concealed burning hate prejudice of those platforms. (okay, maybe I'm projecting there)

And now for the important advice. If you continue to hone your specialities while also diversifying your expertise in other areas, you'll eventually be in a place where you can find new work at any time of the year in less than two weeks in any given major city doing stuff that is mostly interesting at least half the time. When you find yourself in this place, don't put up with these jobs where they say they want this and by day two they have you doing THAT with no hope of a reprieve foreseeable in the long-term future. Just politely explain and apologize but no you really didn't want to do THAT and said as much at your interview and then !@#$ing quit and move on when a couple weeks roll by and they've inevitably done nothing to accommodate for the fact that they misrepresented the position to you and refuse to acknowledge that.

But trust me, finding a new gig is always way better than getting seriously irritated and unhappy for any amount of time lasting longer than 5 minutes. But of course, first you have to pay your dues so you can do that. Some people never will. That's why they want everything in the stuff that they know best. And of course other answers aren't really wrong. It does make sense for a .NET shop to go with .NET if they have to maintain the silly thing.

Of course, what doesn't make sense is why they'd diversify with a Rails/JS/UI dev and only have him do MVC apps. But for now. You may need to pick it up and pay your dues. And as I said in comments MVC's really not that bad. A really bad choice given all the options but certainly not the worst. It's pretty straightforward, doesn't throw 10,000 layers of abstraction on top of everything that's actually happening, and doesn't get itself so twisted with the client-side that you'd curse the names of the MS engineers responsible if anybody could be bothered to learn them.

So get to that place where you can leave when you want if you haven't already and you might even find you have a more skeptical eye of things you currently like. You might even find yourself disliking rails as much as I do. Not that there's anything wrong with Ruby (other than its interpreter of course).


答:
Let's see. So right now, I can build apps on the desktop using Roger Wang's node-webkit, write server-side code that just works without fiddling with 18 layers of config and absurdly over-complicated servers that refuse to just do the 'duh' things right out of the box, write phonegap/cordova apps for Android, IOS, Winphone, and several other platforms simultaneously including desktop mostly reusing the same code in Roger Wang's node-webkit (highly recommend btw - thanks Roger). I can write Linux GUIs in JS. I can do damn near anything Microsoft using web technology...

So uh... yes. I would say the answer is yes. But it's not just JS. If you really want to be able to handle UI well, you have to learn the crap out of CSS. Once the crap has been learned out of, you can do damn near anything including performance critical-stuff with a little help from our friends C and C++ bound easily to JS through V8.

And you can't be a Java dev about it and write once and test nowhere. You do actually have to learn the quirks of the platforms you're supporting. There is no multi-platform solution that has negated that but I would argue that web technology and web UI devs have taught the planet how to finally !@#$ing do it right.

So learn more and it will be less difficult. Learn to properly normalize for multi-platform and use OOP to your advantage and you may be shocked at just how maintainable and lean and mean a well-written and non-hackish JS app that handles multiple interpretations of what its code actually means can be. Take a trip down memory lane on Quirksmode. Read the first edition of DOM scripting. Pay a visit to Dean Edwards's site and blow some of the dust off of some his still-completely-relevant-and-awesome ideas. We've been at this "demanding that our JavaScript function properly" thing for quite a while now but I'd say it probably really kicked in when everybody realized just how freaking useful and powerful the DOM + CSS2 + and JavaScript could be (well before people started tinkering with XHR and assigning undue importance to Ajax's contribution to the evolution of the modern web app).

As far as I'm concerned, and I've been exposed to PHP, Python, C#, Java, and Ruby professionally, no language as popular and widespread wraps, adapts and normalizes as well as JS. Nothing. This may have something to do with why it has spread from the client-side browser like wildfire and you're finding yourself irritated that you keep running into it all over the place.


问:
UI design and confirmation paradigm
I just saw this lecture by Spolsky, where he questions the need for choices and confirmation dialogs. At some point he has a MacOS settings window and he mentions that "now some are getting rid of the OK button". The window indeed has no OK (or cancel) button. Changing a setting makes it change, when you're done configuring, you close that window, period.

Being a long time Windows user and a recent Mac owner, the difference is noticeable at first. I looked for the OK button for a while, only to find out, quite naturally and painlessly, that there was none. I expressed satisfaction and went on my merry way.

However, I'm curious to know if this UI design pattern would succeed in the Windows-based world. Granted that if Microsoft brought it out with say Windows-8 (fat chance, I know), people would get used to it eventually. But is there some experience out there of such an approach, of changing the "confirmation paradigm" on a platform where it's so prevalent? Did it leave users (especially the non-technical ones) confused, frustrated, scared, or happy?

TL;DR: Remove OK/cancel confirmation, what happens?

EDIT:

Mac GUI for appearance settings.

答: You said so yourself : you looked for the OK button for a while. Users should find things right away.</p>

Title: UI design and confirmation paradigm


答:
Depending on your situation, it could be dangerous to assume you know why they hired you, and even more so to assume your manager knows that and agrees that hiring people with your skills is a good idea.

I would ask take the advice above and make a business case why you should go with JRuby over C#, maybe your argument and timelines means breaking from the old ways makes sense.  I would not just assume it is okay or not, give the manager or lead the facts and let them make the decision, it is what they are being paid the big bucks for, plus its a bit of CYA.


答:
You probably want some sort of job queue here.  The exact form of such a queue can vary.  But basically your server side script will add a task into a queue.  The tasks in the queue are handled by a completely different process, and mark them complete when finished.  You can then use something like websockets or long polling to 'watch' the queue, and report on task status.

For example, you might make a database table that will function as a queue.  When a request comes in to your server, you insert the necessary task information into that table.  A separate process will poll that table every X seconds/minutes, and when it finds a new entry, it executes the requested job.  When the job is finished, it marks the task as complete in the database.  Meanwhile, inside the browser, you have opened up a connection to your server using either websockets or long polling.  That will poll the queue for the status of the task, and send it back to the end user who can then see what the status of the task is.

Thats a simple table-based solution.  There are of course other ways to handle the specifics (message queues).

Title: Web programming, standard way to deal with a response that takes time to complete

Body:
With normal form submission I use the pattern Post / Redirect / Get, when processing the forms.

I have a database application built with Django. I want to allow the users to select a number of items from the database, then launch a computationally intensive task based on those items.

I expect the task to take between 10 minutes and 2 hours to complete.

Is there a standard approach to dealing with requests like this (i.e. that don't return immediately)? Ideally there would be some way to display the progress.