2,245 karma · joined March 15, 2013
https://github.com/montanaflynn
I think the biggest thing to do is finalize the public API and release v1.0.0. I started with only functions but have since added types, so I'd like to figure out if I should support both or stick to one or the other. I have a feeling I could use an Interface to make stats work for both []float64 and []int but I'm not sure about that.
Another thing I'd like to do is add more test suites, I know they are out there for more mature statistics packages in other languages that could be ported to Go.
Speaking of mature packages, I think the Gnu GSL Statistics[1] could be a good roadmap for future functionality and API design decisions.
1. http://www.gnu.org/software/gsl/manual/html_node/Statistics....
I started with only []float64 but wanted to allow stuff like this:
func getData() []float64 {
// Do stuff to get the data and
// store it in var data []float64
return data
}
var d Float64Data = getData()
fmt.Println(d.Max())
1. https://github.com/montanaflynn/stats/blob/master/examples/m...2. https://github.com/montanaflynn/stats/blob/master/examples/m...
1. https://github.com/montanaflynn/stats/commit/a3efee7551d14a9...
However, after doing some research I learned that in addition to Panic() there's also Recover()[1], so I'll concede that there is similarity between panic/recover and throw/catch. Prior to my learning about Recover() I was under the assumption that Panic was just used to print a message and close a program with a non-zero status.
> no exceptions
1. http://commandcenter.blogspot.pt/2012/06/less-is-exponential...
# Generate coverage data
go test -coverprofile=coverage.out
# View coverage by function
go tool cover -func="coverage.out"
# View coverage line by line
go tool cover -html="coverage.out"1. https://gobyexample.com/errors
2. http://dave.cheney.net/2012/01/18/why-go-gets-exceptions-rig...
How does the pricing compare to traditional printers? I think a better pricing user experience could go a long way to converting users into customers. Something like choose the product and a slider for quantity that shows the cost, discount and comparison to competitors would be a huge improvement. Tables also have their place so they should be accessible.
When's the API going to go public? I'd be interested to see how it's designed.
Since I'm interested in highly concurrent web services I thought it was interesting they are underway porting their http server from Ruby's Unicorn to Golang. It would be nice to see a separate post on this process and any performance comparisons.
Checking out the source code[1] I noticed how nice and full featured the GitLab UI. As a daily GitHub user I was pleasantly surprised by how comfortable I was navigating around.
I've been anticipating the change and had already updated my .travis.yml file in my stats package[2] which would fall back to tip.
[1] https://github.com/izabera/j/commit/24e0c49e38c63c4f96f01725...
[1] http://i.imgur.com/wQoyhT1.png
Edit: You can create new APIs on blockspring by going directly to a route[2] which still works. I saw Alexa had an API but it needed authentication credentials, and since I already had found Alexa's undocumented API[3] I added it to blockspring[4] just for fun.
[2] https://open.blockspring.com/blocks/new
[3] http://data.alexa.com/data?cli=10&url=news.ycombinator.com
For anyone who wants to view the actual blockspring UI/UX along with what APIs are available.
I personally prefer seeing the product rather than reading marketing materials. In many cases (not specific to blockspring) they're completely different in terms of design, messaging and stated features.
fn search_entry_hashed<'a, K: Eq, V>(table: &'a mut RawTable<K,V>, hash: SafeHash, k: K)
-> Entry<'a, K, V> docker ps -q | xargs docker stats docker rmi -f $(docker images | grep "^<none>" | awk "{print \$3}")
I agree with everything else you're saying completely. Although messaging a value prop is hard when you have so many use cases. We faced the same issue and ended up trying to segment users as quickly and high up in the funnel as possible so we could speak directly to their needs.