Hacker Newsnew | comments | show | ask | jobs | submit | iampims's comments login

I found the pandas tests to be a great source for implementing robust CSV parsers:

https://github.com/pydata/pandas/blob/master/pandas/io/tests...

-----


No specs, no details of the “ecosystem”.

The Withings activité looks a lot nicer: http://www.withings.com/activite/en-US

-----


I can’t remember where I read it, but “studies“ have shown that to retain the same level of happiness you need to make $40K more per additional hour of commute.

Maybe that can be a starting point for negotiating a raise.

-----


HyperLogLog is for cardinality estimation, not set membership. A bloom filter would be more appropriate I believe.

-----


That's assuming a linear distribution of clicks and we all know it's never the case. It could well be over 10K sustained for peak hours. Averages are often misleading :)

-----


Without wanting to detract from the engineering accomplishments here (which I have never come close to), it's important to note that low-latency does not appear to be a design criteria i.e. it's okay if it takes a couple minutes to process events during peak load, which means there is some leeway for smoothing the input peaks over processing time.

Furthermore, these are just click events. It's okay to lose a few, so the design doesn't have to be especially good at making sure events aren't lost, as far as I can tell.

A good design is as much about what is left out as what is left in, which is the lesson between the lines here in my opinion.

-----


My thoughts exactly. If you come to my house and ring the bell, but it takes me 15mins to get off the couch to reach the door, I can't really claim to be "available" with a straight face. Sure, I "technically" am available, but that level of latency is not practical.

-----


The system is still available if your ring gets an acknowledgement of receipt. The latency for the request to be served is a design metric and has no impact on "availability"

-----


>> The system is still available if your ring gets an acknowledgement of receipt

This is the equivalent of (as per my example) yelling out "I hear ya! Coming..." and then take 15mins to reach the door. I never said that low latency implies anything about the level of availability; I merely meant that arguing about the availability of systems is incomplete without a thorough discussion of latency.

In the case of Bitly, I'm just curoius about the systems that are highly available but "require" low latency vs systems that don't require it. As ryanjshaw points out, the system may have a degree of tolerance for lossy click events. If you have a heterogeneous mix of systems with different tolerance levels, that surely affects the architecture does it not?

-----


They say that the clicks and shortened URLs are handled synchronously. It is the recording of the clicks for analysis that is done asynchronously.

-----


How can we help?

-----


Thank you for asking, much appreciated. :)

We'll probably do a small beta as we get the local cloud ready for release to make sure things are easy to use and work as expected. Since it'll be open source, I'm hoping the beta group can help find bugs and even send in pull requests if there are pieces they want added. The beta signup thread is here at the moment: https://community.spark.io/t/where-is-the-source-code-for-th...

Thanks, David

-----


Can anyone point me to a documentation that explains the consistency choices? Is it CP? Is it AP?

-----


You should also consider organizing your repo to be `go get` compliant.

http://golang.org/doc/code.html#Organization

-----


"go get" is kind of ok for trying out a new library quickly, but it's terrible for a real project.

Brad Fitzpatrick doesn't use it for Camlistore, instead he also does a Makefile-like system: https://github.com/bradfitz/camlistore

The sooner they deprecate the use of "go get", the better.

-----


Brad is keeping a copy of all 3rd party libraries in https://github.com/bradfitz/camlistore/tree/master/third_par...

Is this the approach you recommend? I’ve never built a large go project, so I’m eager to learn what the best practices are.

-----


I would not use Camlistore as an example for typical Go best-practices. Aside from the fact that >30% of the project (by Github's estimation) is written in various other languages, the opening comment on the Makefile reads, "The rest of this Makefile is mostly historical and should hopefully disappear over time."

Also, GP is conflating the issues of (1) fetching dependencies, (2) building a project, (3) installing the project. Makefiles aren't inherently evidence against "go get"; there is no reason that "go get" couldn't call "make" instead of "go build" (which it does).

The main reason that (almost) no pure Go projects have Makefiles anymore[0] is because they're frankly not needed. The standard Go build tools[1] are more than sufficient.

Don't take my word for it, though. Hop on #go-nuts on freenode and ask the guys there (many of whom are core contributors) what they think of Makefiles. They'll tell you the same thing that they told me over a year ago when I tried to advocate the use of Makefiles in pure Go projects.

[0] For what it's worth, before Go 1.0 came out, projects had Makefiles. The fact that Makefiles were a part of the standard build process and later removed should be a hint as to what the idiomatic Go approach is considered to be.

[1] "go get" isn't exactly a build tool in this sense; it's a convenience wrapper for cloning using git/hg/etc., followed by "go build" and "go install"

-----


> Also, GP is conflating the issues of (1) fetching dependencies, (2) building a project, (3) installing the project. Makefiles aren't inherently evidence against "go get"; there is no reason that "go get" couldn't call "make" instead of "go build" (which it does).

Go get conflates those issues. It fetches dependencies, builds the project, and installs it.

You don't need Makefiles, you're right. You need a script that sets GOPATH and calls "go build".

The most important thing is to not depend on the whims of somebody else's repository. In the best case, they'll push an update and break your code for a while. In the worst case, they'll delete their repo; then you get to find your local copy, push it to github, and change all your source files to point to that.

Heaven help you if other people want to fork your project. Say I wrote "github.com/jff/bigproject", which depends on my package "github.com/jff/mypackage". Now, if Joe wants to fork the package and make a tweak, he also has to fork the main project and change all of its imports to point to github.com/joe/mypackage so he can compile and test it. Of course he can't very well push that, he'll have to revert the import changes again assuming I accept his pull request for mypackage. I've dealt with this in real practice when we had 3 people working on a project which imported 3 other packages. We were forever dealing with build failures and changed import paths and of course could hardly do a pull from one fork to another. It was hell.

Better to distribute the entire workspace, with src/ containing all the packages you need and nothing else.

-----


Yes, that's what I recommend. I don't recommend a Makefile for a pure Go project, you really just need a shell script that sets GOPATH and calls "go build". That's what we do and it works well.

-----


> you really just need a shell script that sets GOPATH

No. :|

-----


It’s one thing to have a transparent salary policy, it’s a whole another world to publicly blog about people’s salary with a link to their Twitter account.

I hope all employees agreed to have their salary published on the buffer blog.

Kudos to them for trying something different.

-----


Yeah, I think it would have been more than enough to simply explain the formula and provide some anonymized examples.

On another note, I am quite surprised at how underpaid some of their positions seem. Senior iOS engineer barely cracking 100k in a very expensive market...

-----


Yeah, that's pretty ballsy. Seems like they're exposing themselves to unnecessary poaching risk. And what do they do in that situation? What if someone has a competing offer and they want to keep them around? Offer a bonus?

-----


It seems like they're ok with the poaching risk. I would assume most of their employees are happy enough, or they'd leave. I'm not sure having the salary posted is a big change from that perspective.

-----


People don't work that way. There is quite a bit of discontent or discomfort people will put up with until they are sufficiently motivated to take action. The number of people who are underpaid by 30% and unwilling to look for another job is far greater than the number who would accept that offer once its in front of them.

-----


If they are paying well then they are actually discouraging poaching

-----


The thing is that Buffer does not pay well... I will say that they pay on the lower side of acceptable.

-----


Nope, you talk about transparency, fairness, etc. If you're sticking to that salary structure you're not going to win on price in this market.

Warm fuzzies are important to a lot of people, look at how non-profits retain people. Also, there are a lot of people who don't know how to negotiate that would probably benefit from something like this.

I know a few devs who stick around at places because they like the people, etc, despite having had multiple offers for more money. Not my style, but it takes all sorts.

-----


> I know a lot of devs who stick around at places because they like the people, etc, despite having had multiple offers for more money.

Sure, but that's not the only consideration here. Employees don't always have the option of sticking around at a company. Not all startups make it, and people are terminated or laid off from jobs they love all the time.

If and when the time comes to find another job, a public record of your previous salary may not benefit you in your negotiations with prospective employers.

-----


If you're not employed you have a very poor BATNA.

-----


It seems like the bonuses for Senior and Lead are too small. The highest paid engineer is only making 20k more than the lowest paid, and 16k of that difference is because of location.

-----


I never understood the hypocrisy about hiding your salary.

-----


In general, it's seen as bragging if your salary is high, and mortifying if your salary is low, so it's usually just better to keep your mouth shut about it.

I've told a number of people my salary and regretted it every time. They seem to take a vicarious pleasure in telling other people how much money I make. "Oh, you should listen to delluminatus, he makes $xx thousand a year." Ugh.

-----


Companies (especially large ones) don't like it as it limits their negotiation position it can also disclose indirect discrimination e.g. "oops all the females seem to be under paid by 10/20%" which can get expensive.

And it also limits employees when they want to move as the new employer knows how much they make now.

-----


Yes, I understand why companies do it. They don't want people to know when they are under/overpaid.

What I don't understand is why people don't talk about it. If you tell and you learn you are overpaid then you feel good. If you learn you are underpaid, well, time to go negotiate/look elsewhere.

Do people think they ARE their salary? It's simply money that some people arbitrary decided to pay you...

-----


Well employees are funny about money in general any HR professional will tell you that :-)

Having a potential employer know exactly what you where paid before puts you at a big disadvantage when it comes to negotiating a new salary /package.

-----


Seems to be more of an American thing than a European thing. Not everyone will hide their salary here. Some will some won't.

-----


I never saw someone disclose his/her salary in France. There seems to be an expectation that doing so would produce jealousy and bitterness. So it's not only an American thing.

-----


If discussing salary in the workplace weren't taboo there'd be people unionizing left and right.

-----


Asymmetrical information = leverage

-----


What was costing you $200+ monthly bills? CPU? Storage? Datastore operations?

-----

More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: