问:
How does persistence fit into a purely functional language?
How does the pattern of using command handlers to deal with persistence fit into a purely functional language, where we want to make IO-related code as thin as possible?

When implementing Domain-Driven Design in an object-oriented language, it's common to use the Command/Handler pattern to execute state changes. In this design, command handlers sit on top of your domain objects, and are responsible for the boring persistence-related logic like using repositories and publishing domain events. The handlers are the public face of your domain model; application code like the UI calls the handlers when it needs to change domain objects' state.

A sketch in C#:

```<code>public class DiscardDraftDocumentCommandHandler : CommandHandler<DiscardDraftDocument>
{
    IDraftDocumentRepository _repo;
    IEventPublisher _publisher;

    public DiscardDraftCommandHandler(IDraftDocumentRepository repo, IEventPublisher publisher)
    {
        _repo = repo;
        _publisher = publisher;
    }

    public override void Handle(DiscardDraftDocument command)
    {
        var document = _repo.Get(command.DocumentId);
        document.Discard(command.UserId);
        _publisher.Publish(document.NewEvents);
    }
}
</code>```

The document domain object is responsible for implementing the business rules (like "the user should have permission to discard the document" or "you can't discard a document that's already been discarded") and for generating the domain events we need to publish (document.NewEvents would be an IEnumerable<Event> and would probably contain a DocumentDiscarded event).

This is a nice design - it's easy to extend (you can add new use cases without changing your domain model, by adding new command handlers) and is agnostic as to how objects are persisted (you can easily swap out an NHibernate repository for a Mongo repository, or swap a RabbitMQ publisher for an EventStore publisher) which makes it easy to test using fakes and mocks. It also obeys model/view separation - the command handler has no idea whether it's being used by a batch job, a GUI, or a REST API.

In a purely-functional language like Haskell, you might model the command handler roughly like this:

```<code>newtype CommandHandler = CommandHandler {handleCommand :: Command -> IO Result)
data Result a = Success a | Failure Reason
type Reason = String

discardDraftDocumentCommandHandler = CommandHandler handle
    where handle (DiscardDraftDocument documentID userID) = do
              document <- loadDocument documentID
              let result = discard document userID :: Result [Event]
              case result of
                   Success events -> publishEvents events >> return result
                   -- in an event-sourced model, there's no extra step to save the document
                   Failure _ -> return result
          handle _ = return $ Failure "I expected a DiscardDraftDocument command"
</code>```

Here's the part I'm struggling to understand. Typically, there'll be some sort of 'presentation' code which calls into the command handler, like a GUI or a REST API. So now we have two layers in our program which need to do IO - the command handler and the view - which is a big no-no in Haskell.

As far as I can make out, there are two opposing forces here: one is model/view separation and the other is the need to persist the model. There needs to be IO code to persist the model somewhere, but model/view separation says that we can't put it in the presentation layer with all the other IO code.

Of course, in a "normal" language, IO can (and does) happen anywhere. Good design dictates that the different types of IO be kept separate, but the compiler doesn't enforce it.

So: how do we reconcile model/view separation with the desire to push IO code to the very edge of the program, when the model needs to be persisted? How do we keep the two different types of IO separate, but still away from all the pure code?

Update: The bounty expires in less than 24 hours. I don't feel that either of the current answers has addressed my question at all. @Ptharien's Flame's comment about acid-state seems promising, but it's not an answer and it's lacking in detail. I'd hate for these points to go to waste!

答:
As near as I can understand your question (which I may not, but thought I'd throw in my 2 cents), since you don't necessarily have access to the objects themselves, you need to have your own object database that self-expires over time).

Ideally the objects themselves can be enhanced to store their state so when they get "passed around", different command processors will know what they are working with.

If that isn't possible, (icky icky), the only way is to have some common DB-like key, that you can use to store the info in a store that is setup to be shareable between different commands -- and hopefully, "open up" the interface and/or the code so any other command writers will also adopt your interface on saving and processing meta-information.

In the area of file servers samba has different ways of storing things
like access lists and alternate data streams, depending on what the host OS provides.  Ideally, samba is being hosted on a file system provides extended attributes on files.  Example 'xfs' on 'linux' -- more commands are copying extended attributes along with a file (by default, most utils on linux "grew up" w/o thinks like extended attributes).

An alternative solution -- that works for multiple samba processes from different users operating on common files (objects), is that if the file system doesn't support attaching the resource directly to the file as with extended attributes, is using a module that implements a virtual file-system layer to emulate extended attributes for samba processes.  Only samba knows about it, but it has the advantage of working when the object format doesn't support it, but still works with diverse samba users (cf. command processors) who do some work on the file based on its previous state.  It will store the meta information in a common database for the file system which helps in controlling the size of the database (and doesn't need expiration of entries unless the files are deleted) -- if samba is the only accessor (the common interface) to the files, then it can transparently provide the same features to files on any file system, that otherwise would be
file-system format specific (similar to different formats of data representation when objects are done by different people or teams).

It may not be useful to you if you needed more information specific to the implementation you are working with, but conceptually, the same theory could be applied to both problem sets.  So if you were looking for algorithms and methods to do what you want, that might help.  If you needed more specific knowledge in some specific framework, then maybe not so helpful... ;-)

BTW -- the reason I mention 'self-expiring' -- is that its not clear if you know what objects are out there and how long they persist.  If you have no direct way of knowing when an object is deleted, you'd have to trim your own metaDB to prevent it filling with old or ancient
meta info that the users have long since deleted the objects for.

If you know when the objects are expired/deleted, then you are ahead of the game, and can expire it out of your metaDB at the same time, but it wasn't clear if you had that option.

Cheers!


问:
Why are string resources generally kept external to the code and not inside the code?
Generally, on many platforms, I'm writing my string resources to a .resx or .xml file, and then I'm getting them using some platform-dependent approach.

That is, on iOS, I'm getting them via NSBundle.MainBundle, and by using Context.Resources on Android.

What are the advantages of this approach, and why not having it directly accessible in the code, so, for example:

In a cross-platform project, any platform can access it directly, with no integration.

There are no concerns during building about whether or not the resources built well.

The coder can use functionalities such as multilanguage handling

Long story short: what is the reason why string resources are structured that way?

[Edit]

Let's say that my file is part of a "core" project shared between other project. (Think about a PCL, cross-platform project file structure.)

And suppose that my file is just totally similar to a .resx/.xml file, looking like this (I'm not a pro in xml, sorry!):

  Parameters
  Paramètres

So, this is basically a custom xml, where you point to the key/language to get the proper string.

The file would be part of the application just like you add any accessible file inside an app, and the system to access the string resources, coded using PCL. Would this add an overhead to the applications?

答:
In addition to internationalization/localization, separating text strings out like this also allows a proofreader to submit corrections to spelling/grammar/punctuation that are isolated to, messages.${LOCALE}, without having to touch a true source code file.  You might have a blackout on code changes but accept such text corrections.  If you are accepting concurrent changes to both code and messages, keeping them separated makes it easier to merge the patches, provided that the code changes don't redefine any messages that existed when the proofreader checked out messages.en_US.

Also, depending on how it's implemented, it may not even be necessary to relink the application.  The code may simply grab line 138 from messages.${LOCALE} for a particular message, with the line number being determined at run time.

ContentLicense: CC BY-SA 3.0


问:
Is the Adapter the correct design pattern for this situation?
I have an instance of a class UntouchableClass of which I need to access the member variables to use in my DotLiquid template. Problem is, UntouchableClass has to inherit from Drop if I want to use it in my template, but I can't change it since it is from an existing library.

I've read about the Adapter pattern, but UntouchableClass does not have an interface from which to inherit the Adapter.

Also, I can't use multiple inheritance (I would create a class which inherits from both UntouchableClass and Drop but this is C# and from what I know this isn't possible).

Is there a design pattern that would suit this situation? Or is there a particular way to do this using DotLiquid?

答:
I won't accept my answer since it isn't directly linked to my question, but here is what worked:

DotLiquid has different rules for template rendering parameters. I thought Drop inheritance was essential, but it turns out it's only one possible condition.

There is a method called Template.RegisterSafeType(Type type, string[] allowedMembers) made specifically for this case.

For some examples, see here: TemplateTests

OwnerDisplayName: Deinonychus


问:
Android apps and GPLv2 classpath exception
My Android app needs javax.activation and javax.mail (both GPLv2 licensed). However, I don't want to make my app GPL-licensed. What are the possibilities to not break the license requirements regarding the classpath exception? Currently, I use maven-dependency-plugin to pull those packages' source code and merge the compiled stuff with my own into one apk. Is that ok? If not, what is?</p>

答:
As long as your app does not depend on the internals of those libraries (i.e. you can replace them with a different version without having to modify your code), you are fine and you can distribute your app under any license you like.

This right you get from the classpath exception, which effectively limits the copyleft nature to the GPLv2.


问:
Has test driven development (TDD) actually benefited a real world project?
I am not new to coding. I have been coding (seriously) for over 15 years now. I have always had some testing for my code. However, over the last few months I have been learning test driven design/development (TDD) using Ruby on Rails. So far, I'm not seeing the benefit.

I see some benefit to writing tests for some things, but very few. And while I like the idea of writing the test first, I find I spend substantially more time trying to debug my tests to get them to say what I really mean than I do debugging actual code. This is probably because the test code is often substantially more complicated than the code it tests. I hope this is just inexperience with the available tools (RSpec in this case).

I must say though, at this point, the level of frustration mixed with the disappointing lack of performance is beyond unacceptable. So far, the only value I'm seeing from TDD is a growing library of RSpec files that serve as templates for other projects/files. Which is not much more useful, maybe less useful, than the actual project code files.

In reading the available literature, I notice that TDD seems to be a massive time sink up front, but pays off in the end. I'm just wondering, are there any real world examples? Does this massive frustration ever pay off in the real world?

I really hope I did not miss this question somewhere else on here. I searched, but all the questions/answers are several years old at this point. It was a rare occasion when I found a developer who would say anything bad about TDD, which is why I have spent as much time on this as I have. However, I noticed that nobody seems to point to specific real-world examples. I did read one answer that said the guy debugging the code in 2011 would thank you for have a complete unit testing suite (I think that comment was made in 2008).

So, I'm just wondering, after all these years, do we finally have any examples showing the payoff is real? Has anybody actually inherited or gone back to code that was designed/developed with TDD and has a complete set of unit tests and actually felt a payoff? Or did you find that you were spending so much time trying to figure out what the test was testing (and why it was important) that you just tossed out the whole mess and dug into the code?

答:
I don't like the idea of blindly following any generic advices because I don't believe there's a one-size-fits-all suggestion that will help most developers to become more productive and reduce defects in applications. From my experience, the more you worry about quality the more you'll lose in the amount of delivered new features. So the level of importance you want to give to quality vs deliverability will actually depend on your product and current strategy and most probably it will be someone else that will decide strategically what's more important for the time being: robustness or deliverability.

Even this decision isn't black or white. Most probably some parts of your application must be robust while others don't have to. Once you identify which parts should have a high degree of quality you should focus on them from the testing perspective since you want to ensure high quality to those parts.

All of what I've said so far has nothing to do with TDD specifically in the sense of writing tests before the implementation, but I believe it's important to separate the benefits of having tested code vs writing the tests first.

Once you understand the benefits of testing itself, TDD or not, you can then discuss the testing strategy for the code you want to be covered by tests. Some people will arguee that if you write the tests later you'll miss some conditions in your tests, but I believe you should be the one to evaluate whether that applies to you. It certainly doesn't apply to me.

So, here's how it works for me. There are basically two situations that will make me write tests: it will improve quality only or it will speed up my development of some feature as well. So, a situation where I'll write tests is when there's no new features in the backlog and I can then decide to improve performance of the application, simplify the code base or improve the test suite. Another situation is the need to have a solid working code where bugs would have big enough impact in the real clients. Yet another one is for testing complex code that is easy to break when working on it. As an example, there's a QueryBuilder class in my code base that takes care of lots of use cases and it would be easy to break some of them while fixing a bug or adding a new feature. I know that writing the tests in those cases are very well-worthy since it will save me lots of time in the future and in this specific case this is also a critical part of the application I maintain, so quality is very important here.

Finally, there's the case where writing the tests first enable me to write a feature faster then not writing the tests at all. That QueryBuilder was also a case where this rule has also applied, but it doesn't mean TDD will also be the best path. Another example of TDD helping on development speed is for testing Excel generation for instance, while in the real application you might have to perform several steps each time you want to test some specific condition in the generation. Or if you need to create some records to test a feature and it's hard or impossible to delete them manually after you have manually tested the code.

So, if it's easier for you to reproduce the steps to run some in-development code programatically (through tests), go for it. But if writing the test is more complicate then testing it manually, then you have to decide if this is the time to focus on quality or if you have lots of requests in your backlog and someone in the company will probably know it better and let you know where you should be focusing in accordingly to their current need and company strategy.

In an ideal world all code is tested, but one can't pretend there isn't a trade-off and assume that TDD is always the best and only path. As with all best practices out there you must always focus on what is best for the company you work for instead of what is better for you. Once you become self-employed you are free to decide to perform TDD all the time if you think it is the best path. If your company believes all code should be tested, then you must write tests for all code you write. But for most cases you have to get the big picture and understand the trade-offs before you take any decision. Sorry, but this is not an exact science and there's no easy (or hard) one-size-fits-all answer that you should follow every time.

Just the same as with design patterns. Understand how they work and why they have been created and what kind of problems they solve and what are their drawbacks as well. Understand the reasoning is way more important than remembering the proposed solutions. What is an expensive operation today may be easily achieved tomorrow with other technologies. If the premise for some well stablished solution is no longer valid most probably the solution is no longer the best one to use. When the requirements, available technology or company's strategy has changed you should always reevaluate your toolbox and when that happens you need to understand why you chose each path in the first place instead of taking them for grant as the best options.

OwnerDisplayName: James


问:
How can you decompose a constructor?
Lets say I have a Enemy class, and the constructor would look something like:

```<code>public Enemy(String name, float width, float height, Vector2 position,
             float speed, int maxHp, int attackDamage, int defense... etc.){}
</code>```

This looks bad because the constructor has so many parameters, but when I create an Enemy instance I need to specify all of these things. I also want these attributes in the Enemy class, so that I can iterate through a list of them and get/set these parameters. I was thinking maybe subclassing Enemy into EnemyB, EnemyA, while hardcoding their maxHp, and other specific attributes, but then I'd lose access to their hardcoded attributes if I wanted to iterate through a list of Enemy (consisting of EnemyA's, EnemyB's, and EnemyC's).

I'm just trying to learn how to code cleanly. If it makes a difference, I work in Java/C++/C#. Any point in the right direction is appreciated.

答:
I would reserve sub classing to classes that represent object that you might want to independently use, e.g. character class where all characters, not just enemies have name, speed, maxHp, or a class to represent sprites that have a presence on screen with width, height, position.

I don't see anything inherently wrong with a constructor with a lot of input parameters but if you want to split it up a bit then you could have one constructor that sets up most of the parameters and another (overloaded) constructor that can be used to set specific ones and have others set to default values.

Depending on what language you choose to use, some can set default values for the input parameters of your constructor like:

```<code>Enemy(float height = 42, float width = 42);
</code>```

Title: How can you decompose a constructor?

Body:
I would reserve sub classing to classes that represent object that you might want to independently use, e.g. character class where all characters, not just enemies have name, speed, maxHp, or a class to represent sprites that have a presence on screen with width, height, position.

I don't see anything inherently wrong with a constructor with a lot of input parameters but if you want to split it up a bit then you could have one constructor that sets up most of the parameters and another (overloaded) constructor that can be used to set specific ones and have others set to default values.

Depending on what language you choose to use, some can set default values for the input parameters of your constructor like:

Enemy(float height = 42, float width = 42);


答:
The solution is to bundle up the parameters into composite types. Width and Height are conceptually related - they specify the dimensions of the enemy and will usually be needed together. They could be replaced with a Dimensions type, or perhaps a Rectangle type that also includes the position. On the other hand, it might make more sense to group position and speed into a MovementData type, especially if acceleration later enters the picture. From context I assume maxHp, attackDamage, defense, etc also belong together in a Stats type. So, a revised signature might look something like this:

```<code>public Enemy(String name, Dimensions dimensions, MovementData movementData, Stats stats)
</code>```

The fine details of where to draw the lines will depend on the rest of your code and what data is commonly used together.

Title: How can you decompose a constructor?

Body:
Lets say I have a Enemy class, and the constructor would look something like:

```<code>public Enemy(String name, float width, float height, Vector2 position,
             float speed, int maxHp, int attackDamage, int defense... etc.){}
</code>```

This looks bad because the constructor has so many parameters, but when I create an Enemy instance I need to specify all of these things. I also want these attributes in the Enemy class, so that I can iterate through a list of them and get/set these parameters. I was thinking maybe subclassing Enemy into EnemyB, EnemyA, while hardcoding their maxHp, and other specific attributes, but then I'd lose access to their hardcoded attributes if I wanted to iterate through a list of Enemy (consisting of EnemyA's, EnemyB's, and EnemyC's).

I'm just trying to learn how to code cleanly. If it makes a difference, I work in Java/C++/C#. Any point in the right direction is appreciated.

Body:
The solution is to bundle up the parameters into composite types. Width and Height are conceptually related - they specify the dimensions of the enemy and will usually be needed together. They could be replaced with a Dimensions type, or perhaps a Rectangle type that also includes the position. On the other hand, it might make more sense to group position and speed into a MovementData type, especially if acceleration later enters the picture. From context I assume maxHp, attackDamage, defense, etc also belong together in a Stats type. So, a revised signature might look something like this:

public Enemy(String name, Dimensions dimensions, MovementData movementData, Stats stats)

The fine details of where to draw the lines will depend on the rest of your code and what data is commonly used together.


答:
You might want to take a look at the Builder pattern. From the link (with an examples of the pattern versus alternatives):

[The] Builder pattern is a good choice when designing
  classes whose constructors or static factories would have more than a
  handful of parameters, especially if most of those parameters are
  optional. Client code is much easier to read and write with builders
  than with the traditional telescoping constructor pattern, and
  builders are much safer than JavaBeans.

Title: How can you decompose a constructor?


答:
Using subclasses to preset some values is not desirable. Only subclass when a new type of enemy has different behavior or new attributes.

The factory pattern is usually used to abstract over the exact class used, but it can also be used to provide a templates for object creation:

class EnemyFactory {

    // each of these methods is essentially a template for a kind of enemy

    Enemy enemyA(String name, ...) {
        return new Enemy(name, ..., presetValue, ...);
    }

    Enemy enemyB(String name, ...) {
        return new Enemy(name, ..., otherValue, ...);
    }

    Enemy enemyC(String name, ...) {
        return new EnemySubclass(name, ..., otherValue, ...);
    }

    ...
}

EnemyFactory factory = new EnemyFactory();
Enemy a = factory.enemyA("fred", ...);
Enemy b = factory.enemyB("willy", ...);
```

Title: How can you decompose a constructor?


问:
Where to Populate Objects
As mentioned in this question, I am moving our team towards objects (as opposed to just throwing DataTables and variables around everywhere).  I have picked a suitable spot for the project that contains the object definitions, but not sure how I should go about populating some of the objects.  In particular, what do I do with classes as properties?

```<code>Public Class Class1
    Public Property SomeProperty As String
    Public Property SomeOtherProperty As String
    Public Property SomeKey As Integer
    Public Property Foo As Class2
End Class
</code>```

In this basic example, I can easily populate the first three properties from a query, but Foo has its own set of properties.  Right now, to create a List(Of Class1) I generate the data for all of the Class1 objects, and then use SomeKey to go back and, one object at a time, populate all of the Foo.  Certainly this works, but in my case it is rather slow, and it seems that perhaps I am simply doing it wrong.

Am I handling that incorrectly?  If so, what should I be doing?  The only other thing I can come up with is to create a query (or stored procedure) that returns all of the appropriate data for all of the objects.  In my test case that amounts to a list that contains 154 Class1's, with each of them having four properties like Foo, and some of those having classes as properties.

答:
Your current approach causes what is called as N+1 Select problem (see https://stackoverflow.com/questions/97197/what-is-the-n1-selects-issue).

One way to solve this is to retrieve all required data in the query by using select distinct and left join.  This is called eager fetching.  In most cases, it is the preferred solution.  If you have a deep hierarchy, you may want to create separate finder methods in your repository class such as findStudent() will only populate Student and findStudentForReview() will return Student.subjects.assignments.

Another way to solve this is to create a getter for property Foo that will retrieve data for Class2 if the data hasn't been retrieved before.  This is called lazy fetching approach: query for Class2 will be executed only when you need Foo value.

Or, you could use a ORM framework for your platform.  You will need extra investment here.  The advantage is ORM framework will handle data population and provide you with ready-to-use objects.

Title: Where to Populate Objects


问:
How to avoid duplicating the domain model in a multi-language distributed application?
My team is currently working on a web platform and we are planning to divide the application in a set of independent services written in different languages, the problem is that these services rely on a domain model layer that will need to be duplicated across the different languages(C# and Java).

The Domain layer is heavily cohesive and cannot be easily splitted out.

Given that working with multiple languages is a requirement what is a good architectural style that will allow a positive approach for this problem?

答:
There is no easy way to do it. DDD is primarily meant as single place where domain logic is encoded. If you try to have multiple places with the logic, you will soon run into bad problems.

The only way to do this in service-oriented architecture is to have one service specifically made to contain this domain logic and have everyone else call to this service. You could have different services for each different bounded context, but you say that is not possible, because you have only one.


问:
Is it an acceptable practice to Get a property, that involve parsing binary, that might throw an exception?
I have a property that is loaded lazily, any time after the ctor is called.

It is possible that the binary that my property relies on is invalid.  If invalid I might have to throw an exception.

Should I

Make the property a method, and be done with it.

Leave things as is.

Leave the property as-is, but add a method to validate the object, which will invoke the lazy parse, that might throw an exception.

答:
I would stick to throwing an unchecked exception.

The reason is it is not up to calling objects to validate your object. Furthermore, pulling the loading logic to a separate method means calling code must know to call method A before method B, and potentially method A can/should only be called once. This is a sequencing anti-pattern.

In this case, I prefer lazy loading which if done correctly ensures A. that loading is done only once, B. calling code does not need to know that methods in your class should be called in a specific order, potentially breaking if they do not.

Pseudocode:

```<code>public object getObject() {
  if (this.data == null) {
    loadObject()
  }
  return this.data
}

private void loadObject() {
  // Expensive loading logic...
}
</code>```

Edit: I would like to clarify that getters/accessors should, generally, not throw anything. However, in this case, we are not dealing with a simple getter. I like to think of this not as "get some simple variable stored on the object" but "go get me some beer from the fridge, and if there are none left, throw a NullPointerException." After all if you are getting a value from some binary file or whatever, are you going to set it too? Probably not. So maybe another question is "should this be called a 'getter' to begin with?" which is a separate question.

Body:
I would stick to throwing an unchecked exception.

The reason is it is not up to calling objects to validate your object. Furthermore, pulling the loading logic to a separate method means calling code must know to call method A before method B, and potentially method A can/should only be called once. This is a sequencing anti-pattern.

In this case, I prefer lazy loading which if done correctly ensures A. that loading is done only once, B. calling code does not need to know that methods in your class should be called in a specific order, potentially breaking if they do not.

Pseudocode:

public object getObject() {
  if (this.data == null) {
    loadObject()
  }
  return this.data
}

private void loadObject() {
  // Expensive loading logic...
}

Edit: I would like to clarify that getters/accessors should, generally, not throw anything. However, in this case, we are not dealing with a simple getter. I like to think of this not as "get some simple variable stored on the object" but "go get me some beer from the fridge, and if there are none left, throw a NullPointerException." After all if you are getting a value from some binary file or whatever, are you going to set it too? Probably not. So maybe another question is "should this be called a 'getter' to begin with?" which is a separate question.


答:
It depends on how much the user of the class knows about the file:

If they do not know it exists or its format, then having the property is sufficient as the users do not have any idea how to deal with the exception.

If the user of the class knows that this file exists, can specify the path, or can create this file, then having a method with clear exception throwing semantics would be better.

If you can get both types of users, then a property and method might have to be done.

Title: Is it an acceptable practice to Get a property, that involve parsing binary, that might throw an exception?

Body:
I have a property that is loaded lazily, any time after the ctor is called.

It is possible that the binary that my property relies on is invalid.  If invalid I might have to throw an exception.

Should I

Make the property a method, and be done with it.

Leave things as is.

Leave the property as-is, but add a method to validate the object, which will invoke the lazy parse, that might throw an exception.


问:
Does tweeting 9 to 5 hurt job applicants?
If you were looking into a job applicant's background and discovered that he or she has 1200 followers on Twitter and averages 50 tweets per day (more than half of which are during business hours), would it affect your hiring decision? How and why?

Personally, I'd be a little worried about the candidate's ability to focus on the job at hand if they're constantly checking in with their 'tweeps' thoughout the day. In non-tech jobs, a lot of companies simply block Twitter as an irrelevant distraction.  But it can be a useful resource---to programmers in particular. I just wonder how much is too much. At what point does it become a red flag?

答:
I just checked one of my TweetDeck columns:

Elijah Manor, 31882 followers

Mark Needham, 1832

Ron Jeffries, 4657

Reginald Braithwaite, 1711

Roy Osherove, 4249

Phil Haack, 11483

Jeremy Miller, 3943

OK, enough. Don't even think about hiring any of them :-)

ContentLicense: CC BY-SA 2.5


问:
If I use Ruby Migrations, do I have to use the rest of Ruby on Rails?
I'm currently trying to come up with a database migrations strategy for my organization.  This includes getting the database scripts into source control, managing versioning, managing releases to QA / Production, managing branching and merging across different release branches, etc.

Ruby Migrations seems to offer solutions to a lot of those problems.  But, from looking at the Ruby on Rails docs, it is unclear to me whether Ruby Migrations can be separated from the rest of the framework.  I work in a primarily .NET shop, but with a lot of other technologies, and with multiple DBMS platforms (SQL Server, Oracle of various versions).  Ruby is not present in our portfolio at all right now, and we have no plans to use it.  If I was to use Ruby Migrations, it would be the only piece of the Ruby on Rails framework that we would want to use.

Can Ruby Migrations be effectively used to manage database changes independently of the rest of the Ruby on Rails framework?  Are there any docs or articles out there that describe this workflow?

(Yes, I know there are other options such as Liquibase but I'm specifically trying to learn about Ruby Migrations with this question.)

答:
You can use the migrations framework in a non-Rails project if you want. I use it in a Rails project that uses Sequel instead of ActiveRecord as the ORM solution but we still use ActiveRecord migrations to evolve our database schema. I know at least two projects that allow you to do that:

https://github.com/rosenfeld/active_record_migrations (compatible with ActiveRecord 4 and above)
https://github.com/thuss/standalone-migrations (compatible with ActiveRecord 3.2)


问:
How to keep track of links pointing to existing web applications in an Intranet?
At my new place of employment we have a Intranet solution containing multiple web applications hosted in IIS. Outside of the development department other departments either source or create other applications / reports that deep link into these web applications.

Unfortunately, I have no direct control over these potential applications and some get created without our knowledge. This causes a problem if we need to do some re-structuring or re-factoring.

I was wondering if anyone had an approach where all inbound links regardless of origin had to be registered - i.e like a link registry or some other approach on how to deal with this. This could then be used so that the impact of any re-organisation of the structure of the web application could be understood.

Any help much appreciated

答:
There are at least two technical methods to deal with the incoming links:

Instead of registration, consider logging and analyzing incoming traffic to determine the source of the links. Good log information will allow you to track the incoming links back to their source. In the event of restructuring, look for an increase in the number of 404 errors as a starting point for finding out-of-date links. Logging and analysis tools such as Webalizer and awstats are good places to start.

If you cannot use logging or find it ineffective, you can develop a proxy through which all incoming links must pass. Valid incoming links should include a registration key (which you assign by department or other factor). Any incoming request which does not include the registration key should be redirected to an information page which explains how to obtain a key. You can associate the keys with specific departments or relevant sources in your database, and can use that database to reach out to the external linkers when you change the link targets.

However, consider whether your business model need to change. If you are not responsible for creating the external links, should it be your responsibility to guard against their failure? Your business may find more value in either:

Requiring the link creators to take responsibility for the links that they generate (ie. they must reach out to you when something breaks), or

Restricting link creation to IIS staff.

Either of these options will allow you to have a better chance to avoid failure in the future.


问:
How do I handle merging code that hasn't been merged in ~3 years in an agile manner?
Our team has recently adopted agile practices and most of the team is new to agile.

In our product, we use some code developed by another team and only they maintain that code. For the last 4-5 years, the previous developers have merged the code they intended to use and not all of that. Over time, the code in our branch was customized as well. Now for 3 years, these code bases have not been merged. We are expecting a lot of changes and manual conflict resolve process to perform a merge, as all of us are new to this code and also the code has been out of sync for long time.

How should we approach this kind of task/story in Agile way? Is there any guidelines to approach such unclear task where uncertainty is very high and we do not know how many conflicts/bugs will come out?

EDIT:1
please bear with me if question is not clear, let me know in comments and i will try to clarify as much as possible. So lets me try one more time.

As a AGILE team what I (and team) has learn so far is, before 2 week sprint starts, we discuss requirements with PM, understand the work needs to be done, finalize the approach for any DB design if and then two week sprint starts. in the middle one day we also do another PBR session where any new concern's can be raised for current sprint or we just continue understanding new stories for next sprint. On the last Day of Sprint we do Sprint Demo, and next Day Sprint Retrospective.

Recently I came to know word Spike. many AGILE teams use the Spike as a 2-3 days of period between sprints either at the end of sprint to finish up minor remaining task and do not need to carry the whole stories to next sprint. Or Sometimes in the beginning of sprint to finalize the design/approach or to flush out Proof of concept kind of thing.

When I (team) saw this code merge task, we are like there is no way we will be able to break down this story to confined task as 90% of things are unknown. we do not have automate test around the code, we haven't merge this code before and again this is a Baseless merge on SQL side. what ever we estimate there are highly chances that we good amount of task may remain incomplete. now in retrospective this will become bad on team. and such task can disturb team velocity as well.

So My question is How other people include such task in there AGILE team. Does this really be executed as SPRINT? or this should be one time effort by team and not logged on AGILE board? In a way i am looking for guidance on how AGILE allows to execute such task. If not Sprint is there anything else ?

答:
There's nothing "agile" about a 3-year merge.

Your team is going to have to put "agile" aside for a while, probably considerably more than a single sprint.  You're going to want to freeze current codebase before you merge and extensively test, so you'll know that the starting code is fully functional.  Then you're going to have to do the full merge, introducing no unrelated changes for its duration.  Then you're going to have to test at least as well as when you started, because no matter how hard you try, you will introduce bugs.  Once you've got that done, you can go back to being agile, but all that stuff in the middle is a classic waterfall solution to a classic waterfall problem.

Oh, and be sure to tag the repository immediately before and after the merge - for a year or more, you'll be blaming every weird bug on "that $#@#@$#^% big merge we did", and you're going to want to re-examine the changes to convince yourselves that you're wrong.


答:
There are things you can do, and they all come down to being able to tell a legitimate deep link from an illegitimate one, for whatever definition of legitimate you've decided on.

It could be a simple as having your approved application set something up in the session upon hitting the proper start page, and anyone without that value set must be deep linking.  You could decide that external application that want to pass this check need to get a value from the server, which then allows you to track all the requests that get made with that ID, or else you don't serve the page.

Note that this prevents legitimate users from deep linking as well, unless they first go to the start page.  It's also pretty easy to hack around, if your business issues run deep enough for that to be an issue.

Title: How to keep track of links pointing to existing web applications in an Intranet?

Body:
At my new place of employment we have a Intranet solution containing multiple web applications hosted in IIS. Outside of the development department other departments either source or create other applications / reports that deep link into these web applications.

Unfortunately, I have no direct control over these potential applications and some get created without our knowledge. This causes a problem if we need to do some re-structuring or re-factoring.

I was wondering if anyone had an approach where all inbound links regardless of origin had to be registered - i.e like a link registry or some other approach on how to deal with this. This could then be used so that the impact of any re-organisation of the structure of the web application could be understood.

Any help much appreciated


答:
You're trying to put space into your IO intensive application for all the non-IO activities; unfortunately typical CRUD apps like you talk about do little other than IO.

I think you understand the relevant separation fine, but where you're trying to place the persistence IO code at some number of layers away from the presentation code, the general fact of the matter is in your controller somewhere you should be calling out to your persistence layer, which may feel too close to your presentation to you - but that's just a coincidence in that type of app has little else to it.

Presentation and persistence make up basically the entirety of the type of app I think you're describing here.

If you think in your head about a similar application that had a lot of complex business logic and data processing in it, I think you'll find yourself able to imagine how that is nicely separated away from the presentational IO and persistence IO stuff such that it needs know nothing about either. The problem you have right now is just a perceptual one caused by trying to see a solution to a problem in a type of application that doesn't have that problem to begin with.

Title: How does persistence fit into a purely functional language?

Body:
How does the pattern of using command handlers to deal with persistence fit into a purely functional language, where we want to make IO-related code as thin as possible?

When implementing Domain-Driven Design in an object-oriented language, it's common to use the Command/Handler pattern to execute state changes. In this design, command handlers sit on top of your domain objects, and are responsible for the boring persistence-related logic like using repositories and publishing domain events. The handlers are the public face of your domain model; application code like the UI calls the handlers when it needs to change domain objects' state.

A sketch in C#:

```<code>public class DiscardDraftDocumentCommandHandler : CommandHandler<DiscardDraftDocument>
{
    IDraftDocumentRepository _repo;
    IEventPublisher _publisher;

    public DiscardDraftCommandHandler(IDraftDocumentRepository repo, IEventPublisher publisher)
    {
        _repo = repo;
        _publisher = publisher;
    }

    public override void Handle(DiscardDraftDocument command)
    {
        var document = _repo.Get(command.DocumentId);
        document.Discard(command.UserId);
        _publisher.Publish(document.NewEvents);
    }
}
</code>```

The document domain object is responsible for implementing the business rules (like "the user should have permission to discard the document" or "you can't discard a document that's already been discarded") and for generating the domain events we need to publish (document.NewEvents would be an IEnumerable<Event> and would probably contain a DocumentDiscarded event).

This is a nice design - it's easy to extend (you can add new use cases without changing your domain model, by adding new command handlers) and is agnostic as to how objects are persisted (you can easily swap out an NHibernate repository for a Mongo repository, or swap a RabbitMQ publisher for an EventStore publisher) which makes it easy to test using fakes and mocks. It also obeys model/view separation - the command handler has no idea whether it's being used by a batch job, a GUI, or a REST API.

In a purely-functional language like Haskell, you might model the command handler roughly like this:

```<code>newtype CommandHandler = CommandHandler {handleCommand :: Command -> IO Result)
data Result a = Success a | Failure Reason
type Reason = String

discardDraftDocumentCommandHandler = CommandHandler handle
    where handle (DiscardDraftDocument documentID userID) = do
              document <- loadDocument documentID
              let result = discard document userID :: Result [Event]
              case result of
                   Success events -> publishEvents events >> return result
                   -- in an event-sourced model, there's no extra step to save the document
                   Failure _ -> return result
          handle _ = return $ Failure "I expected a DiscardDraftDocument command"
</code>```

Here's the part I'm struggling to understand. Typically, there'll be some sort of 'presentation' code which calls into the command handler, like a GUI or a REST API. So now we have two layers in our program which need to do IO - the command handler and the view - which is a big no-no in Haskell.

As far as I can make out, there are two opposing forces here: one is model/view separation and the other is the need to persist the model. There needs to be IO code to persist the model somewhere, but model/view separation says that we can't put it in the presentation layer with all the other IO code.

Of course, in a "normal" language, IO can (and does) happen anywhere. Good design dictates that the different types of IO be kept separate, but the compiler doesn't enforce it.

So: how do we reconcile model/view separation with the desire to push IO code to the very edge of the program, when the model needs to be persisted? How do we keep the two different types of IO separate, but still away from all the pure code?

Update: The bounty expires in less than 24 hours. I don't feel that either of the current answers has addressed my question at all. @Ptharien's Flame's comment about acid-state seems promising, but it's not an answer and it's lacking in detail. I'd hate for these points to go to waste!


答:
Sounds to me like it could be a big mistake to to treat this as just a big example of a merge, something that is going to involve an unusually long set of sessions sitting in front of a merge tool and pressing 'accept/reject changes'.

Instead, I would:

Spend an appropriate amount of time, perhaps a week, reading both sets of code.

Decide which one has the better architecture and tests; make that (call it system A) the baseline

Ensure there is a decent set of automated tests for system A; probably mostly integration-style near end-to-end tests.

extract a list of the required set of features from system B

put those features on the system A backlog

as those features are implemented, consider mining the system B for useful bits of code. But really you are reimplementing the features, with at leat the normal amount of testing; perhaps a bit more.

as subsystems of A become feature-complete wrt B's requirements, swap them into production on both systems, discarding that part of B.

repeat until there is only one part of B left: make that the 'do-B' subsystem of A.

Title: How do I handle merging code that hasn't been merged in ~3 years in an agile manner?

Body:
Our team has recently adopted agile practices and most of the team is new to agile.

In our product, we use some code developed by another team and only they maintain that code. For the last 4-5 years, the previous developers have merged the code they intended to use and not all of that. Over time, the code in our branch was customized as well. Now for 3 years, these code bases have not been merged. We are expecting a lot of changes and manual conflict resolve process to perform a merge, as all of us are new to this code and also the code has been out of sync for long time.

How should we approach this kind of task/story in Agile way? Is there any guidelines to approach such unclear task where uncertainty is very high and we do not know how many conflicts/bugs will come out?

EDIT:1
please bear with me if question is not clear, let me know in comments and i will try to clarify as much as possible. So lets me try one more time.

As a AGILE team what I (and team) has learn so far is, before 2 week sprint starts, we discuss requirements with PM, understand the work needs to be done, finalize the approach for any DB design if and then two week sprint starts. in the middle one day we also do another PBR session where any new concern's can be raised for current sprint or we just continue understanding new stories for next sprint. On the last Day of Sprint we do Sprint Demo, and next Day Sprint Retrospective.

Recently I came to know word Spike. many AGILE teams use the Spike as a 2-3 days of period between sprints either at the end of sprint to finish up minor remaining task and do not need to carry the whole stories to next sprint. Or Sometimes in the beginning of sprint to finalize the design/approach or to flush out Proof of concept kind of thing.

When I (team) saw this code merge task, we are like there is no way we will be able to break down this story to confined task as 90% of things are unknown. we do not have automate test around the code, we haven't merge this code before and again this is a Baseless merge on SQL side. what ever we estimate there are highly chances that we good amount of task may remain incomplete. now in retrospective this will become bad on team. and such task can disturb team velocity as well.

So My question is How other people include such task in there AGILE team. Does this really be executed as SPRINT? or this should be one time effort by team and not logged on AGILE board? In a way i am looking for guidance on how AGILE allows to execute such task. If not Sprint is there anything else ?


问:
Should a unit/integration test that may result in an infinite loop have a clear assertion?
Unit: A multithreaded unit reads data of a queue and processes it, sending it off to another queue. When the last item is processed (null value found) the process stops.

Test: Place a set of known data in the queue and run. Check that data placed on the output queue is correct.

If the unit is incorrectly programmed, it may continue trying to read and process nulls of the queue. This may or may not result in an exception (using Java as the example language). So this test could conceivably cause an infinite loop.

Should the test keep track of the number of items read off the queue and throw an error if more than the specified number of elements is read? or should the test continue to run, knowing that the runner(human) will see that it is not ending?

答:
Tests should always terminate (ideally quickly!).

If you have a test that doesn't terminate, your continuous integration server will fail its test run, which is great, but the failure will likely be "your test suite took too long so I killed it", which isn't very helpful.

In this case, if you have N items in the list and you've read N + 2 items already, then your test should fail, and explain why (say, a message like "test failed because it was about to loop infinitely").


问:
When is the private key given to the client?
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

I've been reading the article and I haven't really grasped it yet. When is the private key given to the client?

Say I have a JavaScript client - where would I store this private key (once assigned) - a cookie?

I think that this maybe is done when authenticating a user, if a JavaScript client makes a post request and authenticates a user, the server validates the input and gives back user id ( a public key ) and then some generated string (stored in a table) = the private key?

And then just follow the approach (quoted) from article:

```<code>[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
[CLIENT] Hash (HMAC-SHA1 or SHA256 preferably) the blob of data data (from Step #1) with your private key assigned to you by the system.
[CLIENT] Send the server the following data:
    Some user-identifiable information like an “API Key”, client ID, user ID or something else it can use to identify who you are. This is the public API key, never the private API key. This is a public value that anyone (even evil masterminds can know and you don’t mind). It is just a way for the system to know WHO is sending the request, not if it should trust the sender or not (it will figure that out based on the HMAC).
    Send the HMAC (hash) you generated.
    Send all the data (parameters and values) you were planning on sending anyway. Probably unencrypted if they are harmless values, like “mode=start&number=4&order=desc” or other operating nonsense. If the values are private, you’ll need to encrypt them.
(OPTIONAL) The only way to protect against “replay attacks” on your API is to include a timestamp of time kind along with the request so the server can decide if this is an “old” request, and deny it. The timestamp must be included into the HMAC generation (effectively stamping a created-on time on the hash) in addition to being checked “within acceptable bounds” on the server.
[SERVER] Receive all the data from the client.
[SERVER] (see OPTIONAL) Compare the current server’s timestamp to the timestamp the client sent. Make sure the difference between the two timestamps it within an acceptable time limit (5-15mins maybe) to hinder replay attacks.
    NOTE: Be sure to compare the same timezones and watch out for issues that popup with daylight savings time change-overs.
    UPDATE: As correctly pointed out by a few folks, just use UTC time and forget about the DST issues.
[SERVER] Using the user-identifying data sent along with the request (e.g. API Key) look the user up in the DB and load their private key.
[SERVER] Re-combine the same data together that the client did in the same way the client did it. Then hash (generate HMAC) that data blob using the private key you looked up from the DB.
    (see OPTIONAL) If you are protecting against replay attacks, include the timestamp from the client in the HMAC re-calculation on the server. Since you already determined this timestamp was within acceptable bounds to be accepted, you have to re-apply it to the hash calculation to make sure it was the same timestamp sent from the client originally, and not a made-up timestamp from a man-in-the-middle attack.
[SERVER] Run that mess of data through the HMAC hash, exactly like you did on the client.
[SERVER] Compare the hash you just got on the server, with the hash the client sent you; if they match, then the client is considered legit, so process the command. Otherwise reject the command!
</code>```

On second note, I believe it would be more readable from the article itself...

Am I getting this right?

答:
If the key is being shared by the client and the server, it's not really a private key---it's a secret key. In particular, it's a shared secret.

If the key is a private key, you are using public key cryptography. The private key is made on the server and never leaves the client. The client uses its private key to sign a certificate signing request which includes a copy of its public key. This goes to the server, which rips out the public key, signs it, and sends back a certificate.

Back to your protocol, it looks like you are using an HMAC, which requires a shared secret key.  Typically you'll register the shared secret before you start this protocol.


答:
What you're considering is called a "hashing scheme".

You're going to take the content of a message and create a hash (i.e. HMAC).

The hash will also include a "secret string" that the server provides.

The client sends that hash along with the message.

The server can re-create the hash from the message, and make sure that its hash value matches exactly the one that the client sent.

If it doesn't match, then error out.

The security comes in because a "Man in the Middle" can create a hash for the content, but cannot create a hash that includes the "secret string"... because only client and server know the secret string.

You can get the "secret string" through an out-of-channel communication (like from an email that you cut and paste into configuration, or database, or somewhere, and load it up with the page), or as a one-time request to the server using SSL & cache that somewhere.

In the conversations I've participated in around web security, there are a couple of central points that come up.

1) if you give a "secret key" to a browser, it's not secret anymore. Javascript in the browser is just too open to really keep a key secret.

However, if you're not passing nuclear secrets or credit card information, that may be an OK compromise for you. It might be that a hacker won't go to the trouble to upload a malicious script to sniff your secret string. But just bear that in mind.

I remember seeing a javascript implementation of the OAuth 1 hashing scheme with a big disclaimer saying, "Don't run this code in production, because a public browser isn't secure."

2) Some technologies have trouble producing a hash. This doesn't sound like a problem for you, but if you just have plain web pages with no javascript available, or maybe an old Flash script, then you might not be able to make the calculations needed for the hash.

The alternative to "hashing" is token-passing.

That means the client gets a token from the server, and sends it along with any requests. The server verifies that it recognizes the token. That means you have to communicate using SSL, because otherwise your token will be visible to the "Man in the Middle" who is sniffing internet traffic. But with SSL it's OK.

Unfortunately, this is a sensitive topic in the security community. OAuth 1 used hashing, but OAuth 2 shifted away from hashing to token passing. This was to defer the cryptographic concerns to SSL, which was doing that anyway. But it's still a pretty contentious issue.

The easiest form of token passing for a browser client is the usual "session" cookie. The client calls the server with username and password, and gets back a "secure" session cookie. Then, as long as the client sends that session cookie with a request, the server can authorize the client's calls.

However, you have to make sure that the "secure" flag is set on the cookie, because you never want to pass it in the clear.

OAuth 2 provides a token-passing scheme which adds security by expiring the tokens.

The short answer is...

If you don't want to go down the OAuth path, then just a) send username/password to fetch a secure "session" cookie, and then pass that secure session cookie with each request to the server. Have the server check it against the list of secure cookies that it has handed out.

You can get fancier, but that's a basic starting point.

Body:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

I've been reading the article and I haven't really grasped it yet. When is the private key given to the client?

Say I have a JavaScript client - where would I store this private key (once assigned) - a cookie?

I think that this maybe is done when authenticating a user, if a JavaScript client makes a post request and authenticates a user, the server validates the input and gives back user id ( a public key ) and then some generated string (stored in a table) = the private key?

And then just follow the approach (quoted) from article:

```<code>[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
[CLIENT] Hash (HMAC-SHA1 or SHA256 preferably) the blob of data data (from Step #1) with your private key assigned to you by the system.
[CLIENT] Send the server the following data:
    Some user-identifiable information like an “API Key”, client ID, user ID or something else it can use to identify who you are. This is the public API key, never the private API key. This is a public value that anyone (even evil masterminds can know and you don’t mind). It is just a way for the system to know WHO is sending the request, not if it should trust the sender or not (it will figure that out based on the HMAC).
    Send the HMAC (hash) you generated.
    Send all the data (parameters and values) you were planning on sending anyway. Probably unencrypted if they are harmless values, like “mode=start&number=4&order=desc” or other operating nonsense. If the values are private, you’ll need to encrypt them.
(OPTIONAL) The only way to protect against “replay attacks” on your API is to include a timestamp of time kind along with the request so the server can decide if this is an “old” request, and deny it. The timestamp must be included into the HMAC generation (effectively stamping a created-on time on the hash) in addition to being checked “within acceptable bounds” on the server.
[SERVER] Receive all the data from the client.
[SERVER] (see OPTIONAL) Compare the current server’s timestamp to the timestamp the client sent. Make sure the difference between the two timestamps it within an acceptable time limit (5-15mins maybe) to hinder replay attacks.
    NOTE: Be sure to compare the same timezones and watch out for issues that popup with daylight savings time change-overs.
    UPDATE: As correctly pointed out by a few folks, just use UTC time and forget about the DST issues.
[SERVER] Using the user-identifying data sent along with the request (e.g. API Key) look the user up in the DB and load their private key.
[SERVER] Re-combine the same data together that the client did in the same way the client did it. Then hash (generate HMAC) that data blob using the private key you looked up from the DB.
    (see OPTIONAL) If you are protecting against replay attacks, include the timestamp from the client in the HMAC re-calculation on the server. Since you already determined this timestamp was within acceptable bounds to be accepted, you have to re-apply it to the hash calculation to make sure it was the same timestamp sent from the client originally, and not a made-up timestamp from a man-in-the-middle attack.
[SERVER] Run that mess of data through the HMAC hash, exactly like you did on the client.
[SERVER] Compare the hash you just got on the server, with the hash the client sent you; if they match, then the client is considered legit, so process the command. Otherwise reject the command!
</code>```

On second note, I believe it would be more readable from the article itself...

Am I getting this right?


问:
Is it bad practice to allow user defined fields?
Generally speaking, is it considered bad practice to allow for user created fields in a database for a webapp?

For example, I am making a home inventory webapp for my wife, and she is going to want to define her own fields for different items.  I was planning to allow her to create item categories, and add "features" to those categories.  Features would just be key/value stored as strings.  That way if she had a category called "Audio CDs" for example, she could add features for stuff like "artist", "tracks", etc.  But in another category like "furniture", she could add features for stuff like "material" (wood, plastic, etc).  Then any item could belong to one (or many) categories, adding those features to the item.

I can see issues where searching by these features requires string comparisons, there's no validation of data, etc.  Following agile methodology, maybe it would be better to just have her come up with new categories and attributes and I would just have to create new tables as we go.  In my example, it's a small userbase (2 of us) and the amount of records created would be small, so not too bad.

Generally speaking though, how do people handle something like this in "real life"?

答:
When you start getting to "user defined fields" as is often found in bug trackers, customer resource management, and similar business tools is that they are not backed with a table with a bajillion fields (if they are, then thats likely a problem of its own).

Instead what you find are Entity Attribute Value table designs and the associated administration tool to manage the valid attributes.

Consider the following table:

```

  +--------------+
  | thing        |
  |--------------|
  | id           |
  | type         |
  | desc         |
  | attr1        |
  | attr2        |
  | attr3        |
  | attr4        |
  | attr5        |
  +--------------+
```

This is after you've added a few attributes.  Instead of attr1 pretend it reads artist or tracks or genre or whatever attributes the thing has.  And instead of 5, what if it was 50.  Clearly that is unmanageable.  It also requires an update of the model and redeployment of the application to handle a new field.  Not ideal.

Now consider the following table structure:

```

  +--------------+     +---------------+    +-------------+
  | thing        |     | thing_attr    |    | attr        |
  |--------------|     |---------------|    |-------------|
  | id           |<---+|  thing_id (fk)|  +>| id          |
  | type         |     |  attr_id  (fk)|+-+ | name        |
  | desc         |     |  value        |    |             |
  +--------------+     +---------------+    +-------------+
```

You've got your thing with its basic fields.  You have two more tables.  One with the attributes.  Each field is a row in the attr table.  And then there is the thing_attr with a pair of foreign keys relating back to the thing table and the attr table.  And this then has a value field where you store whatever the value of the field for that entity would be.

And now you've got a structure where the attr table can be updated at runtime and new fields can be added (or removed) on the fly without significant impact to the overall application.

The queries are a little bit more complex and validation becomes more complex too (either funky stored procedures or all client side).  Its a trade off in design.

Consider also the situation where some day you need to do a migration and you come back to the application to find that there are now a half dozen or so more attributes than the schema you originally distributed.  This makes for ugly migrations and upgrades where the Entity Attribute Value table, when used correctly, can be cleaner.   (Not always, but can be.)

Are there any downsides to just modifying the schema at runtime? If the user thinks a thing needs a new attribute, just dynamically add a column to the table?

If you are working with the appropriate flavor of nosql database, you could probably do this (note that the appropriate flavor of the nosql for this would probably be a key-value store which is, well, the EAV table for relational ones described above) without too much trouble.  However it comes with all the compromises for nosql which are described elsewhere in great detail.

If you are instead working on a relational database - you need to have the schema.  Adding the column dynamically means some subset of the following things are true:

You are doing meta-database programming.  Instead of being able to cleanly map this column to that field with a nice ORM, you are probably doing things like select * and then doing some complex code to find out what the data actually is (see Java's ResultSetMetaData) and then storing that in a map (or some other datatype - but not nice fields in the code).  This then throws away a fair bit of type and typo safety that you have with the traditional approach.

You've likely abandoned the ORM.  This means you're writing raw sql for all the code instead of letting the system do the work for you.

You've given up on doing clean upgrades.  What happens when the customer adds a field with one name that your next version also uses?  In the matchmaking site the upgrade that wants to add a hasdate field for storing a timestamp has already been defined as hasdate with a boolean for a successful match... and your upgrade breaks.

You're trusting that the customer doesn't break the system by using some reserved word that breaks your queries too... somewhere.

You've bound yourself to one database brand.  The DDL of different databases is different. Database types are the easiest example of this.  varchar2 vs text and the like.  Your code to add the column would work on MySQL but not Postgres or Oracle or SQL Server.

Do you trust the customer to actually add the data well?  Sure, the EAV is far from ideal but now you've got some horrendous obscure table names that you the developer didn't add, with the wrong type of index (if any), with no constraints added in the code where there need to be and so on.

You've given schema modification privileges to the user running the application. Little Bobby Drop Tables isn't possible when you're restricted to SQL rather than DDL (sure you can do a delete * from students instead, but you can't really mess up the database in bad ways).  The number of things that can go wrong with schema access either from an accident or malicious activity skyrockets.

This really boils down to "don't do it." If you really want this, go with a known pattern of the EAV table structure or a database that is entirely dedicated to this structure.  Don't let people create arbitrary fields in a table.  The headaches just aren't worth it.

Body:
When you start getting to "user defined fields" as is often found in bug trackers, customer resource management, and similar business tools is that they are not backed with a table with a bajillion fields (if they are, then thats likely a problem of its own).

Instead what you find are Entity Attribute Value table designs and the associated administration tool to manage the valid attributes.

Consider the following table:

  +--------------+
  | thing        |
  |--------------|
  | id           |
  | type         |
  | desc         |
  | attr1        |
  | attr2        |
  | attr3        |
  | attr4        |
  | attr5        |
  +--------------+

This is after you've added a few attributes.  Instead of attr1 pretend it reads artist or tracks or genre or whatever attributes the thing has.  And instead of 5, what if it was 50.  Clearly that is unmanageable.  It also requires an update of the model and redeployment of the application to handle a new field.  Not ideal.

Now consider the following table structure:

  +--------------+     +---------------+    +-------------+
  | thing        |     | thing_attr    |    | attr        |
  |--------------|     |---------------|    |-------------|
  | id           |<---+|  thing_id (fk)|  +>| id          |
  | type         |     |  attr_id  (fk)|+-+ | name        |
  | desc         |     |  value        |    |             |
  +--------------+     +---------------+    +-------------+

You've got your thing with its basic fields.  You have two more tables.  One with the attributes.  Each field is a row in the attr table.  And then there is the thing_attr with a pair of foreign keys relating back to the thing table and the attr table.  And this then has a value field where you store whatever the value of the field for that entity would be.

And now you've got a structure where the attr table can be updated at runtime and new fields can be added (or removed) on the fly without significant impact to the overall application.

The queries are a little bit more complex and validation becomes more complex too (either funky stored procedures or all client side).  Its a trade off in design.

Consider also the situation where some day you need to do a migration and you come back to the application to find that there are now a half dozen or so more attributes than the schema you originally distributed.  This makes for ugly migrations and upgrades where the Entity Attribute Value table, when used correctly, can be cleaner.   (Not always, but can be.)

Are there any downsides to just modifying the schema at runtime? If the user thinks a thing needs a new attribute, just dynamically add a column to the table?

If you are working with the appropriate flavor of nosql database, you could probably do this (note that the appropriate flavor of the nosql for this would probably be a key-value store which is, well, the EAV table for relational ones described above) without too much trouble.  However it comes with all the compromises for nosql which are described elsewhere in great detail.

If you are instead working on a relational database - you need to have the schema.  Adding the column dynamically means some subset of the following things are true:

You are doing meta-database programming.  Instead of being able to cleanly map this column to that field with a nice ORM, you are probably doing things like select * and then doing some complex code to find out what the data actually is (see Java's ResultSetMetaData) and then storing that in a map (or some other datatype - but not nice fields in the code).  This then throws away a fair bit of type and typo safety that you have with the traditional approach.

You've likely abandoned the ORM.  This means you're writing raw sql for all the code instead of letting the system do the work for you.

You've given up on doing clean upgrades.  What happens when the customer adds a field with one name that your next version also uses?  In the matchmaking site the upgrade that wants to add a hasdate field for storing a timestamp has already been defined as hasdate with a boolean for a successful match... and your upgrade breaks.

You're trusting that the customer doesn't break the system by using some reserved word that breaks your queries too... somewhere.

You've bound yourself to one database brand.  The DDL of different databases is different. Database types are the easiest example of this.  varchar2 vs text and the like.  Your code to add the column would work on MySQL but not Postgres or Oracle or SQL Server.

Do you trust the customer to actually add the data well?  Sure, the EAV is far from ideal but now you've got some horrendous obscure table names that you the developer didn't add, with the wrong type of index (if any), with no constraints added in the code where there need to be and so on.

You've given schema modification privileges to the user running the application. Little Bobby Drop Tables isn't possible when you're restricted to SQL rather than DDL (sure you can do a delete * from students instead, but you can't really mess up the database in bad ways).  The number of things that can go wrong with schema access either from an accident or malicious activity skyrockets.

This really boils down to "don't do it." If you really want this, go with a known pattern of the EAV table structure or a database that is entirely dedicated to this structure.  Don't let people create arbitrary fields in a table.  The headaches just aren't worth it.


答:
Doing this well is hard.

For a one-off application like what you're planning, you can, of course, just add a column for each field, and provide a UI that makes field definition by untrained users safer than giving them an SQL command line.  Or you could follow the dreaded Entity-Attribute-Value pattern, which is a classic, if somewhat scary, response to this sort of problem.  Building the UI for defining EAV fields is usually much more complex than for database columns, and the queries can get pretty hairy, but for large numbers of fields (i.e., highly-sparse-matrix schemata), it may be the only way to get the job done.

Title: Is it bad practice to allow user defined fields?

Body:
Generally speaking, is it considered bad practice to allow for user created fields in a database for a webapp?

For example, I am making a home inventory webapp for my wife, and she is going to want to define her own fields for different items.  I was planning to allow her to create item categories, and add "features" to those categories.  Features would just be key/value stored as strings.  That way if she had a category called "Audio CDs" for example, she could add features for stuff like "artist", "tracks", etc.  But in another category like "furniture", she could add features for stuff like "material" (wood, plastic, etc).  Then any item could belong to one (or many) categories, adding those features to the item.

I can see issues where searching by these features requires string comparisons, there's no validation of data, etc.  Following agile methodology, maybe it would be better to just have her come up with new categories and attributes and I would just have to create new tables as we go.  In my example, it's a small userbase (2 of us) and the amount of records created would be small, so not too bad.

Generally speaking though, how do people handle something like this in "real life"?


答:
I came a cross some thing similar recently.

I made 2 tables.

```<code>1: table Objects
    Id , name, type
</code>```

He is all your objects. U set name of it .

And a type of this object :- for me available types was inventory , inventory_item , office.

And usual setup was n items are child or inventory which is also child of office and I used a join table to join objects to each other

```<code>2 table settings
     organization_Id , title, value , type
</code>```

Settings table contain every field name for that specific object type , and value in value.

Example properties of office

Location, phone , working hours

And for items

Amount

Price

Barcode

Etc, all these properties are enforced by you model and saved in settings table as separate rows ( yet use replace not insert to avoid multiple rows for same field )

So when ever I want an office I load it easy with all its relations and settings where settings object_I'd in (requested objects)

After that I pivot all rows from settings and that's it.

And in case I wanted a setting to be specific to an item in a inventory (not global) I set object_I'd = I'd from object_objects relations table and I set settings.type = relation_setting

I hope you understand what I mean I will try to reformat answer when I get to a laptop

Body:
I came a cross some thing similar recently.

I made 2 tables.

1: table Objects
    Id , name, type

He is all your objects. U set name of it .

And a type of this object :- for me available types was inventory , inventory_item , office.

And usual setup was n items are child or inventory which is also child of office and I used a join table to join objects to each other

2 table settings
     organization_Id , title, value , type

Settings table contain every field name for that specific object type , and value in value.

Example properties of office

Location, phone , working hours

And for items

Amount

Price

Barcode

Etc, all these properties are enforced by you model and saved in settings table as separate rows ( yet use replace not insert to avoid multiple rows for same field )

So when ever I want an office I load it easy with all its relations and settings where settings object_I'd in (requested objects)

After that I pivot all rows from settings and that's it.

And in case I wanted a setting to be specific to an item in a inventory (not global) I set object_I'd = I'd from object_objects relations table and I set settings.type = relation_setting

I hope you understand what I mean I will try to reformat answer when I get to a laptop


问:
Which relationship is more natural?
Have a quick question on how to best structure something for my Java project:

I'm a user. I can work at one or more places. At those workplaces, I have one or more roles. For each of these roles, I work a shift.

I either came up with:

My workplaces have shifts, my shifts have exactly 1 position (what position did I work when I worked my shift? It varies day to day..)

or

Workplaces have positions, each position has shifts

I think the 2nd is more natural but keep going back and forth / unsure of what has more of an advantage both now and for the future. It's hard for me as I can argue both I guess?

Thanks!

答:
It might make the most sense to look at how you'll use those structures in your code. If you're writing a scheduling app, then putting shifts higher might make more sense because they're a scheduling artifact. If you're doing a HR app, then putting positions higher might make sense because you're worried about managing people and their roles.

An entity-relationship diagram would help, although you've pretty much got it laid out already.

But it's actually both. A workplace "has a" list of positions, but also "has a" list of shifts. Shifts will have additional information, like start and end time. And a shift "has a" position that describes what to do during that shift.

Another way to think of it is, a shift "realizes" a position. That is, it makes it real by adding scheduling information.

Here's another alternative: Positions and shifts are top-level entities, and they "have a" reference to a workplace.

You might bust out a simple Entity-Relationship diagram, and then decide which of the relationships (and in what direction) you want to model in your code. Some of the relationships you can rely on queries and joins to pull from your database.

Title: Which relationship is more natural?


问:
Avoid code repetition in CRUD operations
I'm developing a PHP application and I find myself doing basically the same code for, say, creating an object based on a form filled by the user.

The objects are of different classes, but the process is mostly the same: take the data from the form, apply validation, save/return error.

Is there a way to automatize this process? I ask also because I intend to write a public API and use the same code to do those operations, instead of just copy/pasting.

I thought of making a kind of Factory Method pattern that receives the type and the data from the form (or any array), create an instance and set the data, testing the validation afterwards (each object knows how to validate their own fields). And that for each of the other CRUD operations as well.

Is that feasible/good practice? Should I just repeat the similar code? There are any other way to do it?

For the record, I'm using ORM already (Doctrine). Still, I think that a lot of create functions with pretty much the same code (a bunch of set*) is something too repetitive.

答:
If you're not already using an ORM, you're probably doing it wrong, because you're not taking advantage of the leverage that an ORM can provide to the practice of writing CRUD methods.

However, there's a bit of history to all this, so I'm now going to tell you a little bedtime story.

In the beginning, there were SQL databases, and life was good.  Web sites were pretty sparse little affairs, and everyone got along by writing data access code by hand.

Then the wolly mammoths came.

No, not that wooly mammoth.

This woolly mammoth.  Databases that encompass an entire business domain:

Suddenly, data access code written by hand didn't cut it anymore.  So we invented ORM's, code-generation programs that produced one class for each table, complete with CRUD methods.  It's a lot of code, but you didn't have to write it, did you?

Great story, huh bro?  Well, not exactly.

You see, someone came along and said "Why do I need to know database theory, when I could just write my classes and then have the ORM generate my tables for me?"

OK, but now you're gonna have to write all of those classes by hand, aren't you?

Which brings us to the question you asked, which essentially is this: why can't I just write a function that accepts a type T, and returns an object of type T, like this?

```<code>public T Read(int id); // C#, for those of you so challenged.
</code>```

Sigh.  Well, you can, actually.  It's called a Generic Repository.  If you want to find out how to build one, you can look here.  It starts with something like this:

```<code>public function select($table, $where = '', $fields = '*', $order = '', $limit = null, $offset = null)
{
    $query = 'SELECT ' . $fields . ' FROM ' . $table
           . (($where) ? ' WHERE ' . $where : '')
           . (($limit) ? ' LIMIT ' . $limit : '')
           . (($offset && $limit) ? ' OFFSET ' . $offset : '')
           . (($order) ? ' ORDER BY ' . $order : '');
    $this->query($query);
    return $this->countRows();
}
</code>```

...and builds on that humble beginning (and other functions to round out the CRUD) to create a complete generic repository.  Add some IoC to it, and you'll have something that any Architecture Astronaut would consider worthy enough to take to interstellar space.

Body:
If you're not already using an ORM, you're probably doing it wrong, because you're not taking advantage of the leverage that an ORM can provide to the practice of writing CRUD methods.

However, there's a bit of history to all this, so I'm now going to tell you a little bedtime story.

In the beginning, there were SQL databases, and life was good.  Web sites were pretty sparse little affairs, and everyone got along by writing data access code by hand.

Then the wolly mammoths came.

No, not that wooly mammoth.

This woolly mammoth.  Databases that encompass an entire business domain:

Suddenly, data access code written by hand didn't cut it anymore.  So we invented ORM's, code-generation programs that produced one class for each table, complete with CRUD methods.  It's a lot of code, but you didn't have to write it, did you?

Great story, huh bro?  Well, not exactly.

You see, someone came along and said "Why do I need to know database theory, when I could just write my classes and then have the ORM generate my tables for me?"

OK, but now you're gonna have to write all of those classes by hand, aren't you?

Which brings us to the question you asked, which essentially is this: why can't I just write a function that accepts a type T, and returns an object of type T, like this?

public T Read(int id); // C#, for those of you so challenged.

Sigh.  Well, you can, actually.  It's called a Generic Repository.  If you want to find out how to build one, you can look here.  It starts with something like this:

public function select($table, $where = '', $fields = '*', $order = '', $limit = null, $offset = null)
{
    $query = 'SELECT ' . $fields . ' FROM ' . $table
           . (($where) ? ' WHERE ' . $where : '')
           . (($limit) ? ' LIMIT ' . $limit : '')
           . (($offset && $limit) ? ' OFFSET ' . $offset : '')
           . (($order) ? ' ORDER BY ' . $order : '');
    $this->query($query);
    return $this->countRows();
}

...and builds on that humble beginning (and other functions to round out the CRUD) to create a complete generic repository.  Add some IoC to it, and you'll have something that any Architecture Astronaut would consider worthy enough to take to interstellar space.


问:
Global request context - anti-pattern?
I was talking today to a colleague of mine about Python web frameworks and our impressions about them. I told him I think Flask having a global request smells badly and is an anti-pattern.

The docs say about request context:

In contrast, during request handling, a couple of other rules exist:

while a request is active, the context local objects (flask.request and others) point to the current request.

any code can get hold of these objects at any time.

I think I understand the idea behind this design decision -- to make the application simpler. It's just a compromise, like in the case of Thread Locals:

Yes it is usually not such a bright idea to use thread locals. They
  cause troubles for servers that are not based on the concept of
  threads and make large applications harder to maintain. However Flask
  is just not designed for large applications or asynchronous servers.
  Flask wants to make it quick and easy to write a traditional web
  application.

Is patching a global object with the current request information an anti-pattern?

I believe it is, because it is in the view of static code analyzer a global state, though it's not. And I as a programmer will not understand how it works without reading the docs carefully. And this has consequences on tests.

Isn't it a good practice to pass the request as an argument to views? I think it's more readable, explicit and easier to debug. And avoids global state.

答:
(I'm going to go bold and make this an answer, although I might get some downvotes.)

Flask is a micro-framework; you benefit from the simplicity while giving up on frills. While on a gut level I agree with you, I do know that I used flask + gunicorn at one shop to give me the multi-threading that I needed. It worked really well. Each instance of the script just handed one request (i.e. one thread), and gunicorn handled the "fan out" among multiple threads. It was great at that.

So the perceived downside you're feeling -- that multiple threads could contend for global state -- just isn't an issue, because it's one script per thread.

(Here's where I may get into trouble) Threading and concurrency is just different in the Python world, and if you come to it with a Java frame of mind, it's hard to squeeze it in. My experience was that concurrency issues that I took for granted in Java, or that are handled transparently by the application container, are a lot closer to the surface in Python.

It was strange to me that one thread would handle one invocation of my script, but after I had a few dozen running on a box at the same time, I felt better about it.

Title: Global request context - anti-pattern?


答: It doesn't take a long time to post a tweet: probably less than it would take to get up, walk to the water cooler, and strike up a brief chat with a coworker. So I don't see Twitter participation as a problem so long as work gets done (well and on time), especially if tweet content is mostly relevant to the job. </p>

Title: Does tweeting 9 to 5 hurt job applicants?

Body:
If you were looking into a job applicant's background and discovered that he or she has 1200 followers on Twitter and averages 50 tweets per day (more than half of which are during business hours), would it affect your hiring decision? How and why?

Personally, I'd be a little worried about the candidate's ability to focus on the job at hand if they're constantly checking in with their 'tweeps' thoughout the day. In non-tech jobs, a lot of companies simply block Twitter as an irrelevant distraction.  But it can be a useful resource---to programmers in particular. I just wonder how much is too much. At what point does it become a red flag?


问:
Combining getters and setters
JavaScript libraries such as jQuery, combine 'getters' and 'setters' in the programming interface for example:

```<code> $('element').css({'color','blue'});
</code>```

will set the color or

```<code> $('element').css();
</code>```

will get the css for an element.

Is there a name for such a pattern and is it a good practice to use in applications?

答:
I'm kinda totally against that for a simple reason: A Class, Method or Function should just do one thing -- in my opinion, and combining the getter and setter method will breach that rule. As the result:

The return value of the function varies based on if getter or setter block get executed. This one can simply lead you into a maintainability nightmare. Your method should return only one type of data/object in any case -- or return null, false or throw an exception in case of error.

Writing Unit Tests will be harder as the function is responsible for two totally different functionality.

Writing documentation for such a method or function is harder for obvious reasons.

It won't be consistent when multiple getter methods needed -- as already mentioned in Blrfl answer.

Title: Combining getters and setters


问:
Why are pointers to literals not possible?
Reference to a literal is possible only if the reference  is declared as constant.

But why is a pointer to a const object not possible in case of literals?
i.e.

```<code>int const& ref = 5;//
</code>```

But why is the same feature not available for a pointer, pointing to a constant object?

答:
In my opinion, this behavior comes from the semantical differences of pointers and references in C++.

The following code snippet with reference works fine:

```<code>const int& r = 5;
std::cout << &r << std::endl;
</code>```

... since a temporary object is created when you assign the value to the const reference, and you can take the address of that temporary object.

The equivalent code snippet with pointer would be like this:

```<code>const int *p = &5;
std::cout << p << std::endl;
</code>```

This one, however, does not compile, since &5, i.e. address of 5, has no meaning in C.

Body:
In my opinion, this behavior comes from the semantical differences of pointers and references in C++.

The following code snippet with reference works fine:

const int& r = 5;
std::cout << &r << std::endl;

... since a temporary object is created when you assign the value to the const reference, and you can take the address of that temporary object.

The equivalent code snippet with pointer would be like this:

const int *p = &5;
std::cout << p << std::endl;

This one, however, does not compile, since &5, i.e. address of 5, has no meaning in C.


答:
In Python you have the print command(function since v3) that prints to the standard output. You don't specify explicitly that you want to print to STDOUT - it's done for you implicitly behind the scenes.

Implicitly. In Python. And no one has a problem with that. Why?

print is part of the Python language, and one requirement of programming in Python is... well... knowing Python. And if you know Python, you know that print targets STDOUT. No surprises there.

Python - as a language - can define it's own convention and assume that the programmers are aware of them.

Frameworks also enjoy that privilege - that's one of the key differences between a framework and a library. You don't have to learn a library in order to use it - you just need to find the part of the API that you need, and assume it follows the conventions of the language(or framework). That's why you don't see recruiters looking for people with knowledge in GSON or Apache Commons. But you do see recruiters looking for people with experience with JQuery or Ruby on Rails or ASP.NET MVC - because those are frameworks that define their own conventions that you need to learn and be aware of.

Flask, as a framework, can define a convention for storing the context in a thread-local global - and it shouldn't surprise anyone, so it's not an anti-pattern.

Title: Global request context - anti-pattern?

Body:
I was talking today to a colleague of mine about Python web frameworks and our impressions about them. I told him I think Flask having a global request smells badly and is an anti-pattern.

The docs say about request context:

In contrast, during request handling, a couple of other rules exist:

while a request is active, the context local objects (flask.request and others) point to the current request.

any code can get hold of these objects at any time.

I think I understand the idea behind this design decision -- to make the application simpler. It's just a compromise, like in the case of Thread Locals:

Yes it is usually not such a bright idea to use thread locals. They
  cause troubles for servers that are not based on the concept of
  threads and make large applications harder to maintain. However Flask
  is just not designed for large applications or asynchronous servers.
  Flask wants to make it quick and easy to write a traditional web
  application.

Is patching a global object with the current request information an anti-pattern?

I believe it is, because it is in the view of static code analyzer a global state, though it's not. And I as a programmer will not understand how it works without reading the docs carefully. And this has consequences on tests.

Isn't it a good practice to pass the request as an argument to views? I think it's more readable, explicit and easier to debug. And avoids global state.