问:
IOS Variable vs Property
Just started diving into Objective-C and IOS development and was wondering when and the correct location I should be declaring variables/properties. The main piece of code i need explaining is below:

Why and when should i be declaring variables inside the interface statement and why do they have the same variable with _ and then the same one as a property. And then in the implementation they do @synthesize tableView = _tableView (I understand what synthesize does)

Thanks :-)

```<code>@interface ViewController : UIViewController <UITableViewDataSource, UITableViewDelegate>
{
    UITableView *_tableView;
    UIActivityIndicatorView *_activityIndicatorView;
    NSArray *_movies;
}

@property (nonatomic, retain) UITableView *tableView;
@property (nonatomic, retain) UIActivityIndicatorView *activityIndicatorView;
@property (nonatomic, retain) NSArray *movies;
</code>```

答:
First of all, there is no need to declare the instance variables for properties as the statement

```<code>@synthesize var = _iVar;
</code>```

is actually generating an implicit variable named _iVar for you.

You would create properties when you want them to be accessible outside the class like

```<code>YourClass *obj = [[YourClass alloc] init];
obj.yourProperty = somevalue;
</code>```

Properties also relieve you of writing your own getters & setters and take care of much of memory management themselves. Here is something you might wanna read plus other articles linked within the post.

http://cocoawithlove.com/2008/08/in-defense-of-objective-c-20-properties.html

Title: IOS Variable vs Property

Body:
First of all, there is no need to declare the instance variables for properties as the statement

@synthesize var = _iVar;

is actually generating an implicit variable named _iVar for you.

You would create properties when you want them to be accessible outside the class like

YourClass *obj = [[YourClass alloc] init];
obj.yourProperty = somevalue;

Properties also relieve you of writing your own getters & setters and take care of much of memory management themselves. Here is something you might wanna read plus other articles linked within the post.

http://cocoawithlove.com/2008/08/in-defense-of-objective-c-20-properties.html


问:
When designing a job queue, what should determine the scope of a job?
We've got a job queue system that'll cheerfully process any kind of job given to it. We intend to use it to process jobs that each contain 2 tasks:

Job (Pass information from one server to another)

Fetch task (get the data, slowly)

Send task (send the data, comparatively quickly)

The difficulty we're having is that we don't know whether to break the tasks into separate jobs, or process the job in one go.

Are there any best practices or useful references on this subject? Is there some obvious benefit to a method that we're missing?

So far we can see these benefits for each method:

Split

Job lease length reflects job length: Rather than total of two

Finer granularity on recovery: If we lose outgoing connectivity we can tell them all to retry

The starting state of the second task is saved to job history: Helps with debugging (although similar logging could be added in single task method)

Single

Single job to be scheduled: Less processing overhead

Data not stale on recovery: If the outgoing downtime is quite long, the pending Send jobs could be outdated

答:
Which of these represents the minimum useful addition to the work that your application does? Usually I take the view that a job on a queue should represent a useful work unit: whether it completes or cancels, you should end up with the system in a consistent state.

That situation is mostly defined by your problem domain, so it's not something for which a general answer exists. Sometimes there are architectural limitations that force you to split up work in unnatural ways. An example is in a GUI application, where you probably aim to do all of your application's work concurrently but then update the user interface on a dedicated thread. That means you have to split your work ("do something useful and show the user I did it") into those two steps ("do something useful, and show the user I did it"). In fact in this case it's not too much of a problem, because if the app quits before updating the UI it's likely that the user didn't want to know about the work you'd done anyway.

If the "minimum useful addition" is too small, then I think about batching them to reduce the amount of time spent in job-submission overhead. This definition of "too small" is something that requires measurement for your work and in your environment - it depends more on the architecture than on your problem. Profile your application: if you're spending a significant amount of time adding and removing things from queues or creating and destroying threads, you're doing too little work in each operation.

ContentLicense: CC BY-SA 3.0


问:
Small assembly language project for practice
I am learning assembly language for x86 architecture. But, i am unable to find any practice problems so that i can test my skills. Can you suggest me some practice problems or some small assembly language project to improve my skills.??

thanks in advance

答: One of the first things I did when learning/playing around with it was a blitting routine, I then added transparency and eventually shadows by specifying colours that would be transparent or a shadow.</p>


问:
How many types of programming languages are there?
Basically, I want to learn lots of programming languages to become a great programmer.  I know only a handful to depth and I was hoping someone could elaborate on how many classes or types of programming languages there are.  Like how you would lump them together if you had to learn them in groups.

Coming from a Java background, I'm familiar with static typing, but I know that in addition to dynamic typing there has to be such variety in available languages that I would love to see a categorical breakdown if possible.

答:
There are different ways to answer this, but in terms they can be categorized as:

Machine language: Machine language is a low-level programming language. It is easily understood by computers but difficult to read by people. This is why people use higher level programming languages. Programs written in high-level languages are also either compiled and/or interpreted into machine language so that computers can execute them.

Assembly language: Assembly language is a representation of machine language. In other words, each assembly language instruction translates to a machine language instruction. Though assembly language statements are readable, the statements are still low-level. A disadvantage of assembly language is that it is not portable, because each platform comes with a particular Assembly Language.

High-level language: High-level languages are what most programmers use nowadays. Languages such as C, C++ and Java are all high-level languages. Advantages of high-level languages are that they are very readable and portable. A disadvantage of high-level languages is that they are less powerful than Assembly Languages. Because a single statement in a high-level language is translated into many machine language statements.

High-level languages can further be classified as:

Functional languages: In Functional language, a program is divided into function definitions. Functional languages are a kind of declarative language. They are mostly based on the typed lambda-calculus with constants. Some of the famous Function languages are Scala, F#, Clojure and Lisp.

Procedural languages: In Procedural Languages, a program is written in a  sequences of steps that should be followed to produce a result. COBOL, FORTRAN and C are some Procedural languages.

Object Oriented Programming languages: In OOP languages, a program is divided into Object that contain data as well as methods that operate on the data. Java, C# and C++ are OOP languages.

Logic Programming languages: Logic Languages are used to create programs that enables the computer to reason logically. eg: Logic language

For in-depth study, check out:

http://en.wikipedia.org/wiki/List_of_programming_languages_by_type and,

http://en.wikipedia.org/wiki/Programming_paradigm

ContentLicense: CC BY-SA 2.5


问:
Learn programming backwards, or "so I failed the FizzBuzz test. Now what?"

A Little Background

I'm 28 today, and I've never had any formal training in software development, but I do have two higher education degrees equivalent to a B.A in Public Relations and an Executive MBA focused on Project Management. I've worked on those fields for about 6 years total an then, 2,5 years ago I quit/lost my job and decided to shift directions.

After a month thinking things through I decided to start freelancing developing small websites in WordPress. I self-learned my way into it and today I can say I run a humble but successful career developing themes and plugins from scratch for my clients - mostly agencies outsourcing some of their dev work for medium/large websites.

But sometimes I just feel that not having studied enough math, or not having a formal understanding of things really holds me behind when I have to compete or work with more experienced developers. I'm constantly looking for ways to learn more but I seem to lack the basics.

Unfortunately, spending 4 more years in Computer Science is not an option right now, so I'm trying to learn all I can from books and online resources. This method is never going to have NASA employ me but I really don't care right now. My goal is to first pass the bar and to be able to call myself a real programmer.

I'm currently spending my spare time studying Java For Programmers (to get a hold on a language everyone says is difficult/demanding), reading excerpts of Code Complete (to get hold of best practices) and also Code: The Hidden Language of Computer Hardware and Software (to grasp the inner workings of computers).

TL;DR

So, my current situation is this: I'm basically capable of writing any complete system in PHP (with the help of Google and a few books), integrating Ajax, SQL and whatnot, and maybe a little slower than an experienced dev would expect due to all the research involved.

But I was stranded yesterday trying to figure out (not Google) a solution for the FizzBuzz test because I didn't have the if($n1 % $n2 == 0) method modulus operator memorized.

What would you suggest as a good way to solve this dilemma? What subjects/books should I study that would get me solving problems faster and maybe more "in a programmers way"?

EDIT - Seems that there was some confusion about what did I not know to solve FizzBuzz.

Maybe I didn't express myself right: I knew the steps needed to solve the problem. What I didn't memorize was the modulus operator. The problem was in transposing basic math to the program, not in knowing basic math.

I took the test for fun, after reading about it on Coding Horror. I just decided it was a good base-comparison line between me and formally-trained devs.

I just used this as an example of how not having dealt with math in a computer environment before makes me lose time looking up basic things like modulus operators to be able to solve simple problems.

答:
I don't think I'd refuse to recommend someone for hire because they did not know it was the modulus operator provided that:

They knew that it was an operator of some sort.

They could tell me what "modulus" was once I prompted them.

It's not always (though usually) %, and some languages are weird. And hell, after a decade I can't honestly say that I know all of the perl operators (and what's the spaceship one do again?) nor can I always remember the bitwise operators perfectly. It's been a few years since I did anything that would even require those.

What might make me hesitate to recommend someone would be if it caused them to have some panic attack over missing that question/test. That might give me the impression they were a little too green (unless it was a very entry level position). No one needs someone who does (or feels the need to) memorize those things. You need someone who understands far broader concepts. No one's going to care if you look that up on google, but you'll have to be confident in the interview that knowing % was no big deal and also that you know to use "operator" as a keyword when you do a quick google search.

Also, this is just an idea... but if your local community college has a compsci program, your other credits would all transfer, and you'd likely only need about 20 credits for the 2 year degree. Could almost finish that in a semester. They'd have you do a data structures course, also hopefully algorithms... might make you a bit stronger.


问:
For what purpose I can use c++ to increase my skills?
I want to learn new things. Initially I was a PHP programmer. Then I thought it was not enough.

Then I started learning Java thing. It took me 3 months to learn.

Java, J2EE, Spring, Hibernte, Spring Security, Spring Roo and many design patterns MVC and stuff like AOP, DI . I never knew that before but I got the idea what J2EE. After 3 months, I just made a simple page with Registration form integrated with Spring Security.

I wanted to make one complete project in it but that was too much for me and I didn't want spend more time on it as then i need to host that as well so I left that.

Then I started learning Python and made few sys admin scripts and then Django and now I am finishing a complete web app in Python.

Now I want to learn C++, but before that I need to find out what i can do with it. Just like I know Python is very useful because I have my own servers so I can write scripting and websites so Python is good for me.

But I am confused in which areas C++ can help me.

I don't want to end up like I have with Java where either I have big projects or nothing for day to day use.

答:
Before learning any language decide for yourself in what direction you want to work. Whether it is web development, System Programming, Business Applications, Mobile App Development, etc.
After you solve this puzzle, you will be able to pick languages in that category. And when its done, don't give up, even if software projects take longer.</p>


问:
I've inherited 200K lines of spaghetti code -- what now?
I hope this isn't too general of a question; I could really use some seasoned advice.

I am newly employed as the sole "SW Engineer" in a fairly small shop of scientists who have spent the last 10-20 years cobbling together a vast code base. (It was written in a virtually obsolete language: G2 -- think Pascal with graphics). The program itself is a physical model of a complex chemical processing plant; the team that wrote it have incredibly deep domain knowledge but little or no formal training in programming fundamentals. They've recently learned some hard lessons about the consequences of non-existant configuration management. Their maintenance efforts are also greatly hampered by the vast accumulation of undocumented "sludge" in the code itself. I will spare you the "politics" of the situation (there's always politics!), but suffice to say, there is not a consensus of opinion about what is needed for the path ahead.

They have asked me to begin presenting to the team some of the principles of modern software development. They want me to introduce some of the industry-standard practices and strategies regarding coding conventions, lifecycle management, high-level design patterns, and source control. Frankly, it's a fairly daunting task and I'm not sure where to begin.

Initially, I'm inclined to tutor them in some of the central concepts of The Pragmatic Programmer, or Fowler's Refactoring ("Code Smells", etc). I also hope to introduce a number of Agile methodologies. But ultimately, to be effective, I think I'm going to need to hone in on 5-7 core fundamentals; in other words, what are the most important principles or practices that they can realistically start implementing that will give them the most "bang for the buck".

So that's my question: What would you include in your list of the most effective strategies to help straighten out the spaghetti (and prevent it in the future)?

答:
After looking into Gensym G2 for a bit it looks like the way to approach this problem is going to be highly dependent upon how much of the code base looks like this:

or this:

versus this, courtesy of 99 Bottles of Beer:

```<code>beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall";
        end
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall";
           end
    end
end
</code>```

In the case of the latter you are working with source code which is effectively a known quantity and some of the other answers offer some very sage advice for dealing with it.

If most of the code base is the latter, or even if a sizable chunk is, you are going to be running into the interesting problem of having code that likely cannot be refactored due to being extremely specialized, or worse yet, something that looks like it may be removable, but unless it is properly documented, you don't know if you are removing critical code (think something along the lines of a scram operation) that doesn't appear to be so at first glance.

Although obviously your first priority is going to be getting some sort of version control online, as pointed out ElYusubov, and it does appear that version control has been supported since version 8.3. Since G2 is a combination of a couple different language methodologies you would likely find it to be most effective to use the version control that is provided with it as opposed to trying to find something else and getting it to work.

Next, although some would likely advocate for starting to refactor, I'm a strong advocate of making sure you fully understand the system you are working with before you start touching any of the code, especially when dealing with code and visual diagrams that developed by developers with out formal training (or background) in software engineering methodologies. The reasoning for this is several fold, but most obvious reason is that you are working with an application that potentially has over 100 person-years worth of work put into it and you really need to make sure you know what it is doing and how much documentation there is in it. As you didn't say which industry the system is deployed to, based upon what I have been reading about G2 it appears it is safe to assume that it is likely a mission critical application that may even hold a potential for also having life safety implications. Thus, understanding exactly what it is doing is going to be very important. It there is code that is not documented work with the others on the team to make sure that documentation is put into place to make sure people can determine what the code does.

Next start wrapping unit tests around as much of the code base and visual diagrams that you can. I must admit to some ignorance with regards to how to do this with G2 but it might almost be worth creating your own testing framework to get this in place. This is also an ideal time to start introducing the other members of the team to get them use to some of the more rigorous engineering practices involved with code quality (i.e. all code must have unit tests and documentation).

Once you have unit tests in place on a fair amount of the code, you can start approaching refactoring on manner such as that suggested by haylem; however, remember to keep in mind that you are dealing with something that is meant for developing expert systems and refactoring it might be an uphill battle. This is actually an environment where there is something to be said for not writing extremely generic code at times.

Finally, make sure you pay close attention to what the other team members say though, just because the code and diagram quality is not the best doesn't necessarily reflect poorly upon them. Ultimately, for the time being they are likely to know more about what the application does than you which is why it is all the more important for you to sit down and make sure you understand what it does before making sweeping changes as well.

Body:
After looking into Gensym G2 for a bit it looks like the way to approach this problem is going to be highly dependent upon how much of the code base looks like this:

or this:

versus this, courtesy of 99 Bottles of Beer:

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall";
        end
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall";
           end
    end
end

In the case of the latter you are working with source code which is effectively a known quantity and some of the other answers offer some very sage advice for dealing with it.

If most of the code base is the latter, or even if a sizable chunk is, you are going to be running into the interesting problem of having code that likely cannot be refactored due to being extremely specialized, or worse yet, something that looks like it may be removable, but unless it is properly documented, you don't know if you are removing critical code (think something along the lines of a scram operation) that doesn't appear to be so at first glance.

Although obviously your first priority is going to be getting some sort of version control online, as pointed out ElYusubov, and it does appear that version control has been supported since version 8.3. Since G2 is a combination of a couple different language methodologies you would likely find it to be most effective to use the version control that is provided with it as opposed to trying to find something else and getting it to work.

Next, although some would likely advocate for starting to refactor, I'm a strong advocate of making sure you fully understand the system you are working with before you start touching any of the code, especially when dealing with code and visual diagrams that developed by developers with out formal training (or background) in software engineering methodologies. The reasoning for this is several fold, but most obvious reason is that you are working with an application that potentially has over 100 person-years worth of work put into it and you really need to make sure you know what it is doing and how much documentation there is in it. As you didn't say which industry the system is deployed to, based upon what I have been reading about G2 it appears it is safe to assume that it is likely a mission critical application that may even hold a potential for also having life safety implications. Thus, understanding exactly what it is doing is going to be very important. It there is code that is not documented work with the others on the team to make sure that documentation is put into place to make sure people can determine what the code does.

Next start wrapping unit tests around as much of the code base and visual diagrams that you can. I must admit to some ignorance with regards to how to do this with G2 but it might almost be worth creating your own testing framework to get this in place. This is also an ideal time to start introducing the other members of the team to get them use to some of the more rigorous engineering practices involved with code quality (i.e. all code must have unit tests and documentation).

Once you have unit tests in place on a fair amount of the code, you can start approaching refactoring on manner such as that suggested by haylem; however, remember to keep in mind that you are dealing with something that is meant for developing expert systems and refactoring it might be an uphill battle. This is actually an environment where there is something to be said for not writing extremely generic code at times.

Finally, make sure you pay close attention to what the other team members say though, just because the code and diagram quality is not the best doesn't necessarily reflect poorly upon them. Ultimately, for the time being they are likely to know more about what the application does than you which is why it is all the more important for you to sit down and make sure you understand what it does before making sweeping changes as well.


问:
Company PC refresh, laptop or desktop?
My company is getting PC refreshes with a choice of to have a desktop or laptop.  Each one seems to have its pros and cons. Would you want the flexibility and freedom of the laptop but take the risk of working extra hours at home? Or a desktop limited to one place, but not having to worry about taking work home and disrupting home time?

I'm not asking what would be better for coding, but more for convenience and productivity.  I currently have a desktop and work about 8 to 9 hours a day, with only coming in on the weekends for when we get behind on major deadlines. I love developing but I also have quite a busy life after work. I feel that having a work laptop will only haze the line of work and home.

答:
I like to use a laptop that is docked to a large monitor with a real keyboard and mouse. My first year in graduate school I used a laptop without a monitor and ended up seriously hurting my neck, shoulders, and back.

The bottom line is that a laptop alone cannot be used for any extended period without causing major problems with your posture. Either your neck is bent, or your arms are in an awkward position. When I was young (high school and college), I could get away with only using a laptop. But things quickly caught up with me when I got older.

If you go with a laptop with a docking solution, then that's probably the best of both worlds.

However, be aware of your company's policies. You may have to install some draconian, no-name software company's encryption or anti-virus software that might render your machine useless for anything but Office.

Title: Company PC refresh, laptop or desktop?


问:
Is committing/checking in code everyday a good practice?
I've been reading Martin Fowler's note on Continuous Integration and he lists as a must "Everyone Commits To the Mainline Every Day".

I do not like to commit code unless the section I'm working on is complete and that in practice I commit my code every three days: one day to investigate/reproduce the task and make some preliminary changes, a second day to complete the changes, and a third day to write the tests and clean it up^ for submission. I would not feel comfortable submitting the code sooner.

Now, I pull changes from the repository and integrate them locally usually twice a day, but I do not commit that often unless I can carve out a smaller piece of work.

Question: is committing everyday such a good practice that I should change my workflow to accomodate it, or it is not that advisable?

Edit: I guess I should have clarified that I meant "commit" in the CVS meaning of it (aka "push") since that is likely what Fowler would have meant in 2006 when he wrote this.

^ The order is more arbitrary and depends on the task, my point was to illustrate the time span and activities, not the exact sequence.

答:
I commit code several times a day. Whenever I reach a point where the code is complete enough to compile and doesn't break other things, it goes in.

You should look at breaking up your work so you can safely check-in a few times a day.

The rationales for this are two:

Any work that is not checked in may be lost - your computer may have a catastrophic failure. In this case, the longer you wait, the more work you lose.

The more work you do without checking in, the more code others will need to integrate when you finally decide that it bakes. This introduces more chances of conflicts and merge issues.


答:
Slavishly adhering to any methodology or practice without understanding the reasons behind it is never a good idea.  That's where cargo-cult programming comes from.

Therefore, "I should commit every day because Martin Fowler said so" is just stupid. And sometimes it's impractical too.  If you're working on a complicated new feature, you might not reach a point where it's worth checking in until you've already worked on it for a few days.

This doesn't mean you should make sure everything's perfect before checking it in.  That's a good way to lose work if something goes wrong.  The correct thing to do is to develop and use good judgment on the matter.  Rules of thumb can only help you so much.

Title: Is committing/checking in code everyday a good practice?

Body:
I've been reading Martin Fowler's note on Continuous Integration and he lists as a must "Everyone Commits To the Mainline Every Day".

I do not like to commit code unless the section I'm working on is complete and that in practice I commit my code every three days: one day to investigate/reproduce the task and make some preliminary changes, a second day to complete the changes, and a third day to write the tests and clean it up^ for submission. I would not feel comfortable submitting the code sooner.

Now, I pull changes from the repository and integrate them locally usually twice a day, but I do not commit that often unless I can carve out a smaller piece of work.

Question: is committing everyday such a good practice that I should change my workflow to accomodate it, or it is not that advisable?

Edit: I guess I should have clarified that I meant "commit" in the CVS meaning of it (aka "push") since that is likely what Fowler would have meant in 2006 when he wrote this.

^ The order is more arbitrary and depends on the task, my point was to illustrate the time span and activities, not the exact sequence.


答:
Oded gave two important reasons to commit code as frequently as possible. I'll add a few more:

While working on your piece of code, other might need some functions on that code. They shouldn't wait 6 days to get it. In this case my colleagues usually create a prototype in my piece of code, commit it, I add the body and commit it again. And this is usually done in a few hours.

The 'common' code is for everyone to see every change as soon as possible. If the piece of code you're working on is totally separate from others' work and you will not have them wait, then it is recommended to create a branch for you to work on, and then, if everything is successful, merge it to the mainline.


答:
I do not agree with this rule and I agree with what Mason Wheeler said. I would
like to add a few ideas.

I try to commit every time I have a meaningful
change to commit: this can be several times a day if I fix several small bugs,
or once a week if I am working on a larger piece of software that cannot be
used by the rest of the code in any meaningful way until it reaches a
consistent state.

Also, I interpret committing as publishing a meaningful revision that
contributes new functionality to the code base.
I think one should try to clean up the code before committing so that
other developers can understand the meaning and the purpose of the change
when they look at the revision history. The fewer changes other developers
see in the history, the better: when I look at the revision history I want
to see increments that add some meaningful functionality; I am not interested
in every small idea each developer had and wanted to try out before they
reached the solution.

Furthermore, I do not think it is a good idea to use the SVN server
(or whatever version control system) as a backup facility to which
the current snapshot of the code is committed (provided that it compiles):
you can use a USB stick or an external USB-drive or a network disk
to mirror your current code so that it does not get lost if your
computer breaks down. Revision control and data backup are two different
things. Publishing a revision is not the same as saving a snapshot
of your code.

Finally, I think that it should not be a problem to commit every now
and then (i.e. only when one is really satisfied with the current state of
the code) and avoiding merge conflicts is not a good justification for
committing (too) often.
Many merge conflicts happen when different people work on the same files
at the same time, which is a bad practice (see e.g. this article, point
7).
Merge conflicts should be reduced by splitting a project into modules with
clear interfaces and as few dependencies as possible, and by coordinating
the work of developers so that the code they work on overlaps as little
as possible.

Just my 2 cents.

EDIT

Another reason against premature commits that came to my mind is that
a (very) buggy version cannot be tested. If you are committing on the trunk
and your test team is testing every day, they might have no testable version
for a few hours (or for a day). Even if you do not try to fix the bug and
just revert your changes, a rebuild can take a couple of hours. With, say,
five testers working in your team, you have wasted 5 x 2 = 10 hours of
the team's time due to inactivity. It happened to me once so I really try
to avoid premature commits in the name of commit as soon as possible.


问:
What OO Design to use ( is there a Design Pattern )?
I have two objects that represent a 'Bar/Club' ( a place where you drink/socialise).

In one scenario I need the bar name, address, distance, slogon

In another scenario I need the bar name, address, website url, logo

So I've got two objects representing the same thing but with different fields.

I like to use immutable objects, so all the fields are set from the constructor.

One option is to have two constructors and null the other fields i.e:

```<code>class Bar {
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
          this.url = null;
     }

     public Bar(String name, Url url){
          this.name = name;
          this.distance = null;
          this.url = url;
     }

     // getters
}
</code>```

I don't like this as you would have to null check when you use the getters

In my real example the first scenario has 3 fields and the second scenario has about 10, so it would be a real pain having two constructors, the amount of fields I would have to declare null and then when the object are in use you wouldn't know which Bar you where using and so what fields would be null and what wouldn't.

What other options do I have?

Two classes called BarPreview and Bar?

Some type of inheritance / interface?

Something else that is awesome?

答:
You need a base class, for example, Location which has a name and an address.  Now, you have two classes Bar and BarPreview extend the base class Location.  In each class you initialize the super class common variables and then your unique variables:

```<code>public class Location {
    protected final String name;
    protected final String address:

    public Location (String locName, String locAddress) {
    name = locName;
    address = locAddress
    }

}

public class Bar extends Location {
    private final int dist;
    private final String slogan;

    public Bar(String barName, String barAddress,
               int distance, String barSlogan) {
    super(locName, locAddress);
    dist = distance;
    slogan = barSlogan;
    }
}
</code>```

And similar for the BarPreview class..

If it makes you sleep better at night, replace all instances of Location in my code with AnythingYouThinkWouldBeAnAppropriateNameForAThingThatABarExtendsSuchAsFoodServicePlace -- ffs.

Body:
You need a base class, for example, Location which has a name and an address.  Now, you have two classes Bar and BarPreview extend the base class Location.  In each class you initialize the super class common variables and then your unique variables:

public class Location {
    protected final String name;
    protected final String address:

    public Location (String locName, String locAddress) {
    name = locName;
    address = locAddress
    }

}

public class Bar extends Location {
    private final int dist;
    private final String slogan;

    public Bar(String barName, String barAddress,
               int distance, String barSlogan) {
    super(locName, locAddress);
    dist = distance;
    slogan = barSlogan;
    }
}

And similar for the BarPreview class..

If it makes you sleep better at night, replace all instances of Location in my code with AnythingYouThinkWouldBeAnAppropriateNameForAThingThatABarExtendsSuchAsFoodServicePlace -- ffs.


答:
The Builder Pattern (or something close to it) might be of use here.

Having immutable objects is an admirable thing, but the reality is that with Reflection in Java, nothing is truly safe ;-).

Title: What OO Design to use ( is there a Design Pattern )?

Body:
I have two objects that represent a 'Bar/Club' ( a place where you drink/socialise).

In one scenario I need the bar name, address, distance, slogon

In another scenario I need the bar name, address, website url, logo

So I've got two objects representing the same thing but with different fields.

I like to use immutable objects, so all the fields are set from the constructor.

One option is to have two constructors and null the other fields i.e:

```<code>class Bar {
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
          this.url = null;
     }

     public Bar(String name, Url url){
          this.name = name;
          this.distance = null;
          this.url = url;
     }

     // getters
}
</code>```

I don't like this as you would have to null check when you use the getters

In my real example the first scenario has 3 fields and the second scenario has about 10, so it would be a real pain having two constructors, the amount of fields I would have to declare null and then when the object are in use you wouldn't know which Bar you where using and so what fields would be null and what wouldn't.

What other options do I have?

Two classes called BarPreview and Bar?

Some type of inheritance / interface?

Something else that is awesome?


答:
My thoughts:

A "Bar", as represented in your domain, has all of the things that may be needed in either place: name, address, URL, logo, slogan, and "distance" (I'm guessing from the requester's location). Therefore, in your domain, there should be one "Bar" class that is the authoritative source of data for one bar, no matter where the data will be used later. This class should be mutable, so that changes to the bar's data can be made and saved when necessary.

However, you have two places in which this Bar object's data is needed, and both of them only need a subset (and you don't want that data to be changed). The usual answer is a "data transfer object" or DTO; a POJO (plain ol' Java object) containing the immutable property getters. These DTOs can be produced by calling a method on the main Bar domain object: "toScenario1DTO()" and "toScenario2DTO()"; the results being a hydrated DTO (meaning that you only need to use the long, complicated constructor in one place).

If you ever needed to send data back to the main domain class (to update it; what's the point of data if you can't change it as needed to reflect the current state of the real world?), you could construct one of the DTOs, or use a new mutable DTO, and hand it back to the Bar class using an "updateFromDto()" method.

EDIT: to provide an example:

```<code>public class Bar {
     private String name;
     private Address address;
     private Distance distance;
     private Url url;
     private Image logo;
     private string Slogan;

     public OnlineBarDto ToOnlineDto()
     {
         return new OnlineBarDto(name, address, url, logo);
     }

     public PhysicalBarDto ToPhysicalDto()
     {
         return new PhysicalBarDto(name, address, distance, slogan);
     }

     public void UpdateFromDto(PhysicalBarDto dto)
     {
         //validation logic here, or mixed into assignments

         name = dto.Name;
         address = dto.Address;
         distance = dto.Distance;
         slogan = dto.Slogan;
     }

     public void UpdateFromDto(OnlineBarDto dto)
     {
         //Validate DTO fields before performing assignments

         name = dto.Name;
         address = dto.Address;
         url= dto.Url;
         logo = dto.Logo;
     }

     // getters/setters - As necessary within the model and data access layers;
     // other classes can update the model using DTOs, forcing validation.
}

public class PhysicalBarDto
{
     public final String Name;
     public final Address Address;
     public final Distance Distance;
     public final String Slogan;

     public PhysicalBarDto(string Name, Address address, Distance distance, string slogan)
     { //set instance fields using parameter fields; you know the drill }
}

public class OnlineBarDto
{
     public final String Name;
     public final Address Address;
     public final Image Logo;
     public final Url Url;

     public OnlineBarDto(string Name, Address address, Url url, Image logo)
     { //ditto }
}
</code>```

The Address, Distance and Url classes should either be immutable themselves, or when used in the DTOs they should be replaced with immutable counterparts.

Body:
My thoughts:

A "Bar", as represented in your domain, has all of the things that may be needed in either place: name, address, URL, logo, slogan, and "distance" (I'm guessing from the requester's location). Therefore, in your domain, there should be one "Bar" class that is the authoritative source of data for one bar, no matter where the data will be used later. This class should be mutable, so that changes to the bar's data can be made and saved when necessary.

However, you have two places in which this Bar object's data is needed, and both of them only need a subset (and you don't want that data to be changed). The usual answer is a "data transfer object" or DTO; a POJO (plain ol' Java object) containing the immutable property getters. These DTOs can be produced by calling a method on the main Bar domain object: "toScenario1DTO()" and "toScenario2DTO()"; the results being a hydrated DTO (meaning that you only need to use the long, complicated constructor in one place).

If you ever needed to send data back to the main domain class (to update it; what's the point of data if you can't change it as needed to reflect the current state of the real world?), you could construct one of the DTOs, or use a new mutable DTO, and hand it back to the Bar class using an "updateFromDto()" method.

EDIT: to provide an example:

public class Bar {
     private String name;
     private Address address;
     private Distance distance;
     private Url url;
     private Image logo;
     private string Slogan;

     public OnlineBarDto ToOnlineDto()
     {
         return new OnlineBarDto(name, address, url, logo);
     }

     public PhysicalBarDto ToPhysicalDto()
     {
         return new PhysicalBarDto(name, address, distance, slogan);
     }

     public void UpdateFromDto(PhysicalBarDto dto)
     {
         //validation logic here, or mixed into assignments

         name = dto.Name;
         address = dto.Address;
         distance = dto.Distance;
         slogan = dto.Slogan;
     }

     public void UpdateFromDto(OnlineBarDto dto)
     {
         //Validate DTO fields before performing assignments

         name = dto.Name;
         address = dto.Address;
         url= dto.Url;
         logo = dto.Logo;
     }

     // getters/setters - As necessary within the model and data access layers;
     // other classes can update the model using DTOs, forcing validation.
}

public class PhysicalBarDto
{
     public final String Name;
     public final Address Address;
     public final Distance Distance;
     public final String Slogan;

     public PhysicalBarDto(string Name, Address address, Distance distance, string slogan)
     { //set instance fields using parameter fields; you know the drill }
}

public class OnlineBarDto
{
     public final String Name;
     public final Address Address;
     public final Image Logo;
     public final Url Url;

     public OnlineBarDto(string Name, Address address, Url url, Image logo)
     { //ditto }
}

The Address, Distance and Url classes should either be immutable themselves, or when used in the DTOs they should be replaced with immutable counterparts.


答:
Appropriate Pattern

What you are looking for is most commonly referred to as the Null Object Pattern. If you don't like the name you can call it the Undefined Value Pattern, same semantics different label. Sometimes this pattern is called Poison Pill Pattern.

In all these cases, the Object is a replacement or stand in for a Default Value instead of null. It doesn't replace the semantic ofnullbut makes it easier to work with the data model in a more predictable way becausenull` should now never be a valid state.

It is a Pattern where you reserve a special instance of a given class to represent an otherwise null option as a Default Value. This way you don't have to check against null, you can check identity against your known NullObject instance. You can safely call methods on it and the like without worrying about NullPointerExceptions.

This way you replace your null assignments with their representative NullObject instances and you are done.

Proper Object Oriented Analysis

This way you can have a common Interface for polymorphism and still have protection from having to worry about the absence of data in the specific implementations of the interface. So some Bar may not have web presence, and some might not have location data at the time of construction. Null Object Patter lets you provide  a default value for each of these that is a marker for that data that says the same thing, nothing has been supplied here, without having the deal with checking for NullPointerException all over the place.

Proper Object Oriented Design

First have an abstract implementation that is a super set of all the attributes that both Bar and Club share.

```<code>class abstract Establishment
{
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(final String name, final Distance distance, final Url url)
     {
          this.name = name;
          this.distance = distance;
          this.url = url;
     }

     public Bar(final String name, final Distance distance)
     {
          this(name, distance, Url.UNKOWN_VALUE);
     }

     public Bar(final String name, final Url url)
     {
          this(name, Distance.UNKNOWN_VALUE, url);
     }

     // other code
}
</code>```

Then you can implement sub classes of this Establishment class and add just the specific things you need for each of the Bar and Club classes that doesn't apply to the other.

Persistence

These placeholder objects if constructed correctly can be transparently stored in a database without any special handling as well.

Future Proof

If you decided to jump on the Inversion of Control / Dependency Injection bandwagon later one, this pattern makes that easy to inject these marker objects as well.

Body:
Appropriate Pattern

What you are looking for is most commonly referred to as the Null Object Pattern. If you don't like the name you can call it the Undefined Value Pattern, same semantics different label. Sometimes this pattern is called Poison Pill Pattern.

In all these cases, the Object is a replacement or stand in for a Default Value instead of null. It doesn't replace the semantic ofnullbut makes it easier to work with the data model in a more predictable way becausenull` should now never be a valid state.

It is a Pattern where you reserve a special instance of a given class to represent an otherwise null option as a Default Value. This way you don't have to check against null, you can check identity against your known NullObject instance. You can safely call methods on it and the like without worrying about NullPointerExceptions.

This way you replace your null assignments with their representative NullObject instances and you are done.

Proper Object Oriented Analysis

This way you can have a common Interface for polymorphism and still have protection from having to worry about the absence of data in the specific implementations of the interface. So some Bar may not have web presence, and some might not have location data at the time of construction. Null Object Patter lets you provide  a default value for each of these that is a marker for that data that says the same thing, nothing has been supplied here, without having the deal with checking for NullPointerException all over the place.

Proper Object Oriented Design

First have an abstract implementation that is a super set of all the attributes that both Bar and Club share.

class abstract Establishment
{
     private final String name;
     private final Distance distance;
     private final Url url;

     public Bar(final String name, final Distance distance, final Url url)
     {
          this.name = name;
          this.distance = distance;
          this.url = url;
     }

     public Bar(final String name, final Distance distance)
     {
          this(name, distance, Url.UNKOWN_VALUE);
     }

     public Bar(final String name, final Url url)
     {
          this(name, Distance.UNKNOWN_VALUE, url);
     }

     // other code
}

Then you can implement sub classes of this Establishment class and add just the specific things you need for each of the Bar and Club classes that doesn't apply to the other.

Persistence

These placeholder objects if constructed correctly can be transparently stored in a database without any special handling as well.

Future Proof

If you decided to jump on the Inversion of Control / Dependency Injection bandwagon later one, this pattern makes that easy to inject these marker objects as well.


答:
There's really no need to overcomplicate this. You need two different kinds of object? Make two classes.

```<code>class OnlineBar {
     private final String name;
     private final Url url;
     public OnlineBar(String name, Url url){
          this.name = name;
          this.url = url;
     }

     // ...
}
class PhysicalBar {
     private final String name;
     private final Distance distance;
     public PhysicalBar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
     }
     //...
}
</code>```

If you need to operate on them equally, consider adding an interface, or using reflection.

Body:
There's really no need to overcomplicate this. You need two different kinds of object? Make two classes.

class OnlineBar {
     private final String name;
     private final Url url;
     public OnlineBar(String name, Url url){
          this.name = name;
          this.url = url;
     }

     // ...
}
class PhysicalBar {
     private final String name;
     private final Distance distance;
     public PhysicalBar(String name, Distance distance){
          this.name = name;
          this.distance = distance;
     }
     //...
}

If you need to operate on them equally, consider adding an interface, or using reflection.


问:
Software Design Idea for multi tier architecture
I am currently investigating multi tier architecture design for a web based application in MVC3. I already have an architecture but not sure if its the best I can do in terms of extendability and performance.

The current architecure has following components

DataTier (Contains EF POCO objects)

DomainModel (Contains Domain related objects)

Global (Among other common things it contains Repository objects for CRUD to DB)

Business Layer (Business Logic and Interaction between Data and Client and CRUD using repository)

Web(Client) (which talks to DomainModel and Business but also have its own ViewModels for Create and Edit Views for e.g.)

Note: I am using ValueInjector for convering one type of entity to another. (which is proving an overhead in this desing. I really dont like over doing this.)

My question is am I having too many tiers in the above architecure?
Do I really need domain model? (I think I do when I exposes my Business Logic via WCF to external clients).

What is happening is that for a simple database insert it

(1) create ViewModel

(2) Convert ViewModel to DomainModel for Business to understand

(3) Business Convert it to DataModel for Repository and then data comes back in the same order.

Few things to consider,

I am not looking for a perfect architecure solution as it does not exits.
I am looking for something that is scalable.
It should resuable (for e.g. using design patterns ,interfaces, inheritance etc.)
Each Layers should be easily testable.

Any suggestions or comments is much appriciated.

Thanks,

答:
I think that repositories and the domain model could be collapsed into into one tier. Repositories are supposed to hide low-level CRUD logic from clients (http://martinfowler.com/eaaCatalog/repository.html). Queries to them should return domain objects. I would even say that repositories and the domain model form the contract of the data access tier. The business model should know only this contract. Whether you consider it its own tier is up to you and your requirements.

It also depends on your requirements, whether it's worth it to have your own business logic tier. If you have different clients, definitely yes. Let all your clients access the business tier, which in turn accesses the data access tier through a facade, which knows and queries the repositories and returns domain objects.

If you have only one client, but e.g. your business logic involves resource intensive computations or you have certain security concerns, it might still be appropriate to have a dedicated business layer, which encapsulates that. Otherwise you might include business logic into a (well-specified) area on the client side. It depends...

OwnerDisplayName: activebiz


答:
The most important principles for working in such a situation are:

Be patient. A hole which took 20 years to dig isn't going to be filled in in a few weeks.

Be positive. Resist the temptation to complain and grumble.

Be pragmatic. Look at a positive change you can accomplish in a day, and do that, today.  Got a version control system yet? Implement it and train people. Then look and see if you can automate testing (Unit testing or something similar). Rinse. Repeat.

Be a model.  Show (don't just tell) people how agile works by being agile.  The first three points above are the keys to being a Good Guy, which is the predecessor to being an effective Agile guy.  In my opinion, people who are admirable developers aren't only smart, they're also good, model employees and colleagues.

Map your territory.  I have a technique for mapping giant legacy codebases. I clone the repo, make a working copy, and then I try to change something, and see what else breaks.  By investigating coupling (via global state, or broken APIs, or a lack of consistent API or any abstractions or interfaces to program against) and by reading the code that breaks when I change things, I discover the cruft, I ask questions that lead to insights from the rest of the team (Oh we added that because Boss X 5 years ago demanded that, it never worked!). Over time, you'll get a mental map of the territory. Once you know how big it is, you'll know enough to make your map and get home.  Encourage others to map the territory of your giant codebase, and to build the technical knowledge of the team. Some people balk at "documentation" because it isn't agile.  Whatever.  I work in scientific environments too, and documentation is king for me, agile manifestos be damned.

Build little apps.   When working with a legacy codebase, I find I get ground down to a pulp. I get my spirit back by building little helper apps.  Maybe those apps are going to help you read, and understand and modify that giant G2 codebase.  Maybe you can make a mini IDE or parser tool that will help you work in your environment.  There are many cases where Meta-programming and Tool-building will not only help you break out of the giant deadlocks that legacy codebases impose on you, they also give your brain the ability to fly unrestricted by your G2 language. Write your tools and helpers in whatever language you can do them fastest and best in. For me, those languages include Python, and Delphi.  If you're a Perl guy, or you actually LIKE programming in C++ or C#, then write your helper tools in that language. teach the rest of the team to build little helper-apps and tools, and "componentry" and you'll eventually see that your legacy codebase isn't so daunting after all.

Title: I've inherited 200K lines of spaghetti code -- what now?

Body:
I hope this isn't too general of a question; I could really use some seasoned advice.

I am newly employed as the sole "SW Engineer" in a fairly small shop of scientists who have spent the last 10-20 years cobbling together a vast code base. (It was written in a virtually obsolete language: G2 -- think Pascal with graphics). The program itself is a physical model of a complex chemical processing plant; the team that wrote it have incredibly deep domain knowledge but little or no formal training in programming fundamentals. They've recently learned some hard lessons about the consequences of non-existant configuration management. Their maintenance efforts are also greatly hampered by the vast accumulation of undocumented "sludge" in the code itself. I will spare you the "politics" of the situation (there's always politics!), but suffice to say, there is not a consensus of opinion about what is needed for the path ahead.

They have asked me to begin presenting to the team some of the principles of modern software development. They want me to introduce some of the industry-standard practices and strategies regarding coding conventions, lifecycle management, high-level design patterns, and source control. Frankly, it's a fairly daunting task and I'm not sure where to begin.

Initially, I'm inclined to tutor them in some of the central concepts of The Pragmatic Programmer, or Fowler's Refactoring ("Code Smells", etc). I also hope to introduce a number of Agile methodologies. But ultimately, to be effective, I think I'm going to need to hone in on 5-7 core fundamentals; in other words, what are the most important principles or practices that they can realistically start implementing that will give them the most "bang for the buck".

So that's my question: What would you include in your list of the most effective strategies to help straighten out the spaghetti (and prevent it in the future)?


答:
Usually the complaints you hear upfront has nothing to do with the important problems. After all, it is entirely normal to hear of these complaints in any software projects.

Hard to understand code? Check. Massive code base? Check.

The real problem is that people leave, and when the new person joins the organisation, there is a typical disorientation. Furthermore, there is an issue of unrealistic expectations and code-quality issues.

Here is what I would tackle, in order:

Backups, both the server and local version

Set up bug tracker

Set up versioning system

Set up FAQ/Wiki

First debriefing of all scientist/programmers

Remind them of the 80/20 rule. 20% of the bugs are responsible for 80% of the problems.

Focus on the biggest issues, and keep enhancement requests et c off.

The purpose here is not to scare people with a big list, but a list of small achievable wins. After all, you have to prove your worth as well.

Set up build system

Start working on getting reliable builds (this may take a while)

identify and name every project

identify cyclic dependencies

if there are binaries from some open-source projects, try to obtain sources

Identify how the G2 code can be modularized, e.g. APIs, services

Identify how the G2 code can be tested, documented.

Set up code-review system

Second debrief

What does an ideal module look like?

How to cordon off old code

How to wrap new module around old code (See the Strangler Pattern http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html )

Identify a crack team of better programmers and work with them to wrap their modules.

Code reviews are there at this stage to improve communication, and documentation. Keep it easy at this stage. Sort out any process issues.

Roll out the system to other programmers. Let the crack team members become peer mentors to the rest. Remember that scaling is the issue here. You are effectively in a management role.


答:
Developing in layers increases complexity and programming effort. You need to justify what good a business layer would provide vs. a business tier. Personally I don't know many cases for regular LOB application to demand a business tier for scalability.
I am not sure what Global is exactly, but the rest are your GUI and Data stuff which you can't avoid separating any way. </p>

Title: Software Design Idea for multi tier architecture

Body:
I am currently investigating multi tier architecture design for a web based application in MVC3. I already have an architecture but not sure if its the best I can do in terms of extendability and performance.

The current architecure has following components

DataTier (Contains EF POCO objects)

DomainModel (Contains Domain related objects)

Global (Among other common things it contains Repository objects for CRUD to DB)

Business Layer (Business Logic and Interaction between Data and Client and CRUD using repository)

Web(Client) (which talks to DomainModel and Business but also have its own ViewModels for Create and Edit Views for e.g.)

Note: I am using ValueInjector for convering one type of entity to another. (which is proving an overhead in this desing. I really dont like over doing this.)

My question is am I having too many tiers in the above architecure?
Do I really need domain model? (I think I do when I exposes my Business Logic via WCF to external clients).

What is happening is that for a simple database insert it

(1) create ViewModel

(2) Convert ViewModel to DomainModel for Business to understand

(3) Business Convert it to DataModel for Repository and then data comes back in the same order.

Few things to consider,

I am not looking for a perfect architecure solution as it does not exits.
I am looking for something that is scalable.
It should resuable (for e.g. using design patterns ,interfaces, inheritance etc.)
Each Layers should be easily testable.

Any suggestions or comments is much appriciated.

Thanks,


答:
I'm a strong believer in committing every logical change that is worth keeping.  Commit often, and if code isn't worth keeping, revert it back to a clean state.  The longer you wait to push/publish your code back, the harder it is to implement, and the more problems you'll run into.  You'll also get feedback about your contributions a lot quicker:

do they break the build?

are you duplicating another team member's efforts?

are you doing something incorrect?

or are people waiting on things from you?

Small changes are a lot easier to manage.

Also, it's worth noting the difference between different version control systems.  Some, such as Git (distributed), will allow you to commit and control your entire history locally, only pushing when you are ready to publish. Others, like SVN (centralized), will combine the two steps making small commits very inefficient.

Don't forget that your commits are essentially change documentation.  When things go wrong, you'll be glad to have more history than not enough.  A single commit for a weeks work seems useless to me.  I'd just end up reading every single line of code changed rather than the summary of each logical chunk.


问:
Can I make a good career with VC++ programming?
I'm addicted to VC++ since 2008, and I begin to work for my current company from 2011 when I graduated in Mathematics. Now I still love VC++, it is a wonderful programming language.

I'm a little confused whether it's a good idea to continue with Windows Programming.

I'm in Beijing, China. Of course, I come from China. I want to find a work in Silicon Valley, America in the future.

Can anyone tell me is it possible for me to find a VC++ work in Silicon Valley someday in the future? And what should I do in the recent years?

答:
Short Answer: Yes, you can find!

How? Start with updating your resume and uploading it in ** dice.com, monster.com or careerbuilder.com, etc.**
Btw, stack exchange has also Careers 2.0 service, where you can look as well.

I would also advice to learn some other web-development tools and languages.
Being locked-up to one platform (windows desktop applications) and VC++ might be a disadvantage. There are some mainstream trends in projects to use C#, Ruby, Java, Python, etc. Thus, there is a need to become familiar with HOT tools and technologies in the market !

```<code>what should I do in the recent years?
</code>```

Master your tools and become expert in languages and tools that you use everyday

Follow developer forums and newsletters like codeproject.com.

Keep learning, and looking for opportunity that better matches your interest !

Body:
Short Answer: Yes, you can find!

How? Start with updating your resume and uploading it in ** dice.com, monster.com or careerbuilder.com, etc.**
Btw, stack exchange has also Careers 2.0 service, where you can look as well.

I would also advice to learn some other web-development tools and languages.
Being locked-up to one platform (windows desktop applications) and VC++ might be a disadvantage. There are some mainstream trends in projects to use C#, Ruby, Java, Python, etc. Thus, there is a need to become familiar with HOT tools and technologies in the market !

what should I do in the recent years?

Master your tools and become expert in languages and tools that you use everyday

Follow developer forums and newsletters like codeproject.com.

Keep learning, and looking for opportunity that better matches your interest !


答:
C++ is still a heavily used language.  It is witnessing a renaissance at Microsoft per Herb Sutter.  That should be encouraging to continue studying VC++.  Industry investment in C++ might see more vigorous growth both in and out of Microsoft camp.

If I may add, do learn other languages as well.  A popular scripting language like Ruby or Python; a new language like Rust or Go or Dart; a functional programming language like Lisp or ML.  Even if you don't use them everyday, what they teach you tend to come a long way in your career.

Title: Can I make a good career with VC++ programming?

Body:
I'm addicted to VC++ since 2008, and I begin to work for my current company from 2011 when I graduated in Mathematics. Now I still love VC++, it is a wonderful programming language.

I'm a little confused whether it's a good idea to continue with Windows Programming.

I'm in Beijing, China. Of course, I come from China. I want to find a work in Silicon Valley, America in the future.

Can anyone tell me is it possible for me to find a VC++ work in Silicon Valley someday in the future? And what should I do in the recent years?


答:
A career in software development tends to be a lot more fluid when it comes to technological knowledge than just "I am using language X" - I have worked in computer security (C++, Java, Perl, Python), defense (C++), and some startups and web companies (Java, Python, C#, Ruby). I have never really been afforded the opportunity to be a single platform or single-language person, except at my current job (using C# in a pure Windows shop), and Visual C++ is a specific implementation of the C++ language that is only available on a single platform (Windows, though the C++ knowledge itself is rather portable in terms of language constructs).

This does not include anything else I have learned for job and on the job - MySQL, Oracle, actually learning and becoming a Solaris/Linux/Generic Unix expert, servers, build systems, Qt (the framework), boost, Javascript, XML, security, etc. etc. etc.

I think it's more important to know that you will likely be expected to do more than just use some particular language - if you want to work in Silicon Valley, I will say C++ is actually not a heavily sought-after language, though it's in use at some major companies like Oracle, Facebook, and Google. You will find that Valley companies tend to seek Java and Ruby knowledge, as well as Javascript expertise.

More than likely, you will be learning and using multiple technologies, languages, and platforms to stay up with the speed of the Valley. I interviewed out there a few months ago (at a very nice startup, got an offer but ultimately turned it down due to personal and family obligations here). They were a Ruby company (I wanted a Ruby job but had never used Ruby professionally) and did not care that I had not use Ruby professionally. Companies out there are not going to be interviewing you for very specific knowledge, they need to find someone who's very flexible, adaptable, and able to pick up many things and do multiple things in rapid order. Windows itself seems to be a rather rare development platform in Valley and Valley-ish companies - developers tend to use Mac OSX or Linux, and companies use Linux for servers (due to cost and general availability on platforms like Amazon EC2, Heroku, and Engine Yard).

I will say the most important thing is to keep experimenting and learning - even on your current job. I am developing my Python, Scala, and R knowledge by using them at my current job (the company does not use any of them in production) because it's easier for me to prototype and experiment in those technologies than using C# up front. It helps me get work done faster in the end. Also, understand that there are many technologies out there and while you will develop expertise in a few, you will gain passing knowledge across a wide variety of technologies, platforms, and languages.


答:
Source code control is step #1 as already stated many times. While the people you work with may not be professional developers and they won't respond to a lot of enterprise or agile mumbo jumbo. They're not low level code monkeys either and trying to treat them like that by forcing them to do things 'your way' will not fly.

You've got to survey whats out there. If they haven't used source code control then just identifying the right versions of the code (if possible) and what all the possible deliverables are is going to take a long time. Then you're going to have the task of teaching your colleagues how to use source code control and convince them that its worth their time. Start with the benefits!

While you're doing that, find other low hanging fruit and fix those problems.

Above all else, listen to what they have to say and work on improving their situation. Don't worry about trying to put your stamp on what they do.

Good luck!


问:
Default Ant target: help or jar?
What would you choose as the default Ant target?

In the context of a small visual tool with a user interface, open source.

I was thinking about jar because the project's distributable is the jar file.

But someone prefers to have help as the default target, to show the available targets.

Or maybe another target? I doubt anyone would really care, but would be the "least surprise" choice?

答:
The name of the default Ant target is not as important as setting it to whichever target will be used most frequently by end users. Good default target names include:

build

dist

jar

main

If your Ant project contains many targets, it can be confusing to new users to read through all the target descriptions (e.g. by listing all the targets by default). The first time building a new project it is convenient to be able to type ant at the command prompt and get the desired deliverable.

Each target should be documented by utilizing the description attribute so that running ant -p provides sufficient information for most users to quickly evaluate the remaining targets in your project. The same principles apply when running the Ant build from within a GUI.

Title: Default Ant target: help or jar?


答: If you care about only a subset of the properties, and you want to make sure they don't get mixed up,  create two interfaces, and use that to talk to your base object.</p>


问:
Future of WPF and free controls ?
I am willing to work on a personal project that I would like to release publicly. I am working with Silverlight and have experience with XAML, as it is my full-time job.

It is enjoyably for me to create UIs in Blend and XAML. I am also a big fan of C# language. I don't know what I would do without LINQ now.

Anyways, I was looking at using WPF for my personal project. It seems that a lot of the controls out on the web are pay for items. The only place I have found to have a significant number of free controls is the WPF extended framework on codeplex.

I want to make a financial application and need a powerful datagrid type of control that will allow me to enter transaction data. I haven't found such control for free in the net. It doesn't seem like there is much free community libraries/controls out there for Microsoft products.

So, I was wondering if WPF would be the right way for me to go. I couldn't find any information on WPF usage in Windows 8, which coming very soon. I don't know Microsoft's plans for this technology.

Would it be a better idea to use something different for the UI instead of WPF?

答:
A good post on future of WPF in Windows 8 - WPF In Windows 8 Metro

discussion about Windows 8 - What is the future of WPF applications?

Unfortunately most good quality WPF controls are commercial - good WPF control libraries out there?. However, there are some limited number of Free controls that you might look:

MSDN - control Library

FREE WPF controls

WPF C# Ribbon Control Library

Wpf Control Library Software

Download free WPF ribbon control (Windows Scenic and Office 2007 style, too)

Title: Future of WPF and free controls ?


问:
How to become a good team player?
I've been programming (obsessively) since I was 12.  I am fairly knowledgeable across the spectrum of languages out there, from assembly, to C++, to Javascript, to Haskell, Lisp, and Qi.  But all of my projects have been by myself.

I got my degree in chemical engineering, not CS or computer engineering, but for the first time this fall I'll be working on a large programming project with other people, and I have no clue how to prepare.  I've been using Windows all of my life, but this project is going to be very unix-y, so I purchased a Mac recently in the hopes of familiarizing myself with the environment.

I was fortunate to participate in a hackathon with some friends this past year -- both CS majors -- and excitingly enough, we won.  But I realized as I worked with them that their workflow was very different from mine.  They used Git for version control.  I had never used it at the time, but I've since learned all that I can about it.  They also used a lot of frameworks and libraries.  I had to learn what Rails was pretty much overnight for the hackathon (on the other hand, they didn't know what lexical scoping or closures were).  All of our code worked well, but they didn't understand mine, and I didn't understand theirs.

I hear references to things that real programmers do on a daily basis -- unit testing, code reviews, but I only have the vaguest sense of what these are.  I normally don't have many bugs in my little projects, so I have never needed a bug tracking system or tests for them.

And the last thing is that it takes me a long time to understand other people's code.  Variable naming conventions (that vary with each new language) are difficult (__mzkwpSomRidicAbbrev), and I find the loose coupling difficult.  That's not to say I don't loosely couple things -- I think I'm quite good at it for my own work, but when I download something like the Linux kernel or the Chromium source code to look at it, I spend hours trying to figure out how all of these oddly named directories and files connect.  It's a programming sin to reinvent the wheel, but I often find it's just quicker to write up the functionality myself than to spend hours dissecting some library.

Obviously, people who do this for a living don't have these problems, and I'll need to get to that point myself.

Question: What are some steps that I can take to begin "integrating" with everyone else?

Thanks!

答:
Being a good team member means communicate fearlessly, trust your colleges and overcome obstacles in a project as a team and deliver project as a team.

It takes time, takes patient and requires to learn in order to feel comfortable and confident as a programmer. It is also true that NOT every programmer is a good Team player, and team players share their success and learn lessons from failures.

It would be helpful to highlight some characters of good team member.

a) Good team member is a person who is goal-oriented instead of self-oriented.

b) Qualities: thinking more about big picture rather than self-satisfaction. This is key point. All other qualities (like reliability, constructive communication,) inherits from this one

c) How to improve:
Try to qualify how have you interact with your team during the day, define good and bad points, pay attention to them during next meetings. Also, try to Look at Team decisions from many angles. Place yourself on the other's roles, think how you can affect others work.

Title: How to become a good team player?


答:
I think you are getting a bit both anxious and excited at working for a group.

None of us learned working in a group or team from books or was given any baby steps or "Dummies Guide to Working in Teams".

We just learn working WITH groups by working IN groups.

Everything that you heard about professional programmers, will fall into place gradually as you work in team.. You'll learn about all of them one by one like version controlling, unit testing etc.

To me, the bottom line is

Become part of a team.

Title: How to become a good team player?

Body:
I've been programming (obsessively) since I was 12.  I am fairly knowledgeable across the spectrum of languages out there, from assembly, to C++, to Javascript, to Haskell, Lisp, and Qi.  But all of my projects have been by myself.

I got my degree in chemical engineering, not CS or computer engineering, but for the first time this fall I'll be working on a large programming project with other people, and I have no clue how to prepare.  I've been using Windows all of my life, but this project is going to be very unix-y, so I purchased a Mac recently in the hopes of familiarizing myself with the environment.

I was fortunate to participate in a hackathon with some friends this past year -- both CS majors -- and excitingly enough, we won.  But I realized as I worked with them that their workflow was very different from mine.  They used Git for version control.  I had never used it at the time, but I've since learned all that I can about it.  They also used a lot of frameworks and libraries.  I had to learn what Rails was pretty much overnight for the hackathon (on the other hand, they didn't know what lexical scoping or closures were).  All of our code worked well, but they didn't understand mine, and I didn't understand theirs.

I hear references to things that real programmers do on a daily basis -- unit testing, code reviews, but I only have the vaguest sense of what these are.  I normally don't have many bugs in my little projects, so I have never needed a bug tracking system or tests for them.

And the last thing is that it takes me a long time to understand other people's code.  Variable naming conventions (that vary with each new language) are difficult (__mzkwpSomRidicAbbrev), and I find the loose coupling difficult.  That's not to say I don't loosely couple things -- I think I'm quite good at it for my own work, but when I download something like the Linux kernel or the Chromium source code to look at it, I spend hours trying to figure out how all of these oddly named directories and files connect.  It's a programming sin to reinvent the wheel, but I often find it's just quicker to write up the functionality myself than to spend hours dissecting some library.

Obviously, people who do this for a living don't have these problems, and I'll need to get to that point myself.

Question: What are some steps that I can take to begin "integrating" with everyone else?

Thanks!


问:
Representing business rules with exceptions
I know it is expensive but (IMO) I believe it is a very good practice. I'm talking about rules like say, you can't save an Invoice if you are not a sales person... so in that case throwing an exception saying 'your are not authorized' or such...

Another approach it would be having objects with a status or something like that

Is there any other approach? how do you feel about it?

答:
If you mean representing individual business rule checks with exceptions, then I don't think it's a very good idea. Many times you have to report more than one failed condition, and not stop on the first one.

On the other hand, I do believe that checking for all rules and then throwing an exception with the summary is a good practice.


问:
Organizing code for iOS app development
I've been developing an app for the iOS platform, and as I've been going along, I've noticed that I've done a terrible job of keeping my files (.h, .m, .mm) organized.  Is there any industry standards or best practices when it comes to organizing files for an iOS project?

My files include custom classes (beside the view controllers), customized View Controllers, third-party content, code that works only on iOS 5.0+ and code that works on previous versions.  What I'm looking for is a solution to keep things organized in a manner that others (or myself in years to come) can look at this and understand the basic structure of the application and not get lost in the multiple files found therein.

答:
There is no industry standard as such. You could look into sample Apple Source Projects to see how they do it..

You could however, try organizing your files into Groups & associate each group to a folder..

Organize all Controllers in One Group with Subgroup for each usecase.

Put all views in One Group and subgroup for each usecase.

Organize All Models in one Group

Put Third Party Libraries in Another Group with Subgroup for each Lib.

So on and So Forth.. Also, associate each group to a folder inside your project.

Title: Organizing code for iOS app development


答:
Another tip I would like to give you is that no two teams are the same, and
that even an existing team will change when one or more people join it.

A team originates from the interaction of individuals that get to know each
other and try to understand how to work together until they find a common way
(see e.g. Tuckman's stages of group development).

So my advice would be not to try and find answers to your questions now, but
to see what happens when you actually start working in the new team.
Some of your issues might be considered non-issues by your colleagues, some
others will be considered relevant and you will have the possibility to
discuss them together or even promote your own view on the topic. And finally,
you will probably also deal with aspects you had not thought of.

I agree with ElYusubov that you need a lot of patience and give yourself and
the new colleagues some team to learn to work together until you become
a team. If you practice some team sport you should have experienced this
already.

One final comment on spending a lot of time understanding other people's code.
Working in a team means you are going to work on someone else's code and other
developers are going to work on your code. Sometimes the code is too complex
to be rewritten from scratch. A typical solution is to ask the original
developer to review your changes, so that you have a bit more confidence
that you are not breaking anything in their code.

This was for me a big leap in the transition from a solo programmer to
a team programmer: you work on code you only partially understand and
you have to get used to it. This involves a lot more communication with
your colleagues, a lot of respect (yes, the have weird naming conventions
for their variables, so what?) and mutual trust (even though they have
a different coding style, I know they deliver working code).

Title: How to become a good team player?


问:
Is version history really sacred or is it better to rebase?
I've always agreed with Mercurial's mantra 1, however, now that Mercurial comes bundled with the rebase extension and it is a popular practice in git, I'm wondering if it could really be regarded as a "bad practice", or at least bad enough to avoid using. In any case, I'm aware of rebasing being dangerous after pushing.

OTOH, I see the point of trying to package 5 commits in a single one to make it look niftier (specially at in a production branch), however, personally I think would be better to be able to see partial commits to a feature where some experimentation is done, even if it is not as nifty, but seeing something like "Tried to do it way X but it is not as optimal as Y after all, doing it Z taking Y as base" would IMHO have good value to those studying the codebase and follow the developers train of thought.

My very opinionated (as in dumb, visceral, biased) point of view is that programmers like rebase to hide mistakes... and I don't think this is good for the project at all.

So my question is: have you really found valuable to have such "organic commits" (i.e. untampered history) in practice?, or conversely, do you prefer to run into nifty well-packed commits and disregard the programmers' experimentation process?; whichever one you chose, why does that work for you? (having other team members to keep history, or alternatively, rebasing it).

1 per Google DVCS analysis, in Mercurial "History is Sacred".

答:
Your question describes history
as a set of ordered code changes, and asks whether or not organic commits clue
future readers into the development process. Yet as a release /
integration engineer, I don't often think of history as code. I'm more
engrossed with the story my history tells, the institutional knowledge it
retains, and whether or not it allows me to quickly debug problems.

I don't think organic workflows do this well, even my own. Qualities I value
about DVCS when I'm coding -- cheap branches, quick commits, saves to the
remote early and often -- are not what I value as my company's integration
manager.
I issue git rebase, git merge, git diff, and git apply far more often
in that role than git add or git commit. Tools like rebase allow me to
transform the code I'm given from something that functions into
something that can be maintained.

Illogical or vague commits aren't useful, but they are sinfully easy to write organically, when the primary concern is making the code work, not distributing it to others. Commits like Case 15: Fixed a problem, or Refactored <cranky legacy feature> make my maintenance-self cringe, even when I author them. None, however, induce the blackout rage like "incremental" commits. Consider this topic branch a developer handed me the other day:

```<code>$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update
</code>```

These things are Evil. It's like DVCS designed for Dr. Faustus. I'll give
you quick and easy source control. You give me is your code
maintainer's soul. All lazy commits are selfish acts. Many of us write them, but we also owe our future selves a logical, replicable,
debuggable history. We can't do that without some way to rebase.

As for failed experiments, why not describe them in our (newly pristine) commit messages? A year from now I don't need a half-finished snippet. I just want a record of the aborted attempt, and perhaps a short explanation if I think I'm foolish enough to try it again. There are a lot of successful workflows in the world, but I'm struggling to think of any reason I'd knowingly commit broken code to a production codebase.

Body:
Your question describes history
as a set of ordered code changes, and asks whether or not organic commits clue
future readers into the development process. Yet as a release /
integration engineer, I don't often think of history as code. I'm more
engrossed with the story my history tells, the institutional knowledge it
retains, and whether or not it allows me to quickly debug problems.

I don't think organic workflows do this well, even my own. Qualities I value
about DVCS when I'm coding -- cheap branches, quick commits, saves to the
remote early and often -- are not what I value as my company's integration
manager.
I issue git rebase, git merge, git diff, and git apply far more often
in that role than git add or git commit. Tools like rebase allow me to
transform the code I'm given from something that functions into
something that can be maintained.

Illogical or vague commits aren't useful, but they are sinfully easy to write organically, when the primary concern is making the code work, not distributing it to others. Commits like Case 15: Fixed a problem, or Refactored <cranky legacy feature> make my maintenance-self cringe, even when I author them. None, however, induce the blackout rage like "incremental" commits. Consider this topic branch a developer handed me the other day:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

These things are Evil. It's like DVCS designed for Dr. Faustus. I'll give
you quick and easy source control. You give me is your code
maintainer's soul. All lazy commits are selfish acts. Many of us write them, but we also owe our future selves a logical, replicable,
debuggable history. We can't do that without some way to rebase.

As for failed experiments, why not describe them in our (newly pristine) commit messages? A year from now I don't need a half-finished snippet. I just want a record of the aborted attempt, and perhaps a short explanation if I think I'm foolish enough to try it again. There are a lot of successful workflows in the world, but I'm struggling to think of any reason I'd knowingly commit broken code to a production codebase.


问:
Considering consistent change, how short of a planning period is too short?
Change is not uncommon, change in requirements, change in specs change in workflow. I've accepted that there will be change, but I wonder: knowing that change is going to happen, how short of a planning period is too short? (Justifications are encouraged)

An iteration (2-4 weeks)?

A week?

A 2-3 day period?

A day?

1/2 a day?

Assume that the company 'plans' 1 [time interval (from above)] in advance from the current so that any plan sounds like:

"[this morning/today/this week/etc.] you'll work on this and [this afternoon/tomorrow/next week/etc.] you'll be working on that.

Also assume that the changes in focus/direction will consistently occur every second to third time interval.

答:
I'm a Scrum Practitionner so I'll will suggest you to use it.

Define the duration of your iteration. I like two weeks iteration in startups, and one month in large enterprise projects

At the beginning of an iteration, select from the features you will develop from the product backlog. Nobody has the right to change the iteration plan, not even the product manager.

Changes occur in the product backlog, not in the iteration plan. Therefore, you are never affected in your work.

More details about Scrum


答:
Revision control: show the domain experts the benefit of being able to revert, see who changed what, etc. (This is tougher with all-binary files, but if the contents are indeed code, surely there is some sort of G2-to-text converter that can enable diffs.)

Continuous integration and test: get the domain experts involved in creating end-to-end tests (easier, since they must already have inputs and expected outputs somewhere) and small unit tests (harder, because spaghetti code probably involves lots of global variables) that cover nearly all functionality and use cases.

Refactor common code into reusable routines and components. Non-software people with no revision control probably copy-and-paste 100s of lines at a time to make routines. Find them and refactor them, showing that all the tests pass and the code has gotten shorter. This will also help you to learn its architecture. If you're lucky by the time you have to start making the hard architectural decisions, you might be down to 100KLOC.

Politically, if you find resistance from the old timers in this process, hire a consultant to come in and give a talk about good software methodology. Make sure you find a good one whose views you agree with, and get management to buy off on the necessity of the consultant even if the domain experts don't. (They should agree - after all, they hired you, so evidently they realize that they need software engineering expertise.) This is a money-wasting trick, of course, but the reason is that if you - the new hotshot youngster programmer - tell them they need to do something, they may ignore it. But if management pays a consultant $5000 to come in and tell them what they need to do, they'll put more faith in it. Bonus points: get the consultant to advise twice as much change as you really want, then you can be the "good guy" and side with the domain experts, compromising to only change half as much as the consultant suggested.


答:
Arguments for checking in every day:

Code is stored and backed up against harddrive failure

Activity can be recorded in commit notes (what did I do on Thursday...?)

Integration with existing code base happens earlier and in smaller chunks, hopefully identifying conflicts or merge issues sooner

Your team have visibility of what you have been working on

Your colleagues can work against your interfaces sooner, giving them more time to integrate with your 'big complex bit of code'

Your code will be real-world tested sooner, or at least exposed to more use than you will give it, leading to earlier identification of bugs or omissions.

Arguments against checking in every day:

Don't need to or don't want to

Haven't 'cleaned up' my code yet, it's a mess

Don't have time

I don't believe there's any good reason to check in less than daily apart from laziness or disorganisation. Nothing worse than see the code running in the development environment doesn't match the code in the development branch because someone 'hasn't finished yet' and thus hasn't checked in.

I'd love to be wrong on this so please let me know any legitimate argument against daily check-in.


问:
How common is meta-programming?
How often do you or have you seen meta-programming be used in projects? In uni I've never seen this be applied, but I've seen this on my previous job (when I saw it I was blown away of how effective it was).

But how common is it? Is it used all the time, or just occasionally?

答: For the past two years the first bit of programming on a new task has almost always been writing code to write code.  There's a ton of boilerplate associated with interactions with a database that can be simplified down to automatic script generation.  Think of things where you need to query 3 tables to form an object or some such.  Why write it yourself if there's 10 of these things that might change in the future?</p>

Title: How common is meta-programming?