问:
Validation and data persistence in a domain model
My (first and current) workplace (a .NET shop) suffers from an over-abundance of anemic domain models, to the extent that I don't really know how validation and data persistence should be handled in a proper domain model.

Data Persistence

One option would be to give the domain model a way to do persistence itself. You could, for example, inject an IFooRepository via constructor injection, and have that resolved by an IoC container to ensure you don't create a dependency on it (à la onion architecture). But I'm not sure if the code that uses the domain model should be responsible for calling methods to save the data, etc., or if it should be done implicitly behind the scenes on a background thread. Perhaps this breaks that purity of the domain model and is more along the lines of the active record pattern.

The other option I see is to not tie the domain model to data persistence at all and instead have a coordinating service layer responsible for that aspect.

What are the best practices for data persistence in the domain model pattern?

Validation

Another problem I don't know how to solve with a proper domain model is how to indicate to the UI why the current model state is invalid without coupling to (or at least catering to) the UI. For example, let's say I have a form an user fills out with various fields. We want to validate that input, and if something is wrong, indicate an error on that specific field with a message.

How would we handle validation with that level of granularity without adding significant complexity to the domain model, or doing hack-ish stringly-typed things (like throwing an validation exception with the property's name and a message)?

答:
The question arises what your UI is using to get the data and how it sends the data to be persisted. I'm afraid since you mentioned you have no service layer and you suffer with finding the right place for your validation, that your UI works directly with your domain classes. That could be the way to go, however it does not sound like a very complex application and you can do persistance work and querying right in the UI code. You can check posts of Ayende Rahien and many others who talk about getting rid of repositories. In relatively simple scenarios ORM is capable to provide enough isolation of domain model from the persistance itself. Also it is a questionable matter if modern ORMs can be seen purely as DAL. Look at NHibernate, it can do so much more than just mapping simple tables to simple classes. And if you look at your repositories you might find a bunch of methods called GetByThis and GetByThat, which issue a simple query to the ORM (if you use one of course) and just play a silly role of unneeded abstraction to make an impression that you do DDD.

Concerning your comment about "not creating" dependencies by injecting repositories - you will onvert control but you will have dependency as soon as you use repository class instance in your domain object. It does not matter how it gets there. So this is the worse choice of all.

To your validation question I would recommend you to look closely to your validation as such and decide what validation is domain specific and what is more data entry specific. Data entry validation like mandatory fields should not be checked by the domain model. It is a simple job and UI layer is perfectly capable of doing that. Even more, most of modern UIs are able to do this validation very easily. However you need to find a way to inform your UI about the data input rules (I will get back to it below). Your domain model need to perform more business-oriented validation, like if customer with such name already exists. But you, again, cannot do this inside your domain class since you are unable to query existing data from there because it is not the domain object responsibility to care about anything outside of its own aggregate.

So if you want to go to deal DDD journey I would recommend you to look at CQRS principle. It is often bound to event sourcing but you can just skip that. Concentrate on this scenario, when using RDBMS with or without ORM or NoSQL for persistence:

Create input models and view models to be used solely by the UI.

Decorate your input models with data attributes for client-side validation.

Send commands from the UI to your backend to do business validation and persistence.

Send queries to your backend from the UI to get the data to show. Returned data should be placed in view models.

Use domain events to communicate between different bounded contexts

It does not necessarily require the backend logic to be put in an application server (although it is very desirable to enable having multiple UIs with the same backend). You can use in-memory events to send commands and queries too.

But again, look at what you really need, don't try to overscale your abstractions just because the book says so. Remember that very often abstractions are put in place just because someone heard this is a good thing. Repositories is a classic example, when people say it makes their system persistence ignorant and they can change their ORM but in fact no one does that. When ORM is changed it means almost full redesign and repositories get scrapped equally well together with all other code.


问:
Architecting multi-model multi-DB ASP.NET MVC solution
I have an ASP.NET MVC 4 solution that I'm putting together, leveraging IoC and the repository pattern using Entity Framework 5. I have a new requirement to be able to pull data from a second database (from another internal application) which I don't have control over.

There is no API available unfortunately for the second application and the general pattern at my place of work is to go direct to the database.

I want to maintain a consistent approach to modeling the domain and use entity framework to pull the data out, so thus far I have used Entity Framework's database first approach to generate a domain model and database context over the top of this.

However, I've become a little stuck on how to include the second domain model in the application.

I have a generic repository which I've now moved out to a common DataAccess project, but short of creating two distinct wrappers for the generic repository (so each can identify with a specific database context), I'm struggling to see how I can elegantly include multiple models?

答:
When talking to an external system you are building an integration. When you integrate with someone, this someone does not become part of your domain model.

As you mentioned, you have no control of that other database. If one day they change something in their tables, your whole application will become unusable and there will be very little you can do except changing your application.

What integration normally assumes and you mentined that too is an API. If you have no API you have build your own. Create a separate service that will read from that database and give it to your main application via an API. Every communication that occurs between your system an external system can be divided to messages (one or two way) and on-demand data requests. For messages you can use a bus like MassTransit or NServiceBus and you build your own module, in vase of NServiceBus it would be a satellite, to transfer messages to and from the external database. If this is on-demand data requests, you can build your own web service that will read from that external database and provide it to your external system for reading via web service calls.

How you work with external database within the adapter is your own choice. You can use EF if you like. If they change their table you will just change your adapter.

Plus, this adapter approach (in fact this is a design pattern) you can easily switch when they come up with a proper API one day or may be any other method like exchanging XML files or similar.

And one last comment - the fact that you created a model in EF designer by clicking "read from database" button or how it called does not mean you got a domain model. You just got some classes that mapped to some tables. Some call it "domain model" but believe me, it is not.

ContentLicense: CC BY-SA 3.0


问:
What are the alternate models for remote desktop software?
A coworker and I were trying to brainstorm and list the different ways an application developer can write a program enabling a user on one computer to run remotely on another computer while being displayed on their own computer. She suggested all possibilities would fall into only three categories:

remote desktop software

hosted service

appliance

I think I understand how an application developer might approach this using the first model (for example, by writing an application that uses a service on the server via a protocol.) I'm unsure how the second model would be different than the first, and I don't understand what the term 'appliance' would mean in this case.

What I would like to know is how should an application developer compare these alternatives when designing a strategy for a new application -  that will be used remotely?

答:
I'm not sure if this would fall into one of the mentioned categories, but a kind of web model is a possibility.  Say you have two clients with identical capabilities.  They share a datasource though which could reside on either client, both, or completely seperate.

In the case of both, you would need to consider conflicts for operations in which the datasource is hit with a request from one client (with a later timestamp) before being hit by the other client (with an earlier timestamp), but could implement exclusive writing similar to microsoft office products for ease.  Or go the google route and have seemingly simultaneous writing.

Just a thought.  Web applications seem like a good solution for remotely accessing resources.


问:
PDF to doxygen - how to do it?
I have a big pdf with the documentation for a project and I need to render this to doxygen (so take each function from the pdf and write it out into doxygen).

Any suggestions on how to do this quickly and effectively (other than doing it by hand)?

答:
First, you will need some kind of OCR software to transform your PDF into some kind of machine readable ASCII text.

Second, since doxygen is a tool for creating docs from annotated source code, I assume you have that source code and your PDF docs refers to functions and classes in that source code. You will have to check if your ASCII-converted PDF text can be assigned uniquely and automatically to annotations of your source code. Since you did not post even the slightest example of how your docs and your source code look like, the only suggestion I can give you is to write a program for that task. The program should read the source code and the ASCII text and write the source code with doxygen compatible annotations. I would not expect to find an existing tool for that part.

Title: PDF to doxygen - how to do it?


问:
How can I make sure that I'm actually learning how to program rather than simply learning the details of a language?
I often hear that a real programmer can easily learn any language within a week. Languages are just tools for getting things done, I'm told. Programming is the ultimate skill that must be learned and mastered.

How can I make sure that I'm actually learning how to program rather than simply learning the details of a language? And how can I develop programming skills that can be applied towards all languages instead of just one?

答:
Programming is about problems solving in such a way that the solution can be expressed in such a restricted grammar that it can be implemented with a programming language. The art of programming is therefore the art of solving problems.

Certain languages invite other programming paradigms such as object orientation, event driven, multi-threaded and MVC framework based. These are all just models and patterns and have nothing really to do with implementation.

If you can sit and solve a problem on paper in such a way that it could be easily translated into code and is associated with an appropriate model for your platform, then you are a programmer. If all you can do it take those solutions and implement them in our chosen language, then that's another matter.

I have been programming for 30 years (OMFG!) and still use php.net to look up commands in PHP because it's not my first language.

I would say that expertise in languages is inversely proportional to how often you look at the manual or stackoverflow. Expertise in programming is how readily you solve problems in a way which is compatible with computer programming languages.

In related news, I learnt Ruby last week. Though I'm no "expert", I can solve you a problem which I could write in Perl, say, and then spend an age translating it to Ruby whilst I learn it some more.


问:
Is it practical to write exit codes in a script where the outcome is more complex than success/fail?
Where I work, we're in the process of automating a lot of tasks that currently need to be run manually by an IT person to determine if the next task can be performed (the second task depends on certain outcomes of the first task). We're ending the first phase of our script automation process, having reworked the first task to have better support for logging, error handling and even emailing a report, but we will not be able to get to reworking the second task right away so it will remain in its current state of manual use.

In the meantime, it has been suggested that we implement exit codes into the first task so that we can simply chain the second task, in its current state, on a successful first task. The only issue here is that the first task is a little more complicated than just success/fail. There are many different parts that can pass that will allow the second task to be run a certain way. Now I know none of this is impossible with exit codes. We could take the time to implement the first task to return all these different exit codes so that the second task can be run in a semi-automated fashion based on these exit codes as a temporary solution to making the entire process automated until we have the time to go in and rework the second task the correct way.

My question is, is it practical to take the time to implement exit codes into a script as a temporary solution to a larger problem where the script is more complex than success/fail?

Note: The exit codes will take some time to implement as our rework of the first task was not designed to return exit codes (it is a self-contained script that handles its own logging and error reporting).

Edit: It is a given that we have to go back and rework the second task in a way that the two tasks can be run independently of each other (their outcomes/state will be shared through a database).

Edit: In general, I know it is useful to have exit codes, but my current situation involves spending a considerable amount of development time to go back and implement the exit codes properly (again because the outcome of the script is quite complex with many different levels of success/fail), when they aren't part of the overall solution, but a temporary hack to our new system in order to "fake" it as a completely automated system until we can actually complete the rework. I guess it's more of a "Is the time spent to implement this hack, while not a complete solution, worth it if we have to go back and undo the hack later?" question.

答:
As GlenH7 pointed out, having multiple possible exit code values is a pretty common practice. However, I'm not sure I would go down that road if I was in your position (which is clearly based on my very limited knowledge of your position).

Automated tests are not humans. I think they work much better and bring much more benefit when things really are black and white (or green and red).  Most of unit testing books stress on making tests very simple and predictable for this very reason.

In your case, your first task is rather complex so it could return a whole bunch of different things.  But the downstream job really cares about one thing: should I or should I not run?

If your downstream job has a bunch of conditional statements and depending on the exit code of the first job, it would do different things then:

Are you sure you want those conditionals? It makes each test run less predictable. If the goal of this stuff is to verify your software works, maybe same verification pass every single time would be easier to maintain?

What if instead of one downstream job, you had N downstream jobs, where each one would run depending on whether or not its environment was setup properly by the first job.  This way you could keep each downstream job's code much smaller, simpler and do the point.

Another thing I would consider is that true or false is definitely very limiting in terms of passing around information.  But -127 to 127 isn't that much better.  It might work today, but you'll probably hit the limit again.  What if instead you passed around XML or JSON.  Have the first job run and generate a report of what it did.  Save that report to a file and have the downstream job parse and base its decision on that.  Both XML and JSON formats are extensible so a) you'll be able to use that report for reporting and b) you'll be able to modify job A and extend information it returns, but job B should still be able to consume existing fields that it relies on.


问:
How many lines of code can a C# developer produce per month?
An executive at my workplace asked me and my group of developers the question:

How many lines of code can a C#
  developer produce per month?

An old system was to be ported to C# and he would like this measure as part of the project planning.

From some (apparently creditable) source he had the answer of "10 SLOC/month" but he was not happy with that.

The group agreed that this was nearly impossible to specify because it would depend on a long list of circumstances. But we could tell that the man would not leave (or be very disappointed in us) if we did not come up with an answer suiting him better. So he left with the many times better answer of "10 SLOC/day"

Can this question be answered? (offhand or even with some analysis)

答:
Well, I am a bit late to this party as usual, but this is actually an interesting one. I initially had the same thought as most that the executive's question is daft. However, I read SK-logic's answer and came to realize that it is a sensible question asked in a nonsensical way. Or, put differently, there is a valid problem behind the question.

Managers often need to try do determine the feasibility, funding, staffing, etc for a project. This is a sensible problem. For a straightford port an estimate based on lines of code of port divided by the estimated average lines of code per developer per day is appealing in simplicity, but doomed to fail for all the reasons given on this page.

A more sensible approach would be: -

For an on-the-spot estimate ask the developers with the most experience with the code for a gut estimate of how long it will take. This is bound to be incorrect for many reasons that I won't go into here, but it is the best that they will be able to do at the outset. At least they should have an idea whether it will be easy-peasy done in a week or years away even with additional resources. If there have been any similar sized ports or pieces of work done, they could use this as a guide.

Estimate the port by component to get a total sizing. Tasks that are not directly related to the port need to be included, such as setting up infrastructure (machines, build systems, etc), investigating and purchasing software, etc.

Identify the riskiest components of the port and start with those first. These are likely to blow out the estimate the most, so should be done up-front if possible so that there are limited surprises late in the port.

Keep track of the progress against the sizing done in step 2 to continually calculate the expected duration of the port. As the project moves ahead this should become more accurate. Of course, the number of lines of code that have been ported (features in the original code base that are now in the ported code) can also be used as a metric and is actually helpful to ensure that the original product is being ported rather than a bunch of cool new functionality being added while not tackling the actual port.

These would be the bare-bones steps, of course there are many other activities around this that are helpful such as investigating porting tools and pluggable frameworks, creating prototypes, determining what really needs to be ported, reusing test tools and infrastructure, etc.

ContentLicense: CC BY-SA 2.5


问:
Should a developer close a ticket in bug tracking tool?
Should a developer close a ticket in a bug tracking tool? Or should only the scrum master or testers should do it?

What are the best practices?

答:
The exact procedure will depend on your team structure, the nature of the development you are doing (bespoke apps for clients, web application used by the general public, internal tools, etc.?) and the point in the development cycle (pre-launch, maintenance of production system).

But as a general principle I would say that the person who should actually close a bug ticket should be the person (or member of the team) that opened it.

So if this ticket came from QA, the developer should mark it as resolved and assign it back to QA, but it should be a QA person who actually verifies the fix and closes it.

In pre-launch phase, it might well be the PM who opened the ticket, and who should close it.

And of course it could be a developer. When I find a bug whilst working on something else, I create a bug in our tracking system, and then it's often me that fixes it, in which case I'll close it myself. But depending on team size and formality of development, you may wish to even assign cases like this to QA so they can verify the original bug, verify the fix, and close the ticket.


问:
Does functional programming ignore the benefits gained from the "On the Criteria To Be Used in Decomposing Systems into Modules" (data hiding)?
There's a classic article named On the Criteria To Be Used in Decomposing Systems into Modules that I just read for the first time.  It makes perfect sense to me, and is probably one of those articles that OOP was based on.  Its conclusion:

We have tried to demonstrate by these examples that
  it is almost always incorrect to begin the decomposition
  of a system into modules on the basis of a flowchart.
  ... Each module is then designed to hide
  such a decision from the others

In my uneducated and inexperienced opinion, functional programming takes the exact opposite advice of this article.  My understanding is functional programming makes data flow idiomatic.  Data gets passed from function to function, each function being intimately aware of the data and "changing it" along the way.  And I think I've seen a Rich Hickey talk where he talks about how data hiding is overrated or unnecessary or something, but I can't remember for sure.

First I want to know if my assessment is correct.  Does the FP paradigm and this article philosophically disagree?

Assuming they disagree, how does FP "compensate" for its lack of data hiding?  Perhaps they sacrifice data hiding but gain X, Y and Z.  I'd like to know the reasoning for why X, Y and Z are considered more beneficial than data hiding.

Or, assuming they disagree, perhaps FP feels that data hiding is bad.  If so, why does it think data hiding is bad?

Assuming they agree, I'd like to know what FPs implementation of data hiding is.  It's obvious to see this in OOP.  You can have a private field that nobody outside the class can access.  There's no obvious analogy of this to me in FP.

I feel there are other questions I should be asking but I don't know I should be asking.  Feel free to answer those, too.

Update

I found this Neal Ford talk that has a very relevant slide in it.  I'll embed the screenshot here:

答:
There is a bit of a paradox here.  Even though functional programming focuses on, well, functions, and frequently has functions that work directly on primitive data types, it tends to have more data hiding than object oriented programming.

How is this so?  Think about a nice OO interface that hides underlying data - perhaps collections (I'm trying to pick something nearly ubiquitous).  You may not need to know the underlying type of the objects in the collection or type of the object implementing the collection, as long as you know the collection implements, say, IEnumerable.  So you have data hiding.

In functional programming, you might write a function that effectively works with an IEnumerable interface, but operates on a primitive data type (or on any data type).  But what if the type didn't ever implement the IEnumerable methods?  Here's the key, you can always have the "methods" that form the needed pieces of the "interface" be parameters passed in to your function.  Or you can put functions together with data and do things in an OO-like way.

Notice that either way you don't have any less data hiding than you have in OO.  My general function that works on any type clearly isn't accessing the data in that type - that happens within the functions passed as parameters to the general function, but the general function never peeks inside those functions to see the data.

So, as far as your point 1, I don't think FP and the article really disagree.  I don't think your characterization of FP not hiding data is correct.  One could implement the design the author preferred in FP, certainly.

As far as point 4 (2 and 3 don't make sense to answer given what I've said for point 1) it varies.  It also varies in OO languages, and in many private fields are private by convention rather than enforced by the language.


答:
What you are doing is building a Workflow system, which is really just a complex state machine.  Exit codes (and error logging) are very important to informing operations, testing, and development to where things failed (and succeeded).  But what you really want is a signaling mechanism that communicates to other entities whether their work can progress, must be delayed, or whether intervention is needed.

Exit codes are one important part of the picture, and can be used as a proxy for solving the workflow issue.  But many processes are more complex than a linear flow of work.  And often systems are implemented that combine more than one work step - leading to the expansion of error codes.  Likely you are also looking at scripts which must check that their needed starting conditions are present.  So you have error codes due to state conditions which prevent the part from starting work, plus you have error codes due to failures during processing.

Messaging or signaling of state (another answer mentions using XML/JSON) is far more communicative than a numeric error code (and the conflation of meanings of a limited set of error codes).  Having a state or message which communicates that a process is 'ok' to start/trigger is a positive signal to proceed.

All that said, there is a principle called YAGNI (You Aint Gonna Need It), which says to postpone build complexity until there is a clear need for it.  Since error/exit codes are an existing mechanism, you might find that they work just fine.  My advice is more to suggest an alternative to grow into, should you decide that you need something more.

Title: Is it practical to write exit codes in a script where the outcome is more complex than success/fail?

Body:
Where I work, we're in the process of automating a lot of tasks that currently need to be run manually by an IT person to determine if the next task can be performed (the second task depends on certain outcomes of the first task). We're ending the first phase of our script automation process, having reworked the first task to have better support for logging, error handling and even emailing a report, but we will not be able to get to reworking the second task right away so it will remain in its current state of manual use.

In the meantime, it has been suggested that we implement exit codes into the first task so that we can simply chain the second task, in its current state, on a successful first task. The only issue here is that the first task is a little more complicated than just success/fail. There are many different parts that can pass that will allow the second task to be run a certain way. Now I know none of this is impossible with exit codes. We could take the time to implement the first task to return all these different exit codes so that the second task can be run in a semi-automated fashion based on these exit codes as a temporary solution to making the entire process automated until we have the time to go in and rework the second task the correct way.

My question is, is it practical to take the time to implement exit codes into a script as a temporary solution to a larger problem where the script is more complex than success/fail?

Note: The exit codes will take some time to implement as our rework of the first task was not designed to return exit codes (it is a self-contained script that handles its own logging and error reporting).

Edit: It is a given that we have to go back and rework the second task in a way that the two tasks can be run independently of each other (their outcomes/state will be shared through a database).

Edit: In general, I know it is useful to have exit codes, but my current situation involves spending a considerable amount of development time to go back and implement the exit codes properly (again because the outcome of the script is quite complex with many different levels of success/fail), when they aren't part of the overall solution, but a temporary hack to our new system in order to "fake" it as a completely automated system until we can actually complete the rework. I guess it's more of a "Is the time spent to implement this hack, while not a complete solution, worth it if we have to go back and undo the hack later?" question.


答:
I'm not going to adress how long it takes to learn a language or what it means to learn a language, instead I'm going to address your actual problem: how to determine if you have learned to program or have learned a programming language.

You've learned to program if you have learned to break a problem down into discrete processes and then use those processes to solve your problem.  You've learned a progamming language if you've learned the syntax of a language and know how to adjust how a process works, when implemented in that language.

This is not to say you should program in Fortan when using Lisp or add up the values of a column in a table in a db using a cursor.  Just that the language is an implementation detail.  One that can change what processes are needed, but not the need for identifing and creating processes -- in the end there is a real world implementation, with input/output and desired results.

Body:
I often hear that a real programmer can easily learn any language within a week. Languages are just tools for getting things done, I'm told. Programming is the ultimate skill that must be learned and mastered.

How can I make sure that I'm actually learning how to program rather than simply learning the details of a language? And how can I develop programming skills that can be applied towards all languages instead of just one?


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

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

My question is:

How you interact with such thousands lines of code?

EDIT:

Any shortcut will be great!

答:
Understand that there really are no shortcuts to grokking in fullness.  (And if you have trouble with that phrase, your education has been SORELY neglected.  It is from "Stranger In a Strange Land", by Robert A. Heinlein.)

Read it, one page at a time, one routine at a time.  Add comments.  Draw pictures of major data structures.  Recognize algorithms.  Draw upon previous knowledge.

Resist the temptation to crank up the debugger.  The debugger viewport is too small: you see one line at a time, but you really don't see where you've been or where you're going.


问:
Creating an effective C++ library website and documentation
Creating a C++ library also means documenting it so that others can use it, and that documentation can vary dramatically in quality.

How should a website for a C++ library be structured so that it is most effective?

I would frame "most effective" as being divided among three specific groups of library stakeholders, which should each be able to find and learn what they need to participate in and use the library:

New users need an excellent, easy introduction, download, setup, and documentation that clearly flows from one step to the next.

Seasoned users need a solid reference with fast access to the details they need, and clear information about new updates.

New contributors need a how to guide covering the steps they must take to get their contributions into the library.

I would like to figure out how to make each very happy with what they see and use. This question is a bit of a cross between professional programming and user experience.

For specific examples, Boost is one of the best collections of libraries, but the initial installation, reference documentation, and figuring out how to contribute can be somewhat confusing.

On the other hand, I have found cppreference.com and the SGI STL documentation to be very clear and useful with explanations, links, and examples.

While the examples are merely opinions and others may differ, it does help give context to the question I am asking.

答:
In my previous company we started generating documentation and having a CI job run nightly and post it as a set of webpages which our team's wiki would then refer to.

As was suggested in comments to your question, we used doxygen.  One thing I really liked that was introduced in version 1.8 was ability to have a directory (or whole tree) of markdown documents whereas before that doxygen was generated purely from source files.

The structure we had was a welcome screen (markdown) which had links to various places. One of them was a product architecture which showed 30,000 foot view of the product and highlighted major services.  Then from that page, there were likes to other markdown pages that expanded each of the services and presented very high level design of each one (10k foot view?).

Also from the main page, we had links to collections of user guides that we wrote to explain how to use some common utility/framework code.

And we slowly started migrating existing design documents (written in MS Word and stored in share point) into doxygen format which actually proved easier than one would expect.  If not for the diagrams, which had to be exported individually and saved as JPEGs, a 20-30 page design document could be converted into doxygen markup format in about 15-30 minutes and it was so simple a co-op could do it (*).

The beauty which I loved about using doxygen for this type of documentation besides that it could generate HTML or PDF from the same source, was that we could tie all our documentation directly to class/function reference pages that were generated by parsing header files.  So it was a very nice structure that would go from "welcome" -> "architecture" -> "design" -> right down to class-level documentation.

And as the whole thing was in markdown, it was very simple to generate content (much easier than attempting to explain to a team of engineers how to correctly use MS Word Styles) and documentation was checked in right there with the source code, so as new versions were introduced and design/architecture modified, documentation would always stay synced up with it.

(*) - j/k we had great co-ops (for the most part) and they made many awesome contributions to the product, but I did make one of them do some of the doc conversion.

OwnerDisplayName: Andrew Hundt


问:
Algorithm to Find the Aggregate Mass of "Granola Bar"-Like Structures?
I'm a planetary science researcher and one project I'm working on is N-body simulations of Saturn's rings.  The goal of this particular study is to watch as particles clump together under their own self-gravity and measure the aggregate mass of the clumps versus the mean velocity of all particles in the cell.  We're trying to figure out if this can explain some observations made by the Cassini spacecraft during the Saturnian summer solstice when large structures were seen casting shadows on the nearly edge-on rings.  Below is a screenshot of what any given timestep looks like.  (Each particle is 2 m in diameter and the simulation cell itself is around 700 m across.)

The code I'm using already spits out the mean velocity at every timestep.  What I need to do is figure out a way to determine the mass of particles in the clumps and NOT the stray particles between them.  I know every particle's position, mass, size, etc., but I don't know easily that, say, particles 30,000-40,000 along with 102,000-105,000 make up one strand that to the human eye is obvious.

So, the algorithm I need to write would need to be a code with as few user-entered parameters as possible (for replicability and objectivity) that would go through all the particle positions, figure out what particles belong to clumps, and then calculate the mass.  It would be great if it could do it for "each" clump/strand as opposed to everything over the cell, but I don't think I actually need it to separate them out.

The only thing I was thinking of was doing some sort of N2 distance calculation where I'd calculate the distance between every particle and if, say, the closest 100 particles were within a certain distance, then that particle would be considered part of a cluster.  But that seems pretty sloppy and I was hoping that you CS folks and programmers might know of a more elegant solution?

Edited with My Solution:  What I did was to take a sort of nearest-neighbor / cluster approach and do the quick-n-dirty N2 implementation first.  So, take every particle, calculate distance to all other particles, and the threshold for in a cluster or not was whether there were N particles within d distance (two parameters that have to be set a priori, unfortunately, but as was said by some responses/comments, I wasn't going to get away with not having some of those).

I then sped it up by not sorting distances but simply doing an order N search and increment a counter for the particles within d, and that sped stuff up by a factor of 6.  Then I added a "stupid programmer's tree" (because I know next to nothing about tree codes).  I divide up the simulation cell into a set number of grids (best results when grid size ≈7 d) where the main grid lines up with the cell, one grid is offset by half in x and y, and the other two are offset by 1/4 in ±x and ±y.  The code then divides particles into the grids, then each particle N only has to have distances calculated to the other particles in that cell.

Theoretically, if this were a real tree, I should get order N*log(N) as opposed to N2 speeds.  I got somewhere between the two, where for a 50,000-particle sub-set I got a 17x increase in speed, and for a 150,000-particle cell, I got a 38x increase in speed.  12 seconds for the first, 53 seconds for the second, 460 seconds for a 500,000-particle cell.  Those are comparable speeds to how long the code takes to run the simulation 1 timestep forward, so that's reasonable at this point.  Oh -- and it's fully threaded, so it'll take as many processors as I can throw at it.

答:
I have been thinking about this problem. I am not a physics expert, so bear with me.

It seems that it is not the distance between the particles that counts to determine the clumps. It is whether or not the gravity fields overlap.

Take a particle P, and determine what other particles have overlapping gravity fields.

Then take one of those and do the same thing. Your goal is not to find all the particles in the clump but to find its boundaries.

Repeat this until all the clumps are found.

Now go back and determine the mass of the clumps. You will have eliminated stray particles, and you can use the clump boundaries to find the mass.

I am not sure if this helps, but it is all I could think of.


问:
How small is the footprint of a small C compiler?
This week I could optimize using a reduced C library that allowed a drastic shrinkage in code size - from about 60 K to about 6 K and then we could load the code in the 8 K on-chip memory  of an FPGA (Altera DE2) which I suppose is SRAM so there is SRAM both on-chip and off-chip(?)

The program was rather small itself and we noticed that most of the size was from libraries and doing embedded system we reduce the libraries to only what is needed so that the footprint is minimized.

It makes me wonder about something I heard in the media which was a story, maybe fictious, that Microsoft had to deliver a C compiler in only 20 K or so in the 70s or early 80s when there was not much memory available for software, is it true? What is a feasible size of the footprint for a small C compiler?

答:
The Software Toolworks C compiler for CP/M came on one 8" SSSD floppy, and compiled most of the language as of about 1982.  It required a machine with 56K of memory and one floppy drive.  I don't remember how much the resident portion of CP/M required.

Turbo Pascal 1.0 required 64K on a CP/M machine, and included an IDE.  It was a single-pass compiler, written in heavily-optimized assembly language, and did EVERYTHING in RAM, making it BLINDINGLY fast.  (Bill Gates was reportedly NOT happy about it: it made Microsoft look really bad.)


问:
What is the Meaning of Return False in a Php Function
i wanted to know what is the meaning of return False in an function.

go Through this function:

```<code>function reset_password($password,$user_id)
{
    $sql="UPDATE user SET password='$password' WHERE user_id='$user_id'";

    if(!mysql_query($sql,$this->mycon))
    {
        array_push($this->err_msg,"Error in Inserting - ".mysql_error($this->mycon));
        return false;
    }
    else
    {
        //Reset Password code.
    }
}
</code>```

in this function i wanted to know what is the meaning of return false.

答:
The return value of a function, in general, is a part of the convention between the caller and the callee. It is a way for the caller to determine what was the outcome of the function execution.

Specifically conceerning your example, this function returns false in the case of failure to reset the password. The caller can take advantage of this information and act accordingly. For example:

```<code>$outcome=$anObj->reset_password('opensessame','some_user');
if($outcome)
  echo "Password was successfully reset.";
else
  {
  $err=$anObj->err_msg[count($anObj->err_msg)-1]; // last element
  echo "Password Reset Failure because: $err";
  }
</code>```

But this is not to be interpreted as "a false return value means something went wrong". Many functions return false because that's the real outcome of the execution upon success. Consider for example in_array(). From the docs:

Description

bool in_array ( mixed $needle , array $haystack [, bool $strict =
  FALSE ] )

Searches haystack for needle using loose comparison unless strict is
  set.

Return Values

Returns TRUE if needle is found in the array, FALSE otherwise.

Body:
The return value of a function, in general, is a part of the convention between the caller and the callee. It is a way for the caller to determine what was the outcome of the function execution.

Specifically conceerning your example, this function returns false in the case of failure to reset the password. The caller can take advantage of this information and act accordingly. For example:

$outcome=$anObj->reset_password('opensessame','some_user');
if($outcome)
  echo "Password was successfully reset.";
else
  {
  $err=$anObj->err_msg[count($anObj->err_msg)-1]; // last element
  echo "Password Reset Failure because: $err";
  }

But this is not to be interpreted as "a false return value means something went wrong". Many functions return false because that's the real outcome of the execution upon success. Consider for example in_array(). From the docs:

Description

bool in_array ( mixed $needle , array $haystack [, bool $strict =
  FALSE ] )

Searches haystack for needle using loose comparison unless strict is
  set.

Return Values

Returns TRUE if needle is found in the array, FALSE otherwise.


答:
My strategy has always been to focus on pure skills rather than specific skills.

Instead of learning Python (or any language) 's special syntax for whatever it is you want to do, spend your brain cycles solving abstract problems, like how to best solve every problem in that category.

That way, you will know what to do no matter the language, and will mostly possess timeless skills that can be used for programming in any language.

Specifically avoid tools that are full of gotchas, like MySQL, or opinionated languages, like Java, as whatever you learn by using these tools will have a big proportion of tool-specific knowledge which is bound to become useless pretty fast.

Contrary to what has been said in many answers, do NOT listen to other programmers,You are a noob and there is no way you can tell the fake from the real deal, so you're better off taking everything with a spoon of salt.

You want to be questioning all the time and accepting only when the solution is fast, elegant and reliable.

Title: How can I make sure that I'm actually learning how to program rather than simply learning the details of a language?


问:
Old programmer disappeared. About to hire another programmer. How do I approach this?
After spending over one year working on a social network project for me using WordPress and BuddyPress, my programmer has disappeared, even though he got paid every single week, for the whole period. Yes, he's not dead as I used an email tracker to confirm and see he opens my emails, but he doesn't respond. It seems he got another job. I wonder why he just couldn't say so. And I even paid him an advance salary for work he hasn't done.

The problem is that I never asked for full documentation for most of the functions he coded in. And there were MANY functions for this 1+ year period, and some of them have bugs that he still didn't fix. Now it seems all confusing.

What's the first thing I should do now? How do I proceed?

I guess the first thing to do will be to get another programmer, but I want to start on the right foot by having all the current code documented so that any programmer can work on all the functions without issues.

Is that the first thing I should do? If yes, how do I go about it?

What's the standard type of documentation required for something like this? Can I get a programmer that will just do the documentation for all the codes and fix the bugs or is documentation not really important?

Also, do you think getting another "individual" programmer is better or get a company that has programmers working for them, so that if the programmer assigned to my project disappears, another can replace him, without my involvement? I feel this is the approach I should have taken in the beginning.

答:
Documenting code afterwards by another programmer? It is merely my own experience and opinion to tell you should not take that path.

Without more detailed knowledge of the quality of that code base, my opinion is that your best approach is to hire a new programmer to fix the bugs, maintain and possibly make modifications you require.

That opinion has the key point of possible modifications (changing or adding), as they need a requirement to be fulfilled. This means that some sort of requirement specification must be written. This is a document.

Which leads to a point of maintaining the whole project. You did not tell in your question if current programs requirements or even rough functional documentation exists, but that is where you should focus now.

In case you don't have any documentation at all, at this point, then it is more up to you to fill that void. You can not hire a programmer to reverse-engineer your application and miraculously mold documentation out of that. You must "explain" what you want the program do (even if it means to reexplain what has already been programmed in.)

When you have that document written (be it in form of requirement- or functional specification), you will get way better results from hiring a new programmer as you can hand over the documentation and start working from there.

There are also lots of programs that produce documents out of source code, which is good way to produce a skeleton of explaining the actual source code (this is in area of technical specification) which you only can work in context of explaining the technical aspects of the functionality specified in functional specification, which specifies the functionality of requirements specified in requirements specification.

So yes, my opinion is to hire a programmer to fix the bugs. After he has fixed the bugs which you agreed should be fixed, you could discuss the documenting aspect as another contract. With luck you hired a programmer who has some experience and can contribute to what steps you should take next from there.


答:
So, your only programmer was hit by a bus, and you need replacement now.

You could try to sue your former programmer, based on yout contract, or find out what's wrong with him. Assuming that he won't come back, this won't help you.

You want to get your product done, so search for a programmer who has
experience in maintaining and developing existing systems. I would
not focus on telling your programmer what to do in what order. Make
sure you hire someone professional, who writes documentation and unit
tests whenever necessary.

From your side, you can make sure that the new programmer has
everything needed for his work: Requirement specifications, a
powerful working machine, and so on. You want a professional programmer, so provide him a professional working environment.

Also, think about hiring a second developer for making this kind of difficult situations easier in the future. A tester would be useful for quality assurance as well.

Title: Old programmer disappeared. About to hire another programmer. How do I approach this?

Body:
After spending over one year working on a social network project for me using WordPress and BuddyPress, my programmer has disappeared, even though he got paid every single week, for the whole period. Yes, he's not dead as I used an email tracker to confirm and see he opens my emails, but he doesn't respond. It seems he got another job. I wonder why he just couldn't say so. And I even paid him an advance salary for work he hasn't done.

The problem is that I never asked for full documentation for most of the functions he coded in. And there were MANY functions for this 1+ year period, and some of them have bugs that he still didn't fix. Now it seems all confusing.

What's the first thing I should do now? How do I proceed?

I guess the first thing to do will be to get another programmer, but I want to start on the right foot by having all the current code documented so that any programmer can work on all the functions without issues.

Is that the first thing I should do? If yes, how do I go about it?

What's the standard type of documentation required for something like this? Can I get a programmer that will just do the documentation for all the codes and fix the bugs or is documentation not really important?

Also, do you think getting another "individual" programmer is better or get a company that has programmers working for them, so that if the programmer assigned to my project disappears, another can replace him, without my involvement? I feel this is the approach I should have taken in the beginning.


问:
Overcoming slow problem solving due to increased knowledge of what might go wrong
This has been troubling me for some time, and I'd really appreciate the input of other professionals.

Short background: I started programming when my parents bought me my first computer in 1988 (at age 14, I'm 39 now). I followed a couple of other career paths before finally becoming a professional programmer in 1997. Late bloomer, perhaps, but that's how it was. I'm still happy with my choice, I love programming, and I consider myself good at what I do.

Lately, I've been noticing that the more experience I gain, the longer it takes me to complete projects, or certain tasks in a project. I'm not going senile yet. It's just that I've seen so many different ways in which things can go wrong. And the potential pitfalls and gotchas that I know about and remember are just getting more and more.

Trivial example: it used to be just "okay, write a file here". Now I'm worrying about permissions, locking, concurrency, atomic operations, indirection/frameworks, different file systems, number of files in a directory, predictable temp file names, the quality of randomness in my PRNG, power shortages in the middle of any operation, an understandable API for what I'm doing, proper documentation, etc etc etc.

In short, the problems have long since moved from "how do I do this" to "what's the best/safest way of doing it".

The upshot is that it takes me longer to finish a project than a novice. My version may be rock solid, and as impenetrable as I know how to make it, but it takes longer.

The "create file" example above was just that, an example. Real tasks are obviously more complex, but less suited for a generic question like this one. I hope you understand where I'm going with this. I have no problem coming up with efficient algorithms, I love math, I enjoy complex subjects, I have no difficulties with concentration. I think I do have a problem with experience, and consequently with a fear of errors (intrinsic or extrinsic).

I spend almost two hours a day reading up on new developments, new techniques, languages, platforms, security vulnerabilities, and so on. The conundrum is that the more knowledge I gain, the slower I am in completing projects.

How do you deal with this?

答:
My best recommendation for you is: building blocks.

Make a file building block that you can trust always, make one for your API, stop wasting your time writing the same thing over and over. Think about every problem once and fix it once and for all.

Noone will catch up to that, certainly not the novice who spend 80% of their time debugging code that fails for corner cases they don't understand.

Most of all, don't fix problems that cannot happen, such as wrong permissions.

If the permissions are wrong, something is already wrong and you should fix that rather than making your program bullet proof.

At some point you have to just not shoot yourself in the foot instead of always checking whether you did or not.

Instead of spending time on documentation, spend time making your code self-documenting and as short as possible. Replace all those duplicate-ish functions. Shrink your library, rename things with precision.


答:
This is a strange situation, and I'm quite sure you're not telling the whole story. I worked with many people, some of who left for various reasons (me being their colleague), but don't try to tell us that everything was super good and one day just no contact.

But that's not problem. At least not anymore; you should learn from your mistake and try not to repeat it in the future. And yes, I'm strongly suggesting that 50% is your fault of him/her leaving.

Now about solving the current problem:

Try to contact your programmer. He reads your email - offer him money for documentation/fixing the most crucial bugs. No one else will be able to fix those faster than him. Doesn't it work? Try to find where he works, contact that company and tell your story. A good company will not hire a person who could do the same for them. At least they'll tell him to finish the documentation for you.

NOTE: you don't want that person back, you just need finished documentation

Be prepared that your one year worth of work is going to be void. He might have fled when you asked for results and he knew he couldn't deliver. It's possible that the code is full of hacks, dirty implementation and overall poor quality. Even if he comes back - he probably won't have the skills or even time to do it right.

Look for another person. He needs to know the same technologies (programming language, frameworks, etc.). If the code quality is good - he could continue, if not, he'll be able to refactor it. Yes, refactoring takes time with no new feature implementation, but it makes code maintainable and that's what you need. Plus, a person who can refactor bad code is a really good programmer, hold on to him/her.

NOTE: it's silly to pay money up front. The whole idea of salary is to pay for job done. Not for a promise made :)

Make lists. It's in your best interests to have a plan. A technical specification that once read will allow the new programmer to understand the job and milestones. Have at least three important documents:

Overall description of the project - a document that will allow even a non-programmer to know what is the project about.

Timeline - what part and when do you expect to be ready? What is already done?

Technical specification - this is a long one. It is THE document that a programmer wants to read. Separate it into logical parts and describe in as much detail as you can the features and workflow of that specific part.

Working with companies isn't really that good; your chances won't get better. And you'll overpay 10 times if you hire only one programmer. If you have a small team, let's say 3-5 people, just hire a programmer willing to be a team lead. He'll do a much better job managing the team.


答: Using modular decomposition you can create a tree that will contain all particles as leafs and upper nodes will cluster these. Based on that tree you can define measures that are applied to every node of it from the root to the leafs downwards. You stop this downwards traversal when the measurements reach user defined thresholds. One such measurement may be the density of the convex hull of all particles in a cluster.</p>

Title: Algorithm to Find the Aggregate Mass of "Granola Bar"-Like Structures?

Body:
I'm a planetary science researcher and one project I'm working on is N-body simulations of Saturn's rings.  The goal of this particular study is to watch as particles clump together under their own self-gravity and measure the aggregate mass of the clumps versus the mean velocity of all particles in the cell.  We're trying to figure out if this can explain some observations made by the Cassini spacecraft during the Saturnian summer solstice when large structures were seen casting shadows on the nearly edge-on rings.  Below is a screenshot of what any given timestep looks like.  (Each particle is 2 m in diameter and the simulation cell itself is around 700 m across.)

The code I'm using already spits out the mean velocity at every timestep.  What I need to do is figure out a way to determine the mass of particles in the clumps and NOT the stray particles between them.  I know every particle's position, mass, size, etc., but I don't know easily that, say, particles 30,000-40,000 along with 102,000-105,000 make up one strand that to the human eye is obvious.

So, the algorithm I need to write would need to be a code with as few user-entered parameters as possible (for replicability and objectivity) that would go through all the particle positions, figure out what particles belong to clumps, and then calculate the mass.  It would be great if it could do it for "each" clump/strand as opposed to everything over the cell, but I don't think I actually need it to separate them out.

The only thing I was thinking of was doing some sort of N2 distance calculation where I'd calculate the distance between every particle and if, say, the closest 100 particles were within a certain distance, then that particle would be considered part of a cluster.  But that seems pretty sloppy and I was hoping that you CS folks and programmers might know of a more elegant solution?

Edited with My Solution:  What I did was to take a sort of nearest-neighbor / cluster approach and do the quick-n-dirty N2 implementation first.  So, take every particle, calculate distance to all other particles, and the threshold for in a cluster or not was whether there were N particles within d distance (two parameters that have to be set a priori, unfortunately, but as was said by some responses/comments, I wasn't going to get away with not having some of those).

I then sped it up by not sorting distances but simply doing an order N search and increment a counter for the particles within d, and that sped stuff up by a factor of 6.  Then I added a "stupid programmer's tree" (because I know next to nothing about tree codes).  I divide up the simulation cell into a set number of grids (best results when grid size ≈7 d) where the main grid lines up with the cell, one grid is offset by half in x and y, and the other two are offset by 1/4 in ±x and ±y.  The code then divides particles into the grids, then each particle N only has to have distances calculated to the other particles in that cell.

Theoretically, if this were a real tree, I should get order N*log(N) as opposed to N2 speeds.  I got somewhere between the two, where for a 50,000-particle sub-set I got a 17x increase in speed, and for a 150,000-particle cell, I got a 38x increase in speed.  12 seconds for the first, 53 seconds for the second, 460 seconds for a 500,000-particle cell.  Those are comparable speeds to how long the code takes to run the simulation 1 timestep forward, so that's reasonable at this point.  Oh -- and it's fully threaded, so it'll take as many processors as I can throw at it.


答:
Just adding to what everyone has said,

If you can't get the old programmer to document his/her code even at a price, then don't expect someone else to be able to document it any better. So here are some options on what you can do for now to make the new programmer productive on day one.

Get a bug database, and start entering all the bugs you found into it. This is the programmer's priority to-do list. Document it well and put in as much detail as possible (source file/root cause, what it does, and what it should do). There are lots of free bug tracking software, like Bugzilla, Redmine and JIRA. Feel free to use whichever you like.

Create a specification sheet for your project. This will give the new programmer some direction after the bugs have been cleared. You can check out Joel's guide on writing specifications.

Create a schedule or a time line for your project. They should have deadlines and milestones in which they get paid for work they rendered rather than paying them in advance.

Now that that's out of the way, you can start looking for a programmer. And like Creative Magic said, outsourcing the job to companies can lead to disaster or blow up the price to infinity and beyond.

This time around, start planning properly for the bus factor when hiring programmers. People come and go and there is nothing you can do about it, so prepare for the worst this time by getting two programmers, or as Uooo said, get one programmer and one tester.

Now, once the programmers are in the shop with you, you can start asking them to document their code going forward rather than asking them to document old code, really, forget that.

Other things to consider when getting a new programmer, make sure they know source control and automated testing. Also, try to get as many checks on the Joel Test as much as possible with their help, you can only do so much of this on your own.


答:
Based on that interaction we had in the comments, I'll go with the assumption that you didn't drive your only developer away because of personal things.  However, basing on that conversation, I'll make another guess that this setback is still mostly your responsibility as a hiring manager.  As you mentioned you don't have AT ALL any experience with developers, but then how do you make a decision on how to hire one?

It sounds like you did your best, but you hired somebody who simply couldn't handle the scale of this project, he built shaky foundation which crumbled under him and then he simply left.  Unfortunately, the difference between developers and entrepreneurs is that the former get paid hourly/salary but they can choose to come and go as they please.  He got paid for the hours he worked and he left when he chose not to get paid anymore. Nothing you can do about that.

So what now?  It seems like you started going down the path of replacing people with process. If only you had enough documentation, people could leave and others could pick up where they left off.  IMO that doesn't work and if it does work, it'll still be way more expensive than having a reliable team of permanent employee(s).  Management at various companies over the last 30 years have tried to replace people with enough documentation (including my last job) and they failed every time. That's why I decided to switch jobs and now they are stuck with their outdated and never accurate documents, while I'm having the time of my life in a new startup.

What I would do if I were you would be to try to find the right person with enough skills and experience to pick up this project and carry it to completion. This not only includes coding skills, but also design, architecture as well as basic project management. Do not try to define how he does his work, or how many documents he needs to produce. Just focus on finding the right person and be prepared to pay accordingly. When you do find him, make sure your role is to support him and remove obstacles from his way, not monitor/micromanage. I'm not implying that you did that before, but I do know a lot of managers tend to do that and that's just counter productive.

Talk to other entrepreneurs, possibly those with more software engineering background. Read these forums and come up with a set of questions to ask your prospective hire. Present the problem and ask what the approach would be.  If he is the right guy (and assuming he didn't see this page), he should be able to suggest a lot of the things that other people already suggested in terms of what should be done in your company as you start recovering.  Ask him to define a plan from the time he is hired to when your v1.0 will ship. How will he get you there.  Ask for help interviewing such a person.

Just few of my own thoughts: Bug tracking is a must (Jira costs $10 for a team of up to 10 people). Source control is a must (git is free. perforce costs peanuts for a team of up to 5 or so people).  Your code is your documentation. Not your written word documents. He should review the code and keep what is salvageable; throw out the rest and focus on writing maintainable and readable code.  Save documentation for few high-level, few-page design docs. He must know the technology you are working on. Don't hire someone with just good intentions; you can't afford to have them learn on your time.  Ask them what other projects they've done (unfortunately you or someone you find might have to keep up with technical aspect of things). You are looking for someone with enough experience but at the same time not too much that that spark of excitement has already burned out. Find someone who is hungry to make an impact. The methodology he proposes or follows should allow you to see work on regular (one or two weeks periods) basis and to provide instant feedback. Don't hire ANYONE who says, it'll be ready in exactly 7.4 months, I'll let you know when it's done.

Good luck


答:
My first suggestion is to cut up your problem into two problems: first, figure out what you want and then figure out how to efficiently get what you want. You can't efficiently get something you haven't defined yet. I'll put some ideas in this answer that may help you find this definition. I suggest you make an inefficient implementation of the ideas you like first, apply it to a few not-too-large datasets, evaluate the results by hand, adapt your definition and repeat (possibly asking another question here), until you are happy with your definition. After that, I suggest you ask another question on how to efficiently compute the result of your definition (if you still need help).

So, let's see what would correspond with our intuitive idea of a 'strand'. Your strands seem to consist of roughly uniformly distributed points, though you should check this by making a zoomed-in picture (of the original dataset) - the resolution of your picture is too low to say with certainty that the points really are roughly uniformly distributed. I'll assume they are for this answer.

An initial idea may be to look at the nearest neighbor of every point. Let's pick a point X, call its nearest neighbor Y and set D as the distance between X and Y. We then look at the circle C around X with radius D*A, where A is a tuning parameter, say A=3. If X is part of a strand, we expect that for every point Z in C, the distance from Z to its nearest neighbor W is about the same as D. If it is significantly shorter, say more than A (or maybe some other parameter B) then X is apparently near to points that are much nearer to each other than to X, so X is probably not part of a strand.

This criterion is not complete however. It only gives a criterion to detect a 'border' between between areas dense with points and areas less dense with points. We still have to cluster points together into strands.

There is a feature in your picture that shows that this is not simple. In the lower-right corner of your picture, there is a relatively large area with a lot of stray points. These stray points are themselves roughly uniformly distributed, so if we were to remove all points in the strand around it (and all other points), then we would expect any strand-detecting algorithm to mark this set of stray points as a strand! We therefore need to be careful when making our clusters.

An idea may be to do the following. We are going to make a graph on these points, where the vertices are the points and edges signify that two points have similar density. For every point, we check the criterion above. If it checks out, we connect X with an edge to all points in C. If it does not check out, we do not add any edge, and mark X as 'stray'. After doing this for every point, we consider the set of connected components. These should consist of a single (in the case of your picture, but other datasets may have multiple) connected component consisting of all points in strands, plus (potentially a lot) more components consisting of single stray points and these 'stray strands'. However, these stray strands have points in them that have been marked as 'stray', so you can simply ignore any component containing a point that has been marked as 'stray'.

A danger of this idea is that you may have a feature where the density of a strand progressively lowers as you move along the strand, until the density is so low that it is just a set of stray points. As our criterion is 'local', it may not detect this and mark these stray points as part of the strand. I'm not sure if this will be a problem: I'd guess most stray points should be caught by the criterion, as changes in density seem quite abrupt in your picture.

If this problem does occur, you could try an alternative to just taking the connected components. For every point X, we calculate the distance to its nearest neighbor D(X). We start at the point with minimal D(X) and perform a BFS (or DFS, the order doesn't matter). We add any point Y whose D(Y) is not much larger than the D(X) (by a tunable factor) we started with. If we do encounter a point Y that has too large D(Y), we remove the edge (X, Y), mark Y as 'stray' and act as if we never visited Y in our BFS. If tuned right, this should prevent the problem I describe above.

An alternative idea to fix this problem acts a bit more local: you could do a BFS and keep track of the lowest D(X) (I use D(X) as a measure of the density around a point) encountered at most say 10 BFS-steps before, and if we encounter a Y that has D(Y) that is much larger than this D(X), we do the same as the other (potential) solution I offered.

As a disclaimer: all the ideas above I thought up on the spot just now, I don't really know if this particular problem has been studied before, so I may just be sprouting nonsense. Just try out the ideas (whether my ideas or your own) that sound sensible to you and find out if they really work, and only then focus on implementing them efficiently.


问:
Reconciling contradictory programming advice: get something working and iterate vs. really think it through before coding
I am an intermediate programmer with a few years of professional experience who is halfway through a masters degree. In learning to program I've often heard two pieces of seemingly contradictory advice.

The first piece of advice was get something working quickly, see how it works (either through prototyping or informal testing), improve the version , see how it works again, improve it again...and then repeat the cycle until you're done. This is sometimes called "spiral development" or phrased as "release early, release often."

The second piece of advice was: really think a project through before ever writing any code.

I've had success with both methods and I would say that I agree with each philosophy.

But now I'm starting to tackle much more complex projects that I have no idea how to complete (like distributed applications and performance-driven graphics programming).

How do I go about these projects?

Do I just start coding SOMETHING and learn (platforms/methods/languages/architectures) as I go -- or do I hold off from coding and do a ton of research/reading before I even open the IDE?

How do I reconcile these contradictory pieces of programming advice?

答:
"Iteration" and "thinking it through" are not contradictory, instead they are complementary.

Even at their extremes, they reflect two paths to get to the same place.

The extreme of Iteration is a thousand monkeys banging away at a thousand keyboards.  With enough time maybe you'll get something that meets the requirements.

The extreme of "think it through" is a Waterfall approach.  If you're lucky the requirements haven't dramatically changed from the start of the project by the time you deliver code. Or you'll just end up with analysis paralysis and have delivered nothing.

You have to have some understanding of the domain and the problem before you start coding.  This is the "think it through" part.  Ideally, you'll see the high level path from beginning to end on how to solve the problem.

But you may only see major portions of that path, and certainly not every stop along the way.  That's where iteration comes into play.  You can start iterating through versions of the application and seeking feedback in order to:

Identify the roadblocks that come up in the lower levels of detail

See stakeholder feedback to clarify those murky areas in the high level path.

The latin root of decide means to "cut off".  Iteration allows you to decide what works in practice instead of just theory and iteration allows you to cut out the other options that aren't feasible.

So you have to think the problem through in order to understand what you're going to do.  But then you need to iterate through versions of the application in order to actually transform the idea into actual code.


问:
Is it good practice to put bug analysis and fix code in bug report?
When I fix a bug I mention briefly what was the issue and in which revision its fixed. But this way nobody would know how much tricky the issue was and how much effort went in analysis and findings.

What is the best practice for a developer to show such things to higher management to get noticed?

答:
To put bug analysis in there is a good practice, for the reasons you mentioned (just avoid being overly verbose).

This way, people reading it (including your future self) would know how much tricky the issue was and how much effort went in analysis and findings. Also, this way simplifies maintenance in the case when further changes are required related to your fix, because one could read bug report and understand why things were changed one or another way.

Just don't expect this to directly make you get noticed by higher management, because this is a different matter, a matter of workplace visibility, and this would require other skills and approaches. For the purpose of visibility, details you put into bug reports play only auxiliary, secondary role, allowing you to quickly find and get these details when necessary. Being capable to quickly pull out a clear explanation for tricky technical matters may give one a certain edge visibility wise, but it does not guarantee a major advantage.

To put fix code (except for snippets that are relevant in your analysis) into a bug report is another matter, typically a bad practice, as it is expected to be in VCS.

Good issue trackers integrated with VCS can even automatically refer readers to changes related to the fix. For an example on how this could be, take a look on Integrating JIRA with Subversion:

JIRA's Subversion integration lets you see Subversion commit information relevant to each issue. Subversion integration can be implemented either by using Atlassian FishEye or the Subversion add-on... both solutions allow you to link JIRA to related code changes in Subversion.

Commits will appear in this tab if the commit log mentions the issue key ('TEST-3' above)...


答:
Management doesn't see it that way.

An employee who solves a problem in a short time will always be considered more valuable than one who solves a problem in a longer time. It doesn't matter if one problem was way harder to understand and way more important for the project - you can usually assume that your higher-ups don't understand the technical issues at stake, and they will assume that every underling exaggerates the difficulty of whatever they are given, Scotty-from-Star-Trek-style.

What you should do to prove your worth is to establish formal metrics that are applied to your workflow and excel at them. For instance, a measurement that managers seem to like is a rate of turnover (story points fulfilled, number of issues resolved).

Title: Is it good practice to put bug analysis and fix code in bug report?

Body:
When I fix a bug I mention briefly what was the issue and in which revision its fixed. But this way nobody would know how much tricky the issue was and how much effort went in analysis and findings.

What is the best practice for a developer to show such things to higher management to get noticed?


问:
How large non-OO code bases are managed?
I always see abstraction is a very useful feature the OO provides for managing the code-base. But how are large non-OO code bases are managed? Or do those just become a "Big Ball of Mud" eventually?

Update:

It seemed everyone is thinking 'abstraction' is just modularization or data-hiding. But IMHO, it also means the use of 'Abstract Classes' or 'Interfaces' which is a must for dependency-injection and thus testing. How non-OO code bases manage this? And also, other than abstraction, the encapsulation also helps a lot to manage large code bases as it define and restrict the relation between data and functions.

With C, it is very much possible to write pseudo-OO code. I don't know much about other non-OO languages. So, is it THE way to manage large C code bases?

答:
Modules, (external/internal) functions, subroutines ...

as Konrad said, OOP is not the only way to manage large code bases. As a matter of fact, a rather lot of software was written before it (before C++*).


答:
I have been working on a project, where it was "standard" to put code of a bug fixes in Word file. We were a team of three developers and a manager and manager was incapable of using version control software to do exactly what it was posted in Word file. The thing died throughout project development, as us developers didn't see the value and forgot to update files.
I would not go down this path again.

However, there is nothing wrong with bug analysis report. But don't over do it. If there is no crisis and bug didn't cause business damage, it is just a waste of time.


答:
Here's how I'd approach the problem :

You have the domain knowledge. You know which features are available on the website now, which ones you'd like to add in the future, and can probably list a few bugs that were reported by users, too.

There's this pile of code sitting there, left to itself in a corner. It might be buggy, but it still delivers value since the site has active users. A complete rewrite would thus be a mistake IMO.

The bridge between your domain expertise and the code was broken when the programmer left. You need to rebuild it so that the code base can be synchronized with your requirements again and that future updates can be developed.

The thing is, that bridge can't be entirely made of documentation. Software is a human matter as much as it is technical. If you don't explain the new programmer what you expect in great detail, he or she'll have a hard time deducing that from the code alone - all the more so if the previous programmer wrote cryptic, poorly documented, poorly tested code. And if you don't work in close wollaboration with the new programmer to find an automated, continuous way to verify the code matches your requirements, in other words to make the bridge more robust, the problem is doomed to repeat itself.

Regularly sit down (even virtually) with the new programmer for domain knowledge processing sessions. During each of these sessions, write together the specifications for a small part of your product. It can be a single web page, it can be a feature. Making them executable specifications (a la Behavior-Driven Development) will increase your level of confidence that the bridge works, because you can run them continuously and be warned when there's something wrong. It will also make the developer's life easier.

After a session, the developer is able to return to his work and
write lower-level tests which validate that the current code complies with the
spec. If it doesn't comply, then the programmer has everything he
needs to fix it. It's also important to remain available for any questions he could have.

Try to maintain a tight, continuous collaboration between you and the programmers on your project, and make sure this is also true between them. This is necessary if you want the functional and technical culture around your project to live on, avoiding issues like the one you're having now. This of course requires not only 2+ developers working on your project, but also that they share with one another the knowledge about everything they write. Thus one can act as a failover when another gets missing. Techniques such as pair programming and code reviews are good ways to achieve that.


答:
It makes sense to put a decent amount of information in there, but whether it will help you "get noticed" is debatable.

It might be one tiny thing in a list of many other things that mark you down as a conscientious developer which management may pay attention to.


问:
How to create a use case diagram for board game played on PC
I'm struggling with a task as I was given to practice UML and use cases. The problem is that I should model computer version of a board game so I am unsure about a few things. obviously it does not matter if you play against the PC or another player, the actions are the same.
The game is simply like tic tac toe.

E.g.

Actor Player ---(Place a diamond)-----include---->(Check for a row)---include-->(Swap players)

But the game is played on the PC, so is Check for row really a use case? And the same with Swap players? Because the system would do that. On the other hand, if it was not, how could I continue?

答:
There is no strict rule for the level of abstraction you choose for your use case diagrams, but in general I would not model them too "low level". For a real-world scenario, you would probably model the game play as just one single use case. If your game has some kind of administrative mode (for example, to change some options), that maybe seen as a different use case.

The things you mentioned above like checking for rows and swapping players are better modeled by an activity diagram.

EDIT: in terms of use cases, IMHO it does matter if you play against the PC or another player. Only because the rules of the game are the same, the interaction with the system is quite different (for example, if this is a desktop program, for playing against another human you might use a network connection, need a "chat mode", and so on).


答:
"What is the best practice for a developer to show such things to higher management to get noticed?"

In my experience, higher management usually doesn't have the capacity to understand what you would have typed anyway.  The further away from development you get, the less they deeply understand.  If you do have higher management that is competent to your level, then simply talk to them.  I've found that higher management geeks are still geeks and love talking about geeky hacks.

If you are truly interested in self-promotion, keep a log book of all your successes, along with how difficult they were.  When review time comes around, you will be prepared with specific examples.

"As a software developer, is it good practice to put bug analysis and fix code in bug report?"

Bug analysis?  Yes.  Other developers need to see how you fixed the bug if they run across a similar problem, especially because pulling a diff and figuring it out can be tedious (if you are leaving the old code commented and describing the entire fix in a comment, shame on you).

Fix code?  Absolutely not.  DRY is not only within the code base, but within artifacts and process information: tie the checkin to the bug/case number either via tooling or the checkin comments, and if they want to see how you fixed it, it should be easily retrievable.  Think of it this way: if they have the capacity to view and understand code and really understand the complexity of your work, then they probably have access to source control anyway.


答:
I would agree that 'Check for a row' or 'Change turns' are not use cases but activities done by computer.
In that case, all that use can do would be performing a move, i.e. Placing a diamond.</p>

Title: How to create a use case diagram for board game played on PC

Body:
I'm struggling with a task as I was given to practice UML and use cases. The problem is that I should model computer version of a board game so I am unsure about a few things. obviously it does not matter if you play against the PC or another player, the actions are the same.
The game is simply like tic tac toe.

E.g.

Actor Player ---(Place a diamond)-----include---->(Check for a row)---include-->(Swap players)

But the game is played on the PC, so is Check for row really a use case? And the same with Swap players? Because the system would do that. On the other hand, if it was not, how could I continue?


答:
Every place I've worked, we had at least two mechanisms for documenting bug fixes.  A changelog edited by the developer, and the commit log also edited by the developer.  The latter is typically just entered as a "message" when you commit the file to source control.

I always follow two principles when fixing a bug and committing it.

First, I always enter a brief summary of the bug, the fix, and the module it's applied to in the changelog.  Always keep in mind your audience for this text:  everybody.  From the other developers and yourself, to support and QA, the sales staff and even the customers.  Everybody needs to understand your log entry.  That means that to a certain extent you're writing to the lowest common denominator, but you still have to describe the bug and the fix in such a way so that the explanation is clear and not embarrassing to the company.  Remember, the customers might read this.  And be brief.  I target less than 10 words.

Second, I add detailed information about the problem and the fix in the commit log.  The audience for this text is very narrow:  yourself and other developers.  Get as technical and detailed as is useful.  Since this is being committed to source control, it will be there forever in the form of a history log.

Also since the change is being comitted to source control, recall that source control itself is a change documentation tool that can and is used to explain technical changes.  If a developer sees something in the change log that they want very specific details about, they will check the source control history and compare your change to the old version side-by-side.  I do this all the time.  This means you do not need to be verbose in any of your log entries about the what you changed.  My verbose log entries are rare, and they are always focused on the why.  The again, the why should also be documented in the code as comments.

Now, as to your question:

What is the best practice for a developer to show such things to
  higher management to get noticed?

Emphasis mine.  Let's talk about this.  Coming from the perspective of higher management, I'm going to suggest that you don't.  You will just come off as a whiney blowhard, always complaining about how hard your job is and how awesome you are.  At least it could be perceived that way.  It reflects badly on you to bloviate.  Stick to the facts, get your work done, and kick ass.  You will get noticed through the quality of your work.  If you don't, move on.


问:
Why I'm not selected in an interview?
I'm working in development for 4 years, and 3.5 in PHP - why I don't seem to be able to be selected in an interview.

I want to know what special things the interviewer wants to see in candidates - for senior PHP developer roles.

Interviewer asks me 10 questions and I'm able to answer only 5. Does selection depend on these things? It doesn't mean that I can't solve the problem, I can google the question, I can ask on forums. Why don't they understand that a man can't remember all the answers for each and every question? Especially programming ones.

Please advise.

答: Reason 1 : You have bad English</p>

Title: Why I'm not selected in an interview?

Body: Reason 1 : You have bad English


问:
How do I include Implementation and Usage Documentation in one file
There are two types of documentation.

One type, the Implementation Documentation, contains information about specific implementation of a construct (eg. Class, Method, etc.). It is targeted to the future me, maintainer, debugger and so on.

And there is Usage Documentation, containing information how to use a provided api. It does not contain information about specific implementation and is targeted to users of the api.

How do I include both of them in one file? (Or do I include both of them in one file? And if not, what type belongs into the source file?)

Are there special techniques, using java-doc and/or best practices?

答:
Both can be tied to the source files.

Implementation Documentation is tied to the code, reflecting development decisions, and goes inside the source file along with code it is related to.

Usage Documentation in Java can be provided in javadoc format, from which the API documentation (e.g. HTML files) can be extracted. It is ideally neutral with regards to implementation but is still tied to the code so it can be looked into while using the API classes when developing using an IDE and you pass the mouse over the class/method.

```<code>/** <b>Usage Documentation</b> in javadoc format providing class description and usage. */
public class PublicClass {

    /** <b>Usage Documentation</b> in javadoc format providing method description and usage.
      * @param aParameter parameter description.
      * @return either the operation succeeded or not.
      * @throws SomeException if an exception occurred.
      */
    public boolean publicMethodThatBelongsToTheAPI(int aParameter) throws SomeException {

        /* Implementation Documentation (non-javadoc) */
        doSomething();

        (...)
    }

    private void doSomething() {
        // More implementation documentation
        (...)
    }
}
</code>```

Body:
Both can be tied to the source files.

Implementation Documentation is tied to the code, reflecting development decisions, and goes inside the source file along with code it is related to.

Usage Documentation in Java can be provided in javadoc format, from which the API documentation (e.g. HTML files) can be extracted. It is ideally neutral with regards to implementation but is still tied to the code so it can be looked into while using the API classes when developing using an IDE and you pass the mouse over the class/method.

/** <b>Usage Documentation</b> in javadoc format providing class description and usage. */
public class PublicClass {

    /** <b>Usage Documentation</b> in javadoc format providing method description and usage.
      * @param aParameter parameter description.
      * @return either the operation succeeded or not.
      * @throws SomeException if an exception occurred.
      */
    public boolean publicMethodThatBelongsToTheAPI(int aParameter) throws SomeException {

        /* Implementation Documentation (non-javadoc) */
        doSomething();

        (...)
    }

    private void doSomething() {
        // More implementation documentation
        (...)
    }
}


答:
Use cases model the different actions or sequences of actions that happen while "actors" are interacting with the "system", f.ex. using the application. The way I see it, "checking a row" is not a use case, it is an step in the program itself.

In UML context, consider what actions the actor, here the player, takes while playing their turns? And, what are the outcomes, in the context of the game itself?


问:
How can I unit test a class which requires a web service call?
I'm trying to test a class which calls some Hadoop web services. The code is pretty much of the form:

```<code>method() {
    ...use Jersey client to create WebResource...
    ...make request...
    ...do something with response...
}
</code>```

e.g. there is a create directory method, a create folder method etc.

Given that the code is dealing with an external web service that I don't have control over, how can I unit test this? I could try and mock the web service client/responses but that breaks the guideline I've seen a lot recently: "Don't mock objects you don't own". I could set up a dummy web service implementation - would that still constitute a "unit test" or would it then be an integration test? Is it just not possible to unit test at this low a level - how would a TDD practitioner go about this?

答:
In my opinion you should mock the webservice calls if this is a unit test, as opposed to an integration test.

Your unit test should not test whether the external webservice is working, or whether your integration with it is correct. Without getting too dogmatic about TDD, note that a side effect of turning your unit test into an integration test is that it's likely to run slower, and you want fast unit tests.

Also, if the webservice is temporarily down or working incorrectly, should this cause your unit test to fail? It doesn't seem right. Your unit test should fail for only one reason: if there is a bug in the code in that "unit".

The only portion of code that is relevant here is ...do something with response.... Mock the rest.


问:
Naming boolean field that is a verb
In Java, by convention getter and setter for boolean fields will be isField() and setField(). This works perfectly fine with field names that are adjectives like active, visible, closed, etc.

But how do I name a field that has meaning of a verb, like haveChildren? Add “_ing” to the verb (havingChildren), maybe?

To clarify, I don't have control of the method names (getter and setter) as they are auto-generated by the IDE. So what I need is an appropriate field name so that when the IDE generate a getter for it, it make senses. For example, hasChildren is a perfect field name, but when the IDE generate the getter for the field it would be isHasChildren. How do I solve this?

答: You could put does before the verb. Such as doesHaveChildren in your example you provided. Or perhaps shouldHaveChildren depending on the context.

Title: Naming boolean field that is a verb


问:
is it bad that I have no html, or javascript in my php files
I have been writing my website, front-end: html, JS, jquery and css, back-end: php mysql. However my php files only contain php and mysql code. Is this a really bad thing? In what situation should PHP files contain html/javascript?? Currently my php files are just there to receive request and response with array of information. I just dont understand why people would put front-end stuff in back-end, is it for security?</p>

答:
I think that it a good practices to separate front-end to back-end.

I am supposing that you are using AJAX to communicate with the back-end, and it is the reason why you are not using HTML/JavaScript in your PHP files. If you have to create a dynamic web page without AJAX, you have to write some HTML code in your PHP file.

Doing every front-end operations with JavaScript imply that these operations are done by the browser. If you prepare the HTML on the server side, the browser just render the code without extra effort.

OwnerDisplayName: Federico