nginx

http://stackoverflow.com/questions/17440415/golang-production-web-application-configuration
http://security.stackexchange.com/questions/30403/should-ssl-be-terminated-at-a-load-balancer

misc

http://openmymind.net/Golang-Hot-Configuration-Reload/
https://bitbucket.org/tebeka/seamless

uwsgi

the subscription system can be used for network-wide automatic scaling:
http://uwsgi-docs.readthedocs.org/en/latest/SubscriptionServer.html
https://groups.google.com/forum/#!topic/golang-nuts/41TPj4PWBI8

multi-process

I would suggest you investigate using a multi-process model where a group of public-facing HTTP servers proxy requests to a group of backends. The front ends could make regular "health check" requests to the back ends (a request that basically says "Are your running and accepting requests?"), and then only send user requests to healthy back ends.

The key advantage of this approach is scalability. When you need to move to a multi-machine or multi-service model, the work is already done for you.

It's relatively easy to write an HTTP "reverse proxy" like this in Go. This talk discusses a similar problem: http://talks.golang.org/2012/simple.slide

It's important to keep in mind that backend servers will die spontaneously, no matter how careful you are. You should design your systems with this in mind.

At Google, we do something like I described in my original mail. Upgrades of backend services are managed by gracefully shutting down the old backends (finishing off any inflight requests) while bringing up the new ones. The front ends are responsible for sending requests only to healthy back ends. This works very well. (It's hard to argue with Google's availability record!)

https://groups.google.com/forum/#!topic/golang-nuts/41TPj4PWBI8

https://groups.google.com/forum/#!topic/golang-nuts/41TPj4PWBI8
https://github.com/rcrowley/goagain
https://github.com/ParsePlatform/go.grace
https://github.com/ngmoco/falcore

uwsgi

The uWSGI project now supports Go as a first class citizen.

Things like binary patching, hot-swapping of instances and tons of other
production tricks are available for free:

http://uwsgi-docs.readthedocs.org/en/latest/Go.html

the Zerg mode is what you can use to implement instance swapping (or
reinforcement) on the same machine:

http://uwsgi-docs.readthedocs.org/en/latest/Zerg.html

https://developers.google.com/gmail/actions/overview

http://goreportcard.com/report/rofrol/goshop

http://blog.codinghorror.com/the-god-login/

Free database or service with limited number of requests http://freegeoip.net/

https://www.gosquared.com/

I am just curious if it's a good idea to open/close db on every request.

For example you have:

db, err := sql.Open("sqlite3", "file:./db/app.db?foreign_keys=true")

and

defer db.Close()

Wouldn't it better just open one connection in file? (for example db.go in package db)

package models

import (
    "conf"
    "database/sql"
)

var DB, _ = sql.Open("postgres", conf.DATABASE_URI)

I think it's faster implement it this way, let me now what do you think.

Thanks.

PS: I am trying to implement app in Go, therefore I am looking for the best design possible.

https://github.com/apexskier/httpauth

Or not?

Unit testy zapobiegają regresji, a nie wykrywają cokolwiek. http://niebezpiecznik.pl/post/5-latek-zhackowal-xboksa-spacja/#comment-298999

https://github.com/drewolson/testflight
http://programmers.stackexchange.com/questions/41409/why-does-tdd-work
http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-testing/

agile approaches are about software development, not about algorithm design. To be more precise: they are mainly about achieving software quality, not correctness. It’s the purpose of tests to help the developer maintain functional correctness – not to guide her towards a correct solution of an algorithmically non-trivial problem, such as Sudoku solving. http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

In general, unit tests should not be testing specific / internal implementation details of the class. Rather, the tests should verify the documented public behavior of the class.

By reading the unit tests and code comments, and comparing them against bits of the actual codebase, you can gain a better understanding of what the previous programmer was thinking and what he was trying to accomplish.

Start writing tests to verify bug reports and then fix the bug

With unit tests, there are certain things that must be tested, such as very high-value code contracts, and the like. There are many things that people test (like "correct output" for the input) which may not be so valuable, particularly if several possible values may be correct.

So test contracts, not internals, and not representation. And please for the heaven's sake, don't test the behavior of your dependencies.

I read the article, and much of what he speaks of is tautological unit tests - testing something where someone could never have done anything but that. I've seen people unit test the behavior of filling up a collection then test to make sure the collection has all of those elements, for instance. And there, he has a point.

But there's a dangerous line there. And while the article makes a good point that too much of that type of testing can be detrimental, I've generally found it better to err on the safer side of more tests.

On your own project, or even on a small team, you can probably get away without them much of the time. But, on larger projects, where many different developers sometimes go back and make changes to code they didn't write, it's very easy for a new guy/gal to make changes with unanticipated consequences. When that occurs without sufficient test coverage, the project will wind up spending 10-20x more man hours to fix the issue.

Why Most Unit Testing is Waste https://news.ycombinator.com/item?id=7353767

Testing at Airbnb https://news.ycombinator.com/item?id=7313421

tested all 4+ billion inputs to ceil(), floor(), and round(), and pointed out that many libraries actually had high error rates, because of incorrect support for rounding, small values, NaN, and -0.0. http://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/

But if none of the code paths used for a test have changed, and the compiler hasn't changed, and there's nothing which depends on random input or timing effects, then why run those tests at all?

The reason is we don't have a good way to do that dependency analysis, which is why we run all of the tests all of the time. Or we manually partition them into "slow" and "fast" tests.
Code instrumented for coverage tells you which tests executed which portions of code. As I remember, Google's C++ build/test system was using this by late 2009 to efficiently run all tests on all checkins to HEAD.

Write adapters or facades that wrap external libraries, use those in your own code's unit tests. This makes you less bound to a specific library as well. Don't mock the outside world [0] for testing your adapters/facades/whatever, but do integration tests that cover your adapters using the real outside world.

You'd also do complete end to end tests where the entire system is used as if it were in production (acceptance testing). TDD makes a lot more sense if you think of it in those three layers: acceptance, integration, unit.

[0] Outside world means anything that's not your code -- networking, filesystem, external libraries, etc.

Mocks are useful. They help you write tests that are more robust, without having to resort to massive and complex @befores. At the same time, though, they have an effect that is more negative than positive on the ability to change the code under test.

Before you write a test, ask yourself "If a bug is found and fixed in the software or any of its dependencies, should this test ever fail?" If the answer is "yes" then don't write the test.

It’s ironic – the more powerful the mocking framework, the less pressure you feel to improve your design

TDD isn't a tool or a library, and thus isn't specific to a language or a framework - it's a philosophy.

Get, read and understand Kent Beck: "Test driven development by example". The rest will follow naturally.

examples http://code.google.com/p/appengine-go/source/browse/example/

stack http://stackoverflow.com/questions/tagged/google-app-engine+go?sort=votes&pageSize=15

http://stackoverflow.com/questions/tagged/google-app-engine

Cons
after working/creating a real application on GAE for a year, now my opnion is that unless you are making a application which needs to scale to million and million of users, don't use GAE. Maintaining and doing trivial tasks in GAE is a headache due to distributed nature, to avoid deadline exceeded errors, count entities or do complex queries requires complex code, so small complex application should stick to LAMP. http://stackoverflow.com/questions/110186/feedback-on-using-google-app-engine

http://stackoverflow.com/questions/565963/hidden-limitations-of-google-app-engine

Pros
http://stackoverflow.com/questions/2246550/are-people-really-using-google-app-engine-or-they-are-just-playing-with-it-beca

This could help http://sanatgersappa.blogspot.ie/2013/03/handling-multiple-file-uploads-in-go.html

• built-in A/B testing
• integrated social media ROI tracking (e.g. SumAll statistics)
• sales automation tools
  • abandoned cart reports
  • automated follow-up emails
  • automated payment reminders
• consumer behavior profiling to live-target marketing efforts based on behavior
• customer persona segmentation such as "single men / mothers with children / affluent customers", to increase marketing effectiveness
• easy-to-use multi-site and multilingual installations (Magento is cumbersome)
• helpdesk ticketing system
• built-in live chat
• built-in onestepcheckout
• automated SEO using artificial intelligence
• scheduled product imports to update product prices, stock, images attributes - including the ability to create new products and disable out-of-stock products
• automatic product categorization based on product description content
• social ecommerce ("share this product" with product landing pages for Facebook/Twitter)
• clever discounts such as bundled product discounts: "buy A+B together, get 5% discount on B"
• built-in product XML/CSV exports for ciao, kelkoo, thefind, google and so forth
• built-in newsletter or at the very least built-in Mailchimp support (with automatic setup)

https://news.ycombinator.com/item?id=7075447

oauth2/fb/g+?

https://plus.google.com/+MattCottingham/posts/UvNrneRjeUW

...which cause footer goes down.

http://stackoverflow.com/a/13303943/588759