问:
What is the disadvantage of using abstract class as a database connectivity in zend framework 2 instead of service locator
If I use database by creating adapter with drivers, initialize it in some abstract class and extend that abstract class to required model. Then use simple query statement. Like this:

```<code>namespace My-Model\Model\DB;
abstract class MysqliDB {
    protected $adapter;

    public function __construct(){
        $this->adapter = new \Zend\Db\Adapter\Adapter(array(
                'driver' => 'Mysqli',
                'database' => 'my-database',
                'username' => 'root',
                'password' => ''
        ));
    }

}
</code>```

And use abstract class of database like this in my models:

```<code>class States extends DB\MysqliDB{

    public function __construct(){
        parent::__construct();
    }
    protected $states = array();

    public function select_all_states(){
        $data = $this->adapter->query('select * from states');
        foreach ($data->execute() as $row){
            $this->states[] = $row;
        }
        return $this->states;
    }
}
</code>```

I am new to zend framework, before i have experience of working in YII and Codeigniter.
I like the object oriented in zend so i want to use it like this.
And don't want to use it through service locater something like this:

```<code> public function getServiceConfig(){
        return array(
            'factories' => array(
            'addserver-mysqli' => new Model\MyAdapterFactory('addserver-mysqli'),
            'loginDB' => function ($sm){
                $adapter = $sm->get('addserver-mysqli');
                return new LoginDB($adapter);
            }
        )
        );

    }
</code>```

In module.
Am i Ok with this approach?

答:
Abstract classes don't share.

The primary benefit of the service locator in this instance is that a request will only open a single adapter to the database and share that adapter with all objects that request it. Whereas in your structure of extending from abstract classes each instance will setup a new adapter to run its statements against the database.

```<code>$states1 = new States();
$states2 = new States();
</code>```

Right there are two separate database connections.

Body:
Abstract classes don't share.

The primary benefit of the service locator in this instance is that a request will only open a single adapter to the database and share that adapter with all objects that request it. Whereas in your structure of extending from abstract classes each instance will setup a new adapter to run its statements against the database.

$states1 = new States();
$states2 = new States();

Right there are two separate database connections.


问:
Zend 'Page Tile' view helper
I've created a ZF2 view helper PageTitle (extending Zend\View\Helper\AbstractHelper). As the name of the helper suggests , it is responsible for rendering the page title for each action view script.

So within each action view script (not layout) I would call :

```<code> echo $this->pageTitle('My Page Title', 'some-icon-class-name');
</code>```

This would render the required HTML output

```<code> <div class="page-title">
   <h1><span class="some-icon-class-name"></span> My Page Title</h1>
 </div>
</code>```

The plugin also contains another view helper (button) within it; its job is to render zero or more form button elements.

My trouble comes when I need to pass these page specific buttons/links. My current solution is to provide an array of 'buttons' as a third parameter.

```<code>$this->pageTitle('My Page Title', 'some-icon-class-name', array(
  'button label 1' => array(
    'attributes' => array(
      'class' => array('some-class-name', 'another-class'),
      'data-foo' => 'bar',
    ),
 )));
</code>```

(Above is just an example of what I have tried to demonstrate the issue. This is in fact numerous buttons, each with several 'attributes' each)

I think the above approach is messy, certainly within the view. It also defeats the purpose of even having a view helper as I will need to provided this config again each time I need to reuse the page header (some pages may use other views as children).

Some solutions I have considered.

Create a page title service factory, per page

Each factory will create a new PageTitle plugin and inject the 'button' config into it. This is then registered ti the view plugin manager under a unique plugin name.

So, as an example, I would change the call in my view to:

```<code>echo $this->mySpecificPageTitle(); // no args as pre-constructed
</code>```

The downside here is that I then need to create allot of factories (just so I can provide very slightly varied arguments).

Provided a 'service' name to the plugin

(this is similar to the navigation view helper) then then helper calls this service and it returns the required configuration.

For example:

```<code>echo $this->pageTitle('My Page Title', 'some-icon-class-name', 'MyButtonService');
</code>```

So within the helper:

```<code>$buttonConfig = $serviceManager->get('MyButtonService');
</code>```

This however again means that I would need to create a factory for each 'MyButtonService' I need.

答:
I would migrate the plugin code out of the __invoke method and instead return an instance of your view helper object. From there provide methods for adding buttons which store the data temporarily in an internal data store (array). From there you then just need a render method which uses all the stored data to build the output. This way you don't have an ever increase list of parameters and can provide easier to call methods which have a specific purpose.

Sample Usage:

```<code>echo $this->pageTitle()->setTitle('My Title')->setIcon('some-icon')->addButton('Test Btn')->addButton('Another Button', array('class' => 'some-class'))->render();
</code>```

All that is required for this is an __invoke that simple does return $this and the methods above saving their inputs to internal class parameters. Your existing code can be dropped in the render method and slightly re-factored and you should be set.

ContentLicense: CC BY-SA 3.0

Title: Zend 'Page Tile' view helper

Body:
I would migrate the plugin code out of the __invoke method and instead return an instance of your view helper object. From there provide methods for adding buttons which store the data temporarily in an internal data store (array). From there you then just need a render method which uses all the stored data to build the output. This way you don't have an ever increase list of parameters and can provide easier to call methods which have a specific purpose.

Sample Usage:

echo $this->pageTitle()->setTitle('My Title')->setIcon('some-icon')->addButton('Test Btn')->addButton('Another Button', array('class' => 'some-class'))->render();

All that is required for this is an __invoke that simple does return $this and the methods above saving their inputs to internal class parameters. Your existing code can be dropped in the render method and slightly re-factored and you should be set.


问:
Why do a lot of logging frameworks provide individual methods instead of a enum 'level'?
I see some of the more preferred logging frameworks like log4j, log4net etc all use 'trace, debug' etc methods.

Why do they use these instead of methods that take something like a enum level?

答:
Log4j, at least, has both. The methods with just the log level name such as logger.debug(...) are convenience methods that simply call logger.log(DEBUG, ...). You can read more about this at the Custom Log Levels documentation page:

Convenience Methods for the Built-in Log Levels

The built-in log levels have a set of convenience methods on the Logger interface that makes them easier to use. For example, the Logger interface has fourteen debug() methods that support the DEBUG level:

```<code>// convenience methods for the built-in DEBUG level
debug(Marker, Message)
debug(Marker, Message, Throwable)
...
</code>```

Body:
Log4j, at least, has both. The methods with just the log level name such as logger.debug(...) are convenience methods that simply call logger.log(DEBUG, ...). You can read more about this at the Custom Log Levels documentation page:

Convenience Methods for the Built-in Log Levels

The built-in log levels have a set of convenience methods on the Logger interface that makes them easier to use. For example, the Logger interface has fourteen debug() methods that support the DEBUG level:

// convenience methods for the built-in DEBUG level
debug(Marker, Message)
debug(Marker, Message, Throwable)
...


问:
Why should I use a factory class instead of direct object construction?
I have seen the history of several С# and Java class library projects on GitHub and CodePlex, and I see a trend of switching to factory classes as opposed to direct object instantiation.

Why should I use factory classes extensively? I have pretty good library, where objects are created the old-fashioned way - by invoking public constructors of classes. In the last commits the authors quickly changed all of the public constructors of thousands of classes to internal, and also created one huge factory class with thousands of CreateXXX static methods that just return new objects by calling the internal constructors of the classes. The external project API is broken, well done.

Why would such a change be useful? What is the point of refactoring in this way? What are the benefits of replacing calls to public class constructors with static factory method calls?

When should I use public constructors, and when should I use factories?

答:
Constructors are fine when they contain short, simple code.

When initialization becomes more than assigning a few variables to the fields, a factory makes sense. Here are some of the benefits:

Long, complicated code makes more sense in a dedicated class (a factory). If the same code is put in a constructor which calls a bunch of static methods, this will pollute the main class.

In some languages and some cases, throwing exceptions in constructors is a really bad idea, since it can introduce bugs.

When you invoke a constructor, you, the caller, needs to know the exact type of the instance you want to create. This is not always the case (as a Feeder, I just need to construct the Animal in order to feed it; I don't care if it's a Dog or a Cat).


答:
Factory classes are often implemented because they allow the project to follow the SOLID principles more closely.  In particular, the interface segregation and dependency inversion principles.

Factories and interfaces allow for a lot more long term flexibility.  It allows for a more decoupled - and therefore more testable - design.  Here is a non-exhaustive list of why you might go down this path:

It allows you to introduce an Inversion of Control (IoC) container easily

It makes your code more testable as you can mock interfaces

It gives you a lot more flexibility when it comes time to change the application (i.e. you can create new implementations without changing the dependent code)

Consider this situation.

Assembly A (-> means depends upon):

```<code>Class A -> Class B
Class A -> Class C
Class B -> Class D
</code>```

I want to move Class B to Assembly B, which is dependent on Assembly A.  With these concrete dependencies I have to move most of my entire class hierarchy across.  If I use interfaces, I can avoid much of the pain.

Assembly A:

```<code>Class A -> Interface IB
Class A -> Interface IC
Class B -> Interface IB
Class C -> Interface IC
Class B -> Interface ID
Class D -> Interface ID
</code>```

I can now move class B across to assembly B with no pain whatsoever.  It still depends on the interfaces in assembly A.

Using an IoC container to resolve your dependencies allows you even more flexibility.  There is no need to update each call to the constructor whenever you change the dependencies of the class.

Following the interface segregation principle and the dependency inversion principle allows us to build highly flexible, decoupled applications.  Once you have worked on one of these types of applications you will never again want to go back to using the newkeyword.

Title: Why should I use a factory class instead of direct object construction?

Body:
I have seen the history of several С# and Java class library projects on GitHub and CodePlex, and I see a trend of switching to factory classes as opposed to direct object instantiation.

Why should I use factory classes extensively? I have pretty good library, where objects are created the old-fashioned way - by invoking public constructors of classes. In the last commits the authors quickly changed all of the public constructors of thousands of classes to internal, and also created one huge factory class with thousands of CreateXXX static methods that just return new objects by calling the internal constructors of the classes. The external project API is broken, well done.

Why would such a change be useful? What is the point of refactoring in this way? What are the benefits of replacing calls to public class constructors with static factory method calls?

When should I use public constructors, and when should I use factories?

Body:
Factory classes are often implemented because they allow the project to follow the SOLID principles more closely.  In particular, the interface segregation and dependency inversion principles.

Factories and interfaces allow for a lot more long term flexibility.  It allows for a more decoupled - and therefore more testable - design.  Here is a non-exhaustive list of why you might go down this path:

It allows you to introduce an Inversion of Control (IoC) container easily

It makes your code more testable as you can mock interfaces

It gives you a lot more flexibility when it comes time to change the application (i.e. you can create new implementations without changing the dependent code)

Consider this situation.

Assembly A (-> means depends upon):

Class A -> Class B
Class A -> Class C
Class B -> Class D

I want to move Class B to Assembly B, which is dependent on Assembly A.  With these concrete dependencies I have to move most of my entire class hierarchy across.  If I use interfaces, I can avoid much of the pain.

Assembly A:

Class A -> Interface IB
Class A -> Interface IC
Class B -> Interface IB
Class C -> Interface IC
Class B -> Interface ID
Class D -> Interface ID

I can now move class B across to assembly B with no pain whatsoever.  It still depends on the interfaces in assembly A.

Using an IoC container to resolve your dependencies allows you even more flexibility.  There is no need to update each call to the constructor whenever you change the dependencies of the class.

Following the interface segregation principle and the dependency inversion principle allows us to build highly flexible, decoupled applications.  Once you have worked on one of these types of applications you will never again want to go back to using the newkeyword.


问:
How I could update a DB table using a POCO class bound in a DataGridView
I try to explain better using an example:

I create the class Product with attibutes like that:

```<code>private string _ProductCode = "";
[DisplayName("ProductCode")]
public String ProductCode
{
   get { return _ProductCode; }
   set { _ProductCode = value; OnPropertyChanged("ProductCode"); }
}
</code>```

the class Product implements the interfaces: INotifyPropertyChanged, IEditableObject

I create the class ProductList that has the following property:

```<code>public List<Product> Products { get; set; }
</code>```

I bind the class Product in a DataGridView control using the DataSource property

```<code>MyGridView.DataSource = ProductList.Products;
</code>```

I have the table ProductListTable on db SqlServer that has more column than the class Product

When I push the button "Save" on my form I'd would like to save the ProductList on ProductListTable

I'm really confusing about the way to follow ... I have to use Link 2 Sql, Entity Framework? I'm searching for something simple for a small project, but using POCO classes for rapresenting the data layer.

Now how I should proceed for linking class to DB table?

答:
You can use Dapper. It is really simple, it boils down to having right sql. Here is example.
PS: Use NuGet in VS and search for Dapper.</p>

```<code>using(var con = new SqlConnection(connectionString))
{
    con.Open();
    con.Execute(
        @"insert ProductListTable(ProductCode, ...) values (@ProductCode, ...)",
        ProductList.Products
    );
}
</code>```

OwnerDisplayName: tagetek

Body:
You can use Dapper. It is really simple, it boils down to having right sql. Here is example.
PS: Use NuGet in VS and search for Dapper.

using(var con = new SqlConnection(connectionString))
{
    con.Open();
    con.Execute(
        @"insert ProductListTable(ProductCode, ...) values (@ProductCode, ...)",
        ProductList.Products
    );
}


问:
Choosing a diff program for Mercurial
I decided to try to contribute Firefox development, and they use Mercurial for source control. In the documentation about using Mercurial it was advised to choose a diff program and to do it before you start coding. They list a bunch of options, one of which appears to be the standard Unix/Linux diff program, which I'm somewhat familiar with via basic use. </p>

<p>The thing is, I hadn't realized that the diff program can even be an issue and I have a feeling that I won't know how to pick one until I pick the wrong one and get screwed by it somehow. So to skip this unnecessary hurdle, I'd like to ask what should I look at when choosing a diff program, and in what cases is the choice important (and in what way)? </p>

答: I'm a fan of Meld.  I never thought I'd move to a gui diff util until Meld came along.  It's simple, supports diffing many things (revisions, directories, files, etc), can do two-way or three-way diffs, and makes manually merging files a breeze.

ContentLicense: CC BY-SA 2.5

Title: Choosing a diff program for Mercurial


答:
If you work with interfaces then you can remain independent of the actual implementation. A factory can be configured (via properties, parameters or some other method) to instantiate one of a number of different implementations.

One simple example: you want to communicate with a device but you don't know if it will be via Ethernet, COM or USB. You define one interface and 3 implementations. At runtime you could then select which method you want and the factory will give you the appropriate implementation.

Use it often...


答:
Like whatsisname said, I believe this is case of cargo cult software design. Factories, especially the abstract kind, are only usable when your module creates multiple instances of a class and you want to give user of this module ability to specify what type to create. This requirement is actually quite rare, because most of the time you just need one instance and you can just pass that instance directly instead of creating an explicit factory.

The thing is, factories (and singletons) are extremely easy to implement and so people use them a lot, even in places where they are not necessary. So when programmer thinks "What design patterns should I use in this code?" the Factory is first that comes to his mind.

Many factories are created because "Maybe, one day, I will need to create those classes differently" in mind. Which is a clear violation of YAGNI.

And factories become obsolete when you introduce IoC framework, because IoC is just a kind of factory. And many IoC frameworks are able to create implementations of specific factories.

Also, there is no design pattern that says to create huge static classes with CreateXXX methods which only call constructors. And it is especially not called a Factory (nor Abstract Factory).


问:
Origin of letter "X" for close icon
Who exactly presented the idea that letter "X" should be used for closing/exiting a window or an application?

According to Medium.com,

The first appearance of [x] in GUI design was likely the Atari TOS, possibly influenced by the Japanese batsu and maru conventions. Thanks to a last minute design change in Windows 95, and the mass adoption of Windows worldwide, [x] has become the standard symbol for ‘close’, a symbol that dominates web, app and software design today.

It is stating that letter "x" for closing/exiting a app originated around 1995 but according to my senior, letter "x" for exit was used first in 1980's in  wordstar 4 on CP/M OS.

答:
The first GUI use of X for exit was Atari TOS in 1985.

The first PC keyboard shortcut use of X for exit may have been the North Star Horizon OS, which dates back to 1977.

In the early Wordstar versions, X was used for down-line and there was no mouse, obviously.

Title: Origin of letter "X" for close icon


问:
Equal or less than 15 lines per method(function) principle?
Some books or master told us this principle: Equal or less than 15 lines per method(function), and the perfect is under(or equal) 8 lines.

Does the principle make sense for most conditions?

There are many cases break the principle in Windows OSX Android UNIX SDKs, so how to deal with the principle?

What are the exceptions for this principle?

Is it worth to take a lot of time to refactor exist code to fit this principle?

How about call another method just at 15th line?(kidding)

答:
I hear "rules" like this all the time, but it's all to easy to try too hard to adhere to these types of rules.

I've seen code where functions are broken into illogical blocks simply to keep functions short.

I'd say that common sense is the best rule.

No one is ever going to be able to come up with a number that works in every situation. If you find a logical block of statements that can be refactored into a new method, do it and you should find your method lengths as reasonable as possible.

If you can't, but you notice that methods are getting unreasonably long, take it not as a sign you should raze them down to an arbitrary number of lines, but that maybe something else needs to be refactored, for example, maybe the class as a whole has too much responsibility.

Edit:  SJuan76 also brings up an excellent point:

Q: When is 15 lines of code not really 15 lines of code?

A: When it's 15 lines of logging values/trival input validation/(etc.)

That's one of the biggest pitfalls of using lines of code as a metric, even if it's a narrow case like this. Lines of code don't convert/equate to any useful measure of "work".  In one environment 10 lines might just be enough to configure an error logger, in another, 2 lines might be enough, I'd say in both cases would merit one method.


问:
Self-Evaluation: How do I know if I actually have a "good grasp" of OOP?
If I skip the back story and any thoughts I have on this topic, there's really only one question left to ask:

How can I find out if I have a "good grasp" on OOP?

(I am specifically using PHP, but it probably won't matter...)

Right now I kind of think of classes as a collection of functions with some global-ish variables accessible by all those functions. This helps to reuse code, keep files short and the namespace clean.

Some of you mentioned inheritance: To me that again just means that I can extend an existing class with more functions and more global-ish variables. It's like an add on to my existing class. And the same benefits come into place: reuse code, keep files short.

I have a ominous feeling that I'll be disillusioned here in a minute...

答:
How can I find out if I have a "good grasp" on OOP?

Normally, when I look at webinars (and read blog-posts and such), I try to see how many concepts I struggle with. Lately (in the past year or so) I tend to understand most of what I read. This is a very subjective question, by the way.

Right now I kind of think of classes as a collection of functions with some global-ish variables accessible by all those functions.

That's a limited view. You can also look at classes as:

encapsulation units

concept expressions (see "is-a" vs. "has-a")

actors within a protocol

building blocks within a global design

Things to look into:

design patterns

UML (models the relationships between objects quite nicely)

method virtualization and "interface as a contract"

There are more, and some of them are only relevant in some contexts (for example, in C++ you can talk about regular and semi-regular types)


问:
Which Continuous Integration framework do you use and why?
There are quite a few different Continuous Integration (CI) frameworks out there and I'm wondering which is the most popular.  Which frameworks have you used at firms where you work?

Is there any reason one CI framework is more popular than another - perhaps this is to do with the features it offers, things that integrate into it or maybe its just marketing?

It seems like continuous integration is used more in the Java and .net worlds than say ruby or python.  Why is this?

答:
I use both CruiseControl.NET and Hudson.  Some of my builds are on one of them and some are on the other.

Why?  Because I am not the build engineer and he who is the build engineer set them up this way!

I don't have a problem with the way my builds are set up or complaints about either product.  I'm reporting to you the way the things are here, matter-of-factly and hope you appreciate this perspective!

UPDATE: Since I posted the answer, Hudson has been forked and became Jenkins.  The above recommendation applies to Jenkins.


答:
I assume that I know a system sufficiently well, if…

I know what parts of that system I don't know intimately. E.g., I might know that some obscure feature X exists, but I wouldn't know off hand how to use that. Having skimmed through all documentation can help here.

I know how that system compares unfavourably to competing systems. I.e., I know the system close enough to know its warts. Knowing multiple sufficiently different systems is helpful here. In the case of OOP implementations, it would be interesting to compare Java with ECMAScript, as they are drastically different.

If you have a good grasp of OOP, you should be able to give an interesting answer to at least half of these questions:

What is an object?

What is a class?

Do we need classes for OOP? What other possibilities are there?

What is a method? How are methods different from ordinary functions/procedures/subroutines? How is a method call resolved?

Why is there a this or self parameter/keyword in methods? What is open recursion?

How is OOP different from other paradigms such as functional, procedural, or modular programming?

How is OOP related to Abstract Data Types?

What strategies for code reuse does OOP offer?

How does inheritance work?

What is multiple inheritance, and what are the problems associated with this? What possible solutions exist?

What are classes, abstract classes, interfaces, mixins, and traits? (Note that most OOP implementations only offer some of these)

Can you list a few common OOP design patterns? Which problems do they solve? Do you know OOP systems that don't require explicit implementation of these patterns?

What are common OOP anti-patterns?

What is the relation between the command pattern and functional programming?

What is the relation between a constructor and a factory method?

What is encapsulation?

What does the acronym SOLID stand for?

What is the single responsibility principle?

What is the open/closed principle?

What is the Liskov Substitution Principle?

What is the depencency inversion principle? How can this be achieved?

Title: Self-Evaluation: How do I know if I actually have a "good grasp" of OOP?

Body:
If I skip the back story and any thoughts I have on this topic, there's really only one question left to ask:

How can I find out if I have a "good grasp" on OOP?

(I am specifically using PHP, but it probably won't matter...)

Right now I kind of think of classes as a collection of functions with some global-ish variables accessible by all those functions. This helps to reuse code, keep files short and the namespace clean.

Some of you mentioned inheritance: To me that again just means that I can extend an existing class with more functions and more global-ish variables. It's like an add on to my existing class. And the same benefits come into place: reuse code, keep files short.

I have a ominous feeling that I'll be disillusioned here in a minute...


问:
How can I share a managed DBConnection across various objects?
I am implementing what I thought was a simple object wrapper around a database where one object "PartRecord" represents one row of a database table.

I want a client to be able to request a given record and to receive an object that contains the data.  The data read and exposed properties are all a piece of cake, but I am trying to share the MySqlConnection object in a coherent way.

My initial naive implementation was to keep a private MySqlConnection object in a VB module and to have a functions that my classes can call. This would effectively be a singleton that any of my classes could share.

```<code>Private MySqlCn as MySqlConnection

Friend Function GetMySqlConnection() as MySqlConnection
   If IsNothing(MySqlCn) then  MySqlCn = New MySqlConnection(cnstring)
   if MySqlCn.State = ConnectionState.Closed then MySqlConnection.Open(cnstring)
   Return MySqlCn
End Function

Friend Sub CloseMySqlConnection()
   If Not IsNothing(MySqlCn) AndAlso (Not MySqlCn.State = ConnectionState.Closed) Then  MySqlCn.Close
End Function
</code>```

With this method you can generally ensure that the objects will share a connection and that it will be open whenever the database is available, but you cannot guarantee that the connection gets closed until the program ends.

Some alternatives that I have tried:

close connection after every read

```<code>'in PartRecord constructor:
Using MySqlCn as MySqlConnection = GetMySqlConnection
  'read data
End Using
'this causes an open and close for every object you instantiate
'obviously bad
</code>```

just leave it open

```<code>'in constructor:
Dim MySqlCn as MySqlConnection = GetMySqlConnection
'read data
'no close or dispose, open for the next guy
'we are sharing an open connection, but
'the connection won't really close until the program ends.
'I think it will close then, but I was a lot more certain of it
'in the COM days when I could wrap it in a class and
'close it in the Terminate event when the reference count hit zero
</code>```

quit having public constructors and have a object factory that implements IDisposable to manage the connection

```<code>'maybe not as nice for the client code
'but does force a sharing of connections
'and the client can call PartFactory.Close or PartFactory.Dispose when they are done
'the PartFactory replaces the singleton
'even though you could have more than one if you wanted
</code>```

your better idea . . .

I would like to know if I can keep my preferred style of public object constructors for a given record, but still manage the shared connection in a responsible way.  I think this might be impossible since the standalone publicly creatable objects do not know when the client is ever done. I think I must leak the "we are connecting to a database y'know" abstraction to the client or else cause open connections or unnecessary network traffic.

Also, the documentation tells you that IDisposable is usually used for unmanaged things (files, handles, etc).  Is is appropriate/necessary for holding a managed object like a .NET DBConnection object? I like that the client would have the Using syntax and that I am signalling that it needs closed in a standard way, but is the deterministic close that I am trying to get necessary and worth my effort in a garbage collected world?  I am not comfortable saying "well the connection will close eventually when no one wants it" since this component will be eventually be used by many different clients in the organization.  What if they crash, or we use it in a long-running server process?

If it matters, this is the first of several DB wrapper classes.  Whatever scheme I use here, I want to maintain across the entire component.

答:
Don't share a connection, unless you have multiple commands in a single transaction (which requires you to keep the connection open). Open / Close after each action which you state as 'obviously bad' is actually the way to go, as connection pooling makes sure you don't lose much (if at all) time. </p>

<p>It also looks like you're re-inventing some data-access system, and you're on track to do it poorly (as you don't know how to solve this simple solution). Pick one of the shelve (there are many free / OSS ones if you don't want a commercial solution) and spend your time on what you should do: write business logic instead of plumbing code. </p>

Body:
Don't share a connection, unless you have multiple commands in a single transaction (which requires you to keep the connection open). Open / Close after each action which you state as 'obviously bad' is actually the way to go, as connection pooling makes sure you don't lose much (if at all) time.

It also looks like you're re-inventing some data-access system, and you're on track to do it poorly (as you don't know how to solve this simple solution). Pick one of the shelve (there are many free / OSS ones if you don't want a commercial solution) and spend your time on what you should do: write business logic instead of plumbing code.


问:
Point estimates scale skewed
When using planning poker for estimates, we've ended up with effectively a non-linear points scale. By that I mean that point value is inconsistent for one-pointers and, say, eight-pointers. Couple examples each:

1 point: add tooltip text to a couple of icons; format date&time strings

3 points: create new user role and specify their permissions; automatically create a new case in CRM whenever certain actions are performed

5 points: watchlist functionality; filtering functionality on several facets

8 points: integrate with a third party provider *and* introduce a persistence layer to cache their responses

My concern is two-fold: we lose estimating fidelity by restricting ourselves to the low-end of the scale and any reporting (or calculating average velocity) will be erroneous.

How can I entice the scrum master, product owner and the team to use a more consistent, linear scale?

Edit: just to clarify, we are using one of the traditional decks that goes all the way up to 100... except we've somehow anchored ourselves to not go over 5, ending up with effectively a logarithmic scale.

答:
For me there is nothing wrong with the fibunacci scale, from what I read and see as examples the problem lies more in the estimates, or the way you estimate.

I do not know the exact situation that you are in, but there seems to be an imbalance between the estimates on the lower ends and the estimates on the higher ends. 8 times a task like adding tooltip text to a couple of icons do not seem to match integrating with integrating 3rd party software and caching the responses.

I know it is not good to compare story points to man days, but I usually seek for a story that will take the developers about 1 day of work, everything included. I don't tell them that I think it is about 1 day of work, I want to avoid that they compare the points to days. This will be our reference story that gets 2 story points. If another story is only half the work, it will be a 1, if another story is small enough, it might be a 1/2. We pick a good 2 story points story that allows us to go small enough. For bigger stories we always compare them with the reference story and stories that have already been found with a higher number. I see in my team that it helps to have some good reference stories lying on the table with a 1/2, 1, 2, 3, 5, 8 story point estimate. Humans are much better at comparing that at measuring.

We also avoid going to big as you do. The limit is often set to 8 SP's. The team is allowed to go above the 8 SP in the original estimates, but this almost always results in splitting it up into smaller parts and estimating these parts again.

No one stops you from using a 4 or a 6 or even a 10 if you feel that the team is not confortable of using the fibonacci numbers for a certain story. We do it also from time to time. We do avoid to do this to often.

And yes, sometimes your estimates are wrong. It happens to every team. But the law of the big numbers tells me that if I estimate 10 stories to be an 8, statistically these stories are on average an 8.

For your 8 SP story, I would recommend to first take away the uncertanty. I see a number of possibilities for this that can even be combined.

Split the story in an integration part and a caching part.

Clearly define cases to integrate in stead of trying to integrate every specific case at once.

Go for a timeboxed effort to get to know the third party soft better before estimating.

Title: Point estimates scale skewed


问:
Estimation of space is required to store 275305224 of 5x5 MagicSquares?
Here are some examples of 5x5 Magic Squares found by some good solvers :

Magic Square Generator by Marcel Roos

this program state using 2.4GHz Intel  takes about 95 hours to generate all solutions.

open source tool

```<code>Magic squares 5x5
Sum must be: 65

Solution:             1
  1  2 13 24 25
  3 23 17  6 16
 20 21 11  8  5
 22  4 14 18  7
 19 15 10  9 12

Solution:             2
  1  2 13 24 25
  3 23 16  8 15
 21 19 10  6  9
 22  4 14 20  5
 18 17 12  7 11

Solution:             3
  1  2 13 24 25
  3 23 19  4 16
 21 15 10 12  7
 22  8  9 20  6
 18 17 14  5 11

 ...
</code>```

The number of all possible solutions is 275305224. Since calculation of all solutions takes a very long time, I would like have one person with a high speed computer find all solutions (in a long continues span of time) and then share them on the web for other people.

What would be an efficient way to store these solutions, using some sort of compression?

(simple logical trick)by attention to the principle that the sum in all rows and columns and diagonal are equal to 65

we only need to know the value for only 14 cells of 25 cells as shown below , this cause the storage space almost reduce to half 14/25

legend:+ means stored value and x means skipped value !

```<code>+ + + + x
+ + + + x
+ + + + x
x + x + x
x x x x x
</code>```

答:
25 cells each of a number < 255, means each occupies 25 bytes.
25 * 275305224 is 6,563Mb or 6.4Gb.

That's uncompressed. Compressed - it depends on the compression algorithm but you're probably looking at a couple of gig no matter what.


问:
How to generalize a classes that has identical function plus some additional function
I have some designing problems with my project. To illustrate my problem, I'll use the following two classes from my project.

```<code>public class RAM_UserManagement{
  private Map<int,User> userList;
  public User addUser(User user){//do stuff}
  public User deleteUser(User user){//do stuff}
  public User updateUser(User user){//do stuff}
  public List<User> getAllUser(){//do stuff}
  public User getUserById(int userId){//do stuff}
}

public class RAM_ServiceManagment{
  private Map<int,Serivce> serviceList;
  public Service addService(Service ser){//do stuff}
  public Service deleteService(Service ser){//do stuff}
  public Service updateService(Service ser){//do stuff}
  public List<Service> getAllSerivces(){//do stuff}
  public Service getServiceById(int id){//do stuff}
  public Service getServiceByStatus(ENUM_STATUS status){//do stuff}
  public Service getServiceByUserName(String Name){//do stuff}
}
</code>```

As you can see, from the nature of these classes they both doing exact same thing with some extra functionality. I am trying to generalize it by creating an interface. This is what I have in mind

```<code>public interface IStorage<T>{
  public T add(T item);
  public T delete(T item);
  public T update(T item);
  public List<T> getAll();//This is where I am struggling..
}
</code>```

So CUD operation in both classes are ok to implement but the R(Read) method in both classes varies. In RAM_ServiceManagement I have extra getAll, getById, getStatus, getByName than the other class.

How can I generalize this? or generalization cannot be applied here at all? Really appreciate if you can give some suggestion.

Thanks

答:
I'd try something like the following:

```<code>public abstract class RAM_Management<T> {
    protected Map<Integer, T> dataList;
    public T addData(T data) { /* ... */ }
    public T deleteData(T data) { /* ... */ }
    public T udpateData(T data) { /* ... */ }
    public List<T> getAllData() { /* ... */ }
    public T getDataById(int id) { /* ... */ }
}

public class RAM_UserManagement extends RAM_Management<User> {
    // needs no separate implementation
}

public class RAM_ServiceManagement extends RAM_Management<Service> {
    public Service getServiceByStatus(ENUM_STATUS status) { /* ... */ }
    public Service getServiceByUserName(String name) { /* ... */ }
}
</code>```

By using an abstract base class instead of an interface, you avoid the need to re-write your implementations of the common methods (assuming that all they do is interact with the protected dataList member.) I've also assumed that both classes' getXXXById methods work the same; if they don't, then you just take it out of the abstract class and implement it in your concrete classes.

Body:
I'd try something like the following:

public abstract class RAM_Management<T> {
    protected Map<Integer, T> dataList;
    public T addData(T data) { /* ... */ }
    public T deleteData(T data) { /* ... */ }
    public T udpateData(T data) { /* ... */ }
    public List<T> getAllData() { /* ... */ }
    public T getDataById(int id) { /* ... */ }
}

public class RAM_UserManagement extends RAM_Management<User> {
    // needs no separate implementation
}

public class RAM_ServiceManagement extends RAM_Management<Service> {
    public Service getServiceByStatus(ENUM_STATUS status) { /* ... */ }
    public Service getServiceByUserName(String name) { /* ... */ }
}

By using an abstract base class instead of an interface, you avoid the need to re-write your implementations of the common methods (assuming that all they do is interact with the protected dataList member.) I've also assumed that both classes' getXXXById methods work the same; if they don't, then you just take it out of the abstract class and implement it in your concrete classes.


问:
Efficiency of self-education
Do you think being self-educated in software development is good? Please give an example of what you have learnt successfully by yourself.</p>

答:
Apparently all answers agree that self-education is everything. I don't think that's completely right. A good teacher can teach you a lot and especially can teach you fast. Obviously at some point you have to take the matters into your own hands and start researching, reading, trying. Even a book is written by someone (a teacher) and tries to teach you something. That same person could be standing in the room and replying to all your questions instead of making you waste time in searching. Searching and banging your head against the wall on the other hand will make the lessons learned very valuable and unlikely to be forgotten.

Especially for starting in a new subject I think a good teacher is very very very helpful. And those who are so keen on self-education should self-educate without wikipedia, without stackoverflow, without books and without blogs ;-)

Title: Efficiency of self-education


问:
Reliable secure data exchange between service written on .NET and an iOS client app
I have a service written on .NET working on a company server. It designed to do a very simple thing, to receive a request via WCF named pipes from another service working locally on the same server, process it and send a response through named pipes back. Request an response are just a fairly small, XML formatted text.

And now I need to couple it somehow with our in-house iOS application to do the same thing but with a remote connection through internet. I'm not all too experienced with an Objective-C iOS development and not sure how to proceed. I was considering adding a TCP endpoint to the same WCF service but then I'm not sure how reliable will it be plus I'll have to use some sort of encryption "manually" on both ends of the connection.

I can extend or change code of both .NET server and Objective-C iOS client as much as I need but I'm not sure how to ensure reliability and most of all security of data transfer between server and client.

Right now I'm considering rewriting my service part to be a web based app since it works at request-response principle anyway but what would be the best approach? Would it be possible to consume a WCF HTTPS endpoint with an iOS client effective enough?

答:
The only interoperable endpoint supported by WCF are the http ones (ie SOAP) and of those, I would steer well clear of the wshttpbinding option as it doesn't really interoperate with non-Microsoft SOAP clients. (there are other SO questions about this, just trust me. basicHttpBinding is the one you want).

From that point, you're basically making SOAP 1.1 calls into a webservice. You can configure your WCF service to listen on 2 endpoints, one for internal clients, the other for external ones. Use one of the security options on the endpoint (probably TransportCredentialsOnly option as iOS will not support all the Windows-only security options such as NTLM that you can use). Making web service calls should be trivial with iOS.

(ah, quick google shows that there is now a webHttpBinding option that exposes your service as a REST-based http server. this is a much better choice than bloated and poorly defined SOAP. I'd use this now).


问:
Limitations of the Identity Map pattern
After asking about the implementation in Ruby of the Identity Map pattern because the potential memory leak in long running server apps, I am considering my initial concept of that pattern.

Initially I thought it was intended to cache database results AND guarantee that only one instance of the same object exist in memory. Is this last assumption right?

Within DDD there is the tendency where Entity equality is based on having the same id not the same memory address, that fits perfectly with the memory problem, however after using many ORMs I always had the "feeling" of having a unique instance of my objects. Is this assumption a dangerous idea? Should I normally be concerned about my objects having multiple instances? Or even being out of sync with the database?

答:
Is this last assumption right?

Yes, what else do you think?

Within DDD there is the tendency where Entity equality is based on having the same id not the same memory address.

This has nothing to do with DDD. "Database objects" always need a unique key or Id, there is typically no "memory address" to be stored in the DB to distinguish them. So there is always an id available, which can be also used for checking equality for objects in memory, regardless from using the identity map pattern or not. Having an "Identity Map" in place, and assumed in your context you can make 100% sure that no object can be created without checking the "Identity Map" first, it is indeed possible to replace the id test by a memory address test, but in practice the advantages are IMHO very small.

I always had the "feeling" of having a unique instance of my objects*

Honestly, having a "feeling" about something like this is IMHO a different word for not knowing how something works. And yes, using a framework without knowing what goes on is always "dangerous" (I prefer the term "error-prone"). To be more specfic: when using an ORM, one should inform himself thoroughly if the ORM already provides something like an "Identity Map" or "Object Cache", and what features it provides exactly.

Should I normally be concerned about my objects having multiple instances?

This depends heavily on the kind application you are going to write, on the kind of business transactions, on the number of records involved, on the kind of queries, and so on. It is perfectly possible to write applications which create objects from the database in a local scope, manipulate them and write them back, without caring about other parts of the application which might have a 2nd copy of the same "db object" at the same time. But if you need the same piece of information in your application always in sync, this might not be the way to go.

Or even being out of sync with the database?

Again, this depends. For lots of applications you cannot even avoid things to get out of sync, at least for a short time (think of a scenario where a second client changes the DB over the network, without any "push" mechanic). But how long this is tolerable, and if certain transactions need to be 100% sure to have the newest version data, depends on your requirements.

Title: Limitations of the Identity Map pattern


问:
How come centralized source control solutions don't do branching in place
With centralized source control like Perforce and SVN, when they create a branch, they create a whole new directory. However, git and other distributed source control solutions, in my experience, are able to update the branch in place as it were. That is, they apply the differences between the two branches to the files.

This seems to me to be the far superior option as it saves huge amount of duplication for large projects, quicker to switch branches etc...

What is the reason for this? I can't see any reason why there being a centralized authority affects the clients ability to diff the two branches and modify the changes.

答:
When centralized systems create a branch, they do various things. Perforce and Subversion are unique in using directories for branches, the later copying the idea from the former. CVS has branches as separate concept from directories and so do most other centralized version control systems.

The use of directories for branches in Subversion is a neat-looking reduction to more elementary concept that unfortunately has it's downsides, because merging only makes sense for branches, but has to be implemented for arbitrary directories in this model and is generally complicated a lot by this.

Using subdirectories for branches is unsuitable for distributed systems, because branches are the basis for distribution and therefore need to be a separate first class concept.

The real difference between branching in centralized and distributed systems is that in centralized systems to create a branch you have to ask the central server, which means naming the branch in a way to avoid conflicts and round-trips to server and such while in distributed system each checkout is a branch by design, so you always already have it when you need it.

And note that even in centralized system the checkout containing local changes is kind of a branch too (with exception of ClearCase dynamic views). Just it is a branch with very limited functionality that can only contain the uncommitted changes.

Some additional notes:

Subversion can switch a branch in a particular checkout.

Subversion creates new directory for a branch, but it does not duplicate the content of the files, so there is really not much difference in storage efficiency.

A distributed system (where revision identity is maintained when moving between repositories) can't use directories for branches, but there is a decentralized system, SVK, that is built on top of subversion and does use directories for branches and works by mirroring subversion repositories.


答:
It's a symptom of a limitation in Java/C#'s module systems.

In principle, there's no reason you shouldn't be able to swap out one implementation of a class for another with the same constructor and method signatures. There are languages that allow this. However, Java and C# insist that every class have a unique identifier (the fully qualified name) and the client code ends up with a hard-coded dependency on it.

You can sort of get around this by fiddling with the file system and compiler options so that com.example.Foo maps to a different file, but this is surprising and unintuitive. Even if you do so, your code is still tied to only one implementation of the class. I.e. If you write a class Foo that depends on a class MySet, you can choose an implementation of MySet at compile time but you still can't instantiate Foos using two different implementations of MySet.

This unfortunate design decision forces people to use interfaces unnecessarily to future-proof their code against the possibility that they'll later need a different implementation of something, or to facilitate unit testing. This isn't always feasible; if you have any methods that look at the private fields of two instances of the class, won't be able to implement them in an interface. That's why, for example, you don't see union in Java's Set interface. Still, outside of numeric types and collections, binary methods aren't common, so you can usually get away with it.

Of course, if you call new Foo(...) you still have a dependency on the class, so you need a factory if you want a class to be able to instantiate an interface directly. However, it's usually a better idea to accept the instance in the constructor and let someone else decide which implementation to use.

It's up to you to decide if it's worth bloating your codebase with interfaces and factories. On the one hand, if the class in question is internal to your codebase, refactoring the code so that it uses a different class or an interface in the future is trivial; you could invoke YAGNI and refactor later if the situation arises. But if the class is part of the public API of a library you've published, you don't have the option of fixing the client code. If you don't use an interface and later need multiple implementations, you'll be stuck between a rock and a hard place.


答:
In my opinion, they're just using the Simple Factory, which is not a proper design pattern and should not be confused with the Abstract Factory or the Factory Method.

And since they have created a "huge fabric class with thousands of CreateXXX static methods", that sounds to an anti-pattern (a God class maybe?).

I think the Simple Factory and static creator methods (which doesn't require an external class), can be useful in some cases. For example, when the construction of an object requires various steps like instancing other objects (e.g. favoring composition).

I wouldn't call even call that a Factory, but just a bunch of methods encapsulated in some random class with the suffix "Factory".


问:
Is a new change request on a user story a different user story
We have completed a user story for a sprint. Near the end of the sprint there was a new functional addition requested for the same user story.

Here the user story will remain the same. ie
As a <user> i want to <> so that <> will remain the same. Only difference is that there is a new value add that is to be done.

So should this be taken as a new user story for the next sprint or should this be taken as a backlog?

We have met the done definition we had for the user story and this new feature is a new requirement which wont have any change in the user story definition.

I am adding an example to make it more clear.

Take a feature say create profile, in that user can update his name,address, phone no, photo etc and its done. now if the customer wants to have facebook link or add country code to phone number, is that change request a new user story?

答:
Once a story has been committed to in a sprint, that story should not be allowed to change any more.

Now, if the user comes up with a new idea halfway through the sprint that would affect one of the stories in that sprint, there are a few ways to handle that:

Abort the sprint and start planning a new sprint. This has a huge impact and will usually be an option of last resort. It is mainly useful if the new ideas of the client completely invalidate the work currently being done.

Remove the affected stories from the sprint. If a few stories are invalidated by these new ideas and are considered to have zero (or even negative) value, then you can decide, in collaboration with the client, to remove those stories from the current sprint. The resulting gap in work could be filled with work from the product backlog.

Add the new ideas as stories. This should be the most common option. If the original stories still have value, complete them as scheduled and add the new ideas as additional stories to the product backlog.

If the changes are very minor (would result in a story of <1 story point) and the story isn't done yet, you could decide to take the changes along with the original story implementation. This choice should be rare.

In your example of the 'create profile' story, the additional story could be that the user wants to store a Facebook link along with the other information in the profile.

The question if the change is a Change Request (which is typically billed separately) or falls under the normal work depends on your contract with the client and is a matter for the account manager.


答:
I'm no Scrum expert (by any means) but I'm going to [naively] say that this should be a new User Story.

You've already met your acceptance criteria on this Story.

Taking on this change might jeopardise that achievement.  (There's probably a trendy, new name for this but we used to call it "Scope Creep" and it was never a Good thing).

Adding a new data field probably means changing the underlying data store.

That may or may not be a "quick" job, again putting your points at risk.

Make it a new Story and put it on the Backlog, just like everything else.

Sure, it seems like a Good Idea (and really important) when it comes up but, when faced with the reality of everything else that needs doing, it may well become [relatively] less important.

You say that this is:

"a new requirement which wont have any change in the user story definition"

Well, if it's a Change but it's not changing the definition of this Story, then how can it be done as part of this Story?  Surely it has to be [part of] a Story whose definition it does change?

Title: Is a new change request on a user story a different user story

Body:
We have completed a user story for a sprint. Near the end of the sprint there was a new functional addition requested for the same user story.

Here the user story will remain the same. ie
As a <user> i want to <> so that <> will remain the same. Only difference is that there is a new value add that is to be done.

So should this be taken as a new user story for the next sprint or should this be taken as a backlog?

We have met the done definition we had for the user story and this new feature is a new requirement which wont have any change in the user story definition.

I am adding an example to make it more clear.

Take a feature say create profile, in that user can update his name,address, phone no, photo etc and its done. now if the customer wants to have facebook link or add country code to phone number, is that change request a new user story?


答:
Just make a new story for your new requirement.

The question in your title may not have a generic answer, but let's consider your example:

```<code>As a user I want to maintain a user profile
</code>```

Suppose you had a definition of done for this story, including the ability to edit and save the home address, telephone number, and a few other things. The Product Owner agreed, the story was estimated and pulled into sprint. Later it was marked as done and the story points were earned.

If you change this story, this will induce a scope change of the original story. It also shows a drop in your burndown, even while you delivered high-quality work as was agreed upon before taking it up. See this related question. Make a new story, accept that it's tiny, and pull it in when you need to fill up your sprint with something small.

Learn from this, and adjust your definition of done each iteration so that it includes a once-over before the end, to prevent trivial additions before it's too late.

Body:
Just make a new story for your new requirement.

The question in your title may not have a generic answer, but let's consider your example:

As a user I want to maintain a user profile

Suppose you had a definition of done for this story, including the ability to edit and save the home address, telephone number, and a few other things. The Product Owner agreed, the story was estimated and pulled into sprint. Later it was marked as done and the story points were earned.

If you change this story, this will induce a scope change of the original story. It also shows a drop in your burndown, even while you delivered high-quality work as was agreed upon before taking it up. See this related question. Make a new story, accept that it's tiny, and pull it in when you need to fill up your sprint with something small.

Learn from this, and adjust your definition of done each iteration so that it includes a once-over before the end, to prevent trivial additions before it's too late.


答: You would probably be better off just tweaking your WCF service into a web API service. The iOS speaks HTTP very effectively and doing HTTP is a pain in WCF.</p>

Title: Reliable secure data exchange between service written on .NET and an iOS client app

Body:
I have a service written on .NET working on a company server. It designed to do a very simple thing, to receive a request via WCF named pipes from another service working locally on the same server, process it and send a response through named pipes back. Request an response are just a fairly small, XML formatted text.

And now I need to couple it somehow with our in-house iOS application to do the same thing but with a remote connection through internet. I'm not all too experienced with an Objective-C iOS development and not sure how to proceed. I was considering adding a TCP endpoint to the same WCF service but then I'm not sure how reliable will it be plus I'll have to use some sort of encryption "manually" on both ends of the connection.

I can extend or change code of both .NET server and Objective-C iOS client as much as I need but I'm not sure how to ensure reliability and most of all security of data transfer between server and client.

Right now I'm considering rewriting my service part to be a web based app since it works at request-response principle anyway but what would be the best approach? Would it be possible to consume a WCF HTTPS endpoint with an iOS client effective enough?


答:
I've used the Fibonacci sequence at several places and it has worked well.  The points are a rough estimatation and represent scale as much as a certain level.  I've found that choosing 5 or 8 for what is an estimate is better than trying to get the desired discussion and ultimately agreement on points when the votes are 5-5-8-5-5-5-8-5 rather than 5-5-9-6-5-6-9-5

To address your concerns about "lose estimating fidelity" I would recommend not worrying about it.  Estimating for the future is best used when there has been a bvuild up of several months of activity.  A couple of sprints is not enough.

I recommend that your primary use of points be to:

Generate discussion of key points of the ticket when people disagree in their point scores.

Title: Point estimates scale skewed

Body:
When using planning poker for estimates, we've ended up with effectively a non-linear points scale. By that I mean that point value is inconsistent for one-pointers and, say, eight-pointers. Couple examples each:

1 point: add tooltip text to a couple of icons; format date&time strings

3 points: create new user role and specify their permissions; automatically create a new case in CRM whenever certain actions are performed

5 points: watchlist functionality; filtering functionality on several facets

8 points: integrate with a third party provider *and* introduce a persistence layer to cache their responses

My concern is two-fold: we lose estimating fidelity by restricting ourselves to the low-end of the scale and any reporting (or calculating average velocity) will be erroneous.

How can I entice the scrum master, product owner and the team to use a more consistent, linear scale?

Edit: just to clarify, we are using one of the traditional decks that goes all the way up to 100... except we've somehow anchored ourselves to not go over 5, ending up with effectively a logarithmic scale.


答:
The biggest problem with using a non-linear story point scale is that it completely screws up Velocity calculations.

In other words, it makes it hard to know how many story points (how much complexity) you can ship in a fixed-length sprint.

Consider two sprints with different story point distributions, but the same total number of story points

```<code>Sprint 1 breakdown (16 points):
16 x 1 story point

Sprint 2 breakdown (16 points):
8 x 2 story points
</code>```

With a linear estimation scale and a steady velocity (eg, 1 story point maps to 1 hour of work) both sprints a comparable amounts of work.  Both sprints will take roughly 16 hours and the story point estimates clearly indicate this.

However, if you use an exponential scale you get totally misleading results.

Let's assume your conversion scale is something like

```<code>n story points = n^2 hours
</code>```

So sprint 1 turns out to be

```<code>16 x 1 story point =
16 x (1^2) hours =
16 * 1 hours
16 hours
</code>```

Sprint 1, consisting of 16 story points, is 16 hours long.

Now let's consider sprint 2.

```<code>8 * 2 story points =
8 * (2^2) hours =
8 * 4 hours =
32 hours
</code>```

So, sprint 2, consisting of 16 story points, is actually 32 hours long.

This is twice as long as your first sprint because you're attempting to deliver twice the complexity.

Thus, the impact of using an exponential scale is that the number of story points in a fixed-length sprint doesn't actually represent the amount of complexity being delivered.

This will make calculating Velocity and using Burdown Charts very difficult.

That should be reason enough to your Scrum Master.

Clarification

The only reason I'm relating story points to time is because sprints have a fixed length in time.

Assuming your team has a fairly stable real velocity, estimating with a non-linear scale will make it so that two sprints of the same length in time with the same story point content being worked on at the same velocity are not actually comparable.

In other words, two sprints with the same total number of story points aren't actually shipping the same amount of complexity.

Title: Point estimates scale skewed

Body:
The biggest problem with using a non-linear story point scale is that it completely screws up Velocity calculations.

In other words, it makes it hard to know how many story points (how much complexity) you can ship in a fixed-length sprint.

Consider two sprints with different story point distributions, but the same total number of story points

Sprint 1 breakdown (16 points):
16 x 1 story point

Sprint 2 breakdown (16 points):
8 x 2 story points

With a linear estimation scale and a steady velocity (eg, 1 story point maps to 1 hour of work) both sprints a comparable amounts of work.  Both sprints will take roughly 16 hours and the story point estimates clearly indicate this.

However, if you use an exponential scale you get totally misleading results.

Let's assume your conversion scale is something like

n story points = n^2 hours

So sprint 1 turns out to be

16 x 1 story point =
16 x (1^2) hours =
16 * 1 hours
16 hours

Sprint 1, consisting of 16 story points, is 16 hours long.

Now let's consider sprint 2.

8 * 2 story points =
8 * (2^2) hours =
8 * 4 hours =
32 hours

So, sprint 2, consisting of 16 story points, is actually 32 hours long.

This is twice as long as your first sprint because you're attempting to deliver twice the complexity.

Thus, the impact of using an exponential scale is that the number of story points in a fixed-length sprint doesn't actually represent the amount of complexity being delivered.

This will make calculating Velocity and using Burdown Charts very difficult.

That should be reason enough to your Scrum Master.

Clarification

The only reason I'm relating story points to time is because sprints have a fixed length in time.

Assuming your team has a fairly stable real velocity, estimating with a non-linear scale will make it so that two sprints of the same length in time with the same story point content being worked on at the same velocity are not actually comparable.

In other words, two sprints with the same total number of story points aren't actually shipping the same amount of complexity.


问:
How often do you refactor or restructure your code in long term projects?
As developers we are always eager to learn new things and better ourselves at what we do.

You've all had moments when you look at your old code and get that feeling:

"WTH, I can't believe I used to write code like this"

Well, when it comes to long term projects that you're working on, what do you do when you look at your old code? You probably have learnt new techniques that you didn't use when you started the project. So you probably are very eager to refactor or restructure, or swap out modules in your project.

But when is the right time to do this, and how often do you do this?
Also, there are risks involved if you do some major refactoring. There's also budget constraints so you may have the urge to make changes but your project manager won't give you the time to do so.
How do people approach such situations?

答:
But when is the right time to do this, and how often do you do this?

The right time is when the old and bad code is actually causing problems, or is becoming so difficult to maintain that the cost of not refactoring is greater than the cost of refactoring, which thankfully does not happen often (at least not in my experience).

Generally, if it ain't broke, don't fix it. Changing working code simply for the sake of making it "nicer" is risky.

Also, there are risks involved if you do some major refactoring?

Yes. If you change your code siginificantly, you must ensure that it works the same as before. Automated unit tests can help with this.


答:
what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs, with no new requirements and adequate performance - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

How much time should I dedicate to refactoring my code?

http://c2.com/cgi/wiki?WhenToStopRefactoring

https://stackoverflow.com/questions/455271/how-do-you-stop-yourself-from-refactoring-working-but-awful-code

Title: How often do you refactor or restructure your code in long term projects?

Body:
As developers we are always eager to learn new things and better ourselves at what we do.

You've all had moments when you look at your old code and get that feeling:

"WTH, I can't believe I used to write code like this"

Well, when it comes to long term projects that you're working on, what do you do when you look at your old code? You probably have learnt new techniques that you didn't use when you started the project. So you probably are very eager to refactor or restructure, or swap out modules in your project.

But when is the right time to do this, and how often do you do this?
Also, there are risks involved if you do some major refactoring. There's also budget constraints so you may have the urge to make changes but your project manager won't give you the time to do so.
How do people approach such situations?

ContentLicense: CC BY-SA 4.0


问:
Why is build.number an "abuse" of semantic versioning?
I was explaining a proposed build system (Gradle/Artifactory/Jenkins/Chef) to one of our senior architects, and he made a comment to me that I sort of disagree with, but am not experienced enough to really weigh-in on.

This project builds a Java library (JAR) as an artifact to be reused by other teams. For versioning, I'd like to use the semantic approach of:

```<code><major>.<minor>.<patch>
</code>```

Where patch indicates bug/emergency fixes, minor indicates backwards-compatible releases, and major indicates either massive refactorings of the API and/or backwards-incompatible changes.

As far as delivery goes here is what I want: a developer commits some code; this triggers a build to a QA/TEST environment. Some tests are ran (some automated, some manual). If all tests pass, then a production build publishes the JAR to our in-house repo. By this point the JAR should be versioned properly, and my thinking was to use the build.number that is automatically generated and provided by our CI tool to act as the patch number.

Thus, the versioning would actually be:

```<code><major>.<minor>.<build.number>
</code>```

Again, where build.number is provided by the CI tool.

The architect dismissed this, saying that using the CI build number was an "abuse" of semantic versioning.

My question is: is this correct, and if so, why? And if not, why not?

答:
Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

So, version numbers (major, minor, patch) must be provided manually, as these are used to tell your users about changes in one place without them having to look at your changelog or some other document.

If you want to include your build number, then you may append them after a + (section 10):

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.


答:
One reason is that the patch may require several builds, so if you have version 5.7, and you want to patch it to 5.7.1, but your first 2 bugfixes fail to build when they are submitted to the CI system, then you will be at 5.7.3 before you've released your first patch!

The answer is to simply use 4 digits (as Microsoft systems tend to have). The 4th is a build number and is used "for information only". Generally people put the repository version number in there (if they use SVN or TFS or similar) which is really nice as you can verify which exact commit was used to build the binaries. If you don't have such a thing, then the CI build number is a reasonable approximation (as you'd hope your CI system can remember the build numbers and tie it to the repo history, but you're not reliant on the CI system remembering them - you can never delete old builds).

One thing to note, The Microsoft schema for versioning uses the 3rd position for build numbers. Chrome uses just 1 number. Ubuntu uses the date. There is no "standard" to use, except that all numbers must increment.

Title: Why is build.number an "abuse" of semantic versioning?

Body:
I was explaining a proposed build system (Gradle/Artifactory/Jenkins/Chef) to one of our senior architects, and he made a comment to me that I sort of disagree with, but am not experienced enough to really weigh-in on.

This project builds a Java library (JAR) as an artifact to be reused by other teams. For versioning, I'd like to use the semantic approach of:

```<code><major>.<minor>.<patch>
</code>```

Where patch indicates bug/emergency fixes, minor indicates backwards-compatible releases, and major indicates either massive refactorings of the API and/or backwards-incompatible changes.

As far as delivery goes here is what I want: a developer commits some code; this triggers a build to a QA/TEST environment. Some tests are ran (some automated, some manual). If all tests pass, then a production build publishes the JAR to our in-house repo. By this point the JAR should be versioned properly, and my thinking was to use the build.number that is automatically generated and provided by our CI tool to act as the patch number.

Thus, the versioning would actually be:

```<code><major>.<minor>.<build.number>
</code>```

Again, where build.number is provided by the CI tool.

The architect dismissed this, saying that using the CI build number was an "abuse" of semantic versioning.

My question is: is this correct, and if so, why? And if not, why not?


问:
Erlang return value conventions
Should functions that return tuples, always return tuples?

For example, I have a function is_user_name_allowed that returns a tuple in this he form if the username is not allowed:

{false, ["Reason 1","Reason 2"]}

If the I want to return true, is there any convention/benefit to returning a tuple as opposed to simply returning true? ({true} vs true)

答: The convention is to just use true in this case. The same style is used in many OTP libraries, e.g. lists:keyfind/3.

Title: Erlang return value conventions


问:
Does it make sense to license source code snippets by CC-BY(-SA)
If I want to put random source code snippets in a publicly accessible git repository, does it make sense to license by CC-BY(-SA) given that CC-BY licenses are generally not recommended for software? To me there is a difference between a full software project where CC-BY clearly isn't appropriate and small random source code files. CC-BY seems like a simple license where GPL is over the top.

The main reason that I ask is that I may take code from StackOverflow (modified or not) which I believe is licensed as CC-BY-SA. Sometimes it would be convenient for me to put it all in one place so I can easily access and find it in the future. While I may be being overly-paranoid, I would like to adhere to the StackExchange CC-BY-SA license. Licensing everything I put there as CC-BY-SA is simple and seems appropriate for snippets (of course code taken from other sources, say with GPL/BSD or whatever will retain their original license if required).

Finally can I combine CC-BY-SA with GPL?

答:
Lets take the last aspect of the question first:

Can I combine CC-BY-SA with GPL?

The simple answer there is no.

At GNU.org they have a list of licenses and their compatibility with the GPL at Various Licenses and Comments about Them #CCBYSA

This has a yellow dotted line to the side of it indicating that it is not GPL compatible.

This is a copyleft free license that is good for artistic and entertainment works, and educational works. Please don't use it for software or documentation, since it is incompatible with the GNU GPL and with the GNU FDL.

Creative commons is aware of this and there is some discussion and thoughts about this at GPL compatibility use cases on their wiki.  They may attempt to make it compatible with the next version of CC-BY-SA (that would be 4.0).

The question is what is your goal for sharing those snippets?  Do you want people to use them? or do you want to impose a given license.  CC-BY-SA is one extreme (that notes the issue of software) and GPL is a copyleft that imposes its license on everything else in the project.

There are many licenses that are middle grounds in this that are very permissive and are GPL compatible.  Going to the Software Licenses section of the various licenses and comments document, one just needs to scroll down a bit past the GPL/GNU ones and you find:

Apache License

Artistic License

Modified BSD

Mozilla Public License

X11 (MIT) license

and many more.  The ones I listed are particularly well known in the community and are the ones that are least likely to cause problems with people trying to read them to make sure they are compatible with other licenses.

The licensing and copyright for code posted on Stack Exchange was brought up some time ago on Meta.StackOverflow (its now on Meta.StackExchange) with the FAQ question: Do I have to worry about copyright issues for code posted on Stack Overflow? and note that much of this delves into the real of legal where you start needing a lawyer.

This does point out the inherit issues of mixing CC-BY-SA which is intended for wiki type answers (such as what I'm writing) and source code.


答:
You may save some time and memory by not having to construct and evaluate a tuple if you just return a bare-naked atom.  Write a benchmark, run several million of each way through it and you'll know for sure.

That aside, it doesn't really matter:

```<code>handle_result(true) -> do_true_things();
handle_result({false, Reasons}) -> do_false_things(Reasons).

some_function() -> handle_result(is_user_name_allowed("bob")).
</code>```

The first version of the function would work just the same if it was specified as handle_result({true}) and is_user_name_allowed() returned a tuple.

More important is the safety aspect.  Make sure you use the matcher to handle the result, which will give you an implicit check that it was valid without having to do it after each call.  If something goes wrong, a function_clause error will bring it to your attention.

What I would not do is return a tuple that's always structured the same way:

```<code>{true, []}
{false, ["Ugly", "Mother dresses him funny"]}
</code>```

While you could match them, it leaves open the possibility that a caller will do...

```<code>{Result, Reasons} = is_user_name_allowed("bob")
</code>```

...and not validate the result.

Title: Erlang return value conventions

Body:
Should functions that return tuples, always return tuples?

For example, I have a function is_user_name_allowed that returns a tuple in this he form if the username is not allowed:

{false, ["Reason 1","Reason 2"]}

If the I want to return true, is there any convention/benefit to returning a tuple as opposed to simply returning true? ({true} vs true)

Body:
You may save some time and memory by not having to construct and evaluate a tuple if you just return a bare-naked atom.  Write a benchmark, run several million of each way through it and you'll know for sure.

That aside, it doesn't really matter:

handle_result(true) -> do_true_things();
handle_result({false, Reasons}) -> do_false_things(Reasons).

some_function() -> handle_result(is_user_name_allowed("bob")).

The first version of the function would work just the same if it was specified as handle_result({true}) and is_user_name_allowed() returned a tuple.

More important is the safety aspect.  Make sure you use the matcher to handle the result, which will give you an implicit check that it was valid without having to do it after each call.  If something goes wrong, a function_clause error will bring it to your attention.

What I would not do is return a tuple that's always structured the same way:

{true, []}
{false, ["Ugly", "Mother dresses him funny"]}

While you could match them, it leaves open the possibility that a caller will do...

{Result, Reasons} = is_user_name_allowed("bob")

...and not validate the result.


答:
So let's start with the simple approach to calculate the bare minimum and find additional means to reduce the size required.

A 5x5 magic square contains the values from 1 - 25.  Said another way, we have 25 potential numbers to store.

There are 25 cells within the grid, and 5 rows.

1st approach

The simplest approach is to use 1 Byte per cell.

So that's 25 Bytes per grid.

25 Bytes for 275,305,224 combinations is 6,882,630,600 Bytes or 6.4 GB.

2nd approach

But we only need 5 bits to represent those 25 potential numbers.
5 bits per cell times 25 cells gives us 15 Bytes, 5 bits per grid.

15.625 Bytes per grid times 275,305,224 combinations is 4,301,644,125 Bytes or 4 GB.

3rd approach

As pointed out in your question, we only need to keep 14 of the 25 cells since we can reliably calculate the missing cells to recreate the grid.

So we can modify the 2nd approach to reduce our required storage further.

5 bits per cell times 14 cells gives us 8 Bytes, 6 bits per grid.

8.75 Bytes per grid times 275,305,224 combinations is 2,408,920,710 Bytes or 2.2 GB

4th approach

According to this site dedicated to magic squares, there are 1,394 ways to add up to 65 using the numbers 1 - 25.  So that's 1,394 reductions.

We need 11 bits to represent those 1,394 reductions.

And now we only need to keep 5 reductions instead of 25 cells.

11 bits times 5 reductions gives us 6 Bytes, 7 bits per grid.

6.875 Bytes per grid times 275,305,224 combinations is 1,892,723,415 Bytes or 1.7 GB

5th approach

We can combine the minimum required cell technique with reduction approach to reduce the required space even further.

In this approach, we only need to keep 4 of the 5 reductions since we can calculate the remaining row of values.

11 bits times 4 reductions gives us 5 Bytes, 4 bits per grid.

5.5 Bytes per grid times 275,305,224 combinations is 1,514,178,732 or 1.4 GB.

6th approach

Based on Pieter B's observation about magic squares, we can reduce the number of potential combinations we need to store.

You can rotate a magic square 90 degrees and it will still be good and you can mirror one and it will still be good, so 1 square can actually stand as a solution for 8 squares.

Which brings us from 275,305,224 combinations down to 34,413,153 combinations.

And using our 5th approach, we now have:

11 bits times 4 reductions gives us 5 Bytes, 4 bits per grid.

5.5 Bytes per grid times 34,413,153 combinations gives us 189,272,341.5 Bytes or 180.5 MB.

Final notes:

A good compression algorithm ought to be able to find additional patterns within the listed reductions and reduce the amount of required space even further.  I haven't played with calculating permutations lately, so I'm not going to wager a guess as to how much further compression you would see from a good compression algorithm.

Title: Estimation of space is required to store 275305224 of 5x5 MagicSquares?

Body:
Here are some examples of 5x5 Magic Squares found by some good solvers :

Magic Square Generator by Marcel Roos

this program state using 2.4GHz Intel  takes about 95 hours to generate all solutions.

open source tool

```<code>Magic squares 5x5
Sum must be: 65

Solution:             1
  1  2 13 24 25
  3 23 17  6 16
 20 21 11  8  5
 22  4 14 18  7
 19 15 10  9 12

Solution:             2
  1  2 13 24 25
  3 23 16  8 15
 21 19 10  6  9
 22  4 14 20  5
 18 17 12  7 11

Solution:             3
  1  2 13 24 25
  3 23 19  4 16
 21 15 10 12  7
 22  8  9 20  6
 18 17 14  5 11

 ...
</code>```

The number of all possible solutions is 275305224. Since calculation of all solutions takes a very long time, I would like have one person with a high speed computer find all solutions (in a long continues span of time) and then share them on the web for other people.

What would be an efficient way to store these solutions, using some sort of compression?

(simple logical trick)by attention to the principle that the sum in all rows and columns and diagonal are equal to 65

we only need to know the value for only 14 cells of 25 cells as shown below , this cause the storage space almost reduce to half 14/25

legend:+ means stored value and x means skipped value !

```<code>+ + + + x
+ + + + x
+ + + + x
x + x + x
x x x x x
</code>```


问:
Why should I use a factory class instead of direct object construction?
I have seen the history of several С# and Java class library projects on GitHub and CodePlex, and I see a trend of switching to factory classes as opposed to direct object instantiation.

Why should I use factory classes extensively? I have pretty good library, where objects are created the old-fashioned way - by invoking public constructors of classes. In the last commits the authors quickly changed all of the public constructors of thousands of classes to internal, and also created one huge factory class with thousands of CreateXXX static methods that just return new objects by calling the internal constructors of the classes. The external project API is broken, well done.

Why would such a change be useful? What is the point of refactoring in this way? What are the benefits of replacing calls to public class constructors with static factory method calls?

When should I use public constructors, and when should I use factories?

答:
The Factory pattern vogue stems from an almost-dogmatic belief among coders in "C-style" languages (C/C++, C#, Java) that use of the "new" keyword is bad, and should be avoided at all costs (or at least centralized). This, in turn, comes from an ultra-strict interpretation of the Single Responsibility Principle (the "S" of SOLID), and also of the Dependency Inversion Principle (the "D"). Simply stated, the SRP says that ideally a code object should have one "reason to change", and one only; that "reason to change" is the central purpose of that object, its "responsibility" in the codebase, and anything else that requires a change to code should not require opening up that class file. The DIP is even simpler; a code object should never be dependent upon another concrete object, but instead on an abstraction.

Case in point, by using "new" and a public constructor, you are coupling the calling code to a specific construction method of a specific concrete class. Your code now has to know that a class MyFooObject exists, and has a constructor that takes a string and an int. If that constructor ever needs more information, all usages of the constructor have to be updated to pass in that information including the one you're writing now, and therefore they are required to have something valid to pass in, and so they must either have it or be changed to get it (adding more responsibilities to the consuming objects). In addition, if MyFooObject is ever replaced in the codebase by BetterFooObject, all usages of the old class have to change to construct the new object instead of the old one.

So, instead, all consumers of MyFooObject should be directly dependent on "IFooObject", which defines the behavior of implementing classes including MyFooObject. Now, consumers of IFooObjects can't just construct an IFooObject (without having the knowledge that a particular concrete class is an IFooObject, which they don't need), so instead they must be given an instance of an IFooObject-implementing class or method from outside, by another object that has the responsibility of knowing how to create the correct IFooObject for the circumstance, which in our parlance is usually known as a Factory.

Now, here's where theory meets reality; an object can never be closed to all types of change all the time. Case in point, IFooObject is now an additional code object in the codebase, which must change whenever the interface required by consumers or implementations of IFooObjects change. That introduces a new level of complexity involved in changing the way objects interact with each other across this abstraction. In addition, consumers will still have to change, and more deeply, if the interface itself is replaced by a new one.

A good coder knows how to balance YAGNI ("You Ain't Gonna Need It") with SOLID, by analyzing the design and finding places that are very likely to have to change in a particular way, and refactoring them to be more tolerant of that type of change, because in that case "you are gonna need it".


答:
Your understanding is correct.

Identity maps are meant to help object-oriented programmers deal with state management issues.  They write imperative programs which, if care is not taken, might end up having different areas of the program dealing with an outdated copy of a persistable object.

Consider basic concurrency issues.  Alice pulls up a particular record on her screen.  Bob does the same a moment later.  Alice updates her copy and saves, then Bob does.  Alice's changes are lost if the program doesn't consider this scenario.

Now take into account the same thing but within the confines of a single program.  Some nebulous Area A of the program loads an object into memory while some other nebulous Area B does the same.  Area A updates its copy, then Area B.  It is always the design of the program that permits internal concurrency issues.

In the imperative world state change runs rampant.  The identity map is pattern for alleviating in-memory concurrency issues.  In programs designed to avoid concurrency issues identity maps are unnecessary.  The problem is that the path of imperative code can be unpredictable and one has to wonder if there might ever be a concurrency issue and guard against it -- just in case.

This would all be less of an issue in functional programming because there is an emphasis on having immutable data.  Everything is represented in data structures.  Each piece of data is represented just once (SPOT) as part of some larger data abstraction that represents the entirety of all the data in its world.  Identity maps are completely unnecessary.  Or, in one respect, you could say that the entire foundation of functional programming is built on using identity maps -- a single big ball of world state.

Title: Limitations of the Identity Map pattern

Body:
After asking about the implementation in Ruby of the Identity Map pattern because the potential memory leak in long running server apps, I am considering my initial concept of that pattern.

Initially I thought it was intended to cache database results AND guarantee that only one instance of the same object exist in memory. Is this last assumption right?

Within DDD there is the tendency where Entity equality is based on having the same id not the same memory address, that fits perfectly with the memory problem, however after using many ORMs I always had the "feeling" of having a unique instance of my objects. Is this assumption a dangerous idea? Should I normally be concerned about my objects having multiple instances? Or even being out of sync with the database?


答:
How can I entice the scrum master, product owner and the team to use a
  more consistent, linear scale?

You shouldn't need to convince them. Reviewing inaccurate point estimates should be part of your retrospective. If any stories ended up being more complicated than anticipated, make note of it.

We only estimated 8 points on STR-1234; but it was
  definitely more than 8 time as complex as a typical 1 point story. I'd say it was more like
  13 times as complex. Possibly even in the 21 point range.

At that point, you'll ideally have a conversation about whether the estimate could have been better with more time to discuss the story, whether it was high enough that it should have been given a huge estimate until being broken down into smaller stories, or whether the bad estimate was unavoidable -- and maybe whether it should have been replaced with (or converted to) a spike during the sprint.

If you can, transition into that conversation without "convincing" anyone that points are informative and useful when done right; you just need to keep up the practice of discussing bad estimates at each review.

If you're SCRUM implementation is broken, you may get pushback.

But, it took the same amount of time as your other 8 pointers!

Or whatever.

At that point, if it occurs, you need to start a discussion about Why you're attempting to use a SCRUM process and Why successful SCRUM implementations work. That discussion can take months. But, it starts by asking your coworkers and boss what they expect out of the process.

At the very least, to address the question at hand, ask the product owner and team what they expect out of story point estimates. Ask them things like:

Should they ensure that each sprint can be treated like a commitment?

Should they ensure we don't spend too much time on minimally valuable improvements?

Should they help the product owner determine if X can be done N sprints from now?

The correct answer to all of the above is yes, of course. And to achieve any of the benefits, you need a meaningful velocity data.  If 8 != 1 * 8 in your reports, the data is meaningless.

Title: Point estimates scale skewed